Articles taggués ‘DDoS’

Testing firewall rules with Hping3 – examples

30/08/2020 Comments off

1. Testing ICMP:

In this example hping3 will behave like a normal ping utility, sending ICMP-echo und receiving ICMP-reply

hping3 -1

2. Traceroute using ICMP:

This example is similar to famous utilities like tracert (Windows) or traceroute (Linux) who uses ICMP packets increasing every time in 1 its TTL value.

hping3 --traceroute -V -1

3. Checking port:

Here hping3 will send a SYN packet to a specified port (80 in our example). We can control also from which local port will start the scan (5050).

hping3 -V -S -p 80 -s 5050

Lire la suite…

Categories: Réseau, Sécurité Tags: , , ,

TCP SYN flood DOS attack with hping3

27/08/2020 Comments off


Wikipedia defines hping as :

hping is a free packet generator and analyzer for the TCP/IP protocol distributed by Salvatore Sanfilippo (also known as Antirez). Hping is one of the de facto tools for security auditing and testing of firewalls and networks, and was used to exploit the idle scan scanning technique (also invented by the hping author), and now implemented in the Nmap Security Scanner. The new version of hping, hping3, is scriptable using the Tcl language and implements an engine for string based, human readable description of TCP/IP packets, so that the programmer can write scripts related to low level TCP/IP packet manipulation and analysis in very short time.

On ubuntu hping can be installed from synaptic manager.

$ sudo apt-get install hping3

Syn flood

To send syn packets use the following command at terminal

$ sudo hping3 -i u1 -S -p 80

The above command would send TCP SYN packets to
sudo is necessary since the hping3 create raw packets for the task , for raw sockets/packets root privilege is necessary on Linux.

S – indicates SYN flag
p 80 – Target port 80
i u1 – Wait for 1 micro second between each packet

More options

Lire la suite…

Linux Iptables Limit the number of incoming tcp connection / syn-flood attacks

23/08/2020 Comments off

A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target’s system. This is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a SYN, but before it has received the ACK.

if Half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. Syn flood is common attack and it can be block with following iptables rules:

iptables -A INPUT -p tcp –syn -m limit –limit 1/s –limit-burst 3 -j RETURN

All incoming connection are allowed till limit is reached:

  • –limit 1/s: Maximum average matching rate in seconds
  • –limit-burst 3: Maximum initial number of packets to match

Open our iptables script, add the rules as follows:

# Limit the number of incoming tcp connections
# Interface 0 incoming syn-flood protection
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
#Limiting the incoming icmp ping request:
iptables -A INPUT -p icmp -m limit --limit  1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP:
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j ACCEPT

First rule will accept ping connections to 1 per second, with an initial burst of 1. If this level crossed it will log the packet with PING-DROP in /var/log/message file. Third rule will drop packet if it tries to cross this limit. Fourth and final rule will allow you to use the continue established ping request of existing connection.

  • ‐‐limit rate: Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the default is 3/hour.
  • ‐‐limit‐burst number: Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5.

You need to adjust the –limit-rate and –limit-burst according to your network traffic and requirements.

Let us assume that you need to limit incoming connection to ssh server (port 22) no more than 10 connections in a 10 minute:

iptables -I INPUT -p tcp -s 0/0 -d $SERVER_IP --sport 513:65535 --dport 22 -m state --state NEW,ESTABLISHED -m recent --set -j ACCEPT
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 11 -j DROP
iptables -A OUTPUT -p tcp -s $SERVER_IP -d 0/0 --sport 22 --dport 513:65535 -m state --state ESTABLISHED -j ACCEPT
Categories: Réseau, Sécurité Tags: , ,

Mod_evasive : un module anti-DDoS pour Apache

16/08/2020 Comments off


Mod_evasive est un module Apache pour contrer les attaques DDoS. Celui-ci est par exemple capable de détecter lorsqu’un utilisateur demande un trop grand nombre de pages sur un site web, sur un délai de temps très court. Voici comment l’installer et le configurer pour une utilisation basique.
Lire la suite…

How to receive a million packets per second

01/04/2020 Comments off

receive million packetsLast week during a casual conversation I overheard a colleague saying: “The Linux network stack is slow! You can’t expect it to do more than 50 thousand packets per second per core!”

That got me thinking. While I agree that 50kpps per core is probably the limit for any practical application, what is the Linux networking stack capable of? Let’s rephrase that to make it more fun:

On Linux, how hard is it to write a program that receives 1 million UDP packets per second?

Hopefully, answering this question will be a good lesson about the design of a modern networking stack.

First, let us assume:

  • Measuring packets per second (pps) is much more interesting than measuring bytes per second (Bps). You can achieve high Bps by better pipelining and sending longer packets. Improving pps is much harder.
  • Since we’re interested in pps, our experiments will use short UDP messages. To be precise: 32 bytes of UDP payload. That means 74 bytes on the Ethernet layer.
  • For the experiments we will use two physical servers: “receiver” and “sender”.
  • They both have two six core 2GHz Xeon processors. With hyperthreading (HT) enabled that counts to 24 processors on each box. The boxes have a multi-queue 10G network card by Solarflare, with 11 receive queues configured. More on that later.
  • The source code of the test programs is available here: udpsender, udpreceiver.


Let’s use port 4321 for our UDP packets. Before we start we must ensure the traffic won’t be interfered with by the iptables:

receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT  
receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK  

A couple of explicitly defined IP addresses will later become handy:

receiver$ for i in `seq 1 20`; do   
              ip addr add 192.168.254.$i/24 dev eth2; 
sender$ ip addr add dev eth3  

1. The naive approach

To start let’s do the simplest experiment. How many packets will be delivered for a naive send and receive?

The sender pseudo code:

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  
fd.bind(("", 65400)) # select source port to reduce nondeterminism  
fd.connect(("", 4321))  
while True:  
    fd.sendmmsg(["x00" * 32] * 1024)

While we could have used the usual send syscall, it wouldn’t be efficient. Context switches to the kernel have a cost and it is be better to avoid it. Fortunately a handy syscall was recently added to Linux: sendmmsg. It allows us to send many packets in one go. Let’s do 1,024 packets at once.

The receiver pseudo code:

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  
fd.bind(("", 4321))  
while True:  
    packets = [None] * 1024
    fd.recvmmsg(packets, MSG_WAITFORONE)

Similarly, recvmmsg is a more efficient version of the common recv syscall.

Let’s try it out:

sender$ ./udpsender  
receiver$ ./udpreceiver1  
  0.352M pps  10.730MiB /  90.010Mb
  0.284M pps   8.655MiB /  72.603Mb
  0.262M pps   7.991MiB /  67.033Mb
  0.199M pps   6.081MiB /  51.013Mb
  0.195M pps   5.956MiB /  49.966Mb
  0.199M pps   6.060MiB /  50.836Mb
  0.200M pps   6.097MiB /  51.147Mb
  0.197M pps   6.021MiB /  50.509Mb

With the naive approach we can do between 197k and 350k pps. Not too bad. Unfortunately there is quite a bit of variability. It is caused by the kernel shuffling our programs between cores. Pinning the processes to CPUs will help:

sender$ taskset -c 1 ./udpsender  
receiver$ taskset -c 1 ./udpreceiver1  
  0.362M pps  11.058MiB /  92.760Mb
  0.374M pps  11.411MiB /  95.723Mb
  0.369M pps  11.252MiB /  94.389Mb
  0.370M pps  11.289MiB /  94.696Mb
  0.365M pps  11.152MiB /  93.552Mb
  0.360M pps  10.971MiB /  92.033Mb

Now, the kernel scheduler keeps the processes on the defined CPUs. This improves processor cache locality and makes the numbers more consistent, just what we wanted.

Lire la suite…