sshguard-users

[SSHGuard-users] switch to firewalld

[Injo <sou...@pr...>]

Hey guys,

First message to the mailing list ;).

I've succesfully set up sshguard 2.0 on archlinux. I had firewalld 
running and was manually blocking IP's I found repeatedly trying to get 
into ssh. This list had around 1000 IP's in it. As you might imagine I 
was getting really tired of the manual maintenance.

When I was looking into sshguard, the documents page made no mention of 
firewalld support, so I uninstalled it and cleared my iptables setup to 
let sshguard handle it.

Just now, I read there firewalld support in version 2.0, so my question 
is, can I switch back to firewalld? How do I need to setup sshguard.conf 
to use firewalld instead?

Another thing I don't quite get is when I see sshguard blocking someone, 
I see this line:
> Aug 02 09:11:38 hostname sshguard[848]: Blocking "84.137.66.201" for 
> 960 secs (3 attacks in 140 secs,
> after 4 abuses over 1624 secs.). I also see a corresponding line with 
> iptables --list, but I don't see this being saved to 
> /etc/iptables/iptables.rules file. How is sshguard saving its blocks? 
> When I reboot the server or restart services, it won't retain whatever 
> sshguard has blocked so far, so how does this work?

Last but not least, I see some sshguard blocks being resolved to 
hostnames in iptables --list. How can I prevent it from doing that? I 
want it to block IP's, because there are dynamic DNS entries in there 
and others are just DSL/home internet lines that constantly change 
anyway. Besides that, it also takes time to try and do reverse lookups 
all the time, especially if they can't be resolved and wait for timeouts 
so I rather have sshguard just use IP addresses.

Thanks for this tool! Hopefully someone can help me here.

Regards,
Ingmar.

Re: [SSHGuard-users] switch to firewalld

[Daniel A. <co...@da...>]

On Wed, 2017-08-02 at 09:37 +0200, Ingmar wrote:
> Hey guys,
> 
> First message to the mailing list ;).
> 
> I've succesfully set up sshguard 2.0 on archlinux. I had firewalld 
> running and was manually blocking IP's I found repeatedly trying to
> get into ssh. This list had around 1000 IP's in it. As you might
> imagine I was getting really tired of the manual maintenance.
> 
> When I was looking into sshguard, the documents page made no mention
> of firewalld support, so I uninstalled it and cleared my iptables
> setup to let sshguard handle it.
> 
> Just now, I read there firewalld support in version 2.0, so my
> question is, can I switch back to firewalld? How do I need to setup
> sshguard.conf to use firewalld instead?

I wrote this tutorial for using SSHGuard with the FirewallD backend. It
says “Fedora” on the tin, but that really just refers to an systemd +
firewalld environment. It should work for you on Arch as well.
It says "Fedora" on the tin, but that really just refers to the
systemd+selinux+firewalld technology stack and should work for you on

https://ctrl.blog/entry/how-to-sshguard-firewalld

Please let me know if you have any questions or comments, and I can
update the tutorial to answer them.

> Another thing I don't quite get is when I see sshguard blocking
> someone, I see this line:
> Aug 02 09:11:38 hostname sshguard[848]: Blocking "84.137.66.201"
> for 960 secs (3 attacks in 140 secs, after 4 abuses over 1624 secs.).
> I also see a corresponding line with iptables --list, but I don't see
> this being saved to /etc/iptables/iptables.rules file. How is
> sshguard saving its blocks? 
> 
> When I reboot the server or restart services, it won't retain
> whatever sshguard has blocked so far, so how does this work?

SSHGuard doesn't store blocks permanently by design. Whenever an
attacker is detected in the configured time window, it will be blocked
for a certain block time. The block time is doubled on subsequent
attacks from the same IP address. Restarting SSHGuard resets every
block. This prevents your block rules from getting out of hand. (Most
attacks don't persist from the same source for more than a couple of
days at the most.)

You can actually change this behaviour to a permanent block. Copy the
firewalld backend (it’s just a shell script that talks with firewalld)
and no-op the release and flush functions. Then add --permanent lags to
all the calls to firewalld and reload the firewall afterwards. Have a
look at the script, and you should be able to work it out in five
minutes.

> Last but not least, I see some sshguard blocks being resolved to 
> hostnames in iptables --list. How can I prevent it from doing that?
> I want it to block IP's, because there are dynamic DNS entries in
> there and others are just DSL/home internet lines that constantly
> change anyway. Besides that, it also takes time to try and do reverse
> lookups all the time, especially if they can't be resolved and wait
> for timeouts so I rather have sshguard just use IP addresses.

This shouldn’t be a problem with a smaller blocklist. A local DNS cache
such as dnsmasq would also all but eliminate this problem. Again, you
can modify the backend script and resolve to IP addresses before
injecting the rules into firewalld.

I’m somewhat surprised that you’re seeing hostnames, actually. Please
retest.

> Thanks for this tool! Hopefully someone can help me here.

I hope this helps! Let us know if you run into any problems!
-- 
Daniel Aleksandersen
SSHGuard contributor
https://daniel.priv.no

[SSHGuard-users] inet question

[Doug D. <do...@sa...>]

I am using sshguard with inet with FreeBSD jails. Having multiple [virtual] 
servers with differing blocking requirements this is really the only option. It 
appears to me that with the switch from BerkleyDB to a flat file that the 
blacklist is implemented by using the /etc/hosts.allow entries.

Whether I am correct or not here is what happens on two systems:

   host 1: sshguard-1.5_2
      blacklist: 7,151 entries
      hosts.allow: 30 lines; max of 270 IPs (9/line) with very little overlap

   host 2: sshguard-2.1.0_1
      blacklist: 3,251 lines
      hosts.allow: 338 line; max of 3,042 entries

first line in hosts.allow:
   ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 167.114.235.137 \
         185.143.223.191 61.184.247.8 115.238.245.4 : DENY

This entire line is in /var/db/sshguard/:

   1544124029|100|4|218.92.1.141     December 6, 2018 7:20:29 PM
   1544126972|100|4|121.22.80.117    December 6, 2018 8:09:32 PM
   1544128387|100|4|118.25.63.24         |
   1544130000|100|4|219.234.88.119       V
   1544135312|100|4|167.114.235.137
   1544135835|100|4|185.143.223.191
   1544136112|100|4|61.184.247.8
   1544137146|100|4|115.238.245.4    December 6, 2018 10:59:06

Taking a random entry, say line 2,800 from blacklist:
   1545136493|100|4|51.38.186.48     December 18, 2018 12:34:53 PM
   1545136864|100|4|182.162.96.184
   1545136941|100|4|212.88.123.198

All three are in hosts.allow

So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be pruned? This 
is the better answer to me. Also as blacklist.db is a flat file I assume the 
epoch time is the time of the blacklisting and not the last reference.



_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
   Fax: 301-217-9277

Re: [SSHGuard-users] inet question

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

Hi Doug,

I noticed that you're running two different versions of SSHGuard.

In 1.5, the port you install determines how SSHGuard blocks attacks. In
2.1, you need to specify the backend you use by yourself.

SSHGuard uses blacklist.db to keep track of hosts it has blacklisted,
because with firewalls like pf and ipfw, SSHGuard removes all of its
blocks (including those that it has blacklisted) when it exits. While
it's running, everything in blacklist.db should also be in hosts.allow.

When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells
SSHGuard what addresses to add back once it starts again.

So, they're not redundant. Is that what you're asking?

Regards,
Kevin

On 12/30/18 2:39 PM, Doug Denault wrote:
> I am using sshguard with inet with FreeBSD jails. Having multiple
> [virtual] servers with differing blocking requirements this is really
> the only option. It appears to me that with the switch from BerkleyDB to
> a flat file that the blacklist is implemented by using the
> /etc/hosts.allow entries.
> 
> Whether I am correct or not here is what happens on two systems:
> 
>   host 1: sshguard-1.5_2
>      blacklist: 7,151 entries
>      hosts.allow: 30 lines; max of 270 IPs (9/line) with very little
> overlap
> 
>   host 2: sshguard-2.1.0_1
>      blacklist: 3,251 lines
>      hosts.allow: 338 line; max of 3,042 entries
> 
> first line in hosts.allow:
>   ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119
> 167.114.235.137 \
>         185.143.223.191 61.184.247.8 115.238.245.4 : DENY
> 
> This entire line is in /var/db/sshguard/:
> 
>   1544124029|100|4|218.92.1.141     December 6, 2018 7:20:29 PM
>   1544126972|100|4|121.22.80.117    December 6, 2018 8:09:32 PM
>   1544128387|100|4|118.25.63.24         |
>   1544130000|100|4|219.234.88.119       V
>   1544135312|100|4|167.114.235.137
>   1544135835|100|4|185.143.223.191
>   1544136112|100|4|61.184.247.8
>   1544137146|100|4|115.238.245.4    December 6, 2018 10:59:06
> 
> Taking a random entry, say line 2,800 from blacklist:
>   1545136493|100|4|51.38.186.48     December 18, 2018 12:34:53 PM
>   1545136864|100|4|182.162.96.184
>   1545136941|100|4|212.88.123.198
> 
> All three are in hosts.allow
> 
> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be
> pruned? This is the better answer to me. Also as blacklist.db is a flat
> file I assume the epoch time is the time of the blacklisting and not the
> last reference.
> 
> 
> 
> _____
> Douglas Denault
> http://www.safeport.com
> do...@sa...
> Voice: 301-217-9220
>   Fax: 301-217-9277
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users


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

Re: [SSHGuard-users] inet question

[Doug D. <do...@sa...>]

I've configured sshguard correctly to use inetd. On host 2 it blocks 50k+ 
attempts/day. Configuration is straight forward enough. What I am trying to say, 
apparently not very well, is the IPs blacklisted are never removed from 
/etc/hosts.allow. In the older version of sshguard blacklisted IPs do not appear 
in the hosts.allow file.

Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated in the 
blacklist file. Can a configuration error cause this behavior?

I kinda assumed this was a bug, so my question was really, if I prune the 
hosts.allow file will the blacklist entries be honored. The answer to that is, I 
take from your email, yes.

Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails are not 
sandboxes. E.g., a process can not ascertain if it running in a jail or 
natively. My config file:

__________________sshguard.conf__________________
#!/bin/sh
# sshguard.conf -- SSHGuard configuration

# Options that are uncommented in this example are set to their default
# values. Options without defaults are commented out.

#### REQUIRED CONFIGURATION ####
# Full path to backend executable (required, no default)
BACKEND="/usr/local/libexec/sshg-fw-hosts"
#BACKEND="/usr/local/libexec/sshg-fw-ipfw"
#BACKEND="/usr/local/libexec/sshg-fw-pf"

# Space-separated list of log files to monitor. (optional, no default)
FILES="/var/log/auth.log /var/log/maillog"

# Shell command that provides logs on standard output. (optional, no default)
# Example 1: ssh and sendmail from systemd journal:
#LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t sendmail -o 
cat"
# Example 2: ssh from os_log (macOS 10.12+)
#LOGREADER="/usr/bin/log stream --style syslog --predicate '(processImagePath 
contains \"sshd\")'"

#### OPTIONS ####
# Block attackers when their cumulative attack score exceeds THRESHOLD.
# Most attacks have a score of 10. (optional, default 30)
THRESHOLD=30

# Block attackers for initially BLOCK_TIME seconds after exceeding THRESHOLD.
# Subsequent blocks increase by a factor of 1.5. (optional, default 120)
BLOCK_TIME=120

# Remember potential attackers for up to DETECTION_TIME seconds before
# resetting their score. (optional, default 1800)
DETECTION_TIME=1800

# Size of IPv6 'subnet to block. Defaults to a single address, CIDR notation. 
(optional, default to 128)
#IPV6_SUBNET=128

# Size of IPv4 subnet to block. Defaults to a single address, CIDR notation. 
(optional, default to 32)
#IPV4_SUBNET=32

#### EXTRAS ####
# !! Warning: These features may not work correctly with sandboxing. !!

# Full path to PID file (optional, no default)
#PID_FILE=/var/run/sshguard.pid

# Colon-separated blacklist threshold and full path to blacklist file.
# (optional, no default)
BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db


On Sun, 30 Dec 2018, Kevin Zheng wrote:

> Hi Doug,
>
> I noticed that you're running two different versions of SSHGuard.
>
> In 1.5, the port you install determines how SSHGuard blocks attacks. In
> 2.1, you need to specify the backend you use by yourself.
>
> SSHGuard uses blacklist.db to keep track of hosts it has blacklisted,
> because with firewalls like pf and ipfw, SSHGuard removes all of its
> blocks (including those that it has blacklisted) when it exits. While
> it's running, everything in blacklist.db should also be in hosts.allow.
>
> When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells
> SSHGuard what addresses to add back once it starts again.
>
> So, they're not redundant. Is that what you're asking?
>
> Regards,
> Kevin
>
> On 12/30/18 2:39 PM, Doug Denault wrote:
>> I am using sshguard with inet with FreeBSD jails. Having multiple
>> [virtual] servers with differing blocking requirements this is really
>> the only option. It appears to me that with the switch from BerkleyDB to
>> a flat file that the blacklist is implemented by using the
>> /etc/hosts.allow entries.
>>
>> Whether I am correct or not here is what happens on two systems:
>>
>>   host 1: sshguard-1.5_2
>>      blacklist: 7,151 entries
>>      hosts.allow: 30 lines; max of 270 IPs (9/line) with very little
>> overlap
>>
>>   host 2: sshguard-2.1.0_1
>>      blacklist: 3,251 lines
>>      hosts.allow: 338 line; max of 3,042 entries
>>
>> first line in hosts.allow:
>>   ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119
>> 167.114.235.137 \
>>         185.143.223.191 61.184.247.8 115.238.245.4 : DENY
>>
>> This entire line is in /var/db/sshguard/:
>>
>>   1544124029|100|4|218.92.1.141     December 6, 2018 7:20:29 PM
>>   1544126972|100|4|121.22.80.117    December 6, 2018 8:09:32 PM
>>   1544128387|100|4|118.25.63.24         |
>>   1544130000|100|4|219.234.88.119       V
>>   1544135312|100|4|167.114.235.137
>>   1544135835|100|4|185.143.223.191
>>   1544136112|100|4|61.184.247.8
>>   1544137146|100|4|115.238.245.4    December 6, 2018 10:59:06
>>
>> Taking a random entry, say line 2,800 from blacklist:
>>   1545136493|100|4|51.38.186.48     December 18, 2018 12:34:53 PM
>>   1545136864|100|4|182.162.96.184
>>   1545136941|100|4|212.88.123.198
>>
>> All three are in hosts.allow
>>
>> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be
>> pruned? This is the better answer to me. Also as blacklist.db is a flat
>> file I assume the epoch time is the time of the blacklisting and not the
>> last reference.
>>
>>
>>
>> _____
>> Douglas Denault
>> http://www.safeport.com
>> do...@sa...
>> Voice: 301-217-9220
>>   Fax: 301-217-9277
>>
>>
>> _______________________________________________
>> sshguard-users mailing list
>> ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> -- 
> Kevin Zheng
> kev...@gm... | ke...@be... | PGP: 0xC22E1090
>

_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
   Fax: 301-217-9277

Re: [SSHGuard-users] inet question

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

Hi Doug,

Then it might be a bug in the hosts backend. I assumed (incorrectly)
that not many people were still using it, so it's been a while since
I've taken a close look.

Like the other backends, SSHGuard should remove the entries it added
after it exits, and should re-add those that are blacklisted when it
starts up again.

So, just to be clear:

blacklist.db is the list of addresses SSHGuard blacklisted. While
SSHGuard is running, hosts.deny (or any other backend) should contain
all of blacklist.db (so that blacklisted hosts are actually blocked) as
well as additional hosts that get blocked while SSHGuard is running.

Anything else is probably a bug; I'll take a look at how the hosts
backend is doing.

Regards,
Kevin

On 12/30/18 7:00 PM, Doug Denault wrote:
> I've configured sshguard correctly to use inetd. On host 2 it blocks
> 50k+ attempts/day. Configuration is straight forward enough. What I am
> trying to say, apparently not very well, is the IPs blacklisted are
> never removed from /etc/hosts.allow. In the older version of sshguard
> blacklisted IPs do not appear in the hosts.allow file.
> 
> Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated
> in the blacklist file. Can a configuration error cause this behavior?
> 
> I kinda assumed this was a bug, so my question was really, if I prune
> the hosts.allow file will the blacklist entries be honored. The answer
> to that is, I take from your email, yes.
> 
> Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails
> are not sandboxes. E.g., a process can not ascertain if it running in a
> jail or natively. My config file:
> 
> __________________sshguard.conf__________________
> #!/bin/sh
> # sshguard.conf -- SSHGuard configuration
> 
> # Options that are uncommented in this example are set to their default
> # values. Options without defaults are commented out.
> 
> #### REQUIRED CONFIGURATION ####
> # Full path to backend executable (required, no default)
> BACKEND="/usr/local/libexec/sshg-fw-hosts"
> #BACKEND="/usr/local/libexec/sshg-fw-ipfw"
> #BACKEND="/usr/local/libexec/sshg-fw-pf"
> 
> # Space-separated list of log files to monitor. (optional, no default)
> FILES="/var/log/auth.log /var/log/maillog"
> 
> # Shell command that provides logs on standard output. (optional, no
> default)
> # Example 1: ssh and sendmail from systemd journal:
> #LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t
> sendmail -o cat"
> # Example 2: ssh from os_log (macOS 10.12+)
> #LOGREADER="/usr/bin/log stream --style syslog --predicate
> '(processImagePath contains \"sshd\")'"
> 
> #### OPTIONS ####
> # Block attackers when their cumulative attack score exceeds THRESHOLD.
> # Most attacks have a score of 10. (optional, default 30)
> THRESHOLD=30
> 
> # Block attackers for initially BLOCK_TIME seconds after exceeding
> THRESHOLD.
> # Subsequent blocks increase by a factor of 1.5. (optional, default 120)
> BLOCK_TIME=120
> 
> # Remember potential attackers for up to DETECTION_TIME seconds before
> # resetting their score. (optional, default 1800)
> DETECTION_TIME=1800
> 
> # Size of IPv6 'subnet to block. Defaults to a single address, CIDR
> notation. (optional, default to 128)
> #IPV6_SUBNET=128
> 
> # Size of IPv4 subnet to block. Defaults to a single address, CIDR
> notation. (optional, default to 32)
> #IPV4_SUBNET=32
> 
> #### EXTRAS ####
> # !! Warning: These features may not work correctly with sandboxing. !!
> 
> # Full path to PID file (optional, no default)
> #PID_FILE=/var/run/sshguard.pid
> 
> # Colon-separated blacklist threshold and full path to blacklist file.
> # (optional, no default)
> BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db
> 
> 
> On Sun, 30 Dec 2018, Kevin Zheng wrote:
> 
>> Hi Doug,
>>
>> I noticed that you're running two different versions of SSHGuard.
>>
>> In 1.5, the port you install determines how SSHGuard blocks attacks. In
>> 2.1, you need to specify the backend you use by yourself.
>>
>> SSHGuard uses blacklist.db to keep track of hosts it has blacklisted,
>> because with firewalls like pf and ipfw, SSHGuard removes all of its
>> blocks (including those that it has blacklisted) when it exits. While
>> it's running, everything in blacklist.db should also be in hosts.allow.
>>
>> When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells
>> SSHGuard what addresses to add back once it starts again.
>>
>> So, they're not redundant. Is that what you're asking?
>>
>> Regards,
>> Kevin
>>
>> On 12/30/18 2:39 PM, Doug Denault wrote:
>>> I am using sshguard with inet with FreeBSD jails. Having multiple
>>> [virtual] servers with differing blocking requirements this is really
>>> the only option. It appears to me that with the switch from BerkleyDB to
>>> a flat file that the blacklist is implemented by using the
>>> /etc/hosts.allow entries.
>>>
>>> Whether I am correct or not here is what happens on two systems:
>>>
>>>   host 1: sshguard-1.5_2
>>>      blacklist: 7,151 entries
>>>      hosts.allow: 30 lines; max of 270 IPs (9/line) with very little
>>> overlap
>>>
>>>   host 2: sshguard-2.1.0_1
>>>      blacklist: 3,251 lines
>>>      hosts.allow: 338 line; max of 3,042 entries
>>>
>>> first line in hosts.allow:
>>>   ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119
>>> 167.114.235.137 \
>>>         185.143.223.191 61.184.247.8 115.238.245.4 : DENY
>>>
>>> This entire line is in /var/db/sshguard/:
>>>
>>>   1544124029|100|4|218.92.1.141     December 6, 2018 7:20:29 PM
>>>   1544126972|100|4|121.22.80.117    December 6, 2018 8:09:32 PM
>>>   1544128387|100|4|118.25.63.24         |
>>>   1544130000|100|4|219.234.88.119       V
>>>   1544135312|100|4|167.114.235.137
>>>   1544135835|100|4|185.143.223.191
>>>   1544136112|100|4|61.184.247.8
>>>   1544137146|100|4|115.238.245.4    December 6, 2018 10:59:06
>>>
>>> Taking a random entry, say line 2,800 from blacklist:
>>>   1545136493|100|4|51.38.186.48     December 18, 2018 12:34:53 PM
>>>   1545136864|100|4|182.162.96.184
>>>   1545136941|100|4|212.88.123.198
>>>
>>> All three are in hosts.allow
>>>
>>> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be
>>> pruned? This is the better answer to me. Also as blacklist.db is a flat
>>> file I assume the epoch time is the time of the blacklisting and not the
>>> last reference.
>>>
>>>
>>>
>>> _____
>>> Douglas Denault
>>> http://www.safeport.com
>>> do...@sa...
>>> Voice: 301-217-9220
>>>   Fax: 301-217-9277
>>>
>>>
>>> _______________________________________________
>>> sshguard-users mailing list
>>> ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>>
>> -- 
>> Kevin Zheng
>> kev...@gm... | ke...@be... | PGP: 0xC22E1090
>>
> 
> _____
> Douglas Denault
> http://www.safeport.com
> do...@sa...
> Voice: 301-217-9220
>   Fax: 301-217-9277


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

Re: [SSHGuard-users] inet question

[Doug D. <do...@sa...>]

First, thanks for the quick replies. If I understand your response, that the 
blacklist entries must be retained in hosts.allow (hosts.deny is no longer used, 
at lease in FreeBSD), that is what I see. That the blacklist must be 
"duplicated" in hosts.allow is different from the version that used BerkeleyDB. 
I am not sure how blocking is done in the old version, but it works, and the 
blacklisted IPs are not in hosts.allow.

The way FreeBSD jails work, is that the guest hosts share the kernel with the 
base system. At the process level this is "virtually" invisible to running 
process. There are some commands that depend on kernel structures that do not 
work. Anyway the result of this is there can only be one IPFW as that is a 
kernel process. So inetd is the only choice using sshguard. I much prefer 
sshguard to fail2ban which is far too complex for my taste.

In the older version it may be that all blacklist entries are removed from 
hosts.allow as they normally time out and then a blacklisted IP is added back to 
hosts.allow on its first attempt. If the current system does not do that, I 
think that would be a nice addition. If using BerkleyDB makes that faster, that 
is both a small footprint tool and at least in FreeBSD, any server other than a 
stand-alone DNS server is likely to have that as a requirement. From a 
performance standpoint I think anything less than 10-20k entries in a flat file 
can be grep'd. In computer time it's centuries between ssh logins.

On Sun, 30 Dec 2018, Kevin Zheng wrote:

> Hi Doug,
>
> Then it might be a bug in the hosts backend. I assumed (incorrectly)
> that not many people were still using it, so it's been a while since
> I've taken a close look.
>
> Like the other backends, SSHGuard should remove the entries it added
> after it exits, and should re-add those that are blacklisted when it
> starts up again.
>
> So, just to be clear:
>
> blacklist.db is the list of addresses SSHGuard blacklisted. While
> SSHGuard is running, hosts.deny (or any other backend) should contain
> all of blacklist.db (so that blacklisted hosts are actually blocked) as
> well as additional hosts that get blocked while SSHGuard is running.
>
> Anything else is probably a bug; I'll take a look at how the hosts
> backend is doing.
>
> Regards,
> Kevin
>
> On 12/30/18 7:00 PM, Doug Denault wrote:
>> I've configured sshguard correctly to use inetd. On host 2 it blocks
>> 50k+ attempts/day. Configuration is straight forward enough. What I am
>> trying to say, apparently not very well, is the IPs blacklisted are
>> never removed from /etc/hosts.allow. In the older version of sshguard
>> blacklisted IPs do not appear in the hosts.allow file.
>>
>> Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated
>> in the blacklist file. Can a configuration error cause this behavior?
>>
>> I kinda assumed this was a bug, so my question was really, if I prune
>> the hosts.allow file will the blacklist entries be honored. The answer
>> to that is, I take from your email, yes.
>>
>> Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails
>> are not sandboxes. E.g., a process can not ascertain if it running in a
>> jail or natively. My config file:
>>
>> __________________sshguard.conf__________________
>> #!/bin/sh
>> # sshguard.conf -- SSHGuard configuration
>>
>> # Options that are uncommented in this example are set to their default
>> # values. Options without defaults are commented out.
>>
>> #### REQUIRED CONFIGURATION ####
>> # Full path to backend executable (required, no default)
>> BACKEND="/usr/local/libexec/sshg-fw-hosts"
>> #BACKEND="/usr/local/libexec/sshg-fw-ipfw"
>> #BACKEND="/usr/local/libexec/sshg-fw-pf"
>>
>> # Space-separated list of log files to monitor. (optional, no default)
>> FILES="/var/log/auth.log /var/log/maillog"
>>
>> # Shell command that provides logs on standard output. (optional, no
>> default)
>> # Example 1: ssh and sendmail from systemd journal:
>> #LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t
>> sendmail -o cat"
>> # Example 2: ssh from os_log (macOS 10.12+)
>> #LOGREADER="/usr/bin/log stream --style syslog --predicate
>> '(processImagePath contains \"sshd\")'"
>>
>> #### OPTIONS ####
>> # Block attackers when their cumulative attack score exceeds THRESHOLD.
>> # Most attacks have a score of 10. (optional, default 30)
>> THRESHOLD=30
>>
>> # Block attackers for initially BLOCK_TIME seconds after exceeding
>> THRESHOLD.
>> # Subsequent blocks increase by a factor of 1.5. (optional, default 120)
>> BLOCK_TIME=120
>>
>> # Remember potential attackers for up to DETECTION_TIME seconds before
>> # resetting their score. (optional, default 1800)
>> DETECTION_TIME=1800
>>
>> # Size of IPv6 'subnet to block. Defaults to a single address, CIDR
>> notation. (optional, default to 128)
>> #IPV6_SUBNET=128
>>
>> # Size of IPv4 subnet to block. Defaults to a single address, CIDR
>> notation. (optional, default to 32)
>> #IPV4_SUBNET=32
>>
>> #### EXTRAS ####
>> # !! Warning: These features may not work correctly with sandboxing. !!
>>
>> # Full path to PID file (optional, no default)
>> #PID_FILE=/var/run/sshguard.pid
>>
>> # Colon-separated blacklist threshold and full path to blacklist file.
>> # (optional, no default)
>> BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db
>>
>>
>> On Sun, 30 Dec 2018, Kevin Zheng wrote:
>>
>>> Hi Doug,
>>>
>>> I noticed that you're running two different versions of SSHGuard.
>>>
>>> In 1.5, the port you install determines how SSHGuard blocks attacks. In
>>> 2.1, you need to specify the backend you use by yourself.
>>>
>>> SSHGuard uses blacklist.db to keep track of hosts it has blacklisted,
>>> because with firewalls like pf and ipfw, SSHGuard removes all of its
>>> blocks (including those that it has blacklisted) when it exits. While
>>> it's running, everything in blacklist.db should also be in hosts.allow.
>>>
>>> When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells
>>> SSHGuard what addresses to add back once it starts again.
>>>
>>> So, they're not redundant. Is that what you're asking?
>>>
>>> Regards,
>>> Kevin
>>>
>>> On 12/30/18 2:39 PM, Doug Denault wrote:
>>>> I am using sshguard with inet with FreeBSD jails. Having multiple
>>>> [virtual] servers with differing blocking requirements this is really
>>>> the only option. It appears to me that with the switch from BerkleyDB to
>>>> a flat file that the blacklist is implemented by using the
>>>> /etc/hosts.allow entries.
>>>>
>>>> Whether I am correct or not here is what happens on two systems:
>>>>
>>>>   host 1: sshguard-1.5_2
>>>>      blacklist: 7,151 entries
>>>>      hosts.allow: 30 lines; max of 270 IPs (9/line) with very little
>>>> overlap
>>>>
>>>>   host 2: sshguard-2.1.0_1
>>>>      blacklist: 3,251 lines
>>>>      hosts.allow: 338 line; max of 3,042 entries
>>>>
>>>> first line in hosts.allow:
>>>>   ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119
>>>> 167.114.235.137 \
>>>>         185.143.223.191 61.184.247.8 115.238.245.4 : DENY
>>>>
>>>> This entire line is in /var/db/sshguard/:
>>>>
>>>>   1544124029|100|4|218.92.1.141     December 6, 2018 7:20:29 PM
>>>>   1544126972|100|4|121.22.80.117    December 6, 2018 8:09:32 PM
>>>>   1544128387|100|4|118.25.63.24         |
>>>>   1544130000|100|4|219.234.88.119       V
>>>>   1544135312|100|4|167.114.235.137
>>>>   1544135835|100|4|185.143.223.191
>>>>   1544136112|100|4|61.184.247.8
>>>>   1544137146|100|4|115.238.245.4    December 6, 2018 10:59:06
>>>>
>>>> Taking a random entry, say line 2,800 from blacklist:
>>>>   1545136493|100|4|51.38.186.48     December 18, 2018 12:34:53 PM
>>>>   1545136864|100|4|182.162.96.184
>>>>   1545136941|100|4|212.88.123.198
>>>>
>>>> All three are in hosts.allow
>>>>
>>>> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be
>>>> pruned? This is the better answer to me. Also as blacklist.db is a flat
>>>> file I assume the epoch time is the time of the blacklisting and not the
>>>> last reference.
>>>>
>>>>
>>>>
>>>> _____
>>>> Douglas Denault
>>>> http://www.safeport.com
>>>> do...@sa...
>>>> Voice: 301-217-9220
>>>>   Fax: 301-217-9277
>>>>
>>>>
>>>> _______________________________________________
>>>> sshguard-users mailing list
>>>> ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>
>>>
>>> -- 
>>> Kevin Zheng
>>> kev...@gm... | ke...@be... | PGP: 0xC22E1090
>>>
>>
>> _____
>> Douglas Denault
>> http://www.safeport.com
>> do...@sa...
>> Voice: 301-217-9220
>>   Fax: 301-217-9277
>
>
> -- 
> Kevin Zheng
> kev...@gm... | ke...@be... | PGP: 0xC22E1090
>

_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
   Fax: 301-217-9277