Hack Attempt
December 2, 2007
Dec 2 14:19:52 myHostname sshd[8843]: Did not receive identification string from someip
Dec 2 14:20:31 myHostname sshd[8846]: Invalid user fluffy from someip
Dec 2 14:20:33 myHostname sshd[8848]: Invalid user admin from someip
Dec 2 14:20:35 myHostname sshd[8850]: Invalid user test from someip
Dec 2 14:20:38 myHostname sshd[8853]: Invalid user guest from someip
Dec 2 14:20:41 myHostname sshd[8855]: Invalid user webmaster from someip
Dec 2 14:20:46 myHostname sshd[8859]: Invalid user oracle from someip
Dec 2 14:20:48 myHostname sshd[8861]: Invalid user library from someip
Dec 2 14:20:52 myHostname sshd[8863]: Invalid user info from someip
Dec 2 14:20:54 myHostname sshd[8865]: Invalid user shell from someip
Dec 2 14:20:57 myHostname sshd[8867]: Invalid user linux from someip
Dec 2 14:20:59 myHostname sshd[8869]: Invalid user unix from someip
Dec 2 14:21:02 myHostname sshd[8871]: Invalid user webadmin from someip
... more like this ...
So that’s what a brute force attack on an SSH server looks like! 
Fortunately, I took time to read and secure the SSH as best I know how and no damage appears to be done. (If the output of less can be trusted) There were only two real attacks.
All in all I learned from the whole thing. I should probably start getting into the habit of reading my logs, and I learned a couple of user names not to use. (my favorites being fluffy, gopher, and Zmeu) I think I also want to look for an ipchains rule to limit access to only IP addresses in my state.
Entry Filed under: Linux. Tags: hack attempts, Security, ssh.
6 Comments Add your own
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed
1.
scaryreasoner | December 2, 2007 at 10:05 pm
um….
“So that’s what a brute force attack on an SSH server looks like!”
The antecedent of “that” is missing in action.
What does a brute force attack on an SSH server look like?
Your post fails to mention it.
2.
dosnlinux | December 3, 2007 at 6:59 am
Fixed. Thanks
3.
Dr Small | December 7, 2007 at 8:41 pm
You weren’t the only one for December 2nd.
I got hit too..
4.
Ryan Grange | March 30, 2008 at 7:34 pm
I wrote an article covering some IPTables rules I found elsewhere on slowing down brute force attempts to hack your ssh server with an explanation of what those rules do. It won’t provide bullet-proof security, but it will give you a stronger defense against the brutes.
5.
Exhibitor | June 24, 2008 at 6:33 am
Somehow i missed the point. Probably lost in translation
Anyway … nice blog to visit.
cheers, Exhibitor!
6.
forkbomb | July 31, 2009 at 1:49 am
First of all, I like disallowing root logins – it’s a minor inconvenience for me but effectively thwarts a lot of skiddie “attacks” that only bruteforce the root account. I authenticate through a normal user account and then ’su’ to root.
I’ve been using denyhosts for quite some time on my SSH server. I use the sync mode these days – I don’t remember my settings of the top of my head, but I believe I block for two weeks any IP seen making 3 bogus logins within 15 minutes. If the length of my /etc/hosts.evil file is any guide, denyhosts is currently blocking over 3500 hosts known to have attempted ssh bruteforces through the denyhosts sync system.
As for blacklisting or whitelisting IPs with iptables, have fun trying to keep on top of ICANN’s IP registration shifts. Not even ICANN can keep track of who’s using what IP (okay, that’s partially sarcastic). That’s why active defenses such as denyhosts that throw up a defense based on a percieved attack can be easier to manage.