Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
Thx Rainer
On 04/04/11 11:18, Rainer Traut wrote:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
This is just a hunch, but --seconds 60 indicates that it will only look back one minute to check if it could find a hit. So if the attacker tries to connect again after 2 minutes or even 61 seconds, it won't trigger this rule. Try increasing this value to 3600 (1 hour). Maybe you want even longer.
kind regards,
David Sommerseth
On 04/04/11 11:18, Rainer Traut wrote:
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
i see similar results on some of my servers, eg:
% grep 'a.bad.ip.address' authpriv|grep 'authentication failure'|awk '{print $3}'|less 15:47:44 15:49:34 15:49:46 15:51:32 15:53:17 15:53:30 15:55:14 15:56:59 15:58:44 16:00:34 16:02:19 16:02:31 16:04:17 [...]
so i can see that yes, at least some automated scripts have been adapted to back off in an attempt not to trip my iptables rules. you can do a similar grep to see the times of your attempts, and that will tell you if they're running a softly-softly script, or if instead they have found a way to test many passwords without tripping the iptables rule.
On Mon, 4 Apr 2011, David Sommerseth wrote:
This is just a hunch, but --seconds 60 indicates that it will only look back one minute to check if it could find a hit. So if the attacker tries to connect again after 2 minutes or even 61 seconds, it won't trigger this rule. Try increasing this value to 3600 (1 hour). Maybe you want even longer.
i occasionally trip my iptables rule myself, for example if i scp a couple of files off a server and then go back for a third; i feel it would be a shame to lock myself out for an hour, by doing that.
the way i see it is that, even in the limiting case where an attacker can try two passwords every minute, she will be limited to just under 3,000 attempts a day, and that's not very many when you're trying to brute-force decent passwords. given that most of those are attempts to guess root's password, and i have "PermitRootLogin no" in sshd_config, the tiny additional load caused by an attempt every 30 seconds is something i can live with in exchange for not locking myself out for too long.
how long you set your lockout for is a call you must make for your server(s); i just wanted you to have more points of view about what people are doing out there in the wild.
On Mon, 4 Apr 2011, Tom Yates wrote:
i occasionally trip my iptables rule myself, for example if i scp a couple of files off a server and then go back for a third; i feel it would be a shame to lock myself out for an hour, by doing that.
An argument for something like pam_tally? Ideally, you'd want it to be IP specific like your iptables techniques. You do really want something that can distinguish between a successful and a failed login though.
jh
On Monday 04 April 2011 12:18:43 Rainer Traut wrote:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Marian
Thx Rainer _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 04.04.2011 12:34, schrieb Marian Marinov:
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Ok, thanks to both of you, it seems the scripts getting better and better. Will change my iptables rule to keep the blacklist for longer.
Thx Rainer
Am Montag, den 04.04.2011, 15:07 +0200 schrieb Rainer Traut:
Am 04.04.2011 12:34, schrieb Marian Marinov:
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Ok, thanks to both of you, it seems the scripts getting better and better. Will change my iptables rule to keep the blacklist for longer.
Thx Rainer
Also check MaxAuthTries in /etc/ssh/sshd_config
Specifies the maximum number of authentication attempts permitted per connection.
Henry
On 04/04/11 15:35, henry ritzlmayr wrote:
Am Montag, den 04.04.2011, 15:07 +0200 schrieb Rainer Traut:
Am 04.04.2011 12:34, schrieb Marian Marinov:
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Ok, thanks to both of you, it seems the scripts getting better and better. Will change my iptables rule to keep the blacklist for longer.
Thx Rainer
Also check MaxAuthTries in /etc/ssh/sshd_config
Specifies the maximum number of authentication attempts permitted per connection.
That won't do too much. It only tells the ssh server how many attempts to accept before closing the TCP connection. The attacker can still just re-connect and try again, which is what usually happens during these attempts. Of course, setting MaxAuthTries to 1, will slow the attacker a little bit down, as it needs to re-establish the SSH connection again.
Moving over to disallowing password authentication and only use pubkey with ~/.ssh/authorized_keys is probably going to do a better job securing the server.
kind regards,
David Sommerseth
Am Montag, den 04.04.2011, 16:04 +0200 schrieb David Sommerseth:
On 04/04/11 15:35, henry ritzlmayr wrote:
Am Montag, den 04.04.2011, 15:07 +0200 schrieb Rainer Traut:
Am 04.04.2011 12:34, schrieb Marian Marinov:
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Ok, thanks to both of you, it seems the scripts getting better and better. Will change my iptables rule to keep the blacklist for longer.
Thx Rainer
Also check MaxAuthTries in /etc/ssh/sshd_config
Specifies the maximum number of authentication attempts permitted per connection.
That won't do too much. It only tells the ssh server how many attempts to accept before closing the TCP connection. The attacker can still just re-connect and try again, which is what usually happens during these attempts. Of course, setting MaxAuthTries to 1, will slow the attacker a little bit down, as it needs to re-establish the SSH connection again.
Right, but with setting MaxAuthTries to 1, the iptables rule specified by the OP jumps in much earlier.
Moving over to disallowing password authentication and only use pubkey with ~/.ssh/authorized_keys is probably going to do a better job securing the server.
kind regards,
David Sommerseth
Henry
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rainer Traut wrote:
Am 04.04.2011 12:34, schrieb Marian Marinov:
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Ok, thanks to both of you, it seems the scripts getting better and better. Will change my iptables rule to keep the blacklist for longer.
May I highly commend to your attention fail2ban? We use it, and it works very well. Default is 3 from an IP, 5 for ssh, and it's banned for a configurable amount of time - default is 2 hours. And you can add additional filters.
mark
You could also try using tcpwrappers along with iptables.
On 04/04/2011 06:34 AM, Marian Marinov wrote:
On Monday 04 April 2011 12:18:43 Rainer Traut wrote:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Marian
Thx Rainer _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Guys, really... look at denyhosts and Hawk.
Both projects analyze the logs of the service and check for failed login attempts.
It is useless to battle the bruteforcers at the network level since they can adapt their behaviour to really easy surcomvent any firewalls.
In order to protect your applications you should build on them. Every daemon now has a decent log capabilities. And you can simply tail the log constantly and detect which IPs should be blocked. And then block them promptly.
It is hard to find someone that will enter the wrong password more then 10 times :)
I don't know for denyhosts, but Hawk removes the blocks every day and you can configure how long you want to keep a single IP blocked. This way you have better control over the automated block/unblock procedure.
If you need more information about Hawk, contact me.
Marian
On Monday 04 April 2011 17:18:58 Jason Brown wrote:
You could also try using tcpwrappers along with iptables.
On 04/04/2011 06:34 AM, Marian Marinov wrote:
On Monday 04 April 2011 12:18:43 Rainer Traut wrote:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name SSH --rsource
And this is part of logwatch:
sshd: Authentication Failures: unknown (www.telkom.co.ke): 137 Time(s) unknown (mkongwe.jambo.co.ke): 130 Time(s) unknown (212.49.70.24): 107 Time(s) root (195.191.250.101): 8 Time(s)
How is it possible for an attacker to try to logon more then 4 times? Can the attacker do this with only one TCP/IP connection without establishing a new one? Or have the scripts been adapted to this?
The attackers are not trying constantly.. Just a few bursts of trys.
Look at denyhosts ( http://denyhosts.sourceforge.net/ ). I also have a tool for protecting from brute force attacks called Hawk ( https://github.com/hackman/Hawk-IDS-IPS ).
Marian
Thx Rainer _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hey you should check out fail2ban as well. Excellent little app that analysis the log for the corresponding demon using a regex (u can create custom ones too) and performs an action you choose including iptables, hosts.deny, etc.. You can easily adjust setting like 3 failed connections max per min, etc..
Works well for sshd, postfix, httpd, etc..also fires you an email when a attack is stopped
Simple and very effective. Definitely worth checking out
Aly
Sent from my BlackBerry device on the Rogers Wireless Network
-----Original Message----- From: Marian Marinov mm@yuhu.biz Sender: centos-bounces@centos.org Date: Mon, 4 Apr 2011 18:00:23 To: CentOS mailing listcentos@centos.org Reply-To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] sshd: Authentication Failures: 137 Time(s)
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rainer Traut <tr.ml@...> writes:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
SNIP
Lots of good advice from several people. All of the suggested solutions mean you still have to wade through log entries from the unsuccessful attacks.
I've been quite happy with similar IP tables rules but I moved sshd to listen on something other than port 22 for external connections. I haven't seen a single brute force attack since making the move and all unsuccessful attempts to login via ssh get logged so it's not like attackers can stay below my radar.
It seems that the script kiddies who are responsible for most of these attacks don't bother scanning (nmap) before the attack. If port 22 isn't open they move elsewhere. If I ever see any failed login attempts I can assume that the perpetrator is at least a little more skilled than usual and possibly take additional action.
Cheers, Dave
David G. Miller wrote:
Rainer Traut <tr.ml@...> writes:
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
SNIP
Lots of good advice from several people. All of the suggested solutions mean you still have to wade through log entries from the unsuccessful
attacks.
Excerpt for tools like fail2ban.
I've been quite happy with similar IP tables rules but I moved sshd to listen on something other than port 22 for external connections. I
haven't seen a
single brute force attack since making the move and all unsuccessful
attempts to
login via ssh get logged so it's not like attackers can stay below my
radar.
It seems that the script kiddies who are responsible for most of these attacks don't bother scanning (nmap) before the attack. If port 22
isn't open
they move elsewhere. If I ever see any failed login attempts I can
assume that the
perpetrator is at least a little more skilled than usual and possibly take additional action.
*sigh* It's not even script kiddies much, anymore: it's China, and Brazil, and then, way down, Russia, Thailand, Italy, the Netherlands, etc, etc. - botnets.
Some are, obviously, with misspelled logins (from last night: comercial), or a, aa, aaa) but some do know: root, oracle, netdump....
mark "ah, to return to the good ol' days, before Cantor and Siegal"
On Monday 04 April 2011 21:08:45 David G.Miller wrote:
Rainer Traut <tr.ml@...> writes:
Hi,
to prevent scripted dictionary attacks to sshd
I applied those iptables rules:
SNIP
Lots of good advice from several people. All of the suggested solutions mean you still have to wade through log entries from the unsuccessful attacks.
I've been quite happy with similar IP tables rules but I moved sshd to listen on something other than port 22 for external connections. I haven't seen a single brute force attack since making the move and all unsuccessful attempts to login via ssh get logged so it's not like attackers can stay below my radar.
This does not help if you provide a public services like shared hosting. We have all of our ssh daemons listening on different port. It was ok for a month or two... and then it became almost the same.
It seems that the script kiddies who are responsible for most of these attacks don't bother scanning (nmap) before the attack. If port 22 isn't open they move elsewhere. If I ever see any failed login attempts I can assume that the perpetrator is at least a little more skilled than usual and possibly take additional action.
Cheers, Dave
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
David G. Miller wrote:
Rainer Traut <tr.ml@...> writes:
Hi,
to prevent scripted dictionary attacks to sshd I applied those iptables rules:
SNIP
Lots of good advice from several people. All of the suggested solutions mean you still have to wade through log entries from the unsuccessful attacks.
I've been quite happy with similar IP tables rules but I moved sshd to listen on something other than port 22 for external connections. I haven't seen a single brute force attack since making the move and all unsuccessful attempts to login via ssh get logged so it's not like attackers can stay below my radar.
It seems that the script kiddies who are responsible for most of these attacks don't bother scanning (nmap) before the attack. If port 22 isn't open they move elsewhere. If I ever see any failed login attempts I can assume that the perpetrator is at least a little more skilled than usual and possibly take additional action.
Cheers, Dave
I use Denyhosts for my security. All attacking IP's are blocked automatically and sent to Denyhosts database server. Those IP's, from around the world are then shared amongst all denyhosts users/systems, so I am already protected from IP's attacking others.
Ljubomir
--On Monday, April 04, 2011 09:15:28 PM +0200 Ljubomir Ljubojevic office@plnet.rs wrote:
I use Denyhosts for my security. All attacking IP's are blocked automatically and sent to Denyhosts database server. Those IP's, from around the world are then shared amongst all denyhosts users/systems, so I am already protected from IP's attacking others.
Note that that is an optional behavior that is not enabled by default.
Yes, denyhosts has a configurable expiry time.
FWIW, denyhosts and fail2ban are pretty much the same in the context of SSH. If you have other services that you want to protect from brute force attacks, fail2ban might be the better option. (Denyhosts will optionally ban all ports to an attacker, but only after they've tried to brute-force ssh.)
Hi,
to prevent scripted dictionary attacks to
sshd
I applied those iptables rules:
-A
INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent
--update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set
--name SSH --rsource
What I have done to totally thwart script-kiddy attacks against SSH is to
1) Move sshd to another port, one higher than 5000 2) configure SSH for RSA-KEY authentication ONLY IE no PAM auth 3) Set up Fail2Ban to auto ip-table block ANY offending IPs after 5 tries.
Script kiddies assume ssh is on port 22, and mosr posr scans don't go as high as 5000.
Since I implement this strategy a month ago, I have seen ZERO attempts against SSH
_______________________________________________
CentOS mailing
list
CentOS@centos.org
On Tue, Apr 5, 2011 at 10:17 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 5 Apr 2011, rrichard@blythe.org wrote:
- Move sshd to another
port, one higher than 5000
I'd have mixed feelings about the Wisdom of running on a non-reserved port.
Why,
We've been running SSH on hundreds of servers on a port higher than 5000 for year now and no problems at all.
On Tue, 5 Apr 2011, Rudi Ahlers wrote:
Why,
We've been running SSH on hundreds of servers on a port higher than 5000 for year now and no problems at all.
I always feel slightly ickie about running services on ports normal users can run on (this obviously depends a lot on who can run processes on the host). Anything that can convince sshd to restart or crash can then potentially nobble that port. With an intelligent user base this is no worse than any other man-in-the-middle attack or DoS since they'll refuse to login when the key doesn't match.
jh
On Tuesday 05 April 2011 11:27:49 Rudi Ahlers wrote:
On Tue, Apr 5, 2011 at 10:17 AM, John Hodrien J.H.Hodrien@leeds.ac.uk
wrote:
On Tue, 5 Apr 2011, rrichard@blythe.org wrote:
- Move sshd to another
port, one higher than 5000
I'd have mixed feelings about the Wisdom of running on a non-reserved port.
Why,
We've been running SSH on hundreds of servers on a port higher than 5000 for year now and no problems at all.
I'm also running ssh on non standard port for more then 7 years and this is on a couple of thousend servers. Its not a problem if you simply add 'Port XXX' to your ~/.ssh/config .
However, the traffic to ssh has reduced with only 40%. In the begining it was very good, we were surprised, how almost all failed attempts dissapeared. But in the following months that number increased and reached 60-65% of the original number.
Introducing a Hawk helped us a lot. Tools like Hawk and fail2ban are quite useful, actually only thinks like that have good impact on the bruteforce attempts.
Regards, Marian Marinov
Introducing a Hawk helped us a lot. Tools like Hawk and
fail2ban are quite
useful, actually only thinks like that have
good impact on the bruteforce
attempts.
Indeed! I run Fail2Ban not only against SSH, but against SMTP/AUTH and IMAPS/POP3S (the only client mail protocols we support). It's amazing how many dictionary attacks take place against SMTP by persistent spamers! Besides the effect against dictionary attacks, it makes the morning reading of the secure log a pleasant experience. :-)
However, moving to a non-standard SSH port has had a profound effect on the attempts. It's a triple whammy for the script kiddies. Find the port if you can, then you get 5 tries at a non-existent username/password before your packets get dropped on the floor, and you are totally blocked from the entire system for an hour.
Bob
On Tue, Apr 5, 2011 at 5:51 PM, rrichard@blythe.org wrote:
Introducing a Hawk helped us a lot. Tools like Hawk and
fail2ban are quite
useful, actually only thinks like that have
good impact on the bruteforce
attempts.
Indeed! I run Fail2Ban not only against SSH, but against SMTP/AUTH and IMAPS/POP3S (the only client mail protocols we support). It's amazing how many dictionary attacks take place against SMTP by persistent spamers! Besides the effect against dictionary attacks, it makes the morning reading of the secure log a pleasant experience. :-)
However, moving to a non-standard SSH port has had a profound effect on the attempts. It's a triple whammy for the script kiddies. Find the port if you can, then you get 5 tries at a non-existent username/password before your packets get dropped on the floor, and you are totally blocked from the entire system for an hour.
Bob
fail2ban work very well against SSH, SMTP, POP3, FTP, etc, etc.
Another useful tool is Config Server Firewall, which offers DDOS protection, and can be configured to email you when someone was blocked for bruteforce attempts.
OR, you can use Port Knocking - which is a iptables script which monitors 2 or 3 ports, when telnetted to in a pre-configured sequence will open the SSH port in the firewall. This also works very well
rrichard@blythe.org wrote:
Indeed! I run Fail2Ban not only against SSH, but against SMTP/AUTH and IMAPS/POP3S (the only client mail protocols we support). It's amazing how many dictionary attacks take place against SMTP by persistent spamers! Besides the effect against dictionary attacks, it makes the morning reading of the secure log a pleasant experience. :-)
My SMTP server has Reverse DNS check active, so any SMTP request from IP that does not have Reverse DNS record is automatically forbidden. Even SMTP servers tht are not properly configured (like one Bank server in my country that sends mails from some obscure IP without DNS record even thou I know they are legit) are denied.
fail2ban had some wrong with it, from the standpoint of my CentOS 5.x server (can't remember what I disliked), wheather it was rpm availability or something else, so I chose denyhosts. There was whole week recently without a single ssh attack on my 3 PC's (2 servers).
Ljubomir
On Apr 5, 2011, at 11:46 PM, Ljubomir Ljubojevic wrote:
rrichard@blythe.org wrote:
Indeed! I run Fail2Ban not only against SSH, but against SMTP/AUTH and IMAPS/POP3S (the only client mail protocols we support). It's amazing how many dictionary attacks take place against SMTP by persistent spamers! Besides the effect against dictionary attacks, it makes the morning reading of the secure log a pleasant experience. :-)
My SMTP server has Reverse DNS check active, so any SMTP request from IP that does not have Reverse DNS record is automatically forbidden. Even SMTP servers tht are not properly configured (like one Bank server in my country that sends mails from some obscure IP without DNS record even thou I know they are legit) are denied.
fail2ban had some wrong with it, from the standpoint of my CentOS 5.x server (can't remember what I disliked), wheather it was rpm availability or something else, so I chose denyhosts. There was whole week recently without a single ssh attack on my 3 PC's (2 servers).
Ljubomir _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I have a centralized bridge PF (Packet Filter) setup and all my servers behind it. All the servers have fail2ban installed and the same on the firewall, so any malicious knock offs on the internal servers ignites the centralized PF that blocks the hosts right away. As mentioned above, I have been using fail2ban for SSH/SMTP/IMAP/POP3 and also have merged content filtering regexes from Amavis into it. That(regex) is the part I love about fail2ban, my fail2ban installation is on a CentOS 5.x box, rpm is available in rpmforge.
Gaurav
-
aly.khimji＠gmail.com -
David G. Miller -
David Sommerseth -
Devin Reade -
Gaurav Ghimire -
henry ritzlmayr -
Jason Brown -
John Hodrien -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Marian Marinov -
Rainer Traut -
rrichard＠blythe.org -
Rudi Ahlers -
Tom Yates