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

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

[SSHGuard-users] Repeated "has already been blocked" Messages Still A Thing?

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

Hi All,

Are the repeated "<whatever> has already been blocked" messages (was
"<whatever> should already have been blocked" in prior versions) still
a thing in recent versions of sshguard?

I know it was once discussed.  Can't find when or where.

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] Enhancement Idea: Add Logging "Verbosity" Command-Line Option?

[Michel M. <cm...@li...>]

Out of topiv

Le 23 mars 2022 18:46:34 GMT+01:00, Jim Seymour <jse...@Li...> a
>
>*sigh*  Y'know, I've been installing, configuring, administering,
>maintaining, and using various flavors of *nix for about 35 years,
>and I did not know that! <smh>

Ah ah ! Neither me, after 26 years sysadmining solaris, hpux, irix, 
.. 

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

Re: [SSHGuard-users] Enhancement Idea: Add Logging "Verbosity" Command-Line Option?

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

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

> On 3/15/22 11:18 AM, Jim Seymour wrote:
[snip]
> 
> If you want to watch multiple log files from one terminal, remember
> that you can pass multiple files to 'tail -f'. For example:
> 
> $ tail -f /var/log/auth.log /var/log/maillog

*sigh*  Y'know, I've been installing, configuring, administering,
maintaining, and using various flavors of *nix for about 35 years,
and I did not know that! <smh>

> 
[snip]
> 
> Would sshg-logtail | sshg-parser -a (in annotate mode) be closer to
> what you are looking for?

I do not know.  I'll look into it.

> 
> (What exactly are you trying to see? Which attacks that SSHGuard
> would have detected in real time?)

In the development/debug of the regexp code I'm working on: To see
each individual attack detection as it happens.  E.g. (from my code):

    sshguard[31417]: parse_line_re(): detected: service name:
     "postfix", service: 260, ip addr: "80.82.77.33", ip_type: 4

(I need to add "dangerousness" to 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>.

Re: [SSHGuard-users] Enhancement Idea: Add Logging "Verbosity" Command-Line Option?

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

On 3/15/22 11:18 AM, Jim Seymour wrote:
> I can "tail -f <logfile> |grep yadda-yadda-yadda" to see what's logged
> to auth.log, but, if sshguard is watching multiple logs that doesn't
> show me all I want to see w/o opening multiple windows and tailing
> multiple logfiles.

If you want to watch multiple log files from one terminal, remember that 
you can pass multiple files to 'tail -f'. For example:

$ tail -f /var/log/auth.log /var/log/maillog

Alternatively, you can run the sshg-logtail script installed in libexec, 
which is a wrapper around the different ways that you invoke tail on 
different operating systems.

> So I'm thinking:
> 
>      . Change the "version" command line switch from "-v" to "-V",
>        and...
> 
>      . Make "-v" a "verbose" switch to cause sshguard to emit more
>        information to wherever it's logging.  Info such as:
> 
>        sshguard: Detected: service name: "postfix", service: 260,
>         ip addr: 192.168.1.2, ip_type: 4, dangerousness: 10
> 
> Maybe make "-v" take a verbosity level argument?

Improvements that would make it easier to see what SSHGuard is doing are 
certainly welcome.

Would sshg-logtail | sshg-parser -a (in annotate mode) be closer to what 
you are looking for?

(What exactly are you trying to see? Which attacks that SSHGuard would 
have detected in real time?)

Regards,
Kevin

Re: [SSHGuard-users] "Stale" and "Pardon" Times

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

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?

For context, "pardon time" in the code refers to what is called 
"blocktime" in the man page, which is:

>               Block first-time attackers for blocktime seconds. Subsequent
>               blocks increase in duration by a factor of 1.5. Since sshguard
>               unblocks attackers at random intervals, actual block times may
>               be somewhat longer.

And "stale time" in the code is the "detection_time":

>               Reset an attacker's attack score after detection_time seconds
>               since the last attack. This means that attackers who attack
>               every detection_time seconds are never blocked by sshguard.
>               However, an increased detection_time may have an impact on
>               legitimate users.

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

Regards,
Kevin

[SSHGuard-users] Enhancement Idea: Add Logging "Verbosity" Command-Line Option?

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

Hi Again,

Doing some experimental coding on sshguard and watching for effects
in real-time, I've run into something of an inconvenience.

I can "tail -f <logfile> |grep yadda-yadda-yadda" to see what's logged
to auth.log, but, if sshguard is watching multiple logs that doesn't
show me all I want to see w/o opening multiple windows and tailing
multiple logfiles.

So I'm thinking:

    . Change the "version" command line switch from "-v" to "-V",
      and...

    . Make "-v" a "verbose" switch to cause sshguard to emit more
      information to wherever it's logging.  Info such as:

      sshguard: Detected: service name: "postfix", service: 260,
       ip addr: 192.168.1.2, ip_type: 4, dangerousness: 10

Maybe make "-v" take a verbosity level argument?

What think y'all?

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