If you are a system administrator of a linux system, you may find the following log entries familiar:
Sep 15 02:00:30 sol sshd[16364]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53382 ssh2
Sep 15 02:00:30 sol sshd[16365]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53394 ssh2
Sep 15 02:00:30 sol sshd[16366]: Failed password for invalid user test from ::ffff:61.167.x.x port 53396 ssh2
Sep 15 02:00:28 sol sshd[16366]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16370]: Invalid user test from ::ffff:61.167.x.x

Many, many times over. These are caused by an brute force attack from the remote host. Most likely this is another compromised machine, checking your machine for easy to guess username and password combinations. It could be someone manually trying to run a password cracking program on your ssh server too. In either case, the remote system really has no business touching your machine. This situation needs an automated solution to block this IP from even getting to your machine. Doing this real-time is essential as well.

Enter the Free APF + BFD scripts from R-fx Networks. These programs work in conjunction with one another to monitor for brute password attempts on your system, then ban the attacking host.

First install the APF (Advanced Policy Firewall) script [Download]

Then install the BFD (Brude Force Detection) script [Download]

When it finds a host that has tried and failed to log in too many times, or has tried too many users who don’t exist on your system, it blocks them in your firewall and e-mails you a message:

The remote system 61.167.x.x was found to have exceeded acceptable login
failures on somehost.com; there was 63 events to the service sshd. As such the
attacking host has been banned from further accessing this system. For the integrity
of your host you should investigate this event as soon as possible.

Executed ban command:
/etc/apf/apf -d 61.167.x.x {bfd.sshd}

The following are event logs from 61.167.x.x on service sshd (all time stamps are GMT -0400):

Sep 15 02:00:27 sol sshd[16364]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:27 sol sshd[16365]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16366]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16370]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:30 sol sshd[16364]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53382 ssh2
Sep 15 02:00:30 sol sshd[16365]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53394 ssh2
Sep 15 02:00:30 sol sshd[16366]: Failed password for invalid user test from ::ffff:61.167.x.x port 53396 ssh2
Sep 15 02:00:31 sol sshd[16370]: Failed password for invalid user test from ::ffff:61.167.x.x port 53412 ssh2
Sep 15 02:00:31 sol sshd[16372]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:32 sol sshd[16373]: Invalid user test from ::ffff: 61.167.x.x

In my experience it works great and is a very easy to install!

12 comments
  1. DenyHosts works to block services using TCP Wrappers, such as SSH and FTP however services like Apache which do not use TCPWrappers would still allow that host to connect. Assuming that any IP performing brute force attacks on your system is malicious (I think that is safe to assume) – I would much rather block them from using all services rather than just services using TCP Wrappers. A Brute force attack may be an indication that someone is trying to find a way into your system, so in my opinion it is better to block them via Firewall (iptables) rather than TCP Wrappers.

  2. DenyHosts works to block services using TCP Wrappers, such as SSH and FTP however services like Apache which do not use TCPWrappers would still allow that host to connect. Assuming that any IP performing brute force attacks on your system is malicious (I think that is safe to assume) – I would much rather block them from using all services rather than just services using TCP Wrappers. A Brute force attack may be an indication that someone is trying to find a way into your system, so in my opinion it is better to block them via Firewall (iptables) rather than TCP Wrappers.

  3. OK. How about the following as another viable alternative:
    +—————————+
    /usr/bin/swatch –config-file=/etc/swatchrc –tail-file=/var/log/messages
    –awk-field-syntax –tail-args “-F” &
    +—————————+
    watchfor /Authentication failed for user/
    exec “/usr/local/sbin/lockout $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15″
    +—————————+
    #! /bin/bash
    #
    IP=`echo $* | awk ‘/Authentication failed/{sub(/(?@/,””);print $6}’ | sed ‘s/)//g’`
    ATTEMPTS=`grep $IP /var/log/messages | grep “Authentication failed for user” | wc -l`

    if [ $ATTEMPTS -gt 2 ]
    then
    route add $IP lo
    MINUTES=`expr $ATTEMPTS – 2`
    echo “route del $IP lo 2> /dev/null” | at now +$MINUTES minutes 2>&1 > /tmp/.pure-lockout.$$
    (hostname ; echo $* ; echo “IP=$IP” ; echo “ATTEMPTS=$ATTEMPTS” ;
    echo “Blocking for $MINUTES minutes” ;
    cat /tmp/.pure-lockout.$$ ) | Mail -s “Lockout”
    admin@example.com
    fi

    rm -f /tmp/.lockout.$$

  4. OK. How about the following as another viable alternative:
    +—————————+
    /usr/bin/swatch –config-file=/etc/swatchrc –tail-file=/var/log/messages \
    –awk-field-syntax –tail-args “-F” &
    +—————————+
    watchfor /Authentication failed for user/
    exec “/usr/local/sbin/lockout $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15″
    +—————————+
    #! /bin/bash
    #
    IP=`echo $* | awk ‘/Authentication failed/{sub(/\(\?@/,””);print $6}’ | sed ‘s/)//g’`
    ATTEMPTS=`grep $IP /var/log/messages | grep “Authentication failed for user” | wc -l`

    if [ $ATTEMPTS -gt 2 ]
    then
    route add $IP lo
    MINUTES=`expr $ATTEMPTS – 2`
    echo “route del $IP lo 2> /dev/null” | at now +$MINUTES minutes 2>&1 > /tmp/.pure-lockout.$$
    (hostname ; echo $* ; echo “IP=$IP” ; echo “ATTEMPTS=$ATTEMPTS” ; \
    echo “Blocking for $MINUTES minutes” ; \
    cat /tmp/.pure-lockout.$$ ) | Mail -s “Lockout”
    admin@example.com
    fi

    rm -f /tmp/.lockout.$$

  5. sudo iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH
    sudo iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 8 –rttl –name SSH -j DROP

    and off he goes :)

  6. sudo iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH
    sudo iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 8 –rttl –name SSH -j DROP

    and off he goes :)

Comments are closed.

You May Also Like

Tweaking TCP for Fast (100mbps+) Connections and Transfers on Linux

We recently did some speed testing on a few of the servers on our network, and we were not receiving the speeds expected considering they were sitting on a physical 100mbps ethernet port. The servers were indeed on physical 100mbps connection, however wget (TCP/IP, HTTP Port 80) download tests showed only a max of about 1.5MB/sec (note the 8bit/byte conversion, so this translates to about 12mbits).

Awesome article on using the VI Text Editor

Awesome article on using vi/vim: Do whatever you want. Don’t learn it…

Fixing ip_conntrack Bottlenecks: The Tale Of The DNS Server With Many Tiny Connections

I manage a server which has a sole purpose: serving DNS requests. We use PowerDNS, which has been great. It is a DNS server whose backend is SQL, making administration of large numbers of records very easy. It is also fast, easy to use, open source and did I mention it is free? The server has been humming along for years now. The traffic graphs don’t show a lot of data moving through it because it only serves DNS requests (plus MySQL replication) in the form of tiny UDP packets. Read on to follow my story of how I fixed this tricky problem. No kittens were harmed in the writing of this post.

Apache’s mod_proxy with Exchange’s Outlook Web Access

Apache’s mod_proxy module is simply one of the best Apache modules out…