A little while ago I asked for some SSH logs and as per usual people responded with gusto. So first of all thanks to all of those that provided logs, it was very much appreciated. Looking through the data it does look like everything is pretty much the same as usual. Get a userid, guess with password1, password2, password3, etc. A number of the logs were provided by the kippo SSH honeypot, which looks like it is well worth running if you want to collect your own info. Thanks again and if I manage to dig out anything further I'll keep you up to date. Mark |
Mark 392 Posts ISC Handler Aug 2nd 2011 |
Thread locked Subscribe |
Aug 2nd 2011 1 decade ago |
For the heck of it I ran those IPs through a script that looks up IPv4 addresses in the World IP DB (www.wipmania.com). The top two results aren't too surprising; they reconfirm my decision to blackhole China at home. The Emirates at #3 seems unusual. Here are the top 10 countries by number of IPs in the SSH_attacking_IPs.txt file:
CN=910; US=556; AE=370; DE=353; TR=300; RU=221; RO=194; KR=188; IT=134; BR=131; |
Hal 50 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
If one uses keys only, are people still seeing attempts at brute forcing, or is the cracking software smart enough to detect that a password is not asked for and moves on?
|
Stephen 1 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
@Stephen: In most of the attacks I have seen, the bots keep trying even if password authentication is disabled.
At a minimum, my Internet-facing SSH services run on non-standard ports, have password authentication disabled and are guarded by fail2ban. I see very few attacks and collect almost no interesting data as a result. |
Stephen 11 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
I use firewalls, but it looks like one could block login attempts for 'service' accounts by using groups and this line in the sshd config:
AllowGroups sshers |
Stephen 28 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
I've been using a script called ssh_brute_blocker running under FreeBSD for about 6 years that bans the IPs. The one i run is a bit modified from what Michael L. Benjamin wrote back in the day. I believe the last release was in 2004 but it still the best i've used. Tried a few, even fail2ban, but allways end up with that old thingi.
|
TorolfB 1 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
2 methods that I use to combat this in different situations are: 1) If ssh has to be available directly from the internet, rate limit tcp syn packets to the ssh port on per source address basis using iptables/netfilter
2) otherwise require ssh connections from outside of the network to be tunneled through vpn or ipsec |
James 12 Posts |
Quote |
Aug 2nd 2011 1 decade ago |
You could also setup snort and snortsam to drop append your iptables fw with a drop rule for said ip.
|
James 1 Posts |
Quote |
Aug 3rd 2011 1 decade ago |
Another tool to limit the effectiveness of brute forcing is BlockHosts. I've been feeding iptables with this tool for years, and it dropped login failures from 70-100k/day to <100/day. (Running SSH on a nonstandard port would generate more support calls than I care to field.). I've been impressed with the BlockHosts implementation, and definitely recommend taking a look.
|
PhilHagen 5 Posts |
Quote |
Aug 3rd 2011 1 decade ago |
With analysing the logs on my host I found that the scanning IP tend to pop up run a brute force attack then disappear for months then run the attack again. I also thought I would have constant stream of attacks but they come up in waves then all goes quite. The maximum I have seen in a week on a host on a DSL line was around 15 different IP’s. I was surprised that is was not more and weeks went by and I did not get one attack. I felt rather left out.
|
Peter P 8 Posts |
Quote |
Aug 3rd 2011 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!