Re: Blocking a slow-burning SSH bruteforce
2010/1/1 J65nko j65...@gmail.com After some posts a discussion on the freebsd-table mailing list goes into several approaches to deal with these SSH probes. See http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053326.html You still could allow outgoing ssh traffic on port 22 and allow incoming SSH on another port. Adriaan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org one thing i have done in the past is severly lock down ssh to a small set of ips with pf. I then ran openvpn to allow me to access from random places, and left the acl on that fairly loose. Everything was also based on keys and certs. Another way to do it is purchase a cheap shell somewhere, and use it to bounce off to get to your box. Your machine can then be acl'ed up well. Make sure to use agent forwarding though just in case anyone is running key logging etc on the remote shell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Blocking a slow-burning SSH bruteforce
I tend to think there's not much I can do about this, but I'll ask anyway. I've implemented sshguard to block the normal bruteforce attacks - which seems to be working reasonably well. However now I have the following: Jan 1 17:42:52 timeserver sshd[1755]: error: PAM: authentication error for illegal user but from 190.146.246.36 Jan 1 17:55:09 timeserver sshd[1788]: error: PAM: authentication error for illegal user byung from 212.243.41.9 Jan 1 18:07:38 timeserver sshd[1809]: error: PAM: authentication error for illegal user cac from 148.233.140.193 Jan 1 18:20:06 timeserver sshd[1832]: error: PAM: authentication error for illegal user cachou from 121.52.215.180 Jan 1 18:32:21 timeserver sshd[1851]: error: PAM: authentication error for illegal user calla from 212.243.41.9 Jan 1 18:44:35 timeserver sshd[1884]: error: PAM: authentication error for illegal user calube from 83.211.160.211 Jan 1 19:09:12 timeserver sshd[1923]: error: PAM: authentication error for illegal user cancy from 194.51.12.238 Jan 1 19:21:35 timeserver sshd[1946]: error: PAM: authentication error for illegal user candice from 82.106.226.77 Jan 1 19:46:12 timeserver sshd[1997]: error: PAM: authentication error for illegal user candyw from 116.55.226.131 Now this seems to me to be a dictionary attack on timeserver, and I'd guess that it's a botnet behind it. It's rather sophisticated since it's only attempting 1 user and password combination per source - so it's far too little to trigger the sshguard rules. Even if it did trigger, it wouldn't prevent the attacks. Apart from switching away from user authentication to private/public keys ... is there anything I can do to mitigate these attacks? Any advice welcome. Dave. -- David Rawling PD Consulting And Security Mob: +61 412 135 513 Email: d...@pdconsec.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On 1/1/10 8:56 AM, David Rawling wrote: I tend to think there's not much I can do about this, but I'll ask anyway. I've implemented sshguard to block the normal bruteforce attacks - which seems to be working reasonably well. However now I have the following: Jan 1 17:42:52 timeserver sshd[1755]: error: PAM: authentication error for illegal user but from 190.146.246.36 Jan 1 17:55:09 timeserver sshd[1788]: error: PAM: authentication error for illegal user byung from 212.243.41.9 Jan 1 18:07:38 timeserver sshd[1809]: error: PAM: authentication error for illegal user cac from 148.233.140.193 Jan 1 18:20:06 timeserver sshd[1832]: error: PAM: authentication error for illegal user cachou from 121.52.215.180 Jan 1 18:32:21 timeserver sshd[1851]: error: PAM: authentication error for illegal user calla from 212.243.41.9 Jan 1 18:44:35 timeserver sshd[1884]: error: PAM: authentication error for illegal user calube from 83.211.160.211 Jan 1 19:09:12 timeserver sshd[1923]: error: PAM: authentication error for illegal user cancy from 194.51.12.238 Jan 1 19:21:35 timeserver sshd[1946]: error: PAM: authentication error for illegal user candice from 82.106.226.77 Jan 1 19:46:12 timeserver sshd[1997]: error: PAM: authentication error for illegal user candyw from 116.55.226.131 Now this seems to me to be a dictionary attack on timeserver, and I'd guess that it's a botnet behind it. It's rather sophisticated since it's only attempting 1 user and password combination per source - so it's far too little to trigger the sshguard rules. Even if it did trigger, it wouldn't prevent the attacks. Apart from switching away from user authentication to private/public keys ... is there anything I can do to mitigate these attacks? Any advice welcome. Dave. -- Few options I can think of in random order...I use #1: 1. Run SSH on an obscure port. Seriously, thats one of the easiest things to do. Since I have done that, I have had ZERO attempts and it works perfectly as long as users know the odd port. In fact, I dont know anyone in our IT circle of friends that runs SSH on port 22. 2. Consider controlling/limiting access via 'pf' if your running 'pf'. Of course with your examples coming from all different IPs, thats not likely gonna help much. 3. Just ignore it - they aren't getting in...similar to spammers being rejected by RBLsits traffic, but cant be a whole lot. 4. Limit login time window too...I run a very narrow window of time to login and a LOW number of attempted logins per session. -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On 2/01/2010 2:07 AM, J.D. Bronson wrote: Few options I can think of in random order...I use #1: 1. Run SSH on an obscure port. Seriously, thats one of the easiest things to do. Since I have done that, I have had ZERO attempts and it works perfectly as long as users know the odd port. In fact, I dont know anyone in our IT circle of friends that runs SSH on port 22. 2. Consider controlling/limiting access via 'pf' if your running 'pf'. Of course with your examples coming from all different IPs, thats not likely gonna help much. 3. Just ignore it - they aren't getting in...similar to spammers being rejected by RBLsits traffic, but cant be a whole lot. 4. Limit login time window too...I run a very narrow window of time to login and a LOW number of attempted logins per session. Darn. 1 is out because 22 is the one port that most organisations (including mine) allow out of their networks for administering routers. 2 is unfortunately not an option (as a consultant I do work from many networks) 4 - again I might have to log in any time ... 3 seems the best approach. Thanks for your thoughts, it's good to get second opinions. Dave. -- David Rawling PD Consulting And Security Mob: +61 412 135 513 Email: d...@pdconsec.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On Sat, 02 Jan 2010 01:56:17 +1100 David Rawling d...@pdconsec.net replied: Apart from switching away from user authentication to private/public keys ... is there anything I can do to mitigate these attacks? Any advice welcome. Is there a specific reason that you don't want to use keys? -- Jerry ges...@yahoo.com |=== |=== |=== |=== | Most general statements are false, including this one. Alexander Dumas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On 2/01/2010 2:24 AM, Jerry wrote: On Sat, 02 Jan 2010 01:56:17 +1100 David Rawlingd...@pdconsec.net replied: Apart from switching away from user authentication to private/public keys ... is there anything I can do to mitigate these attacks? Any advice welcome. Is there a specific reason that you don't want to use keys? If we're being brutally honest - I'd probably lose them ... Dave. -- David Rawling PD Consulting And Security Mob: +61 412 135 513 Email: d...@pdconsec.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On 1/1/10 9:19 AM, David Rawling wrote: Darn. 1 is out because 22 is the one port that most organisations (including mine) allow out of their networks for administering routers. 2 is unfortunately not an option (as a consultant I do work from many networks) 4 - again I might have to log in any time ... 3 seems the best approach. Thanks for your thoughts, it's good to get second opinions. Dave. I understand using/needing port 22 opened...but what another widely used port..like for Citrix (sp?) or something? - most firewalls have those ports open. As far as controlling login time and access, I meant something like this: # Authentication: LoginGraceTime 1m MaxAuthTries 2 # Allow staff access and users no access AllowGroups staff -- J.D. Bronson Information Technology Aurora Health Care - Milwaukee WI ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
On Fri, Jan 1, 2010 at 8:56 AM, David Rawling d...@pdconsec.net wrote: I tend to think there's not much I can do about this, but I'll ask anyway. I've implemented sshguard to block the normal bruteforce attacks - which seems to be working reasonably well. However now I have the following: Jan 1 17:42:52 timeserver sshd[1755]: error: PAM: authentication error for illegal user but from 190.146.246.36 Jan 1 17:55:09 timeserver sshd[1788]: error: PAM: authentication error for illegal user byung from 212.243.41.9 Jan 1 18:07:38 timeserver sshd[1809]: error: PAM: authentication error for illegal user cac from 148.233.140.193 Jan 1 18:20:06 timeserver sshd[1832]: error: PAM: authentication error for illegal user cachou from 121.52.215.180 Jan 1 18:32:21 timeserver sshd[1851]: error: PAM: authentication error for illegal user calla from 212.243.41.9 Jan 1 18:44:35 timeserver sshd[1884]: error: PAM: authentication error for illegal user calube from 83.211.160.211 Jan 1 19:09:12 timeserver sshd[1923]: error: PAM: authentication error for illegal user cancy from 194.51.12.238 Jan 1 19:21:35 timeserver sshd[1946]: error: PAM: authentication error for illegal user candice from 82.106.226.77 Jan 1 19:46:12 timeserver sshd[1997]: error: PAM: authentication error for illegal user candyw from 116.55.226.131 Now this seems to me to be a dictionary attack on timeserver, and I'd guess that it's a botnet behind it. It's rather sophisticated since it's only attempting 1 user and password combination per source - so it's far too little to trigger the sshguard rules. Even if it did trigger, it wouldn't prevent the attacks. Apart from switching away from user authentication to private/public keys ... is there anything I can do to mitigate these attacks? Any advice welcome. Dave. If your passwords are complex, those attacks could come for a million years on localhost and not get anywhere let alone over a latent network. Worrying about that stuff with complex password is akin to devising a plan for repelling a Godzilla attack. Another point is these attacks typically try common passwords, it's a distributed common password attack, not a brute force. If you are concerned about this for other reasons, eg you have local users on the system and you don't enforce a password policy. there are several utilities for dealing with this. I'm not familar with sshguard, but these types of attacks are blocked quite well with denyhosts, since the ip's are recycled through eventually and you can configure the parameters for blocking. Denyhosts also has the ability to download to, and upload from a shared blocklist. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
David Rawling wrote: On 2/01/2010 2:07 AM, J.D. Bronson wrote: Few options I can think of in random order...I use #1: 1. Run SSH on an obscure port. Seriously, thats one of the easiest things to do. Since I have done that, I have had ZERO attempts and it works perfectly as long as users know the odd port. In fact, I dont know anyone in our IT circle of friends that runs SSH on port 22. 2. Consider controlling/limiting access via 'pf' if your running 'pf'. Of course with your examples coming from all different IPs, thats not likely gonna help much. 3. Just ignore it - they aren't getting in...similar to spammers being rejected by RBLsits traffic, but cant be a whole lot. 4. Limit login time window too...I run a very narrow window of time to login and a LOW number of attempted logins per session. Darn. 1 is out because 22 is the one port that most organisations (including mine) allow out of their networks for administering routers. 2 is unfortunately not an option (as a consultant I do work from many networks) 4 - again I might have to log in any time ... 3 seems the best approach. Thanks for your thoughts, it's good to get second opinions. A final option is something like port knocking. (http://www.portknocking.org/) basicly a demon that checks if a specific packet/sequence has been blocked by the firewall and opens a port if the conditions are met. I havent actually tried it and it sounds a bit fiddely to be honest but it should work and theres security/knock in ports if you want to try it. Vince Dave. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Blocking a slow-burning SSH bruteforce
After some posts a discussion on the freebsd-table mailing list goes into several approaches to deal with these SSH probes. See http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053326.html You still could allow outgoing ssh traffic on port 22 and allow incoming SSH on another port. Adriaan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
