SSHGuard
sshguard.net
SSHGuard
1–10 of 149 posts
Re: SSHGuard
#2Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page
Tools like these are essential if you have Internet-facing SSH services.
If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon.
Best practices for Internet-facing SSH:
- run on non-standard port (not port 22)
- disable passwords, use SSH passkeys instead: https://www.techrepublic.com/article/how-to-setup-ssh-key-au...
- disable root SSH login
- run fail2ban, sshguard, or similar "block IP addresses for suspicious activity" services
- setup port knocking: https://www.tecmint.com/port-knocking-to-secure-ssh/
edit:
- run WireGuard VPN (https://en.wikipedia.org/wiki/WireGuard) for defense-in-depth
Re: SSHGuard
#3In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled.
These tools are popular, but I think they're kind of silly.
Later
I read some comments below, which compared this to Fail2ban (I had written this tool off as yet another Fail2ban-style script). But it's even scarier: it's written in C. I guess this is from like 2010? Don't run stuff like this.
Re: SSHGuard
#4Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…
[deleted]
Re: SSHGuard
#5Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…
[deleted]
Re: SSHGuard
#6Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…
The issue with fail2ban is that it's an extremely heavy python application. It takes up a boatload of resources!
SSHGuard however is much lighter and even less to configure manually.
Re: SSHGuard
#7Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…
Or just run wireguard and ssh on top of that without all the fussy config and tooling to expose ssh to the internet. You could even live dangerously and just use telnet once you have wireguard going.
Re: SSHGuard
#8In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…
Doesn't it make sense to do both given that the cost of additional mitigation is trivial?
Re: SSHGuard
#9Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…
The issue with fail2ban is that it's an extremely heavy python application. It takes up a boatload of resources! SSHGuard however is much lighter and even less to configure manually.
I am not trying to compare fail2ban and SSHGuard.
I used fail2ban in the past and it was helpful.
If I was currently running an Internet-facing SSH daemon, I would give SSHGuard a try.
Re: SSHGuard
#10In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…
Doesn't it make sense to do both given that the cost of additional mitigation is trivial?
No.