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

Re: [Sshguard-users] sshguard working but not blocking, functioning in debug mode

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

On Tue, 21 Jul 2009, Mij wrote:

>
> On Jul 21, 2009, at 21:17 , Peter Beckman wrote:
>
>> On Tue, 21 Jul 2009, Mij wrote:
>>
>>> Naturally the same machinery is used for blocking with or without -
>>> d, so
>>> if in the latter case it works, is sshguard run as root from the
>>> syslog
>>> instance?
>>
>> syslogd is running as root, and since I've tested it in the past and
>> it
>> has worked, and I haven't updated anything, I was surprised to see the
>> failure.
>
> 2 things:
> 1) you show that with -d the address is visible in the PF table after
> blocking.
> What about the normal run?

  Wasn't around at the time of the attack, I only get notified at the end of
  the day when I get emailed the log.

  I upgraded to 1.4rc5 and tested manually, and it blocked successfully.
  Hopefully the bot-net tries again soon, and I'll see if the issue was
  resolved by upgrading.

  PS -- If you were bored, you could always create a few new FreeBSD Ports:

     sshguard-devel
     sshguard-devel-pf (or modify the sshguard-pf to have a flag to use
     sshguard-devel)

  I built a pseudo-hack port, but didn't spend enough time to figure out how
  to install it as sshguard-devel-1.4rc5 without figuring out how to tell it
  to download sshguard-1.4rc5.tar.gz from SourceForge.  Probably could with
  some time and effort, the former of which I have none of!

> 2) sshguard always logs debug messages (filtering/dispatching left up to
> syslogd). Have a look at your debug.log or all.log for debug messages.
> There you find whether/why the actual blocking command fails.

  Unfortunately FreeBSD sets the logging and rotation of debug.log extremely
  short, and the logs that would have given some insight into the issue are
  now rotated.  I've set my debug.log to rotate weekly instead of hourly,
  which should give some insight if things go wrong.

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

Re: [Sshguard-users] sshguard working but not blocking, functioning in debug mode

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

On Jul 21, 2009, at 21:17 , Peter Beckman wrote:

> On Tue, 21 Jul 2009, Mij wrote:
>
>> Naturally the same machinery is used for blocking with or without - 
>> d, so
>> if in the latter case it works, is sshguard run as root from the  
>> syslog
>> instance?
>
> syslogd is running as root, and since I've tested it in the past and  
> it
> has worked, and I haven't updated anything, I was surprised to see the
> failure.

2 things:
1) you show that with -d the address is visible in the PF table after  
blocking.
What about the normal run?

2) sshguard always logs debug messages (filtering/dispatching left up to
syslogd). Have a look at your debug.log or all.log for debug messages.
There you find whether/why the actual blocking command fails.

Re: [Sshguard-users] sshguard working but not blocking, functioning in debug mode

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

On Tue, 21 Jul 2009, Mij wrote:

> Naturally the same machinery is used for blocking with or without -d, so
> if in the latter case it works, is sshguard run as root from the syslog
> instance?

  syslogd is running as root, and since I've tested it in the past and it
  has worked, and I haven't updated anything, I was surprised to see the
  failure.

> Btw, we advice upgrading to 1.4rc5.

  I didn't see it updated in FreeBSD ports, so I didn't update it.  I've now
  updated it, will report back if I have the same problem again.

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

Re: [Sshguard-users] sshguard working but not blocking, functioning in debug mode

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

Naturally the same machinery is used for blocking with or without -d,  
so if in the
latter case it works, is sshguard run as root from the syslog instance?

Btw, we advice upgrading to 1.4rc5.


On Jul 21, 2009, at 19:51 , Peter Beckman wrote:

> My setup: FreeBSD using sshguard with pf.
>
> I've been recently attacked by a single IP over and over again.  I  
> set the
> -p to 2400, and sshguard seems to do as I request:
>
>   Jul 20 10:00:00 host sshguard[5331]: Started successfully  
> [(a,p,s)=(4, 2400, 1200)], now ready to scan.
>
> Great!  And sshguard seems to be doing the right thing:
>
>   Jul 20 10:50:32 host sshd[7233]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:35 host sshd[7235]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:37 host sshd[7237]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:39 host sshd[7239]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:39 host sshguard[5331]: Blocking 140.111.145.7: 4  
> failures over 7 seconds.
>
> But then:
>
>   Jul 20 10:50:41 host sshd[7243]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:44 host sshd[7250]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:46 host sshd[7252]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:48 host sshd[7255]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:48 host sshguard[5331]: Blocking 140.111.145.7: 4  
> failures over 7 seconds.
>   Jul 20 10:50:50 host sshd[7259]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:52 host sshd[7266]: Invalid user PlcmSpIp from  
> 140.111.145.7
>   Jul 20 10:50:54 host sshd[7268]: Invalid user ts from 140.111.145.7
>   Jul 20 10:50:56 host sshd[7270]: Invalid user ts from 140.111.145.7
>   Jul 20 10:50:56 host sshguard[5331]: Blocking 140.111.145.7: 4  
> failures over 6 seconds.
>
>   See all the log failures: http://pastebin.com/f2b6e140
>
> Well that's not right, pf should have blocked.  Testing with -d,  
> pasting
> the last 4 lines above:
>
>   Matched IP address 140.111.145.7
>   Blocking 140.111.145.7: 4 failures over 1 seconds.
>   Setting environment:  
> SSHG_ADDR=140.111.145.7;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
>   No ALTQ support in kernel
>   ALTQ related functions disabled
>   1/1 addresses added.
>   Run command "/sbin/pfctl -Tadd -t sshguard $SSHG_ADDR": exited 0.
>
> Confirming the pfctl command was correct:
>
>   --> sudo pfctl -Tshow -t sshguard
>   No ALTQ support in kernel
>   ALTQ related functions disabled
>       140.111.145.7
>
> Confirming the pf.conf is correctly set:
>
>   --> sudo grep sshguard /etc/pf.conf
>   # sshguard blockage
>   table <sshguard> persist
>   block in quick on $ext_if from <sshguard> to any label "ssh  
> bruteforce"
>
>   (that's the first block in the pf.conf, there's no allow before it)
>
> So it's working in debug.
>
> Is it possible that syslog gets clogged and doesn't actually write  
> out the
> failed auth messages fast enough?  Is sshguard flushing the tables  
> without
> saying so?  What might be happening in production that's not  
> happening in my
> test?  syslogd is running in secure mode (syslogd -s) and not  
> accepting
> external connections; here are the relevant syslog.conf entries:
>
>   auth.info;authpriv.info                         /var/log/auth.log
>   auth.info;authpriv.info         |exec /usr/local/sbin/sshguard -p  
> 2400 -w /usr/local/etc/sshguard.whitelist
>
> In case you wonder "Why are you piping to exec?!?", from the sh  
> manpage:
>
>    exec [command [arg ...]]
>            Unless command is omitted, the shell process is replaced  
> with the
>            specified program (which must be a real program, not a  
> shell
>            built-in command or function).  Any redirections on the  
> exec com-
>            mand are marked as permanent, so that they are not undone  
> when
>            the exec command finishes.
>
> I've included all the failures below my sig.
>
> ---------------------------------------------------------------------------
> Peter Beckman                                                   
> Internet Guy
> be...@an...                                 http://www.angryox.com/
> ---------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] sshguard working but not blocking, functioning in debug mode

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

My setup: FreeBSD using sshguard with pf.

I've been recently attacked by a single IP over and over again.  I set the
-p to 2400, and sshguard seems to do as I request:

     Jul 20 10:00:00 host sshguard[5331]: Started successfully [(a,p,s)=(4, 2400, 1200)], now ready to scan.

Great!  And sshguard seems to be doing the right thing:

     Jul 20 10:50:32 host sshd[7233]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:35 host sshd[7235]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:37 host sshd[7237]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:39 host sshd[7239]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:39 host sshguard[5331]: Blocking 140.111.145.7: 4 failures over 7 seconds.

But then:

     Jul 20 10:50:41 host sshd[7243]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:44 host sshd[7250]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:46 host sshd[7252]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:48 host sshd[7255]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:48 host sshguard[5331]: Blocking 140.111.145.7: 4 failures over 7 seconds.
     Jul 20 10:50:50 host sshd[7259]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:52 host sshd[7266]: Invalid user PlcmSpIp from 140.111.145.7
     Jul 20 10:50:54 host sshd[7268]: Invalid user ts from 140.111.145.7
     Jul 20 10:50:56 host sshd[7270]: Invalid user ts from 140.111.145.7
     Jul 20 10:50:56 host sshguard[5331]: Blocking 140.111.145.7: 4 failures over 6 seconds.

     See all the log failures: http://pastebin.com/f2b6e140

Well that's not right, pf should have blocked.  Testing with -d, pasting
the last 4 lines above:

     Matched IP address 140.111.145.7
     Blocking 140.111.145.7: 4 failures over 1 seconds.
     Setting environment: SSHG_ADDR=140.111.145.7;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
     No ALTQ support in kernel
     ALTQ related functions disabled
     1/1 addresses added.
     Run command "/sbin/pfctl -Tadd -t sshguard $SSHG_ADDR": exited 0.

Confirming the pfctl command was correct:

     --> sudo pfctl -Tshow -t sshguard
     No ALTQ support in kernel
     ALTQ related functions disabled
         140.111.145.7

Confirming the pf.conf is correctly set:

     --> sudo grep sshguard /etc/pf.conf
     # sshguard blockage
     table <sshguard> persist
     block in quick on $ext_if from <sshguard> to any label "ssh bruteforce"

     (that's the first block in the pf.conf, there's no allow before it)

So it's working in debug.

Is it possible that syslog gets clogged and doesn't actually write out the
failed auth messages fast enough?  Is sshguard flushing the tables without
saying so?  What might be happening in production that's not happening in my
test?  syslogd is running in secure mode (syslogd -s) and not accepting
external connections; here are the relevant syslog.conf entries:

     auth.info;authpriv.info                         /var/log/auth.log
     auth.info;authpriv.info         |exec /usr/local/sbin/sshguard -p 2400 -w /usr/local/etc/sshguard.whitelist

In case you wonder "Why are you piping to exec?!?", from the sh manpage:

      exec [command [arg ...]]
              Unless command is omitted, the shell process is replaced with the
              specified program (which must be a real program, not a shell
              built-in command or function).  Any redirections on the exec com-
              mand are marked as permanent, so that they are not undone when
              the exec command finishes.

I've included all the failures below my sig.

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

Re: [Sshguard-users] SSHGuard Limits

[Greg P. <gpa...@hi...>]

Mij wrote:
> On Apr 21, 2009, at 14:27 , Greg Parrish wrote:
>
>   
>> Hi Mij,
>>
>> I have updated my init script to use the -d option and that is  
>> working.
>> It does not appear to log to the auth.log file I am using, any details
>> of the incoming blocked connections, I assume this is expected.
>>     
>
> yup, -d is mean for inspecting/debugging and routes log messages
> to the console instead of syslog().
>
>
>   
>> Further I am not sure how to snap the entries into sshguard when  
>> running
>> with -d, can you detail what you want me to do there or provide a  
>> link?
>>     
>
> you run with -d, then you just paste the entries into the terminal (in  
> its
> standard input). When you enter the newline character, the parser is
> fired and you see its messages as an output.
>
>
>   
>> Now here is an update as I have been watching this while running under
>> the -d option. I got to 30 entries in the iptables chain and it  
>> stopped
>> working. I was on the console and watching the logs go by from the -d
>> output. I noticed at one point there  was no more updates from the
>> console. I attempted to login incorrectly from a few remote locations
>> and I never got blocked, I could attempt to login over and over and
>> there was NO output from sshguard as before. The process was still
>> running but it was like it was just doing nothing. It remained like  
>> this
>> for a few hours until restart.
>>     
>
> uhm, that sounds suspicious. If SSHGuard runs but prints no messages,
> it may be it's not getting log lines.
> Can you
> 1) feed sshguard in the "tail" mode
> http://sshguard.sourceforge.net/doc/setup/loggingrawfile.html
> that's more "manual", but removes points of indeterminism
> 2) test again so as to inject your 30 blocked entries
> 3) inject more and see how SSHGuard behaves
>
> if 3 fails, there's something wrong with SSHGuard; in this case, please
> send me the log file of the 30+ abuses. If 3 succeeds, there is  
> something
> not working on the syslog side.
>
> michele
>   

Hi Michele,

Okay I worked more on the -d option and figured that out. I ran it 
manually as I do in the script with the tail option. I learned how to 
manually add entries from the console as you stated and also can dump 
lines into the tailed file to trigger events. In summary I started it up 
with tail using a new copy of the auth.log. I did a cat from the current 
auth log to the new auth log. It processes all the entries for some time 
and then it stops like it is waiting for more input which appears normal.

Since many of these items recurred over time I had a ton of dups in the 
iptables which was fine. In fact I was able to run it up over 2000 
entries easily without failure. I did more testing and continued to add 
entries without issue. So based on your thoughts above I investigated 
the logging procedure. The thing that caught my eye was that this fails 
almost on schedule, from what I can tell about once a week. I thought 
and checked into the log rotation and sure enough our auth log file was 
in there. I have removed that, restarted everything and now ready to 
test. I think this could fix our problem as log rotation usually 
requires some planning around the services associated with them.

If this fixes the problem I will let you know while also monitoring the 
size of the auth file as it grows. If it becomes a problem we can do 
other things to rotate and restart sshguard as needed to go along with that.

Thanks,
greg


>
>   
>> So our problem does not appear to be unrecognized entries but any  
>> entry
>> after some time or some number of previous blocking events, it just  
>> stop
>> s working.
>>
>> I used the init to stop and start and tested and it is working again  
>> all
>> fine. Let me know how you would like to proceed on gathering more data
>> on this issue if interested.
>>
>> Thanks,
>> greg
>>
>>
>>
>> Mij wrote:
>>     
>>> Hello,
>>>
>>> sorry for the latency, busy time.
>>>
>>> Whenever you see some log entries that you expect to be "suspicious"
>>> but are
>>> not recognized as such, you should repeat the manual check: pick the
>>> log entry
>>> as-is, and snap it into sshguard run with -d. This takes few seconds
>>> and both
>>> confirms whether the entry should be recognized, and if not shows why
>>> with
>>> descriptive output.
>>>
>>> Can you do this and, if failed, send in the precise log entry that
>>> fails to be reported?
>>>
>>>
>>> On Mar 26, 2009, at 17:10 , Greg Parrish wrote:
>>>
>>>       
>>>> Greg Parrish wrote:
>>>>         
>>>>> Mij wrote:
>>>>>           
>>>>>> As SimCList is used for recording those, there is no such limit by
>>>>>> design.
>>>>>>             
>>>>> Okay that is good to know. I check on another host we have
>>>>> elsewhere and
>>>>> it has 72 entries in the table so it is not seeing this limit.
>>>>>
>>>>>           
>>>>>> What evidence makes you think that (nothing logged, errors or  
>>>>>> else)?
>>>>>>             
>>>>> As mentioned there are entries showing in Logwatch for multiple
>>>>> logins
>>>>> on valid user names that are not being prevented after 2 failed
>>>>> logins.
>>>>> For example today:
>>>>>
>>>>> ftp/password from 219.94.152.55: 7 Time(s)
>>>>>
>>>>> Once I noticed this I logged in from a remote location with an
>>>>> invalid
>>>>> password and it does not initiate a block from my IP address. For
>>>>> example:
>>>>>
>>>>> Mar 17 08:07:04 arnold sshd(pam_unix)[17502]: authentication  
>>>>> failure;
>>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:07:07 arnold sshd[17502]: Failed password for gparrish  
>>>>> from
>>>>> 129.90.96.101 port 12156 ssh2
>>>>> Mar 17 08:07:13 arnold last message repeated 2 times
>>>>> Mar 17 08:07:13 arnold sshd[17505]: Connection closed by
>>>>> 129.90.96.101
>>>>> Mar 17 08:07:13 arnold sshd(pam_unix)[17502]: 2 more authentication
>>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:07:14 arnold sshd(pam_unix)[17506]: authentication  
>>>>> failure;
>>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:07:17 arnold sshd[17506]: Failed password for gparrish  
>>>>> from
>>>>> 129.90.96.101 port 12186 ssh2
>>>>> Mar 17 08:07:23 arnold last message repeated 2 times
>>>>> Mar 17 08:07:23 arnold sshd[17509]: Connection closed by
>>>>> 129.90.96.101
>>>>> Mar 17 08:07:23 arnold sshd(pam_unix)[17506]: 2 more authentication
>>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>>
>>>>>
>>>>>           
>>>>>> Run sshguard in interactive mode (add -d) and paste attack lines
>>>>>> repeatedly, change address once one has been blocked, and please
>>>>>> report what happens
>>>>>> at the 17th time.
>>>>>>             
>>>>> I botched it. I used the init script to take it down and it cleared
>>>>> the
>>>>> iptables DROP list in the sshguard chain. I do have the new logging
>>>>> where this same IP is now blocked:
>>>>>
>>>>>
>>>>> Mar 17 08:11:25 arnold sshd(pam_unix)[17694]: authentication  
>>>>> failure;
>>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:11:27 arnold sshd[17694]: Failed password for gparrish  
>>>>> from
>>>>> 129.90.96.101 port 12353 ssh2
>>>>> Mar 17 08:11:33 arnold last message repeated 2 times
>>>>> Mar 17 08:11:33 arnold sshd[17697]: Connection closed by
>>>>> 129.90.96.101
>>>>> Mar 17 08:11:33 arnold sshd(pam_unix)[17694]: 2 more authentication
>>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:11:35 arnold sshd(pam_unix)[17698]: authentication  
>>>>> failure;
>>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>>> user=gparrish
>>>>> Mar 17 08:11:38 arnold sshd[17698]: Failed password for gparrish  
>>>>> from
>>>>> 129.90.96.101 port 12362 ssh2
>>>>> Mar 17 08:11:38 arnold sshguard[17605]: Blocking 129.90.96.101: 2
>>>>> failures over 10 seconds.
>>>>>
>>>>>
>>>>> Once I get back to this point I will kill the process and  
>>>>> initiate it
>>>>> with the -d option and report back.
>>>>>
>>>>> Using Centos 4.2 on 2.6.9-22.0.1.ELsmp
>>>>>
>>>>> -greg
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> On Mar 10, 2009, at 14:01 , Greg Parrish wrote:
>>>>>>
>>>>>>             
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am using the following parameters for sshguard (v1.3). I know
>>>>>>> the -p
>>>>>>> is huge and we dont mind blacklisting intruders for long  
>>>>>>> periods. I
>>>>>>> noticed today in logwatch and from further testing that once we
>>>>>>> reach
>>>>>>> about 16 entries in the accumulated list for iptables that no
>>>>>>> further
>>>>>>> entries are being accepted.
>>>>>>>
>>>>>>> /usr/local/sbin/sshguard -a 2 -p 25920000 -s 1800 -w /etc/
>>>>>>> sshguard.whitelist
>>>>>>>
>>>>>>> Please review and let me know if you need more information or  
>>>>>>> logs.
>>>>>>> I am
>>>>>>> wondering if there is a limit somewhere in the binary or if this
>>>>>>> is by
>>>>>>> design.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> greg
>>>>>>>
>>>>>>>               
>>>>> ------------------------------------------------------------------------------
>>>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
>>>>> are
>>>>> powering Web 2.0 with engaging, cross-platform capabilities.
>>>>> Quickly and
>>>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based
>>>>> development
>>>>> software that enables intelligent coding and step-through  
>>>>> debugging.
>>>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>>>>> _______________________________________________
>>>>> Sshguard-users mailing list
>>>>> Ssh...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>>>           
>>>> Okay I have ran into this problem again. This time we have 12
>>>> entries in
>>>> the drop table, last time was 16. Logwatch shows multiple root login
>>>> attempts from the same IP which does not happen when this is  
>>>> working.
>>>>
>>>> I ran the command with the -d option but I get no output. I tried
>>>> connecting to the host 7 times, with 3 failed logins each and  
>>>> nothing,
>>>> so of what I am seeing otherwise.
>>>>
>>>> /usr/local/sbin/sshguard -d -a 2 -p 25920000 -s 1800 -w
>>>> /etc/sshguard.whitelist
>>>>
>>>>
>>>> SSH Guard Server Log from CLI:
>>>>
>>>> [hostname]# /usr/local/sbin/sshguard -d -a 2 -p 25920000 -s 1800 -w
>>>> /etc/sshguard.whitelist
>>>> whitelist: add '192.168.122.234' as plain IPv4.
>>>> whitelist: add plain ip 192.168.122.234.
>>>> whitelist: add '127.0.0.1' as plain IPv4.
>>>> whitelist: add plain ip 127.0.0.1.
>>>> Started successfully [(a,p,s)=(2, 25920000, 1800)], now ready to  
>>>> scan.
>>>>
>>>> -greg
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Sshguard-users mailing list
>>>> Ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>>         
>>> ------------------------------------------------------------------------------
>>> Stay on top of everything new and different, both inside and
>>> around Java (TM) technology - register by April 22, and save
>>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>>> 300 plus technical and hands-on sessions. Register today.
>>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>       
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>     
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>   


-- 



Greg Parrish
NC WISE Application and Systems Administrator
NC Department of Public Instruction
301 N. Wilmington Street
Raleigh, NC 27601
Cell: 919-247-4121 

Re: [Sshguard-users] ip addrs not being parsed from log messages

[Adam C. <ada...@be...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000099">
<tt>Thanks for the suggestions.&nbsp; <br>
<br>
Problem #1 was resolved some time ago - I believe by recompiling from
source<br>
<br>
Problem #2 - I believe the diagnosis is correct.&nbsp; This "attacking host"
was a system I was testing from.&nbsp; The problem is no longer reproducible
because this host now has a "real" hostname and static IP.&nbsp; Previously
it was dhcp/ddns assigned and that may have caused the name resolution
to behave unexpectedly.<br>
<br>
sshguard is protecting my servers nicely now, thank you very much<br>
</tt><br>
David Horn wrote:
<blockquote
 cite="mid:25f...@ma..."
 type="cite">
  <pre wrap="">On Fri, Jul 3, 2009 at 5:35 AM, Mij<a class="moz-txt-link-rfc2396E" href="mailto:mi...@bi...">&lt;mi...@bi...&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Shalom,

few months of delay are not too bad :)

for paste #1: please do
1) verify "yacc" and "lex" (or bison/flex) are available on your system
2) in sshguard dir, do make clean
3) remove src/attack_parser.c src/attack_parser.h and src/
attack_scanner.c
4) re- ./configure with your relevant params
5) make

then re-try.


paste #2 is more subtle and interesting:
notice the following excerpt:

    </pre>
    <blockquote type="cite">
      <pre wrap="">&nbsp;$1 = token HOSTADDR ()
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv4 address: Unknown host.
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv6 address: Unknown host.
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv4 nor IPv6 address!
Stack now 0 1 6
      </pre>
    </blockquote>
    <pre wrap="">the parser of SSHGuard distinguishes when addresses are provided as
host names, as in this case. As eventually firewalls want raw
addresses, not
hostnames, SSHGuard resolves in real time the hostnames it finds to
their
IP.
In this case, there's some strange stuff going on on your machine:
1) your sshd receives a connection from a machine
2) for log readability, it reverse-translates the IP address to its
hostname.
3) presumably your DNS server reverses such IP address to
"tech.dyn.berkeley.edu <a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>", which is not a
proper
domain name.
4) therefore, when you try to resolve the domain again to the address,
this
fails. Of course, SSHGuard can't then do anything about it.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There are some interesting things going on here, and I have seen this
behavior on my machine as well.   Here are the case scenarios I have
found.

1) Attacking host (IPv4 or IPv6) has a reverse name associated,
(.in.addr.arpa/ip6.arpa), but no forward address (A/AAAA) record.
Very easy to setup for the attacker in either ipv4 or ipv6 address
scenarios.
2) Attacking host (IPv4) has a reverse name associated,
(.in.addr.arpa), but only a forward address using IPv6 (AAAA) record.
3) Attacking host (IPv6) has a reverse name associated, (.ip6.arpa),
and both a (IPv4) A record, and a (IPv6) AAAA record, sshguard prefers
the ipv4 record, thus the block fails since the attack is happening
over IPv6.
4) Attacking host (IPv4 or IPv6) has a reverse name associated for
SOMEONE ELSES host (say <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>), (.in.addr.arpa/ip6.arpa),
causing a potential (depending on firewall used) denial of service by
disallowing communications with OTHER sites.   This is the really
sneaky/evil one.

Of course there is a simple solution (although not elegant yet) of
adding the following directive to sshd_config for those using openssh:

LogLevel DEBUG2

This causes sshd to NOT perform reverse lookups on entries sent to
"AUTH" syslog facility, and just provides raw addresses.  Of course
DEBUG2 causes lots of other log entries and can be quite noisy, so
watch your log sizes and setup a sane log archive config.

I have been meaning to dig into the openssh code and see if there is
some other directive that would just do what is needed without the
full DEBUG2 logging, but have not had the time yet.

Good Luck

-_Dave

  </pre>
  <blockquote type="cite">
    <pre wrap="">
On Apr 22, 2009, at 24:32 , Adam Cohen wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">sshguard 1.4rc3 on rhel5

My first host is up and running great and today I went to install to a
second host. &nbsp;But I must have missed documenting a step in my process
because I'm having an issue. &nbsp;Looks like the IP address isn't being
parsed out the log message correctly. &nbsp;Here's a simple example,
running
from the command line with debug:

[root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
128.32.152.8 port 61158 ssh2
Starting parse
Entering state 0
Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
ebi-prod01 sshd[21594]:")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 169 (" ")
--accepting rule at line 113 ("Failed password for adam from ")
Next token is token SSH_LOGINERR_PREF ()
Shifting token SSH_LOGINERR_PREF ()
Entering state 6
Reading a token: --accepting rule at line 159 ("128")
Next token is token INTEGER ()
Error: popping token SSH_LOGINERR_PREF ()
Stack now 0 1
Error: popping token SYSLOG_BANNER_PID ()
Stack now 0
Cleanup: discarding lookahead token INTEGER ()
Stack now 0

I've tried modifying the input but only get a reasonable response
when I
use a hostname:

[root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
tech.dyn.berkeley.edu <a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a> port 51152 ssh2
Starting parse
Entering state 0
Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
ebi-prod01 sshd[21594]:")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 169 (" ")
--accepting rule at line 113 ("Failed password for adam from ")
Next token is token SSH_LOGINERR_PREF ()
Shifting token SSH_LOGINERR_PREF ()
Entering state 6
Reading a token: --accepting rule at line 158 ("tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>")
Next token is token HOSTADDR ()
Shifting token HOSTADDR ()
Entering state 40
Reducing stack by rule 18 (line 115):
&nbsp;$1 = token HOSTADDR ()
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv4 address: Unknown host.
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv6 address: Unknown host.
Could not resolve hostname 'tech.dyn.berkeley.edu
<a class="moz-txt-link-rfc2396E" href="http://tech.dyn.berkeley.edu">&lt;http://tech.dyn.berkeley.edu&gt;</a>' in IPv4 nor IPv6 address!
Stack now 0 1 6
Cleanup: popping token SSH_LOGINERR_PREF ()
Cleanup: popping token SYSLOG_BANNER_PID ()

I've also recompiled and replaced the binary to no avail. &nbsp;I am afraid
that I did see this symptom at one point during my first installation
but I have no notes on what cleared the problem. &nbsp;Any suggestions?

thanks
Adam

--
Adam Cohen / IT Manager
Energy Biosciences Institute / UC Berkeley
109 Calvin Lab / 510-642-7709


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/p">http://p.sf.net/sfu/p</a>
_______________________________________________
Sshguard-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ssh...@li...">Ssh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sshguard-users">https://lists.sourceforge.net/lists/listinfo/sshguard-users</a>
      </pre>
    </blockquote>
    <pre wrap="">
------------------------------------------------------------------------------
_______________________________________________
Sshguard-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ssh...@li...">Ssh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sshguard-users">https://lists.sourceforge.net/lists/listinfo/sshguard-users</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
------------------------------------------------------------------------------
_______________________________________________
Sshguard-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ssh...@li...">Ssh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sshguard-users">https://lists.sourceforge.net/lists/listinfo/sshguard-users</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Adam Cohen / IT Manager
Energy Biosciences Institute / UC Berkeley
109 Calvin Lab / 510-642-7709</pre>
</body>
</html>

Re: [Sshguard-users] SSHguard for HTTP

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

always nice to see quests for collateral applications of SSHGuard.  
Thanks.
Please submit these lines to
http://sshguard.sourceforge.net/newattackpatt.php

we look in there to decide what to support in next releases (I'm not  
saying that
the post is off topic, we just want a reference in there).

Grep:
what for? The parser is already a grep itself. Some users hinted  
voodoo beliefs
of performance load with the parser. I don't know where they come  
from, but
forget it. The parser boils down to a state machine. At the first  
character which
does not comply with some pattern, the deal is over. When you filter  
with regular
expressions or grep, they have to scan through the entire line instead.

multiple addresses in log line: nothing. A regular expression could be  
confused,
the context-free parser SSHGuard uses is not.

Re: [Sshguard-users] Blocking bots looking for vulnerable web apps

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

FYI, we've scheduled this for 1.5 and we'll be working on this kind of  
soon.


On Apr 22, 2009, at 11:49 , Hans F. Nordhaug wrote:

> Thx for your reply, michele, and sorry about not coming back to this
> issue before now. To me 1 isn't such a big problem - there are many
> ways to work around it. However, 2 is a real problem that I didn't
> think about. I clearly can't use the same "density" for SSH and HTTP.
> I think I'll wait for you ;-)
>
> I definetly think this would be a nice addition to SSHGuard, but I
> also realize that it might not make sense to extend SSHGuard to handle
> every thing. Maybe there are other tools out there that all ready
> do the job? I just happen to like SSHGuard.
>
> Regards,
> Hans

Re: [Sshguard-users] SSHGuard Limits

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

On Apr 21, 2009, at 14:27 , Greg Parrish wrote:

> Hi Mij,
>
> I have updated my init script to use the -d option and that is  
> working.
> It does not appear to log to the auth.log file I am using, any details
> of the incoming blocked connections, I assume this is expected.

yup, -d is mean for inspecting/debugging and routes log messages
to the console instead of syslog().


> Further I am not sure how to snap the entries into sshguard when  
> running
> with -d, can you detail what you want me to do there or provide a  
> link?

you run with -d, then you just paste the entries into the terminal (in  
its
standard input). When you enter the newline character, the parser is
fired and you see its messages as an output.


> Now here is an update as I have been watching this while running under
> the -d option. I got to 30 entries in the iptables chain and it  
> stopped
> working. I was on the console and watching the logs go by from the -d
> output. I noticed at one point there  was no more updates from the
> console. I attempted to login incorrectly from a few remote locations
> and I never got blocked, I could attempt to login over and over and
> there was NO output from sshguard as before. The process was still
> running but it was like it was just doing nothing. It remained like  
> this
> for a few hours until restart.

uhm, that sounds suspicious. If SSHGuard runs but prints no messages,
it may be it's not getting log lines.
Can you
1) feed sshguard in the "tail" mode
http://sshguard.sourceforge.net/doc/setup/loggingrawfile.html
that's more "manual", but removes points of indeterminism
2) test again so as to inject your 30 blocked entries
3) inject more and see how SSHGuard behaves

if 3 fails, there's something wrong with SSHGuard; in this case, please
send me the log file of the 30+ abuses. If 3 succeeds, there is  
something
not working on the syslog side.

michele


> So our problem does not appear to be unrecognized entries but any  
> entry
> after some time or some number of previous blocking events, it just  
> stop
> s working.
>
> I used the init to stop and start and tested and it is working again  
> all
> fine. Let me know how you would like to proceed on gathering more data
> on this issue if interested.
>
> Thanks,
> greg
>
>
>
> Mij wrote:
>> Hello,
>>
>> sorry for the latency, busy time.
>>
>> Whenever you see some log entries that you expect to be "suspicious"
>> but are
>> not recognized as such, you should repeat the manual check: pick the
>> log entry
>> as-is, and snap it into sshguard run with -d. This takes few seconds
>> and both
>> confirms whether the entry should be recognized, and if not shows why
>> with
>> descriptive output.
>>
>> Can you do this and, if failed, send in the precise log entry that
>> fails to be reported?
>>
>>
>> On Mar 26, 2009, at 17:10 , Greg Parrish wrote:
>>
>>> Greg Parrish wrote:
>>>> Mij wrote:
>>>>> As SimCList is used for recording those, there is no such limit by
>>>>> design.
>>>> Okay that is good to know. I check on another host we have
>>>> elsewhere and
>>>> it has 72 entries in the table so it is not seeing this limit.
>>>>
>>>>> What evidence makes you think that (nothing logged, errors or  
>>>>> else)?
>>>> As mentioned there are entries showing in Logwatch for multiple
>>>> logins
>>>> on valid user names that are not being prevented after 2 failed
>>>> logins.
>>>> For example today:
>>>>
>>>> ftp/password from 219.94.152.55: 7 Time(s)
>>>>
>>>> Once I noticed this I logged in from a remote location with an
>>>> invalid
>>>> password and it does not initiate a block from my IP address. For
>>>> example:
>>>>
>>>> Mar 17 08:07:04 arnold sshd(pam_unix)[17502]: authentication  
>>>> failure;
>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:07:07 arnold sshd[17502]: Failed password for gparrish  
>>>> from
>>>> 129.90.96.101 port 12156 ssh2
>>>> Mar 17 08:07:13 arnold last message repeated 2 times
>>>> Mar 17 08:07:13 arnold sshd[17505]: Connection closed by
>>>> 129.90.96.101
>>>> Mar 17 08:07:13 arnold sshd(pam_unix)[17502]: 2 more authentication
>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:07:14 arnold sshd(pam_unix)[17506]: authentication  
>>>> failure;
>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:07:17 arnold sshd[17506]: Failed password for gparrish  
>>>> from
>>>> 129.90.96.101 port 12186 ssh2
>>>> Mar 17 08:07:23 arnold last message repeated 2 times
>>>> Mar 17 08:07:23 arnold sshd[17509]: Connection closed by
>>>> 129.90.96.101
>>>> Mar 17 08:07:23 arnold sshd(pam_unix)[17506]: 2 more authentication
>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>>
>>>>
>>>>> Run sshguard in interactive mode (add -d) and paste attack lines
>>>>> repeatedly, change address once one has been blocked, and please
>>>>> report what happens
>>>>> at the 17th time.
>>>> I botched it. I used the init script to take it down and it cleared
>>>> the
>>>> iptables DROP list in the sshguard chain. I do have the new logging
>>>> where this same IP is now blocked:
>>>>
>>>>
>>>> Mar 17 08:11:25 arnold sshd(pam_unix)[17694]: authentication  
>>>> failure;
>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:11:27 arnold sshd[17694]: Failed password for gparrish  
>>>> from
>>>> 129.90.96.101 port 12353 ssh2
>>>> Mar 17 08:11:33 arnold last message repeated 2 times
>>>> Mar 17 08:11:33 arnold sshd[17697]: Connection closed by
>>>> 129.90.96.101
>>>> Mar 17 08:11:33 arnold sshd(pam_unix)[17694]: 2 more authentication
>>>> failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:11:35 arnold sshd(pam_unix)[17698]: authentication  
>>>> failure;
>>>> logname= uid=0 euid=0 tty=ssh ruser= rhost=129.90.96.101
>>>> user=gparrish
>>>> Mar 17 08:11:38 arnold sshd[17698]: Failed password for gparrish  
>>>> from
>>>> 129.90.96.101 port 12362 ssh2
>>>> Mar 17 08:11:38 arnold sshguard[17605]: Blocking 129.90.96.101: 2
>>>> failures over 10 seconds.
>>>>
>>>>
>>>> Once I get back to this point I will kill the process and  
>>>> initiate it
>>>> with the -d option and report back.
>>>>
>>>> Using Centos 4.2 on 2.6.9-22.0.1.ELsmp
>>>>
>>>> -greg
>>>>
>>>>
>>>>
>>>>> On Mar 10, 2009, at 14:01 , Greg Parrish wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am using the following parameters for sshguard (v1.3). I know
>>>>>> the -p
>>>>>> is huge and we dont mind blacklisting intruders for long  
>>>>>> periods. I
>>>>>> noticed today in logwatch and from further testing that once we
>>>>>> reach
>>>>>> about 16 entries in the accumulated list for iptables that no
>>>>>> further
>>>>>> entries are being accepted.
>>>>>>
>>>>>> /usr/local/sbin/sshguard -a 2 -p 25920000 -s 1800 -w /etc/
>>>>>> sshguard.whitelist
>>>>>>
>>>>>> Please review and let me know if you need more information or  
>>>>>> logs.
>>>>>> I am
>>>>>> wondering if there is a limit somewhere in the binary or if this
>>>>>> is by
>>>>>> design.
>>>>>>
>>>>>> Thanks,
>>>>>> greg
>>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
>>>> are
>>>> powering Web 2.0 with engaging, cross-platform capabilities.
>>>> Quickly and
>>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based
>>>> development
>>>> software that enables intelligent coding and step-through  
>>>> debugging.
>>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>>>> _______________________________________________
>>>> Sshguard-users mailing list
>>>> Ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>
>>>
>>> Okay I have ran into this problem again. This time we have 12
>>> entries in
>>> the drop table, last time was 16. Logwatch shows multiple root login
>>> attempts from the same IP which does not happen when this is  
>>> working.
>>>
>>> I ran the command with the -d option but I get no output. I tried
>>> connecting to the host 7 times, with 3 failed logins each and  
>>> nothing,
>>> so of what I am seeing otherwise.
>>>
>>> /usr/local/sbin/sshguard -d -a 2 -p 25920000 -s 1800 -w
>>> /etc/sshguard.whitelist
>>>
>>>
>>> SSH Guard Server Log from CLI:
>>>
>>> [hostname]# /usr/local/sbin/sshguard -d -a 2 -p 25920000 -s 1800 -w
>>> /etc/sshguard.whitelist
>>> whitelist: add '192.168.122.234' as plain IPv4.
>>> whitelist: add plain ip 192.168.122.234.
>>> whitelist: add '127.0.0.1' as plain IPv4.
>>> whitelist: add plain ip 127.0.0.1.
>>> Started successfully [(a,p,s)=(2, 25920000, 1800)], now ready to  
>>> scan.
>>>
>>> -greg
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>>
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] ip addrs not being parsed from log messages

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

On Fri, Jul 3, 2009 at 5:35 AM, Mij<mi...@bi...> wrote:
> Shalom,
>
> few months of delay are not too bad :)
>
> for paste #1: please do
> 1) verify "yacc" and "lex" (or bison/flex) are available on your system
> 2) in sshguard dir, do make clean
> 3) remove src/attack_parser.c src/attack_parser.h and src/
> attack_scanner.c
> 4) re- ./configure with your relevant params
> 5) make
>
> then re-try.
>
>
> paste #2 is more subtle and interesting:
> notice the following excerpt:
>
>>  $1 = token HOSTADDR ()
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host.
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host.
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address!
>> Stack now 0 1 6
>
> the parser of SSHGuard distinguishes when addresses are provided as
> host names, as in this case. As eventually firewalls want raw
> addresses, not
> hostnames, SSHGuard resolves in real time the hostnames it finds to
> their
> IP.
> In this case, there's some strange stuff going on on your machine:
> 1) your sshd receives a connection from a machine
> 2) for log readability, it reverse-translates the IP address to its
> hostname.
> 3) presumably your DNS server reverses such IP address to
> "tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu>", which is not a
> proper
> domain name.
> 4) therefore, when you try to resolve the domain again to the address,
> this
> fails. Of course, SSHGuard can't then do anything about it.

There are some interesting things going on here, and I have seen this
behavior on my machine as well.   Here are the case scenarios I have
found.

1) Attacking host (IPv4 or IPv6) has a reverse name associated,
(.in.addr.arpa/ip6.arpa), but no forward address (A/AAAA) record.
Very easy to setup for the attacker in either ipv4 or ipv6 address
scenarios.
2) Attacking host (IPv4) has a reverse name associated,
(.in.addr.arpa), but only a forward address using IPv6 (AAAA) record.
3) Attacking host (IPv6) has a reverse name associated, (.ip6.arpa),
and both a (IPv4) A record, and a (IPv6) AAAA record, sshguard prefers
the ipv4 record, thus the block fails since the attack is happening
over IPv6.
4) Attacking host (IPv4 or IPv6) has a reverse name associated for
SOMEONE ELSES host (say www.google.com), (.in.addr.arpa/ip6.arpa),
causing a potential (depending on firewall used) denial of service by
disallowing communications with OTHER sites.   This is the really
sneaky/evil one.

Of course there is a simple solution (although not elegant yet) of
adding the following directive to sshd_config for those using openssh:

LogLevel DEBUG2

This causes sshd to NOT perform reverse lookups on entries sent to
"AUTH" syslog facility, and just provides raw addresses.  Of course
DEBUG2 causes lots of other log entries and can be quite noisy, so
watch your log sizes and setup a sane log archive config.

I have been meaning to dig into the openssh code and see if there is
some other directive that would just do what is needed without the
full DEBUG2 logging, but have not had the time yet.

Good Luck

-_Dave

>
>
> On Apr 22, 2009, at 24:32 , Adam Cohen wrote:
>
>> sshguard 1.4rc3 on rhel5
>>
>> My first host is up and running great and today I went to install to a
>> second host.  But I must have missed documenting a step in my process
>> because I'm having an issue.  Looks like the IP address isn't being
>> parsed out the log message correctly.  Here's a simple example,
>> running
>> from the command line with debug:
>>
>> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
>> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
>> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
>> 128.32.152.8 port 61158 ssh2
>> Starting parse
>> Entering state 0
>> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
>> ebi-prod01 sshd[21594]:")
>> Next token is token SYSLOG_BANNER_PID ()
>> Shifting token SYSLOG_BANNER_PID ()
>> Entering state 1
>> Reading a token: --accepting rule at line 169 (" ")
>> --accepting rule at line 113 ("Failed password for adam from ")
>> Next token is token SSH_LOGINERR_PREF ()
>> Shifting token SSH_LOGINERR_PREF ()
>> Entering state 6
>> Reading a token: --accepting rule at line 159 ("128")
>> Next token is token INTEGER ()
>> Error: popping token SSH_LOGINERR_PREF ()
>> Stack now 0 1
>> Error: popping token SYSLOG_BANNER_PID ()
>> Stack now 0
>> Cleanup: discarding lookahead token INTEGER ()
>> Stack now 0
>>
>> I've tried modifying the input but only get a reasonable response
>> when I
>> use a hostname:
>>
>> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
>> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
>> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
>> tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu> port 51152 ssh2
>> Starting parse
>> Entering state 0
>> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
>> ebi-prod01 sshd[21594]:")
>> Next token is token SYSLOG_BANNER_PID ()
>> Shifting token SYSLOG_BANNER_PID ()
>> Entering state 1
>> Reading a token: --accepting rule at line 169 (" ")
>> --accepting rule at line 113 ("Failed password for adam from ")
>> Next token is token SSH_LOGINERR_PREF ()
>> Shifting token SSH_LOGINERR_PREF ()
>> Entering state 6
>> Reading a token: --accepting rule at line 158 ("tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>")
>> Next token is token HOSTADDR ()
>> Shifting token HOSTADDR ()
>> Entering state 40
>> Reducing stack by rule 18 (line 115):
>>  $1 = token HOSTADDR ()
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host.
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host.
>> Could not resolve hostname 'tech.dyn.berkeley.edu
>> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address!
>> Stack now 0 1 6
>> Cleanup: popping token SSH_LOGINERR_PREF ()
>> Cleanup: popping token SYSLOG_BANNER_PID ()
>>
>> I've also recompiled and replaced the binary to no avail.  I am afraid
>> that I did see this symptom at one point during my first installation
>> but I have no notes on what cleared the problem.  Any suggestions?
>>
>> thanks
>> Adam
>>
>> --
>> Adam Cohen / IT Manager
>> Energy Biosciences Institute / UC Berkeley
>> 109 Calvin Lab / 510-642-7709
>>
>>
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] ip addrs not being parsed from log messages

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

Shalom,

few months of delay are not too bad :)

for paste #1: please do
1) verify "yacc" and "lex" (or bison/flex) are available on your system
2) in sshguard dir, do make clean
3) remove src/attack_parser.c src/attack_parser.h and src/ 
attack_scanner.c
4) re- ./configure with your relevant params
5) make

then re-try.


paste #2 is more subtle and interesting:
notice the following excerpt:

>  $1 = token HOSTADDR ()
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host.
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host.
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address!
> Stack now 0 1 6

the parser of SSHGuard distinguishes when addresses are provided as
host names, as in this case. As eventually firewalls want raw  
addresses, not
hostnames, SSHGuard resolves in real time the hostnames it finds to  
their
IP.
In this case, there's some strange stuff going on on your machine:
1) your sshd receives a connection from a machine
2) for log readability, it reverse-translates the IP address to its  
hostname.
3) presumably your DNS server reverses such IP address to
"tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu>", which is not a  
proper
domain name.
4) therefore, when you try to resolve the domain again to the address,  
this
fails. Of course, SSHGuard can't then do anything about it.


On Apr 22, 2009, at 24:32 , Adam Cohen wrote:

> sshguard 1.4rc3 on rhel5
>
> My first host is up and running great and today I went to install to a
> second host.  But I must have missed documenting a step in my process
> because I'm having an issue.  Looks like the IP address isn't being
> parsed out the log message correctly.  Here's a simple example,  
> running
> from the command line with debug:
>
> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
> 128.32.152.8 port 61158 ssh2
> Starting parse
> Entering state 0
> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
> ebi-prod01 sshd[21594]:")
> Next token is token SYSLOG_BANNER_PID ()
> Shifting token SYSLOG_BANNER_PID ()
> Entering state 1
> Reading a token: --accepting rule at line 169 (" ")
> --accepting rule at line 113 ("Failed password for adam from ")
> Next token is token SSH_LOGINERR_PREF ()
> Shifting token SSH_LOGINERR_PREF ()
> Entering state 6
> Reading a token: --accepting rule at line 159 ("128")
> Next token is token INTEGER ()
> Error: popping token SSH_LOGINERR_PREF ()
> Stack now 0 1
> Error: popping token SYSLOG_BANNER_PID ()
> Stack now 0
> Cleanup: discarding lookahead token INTEGER ()
> Stack now 0
>
> I've tried modifying the input but only get a reasonable response  
> when I
> use a hostname:
>
> [root@ebi-prod01 sbin]# sshguard -d -a 2 -p 10
> Started successfully [(a,p,s)=(2, 10, 1200)], now ready to scan.
> Apr 21 14:11:00 ebi-prod01 sshd[21594]: Failed password for adam from
> tech.dyn.berkeley.edu <http://tech.dyn.berkeley.edu> port 51152 ssh2
> Starting parse
> Entering state 0
> Reading a token: --accepting rule at line 96 ("Apr 21 14:11:00
> ebi-prod01 sshd[21594]:")
> Next token is token SYSLOG_BANNER_PID ()
> Shifting token SYSLOG_BANNER_PID ()
> Entering state 1
> Reading a token: --accepting rule at line 169 (" ")
> --accepting rule at line 113 ("Failed password for adam from ")
> Next token is token SSH_LOGINERR_PREF ()
> Shifting token SSH_LOGINERR_PREF ()
> Entering state 6
> Reading a token: --accepting rule at line 158 ("tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>")
> Next token is token HOSTADDR ()
> Shifting token HOSTADDR ()
> Entering state 40
> Reducing stack by rule 18 (line 115):
>  $1 = token HOSTADDR ()
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv4 address: Unknown host.
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv6 address: Unknown host.
> Could not resolve hostname 'tech.dyn.berkeley.edu
> <http://tech.dyn.berkeley.edu>' in IPv4 nor IPv6 address!
> Stack now 0 1 6
> Cleanup: popping token SSH_LOGINERR_PREF ()
> Cleanup: popping token SYSLOG_BANNER_PID ()
>
> I've also recompiled and replaced the binary to no avail.  I am afraid
> that I did see this symptom at one point during my first installation
> but I have no notes on what cleared the problem.  Any suggestions?
>
> thanks
> Adam
>
> -- 
> Adam Cohen / IT Manager
> Energy Biosciences Institute / UC Berkeley
> 109 Calvin Lab / 510-642-7709
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

Committed, thanks David, thanks testers.


On May 9, 2009, at 17:20 , David Horn wrote:

> Anyone on this list have access to a OSX 10.5 dev environment that is
> willing to test some patches ?
>
> I have a patch for ipfw firewall and ipv6 that I have tested on
> FreeBSD 7, and OSX (ppc) 10.4, but I would prefer someone test with
> OSX 10.5 or even snow leopard (intel or ppc) as well.
>
> 1)  Get base code here:
>     svn co https://sshguard.svn.sourceforge.net/svnroot/sshguard  
> sshguard
>
> 2)  Get the patches (both) of them from here:  (save to the
> sshguard/trunk directory from step 1)
>     https://sourceforge.net/tracker/?func=detail&aid=2777559&group_id=188282&atid=924687
>
> 3)  Apply patches and configure/build
>
> su root
> cd sshguard/trunk
> patch <osx_configure_ac_patch.txt
> pushd src/fwalls
> patch <../../ipfw_ipv6_patch_2.txt
> popd
> autoreconf
> ./configure --with-firewall=ipfw
> make clean && make
>
> 4)  If all builds well, try running sshguard with the "-d" parameter
> and paste the following attack example:
>
> e.g.  src/sshguard -d
>
> Attack Example:  (if your email client wraps the string to multiple
> lines, make sure it is one line before you paste into the sshguard
> debug terminal)
>
> Apr 30 12:19:08 minimac sshd[7097]: Failed keyboard-interactive/pam
> for invalid user asdf from 2001:db8::1 port 57453 ssh2
>
> Paste the attack example into the terminal 4 times and you should see
> the following at the end:
>
> Running command: '/sbin/ip6fw add 55045 drop ipv6 from 2001:db8::1  
> to any'.
> 55045 deny ipv6 from 2001:db8::1 to any
> Command exited 0.
> First sight of offender '2001:db8::1:6', adding to offenders list.
>
> If you see any other exit code than "Command exited 0.", please paste
> the entire output buffer in a response email.
>
> --Thanks!
>
> -_Dave H
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] SSHguard for HTTP

[Kacper W. <ka...@gm...>]

On Fri, Jun 26, 2009 at 8:22 PM, Peter Beckman<be...@an...> wrote:
> On Thu, 11 Jun 2009, Peter Beckman wrote:
>
>> Would this work?
>>
>>     tail -n0 -F httpd.log | grep ' 404 ' | sshguard -a 100 -s 60 -p 1200
>
>  Unfortunately this doesn't work.  The problem, however, is not SSHguard,
>  but pipes.  Once you run

I believe grep sends an untimely EOF to end the tail stream.

I haven't tried it in this particular case, but maybe you could try using socat:
http://www.dest-unreach.org/socat/doc/socat.html
which is a pretty useful tool for cases like this.

HTH,
-- 
http://kacper.doesntexist.org
http://windows.dontexist.net
Employ no technique to gain supreme enlightment.
- Mar pa Chos kyi blos gros

Re: [Sshguard-users] SSHguard for HTTP

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

On Thu, 11 Jun 2009, Peter Beckman wrote:

> Would this work?
>
>     tail -n0 -F httpd.log | grep ' 404 ' | sshguard -a 100 -s 60 -p 1200

  Unfortunately this doesn't work.  The problem, however, is not SSHguard,
  but pipes.  Once you run

     tail -n0 -F httpd.log | grep ' 404 '

  It outputs as expected to stdout.  However, when you add pipe number two,
  piping to sshguard, the output doesn't continue as tail processes.  I'm
  not sure if it gets buffered somewhere or what, but SOMETHING prevents
  the output you can see from grep to getting to sshguard.  Try it out:

     tail -n0 -F httpd.log | grep ' 200 ' | cat

  If you just do:

     cat httpd.log | grep ' 200 ' | cat

  Works just fine.  But there is something about tail that screws up
  multiple pipes.  Anyone know what's up here?  I tried installing gtail
  (didn't work), tried to figure out how to configure lighttpd to spit only
  404's to a certain local0 syslog facility so I could pipe it to lighttpd,
  I even googled "'tail -f' multiple pipes" and read a bunch of stuff.  I've
  looked for unbuffering functionality in grep, egrep, sed, tail, gtail and
  others.  Most solutions I did find simply worked around the issue of
  multiple pipes by combining commands into a single pipe after tail -F.
  People doing:

     tail -n0 -F httpd.log | grep 'foo' | grep -v 'bar'

  were told to use awk and a single pipe.

  So what's the deal?  Why does tail not play nice with multiple pipes?

  In theory, something like this would work like a charm:

     tail -n0 -F httpd.log | sed -n -E 's/^(.+?) .+ 404 .+$/\1 404 access denied/p' | sshguard -a 100 -s 60 -p 1200

  (if it only worked) to only get the 404's out of the log file, and then
  rewrite the log entry to meet sshguard's criteria for blocking.  The '-n'
  and trailing 'p' flag in s// allow me to NOT pipe non-replaced lines to
  sshguard, for efficiency.  But this doesn't work (tested with sshguard -d).

  If you can think of how to use SSHguard to block people who attempt brute
  force HTTP scans of 404 links and get around the multiple pipes issue, I'd
  love to hear it.  Lighttpd doesn't log 404 errors to the error log, and it
  doesn't seem to be able to only send 404 errors to a different file than
  the set access log file.  I'd still need to pipe access log entries sent
  to syslog through sed and then sshguard, which MIGHT work, but then I lose
  access logs, which are kinda important.  Plus I'm not sure what kind of
  overhead that might generate.

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

[Sshguard-users] SSHguard for HTTP

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

A common attack these days is to try a few thousand HTTP URLs looking for
scripts or code or pages that are running open source software with some
sort of vulnerability or "feature" that sends email out.

Often these attacks are run on servers that can generate thousands of
requests per second, overwhelming systems and servers that usually handle
hundreds of connections per minute.

I use lighttpd, but it could be extended to Apache.  For example (actual IP
and hostname replaced to protect, well something):

198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:31 +0000] "GET /modules/jinzora/backend/classes.php?include_path=../lib/jinzora.js%00 HTTP/1.1" 404 5069 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:31 +0000] "GET /cgi-bin//plugins/db/mysql/mysql.inc.php HTTP/1.1" 404 5039 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:31 +0000] "GET /cgi-bin/index.php?blog=1&title='&more=1&c=1&tb=1&pb=1 HTTP/1.1" 404 5074 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:31 +0000] "GET /scripts/ideabox/include.php?ideaDir=http://xxxxxxxx HTTP/1.1" 404 5051 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:31 +0000] "GET //plugins/db/mysql/mysql.inc.php HTTP/1.1" 404 5031 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:32 +0000] "GET /cgi-bin/ideabox/include.php?ideaDir=http://xxxxxxxx HTTP/1.1" 404 5051 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:32 +0000] "GET /ideabox/include.php?ideaDir=http://xxxxxxxx HTTP/1.1" 404 5043 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:32 +0000] "GET /include.php?ideaDir=http://xxxxxxxx HTTP/1.1" 404 5035 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
198.6.1.1 4.3.2.1 - [01/Jan/2009:13:31:32 +0000] "GET /ideabox/include.php?ideaDir=http://xxxxxxxx HTTP/1.1" 404 5043 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

My concern is that there are potentially two IP addresses in the log file,
the REMOTE_ADDR and the server IP, HTTP_HOST.  There isn't really much of
an "error" here.  Nothing is wrong, other than the end user generated over
8,000 404 (Not Found) messages in a matter of a few minutes.

I realize there are bandwidth limiters and other sorts of software to block
stuff like this, but I really like sshguard, and this seems like the kind
of thing it can do well.

Would this work?

     tail -n0 -F httpd.log | grep ' 404 ' | sshguard -a 100 -s 60 -p 1200

That would strip out the 404's from the log, and only those would be passed
to sshguard, which would block them upon more than 100 404 messages in 60
seconds.

Thoughts?  What happens when there are multiple IP addresses in the log
file line?

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

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

On Fri, May 29, 2009 at 9:12 AM, Jim Tobin <jt...@gm...> wrote:
> I checked out revision 101.
> I downloaded the two patch files.
> I successfully applied the osx_configure_ac_patch
> The ipfw_ipv6 patch failed:
> bash-3.2# patch </Users/jimtobin/Downloads/ipfw_ipv6_patch_2.txt
> patching file ipfw.c
> patch unexpectedly ends in middle of line
> Hunk #2 succeeded at 77 with fuzz 2.
> bash-3.2#
> Is that an expected outcome?

Yes, and no.  It is expected with the version of patch on OSX.  I did
not get this under freebsd (where the patch was created)

In any case, the warnings are harmless for this particular patch on
osx.  The diff patch was created under freebsd with the svn diff
command.

--Thanks for testing.

-_Dave H

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

On Fri, 29 May 2009, Jim Tobin wrote:

> I checked out revision 101.I downloaded the two patch files.
> I successfully applied the osx_configure_ac_patch
> The ipfw_ipv6 patch failed:
>
> bash-3.2# patch </Users/jimtobin/Downloads/ipfw_ipv6_patch_2.txt
> patching file ipfw.c
> patch unexpectedly ends in middle of line
> Hunk #2 succeeded at 77 with fuzz 2.
> bash-3.2#
>
> Is that an expected outcome?

  I got that too, but if you actually look at the patch, it's fine.  I
  didn't bother to fix it, but the patch works to get both added lines into
  the ipfw.c file, so compile away, do not be afraid.

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

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

[Jim T. <jt...@gm...>]

I checked out revision 101.I downloaded the two patch files.
I successfully applied the osx_configure_ac_patch
The ipfw_ipv6 patch failed:

bash-3.2# patch </Users/jimtobin/Downloads/ipfw_ipv6_patch_2.txt
patching file ipfw.c
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 77 with fuzz 2.
bash-3.2#

Is that an expected outcome?

I'll await your reply before proceeding.

Re: [Sshguard-users] sshguard 1.4rc4 on Mac OS X Server 10.5.7

[Jim T. <jt...@gm...>]

sshguard 1.4rc4 is happily running on my Mac OS X Server 10.5.7.
My previous experience with it not blocking was simply because I hadn't
started the firewall service in Server Admin!

Remember to compile --with-firewall=ipfw
--with-firewall-rule-range=11000-11999 (or whatever, just get under the
allow rule that Server Admin will set at 12302 for ssh)

tail -n0 -F /var/log/secure.log | /usr/local/sbin/sshguard

My next step is to create a system LaunchDaemon for this so on reboot my
server is still protected.  I'll post the contents of that plist when done.

Thanks for sshguard!

[Sshguard-users] sshguard 1.4rc4 on Mac OS X Server 10.5.7

[Jim T. <jt...@gm...>]

I downloaded the 1.4rc4, compiled it with the IPFW option and set the rule
range to 11000-11999, make'd and make installed with no problems.

I used the tail | sshguard method and tested with an invalid username and
garbage password.  Sure enough, sshguard generated an IPFW rule blocking the
computer I was coming from (192.168.0.198).
services:~ me: sudo ipfw list
Password:
01000 allow ip from any to any via lo0
01010 deny ip from any to 127.0.0.0/8
01020 deny ip from 224.0.0.0/4 to any in
01030 deny tcp from any to 224.0.0.0/4 in
11136 deny ip from 192.168.0.198 to me
12300 allow tcp from any to any established
12301 allow tcp from any to any out
12302 allow tcp from any to any dst-port 22
12302 allow udp from any to any dst-port 22
12303 allow udp from any to any out keep-state
12304 allow tcp from any to any dst-port 53 out keep-state
12304 allow udp from any to any dst-port 53 out keep-state
12305 allow udp from any to any in frag
12306 allow tcp from any to any dst-port 311
12307 allow tcp from any to any dst-port 625
12308 allow udp from any to any dst-port 626
12309 allow icmp from any to any icmptypes 8
12310 allow icmp from any to any icmptypes 0
12311 allow igmp from any to any
65534 deny ip from any to any
65535 allow ip from any to any

But oddly, the firewall is not blocking access from that computer (I can
pull up the web page hosted by the server, continue to ssh, etc)

I'm suspecting the "me" token is being misinterpreted by the version of IPFW
running here.

Can anyone else share their experiences with sshguard on OS X Server?

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

On Sat, 9 May 2009, David Horn wrote:

> Anyone on this list have access to a OSX 10.5 dev environment that is
> willing to test some patches ?

  Looks like it works:

     (4 tries, debugging match stuff cut)...

     Matched address 2001:db8::1:6 attacking service 100
     Blocking 2001:db8::1:6 for >420secs: 4 failures over 8 seconds.
     Running command: '/sbin/ip6fw add 55038 drop ipv6 from 2001:db8::1 to any'.
     55038 deny ipv6 from 2001:db8::1 to any
     Command exited 0.
     First sight of offender '2001:db8::1:6', adding to offenders list.

  Thanks for the patches David!  Compiled on 10.5.7 Mac Pro.

Beckman

PS -- Is the webmaster position still open Mij?  I think I emailed you
about it but never heard back.
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
be...@an...                                 http://www.angryox.com/
---------------------------------------------------------------------------

Re: [Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

thanks for your contribution. Any Mac user around who can contribute a  
few testing?
If not, I will have a look at this in some weeks.


On May 9, 2009, at 17:20 , David Horn wrote:

> Anyone on this list have access to a OSX 10.5 dev environment that is
> willing to test some patches ?
>
> I have a patch for ipfw firewall and ipv6 that I have tested on
> FreeBSD 7, and OSX (ppc) 10.4, but I would prefer someone test with
> OSX 10.5 or even snow leopard (intel or ppc) as well.
>
> 1)  Get base code here:
>     svn co https://sshguard.svn.sourceforge.net/svnroot/sshguard  
> sshguard
>
> 2)  Get the patches (both) of them from here:  (save to the
> sshguard/trunk directory from step 1)
>     https://sourceforge.net/tracker/?func=detail&aid=2777559&group_id=188282&atid=924687
>
> 3)  Apply patches and configure/build
>
> su root
> cd sshguard/trunk
> patch <osx_configure_ac_patch.txt
> pushd src/fwalls
> patch <../../ipfw_ipv6_patch_2.txt
> popd
> autoreconf
> ./configure --with-firewall=ipfw
> make clean && make
>
> 4)  If all builds well, try running sshguard with the "-d" parameter
> and paste the following attack example:
>
> e.g.  src/sshguard -d
>
> Attack Example:  (if your email client wraps the string to multiple
> lines, make sure it is one line before you paste into the sshguard
> debug terminal)
>
> Apr 30 12:19:08 minimac sshd[7097]: Failed keyboard-interactive/pam
> for invalid user asdf from 2001:db8::1 port 57453 ssh2
>
> Paste the attack example into the terminal 4 times and you should see
> the following at the end:
>
> Running command: '/sbin/ip6fw add 55045 drop ipv6 from 2001:db8::1  
> to any'.
> 55045 deny ipv6 from 2001:db8::1 to any
> Command exited 0.
> First sight of offender '2001:db8::1:6', adding to offenders list.
>
> If you see any other exit code than "Command exited 0.", please paste
> the entire output buffer in a response email.
>
> --Thanks!
>
> -_Dave H
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] sshguard on OSX 10.5 and ipfw (ipv6)

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

Anyone on this list have access to a OSX 10.5 dev environment that is
willing to test some patches ?

I have a patch for ipfw firewall and ipv6 that I have tested on
FreeBSD 7, and OSX (ppc) 10.4, but I would prefer someone test with
OSX 10.5 or even snow leopard (intel or ppc) as well.

1)  Get base code here:
     svn co https://sshguard.svn.sourceforge.net/svnroot/sshguard sshguard

2)  Get the patches (both) of them from here:  (save to the
sshguard/trunk directory from step 1)
     https://sourceforge.net/tracker/?func=detail&aid=2777559&group_id=188282&atid=924687

3)  Apply patches and configure/build

su root
cd sshguard/trunk
patch <osx_configure_ac_patch.txt
pushd src/fwalls
patch <../../ipfw_ipv6_patch_2.txt
popd
autoreconf
./configure --with-firewall=ipfw
make clean && make

4)  If all builds well, try running sshguard with the "-d" parameter
and paste the following attack example:

e.g.  src/sshguard -d

Attack Example:  (if your email client wraps the string to multiple
lines, make sure it is one line before you paste into the sshguard
debug terminal)

Apr 30 12:19:08 minimac sshd[7097]: Failed keyboard-interactive/pam
for invalid user asdf from 2001:db8::1 port 57453 ssh2

Paste the attack example into the terminal 4 times and you should see
the following at the end:

Running command: '/sbin/ip6fw add 55045 drop ipv6 from 2001:db8::1 to any'.
55045 deny ipv6 from 2001:db8::1 to any
Command exited 0.
First sight of offender '2001:db8::1:6', adding to offenders list.

If you see any other exit code than "Command exited 0.", please paste
the entire output buffer in a response email.

--Thanks!

-_Dave H

Re: [Sshguard-users] Blocking bots looking for vulnerable web apps

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

* Mij <mi...@bi...> [2009-02-06]:
> 
> On Feb 5, 2009, at 9:11 PM, Hans F. Nordhaug wrote:
> 
> > * Forrest Aldrich <fo...@fo...> [2009-02-05]:
> >> I have the same problem -- my method of blocking is visually
> >> doing  "tail -F access.log" and putting filters in.
> >>
> >> To use SSHGuard for this, you'd have to implement pattern
> >> searches  for the specific attacks... might be okay for a few,
> >> annoying for more  than that.   I think something like
> >> mod_security may help in this case (though I've never used it).
> >
> > Well, I don't think you have to do it that strict. I would say that if
> > an IP is getting many 404 entries (maybe with the added condition of
> > empty referrer) in very short time, it's likely to be a scanning
> > attack. SSHGuard by default doesn't block for very long so if it was a
> > legitime user hitting refresh like crazy, it wouldn't harm that much.
> 
> I'm not quite convinced for 2 reasons:
> 1) such rules appear quite "loose". I'm not sure this fits with the
> conservative policy used so far to avoid false positives at the cost
> of complexity.  For example, crawlers issue a "GET /robots.txt"
> which often results in a  404 and lacks a referer. On webservers
> with plenty of vhosts a bunch of such  requests within few minutes
> may result in an undesired blocking.
> 
> A solution can be to add to such conditions sensitivity to the
> target  filetype, and block only those involving dynamic scripts
> like .php, .pl etc.
> 
> 
> 2) Sshguard currently assumes that all attacks have the same
> "density", that is, 4 attacks to ssh are "as dangerous" as 4 to
> proftpd or  anything else.  This case breaks this assumption, as you
> would require many more "404"s than login failures before
> determining an abuse.
> 
> A solution is either to define the conditions above "tight enough"
> to  raise the density of each attack, or to wait for me to
> eventually implement the system based on scoring and threshold.

Thx for your reply, michele, and sorry about not coming back to this
issue before now. To me 1 isn't such a big problem - there are many
ways to work around it. However, 2 is a real problem that I didn't
think about. I clearly can't use the same "density" for SSH and HTTP.
I think I'll wait for you ;-) 

I definetly think this would be a nice addition to SSHGuard, but I
also realize that it might not make sense to extend SSHGuard to handle
every thing. Maybe there are other tools out there that all ready
do the job? I just happen to like SSHGuard.

Regards,
Hans