Thanks for all the great input guys.
Theres a lot of reading to do before I can decide ona the most suitable option for me, but I'll get through it all.

While i'm getting my head around everything to impliment a permanent solution, what about this? (sorry, not great with iptables just yet..) Leave sshd listening on port 22, but firewall off everything except my trusted IP's (localhost, home, girlfriend, work subnet, internal subnet, flatmates server) . Add an IPTables rule to port forward $ambiguous_external_port through to port 22 on localhost (or if its safer, the 10.x.x.x IP assigned to the machine) , and log the instance. My thinking is that this would make it harder for someone to find my open ssh port, but leave me the convenience of not having to specify a port when I connect from my regular connections, dozens of times a day. Or is it just going to open up an IP spoofing exploit on port 22, and achieve practically nothing?

Presumably this would eliminate the need for my original idea of search-and-destroy on the brute force scripts, but I'll probably look at implimenting something along those lines when I get my ftpd going (i'm using SCP for everything now, but theres a need to change that. ) and will still look at using the idea for my permanent SSH solution.

I like the sound of of SEC, the IPTables' "recent" option, and port knocking. Because NZ IPs are assigned from the APNIC ranges, I'm not sure how well the GEOIP patch would work, but i'll look into it. (otherwise I would have blacklisted all of Asia already) I'm going to read through all the rules and scripts posted, once i've researched the available tools, and i'll go from there.


Cheers
Jeremy B

Jeremy Brake wrote:

Hey all,

I'm looking for an app/script which can monitor for failed ssh logins, and block using IPTables for $time after $number of failed logins (an exclusion list would be handy as well) so that I can put a quick stop to these niggly brute-force ssh "attacks" I seem to be getting more and more often.

Anyone have any ideas?

Thanks, Jeremy B


--
[email protected] mailing list

Reply via email to