I want to decrease the likelihood of a successful ssh attack on a linux system. The only port that is open is 22 (I use port forwarding for everything else), and of course I made sure that ssh accepts only key-pair-based logins (no passwords).
The volume of failed ssh login attempts (output of
last -f /var/log/btmp) was fairly large (as anybody opening up port 22 should expect), so for the last 2+ years I've been relying on a variation af the iptables-based solutions often mentioned to block ssh attacks, for example Hundreds of failed ssh logins.
One annoying drawback of such a scheme is that it limits the number of new connections from an ip address per amount of time, no matter whether previous connections from that ip were successful or not and whether they were trying to log in as the same user or not. Imagine a script containing half a dozen of
rsync commands used from abroad to update various areas on that server: it typically hits the "new connection limit" and fails somewhere in the middle. The same goes if several users behind a router (showing up as the same IP address) do connect on my server more or less at the same time.
So, I am wondering if, without resorting to parsing the
/var/log files, it is possible to implement the following strategy with
- accept established connections
- allow new connections from previously successful connections
- put IPs with failed connections in jail for some time
- Same as above, but allowing/jailing specific
user@ipinstead of everybody
And to attempt to curb botnet attacks:
- Temporarily put in jail a user (no matter which IP (s)he connects from) after a failed ssh attempt.