Re: [rhelv5-list] fail2ban not working as it should
Robert G. (Doc) Savage wrote:
On Mon, 2009-05-04 at 22:49 +0800, John Summerfield wrote:
Robert G. (Doc) Savage wrote:
I'm trying to contend with global SSH brute force attacks with fail2ban.
Apparently I have one or more settings/permissions wrong. Iptables is
not being updated despite waves of attacks, and I'm not getting any
e-mail warnings. Suggestions anybody?
--Doc Savage
Fairview Heights, IL
I've made the following changes to /etc/fail2ban.conf:
background = true
bantime = -1
ignoreip = 192.168.1.1/24
[MAIL] notification
enabled = true
Here is a sample entry from /var/log/secure for an attack on user
'nagios':
May 3 08:41:20 lion sshd[30068]: reverse mapping checking getaddrinfo for
51.82.66.200.in-addr.arpa failed - POSSIBLE BREAK-IN ATTEMPT!
May 3 08:41:20 lion sshd[30068]: pam_unix(sshd:auth): authentication failure;
logname= uid=0 euid=0 tty=ssh ruser= rhost=200.66.82.51 user=nagios
May 3 08:41:22 lion sshd[30068]: Failed password for nagios from 200.66.82.51
port 35501 ssh2
May 3 08:41:22 lion sshd[30069]: Received disconnect from 200.66.82.51: 11:
Bye Bye
I am curious.
I only manage small networks, with little expected ssh traffic. I use
iptables to limit the number of connexion attempts per hour to two or so.
I find I block 90% or so of bad ssh connexions, nothing short of a
distributed attach can home to enumerate passwords, and I don't have
enough bandwidth for anyone to make a realistic attempt to guess a password.
I get messages like yours above,. but not enough to trouble me. I don't
expect every to get none, but on the other hand it's possible someone
might need to connect some time without a key, and maybe get the
password wrong in the process of trying to use it.
I'm sure that there are good reasons my method won't work, but I'd like
to know some of them, just in case.
How many ssh connexions do you expect?
How many are you receiving?
- pam_unix Begin
sshd:
Authentication Failures:
unknown (200.66.82.51): 437 Time(s)
x (200.66.82.51): 14 Time(s)
xx (200.66.82.51): 8 Time(s)
x (200.66.82.51): 8 Time(s)
xx (200.66.82.51): 6 Time(s)
xxx (200.66.82.51): 5 Time(s)
xxx (200.66.82.51): 4 Time(s)
x (200.66.82.51): 4 Time(s)
xxx (200.66.82.51): 4 Time(s)
root (200.66.82.51): 2 Time(s)
(200.66.82.51): 1 Time(s)
x (200.66.82.51): 1 Time(s)
root (nlos-41.222.17.240.iconnect.zm): 1 Time(s)
Invalid Users:
Unknown Account: 437 Time(s)
-- pam_unix End -
- SSHD Begin
Failed logins from:
41.222.17.240 (nlos-41.222.17.240.iconnect.zm): 1 time
200.66.82.51 (51.82.66.200.in-addr.arpa): 57 times
Illegal users from:
200.66.82.51 (51.82.66.200.in-addr.arpa): 437 times
Users logging in through sshd:
root:
192.168.1.XXX (xx.x.xxx): 1 time
Received disconnect:
11: Bye Bye : 494 Time(s)
**Unmatched Entries**
pam_succeed_if(sshd:auth): error retrieving information about user
CounterStrike : 1 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user tribox : 1
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user teamspeak :
10 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user stephanie :
4 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user info : 3
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user informix :
8 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user web7 : 16
time(s)
...
pam_succeed_if(sshd:auth): error retrieving information about user ts : 15
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user cod3 : 1
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user web4 : 3
time(s)
For comparison:
- Kernel Begin
Dropped 361 packets on interface eth0
From 58.61.156.101 - 3 packets to tcp(22)
From 59.77.25.61 - 27 packets to tcp(22)
From 86.126.16.27 - 69 packets to tcp(22)
From 86.126.78.53 - 99 packets to tcp(22)
From 117.21.127.102 - 6 packets to tcp(22)
From 124.254.7.198 - 16 packets to tcp(22)
From 140.114.196.35 - 30 packets to tcp(22)
From 202.103.0.117 - 27 packets to tcp(22)
From 210.51.171.74 - 30 packets to tcp(22)
From 210.245.81.31 - 15 packets to tcp(22)
From 219.148.34.4 - 25 packets to tcp(22)
From 220.184.13.87 - 14 packets to tcp(22)
Logged 23 packets on interface eth0
From 58.61.156.101 - 1 packet to tcp(22)
From 59.77.25.61 - 2 packets to tcp(22)
From 86.126.16.27 - 5 packets to tcp(22)
From 117.21.127.102 - 2 packets to tcp(22)
From 124.254.7.198 - 2 packets to tcp(22)
From 140.114.196.35 - 2 packets to t
Re: [rhelv5-list] fail2ban not working as it should
On Tue, 2009-05-05 at 11:26 +0200, shrek-m gmx.de wrote: > Am 05.05.2009 09:05, Tim schrieb: > > I know this isn't what you asked but I use BlockSSHD to do what you > > want fail2ban to do. > > > > http://blocksshd.sourceforge.net/ > > > > Works for me. > > or denyhosts > http://download.fedora.redhat.com/pub/epel/5/i386/denyhosts-2.6-5.el5.noarch.rpm > Or pam_abl http://www.hexten.net/wiki/index.php/Pam_abl which is available via yum from the rpmforge collection using: [rpmforge] name = Red Hat Enterprise $releasever - RPMforge.net - dag mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge enabled = 0 protect = 0 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag gpgcheck = 1 Andy ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
RE: [rhelv5-list] fail2ban not working as it should
> > > > Sorry. I should have included version info: > > > > $ rpm -qa | grep fail2ban > > > > fail2ban-0.6.2-3.el5 > > > > > > Why don't you upgrade to a later version? I've seen several > > other complaints regarding similar iptables errors with > > fail2ban and it seems an upgrade is what everyone was proposing. > > > > Justin, > > This is the latest version for RHEL5 in the EPEL repository. Is anyone > > at Red Hat actually tracking this package, or is its inclusion in EPEL > > just a convenience? > > I've been told and also read somewhere that the contents of EPEL is on > the sponsors' shoulders. It's existence is for our convenience. if someone is concerned about the current status of an EPEL (or even RHEL or Fedora) package you have a few routes base on my experience. IMHO the best option is to download the latest SRPM and update it to the latest version of the package, then send an e-mail to the package maintainer(s) offering up the new SRPM for their review. Sometimes there is a good technical reason they haven't updated it, but other times it could just be because they've been busy (it happens to all of us). At the end of it you at least have the updated package for yourself, which if you have space you can host for the others you've found in your position. If upping the package is something you don't feel comfortable with, you can try contacting the packager in a similar manner, asking if they know when it will be updated, or just filing a bug in the appropriate distribution's bugzilla. -greg ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
RE: [rhelv5-list] fail2ban not working as it should
I've been told and also read somewhere that the contents of EPEL is on the sponsors' shoulders. It's existence is for our convenience. Patti Clark Sr. Linux Administrator DOE/OSTI > -Original Message- > From: rhelv5-list-boun...@redhat.com > [mailto:rhelv5-list-boun...@redhat.com] On Behalf Of Robert > G. (Doc) Savage > Sent: Tuesday, May 05, 2009 7:29 AM > To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list > Subject: Re: [rhelv5-list] fail2ban not working as it should > > > On Tue, 2009-05-05 at 09:08 +0100, Justin Cook wrote: > > On Mon, May 04, 2009 at 10:06:54PM -0500, Robert G. (Doc) > Savage wrote: > > > Sorry. I should have included version info: > > > $ rpm -qa | grep fail2ban > > > fail2ban-0.6.2-3.el5 > > > > Why don't you upgrade to a later version? I've seen several > other complaints regarding similar iptables errors with > fail2ban and it seems an upgrade is what everyone was proposing. > > Justin, > This is the latest version for RHEL5 in the EPEL repository. Is anyone > at Red Hat actually tracking this package, or is its inclusion in EPEL > just a convenience? > --Doc > > ___ > rhelv5-list mailing list > rhelv5-list@redhat.com > https://www.redhat.com/mailman/listinfo/rhelv5-list > ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
On Tue, May 05, 2009 at 06:29:07AM -0500, Robert G. (Doc) Savage wrote: > This is the latest version for RHEL5 in the EPEL repository. Is anyone > at Red Hat actually tracking this package, or is its inclusion in EPEL > just a convenience? Someone packaged that version a few years ago and made it available via EPEL. I notice in Dag's repo a much newer version, albeit still not the latest: http://dag.wieers.com/rpm/packages/fail2ban/fail2ban-0.8.1-1.el5.rf.noarch.rpm If you cannot get that one to work, then just download the latest tarball and install manually. I know it's not the best way, but most likely it will work :) -- Justin Cook ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
On Tue, 2009-05-05 at 09:08 +0100, Justin Cook wrote: > On Mon, May 04, 2009 at 10:06:54PM -0500, Robert G. (Doc) Savage wrote: > > Sorry. I should have included version info: > > $ rpm -qa | grep fail2ban > > fail2ban-0.6.2-3.el5 > > Why don't you upgrade to a later version? I've seen several other complaints > regarding similar iptables errors with fail2ban and it seems an upgrade is > what everyone was proposing. Justin, This is the latest version for RHEL5 in the EPEL repository. Is anyone at Red Hat actually tracking this package, or is its inclusion in EPEL just a convenience? --Doc ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
On Mon, May 04, 2009 at 10:06:54PM -0500, Robert G. (Doc) Savage wrote: > Sorry. I should have included version info: > $ rpm -qa | grep fail2ban > fail2ban-0.6.2-3.el5 Why don't you upgrade to a later version? I've seen several other complaints regarding similar iptables errors with fail2ban and it seems an upgrade is what everyone was proposing. -- Justin Cook ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
Am 05.05.2009 09:05, Tim schrieb: > I know this isn't what you asked but I use BlockSSHD to do what you > want fail2ban to do. > > http://blocksshd.sourceforge.net/ > > Works for me. or denyhosts http://download.fedora.redhat.com/pub/epel/5/i386/denyhosts-2.6-5.el5.noarch.rpm -- shrek-m ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
Robert G. (Doc) Savage wrote: --SNIP-- Those 437 Unknown Account failures appear to be typical of your script kiddie brute force attack. Some days logwatch reports mover 2,000 failed attempts. What annoys the crap out of me is that most of the attacking IP addresses resolve to PRC. I'm pretty careful about setting up my systems to minimize the number of services and accounts, and to use strong passwords. When I read about fail2ban it seemed to be a solid way to use iptables to further harden my system against those IP addresses that demonstrably make obnoxious asses of themselves -- Peoples Liberation Army or whoever. --Doc I know this isn't what you asked but I use BlockSSHD to do what you want fail2ban to do. http://blocksshd.sourceforge.net/ Works for me. -- Tim ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
On Mon, 2009-05-04 at 22:49 +0800, John Summerfield wrote:
> Robert G. (Doc) Savage wrote:
> > I'm trying to contend with global SSH brute force attacks with fail2ban.
> > Apparently I have one or more settings/permissions wrong. Iptables is
> > not being updated despite waves of attacks, and I'm not getting any
> > e-mail warnings. Suggestions anybody?
> >
> > --Doc Savage
> > Fairview Heights, IL
> >
> > I've made the following changes to /etc/fail2ban.conf:
> >
> > background = true
> > bantime = -1
> > ignoreip = 192.168.1.1/24
> > [MAIL] notification
> > enabled = true
> >
> > Here is a sample entry from /var/log/secure for an attack on user
> > 'nagios':
> >
> > May 3 08:41:20 lion sshd[30068]: reverse mapping checking getaddrinfo for
> > 51.82.66.200.in-addr.arpa failed - POSSIBLE BREAK-IN ATTEMPT!
> > May 3 08:41:20 lion sshd[30068]: pam_unix(sshd:auth): authentication
> > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.66.82.51
> > user=nagios
> > May 3 08:41:22 lion sshd[30068]: Failed password for nagios from
> > 200.66.82.51 port 35501 ssh2
> > May 3 08:41:22 lion sshd[30069]: Received disconnect from 200.66.82.51:
> > 11: Bye Bye
>
> I am curious.
>
> I only manage small networks, with little expected ssh traffic. I use
> iptables to limit the number of connexion attempts per hour to two or so.
>
> I find I block 90% or so of bad ssh connexions, nothing short of a
> distributed attach can home to enumerate passwords, and I don't have
> enough bandwidth for anyone to make a realistic attempt to guess a password.
>
> I get messages like yours above,. but not enough to trouble me. I don't
> expect every to get none, but on the other hand it's possible someone
> might need to connect some time without a key, and maybe get the
> password wrong in the process of trying to use it.
>
> I'm sure that there are good reasons my method won't work, but I'd like
> to know some of them, just in case.
>
> How many ssh connexions do you expect?
> How many are you receiving?
>
> Here are my relevant rules:
>
> LOGtcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22
> state NEW limit: avg 5/hour burst 5 LOG flags 0 level 4 prefix
> `SSH connexion '
> ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22
> state NEW limit: avg 5/hour burst 5
> LOGtcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22
> LOG flags 0 level 4 prefix `SSH connexion attack dropped '
> DROP tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22
>
> Before these, there are rules for sites explicitly allowed, so these
> rules apply to the rest of the world. Would something of this kind help
> you? I would think a limit well above your expected rate (or, like me,
> some rules to permit approved locations) might help.
John,
Today's logwatch e-mail report is smaller than usual, but fairly
typical:
- pam_unix Begin
sshd:
Authentication Failures:
unknown (200.66.82.51): 437 Time(s)
x (200.66.82.51): 14 Time(s)
xx (200.66.82.51): 8 Time(s)
x (200.66.82.51): 8 Time(s)
xx (200.66.82.51): 6 Time(s)
xxx (200.66.82.51): 5 Time(s)
xxx (200.66.82.51): 4 Time(s)
x (200.66.82.51): 4 Time(s)
xxx (200.66.82.51): 4 Time(s)
root (200.66.82.51): 2 Time(s)
(200.66.82.51): 1 Time(s)
x (200.66.82.51): 1 Time(s)
root (nlos-41.222.17.240.iconnect.zm): 1 Time(s)
Invalid Users:
Unknown Account: 437 Time(s)
-- pam_unix End -
- SSHD Begin
Failed logins from:
41.222.17.240 (nlos-41.222.17.240.iconnect.zm): 1 time
200.66.82.51 (51.82.66.200.in-addr.arpa): 57 times
Illegal users from:
200.66.82.51 (51.82.66.200.in-addr.arpa): 437 times
Users logging in through sshd:
root:
192.168.1.XXX (xx.x.xxx): 1 time
Received disconnect:
11: Bye Bye : 494 Time(s)
**Unmatched Entries**
pam_succeed_if(sshd:auth): error retrieving information about user
CounterStrike : 1 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user tribox : 1
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user teamspeak :
10 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user stephanie :
4 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user info : 3
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user informix :
8 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user web7 : 16
time(s)
...
pam_succeed_if(sshd:auth): error retrieving information about user ts : 15
time(s)
pam_succeed_if(sshd:auth): error retrieving information about user cod3 : 1
time(s)
pam_succeed_if(sshd:auth): error retrieving in
Re: [rhelv5-list] fail2ban not working as it should
On Mon, 2009-05-04 at 09:56 +0100, Justin Cook wrote: > According to the logs, your SMTP server is refusing the sender. AFA > the iptables exit codes, what version of fail2ban are you using? > > On Mon, May 4, 2009 at 2:28 AM, Robert G. (Doc) Savage > wrote: > > I'm trying to contend with global SSH brute force attacks with fail2ban. > > Apparently I have one or more settings/permissions wrong. Iptables is > > not being updated despite waves of attacks, and I'm not getting any > > e-mail warnings. Suggestions anybody? Justin, Sorry. I should have included version info: $ rpm -qa | grep fail2ban fail2ban-0.6.2-3.el5 --Doc ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
Robert G. (Doc) Savage wrote: I'm trying to contend with global SSH brute force attacks with fail2ban. Apparently I have one or more settings/permissions wrong. Iptables is not being updated despite waves of attacks, and I'm not getting any e-mail warnings. Suggestions anybody? --Doc Savage Fairview Heights, IL I've made the following changes to /etc/fail2ban.conf: background = true bantime = -1 ignoreip = 192.168.1.1/24 [MAIL] notification enabled = true Here is a sample entry from /var/log/secure for an attack on user 'nagios': May 3 08:41:20 lion sshd[30068]: reverse mapping checking getaddrinfo for 51.82.66.200.in-addr.arpa failed - POSSIBLE BREAK-IN ATTEMPT! May 3 08:41:20 lion sshd[30068]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.66.82.51 user=nagios May 3 08:41:22 lion sshd[30068]: Failed password for nagios from 200.66.82.51 port 35501 ssh2 May 3 08:41:22 lion sshd[30069]: Received disconnect from 200.66.82.51: 11: Bye Bye I am curious. I only manage small networks, with little expected ssh traffic. I use iptables to limit the number of connexion attempts per hour to two or so. I find I block 90% or so of bad ssh connexions, nothing short of a distributed attach can home to enumerate passwords, and I don't have enough bandwidth for anyone to make a realistic attempt to guess a password. I get messages like yours above,. but not enough to trouble me. I don't expect every to get none, but on the other hand it's possible someone might need to connect some time without a key, and maybe get the password wrong in the process of trying to use it. I'm sure that there are good reasons my method won't work, but I'd like to know some of them, just in case. How many ssh connexions do you expect? How many are you receiving? Here are my relevant rules: LOGtcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22 state NEW limit: avg 5/hour burst 5 LOG flags 0 level 4 prefix `SSH connexion ' ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22 state NEW limit: avg 5/hour burst 5 LOGtcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22 LOG flags 0 level 4 prefix `SSH connexion attack dropped ' DROP tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:22 Before these, there are rules for sites explicitly allowed, so these rules apply to the rest of the world. Would something of this kind help you? I would think a limit well above your expected rate (or, like me, some rules to permit approved locations) might help. -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
Re: [rhelv5-list] fail2ban not working as it should
According to the logs, your SMTP server is refusing the sender. AFA the iptables exit codes, what version of fail2ban are you using? On Mon, May 4, 2009 at 2:28 AM, Robert G. (Doc) Savage wrote: > I'm trying to contend with global SSH brute force attacks with fail2ban. > Apparently I have one or more settings/permissions wrong. Iptables is > not being updated despite waves of attacks, and I'm not getting any > e-mail warnings. Suggestions anybody? -- Justin Cook ___ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
