Show HN: TOTP Based Port Knocking -- two factor firewall
dhj.io
dhj.io
Short version:
Client and server share a key.
Each can generate a TOTP based hash.
Client sends hash to server listening on UDP.
If hashes match the server opens the normally closed ssh port for a few seconds (long enough to make a connection).
Like a Google Authenticator TOTP code, the correct hash changes every T seconds so identification of the UDP port and interception of the key is only helpful for a limited (if any) amount of time.
Is this worth turning into a robust daemon? Is there a better way to deal with constant ssh probing? A module in a firewall would be ideal. Environment based config would make it fairly easy to use in provisioning for ssh admin with a smaller scan footprint.
Turn off password auth (aka only accept pubkey auth) and use something like fail2ban to ip-block hosts with repeated failed login
Thank you for your feedback!
I'm not sure I understand? fail2ban works like this:
it monitors configured log files for patterns/strings: in this case its looking for multiple failed logins within N minutes from the same IP.
If that condition is met, it adds an iptables rule to reject all connections from that IP.
If you're getting lots of random IPs, try tweaking the failures required or the timing window - you could reduce the number of failures and widen the window to better handle the situation where you might not get many hits from a given host.
If you're using key only access, you have much less to worry about: bots like that are just trying to defeat regular password auth. While its annoying unless its causing you network issues its not a concern once password auth is disabled.
That is the problem, it always seems to be random IPs. Thats why failtoban is a losing battle. Failtoban works per IP, but no matter how sensitive the ban rule there always seems to be an endless supply of new IPs.
I do use keys for ssh access so disabling passwords does cover most of the safety concern. I guess it is more of an annoyance than anything. It looks huge in the logs, but network usage wise it probably boils down to once every few minutes.