Sockstress Tools & Source Code
Sockstress is a Denial of Service attack on TCP services discovered in 2008 by Jack C. Louis from Outpost24. It works by using raw sockets to establish many TCP connections to a listening service. Because raw sockets are used, connections are established without having to save any per-connection state on the attacker's machine.
Like SYN flooding, sockstress is an asymmetric resource consumption attack: It requires very little resources (time, memory, and bandwidth) to run a sockstress attack, but uses a lot of resources on the victim's machine. Because of this asymmetry, a weak attacker (e.g. one bot behind a cable modem) can bring down a rather large web server.
Unlike SYN flooding, sockstress actually completes the TCP 3-way handshake, and is not thwarted by using SYN cookies. In the last packet of the three-way handshake a ZERO window size is advertised -- meaning that the client is unable to accept data -- forcing the victim to keep the connection alive and periodically probe the client to see if it can accept data yet.
This implementation of sockstress
takes the idea a little further
(actually, Outpost24's code does this too) by allowing the user to specify a
payload, which will be sent along with the last packet of the three-way
handshake, so in addition to opening a connection, the attacker can request
a webpage, perform a DNS lookup, send email to a SMTP server, or anything
else that can fit in one packet.
The rest of this page is about our implementation.
Our sockstress code has been tested on Debian Linux, using the GCC compiler.
# gcc -pthread -o sockstress sockstress.o
How do I use sockstress?
Sockstress uses raw sockets, so you must run the tool as root. You must also stop your OS from sending RST packets to the victim in response to unrecognized SYN/ACKs sent during the attack. To do so, set an iptables rule:
Where xx.xx.xx.xx is the victim's IP address.
To view the sockstress help menu, run:
SOCKSTRESS - CVE-2008-4609 | firstname.lastname@example.org
Usage: ./sockstress <ip>:<port> <interface> [-p payload] [-d delay]
<ip> Victim IP address
<port> Victim port
<interface> Local network interface (e.g. eth0)
-p payload File containing data to send after connecting
Payload can be at most 1000 bytes
-d delay Microseconds between SYN packets (default: 10000)
-h Help menu
**You must configure your firewall to drop TCP reset packets sent to <ip>**
To execute an attack, sockstress requires three parameters:
- Victim IP
- Victim port
- Network interface to send packets from (e.g. eth0)
For example, to run an attack on port 80 on 127.0.0.1, run:
Sockstress also allows the user to control the delay between sent SYN packets. This value is specified in microseconds with the -d option. For example, to send a SYN packet every second, run:
You can also have sockstress send some data to the victim after the connection has been established. Do this by specifying a file containing the data with the -p option. For example, to make HTTP requests:
... where payloads/http contains:
Example payloads for making DNS requests, requesting web pages, and sending mail with SMTP are provided with the source code.
To run a sockstress attack against multiple ports, you must run multiple instances of the tool. The attack can be amplified by assigning many IP addresses to a single machine and running an instance of the attack from each IP. This improves the attack because sockstress will quickly establish a connection from every source port, so more IP addresses are needed to open more connections (more sets of source ports).
How can I prevent sockstress attacks?
The only way to completely prevent sockstress attacks is to whitelist access to TCP services. This is not practical in most situations, so the best that can be done is to rate limit connections with iptables.
To block an IP after it opens more than 10 connections to port 80 within 30 seconds, install the following iptables rules:
# iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 30 --hitcount 10 -j DROP
Note that sockstress attacks are still possible even with these rules in place. The attacker just needs more IP addresses to mount a successful attack.
You're probably wondering what it looks like to be under attack by sockstress. The output of netstat -tn will look something like this:
tcp6 0 0 192.168.1.10:80 192.168.1.102:16022 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:26244 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:6786 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:1676 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:9440 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:22446 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:48356 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:21740 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:30341 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:62594 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:14492 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:31940 ESTABLISHED
tcp6 0 1 192.168.1.10:80 192.168.1.102:39136 FIN_WAIT1
tcp6 0 0 192.168.1.10:80 192.168.1.102:54779 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:59578 ESTABLISHED
tcp6 0 0 192.168.1.10:80 192.168.1.102:38544 ESTABLISHED
Is releasing this code ethical?
Sockstress code has existed in the wild since (at least) 2011:
- Sockstress Perl PoC created in 2011
- Outpost24's Sockstress Source uploaded to 2shared.com in 2011 (mirrored here for convenience)
Sockstress is still effective. However, any packet hacker could easily write a sockstress attack tool. For this reason, I feel it is best to release my sockstress tool so system administrators can test their systems and stronger defences can be developed.