[LINUX] Utiliser iptables pour se protéger des Denis de Service (portscan, flood, etc...) • Forum OXMO

soul^keeper

Rechercher tous les messages de ce membre

Cliquez ici pour envoyer un message privé à cet utilisateur

Administrateur

Connecté

Niveau : 5
N° de Membre : 1

Ancienneté : 100%

Participation : 19%

Inscription: 22 Feb 2002
Localisation: La Défense
Age: 48
Messages: 16621
Sujets Lancés : 2412

[LINUX] Utiliser iptables pour se protéger des Denis de Service (portscan, flood, etc...)

Je viens de trouver une méthode très élégante pour implémenter une protection contre le flood ou les scans au niveau d'iptables.

En fait, je viens de découvrir l'existence de ce module "ipt_recent" qui est tout simplement excellent !!

Il permet de se prémunir efficacement contre les Dénis de Services (DoS) en mémorisant dynamiquement l'activité de toutes les IP qui se connectent à votre système.

On peut alors logguer et dropper les abus simplement (ex: blacklister toute IP qui se connecte plus de <i>x</i> fois pendant un intervalle de temps donné sur un port ou autre...). Ce n'est biensûr qu'un exemple car les possibilités offertes sont infinies !

Je viens de refaire la majeure partie de la protection du serveur grâce à ce module !

Entre autre:
- ICMP flood
- Port scanners
- TCP SYN Flood

C'est hyper efficace, et ça a l'énorme avantage de gérer indépendamment chaque IP (ou bloc) !! Contrairement au module "ipt_limit" qui est excellent aussi mais qui fonctionne de manière globale...

Bref, voyez plutôt cet article :

Using iptables to rate-limit incoming connections
Posted by Steve in the Security section on Sun 17 Jul 2005 at 00:39

The iptables firewall has several useful extension modules which can be used to in addition to the basic firewall functionality. One of the more interesting of these extensions is the "recent" module which allows you to match recent connections, and perform simple throttling on incoming connections.

We've previously described keeping SSH access secure by limiting which users can connect, or just firewalling access so that only a small list of trusted IP addresses can connect. In most cases this is sufficient to protect your system.

However there are times when you have to allow arbitary incoming connections, when you are travelling for example.

In these situations you can open up your system to allow incoming connections and be the target of a dictionary attack - literally a machine trying to connect and login over and over again using usernames and passwords from a dictionary.

These attempts will be logged in your /var/log/auth.log file like this:

Citation:

sshd[x]: Illegal user admin from aa.bb.cc.dd
sshd[x]: Illegal user test from aa.bb.cc.dd
sshd[x]: Illegal user guest from aa.bb.cc.dd

In this situation you can create a collection of firewalling rules which will deny access from remote clients who attempt to connect "too many" times.

If you have an existing firewall in place, using iptables, then adding the rules is very straightforward.

The way the recent module works is fairly straightforward, you basically add IP addresses to a list, which can then be used in the future to test connection attempts against. This allows you to limit the number of connections against either a number of seconds, or connection attempts. In our example we'll do both.

An example is probably the simplest way to illustrate how it works. The following two rules will limit incoming connections to port 22 to no more than 3 attemps in a minute - an more than that will be dropped:

code:iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 -j DROP

The --state flag takes a comma seperated list of connection states as an argument, by using "--state NEW" as we did we make sure that only new connections are managed by the module.

The --set parameter in the first line will make sure that the IP address of the host which initiated the connection will be added to the "recent list", where it can be tested and used again in the future i.e. in our second rule.

The second rule is where the magic actually happens. The --update flag tests whether the IP address is in the list of recent connections, in our case each new connection on port 22 will be in the list because we used the --set flag to add it in the preceeding rule.

Once that's done the --seconds flag is used to make sure that the IP address is only going to match if the last connection was within the timeframe given. The --hitcount flag works in a similar way - matching only if the given count of connection attempts is greater than or equal to the number given.

Together the second line will DROP an incoming connection if:

The IP address which initiated the connection has previously been added to the list and
The IP address has sent a packet in the past 60 seconds and
The IP address has sent more than 4 packets in total.
You can adjust the numbers yourself to limit connections further, so the following example will drop incoming connections which make more than 2 connection attempts upon port 22 within ten minutes:

code:iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 600 --hitcount 2 -j DROP

If you wish to test these rules you can script a number of connection attempts from an external host with the netcat package.

The following script attempts to connect to the IP address 192.168.1.1 5 times. The first couple of attempts you should see a welcome banner such as "SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4" - after that the script will hang as it's packets are dropped and no response is sent:

code:#!/bin/bash

for i in `seq 1 5` ; do
  echo 'exit' | nc 192.168.1.1 22 ;
done

There's a lot of documentation on the netfilter/iptables firewall, and it's available modules which you can find in the Netfilter Extension HOWTO.

This HOWTO contains documentation on many different modules, along with examples. A recommended read if you're interested in Linux firewalling.

If you wish to experiment with rules and testing it's worth remembering how to remove all active rules. The following commands will flush your iptables filewall, and remove all currently active rules:

code:
iptables -F
iptables -X

<hr>

A titre informatif, voilà la syntaxe de ce module:

Citation:
This patch by Stephen Frost <sfrost@snowman.net> adds a new match that allows you to dynamically create a list of IP addresses and then match against that list in a few different ways.

For example, you can create a `badguy' list out of people attempting to connect to port 139 on your firewall and then DROP all future packets from them without considering them.

# iptables -A FORWARD -m recent --name badguy --rcheck --seconds 60 -j DROP
# iptables -A FORWARD -p tcp -i eth0 --dport 139 -m recent --name badguy --set -j DROP

# iptables --list
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere recent: CHECK seconds: 60
DROP tcp -- anywhere anywhere tcp dpt:netbios-ssn recent: SET

Supported options for the recent match are :

--name name
-> Specify the list to use for the commands. If no name is given then 'DEFAULT' will be used.

[!] --set
-> This will add the source address of the packet to the list. If the source address is already in the list, this will update the existing entry. This will always return success or failure if `!' is passed in.

[!] --rcheck
-> This will check if the source address of the packet is currently in the list and return true if it is, and false otherwise. Opposite is returned if `!' is passed in.

[!] --update
-> This will check if the source address of the packet is currently in the list. If it is then that entry will be updated and the rule will return true. If the source address is not in the list then the rule will return false. Opposite is returned if `!' is passed in.

[!] --remove
-> This will check if the source address of the packet is currently in the list and if so that address will be removed from the list and the rule will return true. If the address is not found, false is returned. Opposite is returned if `!' is passed in.

[!] --seconds seconds
-> This option must be used in conjunction with one of `rcheck' or `update'. When used, this will narrow the match to only happen when the address is in the list and was seen within the last given number of seconds. Opposite is returned if `!' is passed in.

[!] --hitcount hits
-> This option must be used in conjunction with one of `rcheck' or `update'. When used, this will narrow the match to only happen when the address is in the list and packets had been received greater than or equal to the given value. This option may be used along with `seconds' to create an even narrower match requiring a certain number of hits within a specific time frame. Opposite returned if `!' passed in.

--rttl
-> This option must be used in conjunction with one of `rcheck' or `update'. When used, this will narrow the match to only happen when the address is in the list and the TTL of the current packet matches that of the packet which hit the --set rule. This may be useful if you have problems with people faking their source address in order to DoS you via this module by disallowing others access to your site by sending bogus packets to you.

Comme vous pouvez voir, on peut définir autant de listes que l'on veut, ce qui permet d'être encore plus spécifique quand au blocage d'une source donnée.

Bref, un vrai bijou et une heureuse trouvaille que je vous fais partager...

Si vous avez des questions, n'hésitez pas

++
soul

Signaler ce message à un modérateur | IP: Logguée
Temps en ligne : 92 Jours, 19 Heures, 42 Minutes, 20 Secondes en ligne

07-12-2005 15:14

Cliquez ici pour lui envoyer un message privé

Ajouter soul^keeper à votre liste d'amis