Re: [SSHGuard-users] performance when using firewalld: adding/removing many entries at once

[Kevin B. <kev...@gm...>]

On 2022/01/19 19:34, Christopher Engelhard wrote:
> 
> On 19.01.22 10:10, Kevin Buckley wrote:
>> That suggests that one could take the blacklist lines
>> and simply pre-populate the
>> 
>> sshguard4.xml
>> 
>> IPSet file, before starting SSHGuard, however I am not sure
>> what SSHGuard would do with existing entries if, on starting,
>> it finds that the sshguard4 IPSet exists, and already has
>> entries.
> 
> This would be another option, but seems rather brittle to me. a) it
> messes with firewalld-internal config files that might or might not stay
> in that location/format and b) actually getting firewalld to read those
> files means triggering a global reload which might or might not
> influence other things the user has been doing in the meantime.

Yes.

It didn't "feel quite right" to me either, but it does separate
all ongoing blocks, initiated by SSHGuard, from already known to
FirewallD drops.

Christpher also writes

> IMO there is no reason not to use the --permanent flag when setting the 
> entries, but that should be checked to be sure. Main difference is that 
> the banned IPs will survive a restart, while sshguards banlist doesn't?, 
> which might lead to IPs not being unbanned. But that is easily remedied 
> by letting SSHGuard wipe the sets on startup. It might already, I can check.


So here's my experience with that:

I start SSHGuard, against a FirewallD that has never seen SSHGUard,
with a blaklist containing 28793, and with the "--permanent" option
added to the SSHGuard's ads/remove block functions, as detailed
previously.

It took around SEVEN hours for SSHGuard to read the entries from the
blacklist and add them into FirewallD.

Jan 19 13:02:11 host systemd[1]: Started SSHGuard - blocks brute-force login at>
Jan 19 13:02:11 host sshguard[25082]: blacklist: blocking 28793 addresses
Jan 19 20:07:32 host sshguard[25082]: Now monitoring attacks.

As may have been already documented, each addition sees the exiting IPSet
file backed up on disk, before the new entry is added.

I then stop SSHGuard.

The sshguard4 IPSet, as known to FirewallD is still there.

I remove the SSHGuard blacklist.

I restart SSHGuard.

10:51:40 host systemd[1]: Started SSHGuard - blocks brute-force login attempts.
10:51:40 host sshguard[15354]: blacklist: blocking 0 addresses
10:51:40 host sshguard[15354]: Now monitoring attacks.

The sshguard4 IPSet, as known to FirewallD is still there.

So now we have a situation where FirewallD "knows about" all 28793 original
blacklisted entries, plus any new blocks before SSHGuard was stopped, but
SSHGuard has no record of anything in the sshguard4 IPSet.

Then again, if FirewallD is dropping connections from all 28793 original
blacklisted entries, plus any new blocks, does SSHGuard need to know that
it was the original source of a given block/drop ?

I think this comes down to whether SSHGuard, or more correctly its blacklist,
has to be the "sole arbiter" of what gets blocked, or whether it is seen as
something that merely adds to, or removes from, whatever system firewalling
mechanisms are in place.

The issue for me now becomes one of removing blocks known to SSHGuard
that are also known to FirewallD.

If this can only occur via a re-reading of a blacklist file from which
"to be unblocked" entries have been removed, then it's going to take
too long to be operationally viable.

If, on other hand, unblocking is handled via direct interaction with
FirewallD, and so without needing to re-read its blacklist file, it
becomes workable.

Not sure what that means for the SSHGuard blacklist though.

Maybe there's a case for two blacklists, one that only gets read at
startup and which gets compared with existing rules in the OS firewall
and an "operational" blacklist that collects any new blocks after the
SSHGuard starts.

Kevin