Greetings everyone. Just a bit of a reminder that many colleges and universities are done for the spring semester, and the K12s are right around the corner. As most of you already realize, this means that a number of very intelligent kids and young adults are soon to have far more free time on their hands (and less adult supervision during the normal working hours for their parents). So I expect that there will be a bit of an increase of attacks and other general noise from outside of corporate or campus network as we have observed in prior years. In that frame of mind, there has been a significant amount of brute force scanning reported by some of our readers and on other mailing lists. And there does appear to be a bit of a spike reflected in the port 22/tcp sources in the past week in the Dshield data. Jim Owens and Jeanna Matthews of Clarkson University released a paper at the Usenix LEET ‘08 conference which investigates current methods and dictionaries used by attackers of SSH in the past several months. The paper shows some evaluations of common techniques used to defend against brute force attacks that are worth reading to some. From the most recent reports I have seen, the attackers have been using either ‘low and slow’ style attacks to avoid locking out accounts and/or being detected by IDS/IPS systems. Some attackers seem to be using botnets to do a distributed style attack which also is not likely to exceed thresholds common on the network. So be warned that there does appear to be a bit more activity involving SSH and weak or otherwise guessable passwords. This would be a great time to do some investigation on your local network to see what servers have SSH open to the world on the default port, and may need to have its security posture reassessed. You might want to try using a few of the techniques discussed in the paper by Owens and Matthews such as
You might note that there is one defense technique that was not even mentioned in the paper, or was not recommended by me. That technique is to lock accounts after X number of failed login attempts. As I work in a similar environment as the authors, I can tell you that this technique has numerous issues when working with academia. First and foremost, the potential for creating a denial of service issue must be weighed against the potential of attackers guessing the right password before IT Security notices. The likelyhood of having a student take out their frustration for a non-IT related issue on a professor or an ex-boyfriend or girlfriend is actually very significant. Additionally, having a single sign-on infrastructure used from Web Applications, Unix based apps and interface, and windows based services mean you have to do significant synchronization of information to make this technique effective against distributed and/or slow attacks. Your mileage for using this technique may vary and could be more valid in your environment. Thanks to all of the readers who have already sent in their observations to us today. :-) Update 1: Another one of our readers sometimes gives advice/consults for an organization which today was having problems with a server denying access to anyone attempting to connect. The reason was that Sshd was denying all connections due to too many failed login attempts. It was recommended that internal servers could use the default port, but external facing hosts which have a need for ssh should use a non-standard high port. Yes, itt is a form of security by obscurity, but it does defeat brain-dead brute force attacks. |
ScottF 191 Posts ISC Handler May 12th 2008 |
Thread locked Subscribe |
May 12th 2008 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!