[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] Detecting Brute-Force and Dictionaryattacks



Excellent!  Thanks Wilson.  I've implemented your blacklist approach and
will monitor logs to verify success.  Really appreciate this as the attacks
were incessant.

Dave Benham

----- Original Message ----- 
From: "Wilson Mattos" <WMattos@xxxxxxxxxx>
To: <suse-security@xxxxxxxx>; <dcb@xxxxxxxxxxx>
Sent: Wednesday, November 01, 2006 2:58 AM
Subject: Re: [suse-security] Detecting Brute-Force and Dictionaryattacks


> David,
>
> You can definitely accomplish what you want with iptables.  You have the
right concept on how to do it, but your rules are not quite right.
>
> Try this (and make sure that if you have other rules that these show up
first, otherwise other rules you might have in the INPUT chain might be
allowing the packets and iptables never gets to these rules):
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --set --name SSH
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --rcheck --seconds 60 --hitcount 4 --name SSH --rsource -j
LOG --log-prefix "SSH_brute_force "
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --rcheck --seconds 60 --hitcount 4 --name SSH -j DROP
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
>
>
> Explanation of the above:
>
> The first rule in the chain will create the entry for the conneciton
attempt in the recent connections table named SSH.  Note that all it does is
add this entry.  It does NOT jump to the ACCEPT target.  If it did, the
other rules would not be processed...which is what was happening in the
example you sent.
>
> The second rule generates the log entry if 4 or more connection attempts
are made within 60 seconds.  Entries in /var/log/messages will have the
prefix "SSH_brute_force " as you described in your example.
>
> The third rule drops any packets coming from a host that has attempted 4
or more SSH connections within the last 60 seconds.
>
> The last rule will allow the connection attempt and does not need to check
the recent table because this rule will only be evaluated if the packet has
not been dropped yet from the rule above.
>
> The approach above only sort of works.  When I tested on my system, the
ssh client kept retrying the connection for a while and extending the amount
of time between connection attempts, so that eventually there were less than
4 packets within 60 seconds and I was able to attempt a login.  Increasing
the time it takes to 90 seconds did the trick because my ssh client gave up
before there were less than 4 attempts within 90 seconds, however, if I
change the settings on my ssh client to retry for longer, or even wait
longer between retries, then this will circumvent the rules.  Another
approach would be to build another recent connections table that black lists
the attackers (rather then checking for time and number of hits, it just
checks for that entry in the table).  Here is how that complete rule set
would look like:
>
> iptables -N SSHATTACKCHAIN
> iptables -A SSHATTACKCHAIN -m recent --name SSHATTACKER --set
> iptables -A SSHATTACKCHAIN -j LOG --log-prefix "SSH_brute_force "
> iptables -A SSHATTACKCHAIN -j DROP
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --rcheck --name SSHATTACKER -j LOG --log-prefix "SSH_Blacklisted_Host
"
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --rcheck --name SSHATTACKER -j DROP
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --set --name SSH
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --rcheck --seconds 10 --hitcount 4 --name SSH -j SSHATTACKCHAIN
>
> iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
>
>
> The above example builds a separate chain to deal with attempts from hosts
that attempted 4 or more SSH connections within 60 seconds.  The  adds the
host to a black list table (SSHATTACKER), then log what you want, and
finally drops the packet.
>
> Note that in this example, the command evaluation actually starts from the
5th iptables command shown above.
>
> First we check to see if the host is blacklisted already, and if so, we
log the connection attempt with a slight different log prefix (it could be
the same if you wanted) and finally we drop the packet.  If not on the black
list, we continue processing the rules.  We log  the connection attempt in
the recent table SSH, then we check to see if there were 4 or more
connection attempts within the last 60 seconds.  If there were, then we go
through and process the rules in the SSHATTACKCHAIN (commands 2-4 above).
Otherwise, if there were less than 4 connection attempts within the last 60
seconds, we accept the packet.
>
> Note that the host will be blacklisted for as long as the server is
running and iptables has not been flushed.  Which means that the host will
not be able to ssh to your server period, no matter how much time goes by.
This could cause a problem for a host that is coming from a NATed network
since all the hosts on that network (the public NAT address) would now be
essentially black listed.  Might be interesting then to add another rule to
remove a host from the blacklist table if there were no connection attempts
made within a specific period of time, say 30 minutes (use --remove, rather
than --set along with the recent module).  Other options would be to not
only block ssh, but all network traffic from a blacklisted host, but again
there are implications to doing this.
>
> If you want additional information or have more questions, please feel
free to ask.
>
> Wil
>
> Wilson Mattos
> Technology Specialist
>
>
> SUSE® Linux Enterprise 10
> Your Linux is ready*
> www.novell.com/linux
>
>
>
> >>> "David C. Benham" <dcb@xxxxxxxxxxx> 10/31/2006 12:51 PM >>>
> If ssh is set to log, the attack will be very obvious. A quick cat
> /var/log/message | grep "ssh" will make it very clear, although you will
> need more going forward.
>
> I'm getting killed by attacks that are virtually running all day long now.
> My QUESTION:  why doesn't the following iptables approach work?
>
> ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
> state NEW recent: SET name: SSH side: source
>
> LOG        tcp  --  anywhere             anywhere            tcp dpt:ssh
> recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source
> LOG level warning prefix `SSH_brute_force '
>
> DROP       tcp  --  anywhere             anywhere            tcp dpt:ssh
> recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source
>
> Sorry for the formatting, it's really just 3 commands and iptables should
> drop packets from the offending attacker, but it does not.  I want an
> iptables solution to this.
>
> > Hi,
> >
> > You can start by checking the log files.
> > I do not know if this can help but in my particular
> > case I installed python and I run Denyhosts as a
> > deamon , and that authomates the tasks of detecting
> > and preventing attacks.
> > DenyHost checks the log files and if there is an
> > attempt to brute force it place a line is
> > /etc/hosts.deny.
> > So some services running under tcpwrap can be very
> > simply "controlled" in this manner.
> > Also of great importance is to use in the sshd config
> > the directives AllowUsers and DenyUsers.
> > The "usual" targets are the very known system users
> > like wwwrun, tomcat, root and so on.
> > Those should be prevented from a external log in.
> > But of course your solution depends a bit on what is
> > the purpose of that precise brute force monitoring ...
> > and exact service you are monitoring ...
> >
> > Regards,
> > Pedro Coelho
> >
> > --- Shashi Kanth Boddula <shashi.boddula@xxxxxxxxxx>
> > wrote:
> >
> >> Hi All,
> >>
> >> I am looking for a good tool to detect brute-force
> >> and dictionary attacks on user accounts on a Linux
> >> system . The tool should also have the intelligence
> >> to differntiate between user mistakes and actual
> >> brute-force/dictionary attacks and reduce the false
> >> positives. SLES9/SLES10 included security tools are
> >> not helping in this case . The seccheck package
> >> functionality also not matching with my requirement.
> >>
> >>
> >> Please , anyone knows any third party security tool
> >> or any opensource security  tool which solves my
> >> problem ?
> >>
> >>
> >> Thanks & Regards,
> >> Shashi Kanth,CISSP
> >>
> >>
> >> --
> >> Check the headers for your unsubscription address
> >> For additional commands, e-mail:
> >> suse-security-help@xxxxxxxx
> >> Security-related bug reports go to security@xxxxxxx,
> >> not here
> >>
> >>
> >
> >
> > --
> > Check the headers for your unsubscription address
> > For additional commands, e-mail: suse-security-help@xxxxxxxx
> > Security-related bug reports go to security@xxxxxxx, not here
> >
>
>
> -- 
> Check the headers for your unsubscription address
> For additional commands, e-mail: suse-security-help@xxxxxxxx
> Security-related bug reports go to security@xxxxxxx, not here
>
>


-- 
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here