sshguard-users — User questions and answers, bugs, and general support

[SSHGuard-users] Parsing DNS names in sshg-parser

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

Hi there,

I'd be curious to know: is anyone aware of an attack signature where 
only an attacker's DNS name (and not IP address) is available?

I'm asking because of this bug report, in which sshg-parser tries to 
parse a fully-qualified Java class name as a DNS name:

https://bitbucket.org/sshguard/sshguard/issues/142/wrong-parsing-of-java-stacktraces-in

This DNS lookup will also fail on systems where SSHGuard knows how to 
sandbox itself. I'm considering removing this lookup altogether if there 
are no known log messages where the IP address is not available.

(By the way, did you know that sshg-parser can operate with reduced 
privileges? Right now it only does so on FreeBSD, via Capsicum; and 
OpenBSD, via pledge(). If you are interested in lending a hand to help 
get sandboxing, or even privilege dropping, working on your system, let 
me know.)

Regards,
Kevin

Re: [SSHGuard-users] Blacklist behaviour with hell list

[kaycee gb <kis...@ho...>]

Sorry I try again for the list.

Hi,

Le Wed, 5 May 2021 14:08:20 -0700,
Kevin Zheng <kev...@gm...> a écrit :

> Hi there,
> 
> On 5/5/21 12:44 PM, kaycee gb wrote:    
> > The point is that after I remove the attacker's address from firewall rules,
> > new "attacks" are not detected and can go smoothly.
> > 
> > I think it has something to do with the code here:      
>  [...]      
> > 
> > sshguard thinks that address is already blocked but shouldn't that address
> > be released and remove from hell list when blacklisting ?      
> 
> SSHGuard assumes that nobody else is changing the firewall rules under 
> its control while it is running. Under this assumption, it should not be 
> possible for an attacker who is blacklisted to show up again.     

I agree. When an attacker is blacklisted, he can't reach the host and/or any
service, so attacker is not logged and SSHGuard will not do anything. That's
seems correct.

>If this 
> does happen, SSHGuard's current behavior is to warn about it without 
> re-blocking the attacker.    

>From what I see, when an attacker is blacklisted at runtime, and you remove the
rule from firewall after blacklist time, there is no warning at all. 

However, when you restart SSHGuard, blacklist list is populated, firewall rules
are loaded. Then if you remove attacker from firewall rules, SSHGuard does it
jobs in a normal way. I mean, track attacker's cumulative score and warn
about it and blacklist at threshold exceed. 
Then again, after this runtime blacklist, if you remove attacker from firewall,
we have the situation that SSHguard do not warn again. 

> 
> Perhaps this behavior should change.    

The behaviour you describe is correct. I just point out that there is a
difference when blacklisting at runtime compared to when blacklisting at
restart. 

At runtime that does not match, in my opinion, with what you can read in
blocker.c's explanation. 

>     
> > From this, I understand that information about attacker blacklisted is
> > cleared from memory/lists/running process.       
> 
> It looks like an attacker that is blacklisted is not correctly removed 
> from the block list. As you point out, all of this can only happen when 
> SSHGuard blacklists an attacker while it's running (not loaded from the 
> blacklist) and the administrator changes the firewall rules under 
> SSHGuard's control while it is running.    

Blacklisting in sshguard is "forever". It happens often attacker's have dynamic
ips. You may want to put an attacker in blacklist for 2 or 3 days if there are
too many abuses from it. But you may want to allow this ip to access your
services again after that time if there is no more "attacks" during that time
and that without restarting SSHGuard. 

So you considere this IP "safe" again, you remove the ip from firewall, but no
tracking is done anymore for new attacks. 
> 
> What should the correct behavior be?    

Like you said above, the blacklisted IP is not removed from hell list at runtime
blacklist and should be to reflect what you can find in explanation text I
mention above. Except that, about this issue, everything else seems correct at
this time. 

I have some lines of code to "fix" this. I put fix between double quotes
because in my opinion there is something to fix but don't know yet your
position about that. 
> 
> Regards,
> Kevin    

Regards,
K.

Re: [SSHGuard-users] Blacklist behaviour with hell list

[kaycee gb <kis...@ho...>]

Sorry forgot the list in first reply.

Le Thu, 6 May 2021 00:46:25 +0300,
Christos Chatzaras <ch...@cr...> a écrit :

> > On 6 May 2021, at 00:08, Kevin Zheng <kev...@gm...> wrote:
> > 
> > Hi there,
> > 
> > On 5/5/21 12:44 PM, kaycee gb wrote:    
>  [...]  
>  [...]  
>  [...]    
> > 
> > SSHGuard assumes that nobody else is changing the firewall rules under its
> > control while it is running. Under this assumption, it should not be
> > possible for an attacker who is blacklisted to show up again. If this does
> > happen, SSHGuard's current behavior is to warn about it without re-blocking
> > the attacker.
> > 
> > Perhaps this behavior should change.
> >     
> 
> I believe the way it works now is correct.
> 
> If you manually remove the IP from firewall table but keep the IP in
> blacklist.db if you reload sshguard it will block it again.
> 
> So why not remove the IP from blacklist.db and then reload sshguard?  

I for example do not want to loose the score tracking for other attackers when
releasing one ip ;)

K.

Re: [SSHGuard-users] Blacklist behaviour with hell list

[kaycee gb <kis...@ho...>]

Hi,

Sorry I forgot the list in first reply.

Le Wed, 5 May 2021 14:08:20 -0700,
Kevin Zheng <kev...@gm...> a écrit :

> Hi there,
> 
> On 5/5/21 12:44 PM, kaycee gb wrote:  
> > The point is that after I remove the attacker's address from firewall rules,
> > new "attacks" are not detected and can go smoothly.
> > 
> > I think it has something to do with the code here:    
>  [...]    
> > 
> > sshguard thinks that address is already blocked but shouldn't that address
> > be released and remove from hell list when blacklisting ?    
> 
> SSHGuard assumes that nobody else is changing the firewall rules under 
> its control while it is running. Under this assumption, it should not be 
> possible for an attacker who is blacklisted to show up again.   

I agree. When an attacker is blacklisted, he can't reach the host and/or any
service, so attacker is not logged and SSHGuard will not do anything. That's
seems correct.

>If this 
> does happen, SSHGuard's current behavior is to warn about it without 
> re-blocking the attacker.  

>From what I see, when an attacker is blacklisted at runtime, and you remove the
rule from firewall after blacklist time, there is no warning at all. 

However, when you restart SSHGuard, blacklist list is populated, firewall rules
are loaded. Then if you remove attacker from firewall rules, SSHGuard does it
jobs in a normal way. I mean, track attacker's cumulative score and warn
about it and blacklist at threshold exceed. 
Then again, after this runtime blacklist, if you remove attacker from firewall,
we have the situation that SSHguard do not warn again. 

> 
> Perhaps this behavior should change.  

The behaviour you describe is correct. I just point out that there is a
difference when blacklisting at runtime compared to when blacklisting at
restart. 

At runtime that does not match, in my opinion, with what you can read in
blocker.c's explanation. 

>   
> > From this, I understand that information about attacker blacklisted is
> > cleared from memory/lists/running process.     
> 
> It looks like an attacker that is blacklisted is not correctly removed 
> from the block list. As you point out, all of this can only happen when 
> SSHGuard blacklists an attacker while it's running (not loaded from the 
> blacklist) and the administrator changes the firewall rules under 
> SSHGuard's control while it is running.  

Blacklisting in sshguard is "forever". It happens often attacker's have dynamic
ips. You may want to put an attacker in blacklist for 2 or 3 days if there are
too many abuses from it. But you may want to allow this ip to access your
services again after that time if there is no more "attacks" during that time
and that without restarting SSHGuard. 

So you considere this IP "safe" again, you remove the ip from firewall, but no
tracking is done anymore for new attacks. 
> 
> What should the correct behavior be?  

Like you said above, the blacklisted IP is not removed from hell list at runtime
blacklist and should be to reflect what you can find in explanation text I
mention above. Except that, about this issue, everything else seems correct at
this time. 

I have some lines of code to "fix" this. I put fix between double quotes
because in my opinion there is something to fix but don't know yet your
position about that. 
> 
> Regards,
> Kevin  

Regards,
K.

Re: [SSHGuard-users] Blacklist behaviour with hell list

[Jim S. <jse...@Li...>]

On Wed, 5 May 2021 14:08:20 -0700
Kevin Zheng <kev...@gm...> wrote:

[snip]
> 
> SSHGuard assumes that nobody else is changing the firewall rules
> under its control while it is running.

That seems to me a reasonable assumption on the service's part.

> Under this assumption, it
> should not be possible for an attacker who is blacklisted to show
> up again. If this does happen, SSHGuard's current behavior is to
> warn about it without re-blocking the attacker.
> 
> Perhaps this behavior should change.

I don't think so.

> 
[snip]
> As you point out, all of this can only
> happen when SSHGuard blacklists an attacker while it's running (not
> loaded from the blacklist) and the administrator changes the
> firewall rules under SSHGuard's control while it is running.
> 
> What should the correct behavior be?

Perhaps I'm confused, but how can an application be expected to
compensate for somebody or something yanking the rug out from under
it behind the scenes?

Mind you: I'm still using a very old version of sshguard.  It's quite
possible I'm missing something key in this discussion.  (E.g.: What
is this "blacklist" and what is a "hell list?"  I looked through my
sshguard mail archive and the on-line release notes.  Came up
bupkis.)  If I'm out-of-line, please accept my apologies.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] Blacklist behaviour with hell list

[Christos C. <ch...@cr...>]

> On 6 May 2021, at 00:08, Kevin Zheng <kev...@gm...> wrote:
> 
> Hi there,
> 
> On 5/5/21 12:44 PM, kaycee gb wrote:
>> The point is that after I remove the attacker's address from firewall rules,
>> new "attacks" are not detected and can go smoothly.
>> I think it has something to do with the code here:
>>>    /* address already blocked? (can happen for 100 reasons) */$
>>>    if (blocklist_contains(attack)) {$
>>>        sshguard_log(LOG_INFO, "%s has already been blocked.",$
>>>                attack.address.value);$
>>>        return;$
>>>    }
>> sshguard thinks that address is already blocked but shouldn't that address be
>> released and remove from hell list when blacklisting ?
> 
> SSHGuard assumes that nobody else is changing the firewall rules under its control while it is running. Under this assumption, it should not be possible for an attacker who is blacklisted to show up again. If this does happen, SSHGuard's current behavior is to warn about it without re-blocking the attacker.
> 
> Perhaps this behavior should change.
> 

I believe the way it works now is correct.

If you manually remove the IP from firewall table but keep the IP in blacklist.db if you reload sshguard it will block it again.

So why not remove the IP from blacklist.db and then reload sshguard?

Re: [SSHGuard-users] Blacklist behaviour with hell list

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

Hi there,

On 5/5/21 12:44 PM, kaycee gb wrote:
> The point is that after I remove the attacker's address from firewall rules,
> new "attacks" are not detected and can go smoothly.
> 
> I think it has something to do with the code here:
>>     /* address already blocked? (can happen for 100 reasons) */$
>>     if (blocklist_contains(attack)) {$
>>         sshguard_log(LOG_INFO, "%s has already been blocked.",$
>>                 attack.address.value);$
>>         return;$
>>     }
> 
> sshguard thinks that address is already blocked but shouldn't that address be
> released and remove from hell list when blacklisting ?

SSHGuard assumes that nobody else is changing the firewall rules under 
its control while it is running. Under this assumption, it should not be 
possible for an attacker who is blacklisted to show up again. If this 
does happen, SSHGuard's current behavior is to warn about it without 
re-blocking the attacker.

Perhaps this behavior should change.

> From this, I understand that information about attacker blacklisted is cleared
> from memory/lists/running process. 

It looks like an attacker that is blacklisted is not correctly removed 
from the block list. As you point out, all of this can only happen when 
SSHGuard blacklists an attacker while it's running (not loaded from the 
blacklist) and the administrator changes the firewall rules under 
SSHGuard's control while it is running.

What should the correct behavior be?

Regards,
Kevin

[SSHGuard-users] Blacklist behaviour with hell list

[kaycee gb <kis...@ho...>]

Hello,

I use sshguard for some time now. After some weeks I started digging in the
code and found this list explanation in blocker.c about fundamental data
structures. 

> * -b). After blacklisting, the block of an attacker is released, because it$ 
> *  has already been blocked permanently.

>From this, I understand that information about attacker blacklisted is cleared
from memory/lists/running process. 

The point is that after I remove the attacker's address from firewall rules,
new "attacks" are not detected and can go smoothly. 

I think it has something to do with the code here:
>    /* address already blocked? (can happen for 100 reasons) */$
>    if (blocklist_contains(attack)) {$
>        sshguard_log(LOG_INFO, "%s has already been blocked.",$
>                attack.address.value);$
>        return;$
>    }

sshguard thinks that address is already blocked but shouldn't that address be
released and remove from hell list when blacklisting ?

In addition, when restarting, blacklist list is updated correctly from
blacklist.db and hell list is not touched. That seems more in adequation with
the explanation above. 

Where am I wrong ? 

K.

Re: [SSHGuard-users] Does Debian 10 install sshguard with nftables as the backend?

[<81...@2r...>]

Jack,

Good, thank you for letting me know.  I am also very new to nftables, but I like it so far.  It has some things that remind me of the packet filter firewall in BSD distro's (pf, pfsense, etc.).  My next step is to get a Debian 10 VPS, and try to install sshguard from source, and see if I can set the BACKEND correctly as you did.  Compiling sshguard on Debian 9 did not work for me, so instead of patching that, let me see if Debian 10 compiles.


Kevin, if it compiles on Debian 10 and the backend sets, I'm in good shape.  As I mentioned, nftables on Debian 9 may not have enough users to patch that tarball for nftables.


Gordon

>>
>>  
>> Hello, Jack, list,
>>
>> Did you install both nftables and sshguard using command line apt install on Debian 10?  If so, that could mean the .deb files from Debian 10 automatically install sshguard with ntables as the backend.  
>>
>>
>>> When buster (Debian 10.0) was first installed (upgrading from Debian 9), I had the surprise to discover the Nftables. By the way, the old version of sshguard didn't worked anymore.
>>> So I downloaded and compiled Ssshg-ard-2.4.1, installed the correct linked files for nftables, learned nftables with their wiki, etc.
>>> Now everything works OK.
>>> Hope it helps...
>>> regards
>>> --
>>> Michel (aka cmic , aka Jack Keradec...)
>>>
>>>
>> Debian 9 (I think) tries to keep iptables when it installs nftables, and I'm guessing 9 won't pick up the nftables backend in sshguard config.  I might try to download the .deb files from Debian 10 for both onto the Debian 9 server, and then install them with gdebi or dpkg.
>>
>> Again, many thanks,
>>
>> Gordon
>>
>> Mar 16, 2021, 14:49 by cm...@li...:
>>
>>> Hello
>>>
>>> I use nftables + sshguard 2.4.1 on Debian 10
>>> ________________________________________
>>> >De : 8187--- via sshguard-users <ssh...@li...>
>>> >Envoyé : mardi 16 mars 2021 04:53
>>> >À : Sshguard Users
>>> >Objet : [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?
>>>
>>>>
>>>>
>>> >How does the blacklist work exactly? From the manpage on Debian 9 I assumed (wrongly?) that sshguard writes to a blacklist file only to >reload it on start or restart. 
>>>
>>> Whe an IP adress is blocked forever, sshguard add this Ip address on the blacklist (/usr/local/etc/blacklist for me) with a unix timestamp *and* 
>>> add this IP address on the 'table ip sshguard' of nftables. This way, the whole blacklist is reloaded on nftables whenever you restart sshguard.
>>> Notice that in the example below, the whole /24 subnet is blaccklisted, which is my own choice. YMMV 
>>>
>>> --------8<-- nft list ruleset ---------
>>> ...
>>> table ip sshguard {
>>> set attackers {
>>> type ipv4_addr
>>> flags interval
>>> elements = { 1.212.145.0/24, 31.210.20.0/24,
>>> 31.210.22.0/24, 40.123.248.0/24,
>>> 43.246.139.0/24, 45.95.169.0/24,
>>> 45.133.1.0/24, 45.141.84.0/24,
>>> 46.101.73.0/24, 74.201.28.0/24,
>>> 77.108.96.0/24, 81.161.63.0/24 }
>>> ....
>>> -----ENDOF ---8<-- nft list ruleset ---------
>>>
>>> --
>>> cmic, retired sysadmin 8-))
>>>
>>>
>>>
>>>
>>>
>>> But from the list archives it appears that on some distros the blacklist file is permanent, and that it aggregates all blacklisted ip addresses without releasing them.
>>>
>>> I have this in /etc/default/sshguard:
>>>
>>> # See man page sshguard(8) for documentation of the command line options
>>> ENABLE_FIREWALL=1
>>>
>>> # By default all units are monitored in SystemD
>>> # list of log files to scan delimited by space (Kfreebsd only)
>>> LOGFILES="/var/log/auth.log"
>>>
>>> # Whitelist configuration file
>>> WHITELIST="/etc/sshguard/whitelist"
>>>
>>> # Other options
>>> ARGS="-a 30 -b 100:/etc/sshguard/blacklist -p 420 -s 3600"
>>>
>>> When I'm able to install sshguard from source and set hosts as the backend, I think (but I'm not sure) that it does eventually remove blocked ip addresses. But with a firewall, do blocked ip's remain in the blacklist file?
>>>
>>> Thanks!
>>>
>>
>>
>
>

[SSHGuard-users] Does Debian 10 install sshguard with nftables as the backend?

[<81...@2r...>]

Hello, Jack, list,

Did you install both nftables and sshguard using command line apt install on Debian 10?  If so, that could mean the .deb files from Debian 10 automatically install sshguard with ntables as the backend.  Debian 9 (I think) tries to keep iptables when it installs nftables, and I'm guessing 9 won't pick up the nftables backend in sshguard config.  I might try to download the .deb files from Debian 10 for both onto the Debian 9 server, and then install them with gdebi or dpkg.

Again, many thanks,

Gordon
Mar 16, 2021, 14:49 by cm...@li...:

> Hello
>
> I use nftables + sshguard 2.4.1 on Debian 10
> ________________________________________
> >De : 8187--- via sshguard-users <ssh...@li...>
> >Envoyé : mardi 16 mars 2021 04:53
> >À : Sshguard Users
> >Objet : [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?
>
>>
>>
> >How does the blacklist work exactly?  From the manpage on Debian 9 I assumed (wrongly?) that sshguard writes to a blacklist file only to >reload it on start or restart. 
>
> Whe an IP adress is blocked forever, sshguard add this Ip address on the blacklist (/usr/local/etc/blacklist for me) with a unix timestamp *and* 
> add this IP address on the 'table ip sshguard' of nftables. This way, the whole blacklist is reloaded on nftables whenever you restart sshguard.
> Notice that in the example below, the whole /24 subnet is blaccklisted, which is my own choice. YMMV 
>
> --------8<-- nft list ruleset ---------
> ...
> table ip sshguard {
>  set attackers {
>  type ipv4_addr
>  flags interval
>  elements = { 1.212.145.0/24, 31.210.20.0/24,
>  31.210.22.0/24, 40.123.248.0/24,
>  43.246.139.0/24, 45.95.169.0/24,
>  45.133.1.0/24, 45.141.84.0/24,
>  46.101.73.0/24, 74.201.28.0/24,
>  77.108.96.0/24, 81.161.63.0/24 }
> ....
> -----ENDOF ---8<-- nft list ruleset ---------
>
> --
> cmic, retired sysadmin 8-))
>
>
>
>
>
> But from the list archives it appears that on some distros the blacklist file is permanent, and that it aggregates all blacklisted ip addresses without releasing them.
>
> I have this in /etc/default/sshguard:
>
> # See man page sshguard(8) for documentation of the command line options
> ENABLE_FIREWALL=1
>
> # By default all units are monitored in SystemD
> # list of log files to scan delimited by space (Kfreebsd only)
> LOGFILES="/var/log/auth.log"
>
> # Whitelist configuration file
> WHITELIST="/etc/sshguard/whitelist"
>
> # Other options
> ARGS="-a 30 -b 100:/etc/sshguard/blacklist -p 420 -s 3600"
>
> When I'm able to install sshguard from source and set hosts as the backend, I think (but I'm not sure) that it does eventually remove blocked ip addresses.  But with a firewall, do blocked ip's remain in the blacklist file?
>
> Thanks!
>

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

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

On 3/16/21 8:17 PM, Kevin Buckley wrote:
>> SSHGuard remembers the addresses that are blocked permanently by adding
>> them to the blacklist file, which is written to when an address is
>> blacklisted and loaded every time SSHGuard stops.
>>
>> I'll clear up the man page a bit.
> 
> Surely "loaded every time SSHGuard starts": not stops ?

Yes, that's a typo on my part.

I've pushed a revised man page to Git. You can also read it online here:

https://bitbucket.org/sshguard/sshguard/src/master/doc/sshguard.8.rst

Does this help clear things up a bit?

Regards,
Kevin

Re: [SSHGuard-users] Change sshguard backend to hosts for transition from iptables to nftables?

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

Hi there,

On 3/14/21 9:08 PM, 8187--- via sshguard-users wrote:
> We're moving a number of Debian machines from iptables to nftables 
> (nft), and it looks as if the sooner we purge iptables and ufw and use 
> only nftables the better.  While this occurs, we would like to try to 
> run sshguard with the "tcpwrapper" hosts backend, and write the blocked 
> hosts to /etc/hosts.deny.  We could install from source and manually set 
> the backend in sshguard.conf, but that would also require changes to the 
> systemd sshguard.services file.

Unless the package doesn't have sshg-fw-hosts (built by default) 
installed in libexec, you shouldn't have to build SSHGuard from source 
to use the hosts (tcpwrapper) backend.

You should just be able to set the BACKEND to sshg-fw-hosts in 
sshguard.conf.

> Unfortunately, Debian 9, after building the dependencies:
> 
> autoconf automake byacc flex gcc python-docutils
> 
> fails ./configure:
> 
> <<
> config.status:1194: error: Something went wrong bootstrapping makefile 
> fragments
>      for automatic dependency tracking.  If GNU make was not used, consider
>      re-running the configure script with MAKE="gmake" (or whatever is
>      necessary).  You can also try re-running configure with the
>      '--disable-dependency-tracking' option to at least be able to build
>      the package (albeit without support for automatic dependency tracking).
>  >>

This could be an automake issue where it thinks some file got touched. 
Which tarball did you extract to get this message?

Regards,
Kevin

Re: [SSHGuard-users] Thank you for the help. Blacklist permanent; Can it be commented out?

[Christos C. <ch...@cr...>]

> On 17 Mar 2021, at 05:49, 8187--- via sshguard-users <ssh...@li...> wrote:
> 
> -Can the blacklist db be "commented out" to release ip's?  It's ordered by unix time on Debian 9, earliest on top, latest on bottom.   If so I might try a script that checks blacklist once a month, and either removes or comments out entries over 30 days old.

The database has this format:

1615489161|100|4|123.123.123.123

The first "column" is the unix timestamp so you can write a script to check if the entries are older than 30 days and remove them (for example using sed). Then you have to restart sshguard or you can also remove these IPs directly from your firewall to avoid a sshguard restart.

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

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

On 2021/03/17 11:58, 81...@2r... wrote:
> 
> Mar 16, 2021, 22:17 by kev...@gm...:
> 
>> On 2021/03/17 02:08, Kevin Zheng wrote:
>>
>>>
>>> SSHGuard remembers the addresses that are blocked permanently by adding
>>> them to the blacklist file, which is written to when an address is
>>> blacklisted and loaded every time SSHGuard stops.
>>>
>>> I'll clear up the man page a bit.
>>>
>>
>> Surely "loaded every time SSHGuard starts": not stops ?
>>
>> Actually writing to point out that one of the "nice" things about
>> that behaviour is that it affords one the opportunity to combine
>> entries from multiple blacklist files ahead of a restart on any
>> given host running SSHGuard.
>>
>> HTH,
>> Kevin
>> 
> I read the manpage incorrectly, so that's my error.  On debian 9 it's clear that blacklist is permanent ("never automatically unblocked") and should be occasionally pruned of stale entries ("but it is good practice to periodically clean out stale blacklist entries.")
> 
> <<-b thresh:file
>                Blacklist an attacker when its dangerousness exceeds thresh.  Blacklisted addresses are added to file so they can be read at the next startup.  Blacklisted  addresses are never automatically unblocked, but it is good practice to periodically clean out stale blacklist entries.
>>>
> Excellent idea to add other blacklists to the blacklist db.  I suppose the snytax could just copy what's already there:
> 
> |unixtime|threshold|failures|ip:
> 
> <<1615817411|100|4|154.209.5.25
> 1615817489|100|4|187.170.234.27
>>>
> 
> Gordon

Not sure I hear the "stale" in

  "... periodically clean out stale blacklist entries ..."

suggestion, on the assumption that once you have been "attacked",
then unless there has been a justification for the access, or a
process whereby you move the blocking closer to the source of the
attack, you would continue to block locally.


As for the melding together of blacklist files, I just cat them and
then run the following AWK script over the concatenated list, with
the idea that you keep a record of the "first/earliest" time you
saw an attack from a given IP.

# munge_blacklists.awk
#
# Takes a list of SSHGuard blacklists
#  and keeps the earliest occurence of duplicated IPs
#
# cat blacklist.*-{1,2} | awk -f munge_blacklists.awk | \
#   sort -n > blacklist.prod_cray
{
   split($0, a, "|")
   if( j[a[4]] > 0)
   {
#DEBUG   print "Dup ", j[a[4]], a[4], a[1]
#     Use the lowest
     if( a[1] > j[a[4]])
     {
       a[1] = j[a[4]]
     }
   }
   j[a[4]] = a[1]
}
END{
   for( b in j)
   {
     printf "%s|100|4|%s\n", j[b], b
   }
}

That might be useful for you: though there will be other ways,
and other languages, that will achieve the same thing.

[SSHGuard-users] Thank you for the help. Blacklist permanent; Can it be commented out?

[<81...@2r...>]

Hello, list,

You guys rock, than you.  My confusion is lifting.  So blacklist is permanent, and it is read each time sshguard starts.  So:

-Can the blacklist db be "commented out" to release ip's?  It's ordered by unix time on Debian 9, earliest on top, latest on bottom.   If so I might try a script that checks blacklist once a month, and either removes or comments out entries over 30 days old.

-If nftables works on debian 9 and integrates with sshguard, I will definitely move to it and purge iptables and ufw.  Before doing that I will place the blacklist ips in hosts.deny, along with a current list of bogons.  I may try to use the .deb package for Debian 10 for sshguard, and hope it automatically points to nftables as a backend.

-I won't use the "hosts" backend, but rather use a firewall backend.  My recollection is that hosts.deny is only read by apps compiled with tcpd.  ACL access might have a better way to do this, but any firewall will block and drop blacklisted ip addresses for any daemon that might be listening, tcpd enabled or not.

-I like the CIDR notation block of ips using /24 notation.  If I can routinely rotate and remove stale blocked ip's I will try that.  I could also use the whitelist to prevent being locked out.

-Any advantage of using standard input and a log?  If I gave the options "-l - /var/log/auth.log" would sshguard monitor both standard input and auth.log?

I'm surprised at how clever the "script kiddies" must be to avoid an immediate block.  Whatever they're using for random spaces the attacks just under some threshold.  This server shows 0 failures for registered users with faillog -a, but the blacklist has grown to 61 ips, and the firewall table is dropping 77 ips  when I run:
 
iptables --list sshguard --line-number --numeric | less

Those must be small numbers compared to what most of you see, but this is a small server with very few daemons listening for ports.

Gordon

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

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

On 2021/03/17 02:08, Kevin Zheng wrote:
>
> SSHGuard remembers the addresses that are blocked permanently by adding
> them to the blacklist file, which is written to when an address is
> blacklisted and loaded every time SSHGuard stops.
>
> I'll clear up the man page a bit.

Surely "loaded every time SSHGuard starts": not stops ?

Actually writing to point out that one of the "nice" things about
that behaviour is that it affords one the opportunity to combine
entries from multiple blacklist files ahead of a restart on any
given host running SSHGuard.

HTH,
Kevin

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

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

Hi there,

On 3/15/21 8:53 PM, 8187--- via sshguard-users wrote:
> How does the blacklist work exactly?  From the manpage on Debian 9 I 
> assumed (wrongly?) that sshguard writes to a blacklist file only to 
> reload it on start or restart.  But from the list archives it appears 
> that on some distros the blacklist file is permanent, and that it 
> aggregates all blacklisted ip addresses without releasing them.

Just to clarify the answer to this question:

When blacklisting is enabled, attackers who exceed the blacklist 
threshold (100 in your configuration, or ~10 attacks) are blocked 
permanently.

SSHGuard remembers the addresses that are blocked permanently by adding 
them to the blacklist file, which is written to when an address is 
blacklisted and loaded every time SSHGuard stops.

I'll clear up the man page a bit.

Regards,
Kevin

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

[Christos C. <ch...@cr...>]

> I work with ipfw firewall. The blacklist is named as a table in its configuration
> When I do maintenance I empty the blacklist by a simple echo > blacklist.db and restart (i) sshguard after with 'sshguart restart' and (ii) a ipfw firewall restart

ipfw restart is not needed. What I do is "rm /var/db/sshguard/blacklist.db" and "service sshguard restart".

Re: [SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

[Jos C. <ssh...@cl...>]

Op 16-3-21 om 4:53 schreef 8187--- via sshguard-users:
> When I'm able to install sshguard from source and set hosts as the 
> backend, I think (but I'm not sure) that it does eventually remove 
> blocked ip addresses.  But with a firewall, do blocked ip's remain in 
> the blacklist file?

I work with ipfw firewall. The blacklist is named as a table in its 
configuration
When I do maintenance I empty the blacklist by a simple echo > 
blacklist.db and restart (i) sshguard after with 'sshguart restart' and 
(ii) a ipfw firewall restart

best, jos

-- With both feed on the ground you will never make a step forward

[SSHGuard-users] Is blacklist permanent? If so move ip addresses to /etc/hosts.deny?

[<81...@2r...>]

How does the blacklist work exactly?  From the manpage on Debian 9 I assumed (wrongly?) that sshguard writes to a blacklist file only to reload it on start or restart.  But from the list archives it appears that on some distros the blacklist file is permanent, and that it aggregates all blacklisted ip addresses without releasing them.

I have this in /etc/default/sshguard:

# See man page sshguard(8) for documentation of the command line options                                   
ENABLE_FIREWALL=1

# By default all units are monitored in SystemD                                                           
# list of log files to scan delimited by space (Kfreebsd only)                                            
LOGFILES="/var/log/auth.log"

# Whitelist configuration file                                                                            
WHITELIST="/etc/sshguard/whitelist"

# Other options                                                                                           
ARGS="-a 30 -b 100:/etc/sshguard/blacklist -p 420 -s 3600"

When I'm able to install sshguard from source and set hosts as the backend, I think (but I'm not sure) that it does eventually remove blocked ip addresses.  But with a firewall, do blocked ip's remain in the blacklist file?

Thanks!

[SSHGuard-users] SSHGuard 2.4.2 release announcement

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

Dear SSHGuard users,

SSHGuard 2.4.2 is now available from SourceForge [1]. There are not many 
changes from 2.4.1; the most significant changes are to recognize some 
new attack signatures from Postfix and remove some attack signatures for 
SSH and Cyrus that were false positive-prone.

**Added**

- Recognize rejections from Postfix's postscreen daemon
- The parser can now be changed using the *PARSER* and *POST_PARSER*
   options

**Changed**

- Remove some false positive attack signatures for SSH and Cyrus
- Adjust log verbosity of some log messages
- The *firewalld* backend now uses *firewall-cmd* instead of *iptables*
   to flush block lists

Regards,
Kevin

[1] https://sourceforge.net/projects/sshguard/files/sshguard/2.4.2/

Re: [SSHGuard-users] [PATCH] nft-sets: switch to a single 'inet' family table

[Christopher E. <ce...@lc...>]

Hi,
I'll try it out,

Christopher

On 11.03.21 20:52, Kevin Zheng wrote:
> On 3/11/21 6:44 AM, Lauri Tirkkonen via sshguard-users wrote:
>> nftables supports a family called 'table' for dual stack abstraction;
>> use that instead of creating two separate tables. two sets are still
>> needed since nftables can only store either v4 or v6 addresses in a
>> single set, but having just one table is still a simplification.
>>
>> also fix a bug where reinitializing the backend would always append a
>> new drop rule at the end of the chain.
> 
> Thank you for the patch. This patch seems reasonable.
> 
> Unfortunately, I don't have a machine on which I can test this patch.
> Could another nft user give this patch a whirl and confirm that it works
> in other environments?
> 
> Thanks,
> Kevin
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[SSHGuard-users] Change sshguard backend to hosts for transition from iptables to nftables?

[<81...@2r...>]

Hello, sshguard list,

Thank you to the developers and maintainers for the excellent work on sshguard.  Very, very useful.

We're moving a number of Debian machines from iptables to nftables (nft), and it looks as if the sooner we purge iptables and ufw and use only nftables the better.  While this occurs, we would like to try to run sshguard with the "tcpwrapper" hosts backend, and write the blocked hosts to /etc/hosts.deny.  We could install from source and manually set the backend in sshguard.conf, but that would also require changes to the systemd sshguard.services file.

Unfortunately, Debian 9, after building the dependencies:

autoconf automake byacc flex gcc python-docutils

fails ./configure:

<<config.status:1194: error: Something went wrong bootstrapping makefile fragments
    for automatic dependency tracking.  If GNU make was not used, consider
    re-running the configure script with MAKE="gmake" (or whatever is
    necessary).  You can also try re-running configure with the
    '--disable-dependency-tracking' option to at least be able to build
    the package (albeit without support for automatic dependency tracking).
>>

I plan to figure this out (maybe a missing build library?), but there are too many machines running Debian 9 to do this quickly.  On Ubuntu 20.04 the dependencies install, compile and make without a problem, and we can set the hosts backend with no problem (BACKEND="/usr/local/libexec/sshg-fw-hosts" in /usr/local/etc/sshguard.conf).

Has anyone been able to change the backend from the stock Debian 9 installed iptables backend to hosts?  If so, how, and how did you modify the sshguard.services file?

I will try to install next from git and see if that is successful.  

Any help would be appreciated.  My skills are limited, but I can spin up a few "sacrificial" Debian 10 vm's if you need someone to test a config with sshguard and nft.  In the past the hosts.deny backend seemed less memory intensive that the firewall backends (pf at the time), but nftables looks impressive.

Thank You,

Gordon

Re: [SSHGuard-users] [PATCH] nft-sets: switch to a single 'inet' family table

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

On 3/11/21 6:44 AM, Lauri Tirkkonen via sshguard-users wrote:
> nftables supports a family called 'table' for dual stack abstraction;
> use that instead of creating two separate tables. two sets are still
> needed since nftables can only store either v4 or v6 addresses in a
> single set, but having just one table is still a simplification.
> 
> also fix a bug where reinitializing the backend would always append a
> new drop rule at the end of the chain.

Thank you for the patch. This patch seems reasonable.

Unfortunately, I don't have a machine on which I can test this patch. 
Could another nft user give this patch a whirl and confirm that it works 
in other environments?

Thanks,
Kevin

[SSHGuard-users] [PATCH] nft-sets: switch to a single 'inet' family table

[Lauri T. <la...@ha...>]

nftables supports a family called 'table' for dual stack abstraction;
use that instead of creating two separate tables. two sets are still
needed since nftables can only store either v4 or v6 addresses in a
single set, but having just one table is still a simplification.

also fix a bug where reinitializing the backend would always append a
new drop rule at the end of the chain.
---
 CHANGELOG.rst              |  4 ++++
 doc/sshguard-setup.7.rst   |  7 +++----
 src/fw/sshg-fw-nft-sets.sh | 35 +++++++++++------------------------
 3 files changed, 18 insertions(+), 28 deletions(-)

diff --git a/CHANGELOG.rst b/CHANGELOG.rst
index a673b51..38f1894 100644
--- a/CHANGELOG.rst
+++ b/CHANGELOG.rst
@@ -16,6 +16,10 @@ Next
 
 - Recognize rejections from Postfix's postscreen daemon
 
+**Changed**
+
+- Switch nftables backend to use a single ``inet`` family table
+
 2.4.1
 =====
 **Added**
diff --git a/doc/sshguard-setup.7.rst b/doc/sshguard-setup.7.rst
index f8306c4..761f309 100644
--- a/doc/sshguard-setup.7.rst
+++ b/doc/sshguard-setup.7.rst
@@ -193,13 +193,12 @@ automatically.
 
 You can inspect the contents of the sets using::
 
-    # nft list set ip sshguard attackers
-    # nft list set ip6 sshguard attackers
+    # nft list set inet sshguard attackers4
+    # nft list set inet sshguard attackers6
 
 Moreover, you can display sshguard's tables with::
 
-    # nft list table ip sshguard
-    # nft list table ip6 sshguard
+    # nft list table inet sshguard
 
 
 TROUBLESHOOTING
diff --git a/src/fw/sshg-fw-nft-sets.sh b/src/fw/sshg-fw-nft-sets.sh
index ea9e202..d2eec2d 100644
--- a/src/fw/sshg-fw-nft-sets.sh
+++ b/src/fw/sshg-fw-nft-sets.sh
@@ -8,40 +8,29 @@ NFT_TABLE=sshguard
 NFT_CHAIN=blacklist
 NFT_SET=attackers
 
-proto() {
-    if [ "6" = "$1" ]; then
-        echo ip6
-    else
-	echo ip
-    fi
-}
-
 run_nft() {
-    ${CMD_NFT} $1 $(proto $3) "${NFT_TABLE}" "$2" > /dev/null 2>&1
+    ${CMD_NFT} $1 inet "${NFT_TABLE}" "$2" > /dev/null 2>&1
 }
 
 fw_init() {
-    run_nft "add table" "" 4
-    run_nft "add table" "" 6
+    run_nft "add table" ""
 
-    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 4
-    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 6
+    run_nft "add set" "${NFT_SET}4 { type ipv4_addr; flags interval; }"
+    run_nft "add set" "${NFT_SET}6 { type ipv6_addr; flags interval; }"
 
-    # Create sets
-    run_nft "add set" "${NFT_SET} { type ipv4_addr; flags interval; }" 4
-    run_nft "add set" "${NFT_SET} { type ipv6_addr; flags interval; }" 6
+    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }'
+    run_nft "flush chain" "${NFT_CHAIN}"
 
-    # Rule to drop sets' IP
-    run_nft "add rule" "${NFT_CHAIN} ip saddr @${NFT_SET} drop" 4
-    run_nft "add rule" "${NFT_CHAIN} ip6 saddr @${NFT_SET} drop" 6
+    run_nft "add rule" "${NFT_CHAIN} ip saddr @${NFT_SET}4 drop"
+    run_nft "add rule" "${NFT_CHAIN} ip6 saddr @${NFT_SET}6 drop"
 }
 
 fw_block() {
-    run_nft "add element" "${NFT_SET} { $1/$3 }" $2
+    run_nft "add element" "${NFT_SET}$2 { $1/$3 }"
 }
 
 fw_release() {
-    run_nft "delete element" "${NFT_SET} { $1/$3 }" $2
+    run_nft "delete element" "${NFT_SET}$2 { $1/$3 }"
 }
 
 fw_flush() {
@@ -50,7 +39,5 @@ fw_flush() {
 }
 
 fw_fin() {
-    # Remove tables
-    run_nft "delete table" "" 4
-    run_nft "delete table" "" 6
+    run_nft "delete table" ""
 }
-- 
2.30.1

-- 
Lauri Tirkkonen | lotheac @ IRCnet