Someone's trying to break into server

Question

Hello,
According to my directory service log, someone is trying to break into our server by trying to log in as 'root' and 'admin'. DirectoryServices senses this and delays the failed authentication return.
Okay, how do we backtrace this fellow's IP and where do I get a detailed log of this apparent hacker's attempts?
Thanks!

Answer 1

In my strongly felt opinion, using denyhosts is mostly a bandaid to a problem, rather than properly addressing it.
The one and only time I have used it was when I was battling a situation not entirely under my control. No need to go into those specifics, but it was indeed a bandaid to a situation in which I could not properly secure the server. That has since changed.
I can't state this with enough emphasis: the proper maintenance of server security should totally negate the need for DenyHosts.
1) Shut off ssh access ("remote login") completely if that is an option
1) Shut off root access via ssh entirely
Said quickly: edit /etc/sshd_config and change the section to appear as follows:
# Authentication:
PermitRootLogin no
AllowUsers myserveradmin
where "myserveradmin" is the shortname of a desired user, and should categorically not be "admin" "administrator" "test" or anything else painfully obvious.
Restart ssh.
Furthermore !
3) Shut off password access via ssh completely. Use access by ssh keys only.
See the tutorial by Mike Bombich (of Apple) here:
http://www.bombich.com/mactips/rsync.html
starting with "Before you start: Security Briefing"
Or this article at another excellent resource:
http://www.afp548.com/article.php?story=20040816224717742
note the further information about how to limit commands available via ssh.
Having done this, edit /etc/sshd_config and add:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no
and restart ssh.
4) Set the shell ("login shell") for every and any account that does not need shell access to your server, to: None
5) Limit ssh access at your firewall, to known-viable IP ranges or even specific static IPs.
Better yet, (while still observing the other steps above) don't allow ssh traffic across your firewall, and setup VPN, and then use ssh access via VPN only.
Do all of this at your own "risk" meaning understand the consequences, the first of which will be a server that is more secure in terms of ssh access. This does little to prevent problematic php (phpBB) or other mismanaged or poor 3rd-party packages and their impact on your server.