Spike in SSH attacks
http://isc.sans.edu/diary.html?storyid=9031 http://isc.sans.edu/diary.html?storyid=9034 Apparently attackers are going after keyboard interactive authentication, which is separate from password authentication. If you are using SSH public/private keys only, make sure you have ChallengeResponseAuthentication no set in your /etc/ssh/sshd_config file. If you must use passwords, make sure everyone has a strong password, and consider using techniques like scan detection, IP-address access control, port knocking, non-standard port, etc. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
FYI, I've been using sshguard for a few month to drop routes to sites that are probing my server. None of the docs seemed to be quite right, so I wrote up some notes on getting it working debian/Lenny here: http://nozell.com/blog/2010/03/09/sshguard-on-debianlenny/ You'll know it is working when you get stuff like this in the logs: lordshiva:~# grep sshguard /var/log/auth.log Jun 20 10:49:37 lordshiva sshguard[2660]: Blocking 211.254.130.116:4 for 420secs: 4 failures over 542 seconds. Jun 21 01:49:05 lordshiva sshguard[2660]: Blocking 217.118.97.58:4 for 420secs: 4 failures over 6 seconds. Jun 21 01:57:51 lordshiva sshguard[2660]: Blocking 24.39.144.137:4 for 420secs: 4 failures over 780 seconds. Jun 21 01:58:52 lordshiva sshguard[2660]: Blocking 217.118.97.58:4 for 1680secs: 4 failures over 6 seconds. Jun 21 02:05:17 lordshiva sshguard[2660]: Blocking 24.39.144.137:4 for 1680secs: 4 failures over 4 seconds. Jun 21 02:50:04 lordshiva sshguard[2660]: Blocking 217.118.97.58:4 for 0secs: 4 failures over 6 seconds. http://nozell.com/blog/2010/03/09/sshguard-on-debianlenny/-marc On Mon, Jun 21, 2010 at 9:28 AM, Benjamin Scott dragonh...@gmail.comwrote: http://isc.sans.edu/diary.html?storyid=9031 http://isc.sans.edu/diary.html?storyid=9034 Apparently attackers are going after keyboard interactive authentication, which is separate from password authentication. If you are using SSH public/private keys only, make sure you have ChallengeResponseAuthentication no set in your /etc/ssh/sshd_config file. If you must use passwords, make sure everyone has a strong password, and consider using techniques like scan detection, IP-address access control, port knocking, non-standard port, etc. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ -- Marc Nozell (m...@nozell.com) http://www.nozell.com/blog ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On 21-Jun-2010, Marc Nozell (m...@nozell.com) noz...@gmail.com sent: FYI, I've been using sshguard for a few month to drop routes to sites that are probing my server. On my cable modem at least, I've been seeing an huge increase in distributed SSH bruteforcing, so sshguard isn't effective. There's clearly a pattern in the usernames being attempted, but the source IPs are all over the place. -- Chip Marshall c...@2bithacker.net http://weblog.2bithacker.net/ KB1QYWPGP key ID 43C4819E v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM pgpT9HK1uOLeR.pgp Description: PGP signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, Jun 21, 2010 at 9:28 AM, Benjamin Scott dragonh...@gmail.com wrote: Apparently attackers are going after keyboard interactive authentication, which is separate from password authentication. So, even if I have set PasswordAuthentication no in my sshd_config, there's still a way to ssh into the server without a key pair? That's confusing. Time to break out the dog-eared snail book and get a refresh... Oh, a reminder: a fellow GNHLUGer told a tale not too long ago about testing ssh changes: always keep an exiting connection open when you're making changes. This way, when you lock yourself out of making new connections with the changes, you can use your old connection to reverse the changes. A good lesson learned. By someone else! -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On 06/21/2010 09:54 AM, Marc Nozell (m...@nozell.com) wrote: FYI, I've been using sshguard for a few month to drop routes to sites that are probing my server. None of the docs seemed to be quite right, so I wrote up some notes on getting it working debian/Lenny here: http://nozell.com/blog/2010/03/09/sshguard-on-debianlenny/ sshguard is in lenny-backports, but the rest of the documentation is quite helpful as the debian package doesn't do any of the setup. Thanks! -Mark ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
Ted Roche writes: Oh, a reminder: a fellow GNHLUGer told a tale not too long ago about testing ssh changes: always keep an exiting connection open when you're making changes. This way, when you lock yourself out of making new connections with the changes, you can use your old connection to reverse the changes. A good lesson learned. By someone else! I usually test out sshd/firewall changes by employing the following two schemes: 1: as a quick test, I run sshd -e -d -p 1234, where 1234 is the number of some temporary, unused port. Then I ssh -p 1234 from some other machine to test the config changes. 2: when I test out firewall (iptables) rules, I generally check once, check again, and then I test by typing this: /etc/init.d/iptables restart ; sleep 600 ; /etc/init.d/iptables stop During the five minutes that my new rules are in effect, I test. However, in the event that something goes haywire, I know that in five minutes I will have access again. Seriously, by combining these two practices, I have kept myself out of some very tough situations Regards, --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, 21 Jun 2010 10:04:59 -0400 Ted Roche tedro...@gmail.com wrote: On Mon, Jun 21, 2010 at 9:28 AM, Benjamin Scott dragonh...@gmail.com wrote: Apparently attackers are going after keyboard interactive authentication, which is separate from password authentication. So, even if I have set PasswordAuthentication no in my sshd_config, there's still a way to ssh into the server without a key pair? That's confusing. Time to break out the dog-eared snail book and get a refresh... I had to do the same. Challenge/Response ?? S/Key From Barret Silverman, SSH...The Definitive Guide, 1st ed., p 175: S/Key is a one-time password system, created by Bellcore [...] 'One-time' means that each time you authenticate, you provide a different password ... The remote sshd service provides you with an integer and a string, which you enter into a magic calculator on your local machine, along with a secret passphrase [never transmitted], and the calculator produces your one-time password. My reading is that Yes, there's a way to ssh in without a key pair; but No, the bad guys don't get in that way (unless the one-time key framework was very poorly set up somehow); and What You Care About is that a machine which OFFERS the S/Key method will get lots of attention from the world of botnets. START WITH NEVER EXPOSING SSHD ON PORT 22. -Bill who just went and looked, and found one of his servers with S/Key still defaulted (on), but with not a peep in the logs because of not being on port 22. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On 21-Jun-2010, Bill Sconce sco...@in-spec-inc.com sent: START WITH NEVER EXPOSING SSHD ON PORT 22. http://en.wikipedia.org/wiki/Security_through_obscurity Personally, I think this is a flawed approach to securing a machine. It only serves to encorage full port scans of machines, which wastes even more bandwidth. Sure, my logs have a lot of failed login attempts, but failed login attempts mean my security is working. It's the successful ones you need to watch out for. You don't secure your house by hiding the door, you secure it by having good locks. -- Chip Marshall c...@2bithacker.net http://weblog.2bithacker.net/ KB1QYWPGP key ID 43C4819E v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM pgpmH90f0n1Cc.pgp Description: PGP signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, Jun 21, 2010 at 11:05 AM, Chip Marshall c...@2bithacker.net wrote: On 21-Jun-2010, Bill Sconce sco...@in-spec-inc.com sent: START WITH NEVER EXPOSING SSHD ON PORT 22. http://en.wikipedia.org/wiki/Security_through_obscurity Personally, I think this is a flawed approach to securing a machine. It I don't think anyone here is advocating a different port to improve security. It's to get out of the way of script kiddies. only serves to encorage full port scans of machines, which wastes even more bandwidth. That might happen, but I don't think full scans of random systems has happened yet. This is an attack on random machines. A targeted machine will probably get a full scan. Sure, my logs have a lot of failed login attempts, but failed login attempts mean my security is working. It's the successful ones you need to watch out for. I'll get alert in my logs if SSH is scanned no matter which ports it is on. If I need it tested, I'll scan it myself. I won't lose that alert amongst a haystack of automated attacks though. You don't secure your house by hiding the door, you secure it by having good locks. If someone looks at your house quickly to break in, they might see there are no doors out back and quickly move on to the next house that has a back door. Maybe your door is more hidden and you have good locks anyways. This was the mentality for having The Club highly visible in your car. Which would be good if the Club wasn't so useful as a prybar and easy to defeat otherwise. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, Jun 21, 2010 at 10:04 AM, Ted Roche tedro...@gmail.com wrote: Apparently attackers are going after keyboard interactive authentication, which is separate from password authentication. So, even if I have set PasswordAuthentication no in my sshd_config, there's still a way to ssh into the server without a key pair? That's confusing. The OpenSSH server has a built-in password prompt/input system, but it can also farm that job out to PAM or other suitable technologies. There are other ways to use a keyboard for authentication than standard Unix passwords, so this isn't just complexity. One-time-passwords and two-factor things like those RSA SecurID tokens both require user input, for example. It's a good idea to explicitly disable any authentication methods you're not using. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, Jun 21, 2010 at 11:05 AM, Chip Marshall c...@2bithacker.net wrote: On 21-Jun-2010, Bill Sconce sco...@in-spec-inc.com sent: START WITH NEVER EXPOSING SSHD ON PORT 22. http://en.wikipedia.org/wiki/Security_through_obscurity Personally, I think this is a flawed approach to securing a machine. I put sshd on a non-standard port, but I don't depend on that for security. I do it as a method of keeping a low profile. It cuts down on log noise, if nothing else. It's also a counter-measure against zero-day exploitation of SSH vulnerabilities. I don't see how that's a bad thing. Combined with a guarded port knocking scheme, it can be a fairly effective counter-measure against wide-area automated scans. The classic definition of security by obscurity is an element which, once known, compromises security, and which cannot be easily changed without changing the security design. For example, I believe all Xerox copiers made in the past several years use the same service password to access a diagnostic menu. There's no way to change it, and the field service techs all depend on it being the same. *That's* security by obscurity. If my *only* method of defense was a non-standard SSH port, and I was using weak passwords and never updated my software, then yes, *that* would be a problem. It's an aphorism in the security world that a car alarm doesn't prevent a car thief from stealing your car. It just makes it easier to steal the car parked next to yours. It only serves to encorage full port scans of machines, which wastes even more bandwidth. If attackers are going to move to doing full port scans, they're going to do that. They don't need or care about our encouragement. They've got more resources available than us. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On Mon, 21 Jun 2010 11:05:18 -0400 Chip Marshall c...@2bithacker.net wrote: On 21-Jun-2010, Bill Sconce sco...@in-spec-inc.com sent: START WITH NEVER EXPOSING SSHD ON PORT 22. You don't secure your house by hiding the door, you secure it by having good locks. I couldn't agree more. The idea is to cut down on the scratching and rattling noises as every script kiddie in Romania bashes on your door on the chance it might be unlatched. Noise is annoying; it's hard to see why anyone would recommend that you have to put up with it. (Nevertheless, if you like port 22, use port 22.) I hope I didn't give the impression that moving off port 22 is the only thing I recommend, or do. On the contrary, I spent solid weeks (documented in changelogs) several years ago researching all the SSH options, determining the sshd configurations I believe to be correct for my clients(*), and writing a Python program to parse the applicable manpage (options and defaults change!), QA the available (many) options, and produce a recommended sshd_config together with a checklist and a set of annotations for manual review. 'Been doing that for years now, for every sshd I set up. START with port 22... -Bill (*) I found it interesting that, when I saw this thread, that a) when I went to ensure that my Python program disallows keyboard interactive, I found that it does so, and has done so since the beginning b) I wasn't able to remember what keyboard interactive means, in spite of having known it a couple of years ago, or whether it's in my set of deprecated settings, and had to look it up again. (Hmm. Is SSH too complicated? Y'think?) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Spike in SSH attacks
On 6/21/2010 8:42 PM, Bill Sconce wrote: On Mon, 21 Jun 2010 11:05:18 -0400 Chip Marshallc...@2bithacker.net wrote On 21-Jun-2010, Bill Sconcesco...@in-spec-inc.com sent: START WITH NEVER EXPOSING SSHD ON PORT 22. You don't secure your house by hiding the door, you secure it by having good locks. I couldn't agree more. The idea is to cut down on the scratching and rattling noises as every script kiddie in Romania bashes on your door on the chance it might be unlatched. Noise is annoying; it's hard to see why anyone would recommend that you have to put up with it. (Nevertheless, if you like port 22, use port 22.) I hope I didn't give the impression that moving off port 22 is the only thing I recommend, or do. When I had 26,000 SSH door rattlings, on one server, in one day, I moved from port 22 on almost every device we administer. The logs were so full of door rattlings, real warnings could get lost. I have never had another SSH probe since. They really must be script kiddies - no port scans to identify alternate SSH ports. As I can limit most SSH connections to a limited pool of originating IPs, I do that too. If possible, we only use SSH keys, no password logins. No root logins. Protocol 2 only, etc. Of course, no remote access unless it is needed. Like any security, the more layers the better. -- Dan Jenkins, Rastech Inc., Bedford, NH, USA, 1-603-206-9951 *** Technical Support Excellence for four decades. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
