How to verify DDOS attack with netstat command

Denial-of-service attack (DoS attack) or Distributed Denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users. This attack generally target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even root nameservers. DoS attacks are implemented by either forcing the targeted computer to reset, or consuming its resources so that it can no longer provide its services or obstructs the communication media between the users and the victim so that they can no longer communicate adequately.

This blog provides you an overview on how to identify DDOS attack using netstat command.

#netstat -na

Display all active Internet connections to the server and only established connections are included.

#netstat -an | grep :80 | sort

Show only active Internet connections to the server on port 80 and sort the results. Useful in detecting a single flood by allowing you to recognize many connections coming from one IP.

#netstat -n -p|grep SYN_REC | wc -l

To find out how many active SYNC_REC are occurring on the server. The number should be pretty low, preferably less than 5. On DoS attack incidents or mail bombs, the number can jump to pretty high. However, the value always depends on system, so a high value may be average on another server.

#netstat -n -p | grep SYN_REC | sort -u

List all IP addresses involved.

#netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’

List all the unique IP addresses of the nodes that are sending SYN_REC connection status.

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

Use netstat command to calculate and count the number of connections each IP address makes to the server.

#netstat -anp |grep ‘tcp\|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n

List the number of connections the IPs are making to the server using TCP or UDP protocol.

#netstat -ntu | grep ESTAB | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr

Check on ESTABLISHED connections instead of all connections, and display the number of connections for each IP.

#netstat -plan|grep :80|awk {‘print $5′}|cut -d: -f 1|sort|uniq -c|sort -nk 1

Show a list IP addresses and its number of connections that are connecting to port 80 on the server. Port 80 is used mainly by the HTTP protocol.

SYN flood attack mitigation

Problem

Someone’s server is victim of a SYN flood attack and as a result, their web service(s) are not functional.

1) Verify that SYN cookies are enabled. To check and see if SYN cookies are enabled in the kernel’s TCP stack:

cat /proc/sys/net/ipv4/tcp_syncookies

If it returns 0, they are not enabled.
To enable them, simply run

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

If cat /proc/sys/net/ipv4/tcp_syncookies returns 1, they are enabled and you can proceed.

2) The next issue is caused by the SYN backlog not being proportionate to the application (most often Apache’s) max connections. As a result, the application in question basically chokes.

To correct this:
1) Stop CSF

/etc/init.d/csf stop
2) Flush IPTables

iptables -F
/etc/init.d/iptables stop
3) Clear unneeded kernel modules

modprobe -r ip_conntrack  (You may have to remove multiple dependencies first)

We now need to modify the amount of connections permitted by Apache, in order to figure this out, see the below.

1) Run the below

sysctl -a | grep syn.

This will return he data you want, particularly the string
“net.ipv4.tcp_max_syn_backlog = 1024” Based on that, 1024 is our base

Let’s apply the necessary changes based on the below exmaple.

netstat -na | grep :80 | wc -l
954
netstat -na | grep SYN | wc -l
465
This tells us the amount of established connections to port 80 and the amount of incoming SYN request, SYN_REC, and so on.

As you can see, the combined amount of these 2 numbers is greater than the syn_backlog we saw previously. Due to the fact that all connections (relatively speaking) in this scenario mustsend a SYN packet to the server, out precious server is choking.

We can work around this by increasing the syn backlog

954 + 465 = 1419

1) Edit /etc/httpd/conf/httpd.conf and set the MaxClients directive to something significantly larger than this number, say 4,000 during this hypothetical attack. Restart Apache with stop/start for the changes to take effect

/etc/init.d/httpd stop
/etc/init.d/httpd start
2) Increase the syn_backlog to play nicely with the changes we made to Apache

sysctl -w net.ipv4.tcp_max_syn_backlog=2048

==========
Also, run this to block all SYN_FLOOD :

while true;
do netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq;
netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq < /tmp/ips.txt; for IP in ‘cat /tmp/ips.txt’;
do iptables -A INPUT -s $IP -j DROP;
done;
/sbin/service iptables save;
sleep 30;
done;
==========

That’s all. Sit back, Relax.

Automatically block connections to a server through csf

This script can be used with csf to block connections on a server automatically if a client is getting really flooded. To use this you must change /etc/csf/csf.conf’s deny limit from 100 to 0 and restart csf and load this script up.

========<<<>>>=======
#!/bin/bash

netstat -anp |grep ‘:80’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n > ~/curr
while read list
do
conns=`echo $list | awk ‘{print $1}’`
ip=`echo $list | awk ‘{print $2}’`
if [ “$conns” -ge 20 ]
then
exist=`cat /etc/csf/csf.deny | grep $ip`
if [ “$ip” != “$exist” ]
then
echo blocking $ip with $conns connections
iptables -I INPUT -s $ip -j DROP
echo $ip >> /etc/csf/csf.deny
blocked=`echo yes`
fi
blocked=`echo yes`
fi
done < ~/curr

if [ $blocked == “yes” ]
then
/etc/init.d/httpd stop
pkill httpd
/etc/init.d/httpd start
fi
=======<<<>>>=======

put in ~ on server add to crontab as so:

*/1 * * * * /root/autoblock.sh >> /var/log/autoblock

and change the 20 next to -ge to whatever threshold you would like on port 80

How to null-route IP addresses via Routing Table ?

Fix :

To block a single IP :

ip route add blackhole XX.XX.XX.XX

To block a network range :

ip route add blackhole XX.XX.XX.XX/16

To remove the block :

ip route del XX.XX.XX.XX
ip route del XX.XX.XX.XX/16
======================

Introducing blockwplogin.sh -A bash script that find and block wordpress attack.

Save the below given bash script in a sh file like blockwplogin.sh and exexute the same from the shell. The script will find and block only attacking Ip’s.

vi blockwplogin.sh and add the below script
Chmod 755 blockwplogin.sh
Execute it

./ blockwplogin.sh

Sit back, relax 🙂

========<<>>=========

#!/bin/bash
#

# Save all requests to any wp-login.php file on the server, to a temporary log

#grep -R “wp-login” /usr/local/apache/domlogs/* > /tmp/wplogins.txt
egrep -R “wp-login|wp-includes\/css” /usr/local/apache/domlogs/* > /tmp/wplogins.txt

# Find IP addresses which sent a POST request to any wp-login.php file

for i in `tac /tmp/wplogins.txt | grep POST | awk -F: ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq`;
do
results=0
exists=0

# Check if this IP address sent a request for CSS files

results=`cat /tmp/wplogins.txt | grep “$i” | grep css | awk -F: ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq | wc -l`

# If not, it is an attacking IP. Add it to a deny rule in /home/.htaccess (if not already exists there)

if test $results -lt 1
then
csf -d $i
fi
done

=========<<>>=========

Check and block wordpress and xmlrc attack on a cPanel server

If you are seeing a lot of access to wp-login.php , you can conclude it as a wordpress attack. The below script will show you the sorted list of accessing ip’s to wp-login

《《《》》》
egrep ‘wp-login.php’ /usr/local/apache/domlogs/* | grep -v ftp_log | awk -F : ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq -c | sort -n
《《《》》》

The result will be shown as below:

2545 69.56.xx.xx

Here the first parameter is the number of hits and second one is the .You can block these ip on firewall to get rid of this.

Also, you can use the below command to get the result for a particular date.

《《《》》》
grep wp-login.php /usr/local/apache/domlogs/* grep “16/Jan/2013:03″|awk ‘{print $1}’ | cut -d: -f2 | sort | uniq -c |sort -n | tail
《《《》》》

If the problem occurs continously,
drop all wordpress login through port 80
————

whille allowing the wp-login again ,please remove this rule

iptables -I INPUT -p tcp –dport 80 -m string –string “wp-login.php” –algo bm -j DROP

If its a xmlrpc.php attack,just replace wp-login.php with xmlrc.php for all the commands like below.

iptables -I INPUT -p tcp –dport 80 -m string –string “xmlrpc.php” –algo bm -j DROPThats all.. 🙂

Too many connections in TIME_WAIT state

Too many connections in TIME_WAIT state:

If you seeing a lot of connections in  TIME_WAIT state then each socket in TIME_WAIT consumes some memory in the kernel, usually somewhat less than an ESTABLISHED socket. But it may increase the load in server.

For solving this you need to do the following on the server,

Login to the server via SSH

Then enter the following command, it will append the values for timeout in the server,

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
Also you need to edit the file,

/etc/sysctl.conf
and add the timeout and recycle values in it.

vi /etc/sysctl.conf
And add the following values to the file

net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_tw_recycle = 1
Now it will be Ok.

Live DDOS MAP

http://www.digitalattackmap.com/#anim=1&color=0&country=ALL&time=15999&view=map

http://projectshield.withgoogle.com/about/