sshguard-users

[SSHGuard-users] Injecting blacklist content into a runing SSHGuard

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

Apologies if I have missed details about this functionality in the docs.
I think the "log polling" code may already be where one would want to
start from but my reading suiggests that you would have to start SSHGuard
in that mode,  and there are caveats about doing both polling file and
consuming "system logs".

The scenario:

I start up SSH Guard on server A.

At some time later, a colleague brings me a blacklist from another
server, say server B.

Clearly, I can take  server A's live blacklist, combine* it with
server B's, stop server A's SSHGuard, put the combined file in
place and restart SSHGuard.

* combine, as in: weed out duplicates; go for the earliest seen
    for any IP addresses in both files, etc, whatever

What I am thinking about is, rather than combining the two files,
I weed out the duplicates from server B and, say, send a SIGnal
to SSHGuard that causes it to read new IPs from a known location,
poke them into the firewall, and add them to the live blacklist file.

I thought about an SSHGuard "utility" that takes a blacklist file
and creates a set of IPTables (if that's your poison) commands
that one then could poke into the firewall, however that sees
your on-disk blacklist file no-longer consistent with the rules
on the SSHGuard IPT Chain.

Any thoughts or anything similar out there?
Kevin

Re: [SSHGuard-users] Injecting blacklist content into a runing SSHGuard

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

On 9/3/20 12:37 AM, Kevin Buckley wrote:
> What I am thinking about is, rather than combining the two files,
> I weed out the duplicates from server B and, say, send a SIGnal
> to SSHGuard that causes it to read new IPs from a known location,
> poke them into the firewall, and add them to the live blacklist file.

It sounds like we're trying to accomplish two things here:

1. Teach SSHGuard how to re-load a blacklist file while running. It
doesn't currently know how to do this. This will probably involve a
not-too-difficult change to sshg-blocker.

2. For someone who runs multiple servers, it sounds like addresses that
are blacklisted in one place should be blacklisted elsewhere.

Perhaps you could have a central syslogd that all your severs log to
where you run a "master" sshg-blocker instance. It could then issue
sshg-fw-style commands to the individual servers via some authenticated
IPC mechanism, be it secure socket, message queue/broker, etc.

It seems that the SSHGuard pieces are there. It would take some glue to
put together a system like this.

Re: [SSHGuard-users] Injecting blacklist content into a runing SSHGuard

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

On 2020/09/11 02:11, Kevin Zheng wrote:
> On 9/3/20 12:37 AM, Kevin Buckley wrote:
>> What I am thinking about is, rather than combining the two files,
>> I weed out the duplicates from server B and, say, send a SIGnal
>> to SSHGuard that causes it to read new IPs from a known location,
>> poke them into the firewall, and add them to the live blacklist file.
> 
> It sounds like we're trying to accomplish two things here:
> 
> 1. Teach SSHGuard how to re-load a blacklist file while running. It
> doesn't currently know how to do this. This will probably involve a
> not-too-difficult change to sshg-blocker.

Not so sure that is what is required, though I'll happily bow to
your inside knowledge of the application here: for me though:

simply re-reading THE blacklist file opens up all kinds of issues,
not least that SSHGuard could be (should be?) trying to update the
on-disk file with new blocked addresses, just as an external user
tries to add content to it as well, ahead of instigating a re-load.

That's why I feel a separate "injection thread", that allows the
SSHGuard process sole access to its on-disk blaclist file, whilst
then able to accept source info from a second channel, to be a good
thing.

Then again, maybe the external user could add blocks directly into
the "your firewall here" and SSHGuard could be "taught" how to
occasionally sync itself against that?

Just floating ideas though.


> 2. For someone who runs multiple servers, it sounds like addresses that
> are blacklisted in one place should be blacklisted elsewhere.

This one, well, yeah, we had ideas there too.

We actually started talking about propagating the machine-local
blacklist info from SSHGuard out towards "the edge", but the
talking dried up.

Kevin