Accueil > Réseau, Sécurité > Configuration avancée du firewall iptables

Configuration avancée du firewall iptables

10/12/2017 Categories: Réseau, Sécurité Tags: , ,
Print Friendly, PDF & Email

Iptables c’est quoi ?

Iptables est un firewall pour les distributions linux. WikipĂ©dia et d’autres articles expliquent ça bien mieux que moi, du coup je ne vais pas m’attarder lĂ  dessus. Mais pour faire simple, un pare-feu systĂšme est un logiciel qui vient contrĂŽler les flux rĂ©seaux connectĂ©s avec votre machine. Conceptuellement, le firewall va recevoir les flux rĂ©seaux, avant la socket. Il va alors appliquer diffĂ©rentes rĂšgles sur ce dernier, en fonction des rĂ©sultats des tests par rapport Ă  ces rĂšgles, un firewall laissera passer la connexion vers la socket ou rejettera le flux.

Les firewalls sont indispensables de nos jours en sĂ©curitĂ© informatique, il s’agit souvent de la 1Ăšre ligne de dĂ©fense d’une machine connectĂ©e sur internet et dans le cas de rĂ©seau d’entreprise, un des Ă©lĂ©ments vraiment efficace pour limiter les rebonds d’un attaquant dans votre rĂ©seau.

Bref, les firewalls c’est bon mangez-en


Mettre Ă  jour Iptables en 1.6.1

Alors sur une debian 8, c’est la version 1.4.1 qui Ă©tait prĂ©sente sur mon serveur. J’ai profitĂ© de ce TP pour la mettre Ă  jour vers la derniĂšre version. Les sources officielles sont disponibles sur le site du projet :

https://www.netfilter.org/projects/iptables/index.html

Et voici comment mettre Ă  jour votre firewall.

DĂ©pendances

Quelques paquets sont nécessaires à la derniÚre version, certains sont présents dans les dépots debian :

apt-get install libbison-dev, flex

D’autres non, et sont Ă  tĂ©lĂ©charger et installer depuis netfilter.org .

libmnl

curl -O https://www.netfilter.org/projects/libmnl/files/libmnl-1.0.4.tar.bz2
tar xvf libmnl-1.0.4.tar.bz2
cd libmnl-1.0.4/
./configure && make
make install
cd ..
rm -Rf libmnl-1.0.4*

libnftnl

curl -O https://www.netfilter.org/projects/libnftnl/files/libnftnl-1.0.8.tar.bz2
tar xvf libnftnl-1.0.8.tar.bz2
cd libnftnl-1.0.8/
./configure && make
make install
cd ..
rm -Rf libnftnl-1.0.8*

Mettre Ă  jour iptables 1.6.1

curl -O https://www.netfilter.org/projects/iptables/files/iptables-1.6.1.tar.bz2
tar xvf iptables-1.6.1.tar.bz2
cd iptables-1.6.1
./configure && make
make install

Je vous recommande un petit reboot, suite à l’installation comme on touche à des modules kernel.

shutdown -r now

Et vous pourrez alors vĂ©rifier que la derniĂšre version d’iptables est bien installĂ©e Ă  l’aide de la commande :

# iptables -V
iptables v1.6.1

Pour les N00bs, quelques rĂšgles simples

Conceptuellement, iptables fonctionne avec des « tables » et des « chains« . Si vous dĂ©butez avec iptables , considĂ©rez qu’il n’existe qu’une table de rĂšgles : « filter » dans la chaĂźne « INPUT« , et ne vous occupez pas (encore) du reste. Et vous devez simplement vous dire qu’un paquet TCP Ă  destination de votre serveur va ĂȘtre analysĂ© par chaque rĂšgle prĂ©sente dans cette table de votre firewall pour dĂ©cider s’il est acceptĂ© ou rejeter. On reviendra sur les autres tables dans la partie configuration avancĂ©e du firewall iptables plus tard dans ce tutoriel.

Le b.a.-ba d’un pare-feu c’est « d’ouvrir et de fermer » des ports TCP. Comprendre, autoriser des connexions sur certains ports TCP et les refuser sur les autres.

Pour la suite, je vais considĂ©rer qu’on configure le firewall d’un serveur web en ligne (type dedibox) avec seulement une IPv4 et que ce serveur hĂ©berge un site web en http (TCP/80) et https (TCP/443) et qu’il est administrĂ© en SSH (TCP/22). Tout le trafic TCP en entrĂ©e en dehors de ces 3 ports n’est donc pas lĂ©gitime et ne devrait pas atteindre notre serveur.

Vous pouvez afficher les rÚgles actuellement appliquée avec la commande

iptables -L -v -n

Qui normalement devrait initialement retourner que tout est accepté.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

On va donc commencer Ă  appliquer des rĂšgles en ligne de commande :

iptables -A INPUT -i lo -j ACCEPT # Autoriser les flux en localhost
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Autoriser les connexions déjà établies,
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT # Autoriser SSH,
iptables -A INPUT -p tcp -m tcp --dport http -j ACCEPT # Autoriser HTTP,
iptables -A INPUT -p tcp -m tcp --dport https -j ACCEPT # Autoriser HTTPS,
iptables -P INPUT DROP # Politique par défaut de la table INPUT : DROP. (i.e bloquer tout le reste).
iptables -P FORWARD DROP # On est pas un routeur ou un NAT pour un réseau privé, on ne forward pas de paquet.

Et c’est tout, qui a dit qu’iptables c’est compliquĂ© Ă  paramĂ©trer ?

Iptables-persistent
Bon c’est bien tout ça mais il reste un petit soucis : les rĂšgles qu’on vient de configurer ne seront pas maintenues entre deux redĂ©marrages de votre serveur. Ce qui vous oblige Ă  les rĂ©-appliquer Ă  chaque reboot. C’est un peu dommage, mais il existe un paquet sous debian qui permet de recharger automatiquement un backup de rĂšgles Ă  chaque dĂ©marrage du serveur. Il s’installe avec :

apt-get install iptables-persistent
Iptables-persistent applique au démarrage une sauvegarde de vos rÚgles placées dans le fichier : /etc/iptables/rules.v4, et pour sauvegarder votre jeu de rÚgles actuels dans ce fichier il suffit de faire :

iptables-save > /etc/iptables/rules.v4

Ce qui permettra à ces rùgles de s’appliquer aprùs chaque reboot.

Comprendre Iptables pour les G33K.ette.s
Bon si vous ĂȘtes un $crIpT kIddI3, vous devriez vous arrĂȘtez lĂ . Pour les autres, Iptables c’est trĂšs trĂšs puissant comme outils, vous pouvez lui faire faire beaucoup de choses, du log des connexions sur le systĂšmes aux rĂšgles anti-DDOS et anti-portscan en passant par l’équilibrage charge des connexions entrantes sur vos CPU. Autant vous dire qu’il y a du boulot et qu’on va allĂšgrement dĂ©passer les cinq lignes de configurations prĂ©cĂ©dentes


Mais avant de recevoir ces rĂšgles on va devoir rentrer un petit plus en dĂ©tails dans le fonctionnement d’Iptables.

Chains & Table

Le site Iptables.info fournis un excellent schéma pour comprendre le cheminement que va faire un paquet dans iptables :

Dans le cadre d’un filtrage de sĂ©curitĂ© pour le serveur web dĂ©crit plus haut, ce sont les chains PREROUTING et INPUT qui vont nous intĂ©resser. Les autres auront un intĂ©rĂȘt si vous positionnez votre firewall en coupure (sur un routeur par exemple). Ici seules les connexions entrantes Ă  destination de notre serveur sont intĂ©ressantes.

Un paquet à destination de notre serveur va donc passer dans l’ordre par les tables suivantes :

PREROUTING – raw
PREROUTING – mangle
PREROUTING – nat
INPUT – mangle
INPUT – filter

Et si ce paquet ne se fait pas droper par une de ces table, et atteint une rĂšgle finissant en ACCEPT (puisqu’on a mis une policy DROP sur INPUT), il sera transfĂ©rĂ© vers le service rĂ©seau demandĂ©.

Rùgles, tables, chains : pourquoi tant d’objets ?

Alors pourquoi dĂ©finir certaines rĂšgles dans une table plutĂŽt qu’une autre ? Et bien pour des raisons de performances, assez logiquement : plus un paquet est « dropé » tĂŽt par iptables et moins il aura consommĂ© de ressources systĂšmes puisqu’il sera passĂ© par moins de test dans iptables. Mais dans ce cas, pourquoi ne pas mettre toutes nos rĂšgles en PREROUTING – raw  ? Simplement parce que les couples « chains-table » d’iptables ne permettent pas tous d’effectuer les mĂȘmes opĂ©rations. Si kes rĂšgles dans INPUT-filter permettent de dĂ©finir des rĂšgles trĂšs complexes, elles seront aussi plus consommatrices de ressources CPU que les rĂšgles en PREROUTING qui ne peuvent exprimer que des tests « simples » mais aussi trĂšs rapide Ă  traiter.

La consĂ©quence de tout ça c’est que vous avez intĂ©rĂȘt Ă  remonter autant que possible vos rĂšgles « vers le haut » dans le schĂ©ma pour essayer de droper un maximum de paquets en PREROUTING la oĂč cela consommera le moins de ressources et ne garder que les rĂšgles compliquĂ©es dans INPUT-filter pour bloquer les attaques les plus Ă©voluĂ©es.

Et les performances, quand on se mange un attaque DDOS ça compte !

Configuration avancée du firewall iptables
 pour les G33K.ette.s

Sysconfig time !

Et malheureusement, une partie des rĂšgles que l’on va dĂ©finir ci-dessous nĂ©cessites des rĂ©glages noyaux particuliers. Je ne dĂ©taille pas tous les rĂ©glages : la plupart trouve leur explication dans les sources que j’ai rĂ©fĂ©rencĂ©es Ă  la fin de cet article. Allons-y, il faut modifier le fichier /etc/sysctl.conf sur votre serveur pour ajouter les rĂ©glages suivants :

# Enable Spoof protection (reverse-path filter) Turn on Source Address Verification in all interfaces to prevent some spoofing attacks
 net.ipv4.conf.default.rp_filter=1
 net.ipv4.conf.all.rp_filter=1
 # Enable SYN Cookie
 net.ipv4.tcp_syncookies=1
 # Do not accept ICMP redirects (prevent some MITM attacks)
 net.ipv4.conf.all.accept_redirects = 0
 net.ipv6.conf.all.accept_redirects = 0
 # Accept ICMP redirects only for gateways listed in our default gateway list (enabled by default)
 net.ipv4.conf.all.secure_redirects = 1
 # Do not send ICMP redirects (we are not a router)
 net.ipv4.conf.all.send_redirects = 0
 # Do not accept IP source route packets (we are not a router)
 net.ipv4.conf.all.accept_source_route = 0
 net.ipv6.conf.all.accept_source_route = 0
 #do not allow ACK pkts to create new connection (normal behavior SYN->, <-SYN,ACK, ACK->)
 net.netfilter.nf_conntrack_tcp_loose=0
 #enable TCP timestamps as SYN cookies utilize this TCP
 net.ipv4.tcp_timestamps=1
 #Conntrack Entry Tuning (Calculate your own values ! depending on your hardware)
 net.netfilter.nf_conntrack_max=200000

Plus un dernier tweak :

echo 'options nf_conntrack hashsize=500000' > /etc/modprobe.d/nf_conntrack.conf # (Calculate your own values ! depending on your hardware)

mais qui nĂ©cessite un reboot pour ĂȘtre appliquĂ©e, donc on le place directement :

echo 500000 > /sys/module/nf_conntrack/parameters/hashsize

Vous pouvez alors appliquer ces modifications ainsi :

sysctl -p

Passons aux rĂšgles iptables.

Configuration avancée du firewall iptables

Note : A partir de maintenant je ne donne plus les rÚgles à appliquer dans le format « ligne de commande » mais dans le format fichier de sauvegarde iptables issue du iptables-save. Pour appliquer ces nouvelles rÚgles il faut alors modifier le fichier/etc/iptables/rules.v4, et exécuter commande suivante :

iptables-restore < /etc/iptables/rules.v4

Ce mode de fonctionnement permet d’appliquer plusieurs rĂšgles « en mĂȘme temps » et en travaillant sur un fichier. Ce qui est plus pratique que d’appliquer des modifs en live sans se rappeler de la ligne prĂ©cĂ©dente


RĂšgles anti « bordel d’internet »

Vous seriez surpris du nombre de tentatives de connexions TCP bizarres qu’on trouve sur Internet : Xmas Scan par nmap n’est un exemple avec toutes les flags TCP à 1. Du coup, voici un jeu de rùgles permettant de rejeter sans trop se poser de questions les connexions TCP avec des combinaisons de flag impossibles ou improbables :

*mangle
 # paquet avec SYN et FIN Ă  la fois
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
 # paquet avec SYN et RST Ă  la fois
 -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
 # paquet avec FIN et RST Ă  la fois
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
 # paquet avec FIN mais sans ACK
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
 # paquet avec URG mais sans ACK
 -A PREROUTING -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
 # paquet avec PSH mais sans ACK
 -A PREROUTING -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
 # paquet avec tous les flags Ă  1 <=> XMAS scan dans Nmap
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
 # paquet avec tous les flags Ă  0 <=> Null scan dans Nmap
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
 # paquet avec FIN,PSH, et URG mais sans SYN, RST ou ACK
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
 # paquet avec FIN,SYN,PSH,URG mais sans ACK ou RST
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
 # paquet avec FIN,SYN,RST,ACK,URG Ă  1 mais pas PSH
 -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP

On peut Ă©galement Ă©tablir d’autres rĂšgles de filtrage triviales basĂ©es sur les IP sources en dropant tout ce qui arrive d’un rĂ©seau privĂ©/rĂ©servĂ©. C’est du spoofing d’IP source, c’est trĂšs peu probable pour un serveur avec uniquement une IP publique sur Internet.

*mangle
 -A PREROUTING -s 224.0.0.0/8 -j DROP
 -A PREROUTING -s 169.254.0.0/16 -j DROP
 -A PREROUTING -s 172.16.0.0/12 -j DROP
 -A PREROUTING -s 192.0.2.0/24 -j DROP
 -A PREROUTING -s 192.168.0.0/16 -j DROP
 -A PREROUTING -s 10.0.0.0/8 -j DROP
 -A PREROUTING -s 0.0.0.0/8 -j DROP
 -A PREROUTING -s 240.0.0.0/5 -j DROP
 -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP

Et voilĂ , aprĂšs j’ai quelques rĂšgles bonus dans le mĂȘme genre que je vous met Ă  la fin.

RĂšgles anti-DDOS

Le principe d’un DDOS est de saturer le serveur de requĂȘtes jusqu’a ce qu’il s’effondre par manque de ressources. La dĂ©fense locale au serveur consiste Ă  droper le plus efficacement possible toutes les demandes de connexions anormales. Il existe diffĂ©rent type de DDOS, certains se contente de spammer des SYN vers votre serveur (en espĂ©rant ouvrir plein de connexions en attente, et saturer votre machine de connexion en attente) et d’autre allant un peu plus loin dans le 3-way handshake TCP (3WHS) toujours avec le mĂȘme objectif. L’idĂ©e dans la tĂȘte de l’attaquant c’est de faire plein d’opĂ©rations peu coĂ»teuses pour lui (Ă©tablir des connexions TCP avec votre serveur et ne pas les suivre) et coĂ»teuses pour votre machine (garder ouvertes tout un tas de connexions en attentes ou inactive)

Loose et invalid state

Un des premiĂšres rĂšgles consiste Ă  dĂ©sactiver le mode « loose » (ça ne s’invente pas) de votre kernel. Ce dernier autorise par dĂ©faut un paquet ACK ouvrir une connexion sur votre serveur (sautant ainsi les deux premiĂšres Ă©tapes du 3WHS).

On a dĂ©jĂ  fait ça plus haut en mettant l’option nf_conntrack_tcp_loose Ă  0 dans le kernel. CombinĂ© ça avec une rĂšgle qui drop les connexions dans un Ă©tat invalide et vous empĂȘchez ces paquets ACK d’établir des connexions avec votre serveur.

*filter
 -A INPUT -m state --state INVALID -j DROP

SynProxy

Synproxy est un mĂ©canisme introduit dans la 1.4.1 d’iptables pour permettre de rĂ©pondre efficacement aux attaques par SYN flooding (i.e. noyer le serveur sous des demandes de SYN qui ne seront pas suivi ACK). Le principe est de sortir les paquets SYN du connection-tracker d’iptables (conntrack) dont les opĂ©rations sont assez coĂ»teuses en ressources et d’établir Ă  la places les connexions au travers d’un proxy-TCP optimisĂ© pour traiter spĂ©cifiquement ce type de demandes et ne transmettre Ă  votre serveur que les connexions TCP correctement Ă©tablies.

On peut le mettre en place à l’aide des lignes suivantes :

*raw
# 1. en -t raw, les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne seront pas suivi par le connexion tracker (et donc traités plus rapidement)
 -A PREROUTING -i eth0 -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
*filter
 # 2. en input-filter, les paquets TCP avec le flag SYN Ă  destination des ports 22,80 ou 443 non suivi (UNTRACKED ou INVALID) et les fais suivre Ă  SYNPROXY.
 # C'est à ce moment que synproxy répond le SYN-ACK à l'émeteur du SYN et créer une connexion à l'état ESTABLISHED dans conntrack, si et seulement si l'émetteur retourne un ACK valide.
 # Note : Les paquets avec un tcp-cookie invalides sont dropés, mais pas ceux avec des flags non-standard, il faudra les filtrer par ailleurs. 
 -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
# 3. en input-filter, la rĂšgles SYNPROXY doit ĂȘtre suivi de celle-ci pour rejeter les paquets restant en Ă©tat INVALID.
 -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m tcp -m state --state INVALID -j DROP

Cette partie mĂ©rite qu’on s’y attarde un peu. La premiĂšre rĂšgle se fait en PREROUTING-raw dĂšs la rĂ©ception du paquet, empĂȘchant ainsi toute consommation inutile de mĂ©moire. Notre paquet passera ensuite en PREROUTING-mangle, permettant de filtrer les paquets anormaux, et arrivera alors Ă  la rĂšgle 2 ou SYN-PROXY fera son boulot crĂ©er des connexions ESTABLISHED seulement lorsque le client effectue un 3WHS valide. La derniĂšre rĂšgle rejette enfin toutes les connexions restantes dans un Ă©tat INVALID, appliquant au passage la protection contre les Ă©tats invalides qu’on a vu juste avant.

MaĂźtrise de charge

Bon on s’est protĂ©gĂ© des DDOS simples Ă  base de SYN et de ACK TCP, mais on ne fait rien pour gĂ©rer un surnombre de connexions normales qui atteignent l’état ESTABLISHED. Potentiellement toutes ces connexions sont lĂ©gitimes, du coup soit on laisse tout passer, soit on essaye de limiter la casse.

Pour cela, une technique consiste Ă  regrouper les IP sources par bloc de 256 (i.e par subnet source en /24) et de n’autoriser qu’un nombre maximum de demandes de connexions SYN par seconde pour chaque subnet. On peut faire ça avec le module hashlimit. Cela aura le mĂ©rite mettre un plafond de connexion par seconde vers votre serveur par groupe de 256 IP.

*raw
 -A PREROUTING -i eth0 -p tcp -m tcp --syn -m multiport --dports 22,80,443 -m hashlimit --hashlimit-above 200/sec --hashlimit-burst 1000 --hashlimit-mode srcip --hashlimit-name syn --hashlimit-htable-size 2097152 --hashlimit-srcmask 24 -j DROP

On peut appliquer une rĂšgle similaire sur le nombre de connexions maximum autorisĂ©es en simultanĂ© par une seule IP source Ă  l’aide du module connlimit.

*filter
 -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 100 -j REJECT

Ce qui empĂȘchera une seule IP de crĂ©er un nombre insensĂ© de connexions avec votre serveur.

Blacklisting portscanner

Une technique que l’on a pas abordĂ©e pour l’instant c’est le portscan, un petit man nmap vous en dira plus si vous ne savez pas ce que c’est. En gros, un attaquant cherche Ă  dĂ©couvrir quels sont les services ouverts sur votre serveur et va tenter d’établir une connexion TCP (plus ou moins valide) sur tous les ports courants, voire carrĂ©ment les 65535 ports, et attendre la rĂ©ponse du serveur pour dĂ©tecter ceux ouvert.

Une premiĂšre technique consiste Ă  limiter le nombre de paquets typique d’un scan, Il y a cet article qui explique bien comment on fait ça. Mais pour ma part, je ne vois pas l’intĂ©rĂȘt de limiter ce qu’on peut droper directement
 du coup la plupart de mes rĂšgles anti « bordel d’internet » plus haut avec le SYNPROXY force dĂ©jĂ  l’attaquant Ă  faire un 3WHS dans les rĂšgles pour voir ce qui se passe la ou c’est ouvert, et la policy DROP en INPUT jettera tout le reste


Du coup on peut passer Ă  une rĂšgle que je trouve plus rigolote, qui consiste Ă  « piĂ©ger des ports » qui ne sont pas utilisĂ©s sur la machine, et blacklister pour un certains temps les machines qui essayer de s’y connecter.

On peut faire ça avec les rÚgles suivantes.

*filter
 -A INPUT -m recent --rcheck --seconds 86400 --name portscan --mask 255.255.255.255 --rsource -j DROP
 -A INPUT -m recent --remove --name portscan --mask 255.255.255.255 --rsource
 -A INPUT -p tcp -m multiport --dports 25,445,1433,3389 -m recent --set --name portscan --mask 255.255.255.255 --rsource -j DROP

Alors attention avec cette rĂšgle, un attaquant motivĂ© qui s’en rendrait compte, pourrait forger des paquets TCP (qui a dit Scapy ?) Ă  destination d’un de ces ports mais avec des IP sources fausses. ConsĂ©quence : votre serveur va se mettre Ă  blacklister tout internet pour 24h si l’attaquant dĂ©cide de parcourir la plage IPv4 complĂšte
 Du coup, c’est une rĂšgle qui fonctionne bien sur un petit serveur perso sans prĂ©tention mais je n’irai pas la mettre en production sur un frontal-web d’une grande boite
 Et pensez Ă  mettre en whitelist votre IP personnelle ou du boulot avec cette rĂšgle, ça vous Ă©vitera de vous faire jeter pour 24h le jour ou vous l’aurez oubliĂ© et que vous lancerez un scan de votre machine :

! -s <IPperso>,<IPboulots>[/NETMASK]

Notez aussi que vous pouvez voir quelles sont les IP blacklistées dans le fichier :

/proc/net/xt_recent/portscan

C’est bon moyen de faire une liste d’IP pourries sur lesquels tester un nmap
^^

Et enfin, accepter les connexions sur des port.

DĂ©jĂ  vu plus haut, pour finir on autorise enfin des connexions entrantes :

*filter
 -A INPUT -i lo -j ACCEPT
 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

Bonus

Bon il me reste quelques rÚgles bonus ou optionnelles à vous proposer, en liste à la Prévert :

On dégage le ping :

*mangle
 -A PREROUTING -p icmp -j DROP

Bloquer la fragmentation TCP

*mangle
 -A PREROUTING -f -j DROP

Notez pour finir que Fail2ban ajoute tout seul des rĂšgles dans votre firewall iptables, mais j’en ai dĂ©jĂ  parlĂ© dans cet article.

Conclusion

Ça vous a paru long ? je n’ai fais qu’effleurer la surface de l’iceberg iptables, je vous invite Ă  parcourir les 2477 lignes du man iptables-extensions pour vous rendre compte des possibilitĂ©s offerte par iptables. Dans les choses sympa que je vous invite Ă  creuser par vous mĂȘme :

La target LOG qui vous permettra de journaliser les connexions qui vous intéresses (méfiez-vous ça peut cracher un paquet de lignes).

Le module CPU pour mettre en oeuvre une rĂ©partition de charge de l’établissement des connexions TCP sur les diffĂ©rents CPU de votre serveur.

Le module time qui permet par exemple de fermer un service automatiquement le weekend ou Ă  certaines heures.

Related Post

Les commentaires sont fermés.