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

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

[Richard J. <rjt...@sa...>]

On Sun, Feb 15, 2015 at 09:29:28PM -0600, Kevin Zheng wrote:
> Doesn't the default SIGHUP handler terminate the process?

Per signal(3) man page, the SIGHUP default when SIG_DFL is requested is
process termination.  My naive understanding is that SIG_DFL has to be
specifically requested in a signal() call, however.

Not specifying SIGHUP in any signal() call might as a side effect set the
signal mask to block SIGHUP.  But my experience here is way back in time,
so I'm not sure any more.

What I see in practice is SIGHUP having no effect (presumably at boot, but
very definitely when sent manually) after I remove the signal() call
setting its handler.

Hmm, for the nonce, it might be better to explicitly set the handler to
SIG_IGN than just leave it out.  I still want to understand why the SIGHUP
is being sent, and then perhaps see about not sending it if that makes
sense.


Richard

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

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

Hi Richard,

Thanks for looking into this issue.

On 02/15/2015 20:12, Richard Johnson wrote:
> sshguard.c includes SIGHUP in its signals upon which to terminate.
> 
> The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently
> comes with a HUP.  Sheer guessing here, but this may be because sshguard
> has the log file open at the time an initial newsyslog run occurs.

I'm running FreeBSD, but I don't start SSHGuard using 'rc.d' since I'm
starting a development version manually every boot.

I'm not sure why SIGHUP is being sent. I'll look around...

> Here's a quick workaround that'll hopefully hold me until there's more time
> for reading code and figuring out how to avoid HUPing sshguard at boot
> time.  It effectively ignores SIGHUP.  Confirmed that on OpenBSD 5.6 stable
> sshguard is still shut down cleanly at reboot time, as well as stops and
> starts fine via /etc/rc.d/sshguard stop|start|restart.
> 
> =======
> --- src/sshguard.c.orig	Wed Feb  9 05:01:47 2011
> +++ src/sshguard.c	Sun Feb 15 18:30:59 2015
> @@ -200,7 +200,6 @@
>  
>      /* termination signals */
>      signal(SIGTERM, sigfin_handler);
> -    signal(SIGHUP, sigfin_handler);
>      signal(SIGINT, sigfin_handler);
>  
>      /* load blacklisted addresses and block them (if requested) */

Doesn't the default SIGHUP handler terminate the process?

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

[Richard J. <rjt...@sa...>]

On Sun, Feb 15, 2015 at 05:19:51PM -0700, Richard Johnson wrote:
> On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon
> start at boot time.  Typical log entries:
> 
> Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
> Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting...
> 
> And sshguard is indeed no longer running.  A later manual start of sshguard
> succeeds.

sshguard.c includes SIGHUP in its signals upon which to terminate.

The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently
comes with a HUP.  Sheer guessing here, but this may be because sshguard
has the log file open at the time an initial newsyslog run occurs.

Here's a quick workaround that'll hopefully hold me until there's more time
for reading code and figuring out how to avoid HUPing sshguard at boot
time.  It effectively ignores SIGHUP.  Confirmed that on OpenBSD 5.6 stable
sshguard is still shut down cleanly at reboot time, as well as stops and
starts fine via /etc/rc.d/sshguard stop|start|restart.

=======
--- src/sshguard.c.orig	Wed Feb  9 05:01:47 2011
+++ src/sshguard.c	Sun Feb 15 18:30:59 2015
@@ -200,7 +200,6 @@
 
     /* termination signals */
     signal(SIGTERM, sigfin_handler);
-    signal(SIGHUP, sigfin_handler);
     signal(SIGINT, sigfin_handler);
 
     /* load blacklisted addresses and block them (if requested) */

=======


Richard

[Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

[Richard J. <rjt...@sa...>]

On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon
start at boot time.  Typical log entries:

Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting...

And sshguard is indeed no longer running.  A later manual start of sshguard
succeeds.

This matches with reported 2012 FreeBSD experience:
https://forums.freebsd.org/threads/at-boot-rc-script-runs-but-service-immediately-exits.29623/

However, in my case, even putting in a 60 second delay on the start of
sshguard is not enough for sshguard to remain running on the system I'm
using for testing.  The start is delayed, but then sshguard quits 1-2
seconds later with the 'Go exit signal' message showing in the log.

I do not know at present whether there's actually an exit signal
sent/received, or whether that message is triggered by something else.

Is this known and fixed yet in the dev repository, or has the cause not yet
been run down?


Richard

-------
/etc/rc.d/sshguard:
-------
#!/bin/sh
#
# $OpenBSD: sshguard.rc,v 1.1 2011/03/07 17:44:16 rpointel Exp $

daemon="/usr/local/sbin/sshguard"
daemon_flags="-l /var/log/authlog"

. /etc/rc.d/rc.subr

rc_bg=YES
rc_reload=NO

rc_cmd $1
-------

[Sshguard-users] OS X warnings

[LuKreme <kr...@kr...>]

com.apple.xpc.launchd[1] (org.macports.sshguard): The Debug key is no longer respected. Please remove it.
com.apple.xpc.launchd[1] (org.macports.sshguard): This service is defined to be constantly running and is inherently inefficient.

(OS X 10.10.2 and 10.10.3beta)

Anything to be concerned about?

-- 
Supposing there was justice for all, after all? For every unheeded
beggar, every harsh word, every neglected duty, every slight... every
choice... Because that was the point, wasn't it? You had to choose. You
might be right, you might be wrong, but you had to choose, knowing that
the rightness or wrongness might never be clear or even that you were
deciding between two sorts of wrong, that there was no right anywhere.
And always, always, you did it by yourself. You were the one there, on
the edge, watching and listening. Never any tears, never any apology,
never any regrets... You saved all that up in a way that could be used
when needed. --Carpe Jugulum

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/10/2015 19:23, Bradley Giesbrecht wrote:
> Done. MacPorts is now building with 95f80c8 from BitBucket.
> 
> http://trac.macports.org/changeset/132790

Fantastic, thanks! If you encounter any bugs or other suggestions,
please do report them here.

Best,
Kevin Zheng

- -- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJU29mOAAoJEOrPD3bCLhCQ6uQH+wfvNqMH1obzfkY7h84wG4Sj
JAsZ3QLD23PuNRlzhyNuwHNkdCzzplMB+tlnSLQDeWcIJXbDWcV7QuPkTiz5NbTH
oEa/bW4TqMUaroHmsYG9DguaiMsBq3xzzlEMlVHN+B3I0PvGYiSua3AnEenZc22r
yi3ffgUMfhzb8S2GhtWveADHEu4zpb21Eg1vQL7K8cPppZ0iZWyBURDPWUJXH5eR
hotYu2tnv7WEIEEVZes7qLyqaliR+eqyDnl4rHcbkl5YqMde8JWQeHd5UsdUvhVs
4i4KeXrqv5nfOxQS5Y2kuv6GnCm0R/fL65V7J3nfUdARYIFE+05bm1rF6XqU3S4=
=hKEw
-----END PGP SIGNATURE-----

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

[Bradley G. <pi...@ma...>]

On Feb 7, 2015, at 7:28 PM, Kevin Zheng <kev...@gm...> wrote:

> Signed PGP part
> On 02/05/15 15:01, Bradley Giesbrecht wrote:
> > I maintain the MacPorts sshguard package and will add your patch to
> > our build.
> 
> Fantastic! Thanks for maintaining the package!
> 
> > Do you know if there are any plans to roll a new release of
> > sshguard?
> 
> Yes, since there have been some major release-worthy changes (most
> notably human-readable blacklisting) from the last release, which was
> quite some time ago. Unfortunately, there's no ETA for this since it
> depends on how busy Mij and I are.
> 
> Meanwhile, testing the development version (from Bitbucket) and
> reporting issues (or lack thereof) is well appreciated.

Done. MacPorts is now building with 95f80c8 from BitBucket.

http://trac.macports.org/changeset/132790


Regards,
Bradley Giesbrecht (pixilla)

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/05/15 15:01, Bradley Giesbrecht wrote:
> I maintain the MacPorts sshguard package and will add your patch to
> our build.

Fantastic! Thanks for maintaining the package!

> Do you know if there are any plans to roll a new release of
> sshguard?

Yes, since there have been some major release-worthy changes (most
notably human-readable blacklisting) from the last release, which was
quite some time ago. Unfortunately, there's no ETA for this since it
depends on how busy Mij and I are.

Meanwhile, testing the development version (from Bitbucket) and
reporting issues (or lack thereof) is well appreciated.

Thanks,
Kevin Zheng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJU1tfxAAoJEOrPD3bCLhCQ7DcIAKux0pDagzWKrU8D/xNaCqgP
ThsVHydFbhZ8yodb03h4ryM5JT9YhzKLmqH1COT9M/COb6YUDsIPyNrchYQSRyC7
QT/X56YCMUC8kymeK6icEa2LFIXZaBfJsoIgRxoCNvArzbUofLNLwkDD8fD9Kzqy
GYqcToGjBEz8gATscQi25h4rVQVPidvWm3ItLPPjXqtKSQm+Tdac80mZUUmRNTas
svRnQN5dET2IJTDueo9AI+ICNaqTm7smHCfssGCLQDuc6s/PRns025dQFunGYgjW
vCcecaHBodiDmuaD4ui+i7o/rF2hAxd/DKp6orG/Q+ntTNk6yhpkc07NYRvGvkE=
=WUN/
-----END PGP SIGNATURE-----

Re: [Sshguard-users] Where are blocked IPs listed in OS X?

[LuKreme <kr...@kr...>]

On 06 Feb 2015, at 14:53 , LuKreme <kr...@kr...> wrote:
> Where is that IP listed as being blocked other than in the logs? It’s not listed in any file in /etc/* but it stops appearing in system.log after sshguard block it.

Never mind. Doh.

# pfctl -T show -t sshguard

-- 
'There's Mr Dibbler.' 'What's he selling this time?' 'I don't think he's
trying to sell anything, Mr Poons.' 'It's that bad? Then we're probably
in lots of trouble.' --Reaper Man

[Sshguard-users] Where are blocked IPs listed in OS X?

[LuKreme <kr...@kr...>]

Feb  6 14:42:58 Jaka sshguard[160]: Blocking 87.106.151.126:4 for >630secs: 40 danger in 4 attacks over 93 seconds (all: 40d in 1 abuses over 93s).

Where is that IP listed as being blocked other than in the logs? It’s not listed in any file in /etc/* but it stops appearing in system.log after sshguard block it.

(Under OS X 10.10)

-- 
Commander: "Seems odd you'd name your ship after a battle you were on
the wrong side of." 
 
Mal: "May have been the losing side. Still not convinced it was the
wrong one."

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

[Alan S. <st...@le...>]

Dear Bradley,

That's great - many thanks (and to you Kevin)

regards

Alan

On 5 Feb 2015, at 21:01, Bradley Giesbrecht <pi...@ma...> wrote:

> On Feb 4, 2015, at 5:03 PM, Kevin Zheng <kev...@gm...> wrote:
> 
>> On 01/27/15 06:25, Alan Stocker wrote:
>>> Any thoughts on what I have setup incorrectly (if anything) or
>>> solutions?
>> 
>> This problem has been fixed recently, and is available in the
>> development repository located at:
>> 
>> https://bitbucket.org/sshguard/sshguard
> 
> Thanks Kevin.
> 
> I maintain the MacPorts sshguard package and will add your patch to our build.
> 
> Do you know if there are any plans to roll a new release of sshguard?
> 
> 
> 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

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

[Bradley G. <pi...@ma...>]

On Feb 4, 2015, at 5:03 PM, Kevin Zheng <kev...@gm...> wrote:

> On 01/27/15 06:25, Alan Stocker wrote:
>> Any thoughts on what I have setup incorrectly (if anything) or
>> solutions?
> 
> This problem has been fixed recently, and is available in the
> development repository located at:
> 
> https://bitbucket.org/sshguard/sshguard

Thanks Kevin.

I maintain the MacPorts sshguard package and will add your patch to our build.

Do you know if there are any plans to roll a new release of sshguard?


Regards,
Bradley Giesbrecht (pixilla)

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

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

Hi Alan,

On 01/27/15 06:25, Alan Stocker wrote:
> Any thoughts on what I have setup incorrectly (if anything) or
> solutions?

This problem has been fixed recently, and is available in the
development repository located at:

https://bitbucket.org/sshguard/sshguard

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

[Barry M. <bmu...@ga...>]

diff --git a/src/parser/attack_parser.y b/src/parser/attack_parser.y
index 4a58dd2..af193fb 100644
--- a/src/parser/attack_parser.y
+++ b/src/parser/attack_parser.y
@@ -89,6 +89,7 @@ static struct {
 /* ssh */
 %token SSH_INVALUSERPREF SSH_NOTALLOWEDPREF SSH_NOTALLOWEDSUFF
 %token SSH_LOGINERR_PREF SSH_LOGINERR_SUFF SSH_LOGINERR_PAM
+%token SSH_VIA_SUFF
 %token SSH_REVERSEMAP_PREF SSH_REVERSEMAP_SUFF
 %token SSH_NOIDENTIFSTR SSH_BADPROTOCOLIDENTIF SSH_BADPROTOCOLIDENTIF_SUFF
 %token SSH_DISCONNECT_PREF SSH_PREAUTH_SUFF
@@ -278,6 +279,7 @@ ssh_illegaluser:
 ssh_authfail:
     SSH_LOGINERR_PREF addr SSH_LOGINERR_SUFF
     | SSH_LOGINERR_PAM addr
+    | SSH_LOGINERR_PAM addr SSH_VIA_SUFF
     ;
 
 ssh_reversemapping:
diff --git a/src/parser/attack_scanner.l b/src/parser/attack_scanner.l
index 5ecdcc8..3956c5d 100644
--- a/src/parser/attack_scanner.l
+++ b/src/parser/attack_scanner.l
@@ -146,6 +146,7 @@ HOSTADDR    localhost|([-a-zA-Z0-9]+\.)+[a-zA-Z]+|{IPV4}|{IPV6}|{IPV4MAPPED6}
 
  /* wrong password for valid user @ FreeBSD, Debian */
 "error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user ")?.+" from "            { return SSH_LOGINERR_PAM; }
+"via ".*                                                        { BEGIN(INITIAL); return SSH_VIA_SUFF; }
 
  /* SSH: reverse mapping "possible break-in attempt!" */
 "reverse mapping checking getaddrinfo for "[^\[]*"["            { BEGIN(ssh_reversemap); return SSH_REVERSEMAP_PREF; }

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

[Vjaceslavs K. <vkl...@gm...>]

I suppose this very the root of the problem was, I was pulling the source
from
https://sshguard.svn.sourceforge.net/svnroot/sshguard/trunk/

Code from https://bitbucket.org/sshguard/sshguard definitely blocks on
Received disconnect from 103.41.124.17: 11:  [preauth]

Thank you.

On Mon, Feb 2, 2015 at 5:27 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi Vjaceslavs,
>
> On 02/02/2015 17:02, Vjaceslavs Klimovs wrote:
> > Just a quick ping on this one, did you have a chance to look at this?
>
> Thanks for the ping, otherwise, I may have forgotten about it!
>
> SSHGuard (in the current development version) correctly detects the
> following message as an attack:
>
> Received disconnect from 103.41.124.17: 11:  [preauth]
>
> Is this the line you intended?
>
> Just as a sanity check, the development version is here:
> https://bitbucket.org/sshguard/sshguard
>
> 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
>

[Sshguard-users] Adding some extra tools to sshguard blacklist handling

[Scott M. <sha...@gm...>]

Dear list..

I found that I needed some extra tools, so I formalized one I found in
a GIST and wrote another one.

https://github.com/shadowbq/sshguard-contrib

sshguard-reprieve

sshguard-dump

Check it out .. Fork it .. Fix it.

Shadowbq

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Barry M. <bmu...@ga...>]

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

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Bradley G. <pi...@ma...>]

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)

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Bradley G. <pi...@ma...>]

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)

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

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

Hi Vjaceslavs,

On 02/02/2015 17:02, Vjaceslavs Klimovs wrote:
> Just a quick ping on this one, did you have a chance to look at this?

Thanks for the ping, otherwise, I may have forgotten about it!

SSHGuard (in the current development version) correctly detects the
following message as an attack:

Received disconnect from 103.41.124.17: 11:  [preauth]

Is this the line you intended?

Just as a sanity check, the development version is here:
https://bitbucket.org/sshguard/sshguard

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

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

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

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Barry M. <bmu...@ga...>]

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

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Barry M. <bmu...@ga...>]

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
>

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

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

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

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

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

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