SSHGuard: is there a good replacement?

[ShelLuser]

Hi guys,

So last week I upgraded my test environment and got the latest SSHGuard. Well... Can't say that I was very happy about it, in fact I think it clearly shows you how little some software authors know about the way their software is being used, and I think it's somewhat upsetting.

As such the question is now: what good alternatives are there for SSHGuard? I also did a bit of research myself (obviously) but I'm curious to know what some other people actually use. The key feature for me is use of tcpwrappers (hosts.allow). For the simple reason that there is no way that I'll allow an automation to control my firewall.

My reasoning is simple: hosts.allow can only be used to block stuff. If a freak incident were to occur within SSHGuard and it could control my firewall then what guarantees do I have left that it won't start opening things up? Because that's the risk of letting it handle your firewall: it can close, but also open things up. Not so much with TCPWrappers: my firewall always supersedes that.

Anyway, thanks for any comments. I'm closing with a small rant. Need to get something off my chest, because I am seriously unhappy with these developments which in my opinion are plain out stupid.

(small rant)

Several features have been removed from SSHGuard, where for me the most notable is the support for TCPWrappers. At first I blamed the Ports maintainer, then after I investigated more I finally learned the truth: this all happened within the original project itself. Apparently they held a poll on their website and from there it was determined that some features had to go.

I think that shows an extremely narrow minded view on the part of the author(s). Because I can't help believe that there are plenty of people like me: who do not rely on the website but on a programs functionality. I use it because it supports the features I need. And I don't visit such websites because I use other methods to keep my software up to date (such as the Ports collection in my example, but the same applies to users who rely on a local software repository (think both pkg-install but also your average Linux user).

If I have to check up on every mailinglist on every software package I use, combined with all those which really matter (security updates) then I'd be looking at a new daytime job

During my investigation things became worse. Because the SSHGuards website still lists tcpd's host.allow as a blocking method. Yet if you read the release announcement for 1.7.0 you'll see what I'm talking about:

On 08/29/2016 10:47, Mark Felder wrote:
> Not sure. I was just looking for an easy hack for users of the hosts
> backend.

If that's something people are interested in it would just involve
translating the original hosts.c into a new sshg-fw backend.

It's only deprecated because not many people said they were using it on
the survey, and I wasn't going to rewrite if not many were using it.

I am soo much done with this project right now.

They deprecated a feature and apparently couldn't even be bothered to update the website. That goes to credibility for me. One of the key elements of security, in my humble opinion of course, is transparency. Well, there's little to be found here it seems so I've dubbed this as unreliable and I'm moving on. Even if they would re-add this feature then I'm still ignoring this from here on, because what'll be next?

When I start using software then I rely on 1 main thing: that it will continue to provide the functionality I have come to love and respect. Apparently that's too much to ask for some software projects, and it's their loss I'd say.

(/rant).

 

[Murph]

A couple of options for you. I'm not familiar with SSHGuard myself, so not sure how easy this first option is.

Use it to manage a firewall table, not the firewall rules. Adding and removing addresses to/from a table avoids the possibility of opening a big hole in the firewall if something goes wrong. The worst that happens is either too many addresses get blocked or no addresses get blocked for the particular rule that uses the table.

Alternatively, switch to security/py-fail2ban. I use that myself, to mitigate SSH brute force attacks. I have it configured to manage PF tables, and the way it is configured makes it essentially impossible that it could open a hole in PF, as the commands it executes are specific to table management. It also (optionally) reports to blocklist.de to publicly name and shame them, as well as auto-generate abuse reports to ISPs.

I consider blocking SSH attacks at the firewall level to be preferable, as it mostly avoids denial of service via resource exhaustion. Blocking through TCP wrappers means that each connection will still consume resources at the Unix process level. I'm not sure if this is as bad as a full fork+exec for OpenSSH, or if it blocks prior to that stage, but it's much worse in terms of resource usage than just dropping the TCP SYN on the floor or bouncing it with a RST or ICMP inside the network stack (I send them an ICMP admin filter prohibited message, but it's personal preference which style of network level blocking you use — I just like doing a positive "fsck off" message, some prefer to emulate a closed port, and others prefer to go dark through just dropping them).

In the not so distant future, we will also have blacklistd for this.

 

[SirDice]

You may want to have a look at the new blacklistd(8) (Available in FreeBSD 11.0). Not a lot of documentation yet so it's a bit of uncharted water.

 

[SirDice]

For the simple reason that there is no way that I'll allow an automation to control my firewall.

Actually, it doesn't control the firewall. All SSHGuard does is manage a table by adding/removing IP addresses. You control the firewall and what happens with that table.

If a freak incident were to occur within SSHGuard and it could control my firewall then what guarantees do I have left that it won't start opening things up?

It can't. All it does is manage a table (which only exists in memory). If SSHGuard would have used anchors (like miniupnpd does for example) then yes, this would indeed be possible but this is not the case. Maybe you've seen SSHGuard on Linux, if I'm not mistaken on there it does directly modify IPTables rules by adding/removing to a specific chain.

I'd even go as far as stating that modifying hosts.* files is more dangerous as it needs to modify a file directly. This could be leveraged to modify other files for example.

That said, if there are problems with SSHGuard it doesn't really matter what you use, the payload will have root access and can do pretty much everything it wants. But at least you can limit that somewhat by running security level 2 or 3 for example. Level 3 might be suitable for SSHGuard although I've never tried it. Level 3 would prevent modification of the rules but I'm not sure if you'd still be able to modify tables.

Alternatively, switch to security/py-fail2ban. I use that myself, to mitigate SSH brute force attacks. I have it configured to manage PF tables, and the way it is configured makes it essentially impossible that it could open a hole in PF, as the commands it executes are specific to table management.

SSHGuard does exactly the same, it only manages a table, nothing more, nothing less.

This is all that's needed for SSHGuard to work with PF:

table <sshguard> persist
block in from <sshguard>

 

[Remington]

+1 for py-fail2ban. I use it exclusively on my servers to block SSH, IMAP, POP, SMTP, and HTTP attacks. The scripts are already there and you can customize the scripts to scan for specific keywords in the log files. It does far better than SSHGuard.

 

[johnblue]

In the context of protecting against SSH attacks, continued and willing use of SSHGuard et al seems to indicate a fundamental lack of understanding of the risks and how to properly address them.

Anyone will be very hard pressed to present superior empirical data on SSH risks than what has been presented by Utah State University:

https://it.wiki.usu.edu/ssh_description

The takeaway is that changing the port along with SSH keys is your best *minimal* defense. IMO, if an admin is relying upon software that monitors log files to protect SSH, they are doing it wrong.

 

[gkontos]

Or not use a standard sshd port.

 

[Remington]

For best protection is to use VPN and then SSH into the server or restrict SSH to specific remote IP address.

You can add this to /etc/ssh/sshd_config

AllowUsers john@192.168.1.100  john@192.168.2.*

 

[Oko]

For best protection is to use VPN and then SSH into the server or restrict SSH to specific remote IP address.

Or for even better protection just unplug the computer from the network and for that matter from the power as well and just go for a walk.