On Tuesday 11 Dec 2012, Ross Younger wrote: Debian Testing, but I believe recent Ubuntus may suffer the same issue. The default banning is only for a few minutes. The problem is that ssh on an obscure port will probably not get any attacks for months. -- Chris Roberts

Hello, On Tue, Dec 11, 2012 at 03:35:15PM +0200, G. Miliotis wrote: logcheck also works, doesn't depend on a specific MTA. It doesn't aggregate events such as failed logins like logwatch does, but it does send you an email about them every hour. Or in my case, about fail2ban having banned them. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

On Tue, December 11, 2012 1:35 pm, G. Miliotis wrote: Given it's the season of goodwill I can't resist... Logwatch depends or Exim *or* mail-transport-agent, the latter being a functional virtual package provided by any of 13 MTA's. I'm running Postfix here. http://packages.debian.org/squeeze/mail-transport-agent http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg Mathew

Andy said: What makes it not - the extra work on your part, or some reluctance on the part of potential customers? I would have been happy to have it pre-installed and from the other side, I wouldn't dream of setting up a WordPress site for someone without something like the Limit Login Attempts plugin installed and activated for much the same reason. Ian

Would just like to thank the list for reminding me to install fail2ban. I have my SSH set up with 2-factor auth any how (with no root login), and I've been lucky enough not to be hit by an attack (so far, touch wood), but a little bit of "belt and braces" never goes amiss. Kind regards Murray Crane On 13 December 2012 14:12, Dom Latter <bitfolk-users(a)latter.org> wrote:

I'm using Google Authenticator, was a breeze to install and configure on both my VPS and my phone. Haven't checked, but I kinda wish Windows had GA auth support... The only potential problem is that if I wipe my phone (to install a different ROM, for instance), it's not particularly easy to automatedly transfer the GA details to the new ROM, but as long as you keep a (written) copy of the GA key, you can just reinstall and use the same key. Kind regards Murray Crane On 14 December 2012 09:28, Michael Stevens <mstevens(a)etla.org> wrote:

Hi Chris, On Thu, Dec 13, 2012 at 05:25:26PM +0000, Chris Dennis wrote: Someone has forked Fail2Ban to add IPv6 support: https://github.com/Th4nat0s/fail2ban so hopefully it won't be too long coming. I must admit I don't have an IPv6 SSH dictionary attack countermeasure myself at the moment. However, across 40 of my IPv6-enabled hosts there have been a total of only four failed attempts to log in from an IPv6 host. Some of those logs go back three years... Not tried that one. It looks pretty good though not present in Debian archive (I see there are some Debian packages provided though) Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

Hi Gerald, On Fri, Dec 14, 2012 at 09:24:36PM +0000, Gerald Davies wrote: If you could add any notes on that to: https://tools.bitfolk.com/wiki/Protecting_against_SSH_dictionary_attacks it would be much appreciated. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

Sorry about the direct first reply, my brain wasn't thinking properly and I hit reply instead of list-reply. On Fri, Dec 14, 2012 at 09:07:45PM +0000, Andy Smith wrote: Not to say that this makes it any less critical to secure your hardware, but scanning ipv6 ranges for even a single open port is extremely impractical. Take, for instance, a single /64, which is pretty much the most common prefix size (and what we are allocated). That's 2**64 ips. Or the equivalent of the current internet. Squared. 18446744073709551615 IP addresses. Assuming you could test for a port being responsive with just a single packet, and assuming each packet is a single byte (which it's not, by a long shot), that's 16 EXAbytes of outbound traffic. Now consider that there are the same number of those huge IPv6 ranges as there are IPs inside them. Scanning entire networks looking for open ports, vulnerable servers, etc, becomes completely impractical with IPv6. What's going to start happening now is hostname fuzzing, to try to discover machines by probing your dns. I can't remember where I heard/read about this, but it's interesting. -Jeremy

On Sat, Dec 15, 2012 at 08:44:28PM +0000, Chris Dennis wrote: Right, which means they have to start fuzzing your dns info (or just grab a zone transfer if your server is set up improperly) It makes it a more targeted attack than just scanning all of the IPs on the internet for vulnerable points. I really wish I could remember where I heard/read about this. It discusses the dns discovery and everything. -Jeremy

On 16/12/12 13:30, Chris Dennis wrote: [snip[ Is there any mileage in configuring each NIC with two quite different IPv6 addresses, one to be used for outbound connections, but with nothing at all listening on it? Any services which need to listen for incoming connections then listen on the second address. Would seem to render that particular attack vector useless. John

Hello, On Sun, Dec 16, 2012 at 04:52:44PM +0000, John Winters wrote: If you are this concerned about remote sites tracking your address then you probably want to use privacy addresses. http://en.wikipedia.org/wiki/IPv6#Privacy Would guarantee you don't have anything listening on it because it changes all the time. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

On 12/12/12 17:18, Peet Grobler wrote: <grin>.

On 2012/12/12 7:50 PM, Christopher Roberts wrote: Security through obscurity is not enough by itself. It might be a good idea, it will keep the script kiddies at bay, and automated scripts searching for specific services (e.g ssh) - most of the crap shared out there simply checks for an open port, some do check for greeting. But then I may or may not have written custom scripts that basically nmap's a host, connects to each open port with a timeout of 10 seconds, and saves any greeting it gets. This was then (or not) automatically scanned via scripts .Anything out-of-the-ordinary (non-IMAP response on IMAP port, any response at all on non-standard port, etc) was hypothetically reported. Very quick, simple and effective. If someone using a script similar to the above hypothetical script targets your specific machine, or the subnet you're on, or all the subnets of the vps provider (i.e not even you directly, they're after bitfolk) then your ssh on your non-standard port will be found, and your security through obscurity would be useless. Chances are also that one who writes a script like this is technically savvy enough to have a much higher chance of getting into your system. Yeah, you will keep all the botnet-run scripts away from your port :22, and keep yourself free from attacks from them, but that's not sufficient. It's debatable whether or not it is a good idea to run ssh on a non-standard port but I don't feel like getting into that now. We run fail2ban on ssh, ssmtp, pop3s, imaps. It has reduced the load on our operators considerably - not having to look through hundreds of lines of log files to see if the attacker was successful or not. I'm considering getting it (fail2ban) implemented on http for one of our company servers too. I've seen several attempts, in quick succession, to get into our system, specifically cross-domain scripting, and mysql non-escaped queries showing our (highly confidential) data. With lax parameters, but there.

On Thursday 13 Dec 2012, Dom Latter wrote: Yes indeed, highly unusual - but they were all the same IP address, so it is effectively a single attempt, albeit 103 times. Exactly so, but you wouldn't rely on that. I first moved to a non-standard port not for security, but because of the server load caused by the attacks. As soon as I shifted ssh port, my server load settled down. That was my only experience of running on port 22, so perhaps that was an unusual case? Absolutely, it is only there as a first line of defence. -- Chris Roberts