sshguard-users

[SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

[hvjunk <hv...@gm...>]

Good day,

 Other than an update of the whitelist file, and restarting sshguard (with all the current blocks being removed), is there another mechanism to dynamically update whitelist IPs?

The “challenge” is that I have dynamically assigned IPs, like mobile devices, that have (for various reasons) trigged the sshguard blocking. I could do the updates of the whitelist file in some way out of band, but the problem is the current blocks are then removed and “forgotten”, which I would prefer not to happen, and I don’t want to open up/whitelist /16 sized netblocks to not restart the sshguard process.

Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request?


HEndrik

Re: [SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

[hvjunk <hv...@gm...>]

> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote:
> 
> Good day,
> 
> Other than an update of the whitelist file, and restarting sshguard (with all the current blocks being removed), is there another mechanism to dynamically update whitelist IPs?
> 
> The “challenge” is that I have dynamically assigned IPs, like mobile devices, that have (for various reasons) trigged the sshguard blocking. I could do the updates of the whitelist file in some way out of band, but the problem is the current blocks are then removed and “forgotten”, which I would prefer not to happen, and I don’t want to open up/whitelist /16 sized netblocks to not restart the sshguard process.
> 
> Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request?

After I sent this, I saw the source code also makes use of ipset(s), and I wondered perhaps to change the sshguard rules, to also have a whitelist, together with the blacklist that would be bypassing the sshguard block chain?

Re: [SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

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

On 7/23/18 5:44 AM, hvjunk wrote:
> 
>> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote:
>> 
>> Good day,
>> 
>> Other than an update of the whitelist file, and restarting sshguard
>> (with all the current blocks being removed), is there another
>> mechanism to dynamically update whitelist IPs?
>> 
>> The “challenge” is that I have dynamically assigned IPs, like
>> mobile devices, that have (for various reasons) trigged the
>> sshguard blocking. I could do the updates of the whitelist file in
>> some way out of band, but the problem is the current blocks are
>> then removed and “forgotten”, which I would prefer not to happen,
>> and I don’t want to open up/whitelist /16 sized netblocks to not
>> restart the sshguard process.

Currently, no. But there are plans to persist blocks across restarts via
a new save file, and the same mechanism might allow runtime changes to
the whitelist.

>> Perhaps would the developers accept a “sshguard-control” type
>> API/interface/program pull request?

That seems a bit complicated. Maybe changes to the file and having
SSHGuard reload it would be better?

> After I sent this, I saw the source code also makes use of ipset(s),
> and I wondered perhaps to change the sshguard rules, to also have a
> whitelist, together with the blacklist that would be bypassing the
> sshguard block chain?

Yes, you can work around the issue by whitelisting your addresses in the
firewall. SSHGuard will attempt to block these addresses but if your
rules have higher priority, they won't be blocked.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

[hvjunk <hv...@gm...>]

> On 23 Jul 2018, at 18:29 , Kevin Zheng <kev...@gm...> wrote:
> 
> On 7/23/18 5:44 AM, hvjunk wrote:
>> 
>>> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote:
>>> 
>>> Good day,
>>> 
>>> Other than an update of the whitelist file, and restarting sshguard
>>> (with all the current blocks being removed), is there another
>>> mechanism to dynamically update whitelist IPs?
>>> 
>>> The “challenge” is that I have dynamically assigned IPs, like
>>> mobile devices, that have (for various reasons) trigged the
>>> sshguard blocking. I could do the updates of the whitelist file in
>>> some way out of band, but the problem is the current blocks are
>>> then removed and “forgotten”, which I would prefer not to happen,
>>> and I don’t want to open up/whitelist /16 sized netblocks to not
>>> restart the sshguard process.
> 
> Currently, no. But there are plans to persist blocks across restarts via
> a new save file, and the same mechanism might allow runtime changes to
> the whitelist.

I would be the first to raise my hand for beta testing please ;)

> 
>>> Perhaps would the developers accept a “sshguard-control” type
>>> API/interface/program pull request?
> 
> That seems a bit complicated. Maybe changes to the file and having
> SSHGuard reload it would be better?

Hmm.. that is/was my first thought too about the whitelist file, but then I got reminded about
my problem, and that is that I’ll have to have a history file somewhere to note the previous IPs for an interface/client to remove,
which means that the file would need to be able to have comments at the end etc. to make it easy/simple to track the client’s old IP to remove etc.

That is why an dynamic control/insert mechanism was what I though would be simpler to control from other scripts etc. where you don’t need to sed/ex/awk the whitelist file

> 
>> After I sent this, I saw the source code also makes use of ipset(s),
>> and I wondered perhaps to change the sshguard rules, to also have a
>> whitelist, together with the blacklist that would be bypassing the
>> sshguard block chain?
> 
> Yes, you can work around the issue by whitelisting your addresses in the
> firewall. SSHGuard will attempt to block these addresses but if your
> rules have higher priority, they won't be blocked.

/me thinking wondering about using the ipset elsewhere in code… there is a “nomatch” option to ipset where we could insert it into the ipset with nomatch as an option. let me test/check that method

[SSHGuard-users] New 'sqlite' branch with persistent blocks

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

Hi there,

SSHGuard keeps an internal list in memory of recent attackers that is
lost when sshg-blocker restarts. One workaround is to enable
blacklisting and write frequent attackers to a permanent block file.

The new 'sqlite' branch on Bitbucket attempts to address this issue by
moving the in-memory list into an on-disk SQLite database. This new
branch depends on SQLite 3.

In this *experimental* branch, the '-b' flag has changed:

When '-b' is not specified, SSHGuard uses an in-memory database. If
there are no bugs, behavior should be no different than it is now.

When '-b' is specified with the argument THRESH:PATH (e.g.
120:/var/run/sshguard.db, just like now), the database is instead
written to PATH and will preserve attacks across restarts. The THRESH
specifies a blacklisting threshold, where an attacker who exceeds the
threshold will be blocked for 30 days.

WARNINGS:

The new database format is not compatible with the old blacklist format.
For now, point this to a new or non-existent file. When this is no
longer experimental, a converter script may be added.

Attacks are NOT deleted from the database AT ALL. This means the more
attacks SSHGuard sees, the bigger the database will grow. Some queries
have not been optimized and will slow down linearly with the size of the
database. Pruning old attacks will be written soon.

To use it:

https://bitbucket.org/sshguard/sshguard/branch/sqlite

Checkout by cloning the repository, then:
$ git checkout sqlite

Comments, and some initial feedback from those who are brave enough to
test this, are welcome!

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

[jungle B. <jun...@gm...>]

Hi Kevin,

Nice work! It is annoying having the blacklist lost after reboots, so maybe
this is a nice, valid solution.

Do you plan on leaving it up to the administrator to prune the blacklist or
will you include, by way of example in docs, a simple query on dropping old
records?

Thanks!

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

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

On 8/7/18 10:38 PM, jungle Boogie wrote:
> Nice work! It is annoying having the blacklist lost after reboots, so
> maybe this is a nice, valid solution.
> 
> Do you plan on leaving it up to the administrator to prune the blacklist
> or will you include, by way of example in docs, a simple query on
> dropping old records?

It will be automatic, pruning on startup and every hour or so. I just
haven't sat down and written the query.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

[Frank S. <fst...@bi...>]

Kevin Zheng wrote:

>> Do you plan on leaving it up to the administrator to prune the blacklist
>> or will you include, by way of example in docs, a simple query on
>> dropping old records?
> 
> It will be automatic, pruning on startup and every hour or so. I just
> haven't sat down and written the query.

Remembering the temporary blocks on restart, is a great idea!

There should be a little script allowing admins to list the db and
prune specific entries by giving an ip etc. In case one of our students
or researchers forgot again that his username is different on his laptop
and tried to login several times with the wrong user and got blocked :-)
This happens from time to time, and for the moment it's easy to remove
such entries from the txt file.

cu,
Frank



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

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

On 8/9/18 12:12 AM, Frank Steiner wrote:
> Remembering the temporary blocks on restart, is a great idea!
> 
> There should be a little script allowing admins to list the db and
> prune specific entries by giving an ip etc. In case one of our students
> or researchers forgot again that his username is different on his laptop
> and tried to login several times with the wrong user and got blocked :-)
> This happens from time to time, and for the moment it's easy to remove
> such entries from the txt file.

Noted, thanks for the suggestion.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090