Re: [SSHGuard-users] Missed detections of ssh abuses

[Jonathan W. <jw...@at...>]

On Tue, Oct 25, 2016 at 11:04:42AM -0700, Kevin Zheng wrote:
> On 10/24/2016 17:05, Jonathan Woithe wrote:
> > In this case, sshguard evidently blocked 91.224.160.131 after 4 of the
> > "Failed password" messages, as I would expect.  What I can't work out is why
> > 91.224.160.131 was blocked while 212.129.60.203 was not, even though they
> > generated the same messages.  The only difference is that 91.224.160.131 had
> > the single failure around 6 hours before the main block, but this should not
> > make a difference.
> 
> It appears that SSHGuard is not recognizing any of the messages with
> "port NNNN" at the end.

I expect this is true.  However, there's still the "Failed password..."
messages, and these should be matched by the 

  Failed XYZ for XYZ from 6.6.6.0 port 14423 ssh2

rule, right?  There were plenty of these in the 212.129.60.203 messages, but
212.129.60.203 wasn't blocked.

The other issue is that in the later 91.224.160.131 case the same pattern
of messages was logged as was seen for 212.129.60.203, but 91.224.160.131
*was* correctly blocked.  That is, from 212.129.60.203 we got 9 groups of
the following form:

  Oct 24 05:52:47 sshd[5254]: Invalid user ubnt from 212.129.60.203 port 62676
  Oct 24 05:52:47 sshd[5254]: input_userauth_request: invalid user ubnt [preauth]
  Oct 24 05:52:48 sshd[5254]: Failed password for invalid user ubnt from 212.129.60.203 port 62676 ssh2

and yet 212.129.60.203 was not blocked.  When we got 5 groups of these:

  Oct 24 01:04:19 sshd[21389]: Invalid user admin from 91.224.160.131 port 34317
  Oct 24 01:04:19 sshd[21389]: input_userauth_request: invalid user admin [preauth]
  Oct 24 01:04:19 sshd[21389]: Failed password for invalid user admin from 91.224.160.131 port 34317 ssh2

then 91.224.160.131 was blocked.  These are exactly the same message
patterns and yet sshguard seemed to treat them differently for some reason.

The only practical difference between the two cases that I can see is the
presence of "last message repeated" lines in between the 91.224.160.131
messages and a couple of 121.18.238.114 messages within the 212.129.60.203
messages.  I can't see how either of these could actively prevent the block
being activated.

> > [1] For example, the "Invalid user inexu from 6.6.6.0" rule would not detect
> > the "Invalid user guest from 212.129.60.203 port 52019" entries because our
> > ssh logs the port number on the end of the rule.  This rule might require
> > "arbitrary text" to be added to the end to allow for this.
> 
> I think this is the solution.

It will certainly allow sshguard to act on the "Invalid user" messages.  As
above though, I can't see why this would be needed since sshguard should
still be acting on the "Failed password" messages in both cases, not just
one of them.

I presume this will require something along the lines of the patch at the
end of this message.

Regards
  jonathan

--- a/sshguard-1.7.0/src/parser/attack_parser.y	2016-10-26 09:28:32.071665939 +1030
+++ b/sshguard-1.7.0/src/parser/attack_parser.y	2016-10-26 09:22:42.997004608 +1030
@@ -69,7 +69,7 @@
 /* flat tokens */
 %token SYSLOG_BANNER TIMESTAMP_SYSLOG TIMESTAMP_ISO8601 TIMESTAMP_TAI64 AT_TIMESTAMP_TAI64 METALOG_BANNER SOCKLOG_BANNER
 /* ssh */
-%token SSH_INVALUSERPREF SSH_NOTALLOWEDPREF SSH_NOTALLOWEDSUFF
+%token SSH_INVALUSERPREF SSH_INVALDUSERSUFF SSH_NOTALLOWEDPREF SSH_NOTALLOWEDSUFF
 %token SSH_LOGINERR_PREF SSH_LOGINERR_SUFF SSH_LOGINERR_PAM
 %token SSH_VIA
 %token SSH_NOIDENTIFSTR SSH_BADPROTOCOLIDENTIF SSH_BADPROTOCOLIDENTIF_SUFF
@@ -219,7 +219,7 @@
 
 ssh_illegaluser:
     /* nonexistent user */
-    SSH_INVALUSERPREF addr
+    SSH_INVALUSERPREF addr SSH_INVALDUSERSUFF
     /* existent, unallowed user */
     | SSH_NOTALLOWEDPREF addr SSH_NOTALLOWEDSUFF
     ;
--- a/sshguard-1.7.0/src/parser/attack_scanner.l	2016-10-26 09:28:16.783513172 +1030
+++ b/sshguard-1.7.0/src/parser/attack_scanner.l	2016-10-26 09:24:22.852473989 +1030
@@ -38,7 +38,7 @@
 
  /* Start Conditions */
  /* for Login services */
-%s ssh_notallowed ssh_loginerr ssh_reversemap ssh_disconnect ssh_badproto ssh_badkex
+%s ssh_invaliduser ssh_notallowed ssh_loginerr ssh_reversemap ssh_disconnect ssh_badproto ssh_badkex
  /* for Mail services */
 %s dovecot_loginerr cyrusimap_loginerr exim_esmtp_autherr sendmail_relaydenied sendmail_authfailure sendmail_noissue postfix_loginerr
  /* for FTP services */
@@ -123,7 +123,8 @@
 
 
  /* SSH: invalid or rejected user (cross platform [generated by openssh]) */
-[Ii]"nvalid user ".+" from "                                    { return SSH_INVALUSERPREF; }
+[Ii]"nvalid user ".+" from "                                    { BEGIN(ssh_invaliduser); return SSH_INVALUSERPREF; }
+<ssh_invaliduser>.*                                             { BEGIN(INITIAL); return SSH_INVALDUSERSUFF; }
  /* match disallowed user (not in AllowUsers/AllowGroups or in DenyUsers/DenyGroups) on Linux Ubuntu/FreeBSD */
  /* "User tinydns from 1.2.3.4 not allowed because not listed in AllowUsers" */
 "User ".+" from "                                               { BEGIN(ssh_notallowed); return SSH_NOTALLOWEDPREF; }