SCIENTIFIC-LINUX-USERS Archives

October 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Miles O'Neal <[log in to unmask]>
Reply To:
Miles O'Neal <[log in to unmask]>
Date:
Wed, 1 Oct 2008 22:44:01 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (22 lines)
|> Harry Enke wrote:
...
|> Is this in error?
|> "Fail2ban scans log files like /var/log/pwdfail or 
|> /var/log/apache/error_log and bans IP that makes too many password 
|> failures. It updates firewall rules to reject the IP address."
|> 
|> Examining logs after the event does not provide real-time protection.

I haven't looked at this tool, but sshblack scans the logs
*as they are written* to monitor for likely attackers and
updates the rules as the attacks begin.  You can set the
threshold in terms of number of tries over some period of
time that triggers a rule to block an apparent attacker.
You can be aggressive or easy-going as you like.  The result
is that a brute force attack must be so ponderously slow
as to be useless unless they just get ridiculously lucky
or you used a ridiculously simple to guess password.

I'd think this is what they mean.  It's real time monitoring
with real time blocking.

ATOM RSS1 RSS2