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

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

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

Hello,

I use freebsd and ipfw, are we able to do the same thing with ipfw ? I read the following articles as mention in the last e-mail (http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html)

or may be just develop a custom bash script to do the same thing via the syslogd facilities  (may I will try this way, stay tune)?


Regards,

Yves
--- En date de : Mar 17.6.08, Mij <mi...@bi...> a écrit :
De: Mij <mi...@bi...>
Objet: Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs
À: ssh...@li...
Date: Mardi 17 Juin 2008, 1h46

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


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


      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

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

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

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

Thanks for replying. You ask good questions.

I must admit, I've done no research of my own into this; I'm just relying 
entirely on the info in this message:

http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092090.html

(quoting the OP): "This is executed in the IP stack and is faster than in the 
firewall when you have over 20 of those special 'deny this IP address' rules 
in the firewall."


A little Googling shows that someone else asked about the technique here (a 
couple years earlier):

http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00168.html

Opinions on efficiency differed but were inconclusive.
This reply offered another route-based approach: 
http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html
(rather than routing to localhost with the 'blackhole' option, route to a 
specially configured pseudo-device with the same functionality)

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

The solution seems to rely on features/efficiencies of FreeBSD, but I don't 
know anything about Linux's TCP/IP stack, so maybe the situation there is 
similar. I'm not qualified to judge.

(I'll respond to the rest later)

Thanks again,
-Mike

[Sshguard-users] possible bug

[Rob S. <sny...@gm...>]

using all the standard ubuntu 8.04 stuff

i started with the syslog approach. it didnt work. then for simplicity I
tried the tail method and get the following:
snyderra@rewop:~$ tail -n0 -F /var/log/auth.log |  /usr/sbin/sshguard
/usr/sbin/sshguard: line 1: syntax error near unexpected token `('
/usr/sbin/sshguard: line 1: `Jul  3 14:32:43 rewop sshd[7376]:
pam_unix(sshd:session): session closed for user snyderra'

here is a tail of /var/log/auth.log

Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)
Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session closed for user
root
Jul  3 14:48:00 rewop sshd[8127]: Invalid user bob from 111.111.111.111
Jul  3 14:48:41 rewop sudo: snyderra : TTY=pts/0 ; PWD=/home/snyderra ;
USER=root ; COMMAND=/usr/bin/nano /etc/syslog.conf
Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)
Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session closed for user
root
Jul  3 14:53:40 rewop sudo: pam_smbpass(sudo:auth): unrecognized option
[missingok]
Jul  3 14:53:40 rewop sudo: snyderra : TTY=pts/1 ; PWD=/home/snyderra ;
USER=root ; COMMAND=/usr/bin/aptitude
Jul  3 14:53:40 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)



any ideas? am i doing something wrong?


thanks.

Re: [Sshguard-users] Add a new custom rule

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

Hello Colin,

thanks for being precise in this report. Please submit the same data  
as an
attack pattern proposal here

http://sshguard.sourceforge.net/newattackpatt.php

there is a chance that I will integrate support for this in the  
upcoming 1.1 stable.


On Jun 28, 2008, at 3:53 PM, Colin wrote:

> Hello,
> I am successfully using sshguard 1.0 on FreeBSD (6.x and 7.0) with  
> ipfw to
> block ssh attacks. On my setup sshguard parses the /var/log/auth.log
> messages which also logs failed FTP and POP attempts. Thus I would  
> like to
> use sshguard to block those attacks too (instead of using a new filter
> program). However I am not sure how to tackle this, could someone  
> point me
> to the necessary modifications or files to change? I suppose
> src/attack_scanner.l is a good start, but is it the only one? A simple
> working rule would be enough for my liking :o).
>
> Thanks,
> Cheers,
> Colin
>
> Typical POP attack:
>
> Jun 26 11:51:17 sleepyowl ipop3d[75832]: Login failed user=dave  
> auth=dave
> host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
> Jun 26 11:51:17 sleepyowl ipop3d[75834]: Login failed user=data  
> auth=data
> host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
> Jun 26 11:51:19 sleepyowl ipop3d[75836]: Login failed user=daustin
> auth=daustin host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
>
>
> Typical FTP attack:
>
> Jun 26 14:04:15 sleepyowl ftpd[79060]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
> Jun 26 14:04:34 sleepyowl ftpd[79067]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
> Jun 26 14:04:53 sleepyowl ftpd[79069]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
>
>
>
> -------------------------------------------------------------------------
> 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] Add a new custom rule

[Colin <in...@sl...>]

Hello,
I am successfully using sshguard 1.0 on FreeBSD (6.x and 7.0) with ipfw to
block ssh attacks. On my setup sshguard parses the /var/log/auth.log
messages which also logs failed FTP and POP attempts. Thus I would like to
use sshguard to block those attacks too (instead of using a new filter
program). However I am not sure how to tackle this, could someone point me
to the necessary modifications or files to change? I suppose
src/attack_scanner.l is a good start, but is it the only one? A simple
working rule would be enough for my liking :o).

Thanks,
Cheers,
Colin

Typical POP attack:

Jun 26 11:51:17 sleepyowl ipop3d[75832]: Login failed user=dave auth=dave
host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
Jun 26 11:51:17 sleepyowl ipop3d[75834]: Login failed user=data auth=data
host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
Jun 26 11:51:19 sleepyowl ipop3d[75836]: Login failed user=daustin
auth=daustin host=210.0.95.29.static.nexnet.net.au [210.0.95.29]


Typical FTP attack:

Jun 26 14:04:15 sleepyowl ftpd[79060]: FTP LOGIN FAILED FROM
211.151.240.50, anne
Jun 26 14:04:34 sleepyowl ftpd[79067]: FTP LOGIN FAILED FROM
211.151.240.50, anne
Jun 26 14:04:53 sleepyowl ftpd[79069]: FTP LOGIN FAILED FROM
211.151.240.50, anne

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

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

* Mij <mi...@bi...> [2008-06-21]:
> 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 :)

This is indeed great news - thank you very much. I'm sorry to say that
I can't help you with any IPF backend issues. (On my private servers I
use PF (FreeBSD) and at work we use iptables (CentOS).)

Hans

> 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

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
>