Joshua Bassett wrote:
I was going through my auth.log file the other day and noticed that
someone (possibly several machines) are trying to login to my box
using a variety of "canned" usernames. Looks like they're trying to
bruteforce their way in...they try maybe 20 usernames per day.
Has anyone else experienced this?
I see this doorknocking all the time. It's simply an extension of
what used to happen with telnet.
Most distros don't set up ssh to deal with this particularly well.
No matter what your policy you can do this
Create a group 'ssh'. Add the userids that are allowed to ssh.
Edit /etc/ssh/sshd_config adding
AllowGroups ssh
PermitRootLogin no
Banner /etc/issue.net
Put a substantial message into issue.net so that it costs the scanner
more receive bandwidth to do the test than transmit bandwidth.
You can always use sudo to get root once logged in. To do this add
the users that can become root to the group 'wheel' and edit /etc/sudoers
to say
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
Some machines can have a policy about who can login from where, then
you can add lines like this to /etc/hosts.allow
sshd: 10.0.0.0/255.0.0.0
assuming /etc/hosts.deny says
ALL: ALL
If you already have a hosts.deny blocking everything then you may need to
say
sshd: ALL
to get ssh to the machine at all.
You might want to get rid of passwords all together. You can force
public key authentication by altering /etc/ssh/sshd_config to
PubkeyAuthentication yes
PasswordAuthentication no
KerberosAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication no
The problem with public keys is that you can't centrally check the
password strength of the password protecting the private key. So
it's good for machines on the network boundary (say transitioning
across a firewall) but sucky within an enterprise (as you're bot
going to catch that 10% of poor passowrds).
Cheers,
Glen
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
