Lexa Software: Security-Alerts@yandex-team.ru archive

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 op=
en to the world on the default port, and may need to have its security post=
ure reassessed.  You might want to try using a few of the techniques discus=
sed in the paper by Owens and Matthews such as

    * Using the host based security tools of DenyHosts, fail2ban, or BlockH=
osts in conjunction with TCP-Wrappers to block access to servers across you=
r organization.
    * Disable direct access to the root account.
    * Avoid using easily guessed user names such as only a first name or a =
last name.  (Side Note: Academia will need to look into the age old policy =
of publishing an online directory of account holders before this one will h=
ave much of an effect.)
    * Enforce strong passwords or use public key authentication in place of=
 passwords (multi-factor or public key is the preferred method especially f=
or systems which contain sensitive data) .
    * Generally reduce the number of publicly accessible services through i=
ptables or similar host based security measures in addition to network fire=
walls.  (think defense in depth.)

You might note that there is one defense technique that was not even mentio=
ned 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 e=
nvironment as the authors, I can tell you that this technique has numerous =
issues when working with academia.  First and foremost, the potential for c=
reating a denial of service issue must be weighed against the potential of =
attackers guessing the right password before IT Security notices.  The like=
lyhood 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 sign=
ificant.  Additionally, having a single sign-on infrastructure used from We=
b Applications, Unix based apps and interface, and windows based services m=
ean you have to do significant synchronization of information to make this =
technique effective against distributed and/or slow attacks.    Your mileag=
e for using this  technique may vary and could be more valid in your enviro=
nment.

Thanks to all of the readers who have already sent in their observations to=
 us today.  :-)

Update 1:
One of our handlers, Jim, pointed me to the DenyHost stat site located at h=
ttp://stats.denyhosts.net/stats.html.  As already mentioned, this does appe=
ar to be a significant new trend of which we all should be aware.

Another one of our readers sometimes gives advice/consults for an organizat=
ion 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 s=
ervers could use the default port, but external facing hosts which have a n=
eed for ssh should use a non-standard high port.  Yes, itt is a form of sec=
urity by obscurity, but it does defeat brain-dead brute force attacks.