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:
Mark Stodola <[log in to unmask]>
Reply To:
Mark Stodola <[log in to unmask]>
Date:
Thu, 2 Oct 2008 00:01:10 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
Sorry I haven't been following this whole thing, but I caught the last 
few.  As far as a real-time solution, I use iptables.  It doesn't care 
if a login failed or succeeded, it just counts the rate of connection.  
You can play with it a bit, depending on how many users hit your machine 
and how often.  It is on a per-host basis, so 3 people from 3 different 
machines won't trip it, however 3 connections from a single machine in 
less than a minute will.  Easily tweaked using lines 2 and 3.  This 
stops all of those automated brute-force attack for me, and I haven't 
locked myself out (yet).

My sample script:

#
# SSH FLOOD PROTECTION
#

# create our new limiting chain where we can send everything to be limited.
${IPTABLES} -N mylimit

# demand XX seconds of silence from a host that has been flagged as flooding.
${IPTABLES} -A mylimit -m recent --update --seconds 604800 -j DROP

# if the host is not flagged for flooding, and has not started to flood in the last minute,
# bounce their connection back where it came from for further rule matching.
${IPTABLES} -A mylimit -m limit --limit 2/m --limit-burst 3 -j RETURN

# They have started to flood, drop their connection and flag them.
${IPTABLES} -A mylimit -m recent --set -j DROP

# shunt NEW ssh connections over to MyLimit to be limited
${IPTABLES} -A INPUT -i ${EXTIF} -p tcp --dport ssh -m state --state NEW -j mylimit

Cheers,
Mark

Michael Mansour wrote:
> Hi,
>
>   
>> Harry Enke wrote:
>>     
>>> Hi,
>>> there is an easy configurable tool for preventing brute force attacks, 
>>> it's called "fail2ban". It sifts through logs for attacks on security 
>>> critical ports and blocks login attempts from ip-addresses which fail 
>>> too often in too short a timeframe (configurable).
>>>
>>> http://www.fail2ban.org
>>>       
>
> I've personally been using:
>
> http://www.aczoom.com/cms/blockhosts
>
> for years now for customers that need ports open to the public internet (ftp,
> ssh, etc). BlockHosts can work with various services out-of-the-box and
> handles hosts.allow/deny files and/or iptables rules. It also has web
> interfaces to display blocked lists and GeoIP maps if you want them.
>
>   
>> 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'm not after real-time, the above is good enough for me but I'm interested in
> your comment. Is there a better software solution out there?
>
> Michael.
>
>   

ATOM RSS1 RSS2