[opensuse] Coordinated, distributed ssh attacks?
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 13:21 +0200, Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
I see the same. The IP addresses often are from China or Indonesia. They are not getting in, but it seems a waste of resources on the server to deal with them. I am not sure how to proceed. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 08:58 -0400, Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 08:58 -0400, Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port.
Yes, that approach actually works very well. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 08:58 -0400, Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port.
Yes, that approach actually works very well.
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 17:16 +0200, Per Jessen wrote:
Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 08:58 -0400, Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port.
Yes, that approach actually works very well.
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 17:27 +0200, Hans Witvliet wrote:
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN.
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 17:27 +0200, Hans Witvliet wrote:
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN.
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources.
Roger, that's almost certainly the first time I've heard anyone say that - I couldn't care less about the resources wasted by ssh brute force attacks (as long as they're not actually denial-of-service), but I care a lot about anyone getting in. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 17:27 +0200, Hans Witvliet wrote:
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN.
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources.
Roger, that's almost certainly the first time I've heard anyone say that - I couldn't care less about the resources wasted by ssh brute force attacks (as long as they're not actually denial-of-service), but I care a lot about anyone getting in.
/Per
I'm pretty sure you misinterpreted what Roger said. He meant that his passwords are secure enough for his purposes. All automated ssh attacks are looking for totally insanely simple passwords, like "password". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday October 3 2009 7:02:29 pm John Andersen wrote:
I'm pretty sure you misinterpreted what Roger said.
He meant that his passwords are secure enough for his purposes.
All automated ssh attacks are looking for totally insanely simple passwords, like "password".
They'll certainly never get MY password! "swordfish". Am I brilliant or what? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 19:07 -0500, Constantinos Galilei wrote:
On Saturday October 3 2009 7:02:29 pm John Andersen wrote:
I'm pretty sure you misinterpreted what Roger said.
He meant that his passwords are secure enough for his purposes.
All automated ssh attacks are looking for totally insanely simple passwords, like "password".
They'll certainly never get MY password! "swordfish". Am I brilliant or what?
Perhaps i misjudged the situation.... If the O.P. manage _all_ involved passowrds, ok, allthough you can have miles of failing entries that get in the syslog. otoh, if other people (clients, customers, lusers) need to geet in, they are probably in control of their own passwords, and then you are in troubles: "password", "admin", "empty", "", "secret", "geheim" etcetcetc. '-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday October 4 2009 2:11:34 am Hans Witvliet wrote:
On Sat, 2009-10-03 at 19:07 -0500, Constantinos Galilei wrote:
On Saturday October 3 2009 7:02:29 pm John Andersen wrote:
I'm pretty sure you misinterpreted what Roger said.
He meant that his passwords are secure enough for his purposes.
All automated ssh attacks are looking for totally insanely simple passwords, like "password".
They'll certainly never get MY password! "swordfish". Am I brilliant or what?
Perhaps i misjudged the situation.... If the O.P. manage _all_ involved passowrds, ok, allthough you can have miles of failing entries that get in the syslog.
otoh, if other people (clients, customers, lusers) need to geet in, they are probably in control of their own passwords, and then you are in troubles: "password", "admin", "empty", "", "secret", "geheim" etcetcetc.
'-)
I have unfortunately been in a situation where I got to see what passwords people use. Even with strict requirements, they manage to put in the most elementary stuff. I should talk, though. I once used "youdneverguess". It was something I didn't mind being hacked, though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 17:27 +0200, Hans Witvliet wrote:
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN.
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources.
Roger, that's almost certainly the first time I've heard anyone say that - I couldn't care less about the resources wasted by ssh brute force attacks (as long as they're not actually denial-of-service), but I care a lot about anyone getting in.
/Per
I'm pretty sure you misinterpreted what Roger said.
Quite possibly. It really sounded like he wasn't worried about the brute force attacks.
He meant that his passwords are secure enough for his purposes.
All automated ssh attacks are looking for totally insanely simple passwords, like "password".
Not so totally insanely simple, not any more. I had a machine compromised about two years ago - the password for the account was a common English word, 7 characters with one vowel substituted by a '0'. /Per -- Per Jessen, Zürich (16.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-10-04 at 19:02 +0200, Per Jessen wrote:
All automated ssh attacks are looking for totally insanely simple passwords, like "password".
Not so totally insanely simple, not any more. I had a machine compromised about two years ago - the password for the account was a common English word, 7 characters with one vowel substituted by a '0'.
There is an utility in oS, I think it is called "john", with a database, that runs as cronjob and tries to crack users passwords. If it cracks one, it sends an email to root and the user. I removed it because it run for many hours at top cpu. The bad guys could be using something like that to generate the passwords. And we could use that utility also, for other reasons. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrI/J8ACgkQtTMYHG2NR9Xo7wCdFOYdxsNvV4NP8usJ4hvfC7Xh nC4Anj2KZXdTRBvFDbL82C4h7GDB0OFK =l4j4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2009-10-04 at 19:02 +0200, Per Jessen wrote:
John Andersen wrote:
Per Jessen wrote:
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 17:27 +0200, Hans Witvliet wrote:
hence i would recommend using keys and disable all password-logins. Other suggestion, use a VPN.
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources.
Roger, that's almost certainly the first time I've heard anyone say that - I couldn't care less about the resources wasted by ssh brute force attacks (as long as they're not actually denial-of-service), but I care a lot about anyone getting in.
The system that allows ssh access has only a few accounts. The few passwords that exist are controlled and less than obvious. Perhaps they might be found in a Martian dictionary. And it would have to be one of the dead Martial languages you don't hear very often these days. I am not trying to be cocky or over confident. I just wanted to point out that the machine that is being attacked has little in the way of accounts with simple minded passwords. Aside from ssh, it is a web gateway to one specific internal machine, also with limited user accounts and great control over passwords. Of course, no machine is impregnable. I think I will be moving sshd to another less-obvious port. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Not so totally insanely simple, not any more. I had a machine compromised about two years ago - the password for the account was a common English word, 7 characters with one vowel substituted by a '0'.
Many years ago, when I was working at IBM, they suggested combining 2 short words with a number, such as "out2lunch". ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Philip Dowie wrote:
Many years ago, when I was working at IBM, they suggested combining 2 short words with a number, such as "out2lunch". ;-)
pwgen -cynsB
;-)
I have used a WPA key, as generated by www.grc.com, as a password. A bit tough to remember though. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
James Knott wrote:
Philip Dowie wrote:
Many years ago, when I was working at IBM, they suggested combining 2 short words with a number, such as "out2lunch". ;-)
pwgen -cynsB
;-)
I have used a WPA key, as generated by www.grc.com, as a password. A bit tough to remember though. ;-)
So you let someone else generate a password for you? And GRC of all possible someone elses? :-o -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
James Knott wrote:
Philip Dowie wrote:
Many years ago, when I was working at IBM, they suggested combining 2 short words with a number, such as "out2lunch". ;-)
pwgen -cynsB
;-)
I have used a WPA key, as generated by www.grc.com, as a password. A bit tough to remember though. ;-)
So you let someone else generate a password for you?
And GRC of all possible someone elses?
:-o
Well, it's supposed to be a fresh random key each time. Of course, having the key doesn't get you much, if you don't know where it's used. I've also generated WEP keys by using the "ps aux|md5sum" command. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
My ssh access is password protected. It is not so much that someone gets in (although I keep an eye open), but rather all the attempts eat resources. Roger, that's almost certainly the first time I've heard anyone say that - I couldn't care less about the resources wasted by ssh brute force attacks (as long as they're not actually denial-of-service), but I care a lot about anyone getting in.
Ditto, dealing with the spray of spurious connection attempts is something current Operating Systems are very good at. I doubt the resources consumed have a measurable performance impact. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-10-03 at 17:16 +0200, Per Jessen wrote:
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port.
Yes, that approach actually works very well.
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
I think you can modify the ssh lines in /etc/services, and those apps might take the new port from there. But you have to change that in the client machines, of course. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrHf4wACgkQtTMYHG2NR9XAuACeMAP3fQ4lVX2bHTMdxcBLVxRe E0UAnAg2hhSTK6OTQtcCpUsIoCgTceAi =NWsS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
On Saturday, 2009-10-03 at 17:16 +0200, Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
I think you can modify the ssh lines in /etc/services, and those apps might take the new port from there. But you have to change that in the client machines, of course.
Joachims earlier suggestion is better - if I modify /etc/services, it goes for all ssh connedtions, which I probably would not want. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 03 October 2009 17:16:09 Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al. HTH, Joop ------------------------------------------------------------ Dit bericht is gescand op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. Mailscanner door http://www.prosolit.nl Professional Solutions fot IT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joop Beris wrote:
On Saturday 03 October 2009 17:16:09 Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page
IMHO, that solution is much easier implemented with three iptables rules or by using the standard openSUSE firewwall as described by Andreas Jaeger. Besides, fail2ban suffers from the same weakness that this attack was clearly designed to abuse.
I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al.
See other postings in this thread - rsync, scp et al is not a problem, you can configure the port on a host-by-host basis in /etc/ssh/ssh_config. Works very well. /Per -- Per Jessen, Zürich (16.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi! Am Montag 05 Oktober 2009 14:29:04 schrieb Joop Beris:
I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al.
It is not security through obscurity, it is load reduction by obscurity. And it does not break rsync if you use the proper syntax or correctly configure your ssh-client. Regards, Matthias -- Matthias Bach http://www.marix.org
Joop Beris wrote:
On Saturday 03 October 2009 17:16:09 Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page
I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al.
HTH,
Joop
You've misinterpreted the entire thread. Slow distributed ssh attacks go right thru Fail2ban, because they don't hit you from the same address and they don't hit you in quick succession. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Oct 5, 2009 at 2:46 PM, John Andersen
Joop Beris wrote:
On Saturday 03 October 2009 17:16:09 Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time.
Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page
I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al.
HTH,
Joop
You've misinterpreted the entire thread. Slow distributed ssh attacks go right thru Fail2ban, because they don't hit you from the same address and they don't hit you in quick succession.
So is it also true that denyhosts is failing to block these attacks? Even if you pull down rogue IPs from the denyhosts central DB? Thanks Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Greg Freemyer wrote:
On Mon, Oct 5, 2009 at 2:46 PM, John Andersen
wrote: Joop Beris wrote:
On Saturday 03 October 2009 17:16:09 Per Jessen wrote:
I've just remembered the only drawback - using rsync, scp and others who use ssh under the covers does become a little tiresome, but I think both rsync and scp have environment variables that'll set a usable default so you don't have to specify the new port all the time. Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page
I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al.
HTH,
Joop You've misinterpreted the entire thread. �Slow distributed ssh attacks go right thru Fail2ban, because they don't hit you from the same address and they don't hit you in quick succession.
So is it also true that denyhosts is failing to block these attacks? Even if you pull down rogue IPs from the denyhosts central DB?
Thanks Greg
Its a distributed attack. They might not EVER contact you twice from the same IP. Deny hosts is a losing battle. Allow hosts only works for specific static ips. Publickey is the only reasonable approach that I can see. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 05 October 2009 20:46:53 John Andersen wrote:
You've misinterpreted the entire thread. Slow distributed ssh attacks go right thru Fail2ban, because they don't hit you from the same address and they don't hit you in quick succession.
You're right. Somehow I missed the "distributed" in the subject. I'm sorry, I retract my comment. Obviously if the attacks are distributed, fail2ban, denyhosts etc., will not work. Note to self: read subject better. Regards, Joop ------------------------------------------------------------ Dit bericht is gescand op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. Mailscanner door http://www.prosolit.nl Professional Solutions fot IT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-10-06 at 08:30 +0200, Joop Beris wrote:
On Monday 05 October 2009 20:46:53 John Andersen wrote:
You've misinterpreted the entire thread. Slow distributed ssh attacks go right thru Fail2ban, because they don't hit you from the same address and they don't hit you in quick succession.
You're right. Somehow I missed the "distributed" in the subject. I'm sorry, I retract my comment. Obviously if the attacks are distributed, fail2ban, denyhosts etc., will not work.
I think there was a comment today on this attack on slashdot, with a link to some interseting explanation. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrLxNkACgkQtTMYHG2NR9UHSQCfdkmwvT1BylbIha1jPzaIspgu PI4An1Iu00JjyGjsElgoe8Oj3/cfHm2U =O261 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 07 October 2009 00:29:37 Carlos E. R. wrote:
I think there was a comment today on this attack on slashdot, with a link to some interseting explanation.
Yes, you're right. Here it is: http://linux.slashdot.org/story/09/10/04/2054259/Sloppy-Linux-Admins-Enable- Slow-Brute-Force-Attacks ------------------------------------------------------------ Dit bericht is gescand op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. Mailscanner door http://www.prosolit.nl Professional Solutions fot IT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 07 October 2009 02:39:03 am Joop Beris wrote:
Yes, you're right. Here it is: http://linux.slashdot.org/story/09/10/04/2054259/Sloppy-Linux-Admins-Enable - Slow-Brute-Force-Attacks
By far the best chuckle on the page: <quote> "DING DONG" you: answer door; Hello? guy: Hi I'm from linux, I'm here to install a critical patch. you: huh? from where? guy: linux, linus sent me, I need to patch your computers.. you: LINUS? REALLY? guy: yes, here is my official linux ID, and we have a nice CD full of new unreleased software for your trouble... Damn linux hackers are getting better and bolder every day. </quote> Good one Joop! -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Sat, 2009-10-03 at 08:58 -0400, Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed. You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I was thinking more along the lines of moving my sshd to a less known port. I access it in a controlled fashion. So, having it on a standard port is not (I think) a requirement for me. Then, our NAT could simply drop the sshd port accesses on the well-known port.
-- Roger Oberholtzer
As does port knocking. There are some firewalls (Shorewall) that allow you to set up port knocking, so that if you knock (ping) some arbitrary port it will unlock some other arbitrary port for some configurable period of time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 03.10.2009, Cristian Rodríguez wrote:
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
That's how I do it. Maybe I don't get the point, but after reading this whole thread I wonder why folks bother. Don't allow password login, or choose a strong one, and nothing more to it.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Heinz Diehl wrote:
On 03.10.2009, Cristian Rodríguez wrote:
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
That's how I do it. Maybe I don't get the point, but after reading this whole thread I wonder why folks bother. Don't allow password login, or choose a strong one, and nothing more to it..
The one issue I have with using ssh public keys is that the client setup seems to get tied to somebodys home-directory. Has anyone worked out a solution where the keys and such are kept on a USB stick (encrypted filesystem perhaps) such that an individual can carry it from place to place with minimal effort? We occasionally have people working from places where 1) their home-directory is not available or 2) is not trusted at all. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Heinz Diehl wrote:
On 03.10.2009, Cristian Rodríguez wrote:
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
That's how I do it. Maybe I don't get the point, but after reading this whole thread I wonder why folks bother. Don't allow password login, or choose a strong one, and nothing more to it..
The one issue I have with using ssh public keys is that the client setup seems to get tied to somebodys home-directory. Has anyone worked out a solution where the keys and such are kept on a USB stick (encrypted filesystem perhaps) such that an individual can carry it from place to place with minimal effort? We occasionally have people working from places where 1) their home-directory is not available or 2) is not trusted at all.
On Linux systems, you can use symlinks to the USB stick. With Windows, you can use Putty, which IIRC works just fine when insalled on a USB drive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
James Knott wrote:
On Linux systems, you can use symlinks to the USB stick. With Windows, you can use Putty, which IIRC works just fine when insalled on a USB drive.
You need PortaPuTTY for that. Putty runs fine, but you need portaputty or one of the other local-file hacked versions to store sessions and keys in files instead of in the registry. Both variants of portaputty will default to looking in some dir relative to the executable for such files, just for that reason, so you can place the exe and the support files together on a usb stick. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 19:00 +0200, Per Jessen wrote:
The one issue I have with using ssh public keys is that the client setup seems to get tied to somebodys home-directory. Has anyone worked out a solution where the keys and such are kept on a USB stick (encrypted filesystem perhaps) such that an individual can carry it from place to place with minimal effort? We occasionally have people working from places where 1) their home-directory is not available or 2) is not trusted at all.
I know some people carry their usb-stick with a openvpn-exe + config (keys/certificates) on it. On any XP (Internet-cafe's are normally polluted with M$) they can run their vpn client, and afterwards they can create ssh-connections (trough the tunnel), read mail safely and so-on (As default-GW and DNS are pushed by their own vpn-server)... hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 04.10.2009, Hans Witvliet wrote:
I know some people carry their usb-stick with a openvpn-exe + config (keys/certificates) on it. On any XP (Internet-cafe's are normally polluted with M$) they can run their vpn client, and afterwards they can create ssh-connections (trough the tunnel), read mail safely and so-on (As default-GW and DNS are pushed by their own vpn-server)...
And the key and other credentials are read into memory, and maybe got copied by the owner of the machine, or dumped to disk, or whatever... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2009-10-04 at 08:47 +0200, Heinz Diehl wrote:
On 04.10.2009, Hans Witvliet wrote:
I know some people carry their usb-stick with a openvpn-exe + config (keys/certificates) on it. On any XP (Internet-cafe's are normally polluted with M$) they can run their vpn client, and afterwards they can create ssh-connections (trough the tunnel), read mail safely and so-on (As default-GW and DNS are pushed by their own vpn-server)...
And the key and other credentials are read into memory, and maybe got copied by the owner of the machine, or dumped to disk, or whatever...
They use to be password protected. If you are more in control, one might use two-factor access for either ssh or vpn... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 04.10.2009, Hans Witvliet wrote:
They use to be password protected.
This doesn't help, any machine outside of your full control is not trustworthy. A simple keylogger grabs the password while entering. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 04 October 2009 07:23:50 Heinz Diehl wrote:
This doesn't help, any machine outside of your full control is not trustworthy. A simple keylogger grabs the password while entering.
Booting from USB stick might be better, in case that computer owner does not intend to steal passwords/data and have computer prepared for that activity. For instance by providing boot in a virtual machine that appear as normal boot, or tempering with a BIOS. Otherwise netbook, or similar device, that only uses public Internet access is the only solution, provided that web server that one wants to access uses some method against man in the middle type of attacks. The common ISP mail servers probably don't use such protection, encryption on both ends and one time transaction keys. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-10-04 at 11:04 -0500, Rajko M. wrote:
On Sunday 04 October 2009 07:23:50 Heinz Diehl wrote:
This doesn't help, any machine outside of your full control is not trustworthy. A simple keylogger grabs the password while entering.
Booting from USB stick might be better, in case that computer owner does not intend to steal passwords/data and have computer prepared for that activity.
I think it was a year ago where a problem was detected on some intel cpus that could be used to create a sort of trojan that would survive a reboot to a clean system. I forget the details, it was theoretical. Perhaps changing microcode? Something with protected modes, perhaps. I don't remember. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrI/bsACgkQtTMYHG2NR9VSLgCbB6y5w9ZTJ0TPpYsVotgLfMCn O0cAn1+BVoSBEb/kVkOedYmTbsNt9lKS =4PZH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Cristian Rodríguez wrote:
On 03/10/09 09:00, Roger Oberholtzer wrote:
I am not sure how to proceed.
You can't actually proceed ;-) this is an issue with any network service on planet earth, but you can protect yourself of being cracked by only using public key authentication.
I am seeing the same thing, but so far the blockhosts script has been doing a pretty good job of blocking them after a fixed number of unsuccessful attempts. -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 03 October 2009 13:21:32 Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
If it would come from the same IP address, the following SUSE Firewall option (set via /etc/sysconfig/SuSEfirewall2 would have helped: FW_SERVICES_REJECT_INT="" # Example: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" Still I suggest to enable it. Is there a similar rule for different IP-addresses? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
On Saturday 03 October 2009 13:21:32 Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
If it would come from the same IP address, the following SUSE Firewall option (set via /etc/sysconfig/SuSEfirewall2 would have helped:
FW_SERVICES_REJECT_INT="" # Example: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Still I suggest to enable it.
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-10-03 at 18:36 +0200, Per Jessen wrote:
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection.
The defense would have to be collaborative. Machines being attacked would have to report the IPs the attacks seem to come from to a central server, which would distribute the data to the protected "clients", who would then block the entire list. Another approach, if you don't expect connections from, say, China, would be to block based on geoip information. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrHgLAACgkQtTMYHG2NR9U8ngCcCtwkhaswL0d4LRHpYNj+0mfU 9ocAn3d4SjuMO9jcW6ihBkXMl6jYIpjX =TdLu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
On Saturday, 2009-10-03 at 18:36 +0200, Per Jessen wrote:
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection.
The defense would have to be collaborative. Machines being attacked would have to report the IPs the attacks seem to come from to a central server, which would distribute the data to the protected "clients", who would then block the entire list.
Yeah, it's a possibility, but it's certainly a lot less effort to use challenge-response or an alternate port.
Another approach, if you don't expect connections from, say, China, would be to block based on geoip information.
Yes, that idea struck me too this afternoon. It's not bad at all. /Per -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi! Am Samstag 03 Oktober 2009 18:56:23 schrieb Per Jessen:
Carlos E. R. wrote:
On Saturday, 2009-10-03 at 18:36 +0200, Per Jessen wrote:
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection.
The defense would have to be collaborative. Machines being attacked would have to report the IPs the attacks seem to come from to a central server, which would distribute the data to the protected "clients", who would then block the entire list.
Yeah, it's a possibility, but it's certainly a lot less effort to use challenge-response or an alternate port.
Something like that already exists in denyhosts. Regards, Matthias -- Matthias Bach http://www.marix.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-10-03 at 20:19 +0200, Matthias Bach wrote:
Am Samstag 03 Oktober 2009 18:56:23 schrieb Per Jessen:
Carlos E. R. wrote:
On Saturday, 2009-10-03 at 18:36 +0200, Per Jessen wrote:
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection.
The defense would have to be collaborative. Machines being attacked would have to report the IPs the attacks seem to come from to a central server, which would distribute the data to the protected "clients", who would then block the entire list.
Yeah, it's a possibility, but it's certainly a lot less effort to use challenge-response or an alternate port.
Something like that already exists in denyhosts.
Not as a collaborative, dynamic, effort? The bad guys collaborate somehow to attack us. To defend ourselves we have to join forces against them. But it probably needs some organization or business to provide the development effort, servers, and authentication. Ie, a server to list bots and block them. And probably inform the police, and a real effort by the authorities to go against them. Even fines against the owners of the botted machines, for not taking the appropriate precautions. Same as a car owner has some responsibilities, the owner of a machine connected to Internet must be responsible for it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrHrxUACgkQtTMYHG2NR9VMTgCfSS+Vm2n/DC2E9lTftx3LAEfd CfoAn10a/PldFlBH2hAVKD3OC1expJv5 =umeG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Oct 3, 2009 at 4:07 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2009-10-03 at 20:19 +0200, Matthias Bach wrote:
Am Samstag 03 Oktober 2009 18:56:23 schrieb Per Jessen:
Carlos E. R. wrote:
On Saturday, 2009-10-03 at 18:36 +0200, Per Jessen wrote:
Yeah, I have similar rules on all of my systems, but like I said, this attack appears to be specifically designed to circumvent that type of protection.
The defense would have to be collaborative. Machines being attacked would have to report the IPs the attacks seem to come from to a central server, which would distribute the data to the protected "clients", who would then block the entire list.
Yeah, it's a possibility, but it's certainly a lot less effort to use challenge-response or an alternate port.
Something like that already exists in denyhosts.
Not as a collaborative, dynamic, effort?
The bad guys collaborate somehow to attack us. To defend ourselves we have to join forces against them. But it probably needs some organization or business to provide the development effort, servers, and authentication.
Ie, a server to list bots and block them. And probably inform the police, and a real effort by the authorities to go against them. Even fines against the owners of the botted machines, for not taking the appropriate precautions. Same as a car owner has some responsibilities, the owner of a machine connected to Internet must be responsible for it.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkrHrxUACgkQtTMYHG2NR9VMTgCfSS+Vm2n/DC2E9lTftx3LAEfd CfoAn10a/PldFlBH2hAVKD3OC1expJv5 =umeG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Guys, I have a script that been storing all the ssh attacks for over the last 6 months if anyone one like a dump of it, I more than happy to share it. It got about 1000+ ip in it. -- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- http://en.opensuse.org/User:Terrorpup openSUSE Ambassador openSUSE Member skype -- terrorpup twitter -- terrorpup Identica -- terrorpup freenode(irc) -- terrorpup/lupinstein. friendfeed -- http://friendfeed.com/terrorpup Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. http://www.susestudio.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-10-03 at 16:19 -0400, Chuck Payne wrote:
Guys, I have a script that been storing all the ssh attacks for over the last 6 months if anyone one like a dump of it, I more than happy to share it. It got about 1000+ ip in it.
Well, that's useful if the IPs are static, but not if the bots are on dymaic addresses. Plus, six months is a lot of time, those machines could have been "repaired" since. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrHw4kACgkQtTMYHG2NR9VwRACfTYM36M8/dseT4rD/RwdfjZa2 TG8AnRjc9ZRAUCUyI4OnrSimdv7gsPQu =8ogA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Oct 3, 2009 at 5:34 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2009-10-03 at 16:19 -0400, Chuck Payne wrote:
Guys, I have a script that been storing all the ssh attacks for over the last 6 months if anyone one like a dump of it, I more than happy to share it. It got about 1000+ ip in it.
Well, that's useful if the IPs are static, but not if the bots are on dymaic addresses. Plus, six months is a lot of time, those machines could have been "repaired" since.
- -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkrHw4kACgkQtTMYHG2NR9VwRACfTYM36M8/dseT4rD/RwdfjZa2 TG8AnRjc9ZRAUCUyI4OnrSimdv7gsPQu =8ogA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Well here are my status for today, 77 attacks alone this week from China. Lucky no attacks today, but you can see were most of my attacks are coming from. http://www.magidesign.com/~cpayne/today.php -- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- http://en.opensuse.org/User:Terrorpup openSUSE Ambassador openSUSE Member skype -- terrorpup twitter -- terrorpup Identica -- terrorpup freenode(irc) -- terrorpup/lupinstein. friendfeed -- http://friendfeed.com/terrorpup Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. http://www.susestudio.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 23:34 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2009-10-03 at 16:19 -0400, Chuck Payne wrote:
Guys, I have a script that been storing all the ssh attacks for over the last 6 months if anyone one like a dump of it, I more than happy to share it. It got about 1000+ ip in it.
Well, that's useful if the IPs are static, but not if the bots are on dymaic addresses. Plus, six months is a lot of time, those machines could have been "repaired" since.
You want to block them altogether? Think again, if they came from a dynamic address, you'll block the next owner as well. Just block passwords all together, it doesn't claim any resources at your side (In contrast of scrutinysing that number of addresses), and don't have to analyse your logfiles for ssh-attacks, as there wont be any anymore. hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hans Witvliet wrote:
Just block passwords all together, it doesn't claim any resources at your side (In contrast of scrutinysing that number of addresses), and don't have to analyse your logfiles for ssh-attacks, as there wont be any anymore.
Hans, I'm curious - I've always liked this solution, but how do you manage all the keys? AFAICT, each server needs to know about (have the key for) each possible client, right? /Per -- Per Jessen, Zürich (13.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2009-10-04 at 10:55 +0200, Per Jessen wrote:
Hans Witvliet wrote:
Just block passwords all together, it doesn't claim any resources at your side (In contrast of scrutinysing that number of addresses), and don't have to analyse your logfiles for ssh-attacks, as there wont be any anymore.
Hans, I'm curious - I've always liked this solution, but how do you manage all the keys? AFAICT, each server needs to know about (have the key for) each possible client, right?
Yes, Uptill next release of openssh, there are two mechanisms 1) On the destination-machine you need in the file ~/.ssh/authorized_keys all the public keys for that particular user If that users has different key-pairs on different machines, you'll see here multiple public keys. 2) keypairs can also be tied to a specific noninteractive (remote-)application, Like rsync. Generating the keys can be done also in two ways, either on the computer itself, or on a security device. If they are created localy, one can still afterwards store them on a smardcard, and protect the private key with a pin-code. Next version of openssh (openssh-5.2) has an huge step forward (i hope it is 11.2, with this option activated during compilation). openssh is then also capable to extract the public key from an PKI-certificate. If you have PKI-certificates from thawte, verisign, cacert, gouvernement (and so on), you will be able to use these. This was already available in the commercial version of ssh, from now-on also in openssh. Hans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-10-04 at 01:30 +0200, Hans Witvliet wrote:
On Sat, 2009-10-03 at 23:34 +0200, Carlos E. R. wrote:
Well, that's useful if the IPs are static, but not if the bots are on dymaic addresses. Plus, six months is a lot of time, those machines could have been "repaired" since.
You want to block them altogether? Think again, if they came from a dynamic address, you'll block the next owner as well.
That's what I was meaning. You can not use a static blocking list, it has to be dynamic. New addresses have to be added and old removed.
Just block passwords all together, it doesn't claim any resources at your side (In contrast of scrutinysing that number of addresses), and don't have to analyse your logfiles for ssh-attacks, as there wont be any anymore.
It is a possibility, where it is possible to use it. For example, my router has ssh, but the login user is fixed by the manufacturer and keys are impossible to add. Thus I have to disable it completely, from the outside. Then, if I'm to connect from the outside to my PC, I may not have control of the ssh home directory to place my key there - nor might I want to do that, allowing somebody else coming later to steal my key from the file. ssh would have to take the key from a usb stick and never store it locally. For windows, it has been said to use putty on a usb stick, but then, some setups remove the usb port. Another hassle is the first connection, because you need to store the other part of the key on the server, and for that you need to connect first, without keys. You can see how sourceforge solves (solved?) that, you have to upload the key on a webpage. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrId8kACgkQtTMYHG2NR9VG/ACghACq44tFjm+Lv2JphsCwDiu4 nDQAoIHwsSpFRjfgC1bR2cnYO2IIX1+b =clIB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Carlos E. R.
On Saturday, 2009-10-03 at 20:19 +0200, Matthias Bach wrote:
Something like that already exists in denyhosts.
Not as a collaborative, dynamic, effort?
Yes, as a collaborative, dynamic effort. from http://denyhosts.sourceforge.net Denyhosts now has over 70,000 users contributing synchronization data and thousands more using DenyHosts without the optional synchronization feature.. What is DenyHosts? DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks). If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system? DenyHosts attempts to address the above... and more.
The bad guys collaborate somehow to attack us. To defend ourselves we have to join forces against them. But it probably needs some organization or business to provide the development effort, servers, and authentication.
Ie, a server to list bots and block them. And probably inform the police, and a real effort by the authorities to go against them. Even fines against the owners of the botted machines, for not taking the appropriate precautions. Same as a car owner has some responsibilities, the owner of a machine connected to Internet must be responsible for it.
I have been using denyhosts for 3+ years and the last two days it has been very busy, but that has subsided today as I suspect it's database has captured *most* of the subject addresses. available: http://download.opensuse.org/repositories/network:/utilities/openSUSE_Factor... http://download.opensuse.org/repositories/network:/utilities/openSUSE_11.1 http://download.opensuse.org/repositories/network:/utilities/openSUSE_11.0 http://download.opensuse.org/repositories/network:/utilities/openSUSE_10.3 http://download.opensuse.org/repositories/network:/utilities/SLE_11 http://download.opensuse.org/repositories/network:/utilities/SLE_10 -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-10-03 at 19:22 -0400, Patrick Shanahan wrote:
* Carlos E. R. <> [10-03-09 16:09]:
Not as a collaborative, dynamic, effort?
Yes, as a collaborative, dynamic effort.
from http://denyhosts.sourceforge.net
Denyhosts now has over 70,000 users contributing synchronization data and thousands more using DenyHosts without the optional synchronization feature..
Interesting...
I have been using denyhosts for 3+ years and the last two days it has been very busy, but that has subsided today as I suspect it's database has captured *most* of the subject addresses.
Mmm... interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrIdToACgkQtTMYHG2NR9WiUgCfVzJXunGBva+BahcCa6pGOkio MjQAoIwA1NVCchn9ZOBLmF7punMHOUQW =7AzW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 03 October 2009 06:21:32 am Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
/Per
Per, Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold! -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2009-10-03 at 19:28 -0500, David C. Rankin wrote:
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Untill they do a full nmap, and decide that if it's a unix machine and port-22 is not there, it might be worthwhile scanning port 2222 or so.. It's what my cert-team calls: "security through obscurity" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 04 October 2009 02:16:32 am Hans Witvliet wrote:
On Sat, 2009-10-03 at 19:28 -0500, David C. Rankin wrote:
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Untill they do a full nmap, and decide that if it's a unix machine and port-22 is not there, it might be worthwhile scanning port 2222 or so..
It's what my cert-team calls: "security through obscurity"
Yes, But unless someone is targeting YOU, all the script kiddie nonsense on port 22 will be completely eliminated. I have two hosts that sit exposed on the net and about 1.5 years ago, I got fed up with all the crack attempts I would receive against port 22 (300 - 3000+ per day, EVERY day). Since moving ssh to a high port, I have had ZERO crack attempts. 300 to 3000+ attempts PER DAY --> down to ZERO in a year-and-a-half. (Like I said --> Worth its weight in gold ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 04 October 2009 09:16:32 Hans Witvliet wrote:
On Sat, 2009-10-03 at 19:28 -0500, David C. Rankin wrote:
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Untill they do a full nmap, and decide that if it's a unix machine and port-22 is not there, it might be worthwhile scanning port 2222 or so..
It's what my cert-team calls: "security through obscurity"
Fail2ban is your friend: http://www.fail2ban.org/wiki/index.php/Main_Page I use it to protect my home server against SSH and Apache attacks. Works like a charm and I don't have to use the "security through obscurity" approach by running my ssh daemon on a different port. Sure, it will stop scripted attacks, but it breaks rsync et al. I used to run denyhosts before, but Fail2ban can also check for other attacks, like authentication to Apache without much configuration. Hosts that attack me, get locked out for 24 hours, which seems long enough to convince them to stay away. For real serious offenders, which come once a month or so, I permanently block them by adding them to /etc/hosts.deny. HTH, Joop ------------------------------------------------------------ Dit bericht is gescand op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. Mailscanner door http://www.prosolit.nl Professional Solutions fot IT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
On Saturday 03 October 2009 06:21:32 am Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
/Per
Per,
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Until this distributed attack my regular method of blocking based on number of attempts from a single IP has worked just fine, but yes, I've now moved sshd to another port on all my external systems. The local systems don't allow external ssh access. I'm still considering moving to the no-password-login setup as Hans Witvliet suggested. It's clearly the optimal solution, I'm just a little concerned about the management when each server needs to "know" about (need to have the key) each possible client. /Per -- Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 04 October 2009 03:52:59 am Per Jessen wrote:
David C. Rankin wrote:
On Saturday 03 October 2009 06:21:32 am Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
/Per
Per,
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Until this distributed attack my regular method of blocking based on number of attempts from a single IP has worked just fine, but yes, I've now moved sshd to another port on all my external systems. The local systems don't allow external ssh access. I'm still considering moving to the no-password-login setup as Hans Witvliet suggested. It's clearly the optimal solution, I'm just a little concerned about the management when each server needs to "know" about (need to have the key) each possible client.
/Per
Per, That's the best part about it. On each host, just do cd ~/.ssh ssh-keygen -t dsa cp id_dsa id_dsa.hostname cp id_dsa.pub id_dsa.pub.hostname do the same thing for root but append an r to the end of the names (id_dsa.pub.hostnamer). Next, collect you public keys in one location on a box that you can reach from the lan. I just use ~/.pkeys. Then create an "authorized_keys" file that contains all the public keys. I just use a small script placed in the same directory as the keys that searches the directory and automatically adds any new keys in the directory to an authorized_keys file and then distributes it to the hosts on my network vi copy or rsync: http://www.3111skyline.com/download/linux/scripts/config/newkey-example.txt Another handy script for the clients is "rokey" (short for remove offending key). If a box is reloaded, etc. and you need to remove the key from your from ~/.ssh/known_hosts due to strict check being enabled, then just simply type: rokey key-number Where key-number is the number in the error message on the terminal. (just saves work;-) http://www.3111skyline.com/download/linux/scripts/config/rokey.txt Once you are all setup, then edit /etc/ssh/sshd_config and disable challenge/response and password authentication and you are done. No more password attempts will be allowed regardless of which port ssh is on. But, if ssh is on a high port, then you don't even get anything in the logs :p PasswordAuthentication no ChallengeResponseAuthentication no (don't forget the put your host/port combinations in either /etc/ssh/ssh_config (system wide) or ~/.ssh/config at the user level. Example:) Host alchemy.yourDomain.com alchemy Port 22 Host archangel.yourDomain.com archangel Port 10201 Host arete.yourDomain.com arete Port 10202 Host ecstasy.yourDomain.com ecstasy Port 10203 Host killerz.yourDomain.com killerz Port 22 Host dcrgx.yourDomain.com dcrgx Port 22 Yes the Port 22 defs are required, and you have to put Host on one line and Port on the following line. Then the port change is transparent for all ssh,rsync,scp,etc.. work. With sftp, you still have to specify the port number: sftp://host.domain.com:10203/home/per/... This may have already been covered, but if you want to limit ssh access to members of a specific group, you can do something like this with the AllowGroups parameter: AllowGroups wheel -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
On Sunday 04 October 2009 03:52:59 am Per Jessen wrote:
I'm still considering moving to the no-password-login setup as Hans Witvliet suggested. It's clearly the optimal solution, I'm just a little concerned about the management when each server needs to "know" about (need to have the key) each possible client.
/Per
Per,
That's the best part about it. On each host, just do
cd ~/.ssh ssh-keygen -t dsa cp id_dsa id_dsa.hostname cp id_dsa.pub id_dsa.pub.hostname
do the same thing for root but append an r to the end of the names (id_dsa.pub.hostnamer).
Hi David thanks, I'll have to take a closer look now. I do understand the process, I've got a couple of dedicated users operating only with challenge-response (for automated tasks). I guess the main reason I'm a little concerned is that seen from an ssh pov, I've got 13 external servers/client and 10-12 local clients/servers. Times 4 users who at times will need the access. Yes, local workstations have a shared /home, but production systems don't nor do the external systems. Hmm, I've just been reading a bit about ssh agent forwarding - that might just solve part of my issue. I was thinking of the following scenario: user-1 on client-1 connects server-1. Does some stuff, then needs to rsync something from server-2 or client-4 - as long as user-1@client-1 is allowed access to server-2 or client-4, will it still work (via this ssh agent forwarding setup)? /Per -- Per Jessen, Zürich (9.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 05 October 2009 01:50:55 am Per Jessen wrote:
Hmm, I've just been reading a bit about ssh agent forwarding - that might just solve part of my issue. I was thinking of the following scenario: user-1 on client-1 connects server-1. Does some stuff, then needs to rsync something from server-2 or client-4 - as long as user-1@client-1 is allowed access to server-2 or client-4, will it still work (via this ssh agent forwarding setup)?
I've played with the agent forwarding and the keychain utilities and I have always found them more work than help. Since you only have to maintain one ~/.ssh/config file and one ~/.ssh/authorized_keys file, it has always been easier just to distribute any new changes with a simple bash script. It is exceeding easy once you have your passwordless login working because you simply set up at text file that has both file names in it: ~/.ssh/config ~/.ssh/authorized_keys and save it as something like sshfiles, then just have a short script that calls rsync from a loop with the users@hostnames as the iterator, something like: for i in juan@box1 manny@box2 fred@box2 greg@box3.thisdomain.com; do rsync -uv --files-from=sshfiles $i done That way it is all done with basic ssh without any of the gimmicks that are usually attached to the keychain or other automation methods. Of course the other ways may suit your needs better, but after fighting this for a couple of years, this is what I have found works the best. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (21)
-
Adam Tauno Williams
-
Andreas Jaeger
-
Brian K. White
-
Carlos E. R.
-
Chuck Payne
-
Constantinos Galilei
-
Cristian Rodríguez
-
David C. Rankin
-
Greg Freemyer
-
Hans Witvliet
-
Heinz Diehl
-
James Knott
-
John Andersen
-
Joop Beris
-
Matthias Bach
-
Moby
-
Patrick Shanahan
-
Per Jessen
-
Philip Dowie
-
Rajko M.
-
Roger Oberholtzer