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

Re: [SSHGuard-users] SSHGuard to fetch and ban Roundcube Webmail login attacks?

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

Thank you for your reports and for filing the bugs on the Bitbucket 
tracker. If you don't mind, I'll respond to those on the tracker.

Regards,
Kevin

[SSHGuard-users] SSHGuard not capturing Dovecot's failed login lines?

[Özgür K. <ozg...@gm...>]

Hello there.

OS: OpenBSD 7.3
SSHGuard: 2.4.2

Sshguard runs ok with Sshd and Postfix, however not with Dovecot.

The following lines are not getting captured in /var/log/maillog file;

Jun 30 01:38:41 mail dovecot: auth-worker(85069): conn
unix:auth-worker (pid=88192,uid=518): auth-worker<1>:
sql(in...@my...,41.22.15.12,<bLCwXEz/5apY7KF/>): Password mismatch
Jun 30 01:38:49 mail dovecot: auth-worker(85069): conn
unix:auth-worker (pid=88192,uid=518): auth-worker<2>:
sql(in...@my...,41.22.15.12,<bLCwXEz/5apY7KF/>): Password mismatch
Jun 30 01:38:52 mail dovecot: auth-worker(85069): conn
unix:auth-worker (pid=88192,uid=518): auth-worker<3>:
sql(in...@my...,41.22.15.12,<XbMaXUz/CqRY7KF/>): Password mismatch
Jun 30 01:38:57 mail dovecot: auth-worker(85069): conn
unix:auth-worker (pid=88192,uid=518): auth-worker<4>:
sql(in...@my...,41.22.15.12,<bLCwXEz/5apY7KF/>): Password mismatch
Jun 30 01:39:00 mail dovecot: auth-worker(85069): conn
unix:auth-worker (pid=88192,uid=518): auth-worker<5>:
sql(in...@my...,41.22.15.12,<XbMaXUz/CqRY7KF/>): Password mismatch

‌(I tried to create failed login attempts above through wrong
passwords by using Outlook client)

P.S.: My sshguard.conf file contains; FILES="/var/log/authlog /var/log/maillog”

Any ideas would be much appreciated, many thanks!

[SSHGuard-users] SSHGuard to fetch and ban Roundcube Webmail login attacks?

[Özgür K. <ozg...@gm...>]

Hello there. First of all, thanks a lot for such a great security tool!

I’m using sshguard-2.4.2 on OpenBSD 7.3, so far, it recognizes sshd
logins, and also contents of the maillog file.

Additionally, I’d really like to add Roundcube Webmail’s login log
file as well, but I don’t really know how to do that.

My sshguard.conf file has currently;

“FILES="/var/log/authlog /var/log/maillog” line, and I tried to make it like;

FILES="/var/log/authlog /var/log/maillog /var/www/logs/roundcube/userlogins.log"

But that didn’t work, SSHGuard doesn’t see failed attempts within the
userlogins.log file.

Here’s the content of userlogins.log file (for both Successful login
and Failed login samples);

[28-Jun-2023 21:31:37 +0300]: <8olvcata> Successful login for
in...@my... (ID: 1) from 85.106.175.13 in session 8olvcataaln1drt7
[29-Jun-2023 10:29:34 +0300]: <4qrhf5r9> Successful login for
in...@my... (ID: 1) from 88.236.173.109 in session
4qrhf5r9m826g04q
[29-Jun-2023 10:42:35 +0300]: <kvhe82m4> Failed login for
te...@my... from 88.236.173.109 in session kvhe82m46sdgbq0r
(error: 0)
[29-Jun-2023 10:42:42 +0300]: <kvhe82m4> Failed login for
te...@my... from 88.236.173.109 in session kvhe82m46sdgbq0r
(error: -2)

As both successful and failed login lines are single lines, I think
SSHGuard could fetch them easily.

Could you kindly please let me know how to do that?

Many thanks in advance!

Re: [SSHGuard-users] OpenSMTPd lexer/parser broken

[B. A. G. <gro...@tc...>]

Kevin,

Thanks for the quick turn around. I've taken a closer look at the filter 
API, and I'm unsure about how exactly y'alls might want to proceed 
there. sshguard is fundamentally a "pull" type service gathering data 
from sources, whereas the smtpd filter API is a "push" type, where smtpd 
executes a long-running filter executable and pushes data to it, 
potentially expecting a response.

At a minimum, a plug will be needed that smtpd can execute, which would 
then place that data into a logfile or fifo that sshguard can read. (I 
think a fifo would be perfect for this, since no retention is needed for 
the data we want, as it would already be logged in maillog).

Since we have to have a separate plug executable, we come to the 
question of where one actually wants to do the parsing. It seems to me 
that it would be simpler to have the plug do the primary parsing via 
something like libopensmtpd rather than implement the full parser in 
sshguard. The plug would just output a simplified format added to the 
sshguard parser, e.g. "timestamp smtpd found-attack hostname.hostdomain 
127.0.0.1".

As for the actual API events in which sshguard would be interested, the 
following would seem to be the most likely candidates:

- link-connect: this contains among other information, a pass/fail 
variable on forward-confirmed reverse DNS. It is recommended by most to 
require FCrDNS to allow the connection to an MX to proceed, so it is 
reasonable to see a failure here as an attack indicator.

-link-auth: this event contains two variables, the username used for an 
authentication attempt, and a pass/fail/error. pass and error to be 
ignored, but fail should be seen as a possible attack.

In theory, one could also use filter-report/filter-response to monitor 
output from other filters, such-as filter-rspamd, so you could handle 
spam messages as an indicator as well, but that seems more than a little 
ambitious for the moment.

Overall, I don't see this as being particularly difficult to get 
working, but it certainly raises the complexity. Instead of allowing 
sshguard to simply do its job, this requires the user to also configure 
smtpd to assist in that matter. Having looked at the requirements for 
this, I'm not entirely convinced that it's something that should be 
done; the prudent action may simply be to update the documentation to 
say "OpenSMTPd support for version <=x.x", and move on.

Hope this helps,
B

Re: [SSHGuard-users] OpenSMTPd lexer/parser broken

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

Hi there,

On 4/1/23 2:15 AM, B. Atticus Grobe via sshguard-users wrote:
> The lexer/parser for OpenSMTPd in sshguard is rather broken. It doesn't 
> seem to recognize anything at all from /var/log/maillog. I have verified 
> this using `/usr/local/libexec/sshg-parser -a' as mentioned in the man 
> pages.
> 
> This is all on OpenBSD 7.2 with the up-to-date syspatches and packages, 
> with sshguard being reported as v2.4.2, although I have confirmed that 
> even with HEAD the issue remains.

This is because OpenSMTPD changed their logging format since we first 
added them, and we haven't updated our attack signatures since.

Part of the reason why we've been slow to update the attack signature is 
that the log output is now split across two lines. SSHGuard's parser 
understands "one line, one attack."

OpenSMTPD developers have also expressed that we should be using the 
smtpd-filters API: https://man.openbsd.org/smtpd-filters.7

This is supposed to offer a stable output format. I haven't taken a look 
yet, but may do so soon. If you're able to look at this as a head start 
and write back with what it might take for SSHGuard to support this, 
please do let me know.

Thanks for reporting and for the log examples.

Regards,
Kevin

[SSHGuard-users] OpenSMTPd lexer/parser broken

[B. A. G. <gro...@tc...>]

Gents and Ladies,

The lexer/parser for OpenSMTPd in sshguard is rather broken. It doesn't 
seem to recognize anything at all from /var/log/maillog. I have verified 
this using `/usr/local/libexec/sshg-parser -a' as mentioned in the man 
pages.

This is all on OpenBSD 7.2 with the up-to-date syspatches and packages, 
with sshguard being reported as v2.4.2, although I have confirmed that 
even with HEAD the issue remains.

I'm making a partially anonymized maillog available to aid in debugging. 
The anonymization consists only of completely removing lines, no 
mangling. Everything remaining is exactly as OpenSMTPd wrote it. The log 
can be found at https://tcp80.org/maillog

I appreciate all the work y'alls have put into this, and it does work 
quite nicely with OpenSSHd, which helps cut down on issues.

Thanks,
B

[SSHGuard-users] SSHGuard issues on Bitbucket temporarily made private

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

Hi there,

Unfortunately, it seems that there are bots going around posting spam 
issues on Bitbucket issue trackers, and SSHGuard has been affected.

To prevent new spam issues from being created, I've temporarily set the 
Bitbucket issue tracker to "private". Hopefully, I will be able to set 
it back to "public" in a few days once the spam has stopped.

If anyone is aware of a way to set more fine-grained permissions on the 
tracker (e.g. anyone can view, only approved users can create) please 
let me know.

In the meantime, if you need to view/add an issue to the tracker, please 
write me directly with your Bitbucket username so that I can give you 
access.

Sorry for the inconvenience.

Regards,
Kevin

Re: [SSHGuard-users] about sshguard and FreeBSD

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

Hi Jack,

On 2/12/23 1:48 AM, jack keradec wrote:
> As a Linux/Debian I already use sshguard w/ nftables.
> But now I want to use sshguard on FreeBSD. Any advice ? Which firewall
> do you use ? (pf, ipfw ??)

SSHGuard supports both ipfw and pf on FreeBSD.

Whichever firewall you choose to use, follow the setup instructions in 
the sshguard-setup(7) manual page.

The FreeBSD handbook has a section on firewalls for FreeBSD:

https://docs.freebsd.org/en/books/handbook/firewalls/

ipfw is native to FreeBSD and best supported. pf has some useful 
macroing features for its configuration file. Which firewall you choose 
depends on your use case and whatever you prefer. I have a few boxes 
with pf and a few boxes with ipfw :)

Good luck,
Kevin

Re: [SSHGuard-users] about sshguard and FreeBSD

[Peter B. <be...@an...>]

I use pf, works well, no issues.

Curious why others prefer ipfw over pf.

On Sun, 12 Feb 2023, jack keradec wrote:

> Hi
> As a Linux/Debian I already use sshguard w/ nftables.
> But now I want to use sshguard on FreeBSD. Any advice ? Which firewall
> do you use ? (pf, ipfw ??)
> TYA
> --
> cmic retired sysadmin.
>

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
be...@an...                                https://www.angryox.com/
---------------------------------------------------------------------------

Re: [SSHGuard-users] about sshguard and FreeBSD

[Ted H. <te...@io...>]

On Sun, 12 Feb 2023, Christos Chatzaras wrote:
> 
>
>       As a Linux/Debian I already use sshguard w/ nftables.
>
>       But now I want to use sshguard on FreeBSD. Any advice ? Which firewall
> do you use ? (pf, ipfw ??)
> 
> 
> I prefer ipfw. 
> 
>

Definitely ipfw.  I've had good luck with it on my systems.

https://docs.freebsd.org/en/books/handbook/firewalls/#firewalls-ipfw

Ted

Re: [SSHGuard-users] about sshguard and FreeBSD

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

> As a Linux/Debian I already use sshguard w/ nftables.
> But now I want to use sshguard on FreeBSD. Any advice ? Which firewall
> do you use ? (pf, ipfw ??)

I prefer ipfw. 

[SSHGuard-users] about sshguard and FreeBSD

[jack k. <cm...@li...>]

Hi
As a Linux/Debian I already use sshguard w/ nftables.
But now I want to use sshguard on FreeBSD. Any advice ? Which firewall
do you use ? (pf, ipfw ??)
TYA
--
cmic retired sysadmin.

Re: [SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

On 2022/10/15 01:50, Kevin Zheng wrote:
> I believe this is accurate.
> 
> SSHGuard normally forgets about attackers when they stop attacking for
> some time (-s detection_time). When an attacker is first added to the
> blacklist (i.e. not a blacklisted address loaded from a file), SSHGuard
> will not forget the attacker.

That's what I thought, although I'm, not sure what we are seeing is
fully down to that.

A reported, we have -s 1220 (seconds) but clearly SSHGuard has
rememebred the "attacks" over a 100 day period, even though the
IP address HAS NOT been added to the blacklist, or rather it has
but then it's been removed, after 1200 seconds.

What seems to be happening here is that ~100 days ago, enough of
an "attack" to cause a temporary block happens, but then the user
remembers how to type their passowrd and the block gets removed,
howver, some 100 days later, during which time the user got
temporarily blocked for a second time, they "attack" us again,
and so get the "three strikes and you're out" permanent block.

> This means that if you manually remove the blocked address from your
> firewall and the address makes another attack, you'll get this message.
> 
> While this is slightly surprising, is there any behavior that needs to
> be changed?

I'd suggest "yes" but only because once you see a "three strikes since
SSHGuard started" permanent block, but realise you want to allow it, you
can either restart SSHGuard, without it in the blacklist, in which case
it takes a while to read the desired blacklist in, or remove the blacklist
entry and the firewall rule for the IP address, but have that IP address
recorded as being at the three strikes level, within SSHGuard..

It'd be "nice" to be able to remove a "known good, but known to mistype
over a long period" entry from a long-running SSHGuard's internal counters
  
Note that it's not the same as adding the "known good, but known to mistype
ocassionally over a long period" entry, to the whitelist.

> It also sounds like what some want is a way to remember attacks across
> SSHGuard reboots, while not blacklisting attackers permanently? Or, at
> least release blacklisted addresses while SSHGuard is running?

The latter would be useful but I'm not sure one needs the former capability,
although perhaps the ability to write out a companion ot the blacklist, that
details IP addresses with one or two "strikes" against them might also be
useful.

I seem to recall though that "poking" individual IP addresses into a
running SSHGuard has been the subject of discussion in the past, and it
was c;lear that it was feasible?

> An experimental branch ('sqlite') exists that persists SSHGuard's
> attackers across reboots.

Nice one: will certainly take a look at that.

Re: [SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

On 10/13/22 7:17 PM, Kevin Buckley wrote:
> It sounds as though the fact that we haven't restarted SSHGuard
> in some time, but merely removed "erroneous" entries from the
> blacklist DB, and removed the IPTables rule, so as to permit an
> IP address access again, will see SSHGuard storing deatils about
> the IP address from "way back when".

I believe this is accurate.

SSHGuard normally forgets about attackers when they stop attacking for 
some time (-s detection_time). When an attacker is first added to the 
blacklist (i.e. not a blacklisted address loaded from a file), SSHGuard 
will not forget the attacker.

This means that if you manually remove the blocked address from your 
firewall and the address makes another attack, you'll get this message.

While this is slightly surprising, is there any behavior that needs to 
be changed?

It also sounds like what some want is a way to remember attacks across 
SSHGuard reboots, while not blacklisting attackers permanently? Or, at 
least release blacklisted addresses while SSHGuard is running?

An experimental branch ('sqlite') exists that persists SSHGuard's 
attackers across reboots.

Regards,
Kevin

Re: [SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

Le Fri, 14 Oct 2022 10:17:14 +0800,
Kevin Buckley <kev...@gm...> a écrit :

> On 2022/10/14 03:27, kaycee gb wrote:
> > 
> > It may be related to an "issue" I had with blacklisted addresses. In my
> > workflow, I unblacklist/free addresses after some time from firewall.
> > Initially I had problems to make it work correctly because SSHGuard do not
> > releases IP's counters for blocked IP's (temporarily or forever). I think I
> > talked about that here some time ago.  
> 
> Cheers for the pointer: I have now found that thread.
> 
> It sounds as though the fact that we haven't restarted SSHGuard
> in some time, but merely removed "erroneous" entries from the
> blacklist DB, and removed the IPTables rule, so as to permit an
> IP address access again, will see SSHGuard storing deatils about
> the IP address from "way back when".

Ok, so you seem to remove entries from firewall too. It was my first impression
but I was not sure. 

> 
> Basically then, we can ignore the
> 
> "after 3 abuses over 9652777 secs",
> 
> part, as it has nothing to do with the application of the block,
> which has resulted from the
> 
> "4 attacks in 6 secs"
> 
> monitoring ?
> 
> 
I am not sure it can be ignored. I mean it depends on what you are looking for.
For me it was not acceptable for what I wanted to do. For others, if the way
SSHGuard works without mods/patches is ok, it may be ignored. 

If you restart SSHguard, this counter is reseted IIRC, but restarting was a
problem for me because when you restart you lose attacks history and I wanted
to keep it. 

Re: [SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

On 2022/10/14 03:27, kaycee gb wrote:
> 
> It may be related to an "issue" I had with blacklisted addresses. In my
> workflow, I unblacklist/free addresses after some time from firewall. Initially
> I had problems to make it work correctly because SSHGuard do not releases IP's
> counters for blocked IP's (temporarily or forever). I think I talked about that
> here some time ago.

Cheers for the pointer: I have now found that thread.

It sounds as though the fact that we haven't restarted SSHGuard
in some time, but merely removed "erroneous" entries from the
blacklist DB, and removed the IPTables rule, so as to permit an
IP address access again, will see SSHGuard storing deatils about
the IP address from "way back when".

Basically then, we can ignore the

"after 3 abuses over 9652777 secs",

part, as it has nothing to do with the application of the block,
which has resulted from the

"4 attacks in 6 secs"

monitoring ?

Re: [SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

Le Thu, 13 Oct 2022 15:41:12 +0800,
Kevin Buckley <kev...@gm...> a écrit :

> If what our logs are telling us is correct, we have recenty seen
> an IP address blacklisted as follows
> 
> Blocking "IP.AD.RE.SS/32" forever \
>   (4 attacks in 6 secs, after 3 abuses over 9652777 secs.)
> 
> I was slightly surprised to see that 3 abuses timespan of
> 111-or-so DAYS, given we are invoking SSHGuard with
> 
>    -a 40
>    -p 420
>    -s 1200
>    -b 100:/path/to/blacklist
> 
> Given that invocation, what's likely to be remembering an
> IP address for 9652777 seconds ?
> 
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Hi,

It may be related to an "issue" I had with blacklisted addresses. In my
workflow, I unblacklist/free addresses after some time from firewall. Initially
I had problems to make it work correctly because SSHGuard do not releases IP's
counters for blocked IP's (temporarily or forever). I think I talked about that
here some time ago. 

IIRC there are 2 tables in SSHGuard. One for attacks count and one for
blocking. I do not have the exact names now. Attacks count is reseted, not the
other, so blocking count is held and increasing forever and it may result in
what you see I think. 

K.

[SSHGuard-users] Retention time of attacks leading to blocks - measured in days ?

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

If what our logs are telling us is correct, we have recenty seen
an IP address blacklisted as follows

Blocking "IP.AD.RE.SS/32" forever \
  (4 attacks in 6 secs, after 3 abuses over 9652777 secs.)

I was slightly surprised to see that 3 abuses timespan of
111-or-so DAYS, given we are invoking SSHGuard with

   -a 40
   -p 420
   -s 1200
   -b 100:/path/to/blacklist

Given that invocation, what's likely to be remembering an
IP address for 9652777 seconds ?

Re: [SSHGuard-users] CIDR addresses in blacklist

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

On 2022/07/02 01:15, Kevin Zheng wrote:
> Hi Andrew,
> 
> Thanks for reporting the issue. After taking a look, it seems that the
> whitelist parser needs to be taught about parsing CIDR.

You mean the blacklist parser?

> The relevant functions are whitelist_add(), whitelist_add_ipv4() and
> whitelist_add_ipv6() in src/blocker/sshguard_whitelist.c, if you want to
> try to take a look before I (hopefully eventually) get around to it.
> 
> Regards,
> Kevin

Wanted ask a question about the blocking logic here, as I think it adds
to the discussion of the question Andrew (my colleague) raises, as regards
"ranges" in the blacklist file not being handled in the same way (indeed,
make that: not being handled at all!) as ranges in the whitelist file.

So, when SSHGuard sees a range specified in the whitelist, does it keep
the range within its memory, so that it does checking against the ranges,
or does it populate its memory with every individual IP address within
a range?

In the case of the blacklist though, where it adds new permanently blocked
entries, both into the backed firewall and onto its blacklist files, it will
clearly only ever operate on a single IP address at a time, because it's
only ever interactively blocking one address (or, if you like a /32) at a
time.

As was seen with issues in loading blacklist entries into a FirewallD backend,
where it appears to take a long time, compared to say IPTables, to add a large
number of individual entries from the SSHGuard blackist, SSHGuard will still
treat "threat activty", from any blacklisted addresses that it hasn't seen yet,
as normal, so if they are "unsophisticated" attacks, they'll still get blocked.

Furthermore, if one was to whitelist an individual IP address from a blacklisted
range, what DROPs would end up being placed into the backend firewall, ahead of
the "ALLOW sshd port traffic rule" entry?

In the way I think of it, SSHGuard doesn't add "jump past the blacklisted DROps
to the "ALLOW sshd port traffic rule" entries, but in order to not have to
split the blacklist ranges to handle a whitelisted IP address, it might have
to do something like that ?

Similarly, if it "sees" a whitelist file entry that is from within a blackist
file range, should it not then rewrite the blackist file, so that it matches
the DROP rules within the backend firewall?

Another Kevin

Re: [SSHGuard-users] CIDR addresses in blacklist

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

Hi Andrew,

Thanks for reporting the issue. After taking a look, it seems that the 
whitelist parser needs to be taught about parsing CIDR.

The relevant functions are whitelist_add(), whitelist_add_ipv4() and 
whitelist_add_ipv6() in src/blocker/sshguard_whitelist.c, if you want to 
try to take a look before I (hopefully eventually) get around to it.

Regards,
Kevin

[SSHGuard-users] CIDR addresses in blacklist

[Andrew E. <and...@gm...>]

Hi Folks,

Given that our blacklist is now ... large, I'd like to consolidate and
expand the blocking to larger ranges than just a single /32 (or
whatever we've defined for IPV4_SUBNET=)
however merely altering the blacklist to include this fails rather spectacularly

ie a blacklist consisting of

1656637200|100|4|2.184.0.0/19   # AS 58224 - TCI, IR
1656637200|100|4|5.113.160.0/20   # AS 44244 - IRANCELL-AS, IR

throws the following error

iptables v1.4.21: host/network `2.184.0.0/19' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `5.113.160.0/20' not found
Try `iptables -h' or 'iptables --help' for more information.

which when using the null firewall becomes obvious why

sshguard[17076]: Now monitoring attacks.
===>>> Initializing (null) firewall
===>>> Blocking 2.184.0.0/19/32 (null)
===>>> Blocking 5.113.160.0/20/32 (null)

so - is it possible to alter the blacklist handling to one of:
* handle a second (fixed) blacklist file - one that's probably been
hand-curated from existing blocks / threat alerts (and pass these to
$BACKEND to block directly)
* be more CIDR aware - by all means save an entry in $BLACKLIST_FILE
with the default subnet size, but be prepared to read something else
back
* something else?

Because I'm working on blocking entire prefixes, I need something more
dynamic than the hard-coded config values for $IPVx_SUBNET

Many thanks

Andrew

[SSHGuard-users] flush & reload?

[Pierre-Philipp B. <pb...@ne...>]

Hello,

I wonder what is the recommended practice to deal with both 
nftables.conf vs sshguard rules, so when ever I need to reload the 
former with a `flush`, the latter comes back right away.

For not I just restart sshguard after I flush & reload the nftables 
rules as follows.

nft -f /etc/nftables.conf # starts with flush ruleset
pkill sshguard
/usr/local/sbin/sshguard -i /var/run/sshguard.pid >> 
/var/log/sshguard.log 2>&1 &

but I am all ears if there's a better way to do it, as this is a bit 
painful to operate.

Thank you

BR
-- 
Pierre-Philipp Braun
SMTP Health Campaign: enforce STARTTLS and verify MX certificates
<https://nethence.com/smtp/>

Re: [SSHGuard-users] A Regular Expression Attack Parser Addition/Replacement For SSHGuard

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

Hi All,

There was a documentation bug in the example regex configuration
files: The macro "<IPV_ANY_ADDR>" was mistakenly documented as
"<IPV_ALL_ADDR>".

It has been corrected as of the tarball published just now and noted
in the ChangeLog.

Sorry about that.

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>.

[SSHGuard-users] A Regular Expression Attack Parser Addition/Replacement For SSHGuard

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

Hi All,

I have created a regular expression attack parser
addition/replacement for sshguard.  It can be built to use either
POSIX regexps or PCREs.

(For PCRE builds you'll need either libpcreposix or libpcre,
depending upon whether you specify USE_PCRE or USE_NATIVE_PCRE,
respectively, along with their "-dev" packages.)

It can either be pretty-easily integrated directly into sshguard or,
as of sshguard-2.4.2, replace the stock parser w/o any changes to
sshguard's code.

But NOTE: The example regex config files do NOT contain all the
signatures the stock sshguards do, and contain a couple I added that
1.7.0 did not have.

It can be found here: https://jimsun.linxnet.com/atre_parser.html

Current state is pretty raw.  There's no "configure" stuff.  The only
thing it's been built and run upon are Linux boxen.  There's no
installer.  Docs are kind of hit-or-miss.  In short: If you're not
code-savvy, this is probably not for you at this time.

I have it integrated directly into my running instances of
sshguard-1.7.0, as a follow-up check to the stock parsing engine, but
I haven't done anything with 2.4.2, yet.

That being said: "make" (with edits) *should* build a stand-alone
parser for you that can be dropped right in as a replacement for the
stock parser in 2.4.2.  (At lease if you're using Linux.)

For the stand-alone replacement parser for 2.4.2, which is also the
test/debug utility, see the atre-parser_doc.txt file at
https://jimsun.linxnet.com/downloads/atre/atre-parser_doc.txt

As always, with this kind of stuff: Use at your own discretion and
risk.

Let me know what y'all think.  Questions, comments, and suggestions
are welcome.

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] "Stale" and "Pardon" Times

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

On Wed, 23 Mar 2022 10:18:54 -0700
Kevin Zheng <kev...@gm...> wrote:

> On 3/15/22 10:41 AM, Jim Seymour wrote:
> > Perhaps there should be a subsequent test, after the options are
> > all processed, to make sure pardon > stale and issue a warning if
> > not? Perhaps also automatically bump pardon by, say, 120 seconds
> > over stale if that happens?  
> 
> Do you mean that the stale time should be longer than the pardon
> time, not the other way around?

Nope :)

Because, as I noted: If stale time > pardon time and their attack
rate interval is longer than pardon time, then they'll get however
many bites of the apple they get until pardon time eventually
increases far enough.

E.g.:

    Initial pardon time: 840 sec.
    Stale time: 1200 sec.
    Attack interval: 1000 sec.

They trigger a block.  It's put in place for ~840 sec., then released.
±160 sec. later they strike again.  Then, after three more hits
(assuming default dangerousness: 10, and accumulated dangerousness
is reset when the block is released [another assumption on my part]),
they get blocked for 1680 sec.  *Then*, only after another four shots
at the target, are they actually blocked.

> 
> For context, "pardon time" in the code refers to what is called 
> "blocktime" in the man page, which is:
> 
[snip]
> 
> And "stale time" in the code is the "detection_time":
> 
[snip]
> 
> So if stale < pardon, each time an attacker gets blocked, it would
> be considered it's first time (because the attacker would have been 
> forgotten by the stale threshold).

Ah.  My bad.  I'd *assumed* "stale" wouldn't get reset until "stale
time" after a block was removed.

Doing so would solve both problems, no?

Unless I'm misunderstanding how these times are used and I'm
completely off in the weeds  :)

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>.