11–20 of 62 posts
Earlier quoted context omitted.
Have you tried fail2ban? It really helps to keep the hacking attempts down on your ssh-server(s), especially if you increase the bantime from the default 600 seconds to a couple of million...
It is all fun and games until you ban yourself for a couple of million seconds... Far too many people ban themselves with fail2ban.
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
Now I do wonder: does this 'exploit' still cause a log line immediately after each attempt? And also, do iptables firewall rules also apply to open connections, or just to new ones? In the latter case, Sshguard and fail2ban are circumvented for a rather high number of attempts.
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
Have you tried fail2ban? It really helps to keep the hacking attempts down on your ssh-server(s), especially if you increase the bantime from the default 600 seconds to a couple of million...
Edit: Thinking about it, I guess that blocking single IPv6 addresses, as sshguard does, doesn't really help at all, as it's easy to obtain huge subnets. (This might even open the door to an iptables DDoS?) Blocking whole subnets, on the other hand, doesn't sound clever either. (Who knows how many users are sharing the same subnet?)
So, should I just close port 22 on IPv6 altogether? Not a very sustainable solution. This needs more research!
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
Recent Google Cloud Engine images have Sshguard enabled by default. Now I do wonder: does this 'exploit' still cause a log line immediately after each attempt? And also, do iptables firewall rules also apply to open connections, or just to new ones? In the latter case, Sshguard and fail2ban are circumvented for a rather high number of attempts.
One of the common gotchas though is that if you add a rule to allow "Established" connections, and then try to add a new rule after that which says "block IP X", that will not sever existing connections.
To block existing connections you can remove that entry from the connection tracking table, or you can insert your "block IP X" rule above your "allow Established connections rule".
Earlier quoted context omitted.
Have you tried fail2ban? It really helps to keep the hacking attempts down on your ssh-server(s), especially if you increase the bantime from the default 600 seconds to a couple of million...
Never seen the need for fail2ban when you can do the same thing with a couple of iptables rules.
Earlier quoted context omitted.
It is all fun and games until you ban yourself for a couple of million seconds... Far too many people ban themselves with fail2ban.
I use key-based authentication and fail2ban. Since that won't fail like passwords, it works wonderfully and the chances of my being banned are nil.
* Until you have a script repeatedly attempt w/o your keys unlocked
* Until you try from a new computer on the same network and fail to setup your keys first.
Ask me how I know :)
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
But what does deter them is port knocking. We went from many attempts per hour to not a single one since adding port knocking to our firewall. Port knocking has been mentioned before on HN and it generally gets a luke warm to negative response. It completely baffles me, this response.
Mozilla's wiki has some information on strengthening the security of your OpenSSH setup.