From: Richard J. <rjt...@sa...> - 2012-06-25 00:28:07
|
sshguard 1.5 is not recognizing messages in /var/log/authlog from sshd on an OpenBSD 4.9 or 5.1 system [1] as containing an attack signature. Apparently, it's been a problem since at least OpenBSD 4.8, per: http://sourceforge.net/mailarchive/forum.php?thread_name=AE3E9B9A-6376-4572-ACF9-128256676CD9%40sshguard.net&forum_name=sshguard-users Example messages in /var/log/authlog: Jun 9 21:46:07 green sshd[28212]: Failed password for invalid user staff from 122.70.128.5 port 35686 ssh2 Jun 9 21:46:07 green sshd[28212]: input_userauth_request: invalid user staff [preauth] Jun 9 21:46:09 green sshd[19052]: Failed password for invalid user sales from 122.70.128.5 port 37580 ssh2 Jun 9 21:46:09 green sshd[19052]: input_userauth_request: invalid user sales [preauth] Jun 9 21:46:11 green sshd[16201]: Failed password for invalid user recruit from 122.70.128.5 port 39886 ssh2 Jun 9 21:46:11 green sshd[16201]: input_userauth_request: invalid user recruit [preauth] Your attack pattern web docs say sshguard is looking for the form: Invalid user inexu from 6.6.6.0 and attack_patternsl.l indeed lists an insistence for uppercase 'I' on the word invalid: "Invalid user ".+" from" The quick patch here fixes the recognition problem if I do a direct paste of the truncated 'invalid user staff from 122.70.128.5' portion into sshguard when it is running in debug mode. --- src/parser/attack_scanner.l.orig Wed Feb 9 05:01:47 2011 +++ src/parser/attack_scanner.l Sun Jun 24 17:07:02 2012 @@ -128,6 +128,8 @@ /* SSH: invalid or rejected user (cross platform [generated by openssh]) */ "Invalid user ".+" from " { return SSH_INVALUSERPREF; } + /* SSH: invalid or rejected user (cross platform [generated by openssh]) */ +"invalid user ".+" from " { return SSH_INVALUSERPREF; } /* 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; } But that patch does not fix the recognition of the pattern within the longer lines when running 'sshguard -l /var/log/authlog'. It also does not fix recognition of even the truncated portion of the line mentioned above when it's appended to a separate log file and watched with 'sshguard -l /tmp/truncatedtest'. Still, am I at least heading in the right direction? Is there other parsing that is too specific to match those sshd authlog entries? Thanks! Richard ------- [1] sshd on OpenBSD 5.1: OpenSSH_6.0, OpenSSL 1.0.0f 4 Jan 2012 sshd on OpenBSD 4.9: OpenSSH_5.6, OpenSSL 0.9.8k25 Mar 2009 ------- PS - sourceforge mailing list subscription finally came through after I put the above info here as well: http://www.sshguard.net/support/submission/detail/37ce7e8f4d7cc1cf7af6/ |
From: Richard J. <rjt...@sa...> - 2012-06-25 03:17:14
|
On Sun, Jun 24, 2012 at 06:03:28PM -0600, Richard Johnson wrote: > But that patch does not fix the recognition of the pattern within the > longer lines when running 'sshguard -l /var/log/authlog'. This looks to be a timestamp issue rather than a more general parsing problem on the longer lines. When I feed the log messages a couple per second with accurate timestamps, sshguard picks up on the simulated brute forcing. It appears that the patch for allowing a lower case 'i' on 'invalid user' has given me a working sshguard for ssh brute forcing of nonexistent users on OpenBSD 5.1. Richard |
From: Henry Y. <henry@Aegis00.com> - 2012-06-25 04:21:47
|
On Sun, Jun 24, 2012 at 18:03:28PM -0600, Richard Johnson wrote: > The quick patch here fixes the recognition problem if I do a direct > paste of the truncated 'invalid user staff from 122.70.128.5' portion > into sshguard when it is running in debug mode. Instead of adding a separate lower-case pattern: "Invalid user ".+" from " "invalid user ".+" from " you should be able to specify a case-insensitive pattern: (?i:i)"nvalid user ".+" from " (This is from the linux documentation for "flex" (which is the flavor of "lex" used in many/most linux systems); I'd assume that you're unlikely to still be using the original "lex". I'm no expert at lex, by the way, but I've used the case-insensitve option successfully in my own custom patterns.) > But that patch does not fix the recognition of the pattern within the > longer lines when running 'sshguard -l /var/log/authlog'. > > It also does not fix recognition of even the truncated portion of the > line mentioned above when it's appended to a separate log file and > watched with 'sshguard -l /tmp/truncatedtest'. For that, I don't know... -- Henry Yen <Henry.Yen@Aegis00.com> Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) |