Menu
▾
▴
sshguard-users
|
From: Barry M. <bmu...@ga...> - 2015-02-02 19:06:30
|
sshd is producing the following in my system.log:
Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication
error for root from 115.239.228.9 via 10.0.1.100
sshguard is not recognizing the threat (debug output below).
If I submit the following, the attack is recognized:
Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication
error for root from 115.239.228.9
(please note "Error: popping nterm text ()" at the end of parser output...)
Ideas, anyone??
######################
# BEGIN DEBUG OUTPUT
######################
Feb 2 13:45:59 crackfox.local sshd[8027]: error: PAM: authentication error
for root from 115.239.228.9 via 10.0.1.100
Starting parse
Entering state 0
Reading a token: --accepting rule at line 110 ("Feb 2 13:45:59
crackfox.local sshd[8027]: ")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 146 ("error: PAM: authentication
error for root from ")
Next token is token SSH_LOGINERR_PAM ()
Shifting token SSH_LOGINERR_PAM ()
Entering state 9
Reading a token: --accepting rule at line 201 ("115.239.228.9")
Next token is token IPv4 ()
Shifting token IPv4 ()
Entering state 50
Reducing stack by rule 23 (line 203):
$1 = token IPv4 ()
-> $$ = nterm addr ()
Stack now 0 1 9
Entering state 56
Reducing stack by rule 34 (line 279):
$1 = token SSH_LOGINERR_PAM ()
$2 = nterm addr ()
-> $$ = nterm ssh_authfail ()
Stack now 0 1
Entering state 32
Reducing stack by rule 27 (line 264):
$1 = nterm ssh_authfail ()
-> $$ = nterm sshmsg ()
Stack now 0 1
Entering state 30
Reducing stack by rule 11 (line 169):
$1 = nterm sshmsg ()
-> $$ = nterm msg_single ()
Stack now 0 1
Entering state 28
Reducing stack by rule 9 (line 163):
$1 = nterm msg_single ()
-> $$ = nterm logmsg ()
Stack now 0 1
Entering state 46
Reducing stack by rule 5 (line 138):
$1 = token SYSLOG_BANNER_PID ()
$2 = nterm logmsg ()
-> $$ = nterm syslogent ()
Stack now 0
Entering state 24
Reducing stack by rule 1 (line 122):
$1 = nterm syslogent ()
-> $$ = nterm text ()
Stack now 0
Entering state 23
Reading a token: --accepting rule at line 221 (" ")
--accepting rule at line 220 ("via")
Next token is token WORD ()
Error: popping nterm text ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0
|
|
From: Bradley G. <pi...@ma...> - 2015-02-02 19:44:43
Attachments:
signature.asc
|
On Feb 2, 2015, at 11:05 AM, Barry Muldrey <bmu...@ga...> wrote: > sshd is producing the following in my system.log: > > Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 via 10.0.1.100 > > sshguard is not recognizing the threat (debug output below). > If I submit the following, the attack is recognized: > > Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 > > (please note "Error: popping nterm text ()" at the end of parser output...) > > Ideas, anyone?? I'm seeing the same thing. No answer but your not alone. Regards, Bradley Giesbrecht (pixilla) |
|
From: Willem J. W. <wj...@di...> - 2015-02-02 20:21:16
|
On 2-2-2015 20:44, Bradley Giesbrecht wrote: > On Feb 2, 2015, at 11:05 AM, Barry Muldrey <bmu...@ga...> wrote: > >> sshd is producing the following in my system.log: >> >> Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 via 10.0.1.100 >> >> sshguard is not recognizing the threat (debug output below). >> If I submit the following, the attack is recognized: >> >> Feb 2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 >> >> (please note "Error: popping nterm text ()" at the end of parser output...) >> >> Ideas, anyone?? > > I'm seeing the same thing. No answer but your not alone. > > Regards, > Bradley Giesbrecht (pixilla) The parsing trace tells you that it accepts the ipnr as ipnr, but then then next word is unexpected in the grammar. So the via 10.0.1.100 is creating a "syntax error" This is inherent to the way the syntax rules are build. And the syntax rules are only modifiable at compile time. And need to be written 101% matching, otherwise the line will be skipped. I'm still not very shure if this is really a desired concept for logfile parsing. E.g. openssh changes its log format, and "all of a sudden" log output is no longer generating desired reactions. It requires "flexible" ways of specifying scanner and parser input, which is not really a trivial thing. --WjW |
|
From: Barry M. <bmu...@ga...> - 2015-02-02 20:53:26
|
>
> found this (line 146) in "attack_scanner.l":
/* wrong password for valid user @ FreeBSD, Debian */
"error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user
")?.+" from " { return SSH_LOGINERR_PAM; }
which seems to be the appropriate pattern...
is there a quick way I can add to that pattern to keep it from spazzing out
when it gets the "via xx.xx.xx.xx" ????
|
|
From: Kevin Z. <kev...@gm...> - 2015-02-03 00:48:06
|
Hi Barry,
On 02/02/2015 14:52, Barry Muldrey wrote:
> /* wrong password for valid user @ FreeBSD, Debian */
> "error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user
> ")?.+" from " { return SSH_LOGINERR_PAM; }
>
> which seems to be the appropriate pattern...
Not quite. You're looking at the lexer, which is responsible for
retrieving separable tokens. To add "via", you are interested in
'attack_parser.y', in particular these lines:
ssh_authfail:
SSH_LOGINERR_PREF addr SSH_LOGINERR_SUFF
| SSH_LOGINERR_PAM addr
;
The solution is to add a new lexer token along the lines of
SSH_OPT_ADDR_SUFFIX and append this to this yacc rule.
This should not be difficult, but isn't exactly trivial either.
Hopefully I'll get around to this soon.
Thanks,
Kevin Zheng
--
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
|
|
From: Barry M. <bmu...@ga...> - 2015-02-03 00:52:50
|
Thanks, Kevin. I'll continue to poke around
...and monitor this thread for news
On Mon, Feb 2, 2015 at 7:47 PM, Kevin Zheng <kev...@gm...> wrote:
> Hi Barry,
>
> On 02/02/2015 14:52, Barry Muldrey wrote:
> > /* wrong password for valid user @ FreeBSD, Debian */
> > "error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user
> > ")?.+" from " { return SSH_LOGINERR_PAM; }
> >
> > which seems to be the appropriate pattern...
>
> Not quite. You're looking at the lexer, which is responsible for
> retrieving separable tokens. To add "via", you are interested in
> 'attack_parser.y', in particular these lines:
>
> ssh_authfail:
> SSH_LOGINERR_PREF addr SSH_LOGINERR_SUFF
> | SSH_LOGINERR_PAM addr
> ;
>
> The solution is to add a new lexer token along the lines of
> SSH_OPT_ADDR_SUFFIX and append this to this yacc rule.
>
> This should not be difficult, but isn't exactly trivial either.
> Hopefully I'll get around to this soon.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
|
|
From: Barry M. <bmu...@ga...> - 2015-02-03 00:59:44
|
Does anyone know who's responsible for printing the "...via 10.0.1.100" in the syslog message? I presume it's there to tell me which interface the attack came in on (for multiple LAN interface machines)? Easiest work-around would be to turn off this portion of the message; I've tried various LogLevels and SyslogFacilities in sshd_config to no avail... thoughts? _-_-_-_-_-_-_-_-_-_-_-_- Barry John Muldrey Jr. Doctoral Student and Graduate Researcher, Georgia Institute of Technology www.barrymuldrey.com +1 (504) 975-7971 689 Berne St SE, Apt C Atlanta, GA 30312-3529 USA On Mon, Feb 2, 2015 at 7:52 PM, Barry Muldrey <bmu...@ga...> wrote: > Thanks, Kevin. I'll continue to poke around > ...and monitor this thread for news > > > On Mon, Feb 2, 2015 at 7:47 PM, Kevin Zheng <kev...@gm...> wrote: > >> Hi Barry, >> >> On 02/02/2015 14:52, Barry Muldrey wrote: >> > /* wrong password for valid user @ FreeBSD, Debian */ >> > "error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user >> > ")?.+" from " { return SSH_LOGINERR_PAM; } >> > >> > which seems to be the appropriate pattern... >> >> Not quite. You're looking at the lexer, which is responsible for >> retrieving separable tokens. To add "via", you are interested in >> 'attack_parser.y', in particular these lines: >> >> ssh_authfail: >> SSH_LOGINERR_PREF addr SSH_LOGINERR_SUFF >> | SSH_LOGINERR_PAM addr >> ; >> >> The solution is to add a new lexer token along the lines of >> SSH_OPT_ADDR_SUFFIX and append this to this yacc rule. >> >> This should not be difficult, but isn't exactly trivial either. >> Hopefully I'll get around to this soon. >> >> Thanks, >> Kevin Zheng >> >> -- >> Kevin Zheng >> kev...@gm... | ke...@kd... | PGP: 0xC22E1090 >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users >> > > |
|
From: Kevin Z. <kev...@gm...> - 2015-02-03 00:42:11
|
On 02/02/2015 14:20, Willem Jan Withagen wrote: > The parsing trace tells you that it accepts the ipnr as ipnr, but then > then next word is unexpected in the grammar. > So the via 10.0.1.100 is creating a "syntax error" > > This is inherent to the way the syntax rules are build. > And the syntax rules are only modifiable at compile time. > And need to be written 101% matching, otherwise the line will be skipped. Willem's analysis is correct. The solution is to add rules to parse the "via" message correctly. I'll get around to this eventually, but anyone is welcome to submit a patch here as well. > I'm still not very shure if this is really a desired concept for logfile > parsing. E.g. openssh changes its log format, and "all of a sudden" log > output is no longer generating desired reactions. > > It requires "flexible" ways of specifying scanner and parser input, > which is not really a trivial thing. This is a tricky issue. Several other (non-SSHGuard) log parsers have had significant "log-injection" vulnerabilities due to weak regular expressions or inadequate sanity checking. SSHGuard's decision has generally been to enforce strong rules, since the alternative is somewhat risky (i.e. root compromise). Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2015-02-03 01:22:38
Attachments:
patch-via.diff
|
Hi Barry, On 02/02/2015 18:59, Barry Muldrey wrote: > Does anyone know who's responsible for printing the "...via 10.0.1.100" > in the syslog message? > I presume it's there to tell me which interface the attack came in on > (for multiple LAN interface machines)? > Easiest work-around would be to turn off this portion of the message; > I've tried various LogLevels and SyslogFacilities in sshd_config to no > avail... You (and other people) are invited to test the attached patch. Let me know how it works! Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Bradley G. <pi...@ma...> - 2015-02-03 02:12:02
Attachments:
signature.asc
|
On Feb 2, 2015, at 5:22 PM, Kevin Zheng <kev...@gm...> wrote: > Hi Barry, > > On 02/02/2015 18:59, Barry Muldrey wrote: >> Does anyone know who's responsible for printing the "...via 10.0.1.100" >> in the syslog message? >> I presume it's there to tell me which interface the attack came in on >> (for multiple LAN interface machines)? >> Easiest work-around would be to turn off this portion of the message; >> I've tried various LogLevels and SyslogFacilities in sshd_config to no >> avail... > > You (and other people) are invited to test the attached patch. > > Let me know how it works! No errors here but have not been able to confirm correctness though it looks good. Regards, Bradley Giesbrecht (pixilla) |
|
From: Bradley G. <pi...@ma...> - 2015-02-03 06:14:53
Attachments:
signature.asc
|
On Feb 2, 2015, at 6:11 PM, Bradley Giesbrecht <pi...@ma...> wrote: > > On Feb 2, 2015, at 5:22 PM, Kevin Zheng <kev...@gm...> wrote: > >> Hi Barry, >> >> On 02/02/2015 18:59, Barry Muldrey wrote: >>> Does anyone know who's responsible for printing the "...via 10.0.1.100" >>> in the syslog message? >>> I presume it's there to tell me which interface the attack came in on >>> (for multiple LAN interface machines)? >>> Easiest work-around would be to turn off this portion of the message; >>> I've tried various LogLevels and SyslogFacilities in sshd_config to no >>> avail... >> >> You (and other people) are invited to test the attached patch. >> >> Let me know how it works! > > No errors here but have not been able to confirm correctness though it looks good. Works here. With patch, running sshguard with SSHGUARD_DEBUG matches attacks previously ignored. Regards, Bradley Giesbrecht (pixilla) |
|
From: Barry M. <bmu...@ga...> - 2015-02-03 14:40:10
|
Works! Thanks Kevin, for the super rapid response! -Barry On Tue, Feb 3, 2015 at 1:14 AM, Bradley Giesbrecht <pi...@ma...> wrote: > > On Feb 2, 2015, at 6:11 PM, Bradley Giesbrecht <pi...@ma...> > wrote: > > > > > On Feb 2, 2015, at 5:22 PM, Kevin Zheng <kev...@gm...> wrote: > > > >> Hi Barry, > >> > >> On 02/02/2015 18:59, Barry Muldrey wrote: > >>> Does anyone know who's responsible for printing the "...via 10.0.1.100" > >>> in the syslog message? > >>> I presume it's there to tell me which interface the attack came in on > >>> (for multiple LAN interface machines)? > >>> Easiest work-around would be to turn off this portion of the message; > >>> I've tried various LogLevels and SyslogFacilities in sshd_config to no > >>> avail... > >> > >> You (and other people) are invited to test the attached patch. > >> > >> Let me know how it works! > > > > No errors here but have not been able to confirm correctness though it > looks good. > > Works here. With patch, running sshguard with SSHGUARD_DEBUG matches > attacks previously ignored. > > > Regards, > Bradley Giesbrecht (pixilla) > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > > |
Thanks for helping keep SourceForge clean.
X