Databases, Systems & Networks

If you run a wordpress blog these days, you are likely to experience brute force attacks where nefarious individuals attempt to break in to your website by quickly a list of userids and passwords against your wp-login.php.  Here’s how I automated detection and blocking of WordPress brute force login attacks.

Detecting a WordPress Brute Force Attack

One can typically detect a wordpress brute force attack by parsing through your webserver’s access_log file.  The access_log file records all of the access requests that a web server handles.  A brute force attack typically will have frequent and numerous attempts to the wp-login.php file as shown below:

Example:  In the access_log file below, we detect a brute force login attack on our WordPress blog.  We detected it by noticing frequent and constant requests to the wp-login.php file.

31.192.210.159 - - [11/Sep/2014:02:01:43 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:44 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:45 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:47 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:49 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:50 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:51 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:52 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:54 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:55 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"

Typically in an event like this, I lookup the IP address in the ARIN database as I showed in a previous article:  What Personal Information Can You Get From Your Web Server?  Frequently, I find that the address is from APAC or RIPE addresses.

Lire la suite…

1 – Le concept

L’attaque SynFlood est basée sur l’envoi massif de demande d’ouverture de session TCP. Les buts recherchés peuvent être :

• Le Buffer Overflow du process écoutant le port TCP de destination.
• La saturation du nombre d’ouverture de session TCP en cours.

2 – Le fonctionnement

2.1 – Schéma

2.2 – Envoi du SYN

Le fonctionnement est de générer une trame TCP de demande de synchronisation à destination de la cible. Cette demande de synchronisation SYN est la première étape d’une ouverture de session TCP. Voici le schéma de l’entête TCP avec ce fameux flag SYN basé sur 1 bit :

Les 5 autres flags doivent être positionnés à 0.

2.3 – Réception par la cible A

La cible recevant la synchronisation TCP mémorise cette demande nécessitant donc de la mémoire et du processeur. Voici l’état des connexions d’un Windows XP avant la réception d’un Synflood :

Et voici après la réception des demandes de SYN :

La cible passe les requêtes reçues en SYN_RECEIVED. Cet état est temporaire, le temps de durée de vie est variable en fonction de la pile IP.

Dans mon exemple, la cible tourne sur une station XP limitée en nombre de sessions simultanée. Ceci ayant pour conséquence l’indisponibilité temporaire du port ciblé.

* testé depuis la machine ayant effectuée le Synflood

Lire la suite…

There are many types of Distributed Denial of Service (DDOS) attacks that can affect and bring down a website, and they vary in complexity and size. The most well known attacks are the good old SYN-flood, followed by the Layer 3/4 UDP and DNS amplification attacks.

Today though, we’re going to spend a little time looking at Layer 7, or what we call an HTTP Flood Attack.

An HTTP flood attack is a type of Layer 7 application attack that utilizes the standard valid GET/POST requests used to fetch information, as in typical URL data retrievals (images, information, etc.) during SSL sessions. An HTTP GET/POST flood is a volumetric attack that does not use malformed packets, spoofing or reflection techniques. – DDoSAttacks.biz

If you’re wondering, yes, we deal with these every day, and we protect our client websites via our Website Firewall.

Today I’m going to share with you some details on a rather large DDoS attack that leveraged the following HTTP request flood attack to wreak havoc on a clients website. I’ll also share the steps we took to mitigate the issue.

Layer 7 DDoS – HTTP Flood Attacks

The first thing to understand about Layer 7 attacks is that they require more understanding about the website and how it operates. The attacker has to do some homework and create a specially crafted attack to achieve their goal. Because of this, these types of DDoS attacks require less bandwidth to take the site down and are harder to detect and block.

Layer 7 DDoS – Part 1: Random URLs

This specific client came to us after his site was down for almost a week. They tried other services to protect their website with not much luck. As soon as he switched his DNS to us, we gained a much deeper appreciation and started to see why.

He was getting thousands of requests like these every second:

75.118.29.205 - - [20/Jan/2014:19:32:06 -0500] "GET /?458739416183768700 HTTP/1.1" 200 440 "http://movies.netflix.com/WiPlayer?movieid=70136122&trkid=7882978&t=Weeds" ""
173.245.56.201 - - [20/Jan/2014:19:32:06 -0500] "GET /?458726993617499500 HTTP/1.1" 200 440 "http://landing.pcwhatsap.com/1/?offer_id=3534&aff=1788&url_id=5618&sub_id=whatsapp_pop" ""
79.19.41.22 - - [20/Jan/2014:19:32:06 -0500] "GET /?458741338856272200 HTTP/1.1" 200 440 "http://www.rumoreweb.it/index.php?option=com_news_portal&view=category&id=21&Itemid=259" ""
190.121.64.3 - - [20/Jan/2014:19:32:06 -0500] "GET /?458722169268652700 HTTP/1.1" 200 440 "http://www.eldivisadero.cl/noticias/?task=show&id=37352" ""
186.54.141.146 - - [20/Jan/2014:19:32:06 -0500] "GET /?458741274224646000 HTTP/1.1" 200 440 "http://badoo.com/01244944965/?r=37.4&p=1" ""

To be more exact, he was getting 5,233 HTTP requests every single second. From different IP addresses around the world.

What is important to note here is how this worked against the client’s platform. The client’s website was built on WordPress. The uniqueness of the requests were bypassing the caching system, forcing the system to render and respond to every request. This was bringing about system failures as the server quickly became overwhelmed by the requests.

For illustration purposes, here is a quick geographic distribution of the IP’s hitting the site. This is for 1 second in the attack. Yes, every second these IP’s were changing.

Stopping the DDoS: Once we identified the type of attack, blocking was easy enough. By default, they were not passing our anomaly check, causing the requests to get blocked at the firewall. One of the many anomalies we look for are valid user agents, and if you look carefully you see that the requests didn’t have one. Hopefully, you’ll also noticed that the referrers were dynamic and the packets were the same size, another very interesting signature. Needless to say, this triggered one of our rules, and within minutes his site was back and the attack blocked.

Lire la suite…

Source: defendagainstddos.wordpress.com

On the 25th of January one of my sites was struggling to stay up, my “Dos Deflate” emails were popping into my inbox at a great frequency.

A quick run of the following command:

netstat -tn 2>/dev/null | grep :80 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr | awk ‘{print $2}’

Gave me a list of addresses connected to the site. The number of addresses was way way above the number normally connected to the site.  A site which although modestly doing 100,000s of page views per day will normally have only 300-500 port 80 connections at any one instance.  This time however we had a 2 or 3 thousand.

A quick copy and paste into the following tool http://software77.net/geo-ip/multi-lookup/ (max 2000 ips per lookup) which is very usefully for bulk ip address to location lookups, yielded the following

1.26.199.253 # CN China
 1.81.157.62 # CN China
 1.83.168.34 # CN China
 1.180.57.96 # CN China
 1.26.201.167 # CN China
 1.62.140.66 # CN China
 1.189.82.78 # CN China
 1.193.76.146 # CN China
 1.26.241.209 # CN China
 1.190.209.36 # CN China
 1.189.162.213 # CN China
 1.31.57.105 # CN China
 1.62.17.196 # CN China
 1.58.137.111 # CN China
 1.83.229.4 # CN China
 1.180.10.45 # CN China
 1.180.5.200 # CN China
 1.26.169.201 # CN China
 1.180.187.10 # CN China
 1.190.2.102 # CN China
 1.25.134.125 # CN China
 1.62.161.233 # CN China
 1.182.28.181 # CN China
 (And on and on)

We clearly had an issue with China, but a quick log in to Google Analytics indicated almost no real-time traffic visiting the site.

Due to the sheer volume of connections for the next 45 mins, I was regularly running this command pasting into excel, then bulk iptabling the the ip address as well as the 65,000 neighbouring addresses.

sudo iptables -A INPUT -s 59.56.0.0/16 -m comment –comment “China IP” -j DROP
sudo iptables -A INPUT -s 1.26.0.0/16 -m comment –comment “China IP” -j DROP

etc etc.

Lire la suite…

Stopping a DDOS (distributed denial of service attack) or DOS (denial of service attack) is no simple task.  Frequently, these attacks become more than just a nuisance, they completely immobilize your server’s services and keep your users from using your website.

We’ve found a few common sense ways to help ease the pain of DDOS and/or DOS attacks.  While no method is fool proof, we certainly can minimize the profound effect these attacks have on your users and subsystems.

Identify the Source

Good luck with that one.  Many DDOS and DOS attacks are from roaming IP addresses.  A distributed denial of service attack can come from many different IP addresses and it quickly becomes impossible for the Linux system administrator to isolate and confine each IP with a firewall rule.

Wikipedia does a great job of describing the various types of attacks here: http://en.wikipedia.org/wiki/Denial-of-service_attack.  For the purpose of this tutorial, I’ll leave the research on the types of attacks up to you, and address the most common form that we’ve encountered over the years, the Apache directed DDOS or DOS attack.

Apache Based Attacks

Symptoms of the Apache DDOS or DOS attack:

• Website(s) serve slow
• You notice hanging processes
• Apache Top tells you that the same IP address is requesting a system resource
• The system resource continues to multiplex, causing more processes to spawn
• The Command:

  netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

• Says that you have a few too many connections to feel comfortable with.

The end result:

• Apache goes down
• System load goes sky high
• Server stops responding
• You cant ssh to the server node
• You’ve lost connectivity completely and a reboot is mandatory in order to restore access to the system

Preventative Measures and Counter Measures:

• Enable SYN COOKIES at the kernel level

  echo 1 > /proc/sys/net/ipv4/tcp_syncookies

• Enable and Configure iptables to prevent the attack or at least work to identify the attack

  /sbin/iptables -N syn-flood
  /sbin/iptables -A syn-flood -m limit --limit 100/second --limit-burst 150 -j RETURN
  /sbin/iptables -A syn-flood -j LOG --log-prefix "SYN flood: "
  /sbin/iptables -A syn-flood -j DROP

• Install the APF firewall to work to identify risky behavior
  • APF stands for Advanced Policy Firewall.  Its a rock solid firewall that normally plays nice with iptables.  You can grab a the most recent copy here: http://www.rfxn.com/projects/
• Install (D)DosDeflate
  • Great software, rock solid, and plays nice with either APF or iptables.  Install and configure the service in seconds using the commands below.  Edit the .conf file to utilize whichever flavor of firewall you’d like to integrate it with.  Set a few configuration settings and you’re done.
  • To Install (D)DosDeflate:

    wget http://www.inetbase.com/scripts/ddos/install.sh
    chmod 0700 install.sh
    ./install.sh

• If it doesnt workout, its simple to uninstall too.  To uninstall:

  wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
  chmod 0700 uninstall.ddos
  ./uninstall.ddos

So a few tools are outlined above.  We’ve found that this will stop 90% of the attacks that are out there.  Some nice firewall rules above your server (at the router or switch level) also help.  Most of the time we can identify suspicious traffic before it even hits your servers, so a shameless plug here is probably in order.

Source: Liquid Communications