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

[Sshguard-users] sshguard and syslog-ng on gentoo

[Andreas S. <and...@na...>]

Hi,

i get an error with sshguard and syslog-ng on gentoo.
The version 1.0 works without problems, but version 1.4 and 1.5beta2  
just seems to crash when invoked directly from the syslogger!
If i start them via "tail -n0 -F /var/log/auth.log | tee -a  
/dev/stderr | env SSHGUARD_DEBUG="" /usr/sbin/sshguard" i get the  
following output:

Run command "iptables -L": exited 0.
Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
Jan 13 14:10:22 sdb sshd[21506]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
user=root
Starting parse
Entering state 0
Reading a token: --accepting rule at line 102 ("Jan 13 14:10:22 sdb  
sshd[21506]:")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 186 (" ")
--accepting rule at line 185 ("pam_unix")
Next token is token WORD ()
Error: popping token SYSLOG_BANNER_PID ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0
Jan 13 14:10:24 sdb sshd[21504]: error: PAM: Authentication failure  
for root from 192.168.0.1
Starting parse
Entering state 0
Reading a token: --accepting rule at line 102 ("Jan 13 14:10:24 sdb  
sshd[21504]:")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 186 (" ")
--accepting rule at line 185 ("error")
Next token is token WORD ()
Error: popping token SYSLOG_BANNER_PID ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0


What could be wrong here!?

Thanks in advance,
Andreas
--------------------------
--> NativeMail System <---
--------------------------

Re: [Sshguard-users] Newbie questions about SSHGUARD install

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

On Jan 5, 2010, at 18:29 , Michael Sheehan wrote:

> I'm a relative n00b to linux having recently ported a wordpress blog over to a cloud server running CentOS 5.4. I installed Webmin (to make my life a bit easier hopefully). I wanted to prevent unauthorized brute force ssh logins so I found sshguard. I read through all of the documentation and did the install (or so I thought). It ran fine it seemed but after rebooting, I cannot tell if it is performing as expected. I see lots of login attempts from my LogWatch file, and many from the same IP address so I now think that my install is not working. My sshguard.fifo file seems to be "updated" regularly though...

As a general rule, please always indicate
- the version of sshguard you are running
- how you installed it (from the OS package manager, or from sources)


> I have a few questions that hopefully someone can help me answer (and please provide "entry level" responses as I may be documenting on a blog post later):
> 1) How can I tell if sshguard is running?

ps ax | grep sshguard


> 2) It seems that my IP tables is not updated with the proper configuration (at least when I look at it via webmin or the actual

Meaning you don't see an "sshguard" chain after rebooting?
Your OS doesn't preserve the firewall configuration across reboots.

I will add some links to the documentation to explain this. If you run CentOS, see
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-iptables.html
at "iptables-save"


> IP tables file). What is the proper way to check the IPtables functionality and install it properly (especially via Webmin)?
> 3) Is there a way to set up a unique "sshguard" log file that only shows actions done by sshguard

You can with syslog-ng, but it seems CentOS uses plain syslog. With syslog, you cannot.


> 4) How stable is the beta release (1.5b)?

For the SVN in general, the core is fairly stable, but the front-ends to the firewall
and the logging systems may sometimes have problems. As we can only test
some of them, we need to get users to report on the rest.
As a rule of thumb, the SVN version you can run in production by keeping an eye
on it.


> 5) What is the upgrade process for 1.5 from 1.4?

configure and make as usual, killall sshguard, then make install


> Thanks for the help!
> 
> -Michael 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Newbie questions about SSHGUARD install

[Michael S. <mi...@hi...>]

I'm a relative n00b to linux having recently ported a wordpress blog over to a cloud server running CentOS 5.4. I installed Webmin (to make my life a bit easier hopefully). I wanted to prevent unauthorized brute force ssh logins so I found sshguard. I read through all of the documentation and did the install (or so I thought). It ran fine it seemed but after rebooting, I cannot tell if it is performing as expected. I see lots of login attempts from my LogWatch file, and many from the same IP address so I now think that my install is not working. My sshguard.fifo file seems to be "updated" regularly though...

I have a few questions that hopefully someone can help me answer (and please provide "entry level" responses as I may be documenting on a blog post later):
1) How can I tell if sshguard is running?
2) It seems that my IP tables is not updated with the proper configuration (at least when I look at it via webmin or the actual IP tables file). What is the proper way to check the IPtables functionality and install it properly (especially via Webmin)?
3) Is there a way to set up a unique "sshguard" log file that only shows actions done by sshguard
4) How stable is the beta release (1.5b)?
5) What is the upgrade process for 1.5 from 1.4?

Thanks for the help!

-Michael 

Re: [Sshguard-users] Bug with sshguard1.5beta1?

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

On Jan 4, 2010, at 17:21 , Trishank Karthik Kuppusamy wrote:

> Hello,
> 
> sshguard1.5beta1 does not seem to be playing well with ipfw on OS 10.6.2:
> 
> Jan  4 01:22:43 localhost sshguard[1036]: Blocking 83.211.160.211:4 for 
>> 1680secs: 4 failures over 987 seconds.
> Jan  4 01:22:43 localhost sshguard[1036]: Command "/sbin/ipfw  to me" 
> exited 64
> Jan  4 01:22:43 localhost sshguard[1036]: Blocking command failed. 
> Exited: -1
> 
> Using sshguard1.4 works as expected, except for the previously reported 
> bug of releasing more than once the same IP address.

This is a regression introduced in a recent commit on the 1.5beta branch.
Thanks for reporting, I committed a fixed version on the repository.

[Sshguard-users] Bug with sshguard1.5beta1?

[Trishank K. K. <tk...@ny...>]

Hello,

sshguard1.5beta1 does not seem to be playing well with ipfw on OS 10.6.2:

Jan  4 01:22:43 localhost sshguard[1036]: Blocking 83.211.160.211:4 for 
 >1680secs: 4 failures over 987 seconds.
Jan  4 01:22:43 localhost sshguard[1036]: Command "/sbin/ipfw  to me" 
exited 64
Jan  4 01:22:43 localhost sshguard[1036]: Blocking command failed. 
Exited: -1

Using sshguard1.4 works as expected, except for the previously reported 
bug of releasing more than once the same IP address.

Thanks.

Re: [Sshguard-users] Failure of release causes sshguard to exit with non-zero value

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

Hi Trishank,

did you try to run in debug mode to see what happens?

env SSHGUARD_DEBUG=""   /usr/local/sbin/sshguard ...
The messages there are quite explicit: your blocking backend
fails with some error when run.


On Dec 28, 2009, at 22:56 , Trishank Karthik Kuppusamy wrote:

> Hello,
> 
> I have sshguard-1.4 installed on OS X 10.6.2 with the "tail log" and 
> "ipfw" setup.
> 
> Every time I start sshguard, it would eventually exit in the near future.
> I think the following output may point to the reason:
> 
> ...
> Dec 22 15:14:18 hostname sshguard[7993]: Releasing 121.52.215.180 after 
> 466 seconds.
> Dec 22 15:15:27 hostname sshguard[7993]: Releasing 121.52.215.180 after 
> 535 seconds.
> Dec 22 15:15:27 hostname sshguard[7993]: Release command failed. Exited: -1
> ...
> Dec 26 13:21:21 hostname sshguard[27412]: Releasing 220.162.241.11 after 
> 441 seconds.
> Dec 26 13:22:06 hostname sshguard[27412]: Releasing 220.162.241.11 after 
> 486 seconds.
> Dec 26 13:22:06 hostname sshguard[27412]: Release command failed. Exited: -1
> ...
> 
> It appears to *sometimes* release, more than once, the same IP address.
> Could someone tell us whether this is expected behaviour?
> If not, then what is a solution?
> Thanks for your time.
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Failure of release causes sshguard to exit with non-zero value

[Trishank K. K. <tk...@ny...>]

Hello,

I have sshguard-1.4 installed on OS X 10.6.2 with the "tail log" and 
"ipfw" setup.

Every time I start sshguard, it would eventually exit in the near future.
I think the following output may point to the reason:

...
Dec 22 15:14:18 hostname sshguard[7993]: Releasing 121.52.215.180 after 
466 seconds.
Dec 22 15:15:27 hostname sshguard[7993]: Releasing 121.52.215.180 after 
535 seconds.
Dec 22 15:15:27 hostname sshguard[7993]: Release command failed. Exited: -1
...
Dec 26 13:21:21 hostname sshguard[27412]: Releasing 220.162.241.11 after 
441 seconds.
Dec 26 13:22:06 hostname sshguard[27412]: Releasing 220.162.241.11 after 
486 seconds.
Dec 26 13:22:06 hostname sshguard[27412]: Release command failed. Exited: -1
...

It appears to *sometimes* release, more than once, the same IP address.
Could someone tell us whether this is expected behaviour?
If not, then what is a solution?
Thanks for your time.

Re: [Sshguard-users] Syslog-ng 3.x Configuration

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

Thanks, I committed the "generic syslog-ng conf block" to the page.


On Dec 5, 2009, at 22:01 , Byron wrote:

> Thank you Mij.  I regret the tone of my previous post; the only proper
> attitude towards Open Source contributors is gratitude.  I was upset,
> but probably just at myself for taking as long as I did to get this
> squared away.  Every so often I am reminded that no matter how
> experienced you are, you can still have a hard time over what (in
> hindsight) was a relatively simple problem.  :-)
> 
> I want to add that in my opinion SSHGuard is the best tool for this
> job.  I like the small efficient daemon design and I especially like the
> use of iptables.  I was never a fan of the approach taken by i.e.
> denyhosts (though it is a fine project), because I'd rather just drop
> all IP traffic from abusers instead of relying on TCPWrappers.
> 
> I tried your idea and also referenced the updated configuration
> instructions on the Web site.  This more general block works very well
> for me.  This is intended for syslog-ng version 3.x:
> 
> #SSHGuard
> # pass only entries with auth+authpriv facilities that are not from the
> sshguard process
> filter f_sshguard { facility(auth, authpriv) and not program("sshguard"); };
> # pass to this process with this template
> destination sshguardproc {
>        program("/usr/sbin/sshguard" template("$DATE $FULLHOST
> $MSGHDR$MESSAGE\n"));
> };
> log { source(src); filter(f_sshguard); destination(sshguardproc); };
> 
> I hope that helps a bit.  SSHD is the only Internet-facing server I am
> running so I don't actually know how well this would work with other
> daemons, but I think it should work so long as those other daemons
> produce logs in a format that SSHGuard can parse. 
> 
> Mij wrote:
>> We can't help but relying on reports from users like you for these things, we can't run
>> after all releases of all adjacent software. There's no need to get upset, just keep
>> doing your part.
>> 
>> I updated the page with Adam James' configuration block, which observes the
>> program() update too.
>> 
>> Btw, the current block seemingly passes only entries from sshd. Other processes
>> should be included with ... and (program(1) or program(2) or ...)
>> -- or more generally
>> and not program("sshguard")
>> 
>> Could you syslog-ng people please test such case and contribute a lasting
>> configuration block for either version?
>> 
>> 
>> 
>> On Dec 5, 2009, at 01:31 , Byron wrote:
>> 
>> 
>>> Hello,
>>> 
>>> 
>>> The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
>>> details how to set up SSHGuard to work with syslog-ng.
>>> 
>>> Unfortunately, I think this information is outdated.  It does not seem
>>> to work correctly with syslog-ng version 3.x.  Nowhere on that Web page
>>> does it specify the syslog-ng version for which the instructions are
>>> intended, so those using newer syslog-ng versions may come to this page
>>> and unknowingly receive incorrect instructions.  I believe that is what
>>> happened to me.  Specifically, that page asks the user to add these
>>> lines to /etc/syslog-ng/syslog-ng.conf:
>>> 
>>> # pass only entries with auth+authpriv facilities that contain sshd
>>> filter sshlogs { facility(auth, authpriv) and match("sshd"); };
>>> # pass to this process with this template (avoids <ID> prefixes)
>>> destination sshguardproc {
>>>       program("/usr/local/sbin/sshguard"  template("$DATE $FULLHOST $MESSAGE\n"));
>>> };
>>> log { source(src); filter(sshlogs); destination(sshguardproc); };
>>> 
>>> This will not only fail to work, it also will not give any error
>>> messages of any kind.  The logfiles will show that sshguard starts up,
>>> but then when SSH/SFTP activity occurs, absolutely nothing happens no
>>> matter how many failed login attempts are received.
>>> 
>>> What compounds the problem is that no documentation I could find
>>> actually explains what kind of string (from the logs) SSHGuard is
>>> expecting.  Therefore, much trial and error was required to figure out
>>> why that didn't work.  More on that later.
>>> 
>>> In syslog-ng version 2.x, the template "$DATE $FULLHOST $MESSAGE\n" will
>>> produce a string like this:
>>> 
>>> "Dec  4 19:00:19 localhost sshd[30708]: Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
>>> 
>>> 
>>> In syslog-ng version 3.x, the template macros have changed.  Now the
>>> template "$DATE $FULLHOST $MESSAGE\n" will produce a string like this:
>>> 
>>> "Dec  4 19:00:19 localhost Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
>>> 
>>> 
>>> And that latter one doesn't work.  SSHGuard seems to just ignore it and
>>> does not act on it at all, though the SSHGuard process is running.
>>> 
>>> It turns out that apparently, SSHGuard needs to see the brackets and the
>>> colon (or maybe just the colon) to correctly parse the string.  I
>>> couldn't find that mentioned anywhere in the man pages, the Web site,
>>> forums, etc.  I think documentation should include information like this
>>> but it doesn't seem to.  When there is a problem, how is the user to
>>> validate that they are feeding SSHGuard the correct information if they
>>> don't know what SSHGuard is expecting or how it parses the string?  I
>>> determined this through trial and error by playing with the macros
>>> (variables) inside of the "template()" string.
>>> 
>>> This configuration DOES work for syslog-ng 3.x.  It amounts to a way to
>>> tell syslog-ng 3.x to construct a string just like what syslog-ng 2.x
>>> would have produced from "$DATE $FULLHOST $MESSAGE\n":
>>> 
>>> #SSHGuard
>>> 
>>> # pass only entries with auth+authpriv facilities that contain sshd
>>> 
>>> filter f_sshlogs { facility(auth, authpriv) and match("sshd"); };
>>> 
>>> # pass to this process with this template (avoids <ID> prefixes)
>>> 
>>> destination sshguardproc {
>>> 
>>>       program("/usr/sbin/sshguard -a 3" template("$DATE $FULLHOST $PROGRAM[$PID]: $MESSAGE\n"));
>>> 
>>> };
>>> 
>>> log { source(src); filter(f_sshlogs); destination(sshguardproc); };
>>> 
>>> 
>>> All this does is restore the program name, the PID in brackets, and the
>>> colon.  Regarding SSHGuard, the difference between syslog-ng 2.x and
>>> syslog-ng 3.x is that the older one included those in $MESSAGE while the
>>> newer one does not.  I have verified that this does work correctly and
>>> will use iptables to halt a password-guessing attempt.
>>> 
>>> Is there any way the SSHGuard homepage can be updated to reflect this
>>> information?  If it is not updated, then other users are likely to find
>>> themselves in a situation where they perfectly follow all instructions
>>> and it still doesn't work, which is most frustrating.
>>> 
>>> ------------------------------------------------------------------------------
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing. 
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing. 
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Syslog-ng 3.x Configuration

[Byron <neg...@ve...>]

Thank you Mij.  I regret the tone of my previous post; the only proper
attitude towards Open Source contributors is gratitude.  I was upset,
but probably just at myself for taking as long as I did to get this
squared away.  Every so often I am reminded that no matter how
experienced you are, you can still have a hard time over what (in
hindsight) was a relatively simple problem.  :-)

I want to add that in my opinion SSHGuard is the best tool for this
job.  I like the small efficient daemon design and I especially like the
use of iptables.  I was never a fan of the approach taken by i.e.
denyhosts (though it is a fine project), because I'd rather just drop
all IP traffic from abusers instead of relying on TCPWrappers.

I tried your idea and also referenced the updated configuration
instructions on the Web site.  This more general block works very well
for me.  This is intended for syslog-ng version 3.x:

#SSHGuard
# pass only entries with auth+authpriv facilities that are not from the
sshguard process
filter f_sshguard { facility(auth, authpriv) and not program("sshguard"); };
# pass to this process with this template
destination sshguardproc {
        program("/usr/sbin/sshguard" template("$DATE $FULLHOST
$MSGHDR$MESSAGE\n"));
};
log { source(src); filter(f_sshguard); destination(sshguardproc); };

I hope that helps a bit.  SSHD is the only Internet-facing server I am
running so I don't actually know how well this would work with other
daemons, but I think it should work so long as those other daemons
produce logs in a format that SSHGuard can parse. 

Mij wrote:
> We can't help but relying on reports from users like you for these things, we can't run
> after all releases of all adjacent software. There's no need to get upset, just keep
> doing your part.
>
> I updated the page with Adam James' configuration block, which observes the
> program() update too.
>
> Btw, the current block seemingly passes only entries from sshd. Other processes
> should be included with ... and (program(1) or program(2) or ...)
> -- or more generally
> and not program("sshguard")
>
> Could you syslog-ng people please test such case and contribute a lasting
> configuration block for either version?
>
>
>
> On Dec 5, 2009, at 01:31 , Byron wrote:
>
>   
>> Hello,
>>
>>
>> The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
>> details how to set up SSHGuard to work with syslog-ng.
>>
>> Unfortunately, I think this information is outdated.  It does not seem
>> to work correctly with syslog-ng version 3.x.  Nowhere on that Web page
>> does it specify the syslog-ng version for which the instructions are
>> intended, so those using newer syslog-ng versions may come to this page
>> and unknowingly receive incorrect instructions.  I believe that is what
>> happened to me.  Specifically, that page asks the user to add these
>> lines to /etc/syslog-ng/syslog-ng.conf:
>>
>> # pass only entries with auth+authpriv facilities that contain sshd
>> filter sshlogs { facility(auth, authpriv) and match("sshd"); };
>> # pass to this process with this template (avoids <ID> prefixes)
>> destination sshguardproc {
>>        program("/usr/local/sbin/sshguard"  template("$DATE $FULLHOST $MESSAGE\n"));
>> };
>> log { source(src); filter(sshlogs); destination(sshguardproc); };
>>
>> This will not only fail to work, it also will not give any error
>> messages of any kind.  The logfiles will show that sshguard starts up,
>> but then when SSH/SFTP activity occurs, absolutely nothing happens no
>> matter how many failed login attempts are received.
>>
>> What compounds the problem is that no documentation I could find
>> actually explains what kind of string (from the logs) SSHGuard is
>> expecting.  Therefore, much trial and error was required to figure out
>> why that didn't work.  More on that later.
>>
>> In syslog-ng version 2.x, the template "$DATE $FULLHOST $MESSAGE\n" will
>> produce a string like this:
>>
>> "Dec  4 19:00:19 localhost sshd[30708]: Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
>>
>>
>> In syslog-ng version 3.x, the template macros have changed.  Now the
>> template "$DATE $FULLHOST $MESSAGE\n" will produce a string like this:
>>
>> "Dec  4 19:00:19 localhost Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
>>
>>
>> And that latter one doesn't work.  SSHGuard seems to just ignore it and
>> does not act on it at all, though the SSHGuard process is running.
>>
>> It turns out that apparently, SSHGuard needs to see the brackets and the
>> colon (or maybe just the colon) to correctly parse the string.  I
>> couldn't find that mentioned anywhere in the man pages, the Web site,
>> forums, etc.  I think documentation should include information like this
>> but it doesn't seem to.  When there is a problem, how is the user to
>> validate that they are feeding SSHGuard the correct information if they
>> don't know what SSHGuard is expecting or how it parses the string?  I
>> determined this through trial and error by playing with the macros
>> (variables) inside of the "template()" string.
>>
>> This configuration DOES work for syslog-ng 3.x.  It amounts to a way to
>> tell syslog-ng 3.x to construct a string just like what syslog-ng 2.x
>> would have produced from "$DATE $FULLHOST $MESSAGE\n":
>>
>> #SSHGuard
>>
>> # pass only entries with auth+authpriv facilities that contain sshd
>>
>> filter f_sshlogs { facility(auth, authpriv) and match("sshd"); };
>>
>> # pass to this process with this template (avoids <ID> prefixes)
>>
>> destination sshguardproc {
>>
>>        program("/usr/sbin/sshguard -a 3" template("$DATE $FULLHOST $PROGRAM[$PID]: $MESSAGE\n"));
>>
>> };
>>
>> log { source(src); filter(f_sshlogs); destination(sshguardproc); };
>>
>>
>> All this does is restore the program name, the PID in brackets, and the
>> colon.  Regarding SSHGuard, the difference between syslog-ng 2.x and
>> syslog-ng 3.x is that the older one included those in $MESSAGE while the
>> newer one does not.  I have verified that this does work correctly and
>> will use iptables to halt a password-guessing attempt.
>>
>> Is there any way the SSHGuard homepage can be updated to reflect this
>> information?  If it is not updated, then other users are likely to find
>> themselves in a situation where they perfectly follow all instructions
>> and it still doesn't work, which is most frustrating.
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing. 
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>     
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>   

Re: [Sshguard-users] Syslog-ng 3.x Configuration

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

We can't help but relying on reports from users like you for these things, we can't run
after all releases of all adjacent software. There's no need to get upset, just keep
doing your part.

I updated the page with Adam James' configuration block, which observes the
program() update too.

Btw, the current block seemingly passes only entries from sshd. Other processes
should be included with ... and (program(1) or program(2) or ...)
-- or more generally
and not program("sshguard")

Could you syslog-ng people please test such case and contribute a lasting
configuration block for either version?



On Dec 5, 2009, at 01:31 , Byron wrote:

> Hello,
> 
> 
> The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
> details how to set up SSHGuard to work with syslog-ng.
> 
> Unfortunately, I think this information is outdated.  It does not seem
> to work correctly with syslog-ng version 3.x.  Nowhere on that Web page
> does it specify the syslog-ng version for which the instructions are
> intended, so those using newer syslog-ng versions may come to this page
> and unknowingly receive incorrect instructions.  I believe that is what
> happened to me.  Specifically, that page asks the user to add these
> lines to /etc/syslog-ng/syslog-ng.conf:
> 
> # pass only entries with auth+authpriv facilities that contain sshd
> filter sshlogs { facility(auth, authpriv) and match("sshd"); };
> # pass to this process with this template (avoids <ID> prefixes)
> destination sshguardproc {
>        program("/usr/local/sbin/sshguard"  template("$DATE $FULLHOST $MESSAGE\n"));
> };
> log { source(src); filter(sshlogs); destination(sshguardproc); };
> 
> This will not only fail to work, it also will not give any error
> messages of any kind.  The logfiles will show that sshguard starts up,
> but then when SSH/SFTP activity occurs, absolutely nothing happens no
> matter how many failed login attempts are received.
> 
> What compounds the problem is that no documentation I could find
> actually explains what kind of string (from the logs) SSHGuard is
> expecting.  Therefore, much trial and error was required to figure out
> why that didn't work.  More on that later.
> 
> In syslog-ng version 2.x, the template "$DATE $FULLHOST $MESSAGE\n" will
> produce a string like this:
> 
> "Dec  4 19:00:19 localhost sshd[30708]: Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
> 
> 
> In syslog-ng version 3.x, the template macros have changed.  Now the
> template "$DATE $FULLHOST $MESSAGE\n" will produce a string like this:
> 
> "Dec  4 19:00:19 localhost Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
> 
> 
> And that latter one doesn't work.  SSHGuard seems to just ignore it and
> does not act on it at all, though the SSHGuard process is running.
> 
> It turns out that apparently, SSHGuard needs to see the brackets and the
> colon (or maybe just the colon) to correctly parse the string.  I
> couldn't find that mentioned anywhere in the man pages, the Web site,
> forums, etc.  I think documentation should include information like this
> but it doesn't seem to.  When there is a problem, how is the user to
> validate that they are feeding SSHGuard the correct information if they
> don't know what SSHGuard is expecting or how it parses the string?  I
> determined this through trial and error by playing with the macros
> (variables) inside of the "template()" string.
> 
> This configuration DOES work for syslog-ng 3.x.  It amounts to a way to
> tell syslog-ng 3.x to construct a string just like what syslog-ng 2.x
> would have produced from "$DATE $FULLHOST $MESSAGE\n":
> 
> #SSHGuard
> 
> # pass only entries with auth+authpriv facilities that contain sshd
> 
> filter f_sshlogs { facility(auth, authpriv) and match("sshd"); };
> 
> # pass to this process with this template (avoids <ID> prefixes)
> 
> destination sshguardproc {
> 
>        program("/usr/sbin/sshguard -a 3" template("$DATE $FULLHOST $PROGRAM[$PID]: $MESSAGE\n"));
> 
> };
> 
> log { source(src); filter(f_sshlogs); destination(sshguardproc); };
> 
> 
> All this does is restore the program name, the PID in brackets, and the
> colon.  Regarding SSHGuard, the difference between syslog-ng 2.x and
> syslog-ng 3.x is that the older one included those in $MESSAGE while the
> newer one does not.  I have verified that this does work correctly and
> will use iptables to halt a password-guessing attempt.
> 
> Is there any way the SSHGuard homepage can be updated to reflect this
> information?  If it is not updated, then other users are likely to find
> themselves in a situation where they perfectly follow all instructions
> and it still doesn't work, which is most frustrating.
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Syslog-ng 3.x Configuration

[Peter B. <be...@an...>]

On Fri, 4 Dec 2009, Byron wrote:

> The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
> details how to set up SSHGuard to work with syslog-ng.

  You must have not read the sshguard-users archives before posting, this
  was mentioned and answered a few days ago:

  http://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
be...@an...                                 http://www.angryox.com/
---------------------------------------------------------------------------

[Sshguard-users] Syslog-ng 3.x Configuration

[Byron <neg...@ve...>]

Hello,


The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
details how to set up SSHGuard to work with syslog-ng.

Unfortunately, I think this information is outdated.  It does not seem
to work correctly with syslog-ng version 3.x.  Nowhere on that Web page
does it specify the syslog-ng version for which the instructions are
intended, so those using newer syslog-ng versions may come to this page
and unknowingly receive incorrect instructions.  I believe that is what
happened to me.  Specifically, that page asks the user to add these
lines to /etc/syslog-ng/syslog-ng.conf:

# pass only entries with auth+authpriv facilities that contain sshd
filter sshlogs { facility(auth, authpriv) and match("sshd"); };
# pass to this process with this template (avoids <ID> prefixes)
destination sshguardproc {
        program("/usr/local/sbin/sshguard"  template("$DATE $FULLHOST $MESSAGE\n"));
};
log { source(src); filter(sshlogs); destination(sshguardproc); };

This will not only fail to work, it also will not give any error
messages of any kind.  The logfiles will show that sshguard starts up,
but then when SSH/SFTP activity occurs, absolutely nothing happens no
matter how many failed login attempts are received.

What compounds the problem is that no documentation I could find
actually explains what kind of string (from the logs) SSHGuard is
expecting.  Therefore, much trial and error was required to figure out
why that didn't work.  More on that later.

In syslog-ng version 2.x, the template "$DATE $FULLHOST $MESSAGE\n" will
produce a string like this:

"Dec  4 19:00:19 localhost sshd[30708]: Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"


In syslog-ng version 3.x, the template macros have changed.  Now the
template "$DATE $FULLHOST $MESSAGE\n" will produce a string like this:

"Dec  4 19:00:19 localhost Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"


And that latter one doesn't work.  SSHGuard seems to just ignore it and
does not act on it at all, though the SSHGuard process is running.

It turns out that apparently, SSHGuard needs to see the brackets and the
colon (or maybe just the colon) to correctly parse the string.  I
couldn't find that mentioned anywhere in the man pages, the Web site,
forums, etc.  I think documentation should include information like this
but it doesn't seem to.  When there is a problem, how is the user to
validate that they are feeding SSHGuard the correct information if they
don't know what SSHGuard is expecting or how it parses the string?  I
determined this through trial and error by playing with the macros
(variables) inside of the "template()" string.

This configuration DOES work for syslog-ng 3.x.  It amounts to a way to
tell syslog-ng 3.x to construct a string just like what syslog-ng 2.x
would have produced from "$DATE $FULLHOST $MESSAGE\n":

#SSHGuard

# pass only entries with auth+authpriv facilities that contain sshd

filter f_sshlogs { facility(auth, authpriv) and match("sshd"); };

# pass to this process with this template (avoids <ID> prefixes)

destination sshguardproc {

        program("/usr/sbin/sshguard -a 3" template("$DATE $FULLHOST $PROGRAM[$PID]: $MESSAGE\n"));

};

log { source(src); filter(f_sshlogs); destination(sshguardproc); };


All this does is restore the program name, the PID in brackets, and the
colon.  Regarding SSHGuard, the difference between syslog-ng 2.x and
syslog-ng 3.x is that the older one included those in $MESSAGE while the
newer one does not.  I have verified that this does work correctly and
will use iptables to halt a password-guessing attempt.

Is there any way the SSHGuard homepage can be updated to reflect this
information?  If it is not updated, then other users are likely to find
themselves in a situation where they perfectly follow all instructions
and it still doesn't work, which is most frustrating.

Re: [Sshguard-users] sshguard & proftpd issues - continued

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

Hello Lego,

did you try to run sshguard in debug/interactive mode?
Have a look at
http://www.sshguard.net/docs/faqs/#does-not-detect
(just updated)



On Nov 20, 2009, at 20:22 , Lego wrote:

> 
> First I would like to say thanks to David Horn for helping so far; This is
> a continuation of my last thread.  I now successfully have sshguard 1.4
> installed and blocking sshd & dovecot again, But still Having issues with
> proftpd.
> 
> [code]
> Nov 20 14:12:09 blurr-ink proftpd[1382]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:12:09 blurr-ink proftpd[1382]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:12:24 blurr-ink proftpd[1385]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:12:24 blurr-ink proftpd[1385]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:12:40 blurr-ink proftpd[1386]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:12:40 blurr-ink proftpd[1386]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:13:19 blurr-ink proftpd[1455]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:13:19 blurr-ink proftpd[1455]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:13:34 blurr-ink proftpd[1456]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:13:34 blurr-ink proftpd[1456]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:13:50 blurr-ink proftpd[1457]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:13:50 blurr-ink proftpd[1457]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:14:06 blurr-ink proftpd[1460]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
> Incorrect password.
> Nov 20 14:14:06 blurr-ink proftpd[1460]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
> Nov 20 14:14:30 blurr-ink proftpd[1464]: localhost
> (dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego: Login
> successful.
> [/code]
> 
> My syslog.conf
> [code]
> auth.info;authpriv.info;ftp.info;mail.info     |exec
> /usr/local/sbin/sshguard -f 310:/var/run/proftpd.pid -f
> 100:/var/run/sshd.pid -f 210:/var/run/dovecot/master.pid -w 127.0.0.1 -a 5
> auth.info;authpriv.info;ftp.info;mail.info       /var/log/sshguard.log
> [/code]
> 
> 
> As I said I have been able to block myself when attemping to log in to sshd
> or dovecot, but when I try to Log into ftp with incorrect credentials it
> still just lets me keep trying over and over.
> 
> -- 
> Sincerely,
> 
> Lego
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Gotcha when upgrading to syslog-ng-3.0

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

Thanks, I'll add this remark to the relevant setup page.


On Nov 16, 2009, at 21:08 , Adam James wrote:

> Hello all,
> 
> Just thought I should mention that if you're piping messages into
> sshguard via syslog-ng, you'll probably find that blocking stops
> working when you upgrade to syslog-ng version 3.0. This is due to a
> subtle change in message format macros.
> 
> The recommended configuration for version 2.x looks something like this:
> 
> destination sshguard {
>        program("/usr/sbin/sshguard"
>                template("$DATE $FULLHOST $MESSAGE\n")
>        );
> };
> filter f_sshguard { facility(auth, authpriv) and match("sshd"); };
> log { source(src); filter(f_sshguard); destination(sshguard); };
> 
> In previous versions $MESSAGE included the program name and pid.
> However this has changed in version 3.0. You now need to include
> $MSGHDR:
> 
> destination sshguard {
>        program("/usr/sbin/sshguard"
>                template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
>        );
> };
> filter f_sshguard { facility(auth, authpriv) and program("sshd"); };
> log { source(src); filter(f_sshguard); destination(sshguard); };
> 
> Note that I also changed match() to program() in the filter, this stops
> syslog-ng complaining about a deprecated use of match.
> 
> Hopefully this might prevent someone else suddenly realising their
> blocking isn't working and then spending 20 minutes trying to figure
> out what has changed!
> 
> 
> Cheers,
> 
> - atj
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] sshguard & proftpd issues - continued

[Lego <le...@bl...>]

First I would like to say thanks to David Horn for helping so far; This is
a continuation of my last thread.  I now successfully have sshguard 1.4
installed and blocking sshd & dovecot again, But still Having issues with
proftpd.

[code]
Nov 20 14:12:09 blurr-ink proftpd[1382]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:12:09 blurr-ink proftpd[1382]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:12:24 blurr-ink proftpd[1385]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:12:24 blurr-ink proftpd[1385]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:12:40 blurr-ink proftpd[1386]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:12:40 blurr-ink proftpd[1386]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:13:19 blurr-ink proftpd[1455]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:13:19 blurr-ink proftpd[1455]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:13:34 blurr-ink proftpd[1456]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:13:34 blurr-ink proftpd[1456]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:13:50 blurr-ink proftpd[1457]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:13:50 blurr-ink proftpd[1457]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:14:06 blurr-ink proftpd[1460]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego (Login failed):
Incorrect password.
Nov 20 14:14:06 blurr-ink proftpd[1460]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - FTP session closed.
Nov 20 14:14:30 blurr-ink proftpd[1464]: localhost
(dyn216-8-133-228.ADSL.mnsi.net[216.8.133.228]) - USER lego: Login
successful.
[/code]

My syslog.conf
[code]
auth.info;authpriv.info;ftp.info;mail.info     |exec
/usr/local/sbin/sshguard -f 310:/var/run/proftpd.pid -f
100:/var/run/sshd.pid -f 210:/var/run/dovecot/master.pid -w 127.0.0.1 -a 5
auth.info;authpriv.info;ftp.info;mail.info       /var/log/sshguard.log
[/code]


As I said I have been able to block myself when attemping to log in to sshd
or dovecot, but when I try to Log into ftp with incorrect credentials it
still just lets me keep trying over and over.

-- 
Sincerely,

Lego

[Sshguard-users] Gotcha when upgrading to syslog-ng-3.0

[Adam J. <at...@pu...>]

Hello all,

Just thought I should mention that if you're piping messages into
sshguard via syslog-ng, you'll probably find that blocking stops
working when you upgrade to syslog-ng version 3.0. This is due to a
subtle change in message format macros.

The recommended configuration for version 2.x looks something like this:

destination sshguard {
        program("/usr/sbin/sshguard"
                template("$DATE $FULLHOST $MESSAGE\n")
        );
};
filter f_sshguard { facility(auth, authpriv) and match("sshd"); };
log { source(src); filter(f_sshguard); destination(sshguard); };

In previous versions $MESSAGE included the program name and pid.
However this has changed in version 3.0. You now need to include
$MSGHDR:

destination sshguard {
        program("/usr/sbin/sshguard"
                template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
        );
};
filter f_sshguard { facility(auth, authpriv) and program("sshd"); };
log { source(src); filter(f_sshguard); destination(sshguard); };

Note that I also changed match() to program() in the filter, this stops
syslog-ng complaining about a deprecated use of match.

Hopefully this might prevent someone else suddenly realising their
blocking isn't working and then spending 20 minutes trying to figure
out what has changed!


Cheers,

- atj

Re: [Sshguard-users] sshguard & proftpd issues

[David H. <dho...@gm...>]

On Mon, Nov 16, 2009 at 3:27 AM, Lego <le...@bl...> wrote:
>
> Hello All, I'm not quite sure how this all works yet, I'm new to mailing
> lists.   Anyway, I've been using sshguard, and have been very pleased with
> the service so far.
>
> But, I have ran into a small problem, sshguard is blocking connections to
> sshd & dovecot properly;  However, it is not blocking connections to
> proftpd.

My first reaction would be to have you try with the latest stable
version of sshguard (1.4).  The source code can be found here:

http://sourceforge.net/projects/sshguard/

sshguard 1.4 is not yet in FreeBSD ports, but hopefully will be soon.
(Mij, do you want help on this ?)

The documentation for compiling can be found here:
http://sshguard.sourceforge.net/doc/setup/compileinstall1x.html

In your case, make sure you set the firewall to pf (  ./configure
--with-firewall=pf  )

sshguard 1.4 fixes some known issues with proftpd log messages, but
since I neither run proftpd, or pf on my FreeBSD system, I can not
give specific examples to that configuration, but try 1.4 and report
back to the list.

If you still have issues after upgrading to 1.4, then try getting some
debug output from sshguard so that you can determine if sshguard
"sees" the attack pattern from proftpd in your configuration.

http://sshguard.sourceforge.net/doc/faq.html

>
> Anyway, I will supply all the information I can and hopefully someone can
> point me in the right direction.  I am using FreeBSD 7.1-Release and
> sshguard 1.3, and many network services not worth mentioning.  Anyway, I
> currently have been seeking help on the FreeBSD forum and was directed to
> try the sshguard mailing list.
>
> This is my thread:  http://forums.freebsd.org/showthread.php?t=8334
>
> My syslog.conf consists of this:
> [code]
> auth.info;authpriv.info;ftp.info;mail.info     |exec
> /usr/local/sbin/sshguard -f 310:/var/run/proftpd.pid -f
> 100:/var/run/sshd.pid -f 210:/var/run/dovecot/master.pid -w 127.0.0.1 -a 5
> [/code]
>
> As I have mentioned sshguard is working properly for sshd & dovecot,
> however I cannnot seem to get it to monitor proftpd properly, I have
> confirmed that the proftpd authentication information is being passed to
> sshguard (If you check the thread there is more detail of what is
> happening, and what trouble shooting steps I have already taken).
>
> Any Information or direction would be very appreciated, Also is there
> anyway to have sshguard monitor webmin/mysql or phpMyAdmin login attempts??
>
> Thanks For your Time
>
> Dan Champagne
> Blurr-ink.com
>

Here is the sshguard 1.4 changelist:

* 1.4       Aug 2009
    - add touchiness: block repeated abusers for longer
    - add blacklisting: store frequent abusers for permanent blocking
    - add support for IPv6 in whitelisting (experimental)
    - sshguard ignores interrupted fgets() and reloads more seldom
(thanks Keven Tipping)
    - debug mode now enabled with SSHGUARD_DEBUG environment variable (no "-d")
    - support non-POSIX libCs that require getopt.h (thanks Nobuhiro Iwamatsu)
    - import newer SimCList containing a number of fixes and improvements
    - firewall backends now block all traffic from attackers by
default, not per-service
    - netfilter/iptables backend now verifies credentials at initialization
    - parser accepts "-" and "_" chars in process names
    - fix detection of some ProFTPd and pure-ftp messages
    - support log formats of new versions of ProFTPd
    - fix one dovecot pattern
    - correctly handle abuse threshold = 1 (thanks K. Tipping)
    - fix handling of IPv6 with IPFW under Mac OS X Leopard (thanks David Horn)
    - fix cmdline argument BoF exploitable by local users when
sshguard is setuid
    - support blocking IPv6 addrs in backed "hosts.allow"
    - extend hosts.allow backend to support all service types
    - localhost addresses are now whitelisted a priori
    - extend IPv6 pattern for matching special addresses (eg, IPv4 embedded)
    - fix grammar to be insensitive to a log injection in sshd (thanks
J. Oosterveen)


Good Luck.

---Dave

[Sshguard-users] sshguard & proftpd issues

[Lego <le...@bl...>]

Hello All, I'm not quite sure how this all works yet, I'm new to mailing
lists.   Anyway, I've been using sshguard, and have been very pleased with
the service so far.

But, I have ran into a small problem, sshguard is blocking connections to
sshd & dovecot properly;  However, it is not blocking connections to
proftpd.

Anyway, I will supply all the information I can and hopefully someone can
point me in the right direction.  I am using FreeBSD 7.1-Release and
sshguard 1.3, and many network services not worth mentioning.  Anyway, I
currently have been seeking help on the FreeBSD forum and was directed to
try the sshguard mailing list.

This is my thread:  http://forums.freebsd.org/showthread.php?t=8334

My syslog.conf consists of this:
[code]
auth.info;authpriv.info;ftp.info;mail.info     |exec
/usr/local/sbin/sshguard -f 310:/var/run/proftpd.pid -f
100:/var/run/sshd.pid -f 210:/var/run/dovecot/master.pid -w 127.0.0.1 -a 5
[/code]

As I have mentioned sshguard is working properly for sshd & dovecot,
however I cannnot seem to get it to monitor proftpd properly, I have
confirmed that the proftpd authentication information is being passed to
sshguard (If you check the thread there is more detail of what is
happening, and what trouble shooting steps I have already taken).

Any Information or direction would be very appreciated, Also is there
anyway to have sshguard monitor webmin/mysql or phpMyAdmin login attempts??

Thanks For your Time

Dan Champagne
Blurr-ink.com

Re: [Sshguard-users] Blocking Attacks

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

the general answer is: working on "attack density" is in TODO.  
Sshguard would
score different patterns with different ways and block when a  
"disturbance level"
is reached. Search previous posts in the ml for more details.


In the specific case of sshd: I'm not sure running the cat-and-mouse  
is the best
approach: logs would still be tainted, there would be not much better  
protection,
and by my experience often their IP pool is so large that you don't  
even see rotation.
See previous post for more details.

I have some ideas for solving this one, but ain't very happy with any.  
The way
DenyHosts (sharing DoS information) is insecure: I can taint the  
global blacklist
by injecting legitimate hosts, thus DoSing thousands of sites.
The "smart" way of measuring the density of attacks and tarpitting TCP  
handshakes
when we're in "distributed attack mode" may prevent of disturb  
legitimate users.

If some users want to share ideas on that, they're highly welcome.  
Otherwise this
task will stay in the idle TODO..



On Oct 2, 2009, at 20:50 , Art Salihu wrote:

> Is there a away to setup certain types of log messages to be banned  
> on first attempt, and the rest at the default of 4?  The reason why  
> I ask is because I like the idea of the default of 4, since users  
> can make mistakes when trying to log in, and that gives them a  
> little room for error, but there are certain log entries that I feel  
> should be banned on first attempt, example.
>
> Oct  2 13:26:27 srvtwc sshd[7642]: User root from mx.referent.ru not  
> allowed because not listed in AllowUsers
> Oct  2 13:26:27 srvtwc sshguard[30833]: Successfully resolved  
> 'mx.referent.ru' --> 4:'86.111.5.38'.
> Oct  2 13:26:27 srvtwc sshguard[30833]: Matched address  
> 86.111.5.38:4 attacking service 100
> Oct  2 13:26:28 srvtwc sshd[7642]: error: PAM: Authentication  
> failure for illegal user root from mx.referent.ru
> Oct  2 13:26:28 srvtwc sshd[7642]: Failed keyboard-interactive/pam  
> for invalid user root from 86.111.5.38 port 33046 ssh2
> Oct  2 13:26:28 srvtwc sshguard[30833]: Matched address  
> 86.111.5.38:4 attacking service 100
> Oct  2 13:27:43 srvtwc sshd[7645]: User root from 119-210-96-87.cust.blixtvik.se 
>  not allowed because not listed in AllowUsers
> Oct  2 13:27:43 srvtwc sshguard[30833]: Successfully resolved  
> '119-210-96-87.cust.blixtvik.se' --> 4:'87.96.210.119'.
> Oct  2 13:27:43 srvtwc sshguard[30833]: Matched address  
> 87.96.210.119:4 attacking service 100
> Oct  2 13:27:43 srvtwc sshd[7645]: error: PAM: Authentication  
> failure for illegal user root from 119-210-96-87.cust.blixtvik.se
> Oct  2 13:27:43 srvtwc sshd[7645]: Failed keyboard-interactive/pam  
> for invalid user root from 87.96.210.119 port 41754 ssh2
> Oct  2 13:27:43 srvtwc sshguard[30833]: Matched address  
> 87.96.210.119:4 attacking service 100
> Oct  2 13:28:49 srvtwc sshd[7649]: User root from static-87-79-66-203.netcologne.de 
>  not allowed because not listed in AllowUsers
> Oct  2 13:28:49 srvtwc sshguard[30833]: Successfully resolved  
> 'static-87-79-66-203.netcologne.de' --> 4:'87.79.66.203'.
> Oct  2 13:28:49 srvtwc sshguard[30833]: Matched address  
> 87.79.66.203:4 attacking service 100
> Oct  2 13:28:50 srvtwc sshd[7649]: error: PAM: Authentication  
> failure for illegal user root from static-87-79-66-203.netcologne.de
> Oct  2 13:28:50 srvtwc sshd[7649]: Failed keyboard-interactive/pam  
> for invalid user root from 87.79.66.203 port 51639 ssh2
> Oct  2 13:28:50 srvtwc sshguard[30833]: Matched address  
> 87.79.66.203:4 attacking service 100
>
> I've noticed in my logs recently since I've started to use sshguard,  
> that the attackers scripts are smart enough to know, or remember,  
> that your server is running sshguard or a service similar, and will  
> attempt brute force attacks from a rotating set of ip's as to which  
> they will never get banned by doing this so long as they have enough  
> ip's to come in from.  The logs show that sshguard is picking it up  
> as an attack properly, but by the time they cycle through their list  
> of remote ip's and use one that sshguard has seen already, it's been  
> over the time period where it would count it as a second attack.
>
> Anything that shows up as "not lised in AllowUsers" or "failure for  
> illegal user xxx" should be banned on first attempt.  That would be  
> a great addition to your already awesome app.
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Question

[Emmanuel A. <man...@gm...>]

Hum,

I will change my ssh port number to try solve this problem.

Thank you so much Mij.

[]s

Emmanuel Alves
man...@gm...

---------------------------------------------------------------------
Twitter: http://www.twitter.com/emartsnet
Linked In: http://www.linkedin.com/in/emartsnet


On Mon, Oct 5, 2009 at 9:53 AM, Mij <mi...@ss...> wrote:

> Nothing is wrong, but the fact you're not being attacked by one
> insisting host, but by
> many in distributed fashion. There is no simple way to detect these:
> imagine you're
> running a shell server with many accesses, how would you spot this is
> a distributed
> attack rather than a "funnily many users got the password wrong in a
> short period of
> time" ? And similarly, even once you detect this, what do you do then?
>
> Detecting these is hard, but we have that in a TODO idle loop.
>
>
> On Oct 2, 2009, at 13:00 , Emmanuel Alves wrote:
>
> > Hi,
> >
> > My SSHGUARD was working perfectly, but since 2 days ago, my security
> > log has a lot of blocked IPs, but i cant find any failures to access
> > my ssh... here is part of my log:
> >
> > Oct  1 09:15:41 brain sshguard[77308]: Blocking 200.11.197.122: 4
> > failures over 2 seconds.
> > Oct  1 09:16:24 brain sshguard[77308]: Blocking 147.52.242.30: 4
> > failures over 0 seconds.
> > Oct  1 09:17:27 brain sshguard[77308]: Blocking 217.15.119.130: 4
> > failures over 0 seconds.
> > Oct  1 09:17:54 brain sshguard[77308]: Blocking 77.95.0.100: 4
> > failures over 0 seconds.
> > Oct  1 09:18:45 brain sshguard[77308]: Blocking 118.98.171.107: 4
> > failures over 4 seconds.
> > Oct  1 09:19:27 brain sshguard[77308]: Blocking 83.142.126.50: 4
> > failures over 1 seconds.
> > Oct  1 09:20:25 brain sshguard[77308]: Release command failed.
> > Exited: -1
> > Oct  1 09:20:55 brain sshguard[77308]: Blocking 69.213.134.19: 4
> > failures over 7 seconds.
> > Oct  1 09:21:31 brain sshguard[77308]: Blocking 203.198.161.20: 4
> > failures over 0 seconds.
> > Oct  1 09:22:18 brain sshguard[77308]: Blocking 217.111.114.216: 4
> > failures over 0 seconds.
> > Oct  1 09:22:55 brain sshguard[77308]: Blocking 88.84.142.50: 4
> > failures over 0 seconds.
> > Oct  1 09:23:32 brain sshguard[77308]: Release command failed.
> > Exited: -1
> > Oct  1 09:23:32 brain sshguard[77308]: Release command failed.
> > Exited: -1
> > Oct  1 09:24:30 brain sshguard[77308]: Blocking 60.28.10.26: 4
> > failures over 139 seconds.
> > Oct  1 09:25:16 brain sshguard[77308]: Blocking 82.98.78.31: 4
> > failures over 0 seconds.
> > Oct  1 09:25:55 brain sshguard[77308]: Blocking 202.78.239.203: 4
> > failures over 1 seconds.
> > Oct  1 09:26:43 brain sshguard[77308]: Blocking 69.129.125.162: 4
> > failures over 3 seconds.
> > Oct  1 09:27:28 brain sshguard[77308]: Blocking 61.183.0.35: 4
> > failures over 0 seconds.
> > Oct  1 09:28:12 brain sshguard[77308]: Blocking 83.132.104.248: 4
> > failures over 0 seconds.
> > Oct  1 09:28:52 brain sshguard[77308]: Blocking 61.172.200.198: 4
> > failures over 1 seconds.
> > Oct  1 09:29:57 brain sshguard[77308]: Blocking 83.142.126.51: 4
> > failures over 1 seconds.
> > Oct  1 09:30:31 brain sshguard[77308]: Blocking 211.137.70.137: 4
> > failures over 3 seconds.
> > Oct  1 09:31:04 brain sshguard[77308]: Blocking 202.107.85.254: 4
> > failures over 710 seconds.
> > Oct  1 09:31:52 brain sshguard[77308]: Blocking 58.185.182.212: 4
> > failures over 0 seconds.
> > Oct  1 09:32:37 brain sshguard[77308]: Blocking 61.131.208.44: 4
> > failures over 1 seconds.
> > Oct  1 09:32:59 brain sshguard[77308]: Release command failed.
> > Exited: -1
> > Oct  1 09:32:59 brain sshguard[77308]: Release command failed.
> > Exited: -1
> > Oct  1 09:33:22 brain sshguard[77308]: Blocking 147.52.242.39: 4
> > failures over 0 seconds.
> > Oct  1 09:34:00 brain sshguard[77308]: Blocking 80.219.210.151: 4
> > failures over 0 seconds.
> > Oct  1 09:34:56 brain sshguard[77308]: Blocking 79.29.174.11: 4
> > failures over 3 seconds.
> > Oct  1 09:35:33 brain sshguard[77308]: Blocking 212.235.9.44: 4
> > failures over 0 seconds.
> > Oct  1 09:36:19 brain sshguard[77308]: Blocking 196.201.228.186: 4
> > failures over 0 seconds.
> > Oct  1 09:37:45 brain sshguard[77308]: Blocking 189.56.92.42: 4
> > failures over 1 seconds.
> >
> > I´m wrong?
> >
> > []s
> >
> > Emmanuel Alves
> > man...@gm...
> >
> > ---------------------------------------------------------------------
> > Twitter: http://www.twitter.com/emartsnet
> > Linked In: http://www.linkedin.com/in/emartsnet
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> >
> http://p.sf.net/sfu/devconf_______________________________________________
> > Sshguard-users mailing list
> > Ssh...@li...
> > https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] sshguard adn proftp?

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

all "protection" comes out of the box. You just make sure that  
sshguard receives
the log messages produced by proftpd.


On Sep 28, 2009, at 21:41 , Paul Bliss wrote:

> Hello all,
>  I've got sshguard running and protecting my SSH logins just fine,  
> but I'm
> confused as to how to add ProFTPD protection as well. The  
> documentation
> seems to assume that I'm smarter than I actually am.
>
> Thanks!
> -Mechno
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Question

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

Nothing is wrong, but the fact you're not being attacked by one  
insisting host, but by
many in distributed fashion. There is no simple way to detect these:  
imagine you're
running a shell server with many accesses, how would you spot this is  
a distributed
attack rather than a "funnily many users got the password wrong in a  
short period of
time" ? And similarly, even once you detect this, what do you do then?

Detecting these is hard, but we have that in a TODO idle loop.


On Oct 2, 2009, at 13:00 , Emmanuel Alves wrote:

> Hi,
>
> My SSHGUARD was working perfectly, but since 2 days ago, my security  
> log has a lot of blocked IPs, but i cant find any failures to access  
> my ssh... here is part of my log:
>
> Oct  1 09:15:41 brain sshguard[77308]: Blocking 200.11.197.122: 4  
> failures over 2 seconds.
> Oct  1 09:16:24 brain sshguard[77308]: Blocking 147.52.242.30: 4  
> failures over 0 seconds.
> Oct  1 09:17:27 brain sshguard[77308]: Blocking 217.15.119.130: 4  
> failures over 0 seconds.
> Oct  1 09:17:54 brain sshguard[77308]: Blocking 77.95.0.100: 4  
> failures over 0 seconds.
> Oct  1 09:18:45 brain sshguard[77308]: Blocking 118.98.171.107: 4  
> failures over 4 seconds.
> Oct  1 09:19:27 brain sshguard[77308]: Blocking 83.142.126.50: 4  
> failures over 1 seconds.
> Oct  1 09:20:25 brain sshguard[77308]: Release command failed.  
> Exited: -1
> Oct  1 09:20:55 brain sshguard[77308]: Blocking 69.213.134.19: 4  
> failures over 7 seconds.
> Oct  1 09:21:31 brain sshguard[77308]: Blocking 203.198.161.20: 4  
> failures over 0 seconds.
> Oct  1 09:22:18 brain sshguard[77308]: Blocking 217.111.114.216: 4  
> failures over 0 seconds.
> Oct  1 09:22:55 brain sshguard[77308]: Blocking 88.84.142.50: 4  
> failures over 0 seconds.
> Oct  1 09:23:32 brain sshguard[77308]: Release command failed.  
> Exited: -1
> Oct  1 09:23:32 brain sshguard[77308]: Release command failed.  
> Exited: -1
> Oct  1 09:24:30 brain sshguard[77308]: Blocking 60.28.10.26: 4  
> failures over 139 seconds.
> Oct  1 09:25:16 brain sshguard[77308]: Blocking 82.98.78.31: 4  
> failures over 0 seconds.
> Oct  1 09:25:55 brain sshguard[77308]: Blocking 202.78.239.203: 4  
> failures over 1 seconds.
> Oct  1 09:26:43 brain sshguard[77308]: Blocking 69.129.125.162: 4  
> failures over 3 seconds.
> Oct  1 09:27:28 brain sshguard[77308]: Blocking 61.183.0.35: 4  
> failures over 0 seconds.
> Oct  1 09:28:12 brain sshguard[77308]: Blocking 83.132.104.248: 4  
> failures over 0 seconds.
> Oct  1 09:28:52 brain sshguard[77308]: Blocking 61.172.200.198: 4  
> failures over 1 seconds.
> Oct  1 09:29:57 brain sshguard[77308]: Blocking 83.142.126.51: 4  
> failures over 1 seconds.
> Oct  1 09:30:31 brain sshguard[77308]: Blocking 211.137.70.137: 4  
> failures over 3 seconds.
> Oct  1 09:31:04 brain sshguard[77308]: Blocking 202.107.85.254: 4  
> failures over 710 seconds.
> Oct  1 09:31:52 brain sshguard[77308]: Blocking 58.185.182.212: 4  
> failures over 0 seconds.
> Oct  1 09:32:37 brain sshguard[77308]: Blocking 61.131.208.44: 4  
> failures over 1 seconds.
> Oct  1 09:32:59 brain sshguard[77308]: Release command failed.  
> Exited: -1
> Oct  1 09:32:59 brain sshguard[77308]: Release command failed.  
> Exited: -1
> Oct  1 09:33:22 brain sshguard[77308]: Blocking 147.52.242.39: 4  
> failures over 0 seconds.
> Oct  1 09:34:00 brain sshguard[77308]: Blocking 80.219.210.151: 4  
> failures over 0 seconds.
> Oct  1 09:34:56 brain sshguard[77308]: Blocking 79.29.174.11: 4  
> failures over 3 seconds.
> Oct  1 09:35:33 brain sshguard[77308]: Blocking 212.235.9.44: 4  
> failures over 0 seconds.
> Oct  1 09:36:19 brain sshguard[77308]: Blocking 196.201.228.186: 4  
> failures over 0 seconds.
> Oct  1 09:37:45 brain sshguard[77308]: Blocking 189.56.92.42: 4  
> failures over 1 seconds.
>
> I´m wrong?
>
> []s
>
> Emmanuel Alves
> man...@gm...
>
> ---------------------------------------------------------------------
> Twitter: http://www.twitter.com/emartsnet
> Linked In: http://www.linkedin.com/in/emartsnet
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Blocking Attacks

[Art S. <art...@gm...>]

Is there a away to setup certain types of log messages to be banned on first
attempt, and the rest at the default of 4?  The reason why I ask is because
I like the idea of the default of 4, since users can make mistakes when
trying to log in, and that gives them a little room for error, but there are
certain log entries that I feel should be banned on first attempt, example.

Oct  2 13:26:27 srvtwc sshd[7642]: User root from mx.referent.ru not allowed
because not listed in AllowUsers
Oct  2 13:26:27 srvtwc sshguard[30833]: Successfully resolved '
mx.referent.ru' --> 4:'86.111.5.38'.
Oct  2 13:26:27 srvtwc sshguard[30833]: Matched address
86.111.5.38:4attacking service 100
Oct  2 13:26:28 srvtwc sshd[7642]: error: PAM: Authentication failure for
illegal user root from mx.referent.ru
Oct  2 13:26:28 srvtwc sshd[7642]: Failed keyboard-interactive/pam for
invalid user root from 86.111.5.38 port 33046 ssh2
Oct  2 13:26:28 srvtwc sshguard[30833]: Matched address
86.111.5.38:4attacking service 100
Oct  2 13:27:43 srvtwc sshd[7645]: User root from
119-210-96-87.cust.blixtvik.se not allowed because not listed in AllowUsers
Oct  2 13:27:43 srvtwc sshguard[30833]: Successfully resolved '
119-210-96-87.cust.blixtvik.se' --> 4:'87.96.210.119'.
Oct  2 13:27:43 srvtwc sshguard[30833]: Matched address
87.96.210.119:4attacking service 100
Oct  2 13:27:43 srvtwc sshd[7645]: error: PAM: Authentication failure for
illegal user root from 119-210-96-87.cust.blixtvik.se
Oct  2 13:27:43 srvtwc sshd[7645]: Failed keyboard-interactive/pam for
invalid user root from 87.96.210.119 port 41754 ssh2
Oct  2 13:27:43 srvtwc sshguard[30833]: Matched address
87.96.210.119:4attacking service 100
Oct  2 13:28:49 srvtwc sshd[7649]: User root from
static-87-79-66-203.netcologne.de not allowed because not listed in
AllowUsers
Oct  2 13:28:49 srvtwc sshguard[30833]: Successfully resolved '
static-87-79-66-203.netcologne.de' --> 4:'87.79.66.203'.
Oct  2 13:28:49 srvtwc sshguard[30833]: Matched address
87.79.66.203:4attacking service 100
Oct  2 13:28:50 srvtwc sshd[7649]: error: PAM: Authentication failure for
illegal user root from static-87-79-66-203.netcologne.de
Oct  2 13:28:50 srvtwc sshd[7649]: Failed keyboard-interactive/pam for
invalid user root from 87.79.66.203 port 51639 ssh2
Oct  2 13:28:50 srvtwc sshguard[30833]: Matched address
87.79.66.203:4attacking service 100

I've noticed in my logs recently since I've started to use sshguard, that
the attackers scripts are smart enough to know, or remember, that your
server is running sshguard or a service similar, and will attempt brute
force attacks from a rotating set of ip's as to which they will never get
banned by doing this so long as they have enough ip's to come in from.  The
logs show that sshguard is picking it up as an attack properly, but by the
time they cycle through their list of remote ip's and use one that sshguard
has seen already, it's been over the time period where it would count it as
a second attack.

Anything that shows up as "not lised in AllowUsers" or "failure for illegal
user xxx" should be banned on first attempt.  That would be a great addition
to your already awesome app.

[Sshguard-users] Question

[Emmanuel A. <man...@gm...>]

Hi,

My SSHGUARD was working perfectly, but since 2 days ago, my security log has
a lot of blocked IPs, but i cant find any failures to access my ssh... here
is part of my log:

Oct  1 09:15:41 brain sshguard[77308]: Blocking 200.11.197.122: 4 failures
> over 2 seconds.
> Oct  1 09:16:24 brain sshguard[77308]: Blocking 147.52.242.30: 4 failures
> over 0 seconds.
> Oct  1 09:17:27 brain sshguard[77308]: Blocking 217.15.119.130: 4 failures
> over 0 seconds.
> Oct  1 09:17:54 brain sshguard[77308]: Blocking 77.95.0.100: 4 failures
> over 0 seconds.
> Oct  1 09:18:45 brain sshguard[77308]: Blocking 118.98.171.107: 4 failures
> over 4 seconds.
> Oct  1 09:19:27 brain sshguard[77308]: Blocking 83.142.126.50: 4 failures
> over 1 seconds.
> Oct  1 09:20:25 brain sshguard[77308]: Release command failed. Exited: -1
> Oct  1 09:20:55 brain sshguard[77308]: Blocking 69.213.134.19: 4 failures
> over 7 seconds.
> Oct  1 09:21:31 brain sshguard[77308]: Blocking 203.198.161.20: 4 failures
> over 0 seconds.
> Oct  1 09:22:18 brain sshguard[77308]: Blocking 217.111.114.216: 4
> failures over 0 seconds.
> Oct  1 09:22:55 brain sshguard[77308]: Blocking 88.84.142.50: 4 failures
> over 0 seconds.
> Oct  1 09:23:32 brain sshguard[77308]: Release command failed. Exited: -1
> Oct  1 09:23:32 brain sshguard[77308]: Release command failed. Exited: -1
> Oct  1 09:24:30 brain sshguard[77308]: Blocking 60.28.10.26: 4 failures
> over 139 seconds.
> Oct  1 09:25:16 brain sshguard[77308]: Blocking 82.98.78.31: 4 failures
> over 0 seconds.
> Oct  1 09:25:55 brain sshguard[77308]: Blocking 202.78.239.203: 4 failures
> over 1 seconds.
> Oct  1 09:26:43 brain sshguard[77308]: Blocking 69.129.125.162: 4 failures
> over 3 seconds.
> Oct  1 09:27:28 brain sshguard[77308]: Blocking 61.183.0.35: 4 failures
> over 0 seconds.
> Oct  1 09:28:12 brain sshguard[77308]: Blocking 83.132.104.248: 4 failures
> over 0 seconds.
> Oct  1 09:28:52 brain sshguard[77308]: Blocking 61.172.200.198: 4 failures
> over 1 seconds.
> Oct  1 09:29:57 brain sshguard[77308]: Blocking 83.142.126.51: 4 failures
> over 1 seconds.
> Oct  1 09:30:31 brain sshguard[77308]: Blocking 211.137.70.137: 4 failures
> over 3 seconds.
> Oct  1 09:31:04 brain sshguard[77308]: Blocking 202.107.85.254: 4 failures
> over 710 seconds.
> Oct  1 09:31:52 brain sshguard[77308]: Blocking 58.185.182.212: 4 failures
> over 0 seconds.
> Oct  1 09:32:37 brain sshguard[77308]: Blocking 61.131.208.44: 4 failures
> over 1 seconds.
> Oct  1 09:32:59 brain sshguard[77308]: Release command failed. Exited: -1
> Oct  1 09:32:59 brain sshguard[77308]: Release command failed. Exited: -1
> Oct  1 09:33:22 brain sshguard[77308]: Blocking 147.52.242.39: 4 failures
> over 0 seconds.
> Oct  1 09:34:00 brain sshguard[77308]: Blocking 80.219.210.151: 4 failures
> over 0 seconds.
> Oct  1 09:34:56 brain sshguard[77308]: Blocking 79.29.174.11: 4 failures
> over 3 seconds.
> Oct  1 09:35:33 brain sshguard[77308]: Blocking 212.235.9.44: 4 failures
> over 0 seconds.
> Oct  1 09:36:19 brain sshguard[77308]: Blocking 196.201.228.186: 4
> failures over 0 seconds.
> Oct  1 09:37:45 brain sshguard[77308]: Blocking 189.56.92.42: 4 failures
> over 1 seconds.
>

I´m wrong?

[]s

Emmanuel Alves
man...@gm...

---------------------------------------------------------------------
Twitter: http://www.twitter.com/emartsnet
Linked In: http://www.linkedin.com/in/emartsnet

[Sshguard-users] sshguard adn proftp?

[Paul B. <pb...@me...>]

Hello all,
  I've got sshguard running and protecting my SSH logins just fine, but I'm 
confused as to how to add ProFTPD protection as well. The documentation 
seems to assume that I'm smarter than I actually am.

Thanks!
-Mechno