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

Re: [Sshguard-users] Waiting for sshguard 1.1 ...

[Mij <mi...@bi...>]

Hello Hans

great to hear such a proactive availability. I already have an about- 
to-be-released
version of 1.1. It already fixes both problems, and several reports  
and patches I had
from users. I usually leave the code running for 3 weeks on a  
production server
before releasing, although I recently had two further submissions that  
I still need to
integrate.

The only item that I won't be able to take out of my todo list is a  
report from beginning
of march. It is related to the IPF backend, I don't use it and I won't  
have time to setup
a test machine for that. If this may interest you, contribution for  
that would be highly
welcome (and of course properly reported).

In the next few weeks I'm going to release 1.1 anyway, don't despair :)

michele


On Jun 20, 2008, at 4:32 PM, Hans F. Nordhaug wrote:

> I would really like a release of 1.1. AFAIK there are at least two
> problems with 1.0 - not blocking root and single letter usernames.
> Are there any issues we can help with so 1.1 can be released?
>
> Regards,
> Hans
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Waiting for sshguard 1.1 ...

[Hans F. N. <Han...@hi...>]

I would really like a release of 1.1. AFAIK there are at least two
problems with 1.0 - not blocking root and single letter usernames.
Are there any issues we can help with so 1.1 can be released?

Regards,
Hans

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mij <mi...@bi...>]

Hello Mike

thanks for your post, please find the comments throughout your text


On Jun 12, 2008, at 7:32 AM, Mike Brown wrote:

> On my FreeBSD system, I've been using route(4) to manually  
> manipulate my
> routing tables, setting up blackhole routes for IPs from which attacks
> originate. This works much more efficiently than ipfw, and very  
> thoroughly
> blocks all communication with the compromised hosts.

thanks, in general I appreciate contributions and customization so I  
look fwd to
include this into the trunk as soon as it becomes a convenient solution.

In which circumstances does this work more efficiently than ipfw or  
another firewall?
I consider quite negligible the load of rejecting connections: what is  
the load at which
you see this improvement?

A benefit that I see is that there is no dependency on specific  
firewalls anymore. A
drawback is that routing tables are not meant for this, so it might be  
tricky to manage
sshguard rules and avoid messing up with "manual" ones. If you're  
interested in
contributing this, please have a look at the question of the  
portability across systems
different from linux.


> Rather than using my own custom, buggy script, I thought I'd try  
> sshguard with
> a custom backend. I used sshguard_backendgen.sh to generate a .h file.
> I used the commands below for the block, release, and flush, and  
> left the
> init and finalize commands empty:
>
> /sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole
> /sbin/route -q delete $SSHG_ADDR 127.0.0.1
> netstat -r -n -W | head | tr -s ' ' '\t' | cut -f 3,1 | rev | grep  
> '^B' | cut -f 2 | rev | xargs -n 1 -J % /sbin/route -q delete %  
> 127.0.0.1
>
> The flush command is a bit kludgy, obviously, and I haven't tested  
> it, but the
> idea is to avoid using 'route flush', which is generally a bad idea,  
> and
> rather just flush the blackholed routes. Unfortunately, the way I  
> have it, it
> will flush _all_ blackholed routes, not just the ones sshguard  
> blocked. Is
> there a way to get just the ones sshguard did? It'd be nice if it  
> could write
> a single log somewhere, other than what shows up in my auth.log  
> (which gets
> rotated).

you're perfectly able to do it, just compose the "add" script with a  
further logging piece, eg (just guessing)

/sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole && echo $SSHG_ADDR  
 >> /var/db/sshguard-blocked.log

then flush with

cat /var/db/sshguard-blocked.log | while read $blocked ; do /sbin/ 
route -q delete $blocked 127.0.0.1 ; done


> Anyway, my main problem is that I don't know what to do with that .h  
> file now.
> How do I tell sshguard to use it? Sorry if this is a dumb question.  
> I couldn't
> find the answer in the docs.

This is not a dumb question :)
the thing was meant to provide 90% of the work with 10% of the effort,  
so it works like this:

1) you generate your .h file
2) you ./configure --with-firewall=pf
	the script copies src/fwalls/command_pf.h to src/fwalls/command.h
	command.h is the file containing the commands of the backend
3) you just replace src/fwalls/command.h with your generated .h file
4) you proceed to compiling & installing


> Also, a third question: do I put the -w option (for whitelisting) in  
> my
> syslog.conf? That part wasn't clear either.

-w and the other options of whitelisting
( http://sshguard.sourceforge.net/doc/usage/whitelisting.html ) are  
command line options
that can be passed to the sshguard process no matter where it is  
started from. Syslog is also fine,
eg this line is fine:
     auth.info;authpriv.info    |/usr/local/sbin/sshguard -w 1.2.3.4 - 
w 5.6.7.0/24

bye


>
>
> Thanks,
> Mike
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mike B. <mi...@sk...>]

On my FreeBSD system, I've been using route(4) to manually manipulate my 
routing tables, setting up blackhole routes for IPs from which attacks 
originate. This works much more efficiently than ipfw, and very thoroughly 
blocks all communication with the compromised hosts.

Rather than using my own custom, buggy script, I thought I'd try sshguard with 
a custom backend. I used sshguard_backendgen.sh to generate a .h file. 
I used the commands below for the block, release, and flush, and left the 
init and finalize commands empty:

/sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole
/sbin/route -q delete $SSHG_ADDR 127.0.0.1
netstat -r -n -W | head | tr -s ' ' '\t' | cut -f 3,1 | rev | grep '^B' | cut -f 2 | rev | xargs -n 1 -J % /sbin/route -q delete % 127.0.0.1

The flush command is a bit kludgy, obviously, and I haven't tested it, but the 
idea is to avoid using 'route flush', which is generally a bad idea, and 
rather just flush the blackholed routes. Unfortunately, the way I have it, it 
will flush _all_ blackholed routes, not just the ones sshguard blocked. Is 
there a way to get just the ones sshguard did? It'd be nice if it could write 
a single log somewhere, other than what shows up in my auth.log (which gets 
rotated).

Anyway, my main problem is that I don't know what to do with that .h file now. 
How do I tell sshguard to use it? Sorry if this is a dumb question. I couldn't 
find the answer in the docs.

Also, a third question: do I put the -w option (for whitelisting) in my 
syslog.conf? That part wasn't clear either.

Thanks,
Mike

Re: [Sshguard-users] SSHguard not recognizing login

[Mij <mi...@bi...>]

Hello,

other users have reported that  sshguard 1.0's parser doesn't consider
strings with 1 letter usernames, thus ignoring those reports.
The parser in version 1.1 recognizes these too.


On May 13, 2008, at 00:52 , Mr. Mystify wrote:

> hi hi...
>
> Currently I have sshguard-1.0 installed on my server, and I see the
> following happens:
>
> Jan 17 18:14:44 srv01 sshd[30968]: Did not receive identification  
> string
> from 85.17.10.113
> Jan 17 18:27:12 srv01 sshd[30972]: Invalid user a from 85.17.10.113
> Jan 17 18:27:12 srv01 sshd[30974]: Invalid user b from 85.17.10.113
> Jan 17 18:27:12 srv01 sshd[30976]: Invalid user c from 85.17.10.113
> Jan 17 18:27:13 srv01 sshd[30978]: Invalid user d from 85.17.10.113
> Jan 17 18:27:13 srv01 sshd[30980]: Invalid user e from 85.17.10.113
> Jan 17 18:27:13 srv01 sshd[30982]: Invalid user f from 85.17.10.113
> Jan 17 18:27:14 srv01 sshd[30984]: Invalid user g from 85.17.10.113
> Jan 17 18:27:14 srv01 sshd[30986]: Invalid user h from 85.17.10.113
> Jan 17 18:27:14 srv01 sshd[30988]: Invalid user i from 85.17.10.113
> Jan 17 18:27:14 srv01 sshd[30990]: Invalid user j from 85.17.10.113
> Jan 17 18:27:15 srv01 sshd[30992]: Invalid user k from 85.17.10.113
> Jan 17 18:27:15 srv01 sshd[30994]: Invalid user l from 85.17.10.113
> Jan 17 18:27:15 srv01 sshd[30996]: Invalid user m from 85.17.10.113
> Jan 17 18:27:15 srv01 sshd[30998]: Invalid user n from 85.17.10.113
> Jan 17 18:27:19 srv01 sshd[31000]: Invalid user o from 85.17.10.113
> Jan 17 18:27:19 srv01 sshd[31002]: Invalid user p from 85.17.10.113
> Jan 17 18:27:19 srv01 sshd[31004]: Invalid user q from 85.17.10.113
> Jan 17 18:27:29 srv01 sshd[31006]: Invalid user r from 85.17.10.113
> Jan 17 18:27:29 srv01 sshd[31008]: Invalid user s from 85.17.10.113
> Jan 17 18:27:29 srv01 sshd[31010]: Invalid user t from 85.17.10.113
> Jan 17 18:27:29 srv01 sshd[31012]: Invalid user u from 85.17.10.113
> Jan 17 18:27:30 srv01 sshd[31014]: Invalid user v from 85.17.10.113
> Jan 17 18:27:33 srv01 sshd[31016]: Invalid user w from 85.17.10.113
> Jan 17 18:27:33 srv01 sshd[31018]: Invalid user x from 85.17.10.113
> Jan 17 18:27:33 srv01 sshd[31020]: Invalid user y from 85.17.10.113
> Jan 17 18:27:34 srv01 sshd[31022]: Invalid user z from 85.17.10.113
> Jan 17 18:27:34 srv01 sshd[31024]: Invalid user aa from 85.17.10.113
> Jan 17 18:27:34 srv01 sshguard[1519]: Matched IP address 85.17.10.113
> Jan 17 18:27:37 srv01 sshd[31026]: Invalid user bb from 85.17.10.113
> Jan 17 18:27:37 srv01 sshguard[1519]: Matched IP address 85.17.10.113
> Jan 17 18:27:38 srv01 sshd[31028]: Invalid user cc from 85.17.10.113
> Jan 17 18:27:38 srv01 sshguard[1519]: Matched IP address 85.17.10.113
> Jan 17 18:27:38 srv01 sshd[31030]: Invalid user dd from 85.17.10.113
> Jan 17 18:27:38 srv01 sshguard[1519]: Matched IP address 85.17.10.113
> Jan 17 18:27:38 srv01 sshguard[1519]: Blocking 85.17.10.113: 4  
> failures
> over 4 seconds.
>
>
> My system is Debian Etch on Athlon64. Has anyone else seen this  
> problem
> or is it already fixed in a newer release?
>
> Regards,
>
> Mr. Mystify
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] SSHguard not recognizing login

[Mr. M. <che...@gm...>]

hi hi...

Currently I have sshguard-1.0 installed on my server, and I see the
following happens:

Jan 17 18:14:44 srv01 sshd[30968]: Did not receive identification string
from 85.17.10.113
Jan 17 18:27:12 srv01 sshd[30972]: Invalid user a from 85.17.10.113
Jan 17 18:27:12 srv01 sshd[30974]: Invalid user b from 85.17.10.113
Jan 17 18:27:12 srv01 sshd[30976]: Invalid user c from 85.17.10.113
Jan 17 18:27:13 srv01 sshd[30978]: Invalid user d from 85.17.10.113
Jan 17 18:27:13 srv01 sshd[30980]: Invalid user e from 85.17.10.113
Jan 17 18:27:13 srv01 sshd[30982]: Invalid user f from 85.17.10.113
Jan 17 18:27:14 srv01 sshd[30984]: Invalid user g from 85.17.10.113
Jan 17 18:27:14 srv01 sshd[30986]: Invalid user h from 85.17.10.113
Jan 17 18:27:14 srv01 sshd[30988]: Invalid user i from 85.17.10.113
Jan 17 18:27:14 srv01 sshd[30990]: Invalid user j from 85.17.10.113
Jan 17 18:27:15 srv01 sshd[30992]: Invalid user k from 85.17.10.113
Jan 17 18:27:15 srv01 sshd[30994]: Invalid user l from 85.17.10.113
Jan 17 18:27:15 srv01 sshd[30996]: Invalid user m from 85.17.10.113
Jan 17 18:27:15 srv01 sshd[30998]: Invalid user n from 85.17.10.113
Jan 17 18:27:19 srv01 sshd[31000]: Invalid user o from 85.17.10.113
Jan 17 18:27:19 srv01 sshd[31002]: Invalid user p from 85.17.10.113
Jan 17 18:27:19 srv01 sshd[31004]: Invalid user q from 85.17.10.113
Jan 17 18:27:29 srv01 sshd[31006]: Invalid user r from 85.17.10.113
Jan 17 18:27:29 srv01 sshd[31008]: Invalid user s from 85.17.10.113
Jan 17 18:27:29 srv01 sshd[31010]: Invalid user t from 85.17.10.113
Jan 17 18:27:29 srv01 sshd[31012]: Invalid user u from 85.17.10.113
Jan 17 18:27:30 srv01 sshd[31014]: Invalid user v from 85.17.10.113
Jan 17 18:27:33 srv01 sshd[31016]: Invalid user w from 85.17.10.113
Jan 17 18:27:33 srv01 sshd[31018]: Invalid user x from 85.17.10.113
Jan 17 18:27:33 srv01 sshd[31020]: Invalid user y from 85.17.10.113
Jan 17 18:27:34 srv01 sshd[31022]: Invalid user z from 85.17.10.113
Jan 17 18:27:34 srv01 sshd[31024]: Invalid user aa from 85.17.10.113
Jan 17 18:27:34 srv01 sshguard[1519]: Matched IP address 85.17.10.113
Jan 17 18:27:37 srv01 sshd[31026]: Invalid user bb from 85.17.10.113
Jan 17 18:27:37 srv01 sshguard[1519]: Matched IP address 85.17.10.113
Jan 17 18:27:38 srv01 sshd[31028]: Invalid user cc from 85.17.10.113
Jan 17 18:27:38 srv01 sshguard[1519]: Matched IP address 85.17.10.113
Jan 17 18:27:38 srv01 sshd[31030]: Invalid user dd from 85.17.10.113
Jan 17 18:27:38 srv01 sshguard[1519]: Matched IP address 85.17.10.113
Jan 17 18:27:38 srv01 sshguard[1519]: Blocking 85.17.10.113: 4 failures
over 4 seconds.


My system is Debian Etch on Athlon64. Has anyone else seen this problem
or is it already fixed in a newer release?

Regards,

Mr. Mystify

Re: [Sshguard-users] RE : Errors when trying to add ipfw rules

[Jeff B. <sp...@ya...>]

--- Yves Guérin <yve...@ya...> wrote:
> Under which user the sshguard is running: ps auxwww
> Look into your securelevel for your kernel: man
> securelevel
> run the kernel below the 3rd level.

Thank you Yves!  It turns out that sshguard was
running under my profile.  I changed it to run under
root and now the rules do get added.

However, now there is a second (and I think common)
problem.  Sshguard adds its rules at 55000+, but the
Mac OS X firewall GUI adds rules at a lower number, so
sshguard's rules are bypassed.  I have no way of
changing Mac OS X's rules, so is there a way to change
the numbers that sshguard uses?

Or do you think it would be better for me to use a
different product instead of sshguard?  Maybe one that
uses hosts.deny (although my understanding was that
sshguard's approach was more secure).

Thanks for your help!


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Sshguard-users] RE : Errors when trying to add ipfw rules

[Yves G. <yve...@ya...>]

Dear Sir,

does the ipfw is running ?
> kldstat

regards,

Yves

Jeff Berman <sp...@ya...> a écrit : Hi everyone,

I just installed sshguard 1.0 on my Mac running OS X
10.4.9.  Sshguard seems to run just fine, but it fails
when trying to add rules to ipfw.  This is the error:

ipfw: socket: Operation not permitted

And this is what is logged:

Apr 14 10:11:08 G3 sshguard[378]: Started successfully
[(a,p,s)=(4, 420, 1200)], now ready to scan.
Apr 14 10:11:25 G3 sshguard[378]: Blocking 127.0.0.1:
4 failures over 5 seconds.\n
Apr 14 10:11:25 G3 sshguard[378]: Blocking command
failed. Exited: 17664
Apr 14 10:20:52 G3 sshguard[378]: Releasing 127.0.0.1
after 567 seconds.\n
Apr 14 10:20:52 G3 sshguard[378]: could not get back
rule ID for address 127.0.0.1
Apr 14 10:20:52 G3 sshguard[378]: Release command
failed. Exited: -1

I'm not an expert with *nix permissions, but this is
how the sshguard executable is listed via ls:

-rwxr-xr-x   1 root  wheel  52924 Apr 14 05:03
sshguard

So I would think that it would have authority to write
out to ipfw.  I also tried running sshguard via sudo
but it gets the same error.  Any ideas how to fix
this?

Thanks!


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users



Yves Guerin
http://welcome.to/virtuelab
 ooooooooside 2008-04-16 and 2008-04-22 ooooooooside 2008-04-23 and 2008-04-29 between 2008-04-04 and 9999-99-99       <hr size="1"> Envoyé avec <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52423/*http://fr.docs.yahoo.com/mail/overview/index.html">Yahoo! Mail</a>.<br>Une boite mail plus intelligente. </a>

[Sshguard-users] RE : Errors when trying to add ipfw rules

[Yves G. <yve...@ya...>]

Hello,

Under which user the sshguard is running: ps auxwww
Look into your securelevel for your kernel: man securelevel
run the kernel below the 3rd level.

Regards

Jeff Berman <sp...@ya...> a écrit : Hi everyone,

I just installed sshguard 1.0 on my Mac running OS X
10.4.9.  Sshguard seems to run just fine, but it fails
when trying to add rules to ipfw.  This is the error:

ipfw: socket: Operation not permitted

And this is what is logged:

Apr 14 10:11:08 G3 sshguard[378]: Started successfully
[(a,p,s)=(4, 420, 1200)], now ready to scan.
Apr 14 10:11:25 G3 sshguard[378]: Blocking 127.0.0.1:
4 failures over 5 seconds.\n
Apr 14 10:11:25 G3 sshguard[378]: Blocking command
failed. Exited: 17664
Apr 14 10:20:52 G3 sshguard[378]: Releasing 127.0.0.1
after 567 seconds.\n
Apr 14 10:20:52 G3 sshguard[378]: could not get back
rule ID for address 127.0.0.1
Apr 14 10:20:52 G3 sshguard[378]: Release command
failed. Exited: -1

I'm not an expert with *nix permissions, but this is
how the sshguard executable is listed via ls:

-rwxr-xr-x   1 root  wheel  52924 Apr 14 05:03
sshguard

So I would think that it would have authority to write
out to ipfw.  I also tried running sshguard via sudo
but it gets the same error.  Any ideas how to fix
this?

Thanks!


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users



Yves Guerin
http://welcome.to/virtuelab
 ooooooooside 2008-04-16 and 2008-04-22 ooooooooside 2008-04-23 and 2008-04-29 between 2008-04-04 and 9999-99-99       <hr size="1"> Envoyé avec <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52423/*http://fr.docs.yahoo.com/mail/overview/index.html">Yahoo! Mail</a>.<br>Une boite mail plus intelligente. </a>

[Sshguard-users] Errors when trying to add ipfw rules

[Jeff B. <sp...@ya...>]

Hi everyone,

I just installed sshguard 1.0 on my Mac running OS X
10.4.9.  Sshguard seems to run just fine, but it fails
when trying to add rules to ipfw.  This is the error:

ipfw: socket: Operation not permitted

And this is what is logged:

Apr 14 10:11:08 G3 sshguard[378]: Started successfully
[(a,p,s)=(4, 420, 1200)], now ready to scan.
Apr 14 10:11:25 G3 sshguard[378]: Blocking 127.0.0.1:
4 failures over 5 seconds.\n
Apr 14 10:11:25 G3 sshguard[378]: Blocking command
failed. Exited: 17664
Apr 14 10:20:52 G3 sshguard[378]: Releasing 127.0.0.1
after 567 seconds.\n
Apr 14 10:20:52 G3 sshguard[378]: could not get back
rule ID for address 127.0.0.1
Apr 14 10:20:52 G3 sshguard[378]: Release command
failed. Exited: -1

I'm not an expert with *nix permissions, but this is
how the sshguard executable is listed via ls:

-rwxr-xr-x   1 root  wheel  52924 Apr 14 05:03
sshguard

So I would think that it would have authority to write
out to ipfw.  I also tried running sshguard via sudo
but it gets the same error.  Any ideas how to fix
this?

Thanks!


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Sshguard-users] Parser changes for FreeBSD

[Mij <mi...@bi...>]

this is a bug: the parser does not recognize pure numbers as valid  
hostnames.

The fix is included in my local source and will be in the next  
release. In the meantime
you can modify your local copy like this:


<if you use ports>
I) cd /usr/ports/security/sshguard
II) make patch
III) cd work/sshguard-1.0
</if you use ports>

modify src/attack_parser.y , locate block:

===
hostname:
	WORD
	| HOSTADDR
;
===

and modify it like this:

===
hostname:
	WORD
	| HOSTADDR
	| INTEGER
;
===

<if you use ports>
cd ../../../sshguard-ipfw
make install
</if you use ports>

if you use sshguard-1.3 instead, look for block:

===
hostname:
     WORD                    {   $$ = $1;    }
     | HOSTADDR              {   $$ = $1;    }
     ;
===

and modify like this

===
hostname:
     WORD                    {   $$ = $1;    }
     | INTEGER               {   snprintf(attackscanner_str,  
MAXSCANBUFLEN, "%d", $1);    $$ = attackscanner_str;  }
     | HOSTADDR              {   $$ = $1;    }
     ;
===

thanks for reporting


On 01/gen/08, at 13:18, AngryWolf wrote:

> Hi,
>
> I have the same problem. My hostname starts with a number so break  
> attempts
> aren't catched. Example:
>
> [root@123456 ~]# sshguard
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from  
> 202.130.138.94
>
> Nothing happened, however changing '123456' to 'localhost' in the  
> keyboard
> input works:
>
> [root@123456 ~]# sshguard
> Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from  
> 202.130.138.94
> Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from  
> 202.130.138.94
> 55006 deny ip from 202.130.138.94 to me
>
> I'm using sshguard-ipfw-1.0_1 on FreeBSD 6.3-PRERELEASE.
>
> -- 
> AngryWolf
> ang...@fl...
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Parser changes for FreeBSD

[AngryWolf <ang...@fl...>]

Hi,

I have the same problem. My hostname starts with a number so break attempts 
aren't catched. Example:

[root@123456 ~]# sshguard
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 123456 sshd[62382]: Invalid user test from 202.130.138.94

Nothing happened, however changing '123456' to 'localhost' in the keyboard 
input works:

[root@123456 ~]# sshguard
Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from 202.130.138.94
Dec 31 10:08:06 localhost sshd[62382]: Invalid user test from 202.130.138.94
55006 deny ip from 202.130.138.94 to me

I'm using sshguard-ipfw-1.0_1 on FreeBSD 6.3-PRERELEASE.

-- 
AngryWolf
ang...@fl...

Re: [Sshguard-users] Problem blocking IP with sshguard 1.0 on FreeBSD

[Mij <mi...@bi...>]

On 12/dic/07, at 17:00, Ryan Phillips wrote:

> On Dec 12, 2007 9:54 AM, Ryan Phillips <tro...@gm...> wrote:
>> On Dec 12, 2007 9:11 AM, Ryan Phillips <tro...@gm...> wrote:
>>> Hi All,
>>>
>>> I have been using the pre-1.0 release perfectly fine, but something
>>> broke with the latest ports update to 1.0.  It doesn't appear that a
>>> user is getting blocked by the firewall.
>>>
>>> Any help would be appreciated.
>>>
>>
>> Sorry for the noise... SSH was listening on all interfaces and the pf
>> rule only blocked on one.
>>
>> For historical sake: block in quick from <sshguard> to any
>
> I guess the 'on' directive would have taken care of that scenario.
> I'm a newb with pf.
>
> Any comments with this problem would be appreciated.

"on $ext_if" matches all the traffic coming in to the ext_if physical  
interface, so
yes, in case that you have multiple addressess assigned to one  
physical interface.

If instead ssh is reachable from different addressess on different  
interfaces, "on"
is just a limitation, and you should instead use something like

         block in quick from <sshguard> to any port 22 label "ssh  
bruteforce"

or use multiple rules with "on $intrf" for every external interface.

The advantage of using "on $interface" is that you protect LAN  
addresses from being
blocked, even if they behave like attackers. Of course this can be  
managed by sshguard
itself with whitelisting anyway.

Re: [Sshguard-users] Problem blocking IP with sshguard 1.0 on FreeBSD

[Ryan P. <tro...@gm...>]

On Dec 12, 2007 9:54 AM, Ryan Phillips <tro...@gm...> wrote:
> On Dec 12, 2007 9:11 AM, Ryan Phillips <tro...@gm...> wrote:
> > Hi All,
> >
> > I have been using the pre-1.0 release perfectly fine, but something
> > broke with the latest ports update to 1.0.  It doesn't appear that a
> > user is getting blocked by the firewall.
> >
> > Any help would be appreciated.
> >
>
> Sorry for the noise... SSH was listening on all interfaces and the pf
> rule only blocked on one.
>
> For historical sake: block in quick from <sshguard> to any

I guess the 'on' directive would have taken care of that scenario.
I'm a newb with pf.

Any comments with this problem would be appreciated.

-ryan

Re: [Sshguard-users] Problem blocking IP with sshguard 1.0 on FreeBSD

[Ryan P. <tro...@gm...>]

On Dec 12, 2007 9:11 AM, Ryan Phillips <tro...@gm...> wrote:
> Hi All,
>
> I have been using the pre-1.0 release perfectly fine, but something
> broke with the latest ports update to 1.0.  It doesn't appear that a
> user is getting blocked by the firewall.
>
> Any help would be appreciated.
>

Sorry for the noise... SSH was listening on all interfaces and the pf
rule only blocked on one.

For historical sake: block in quick from <sshguard> to any

Thanks for the great software!

-Ryan

[Sshguard-users] Problem blocking IP with sshguard 1.0 on FreeBSD

[Ryan P. <tro...@gm...>]

Hi All,

I have been using the pre-1.0 release perfectly fine, but something
broke with the latest ports update to 1.0.  It doesn't appear that a
user is getting blocked by the firewall.

Any help would be appreciated.

Thanks,
Ryan

pf config:
  table <sshguard> persist
  pass in all
  pass out all

  # block all incoming packets but allow ssh, pass all outgoing tcp and udp
  # connections and keep state, logging blocked packets.

  block in all
  block  return-rst out quick proto tcp from any to any port 113

  block in quick on $ext_if from <block_hosts> to any
  block in quick on $ext_if from <sshguard> to any

  ...

auth.log:

Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 539 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 538 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 537 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 535 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 534 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 531 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 11 23:59:27 zeus sshguard[61062]: Releasing 77.246.240.82 after 526 seconds.
Dec 11 23:59:27 zeus sshguard[61062]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 11 23:59:27 zeus sshguard[61062]: Run command "/sbin/pfctl -Tdel
-t sshguard $SSHG_ADDR": exited 0.
Dec 12 00:00:01 zeus sshguard[61062]: Got exit signal, flushing
blocked addresses and exiting...
Dec 12 00:00:01 zeus sshguard[61062]: Run command "/sbin/pfctl -Tflush
-t sshguard": exited 0.
Dec 12 00:00:01 zeus sshguard[83693]: Started successfully
[(a,p,s)=(4, 420, 1200)], now ready to scan.
Dec 12 00:00:20 zeus postfix/smtpd[83948]: sql auxprop plugin using mysql engine
Dec 12 00:00:20 zeus sshd[83929]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:20 zeus sshd[83929]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:20 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83930]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83930]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83931]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83931]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83934]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83934]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshd[83933]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83933]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Blocking 77.246.240.82: 4
failures over 1 seconds.
Dec 12 00:00:21 zeus sshguard[83693]: Setting environment:
SSHG_ADDR=77.246.240.82;SSHG_ADDRKIND=4;SSHG_SERVICE=10.
Dec 12 00:00:21 zeus sshguard[83693]: Run command "/sbin/pfctl -Tadd
-t sshguard $SSHG_ADDR": exited 0.
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83935]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83935]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83938]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83938]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82
Dec 12 00:00:21 zeus sshd[83942]: reverse mapping checking getaddrinfo
for 240-82.umostel.ru [77.246.240.82] failed - POSSIBLE BREAK-IN
ATTEMPT!
Dec 12 00:00:21 zeus sshd[83942]: Invalid user alexis from 77.246.240.82
Dec 12 00:00:21 zeus sshguard[83693]: Matched IP address 77.246.240.82

Re: [Sshguard-users] More problems catching failed password attempts for root

[Mij <mi...@bi...>]

thanks for your precious test data. I will look into your report in a  
couple
of week ends


On 16/nov/07, at 21:48, Forrest Aldrich wrote:

> I posted a message recently about having problems with sshguard on
> FreeBSD-6.x, whereby failed passwords for root were not being caught
> (everything else was).  I'm continuing to have this problem and I  
> wonder
> if this might play into it:
>
> /etc/syslog.conf:
>
> auth.info;authpriv.info                         /var/log/auth.log
> auth.info;authpriv.info
> |/usr/local/sbin/sshguard -p 18000 -w /usr/local/etc/ 
> sshguard_whitelist
>
> First entry is simply writing to auth.log, the other going to  
> sshguard.
> Probably just a typo that needed to be corrected, though it still
> appears to work correctly.
>
> In any case, take the log snipped below from today where this happened
> once again.
>
> I'd be interested in any constructive feedback about fixing this.
> Notice that it seems to act on every user except "root".
>
>
> Nov 16 08:20:15 gw sshd[25604]: Did not receive identification string
> from 80.53.67.35
> Nov 16 08:22:04 gw sshd[25618]: Did not receive identification string
> from 85.18.101.82
> Nov 16 08:25:17 gw sshd[25622]: Failed password for root from
> 80.53.67.35 port 46074 ssh2
> Nov 16 08:25:20 gw sshd[25624]: Invalid user admin from 80.53.67.35
> Nov 16 08:25:20 gw sshd[25624]: Failed password for invalid user admin
> from 80.53.67.35 port 46136 ssh2
> Nov 16 08:25:21 gw sshd[25626]: Invalid user test from 80.53.67.35
> Nov 16 08:25:21 gw sshd[25626]: Failed password for invalid user test
> from 80.53.67.35 port 46209 ssh2
> Nov 16 08:25:23 gw sshd[25628]: Invalid user guest from 80.53.67.35
> Nov 16 08:25:23 gw sshd[25628]: Failed password for invalid user guest
> from 80.53.67.35 port 46262 ssh2
> Nov 16 08:25:25 gw sshd[25630]: Invalid user webmaster from  
> 80.53.67.35
> Nov 16 08:25:25 gw sshguard[24319]: Blocking 80.53.67.35: 4 failures
> over 5 seconds.
> Nov 16 08:25:25 gw sshd[25630]: Failed password for invalid user
> webmaster from 80.53.67.35 port 46314 ssh2
> Nov 16 08:36:28 gw sshd[25653]: Failed password for root from
> 85.18.101.82 port 33750 ssh2
> Nov 16 08:36:29 gw sshd[25655]: Failed password for root from
> 85.18.101.82 port 33802 ssh2
> Nov 16 08:36:30 gw sshd[25657]: Failed password for root from
> 85.18.101.82 port 33854 ssh2
> Nov 16 08:36:31 gw sshd[25659]: Failed password for root from
> 85.18.101.82 port 33909 ssh2
> Nov 16 08:36:32 gw sshd[25661]: Failed password for root from
> 85.18.101.82 port 33965 ssh2
> Nov 16 08:36:33 gw sshd[25663]: Failed password for root from
> 85.18.101.82 port 34021 ssh2
> Nov 16 08:36:34 gw sshd[25665]: Failed password for root from
> 85.18.101.82 port 34080 ssh2
> Nov 16 08:36:35 gw sshd[25667]: Failed password for root from
> 85.18.101.82 port 34134 ssh2
> Nov 16 08:36:36 gw sshd[25669]: Failed password for root from
> 85.18.101.82 port 34203 ssh2
> Nov 16 08:36:37 gw sshd[25671]: Failed password for root from
> 85.18.101.82 port 34253 ssh2
> Nov 16 08:36:39 gw sshd[25673]: Failed password for root from
> 85.18.101.82 port 34309 ssh2
> Nov 16 08:36:40 gw sshd[25675]: Failed password for root from
> 85.18.101.82 port 34373 ssh2
> Nov 16 08:36:41 gw sshd[25677]: Failed password for root from
> 85.18.101.82 port 34418 ssh2
> Nov 16 08:36:42 gw sshd[25679]: Failed password for root from
> 85.18.101.82 port 34466 ssh2
> Nov 16 08:36:43 gw sshd[25681]: Failed password for root from
> 85.18.101.82 port 34529 ssh2
> Nov 16 08:36:44 gw sshd[25683]: Failed password for root from
> 85.18.101.82 port 34577 ssh2
> Nov 16 08:36:46 gw sshd[25685]: Failed password for root from
> 85.18.101.82 port 34646 ssh2
> Nov 16 08:36:47 gw sshd[25687]: Failed password for root from
> 85.18.101.82 port 34727 ssh2
> Nov 16 08:36:48 gw sshd[25689]: Failed password for root from
> 85.18.101.82 port 34780 ssh2
> Nov 16 08:36:49 gw sshd[25691]: Failed password for root from
> 85.18.101.82 port 34861 ssh2
> Nov 16 08:36:50 gw sshd[25693]: Failed password for root from
> 85.18.101.82 port 34915 ssh2
> Nov 16 08:36:52 gw sshd[25695]: Failed password for root from
> 85.18.101.82 port 34964 ssh2
> Nov 16 08:36:53 gw sshd[25697]: Failed password for root from
> 85.18.101.82 port 35031 ssh2
> Nov 16 08:36:54 gw sshd[25699]: Failed password for root from
> 85.18.101.82 port 35085 ssh2
> Nov 16 08:36:55 gw sshd[25701]: Failed password for root from
> 85.18.101.82 port 35140 ssh2
> Nov 16 08:36:56 gw sshd[25703]: Failed password for root from
> 85.18.101.82 port 35190 ssh2
> Nov 16 08:36:57 gw sshd[25705]: Failed password for root from
> 85.18.101.82 port 35250 ssh2
> Nov 16 08:36:58 gw sshd[25707]: Failed password for root from
> 85.18.101.82 port 35307 ssh2
> Nov 16 08:36:59 gw sshd[25709]: Failed password for root from
> 85.18.101.82 port 35358 ssh2
> Nov 16 08:37:01 gw sshd[25711]: Failed password for root from
> 85.18.101.82 port 35434 ssh2
> Nov 16 08:37:02 gw sshd[25713]: Failed password for root from
> 85.18.101.82 port 35478 ssh2
> Nov 16 08:37:03 gw sshd[25715]: Failed password for root from
> 85.18.101.82 port 35525 ssh2
> Nov 16 08:37:04 gw sshd[25717]: Failed password for root from
> 85.18.101.82 port 35597 ssh2
> Nov 16 08:37:05 gw sshd[25719]: Failed password for root from
> 85.18.101.82 port 35652 ssh2
> Nov 16 08:37:07 gw sshd[25721]: Invalid user administrator from  
> 85.18.101.82
> Nov 16 08:37:07 gw sshd[25721]: Failed password for invalid user
> administrator from 85.18.101.82 port 35714 ssh2
> Nov 16 08:37:08 gw sshd[25723]: Invalid user administrator from  
> 85.18.101.82
> Nov 16 08:37:08 gw sshd[25723]: Failed password for invalid user
> administrator from 85.18.101.82 port 35787 ssh2
> Nov 16 08:37:09 gw sshd[25725]: Invalid user administrator from  
> 85.18.101.82
> Nov 16 08:37:09 gw sshd[25725]: Failed password for invalid user
> administrator from 85.18.101.82 port 35837 ssh2
> Nov 16 08:37:10 gw sshd[25727]: Invalid user administrator from  
> 85.18.101.82
> Nov 16 08:37:10 gw sshguard[24319]: Blocking 85.18.101.82: 4 failures
> over 3 seconds.
> Nov 16 08:37:10 gw sshd[25727]: Failed password for invalid user
> administrator from 85.18.101.82 port 35888 ssh2
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] More problems catching failed password attempts for root

[Forrest A. <fo...@fo...>]

I posted a message recently about having problems with sshguard on 
FreeBSD-6.x, whereby failed passwords for root were not being caught 
(everything else was).  I'm continuing to have this problem and I wonder 
if this might play into it:

/etc/syslog.conf:

auth.info;authpriv.info                         /var/log/auth.log
auth.info;authpriv.info                         
|/usr/local/sbin/sshguard -p 18000 -w /usr/local/etc/sshguard_whitelist

First entry is simply writing to auth.log, the other going to sshguard.  
Probably just a typo that needed to be corrected, though it still 
appears to work correctly.

In any case, take the log snipped below from today where this happened 
once again.

I'd be interested in any constructive feedback about fixing this.  
Notice that it seems to act on every user except "root".


Nov 16 08:20:15 gw sshd[25604]: Did not receive identification string 
from 80.53.67.35
Nov 16 08:22:04 gw sshd[25618]: Did not receive identification string 
from 85.18.101.82
Nov 16 08:25:17 gw sshd[25622]: Failed password for root from 
80.53.67.35 port 46074 ssh2
Nov 16 08:25:20 gw sshd[25624]: Invalid user admin from 80.53.67.35
Nov 16 08:25:20 gw sshd[25624]: Failed password for invalid user admin 
from 80.53.67.35 port 46136 ssh2
Nov 16 08:25:21 gw sshd[25626]: Invalid user test from 80.53.67.35
Nov 16 08:25:21 gw sshd[25626]: Failed password for invalid user test 
from 80.53.67.35 port 46209 ssh2
Nov 16 08:25:23 gw sshd[25628]: Invalid user guest from 80.53.67.35
Nov 16 08:25:23 gw sshd[25628]: Failed password for invalid user guest 
from 80.53.67.35 port 46262 ssh2
Nov 16 08:25:25 gw sshd[25630]: Invalid user webmaster from 80.53.67.35
Nov 16 08:25:25 gw sshguard[24319]: Blocking 80.53.67.35: 4 failures 
over 5 seconds.
Nov 16 08:25:25 gw sshd[25630]: Failed password for invalid user 
webmaster from 80.53.67.35 port 46314 ssh2
Nov 16 08:36:28 gw sshd[25653]: Failed password for root from 
85.18.101.82 port 33750 ssh2
Nov 16 08:36:29 gw sshd[25655]: Failed password for root from 
85.18.101.82 port 33802 ssh2
Nov 16 08:36:30 gw sshd[25657]: Failed password for root from 
85.18.101.82 port 33854 ssh2
Nov 16 08:36:31 gw sshd[25659]: Failed password for root from 
85.18.101.82 port 33909 ssh2
Nov 16 08:36:32 gw sshd[25661]: Failed password for root from 
85.18.101.82 port 33965 ssh2
Nov 16 08:36:33 gw sshd[25663]: Failed password for root from 
85.18.101.82 port 34021 ssh2
Nov 16 08:36:34 gw sshd[25665]: Failed password for root from 
85.18.101.82 port 34080 ssh2
Nov 16 08:36:35 gw sshd[25667]: Failed password for root from 
85.18.101.82 port 34134 ssh2
Nov 16 08:36:36 gw sshd[25669]: Failed password for root from 
85.18.101.82 port 34203 ssh2
Nov 16 08:36:37 gw sshd[25671]: Failed password for root from 
85.18.101.82 port 34253 ssh2
Nov 16 08:36:39 gw sshd[25673]: Failed password for root from 
85.18.101.82 port 34309 ssh2
Nov 16 08:36:40 gw sshd[25675]: Failed password for root from 
85.18.101.82 port 34373 ssh2
Nov 16 08:36:41 gw sshd[25677]: Failed password for root from 
85.18.101.82 port 34418 ssh2
Nov 16 08:36:42 gw sshd[25679]: Failed password for root from 
85.18.101.82 port 34466 ssh2
Nov 16 08:36:43 gw sshd[25681]: Failed password for root from 
85.18.101.82 port 34529 ssh2
Nov 16 08:36:44 gw sshd[25683]: Failed password for root from 
85.18.101.82 port 34577 ssh2
Nov 16 08:36:46 gw sshd[25685]: Failed password for root from 
85.18.101.82 port 34646 ssh2
Nov 16 08:36:47 gw sshd[25687]: Failed password for root from 
85.18.101.82 port 34727 ssh2
Nov 16 08:36:48 gw sshd[25689]: Failed password for root from 
85.18.101.82 port 34780 ssh2
Nov 16 08:36:49 gw sshd[25691]: Failed password for root from 
85.18.101.82 port 34861 ssh2
Nov 16 08:36:50 gw sshd[25693]: Failed password for root from 
85.18.101.82 port 34915 ssh2
Nov 16 08:36:52 gw sshd[25695]: Failed password for root from 
85.18.101.82 port 34964 ssh2
Nov 16 08:36:53 gw sshd[25697]: Failed password for root from 
85.18.101.82 port 35031 ssh2
Nov 16 08:36:54 gw sshd[25699]: Failed password for root from 
85.18.101.82 port 35085 ssh2
Nov 16 08:36:55 gw sshd[25701]: Failed password for root from 
85.18.101.82 port 35140 ssh2
Nov 16 08:36:56 gw sshd[25703]: Failed password for root from 
85.18.101.82 port 35190 ssh2
Nov 16 08:36:57 gw sshd[25705]: Failed password for root from 
85.18.101.82 port 35250 ssh2
Nov 16 08:36:58 gw sshd[25707]: Failed password for root from 
85.18.101.82 port 35307 ssh2
Nov 16 08:36:59 gw sshd[25709]: Failed password for root from 
85.18.101.82 port 35358 ssh2
Nov 16 08:37:01 gw sshd[25711]: Failed password for root from 
85.18.101.82 port 35434 ssh2
Nov 16 08:37:02 gw sshd[25713]: Failed password for root from 
85.18.101.82 port 35478 ssh2
Nov 16 08:37:03 gw sshd[25715]: Failed password for root from 
85.18.101.82 port 35525 ssh2
Nov 16 08:37:04 gw sshd[25717]: Failed password for root from 
85.18.101.82 port 35597 ssh2
Nov 16 08:37:05 gw sshd[25719]: Failed password for root from 
85.18.101.82 port 35652 ssh2
Nov 16 08:37:07 gw sshd[25721]: Invalid user administrator from 85.18.101.82
Nov 16 08:37:07 gw sshd[25721]: Failed password for invalid user 
administrator from 85.18.101.82 port 35714 ssh2
Nov 16 08:37:08 gw sshd[25723]: Invalid user administrator from 85.18.101.82
Nov 16 08:37:08 gw sshd[25723]: Failed password for invalid user 
administrator from 85.18.101.82 port 35787 ssh2
Nov 16 08:37:09 gw sshd[25725]: Invalid user administrator from 85.18.101.82
Nov 16 08:37:09 gw sshd[25725]: Failed password for invalid user 
administrator from 85.18.101.82 port 35837 ssh2
Nov 16 08:37:10 gw sshd[25727]: Invalid user administrator from 85.18.101.82
Nov 16 08:37:10 gw sshguard[24319]: Blocking 85.18.101.82: 4 failures 
over 3 seconds.
Nov 16 08:37:10 gw sshd[25727]: Failed password for invalid user 
administrator from 85.18.101.82 port 35888 ssh2

Re: [Sshguard-users] Failed password attempts

[Forrest A. <fo...@fo...>]

On FreeBSD, all SSH related syslog entries go to /var/log/auth.log.  The 
relevant portion of my /etc/syslog.conf:

auth.info;authpriv.info                         /var/log/auth.log

The log entries I sent you about failed password for root (etc) 
originated from that one file, where sshguard is watching.  They were 
not caught (for whatever reason).  For other actions, it works fine and 
is populating the PF firewall table "sshguard".


Forrest



Mij wrote:
> okay I do not get what's your point :)
> If you complain sshguard does not block attempts to login with failed  
> password,
> your setup has something wrong because sshguard does recognize those  
> strings
>
> Are you sure sshguard gets those messages? You can trace what's wrong  
> by running
> sshguard with the debug flag (-d), issue those strings by keyboard  
> and see how it reacts.
> If it does block, then the system instance is not getting entries or  
> fails to run blocking
> commands.
>
>
> On 01/nov/07, at 15:11, Forrest Aldrich wrote:
>
>   
>> I'm not sure how this applies to my question, as I have syslog working
>> just fine on my system (FreeBSD).   The FreeBSD systems use a  
>> modern syslog.
>>
>> This log below is from /var/log/auth.log, which is where all of SSH's
>> entries go.   I just felt that sshguard should pick up on this (or be
>> tunable to do so, since Linux has a "faillog" subsystem which can lock
>> out at the login: prompt)
>>
>>
>> _F
>>
>>
>> Mij wrote:
>>     
>>> forrest,
>>>
>>> You know that syslog has the capability to dispatch logs depending on
>>> rules, not
>>> only deterministically to one same file.
>>> Please follow the instructions on http://sshguard.sourceforge.net/ 
>>> doc/
>>> setup/setup.html
>>> and particularly, for the syslog setup, follow the "Older flavour  
>>> setup"
>>>
>>>
>>> On 31/ott/07, at 17:05, Forrest Aldrich wrote:
>>>
>>>
>>>       
>>>> It seems reasonable that sshguard should be able to detect failed
>>>> password attempts, too.   I realize there is "faillog" on Linux
>>>> systems
>>>> for that, but not on FreeBSD. My system log was jammed with over
>>>> 1000 of
>>>> these entries from last night:
>>>>
>>>> Oct 31 10:03:22 gw sshd[55652]: Failed password for root from
>>>> 213.186.38.84 port 53650 ssh2
>>>> Oct 31 10:03:23 gw sshd[55654]: Failed password for root from
>>>> 213.186.38.84 port 44049 ssh2
>>>> Oct 31 10:03:24 gw sshd[55656]: Failed password for root from
>>>> 213.186.38.84 port 49587 ssh2
>>>> Oct 31 10:03:25 gw sshd[55658]: Failed password for root from
>>>> 213.186.38.84 port 41421 ssh2
>>>> Oct 31 10:03:25 gw sshd[55660]: Failed password for root from
>>>> 213.186.38.84 port 36564 ssh2
>>>> Oct 31 10:03:26 gw sshd[55662]: Failed password for root from
>>>> 213.186.38.84 port 35111 ssh2
>>>> Oct 31 10:03:27 gw sshd[55664]: Failed password for root from
>>>> 213.186.38.84 port 49382 ssh2
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> --
>>>> ---
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a
>>>> browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>> _______________________________________________
>>>> Sshguard-users mailing list
>>>> Ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>>
>>>>         
>>> --------------------------------------------------------------------- 
>>> ----
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a  
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>
>>>       
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>   

Re: [Sshguard-users] Failed password attempts

[Mij <mi...@bi...>]

okay I do not get what's your point :)
If you complain sshguard does not block attempts to login with failed  
password,
your setup has something wrong because sshguard does recognize those  
strings

Are you sure sshguard gets those messages? You can trace what's wrong  
by running
sshguard with the debug flag (-d), issue those strings by keyboard  
and see how it reacts.
If it does block, then the system instance is not getting entries or  
fails to run blocking
commands.


On 01/nov/07, at 15:11, Forrest Aldrich wrote:

> I'm not sure how this applies to my question, as I have syslog working
> just fine on my system (FreeBSD).   The FreeBSD systems use a  
> modern syslog.
>
> This log below is from /var/log/auth.log, which is where all of SSH's
> entries go.   I just felt that sshguard should pick up on this (or be
> tunable to do so, since Linux has a "faillog" subsystem which can lock
> out at the login: prompt)
>
>
> _F
>
>
> Mij wrote:
>> forrest,
>>
>> You know that syslog has the capability to dispatch logs depending on
>> rules, not
>> only deterministically to one same file.
>> Please follow the instructions on http://sshguard.sourceforge.net/ 
>> doc/
>> setup/setup.html
>> and particularly, for the syslog setup, follow the "Older flavour  
>> setup"
>>
>>
>> On 31/ott/07, at 17:05, Forrest Aldrich wrote:
>>
>>
>>> It seems reasonable that sshguard should be able to detect failed
>>> password attempts, too.   I realize there is "faillog" on Linux
>>> systems
>>> for that, but not on FreeBSD. My system log was jammed with over
>>> 1000 of
>>> these entries from last night:
>>>
>>> Oct 31 10:03:22 gw sshd[55652]: Failed password for root from
>>> 213.186.38.84 port 53650 ssh2
>>> Oct 31 10:03:23 gw sshd[55654]: Failed password for root from
>>> 213.186.38.84 port 44049 ssh2
>>> Oct 31 10:03:24 gw sshd[55656]: Failed password for root from
>>> 213.186.38.84 port 49587 ssh2
>>> Oct 31 10:03:25 gw sshd[55658]: Failed password for root from
>>> 213.186.38.84 port 41421 ssh2
>>> Oct 31 10:03:25 gw sshd[55660]: Failed password for root from
>>> 213.186.38.84 port 36564 ssh2
>>> Oct 31 10:03:26 gw sshd[55662]: Failed password for root from
>>> 213.186.38.84 port 35111 ssh2
>>> Oct 31 10:03:27 gw sshd[55664]: Failed password for root from
>>> 213.186.38.84 port 49382 ssh2
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Failed password attempts

[Forrest A. <fo...@fo...>]

I'm not sure how this applies to my question, as I have syslog working 
just fine on my system (FreeBSD).   The FreeBSD systems use a modern syslog.

This log below is from /var/log/auth.log, which is where all of SSH's 
entries go.   I just felt that sshguard should pick up on this (or be 
tunable to do so, since Linux has a "faillog" subsystem which can lock 
out at the login: prompt)


_F


Mij wrote:
> forrest,
>
> You know that syslog has the capability to dispatch logs depending on  
> rules, not
> only deterministically to one same file.
> Please follow the instructions on http://sshguard.sourceforge.net/doc/ 
> setup/setup.html
> and particularly, for the syslog setup, follow the "Older flavour setup"
>
>
> On 31/ott/07, at 17:05, Forrest Aldrich wrote:
>
>   
>> It seems reasonable that sshguard should be able to detect failed
>> password attempts, too.   I realize there is "faillog" on Linux  
>> systems
>> for that, but not on FreeBSD. My system log was jammed with over  
>> 1000 of
>> these entries from last night:
>>
>> Oct 31 10:03:22 gw sshd[55652]: Failed password for root from
>> 213.186.38.84 port 53650 ssh2
>> Oct 31 10:03:23 gw sshd[55654]: Failed password for root from
>> 213.186.38.84 port 44049 ssh2
>> Oct 31 10:03:24 gw sshd[55656]: Failed password for root from
>> 213.186.38.84 port 49587 ssh2
>> Oct 31 10:03:25 gw sshd[55658]: Failed password for root from
>> 213.186.38.84 port 41421 ssh2
>> Oct 31 10:03:25 gw sshd[55660]: Failed password for root from
>> 213.186.38.84 port 36564 ssh2
>> Oct 31 10:03:26 gw sshd[55662]: Failed password for root from
>> 213.186.38.84 port 35111 ssh2
>> Oct 31 10:03:27 gw sshd[55664]: Failed password for root from
>> 213.186.38.84 port 49382 ssh2
>>
>>
>>
>>
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>   

Re: [Sshguard-users] Failed password attempts

[Mij <mi...@bi...>]

forrest,

You know that syslog has the capability to dispatch logs depending on  
rules, not
only deterministically to one same file.
Please follow the instructions on http://sshguard.sourceforge.net/doc/ 
setup/setup.html
and particularly, for the syslog setup, follow the "Older flavour setup"


On 31/ott/07, at 17:05, Forrest Aldrich wrote:

> It seems reasonable that sshguard should be able to detect failed
> password attempts, too.   I realize there is "faillog" on Linux  
> systems
> for that, but not on FreeBSD. My system log was jammed with over  
> 1000 of
> these entries from last night:
>
> Oct 31 10:03:22 gw sshd[55652]: Failed password for root from
> 213.186.38.84 port 53650 ssh2
> Oct 31 10:03:23 gw sshd[55654]: Failed password for root from
> 213.186.38.84 port 44049 ssh2
> Oct 31 10:03:24 gw sshd[55656]: Failed password for root from
> 213.186.38.84 port 49587 ssh2
> Oct 31 10:03:25 gw sshd[55658]: Failed password for root from
> 213.186.38.84 port 41421 ssh2
> Oct 31 10:03:25 gw sshd[55660]: Failed password for root from
> 213.186.38.84 port 36564 ssh2
> Oct 31 10:03:26 gw sshd[55662]: Failed password for root from
> 213.186.38.84 port 35111 ssh2
> Oct 31 10:03:27 gw sshd[55664]: Failed password for root from
> 213.186.38.84 port 49382 ssh2
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Parser changes for FreeBSD

[Mij <mi...@bi...>]

hello Eric,

please file this mail on the feature request tracker

http://sourceforge.net/tracker/?group_id=188282

I'm not sure I will handle it, partly because I guess a marginal  
fraction of the
users enables this syslogd option and it might not worth the effert.  
I will inspect
the problem better this week end and provide a patch for you if it  
does not take
too much time (specifically handling the variability of v's could be  
boring)

bye


On 31/ott/07, at 01:07, Eric W. Bates wrote:

> FreeBSD syslogd has an option to make it more verbose when writing  
> logs.
>   I'm old and slow; so I find the option helpful.  Unfortunately using
> the  option spoils sshguard's parser.
>
> I took a stab a reworking attack_parser.y to deal with the extra text.
> I'm out of depth with yacc; so instead of a working patch, I have a
> feature request.
>
>  From syslogd(8)
>
>       -v      Verbose logging.  If specified once, the numeric  
> facility
>
>               and priority are logged with each locally-written  
> message.
>               If specified more than once, the names of the  
> facility and
>               priority are logged with each locally-written message.
>
> If you specify -vv here is an example:
>
> Oct 28 09:34:23 <auth.info> 235 sshd[73761]: Invalid user  
> administrator
> from 210.188.220.65
> Oct 28 09:34:30 <auth.info> 235 sshd[73763]: Invalid user  
> administrator
> from 210.188.220.65
>
> This also demonstrates another parsing problem: my host is named
> '235.dhcp.mydomain.tld'; so the host name appears in the log as '235'
> which also causes a parsing failure.
>
> My attempt to fix both problems:
>
> *** attack_parser.y.orig        Tue Oct 30 15:08:41 2007
> --- attack_parser.y     Tue Oct 30 15:36:13 2007
> ***************
> *** 49,55 ****
>     */
>    syslogent:
>         /* timestamp host name procname[pid]: logmsg */
> !     TIMESTAMP_SYSLOG host name procname '[' INTEGER ']' ':'  
> logmsg NEWLINE
>        ;
>
>    /* a multilog-generated log entry */
> --- 49,55 ----
>     */
>    syslogent:
>         /* timestamp host name procname[pid]: logmsg */
> !     TIMESTAMP_SYSLOG verbose host name procname '[' INTEGER ']' ':'
> logmsg NEWLINE
>        ;
>
>    /* a multilog-generated log entry */
> ***************
> *** 60,65 ****
> --- 60,66 ----
>    /* name of a host */
>    host name:
>        WORD
> +     | INTEGER
>        | HOSTADDR          { }
>        ;
>
> ***************
> *** 69,74 ****
> --- 70,81 ----
>        | WORD '(' WORD ')'
>        ;
>
> + /* optional facility and priority when 'verbose' logging is on */
> + verbose:
> +     '<' WORD '.' WORD '>'
> +     | ''
> +     ;
> +
>    /* the "payload" of a log entry: the oridinal message generated  
> from
> a process */
>    logmsg:
>        sshmsg          {   attackparser_service = SERVICES_SSH; }
> ***************
> *** 145,149 ****
>    %%
>
>    void yyerror(char *msg) { /* do nothing */ }
> -
> -
> --- 152,154 ----
>
>
> Also note that when I use bison 2.3 to compile attack_parser.y, the
> resultant attack_parser.h bears no resemblance to the attack_parser.h
> file include in the distribution source. In fact gcc fails with a  
> bunch
> of function undefined errors.  However, swapping in the include  
> file as
> provided in the distribution does allow it to build.  It just still
> won't parse my ssh log. [sigh]
>
> Thanks for your time.
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Failed password attempts

[Forrest A. <fo...@fo...>]

It seems reasonable that sshguard should be able to detect failed
password attempts, too.   I realize there is "faillog" on Linux systems
for that, but not on FreeBSD. My system log was jammed with over 1000 of
these entries from last night:

Oct 31 10:03:22 gw sshd[55652]: Failed password for root from
213.186.38.84 port 53650 ssh2
Oct 31 10:03:23 gw sshd[55654]: Failed password for root from
213.186.38.84 port 44049 ssh2
Oct 31 10:03:24 gw sshd[55656]: Failed password for root from
213.186.38.84 port 49587 ssh2
Oct 31 10:03:25 gw sshd[55658]: Failed password for root from
213.186.38.84 port 41421 ssh2
Oct 31 10:03:25 gw sshd[55660]: Failed password for root from
213.186.38.84 port 36564 ssh2
Oct 31 10:03:26 gw sshd[55662]: Failed password for root from
213.186.38.84 port 35111 ssh2
Oct 31 10:03:27 gw sshd[55664]: Failed password for root from
213.186.38.84 port 49382 ssh2

[Sshguard-users] Parser changes for FreeBSD

[Eric W. B. <er...@vi...>]

FreeBSD syslogd has an option to make it more verbose when writing logs. 
  I'm old and slow; so I find the option helpful.  Unfortunately using 
the  option spoils sshguard's parser.

I took a stab a reworking attack_parser.y to deal with the extra text. 
I'm out of depth with yacc; so instead of a working patch, I have a 
feature request.

 From syslogd(8)

      -v      Verbose logging.  If specified once, the numeric facility 

              and priority are logged with each locally-written message.
              If specified more than once, the names of the facility and
              priority are logged with each locally-written message.

If you specify -vv here is an example:

Oct 28 09:34:23 <auth.info> 235 sshd[73761]: Invalid user administrator 
from 210.188.220.65
Oct 28 09:34:30 <auth.info> 235 sshd[73763]: Invalid user administrator 
from 210.188.220.65

This also demonstrates another parsing problem: my host is named 
'235.dhcp.mydomain.tld'; so the host name appears in the log as '235' 
which also causes a parsing failure.

My attempt to fix both problems:

*** attack_parser.y.orig        Tue Oct 30 15:08:41 2007
--- attack_parser.y     Tue Oct 30 15:36:13 2007
***************
*** 49,55 ****
    */
   syslogent:
        /* timestamp host name procname[pid]: logmsg */
!     TIMESTAMP_SYSLOG host name procname '[' INTEGER ']' ':' logmsg NEWLINE
       ;

   /* a multilog-generated log entry */
--- 49,55 ----
    */
   syslogent:
        /* timestamp host name procname[pid]: logmsg */
!     TIMESTAMP_SYSLOG verbose host name procname '[' INTEGER ']' ':' 
logmsg NEWLINE
       ;

   /* a multilog-generated log entry */
***************
*** 60,65 ****
--- 60,66 ----
   /* name of a host */
   host name:
       WORD
+     | INTEGER
       | HOSTADDR          { }
       ;

***************
*** 69,74 ****
--- 70,81 ----
       | WORD '(' WORD ')'
       ;

+ /* optional facility and priority when 'verbose' logging is on */
+ verbose:
+     '<' WORD '.' WORD '>'
+     | ''
+     ;
+
   /* the "payload" of a log entry: the oridinal message generated from 
a process */
   logmsg:
       sshmsg          {   attackparser_service = SERVICES_SSH; }
***************
*** 145,149 ****
   %%

   void yyerror(char *msg) { /* do nothing */ }
-
-
--- 152,154 ----


Also note that when I use bison 2.3 to compile attack_parser.y, the 
resultant attack_parser.h bears no resemblance to the attack_parser.h 
file include in the distribution source. In fact gcc fails with a bunch 
of function undefined errors.  However, swapping in the include file as 
provided in the distribution does allow it to build.  It just still 
won't parse my ssh log. [sigh]

Thanks for your time.