Menu
▾
▴
sshguard-users
|
From: Greg P. <gre...@hc...> - 2009-03-10 13:01:57
|
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 |
|
From: Mij <mi...@bi...> - 2009-03-14 12:33:30
|
As SimCList is used for recording those, there is no such limit by design. What evidence makes you think that (nothing logged, errors or else)? 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. > 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |
|
From: Mij <mi...@bi...> - 2009-03-16 02:28:57
|
As SimCList is used for recording those, there is no such limit by design. What evidence makes you think that (nothing logged, errors or else)? 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. 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Greg P. <gre...@hc...> - 2009-03-17 12:15:43
|
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
>>
|
|
From: Greg P. <gre...@hc...> - 2009-03-26 16:10:44
|
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 |
|
From: Mij <mi...@bi...> - 2009-04-17 08:26:46
|
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 |
|
From: Greg P. <gre...@hc...> - 2009-04-21 12:27:41
|
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. 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? 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. 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 |
|
From: Mij <mi...@bi...> - 2009-07-03 15:12:32
|
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 |
|
From: Greg P. <gpa...@hi...> - 2009-07-04 02:34:56
|
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 |
|
From: Greg P. <gre...@hc...> - 2009-04-08 14:11:30
|
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 > > I am still having this same issue as it continues every few days. This time had about 20 entries in the iptable sshguard chain before it stop working. 1. Start sshguard using init script 2. Runs fine and stops attacks for days (verified with logwatch) 3. New logwatch shows many ssh root login attempts from single IP 4. Restart sshgaurd using init, clears iptables chain and begins working I have verified the above using my own failed login from outside hosts. Again I stopped sshguard using pkill and then the init (which clears the chain filter list) and ran this manually as requested and it does nothing, no log, no screen output. Can I get some idea on how to better troubleshoot this issue please? [root@hostname ~]# /usr/local/sbin/sshguard -d -a 2 -p 2592000 -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, 2592000, 1800)], now ready to scan. After a few attacks from the outside (>2) there is no blocking, no log, nothing when running this manually as suggested previously as seen above. Thanks much, -greg |
|
From: Mij <mi...@bi...> - 2009-04-17 08:17:14
|
On Apr 8, 2009, at 14:27 , Greg Parrish wrote: > I am still having this same issue as it continues every few days. This > time had about 20 entries in the iptable sshguard chain before it stop > working. > > 1. Start sshguard using init script > 2. Runs fine and stops attacks for days (verified with logwatch) > 3. New logwatch shows many ssh root login attempts from single IP > 4. Restart sshgaurd using init, clears iptables chain and begins > working > > I have verified the above using my own failed login from outside > hosts. > > Again I stopped sshguard using pkill and then the init (which clears > the > chain filter list) and ran this manually as requested and it does > nothing, no log, no screen output. Can I get some idea on how to > better > troubleshoot this issue please? this is interesting news. I have never observed this behavior and I'm very interested in it. Please do this: 1) wait until you observe this behaviour (stopping recognition) 2) locate the place in logs where sshguard started last 3) send in all the log activity related to ssh after that. You can easily use awk to obfuscate hostnames, IPs and user names. As I can't reproduce this behaviour, I don't see any other way to inspect the problem. > > [root@hostname ~]# /usr/local/sbin/sshguard -d -a 2 -p 2592000 -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, 2592000, 1800)], now ready to scan. > > > After a few attacks from the outside (>2) there is no blocking, no > log, > nothing when running this manually as suggested previously as seen > above. > > Thanks much, > -greg |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X