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

Re: [SSHGuard-users] patch with parser for Proxmox VE auth failures

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

Hi, thank you both.

Best regards,
Jos

Kevin Zheng:
> Hi Christoph,
>
> Thanks for the patch. Happy to include this attack signature for 
> Proxmox VE in SSHGuard.
>
> I'm glad you found the documentation useful.
>
> I made a small adjustment to your patch. In attack_scanner.l the 
> attack signatures for the "unknown user" case overlap with those for 
> the known user, so everything still works when I remove the two lines 
> for the unknown user case.
>
> I've committed this and this will be available in the next release.
>
> Thanks again for your contribution!

Re: [SSHGuard-users] patch with parser for Proxmox VE auth failures

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

Hi Christoph,

Thanks for the patch. Happy to include this attack signature for Proxmox 
VE in SSHGuard.

I'm glad you found the documentation useful.

I made a small adjustment to your patch. In attack_scanner.l the attack 
signatures for the "unknown user" case overlap with those for the known 
user, so everything still works when I remove the two lines for the 
unknown user case.

I've committed this and this will be available in the next release.

Thanks again for your contribution!

Thanks,
Kevin

[SSHGuard-users] patch with parser for Proxmox VE auth failures

[<de...@kl...>]

Dear all,

please find attached a parser for evaluating authentication failure from pvedaemon, a major part of Proxmox Virtual Environment. (https://proxmox.com/en/proxmox-virtual-environment/overview)

This parser ist based upon information in the Proxmox wiki
(parser & jail for Fail2Ban) as well as some real-world
auth errors I've generated myself. :)

Additionally, I've attached the logs from running make check.
Hopefully this all will be of some use for you.

Notes on myself : I'm working as full-time sysadmin and we are evaluating using Proxmox at work. In private I'm using Proxmox since about 1.5 years. As I myself prefer sshguard over Fail2Ban due to it being way faster and for me easier to  understand and implement.
The instruction on how to contribute on the website is quite well thus I've decided to try to add this parser myself. Quite surprised it went that well at all. Nevertheless please bear with me it's my very first patch file ever.

kind regards
Christoph

----------------------------------------
>From 50bdd556f457bc42a1112d844a9b186ec4412881 Mon Sep 17 00:00:00 2001
From: chrkli <de...@kl...>
Date: Sun, 5 May 2024 03:18:08 +0200
Subject: [PATCH] add parser for Proxmox VE

based on information found on Proxmox wiki in regard to Fail2Ban, see
https://pve.proxmox.com/wiki/Fail2ban#Filter_Config
note: only parses messages from pvedaemon, does NOT consider additionally
thrown auth_pam error when using realm "PAM" inside Proxmox VE webapp
---
src/common/attack.h         |  1 +
src/common/service_names.c  |  1 +
src/parser/attack_parser.y  |  8 ++++++++
src/parser/attack_scanner.l | 10 +++++++++-
src/parser/tests.txt        | 16 ++++++++++++++++
5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/src/common/attack.h b/src/common/attack.h
index e7e4896..d19945c 100644
--- a/src/common/attack.h
+++ b/src/common/attack.h
@@ -50,6 +50,7 @@ enum service {
     SERVICES_OPENVPN_PS     = 410,  //< OpenVPN Portshare
     SERVICES_GITEA          = 500,  //< Gitea
     SERVICES_MSSQL          = 600,  //< Microsoft SQL Server for Linux
+    SERVICES_PROXMOXVE      = 700,  //< Proxmox VE
};

/* an attack (source address & target service info) */
diff --git a/src/common/service_names.c b/src/common/service_names.c
index bbc4d69..174c57c 100644
--- a/src/common/service_names.c
+++ b/src/common/service_names.c
@@ -29,6 +29,7 @@ static const struct service_s services[] = {
     {SERVICES_GITEA, "Gitea"},
     {SERVICES_OPENVPN_PS, "OpenVPN Portshare"},
     {SERVICES_MSSQL, "MSSQL"},
+    {SERVICES_PROXMOXVE, "Proxmox VE"},
};

const char *service_to_name(enum service code) {
diff --git a/src/parser/attack_parser.y b/src/parser/attack_parser.y
index 601d81c..d632ac9 100644
--- a/src/parser/attack_parser.y
+++ b/src/parser/attack_parser.y
@@ -119,6 +119,8 @@ static void yyerror(attack_t *, const char *);
%token OPENVPN_PS_TERM_SUFF
/* MSSQL */
%token MSSQL_AUTHFAIL_PREF
+/* Proxmox VE */
+%token PROXMOXVE_AUTHFAIL_PREF PROXMOXVE_AUTHFAIL_SUFF

%%

@@ -195,6 +197,7 @@ msg_single:
   | giteamsg          { attack->service = SERVICES_GITEA; }
   | openvpnpsmsg      { attack->service = SERVICES_OPENVPN_PS; }
   | sqlservrmsg       { attack->service = SERVICES_MSSQL; }
+  | proxmoxvemsg      { attack->service = SERVICES_PROXMOXVE; }
   ;

/* an address */
@@ -390,6 +393,11 @@ openvpnpsmsg:
   | OPENVPN_PS_TERM_PREF '[' addr ']' OPENVPN_PS_TERM_SUFF
   ;

+ /* attack rules for Proxmox VE */
+proxmoxvemsg:
+    PROXMOXVE_AUTHFAIL_PREF addr PROXMOXVE_AUTHFAIL_SUFF
+  ;
+
%%

static void yyerror(__attribute__((unused)) attack_t *a,
diff --git a/src/parser/attack_scanner.l b/src/parser/attack_scanner.l
index a7c2a33..c7a4913 100644
--- a/src/parser/attack_scanner.l
+++ b/src/parser/attack_scanner.l
@@ -37,7 +37,7 @@ static int getsyslogpid(char *syslogbanner, int length);

  /* Start Conditions */
  /* for Login services */
-%s ssh_notallowed ssh_reversemap ssh_disconnect ssh_badproto ssh_invalid_format ssh_badkex cockpit_authfail
+%s ssh_notallowed ssh_reversemap ssh_disconnect ssh_badproto ssh_invalid_format ssh_badkex cockpit_authfail proxmoxve_authfail
  /* for SSHGuard */
%s sshguard_attack sshguard_block
%s bind
@@ -344,6 +344,14 @@ HTTP_LOGIN_200OK_BAD       .*({WORDPRESS_LOGIN}|{TYPO3_LOGIN}|{CONTAO_LOGIN}).*
"Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. [CLIENT: " { return MSSQL_AUTHFAIL_PREF; }
"Length specified in network packet payload did not match number of bytes read; the connection has been closed. Please contact the vendor of the client library. [CLIENT: " { return MSSQL_AUTHFAIL_PREF; }

+ /* Proxmox VE */
+ /* failed authentication */
+"authentication failure; rhost="  { BEGIN(proxmoxve_authfail); return PROXMOXVE_AUTHFAIL_PREF; }
+<proxmoxve_authfail>" "+"user=".+" "+"msg=".+                        { BEGIN(INITIAL); return PROXMOXVE_AUTHFAIL_SUFF; }
+ /* unknown internal user */
+"authentication failure; rhost="  { BEGIN(proxmoxve_authfail); return PROXMOXVE_AUTHFAIL_PREF; }
+<proxmoxve_authfail>" "+"user=".+" "+"msg=no such user ('".+"')"     { BEGIN(INITIAL); return PROXMOXVE_AUTHFAIL_SUFF; }
+
  /**         COMMON-USE TOKENS       do not touch these          **/
  /* an IPv4 address */
{IPV4}                                                          { yylval.str = yytext; return IPv4; }
diff --git a/src/parser/tests.txt b/src/parser/tests.txt
index bd610fe..4ee143c 100644
--- a/src/parser/tests.txt
+++ b/src/parser/tests.txt
@@ -597,3 +597,19 @@ M
600 198.199.105.106 4 10
M

+#### Proxmox VE
+May 04 23:45:19 deb12-pve pvedaemon[2352]: authentication failure; rhost=::ffff:192.0.2.74 user=tester@pve msg=Authentication failure
+700 192.0.2.74 4 10
+M
+May 05 00:11:56 deb12-pve pvedaemon[2350]: authentication failure; rhost=2001:0DB8:72a:1936:2d49:83ed:d49a:6ffd user=root@pam msg=Authentication failure
+700 2001:0DB8:72a:1936:2d49:83ed:d49a:6ffd 6 10
+M
+May 05 00:07:09 deb12-pve pvedaemon[2351]: authentication failure; rhost=::ffff:192.0.2.154 user=tester2@pam msg=no such user ('tester2@pam')
+700 192.0.2.154 4 10
+M
+May 05 00:08:19 deb12-pve pvedaemon[2352]: authentication failure; rhost=::ffff:192.0.2.7 user=tester3@pve msg=no such user ('tester3@pve')
+700 192.0.2.7 4 10
+M
+May 05 00:12:11 deb12-pve pvedaemon[2352]: authentication failure; rhost=2001:0DB8:72a:1936:2d49:83ed:d49a:6ffd user=root@pve msg=no such user ('root@pve')
+700 2001:0DB8:72a:1936:2d49:83ed:d49a:6ffd 6 10
+M
-- 
2.45.0

Re: [SSHGuard-users] Latest update check

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

Kevin Zheng:
> I'm still troubleshooting the issue. As I mentioned, I'm a bit 
> confused why pkg is reporting this as an issue since libcap_net is 
> part of the FreeBSD base system.
>
> As long as SSHGuard appears to be working with you, I don't think this 
> issue is very serious. You can double check that you have libcap_net 
> located at that path, which you probably do because it's part of the 
> base system.

As far as I can check SSHGuard works ok.
Just checked FreeBSD 13.2-RELEASE-p4 and found the following casper 
related files:

/lib/casper
/lib/casper/libcap_dns.so.2
/lib/casper/libcap_fileargs.so.1
/lib/casper/libcap_grp.so.1
/lib/casper/libcap_net.so.1
/lib/casper/libcap_pwd.so.1
/lib/casper/libcap_sysctl.so.2
/lib/casper/libcap_syslog.so.1
/lib/libcasper.so.1

/usr/include/casper
/usr/include/casper/cap_dns.h
/usr/include/casper/cap_fileargs.h
/usr/include/casper/cap_grp.h
/usr/include/casper/cap_net.h
/usr/include/casper/cap_pwd.h
/usr/include/casper/cap_sysctl.h
/usr/include/casper/cap_syslog.h
/usr/include/libcasper.h
/usr/include/libcasper_service.h

/usr/lib/libcasper.so

/usr/local/lib/perl5/site_perl/mach/5.36/libcasper.ph
/usr/local/lib/perl5/site_perl/mach/5.36/libcasper_service.ph

/usr/share/man/man3/caph_enter_casper.3.gz
/usr/share/man/man3/libcasper.3.gz
/usr/share/man/man3/libcasper_service.3.gz

/usr/tests/lib/libcasper
/usr/tests/lib/libcasper/services
/usr/tests/lib/libcasper/services/cap_dns
/usr/tests/lib/libcasper/services/cap_grp
/usr/tests/lib/libcasper/services/cap_pwd
/usr/tests/lib/libcasper/services/cap_sysctl

Best, Jos

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

Re: [SSHGuard-users] Latest update check

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

Hi Jos,

On 11/11/23 12:43 PM, Jos Chrispijn wrote:
>> I've managed to reproduce the issue and will be investigating.
>> libcap_net.so.1 is typically provided by the base system, located e.g. 
>> at /lib/casper/libcap_net.so.1
> 
> Next week I will upgrade FreeBSD to v14-p5
> Might be that the libcap is added. Can you add it in the next sshguard 
> version or should I report this to BSD maintainer(s)?

I'm still troubleshooting the issue. As I mentioned, I'm a bit confused 
why pkg is reporting this as an issue since libcap_net is part of the 
FreeBSD base system.

As long as SSHGuard appears to be working with you, I don't think this 
issue is very serious. You can double check that you have libcap_net 
located at that path, which you probably do because it's part of the 
base system.

I'll let you know what I find.

Regards,
Kevin

Re: [SSHGuard-users] Latest update check

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

Hi Kevin,
> Thanks for the report. This looks like a FreeBSD-specific issue 
> related to the latest release, which updated the Capsicum-sandboxed 
> DNS lookup to use libcasper.
>
> I've managed to reproduce the issue and will be investigating.
> libcap_net.so.1 is typically provided by the base system, located e.g. 
> at /lib/casper/libcap_net.so.1

Next week I will upgrade FreeBSD to v14-p5
Might be that the libcap is added. Can you add it in the next sshguard 
version or should I report this to BSD maintainer(s)?

Thanks
Jos

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

Re: [SSHGuard-users] Latest update check

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

Hi Jos.

On 11/8/23 7:07 AM, Jos Chrispijn via sshguard-users wrote:
> After the update of sshguard, I noticed this while running
> 
> # pkg check -Bdsr
> 
> (sshguard-2.4.3,1) /usr/local/libexec/sshg-blocker - required shared 
> library libcap_net.so.1 not found
> (sshguard-2.4.3,1) /usr/local/libexec/sshg-fw-hosts - required shared 
> library libcap_net.so.1 not found
> (sshguard-2.4.3,1) /usr/local/libexec/sshg-parser - required shared 
> library libcap_net.so.1 not found
> 
> Can you tell me if this is just due to the upgrade or should these 
> libraries have been updated during that upgrade?

Thanks for the report. This looks like a FreeBSD-specific issue related 
to the latest release, which updated the Capsicum-sandboxed DNS lookup 
to use libcasper.

I've managed to reproduce the issue and will be investigating.

libcap_net.so.1 is typically provided by the base system, located e.g. 
at /lib/casper/libcap_net.so.1

Regards,
Kevin

[SSHGuard-users] Latest update check

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

After the update of sshguard, I noticed this while running

# pkg check -Bdsr

(sshguard-2.4.3,1) /usr/local/libexec/sshg-blocker - required shared 
library libcap_net.so.1 not found
(sshguard-2.4.3,1) /usr/local/libexec/sshg-fw-hosts - required shared 
library libcap_net.so.1 not found
(sshguard-2.4.3,1) /usr/local/libexec/sshg-parser - required shared 
library libcap_net.so.1 not found

Can you tell me if this is just due to the upgrade or should these 
libraries have been updated during that upgrade?

Best, Jos


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

[SSHGuard-users] Alert latest update

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

Dear All,

After the update of sshguard, I noticed this while running

# pkg check -Bdsr

(sshguard-2.4.3,1) /usr/local/libexec/sshg-blocker - required shared 
library libcap_net.so.1 not found
(sshguard-2.4.3,1) /usr/local/libexec/sshg-fw-hosts - required shared 
library libcap_net.so.1 not found
(sshguard-2.4.3,1) /usr/local/libexec/sshg-parser - required shared 
library libcap_net.so.1 not found

Can you tell me if this is just due to the upgrade or should these 
libraries have been updated during that upgrade?

thanks for your comment,
Jos

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

[SSHGuard-users] SSHGuard 2.4.3 release announcement

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

Dear SSHGuard users,

SSHGuard 2.4.3 is now available on SourceForge:

https://sourceforge.net/projects/sshguard/files/sshguard/2.4.3/

This release adds and updates some attack signatures and corrects a 
whitelisting bug on 32-bit x86 and DNS resolution inside the FreeBSD 
capability sandbox.

If you are not impacted by either bug, and do not require the updated 
signatures, then this update is optional.

Added

- Add signature for BIND
- Add signature for Gitea
- Add signature for Microsoft SQL Server for Linux
- Add signature for OpenVPN Portshare
- Add signature for user-defined HTTP attacks
- Update signatures for Dovecot
- Update signatures for Postfix

Fixed

- Fix memset off-by-one (whitelisting on 32-bit x86)
- Resolve DNS names in capability mode using casper (FreeBSD)

Regards,
Kevin

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

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

On 2023/06/30 17:04, Özgür Kazancci wrote:
> 
> The following lines are not getting captured in /var/log/maillog file;
> ...
> 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!
> 

Are you able to checkout the SSHGuard source from the Git repo

    https://bitbucket.org/sshguard/sshguard.git

or otherwise access the source code?

If so, take a look at the file

   src/parser/attack_scanner.l

to see the format of the strings that are being looked for, eg:


/* get this instead: match invalid login @ Linux Ubuntu */
  /* "Failed password for validuser from 1.2.3.4 port 54609 ssh2" */
"Failed "[^ ]+" for "[^ ]+" from "                              { return SSH_LOGINERR_PREF; }

and where the current entry targetting Dovecot seems to be:

  /* dovecot */
("(libdovecot."[0-9\.]+".dylib) ")?(imap|pop3|submission)"-login: ""Info: "?("Aborted login"|Disconnected).*" (auth failed, "{NUMBER}" attempts".*"): ".+" rip=" { BEGIN(dovecot_loginerr); return DOVECOT_IMAP_LOGINERR_PREF; }
<dovecot_loginerr>", lip=".+                                        { BEGIN(INITIAL); return DOVECOT_IMAP_LOGINERR_SUFF; }

That might help you to construct an attack signature that matches
what you would like to trap.

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