Réduisez de moitié les règles de pare-feu - une règle iptables pour tcp et udp

J'ai un certain nombre de règles iptables sur mon pare-feu qui ressemblent à ceci:

iptables -A zone_lan_forward -p tcp -d 1.2.3.0/24 -j ACCEPT
iptables -A zone_lan_forward -p udp -d 1.2.3.0/24 -j ACCEPT

Existe-t-il un raccourci pour avoir deux règles - une pour tcp et une pour udp - pour chaque adresse? Je veux dire, je peux faire quelque chose comme ça:

iptables -A zone_lan_forward -p tcp,udp -d 1.2.3.0/24 -j ACCEPT

— Big McLargeÉnorme
source

Réponses:

Créez une nouvelle chaîne qui acceptera tous les paquets TCP et UDP et passez à cette chaîne à partir des règles permissives IP / port individuelles:

iptables -N ACCEPT_TCP_UDP
iptables -A ACCEPT_TCP_UDP -p tcp -j ACCEPT
iptables -A ACCEPT_TCP_UDP -p udp -j ACCEPT

iptables -A zone_lan_forward -d 1.2.3.0/24 -j ACCEPT_TCP_UDP

Cela ajoute la surcharge de quelques lignes supplémentaires, mais réduit de moitié le nombre de règles TCP / UDP.

Je n'oublierais pas l' -pargument, car vous ouvrez non seulement le pare-feu pour ICMP, mais aussi tout autre protocole. Depuis la page de manuel iptables sur -p:

Le protocole spécifié peut être l'un des protocoles tcp, udp, icmp ou tous, ou il peut s'agir d'une valeur numérique, représentant l'un de ces protocoles ou un autre. Un nom de protocole de / etc / protocoles est également autorisé.

Vous n'écoutez peut-être aucun protocole à l'exception de TCP, UDP et ICMP pour le moment , mais qui sait ce que l'avenir peut nous réserver. Ce serait une mauvaise pratique de laisser le pare-feu ouvert inutilement.

Avertissement: Les commandes iptables sont sur le dessus de ma tête; Je n'ai pas accès à une box sur laquelle les tester ATM.

— s.co.tt
source

Il s'agit d'une solution très élégante qui ne laisse pas inutilement le pare-feu ouvert.

— Big McLargeHuge

Mais cette méthode de création d'une nouvelle chaîne échouera si le filtrage est effectué via le numéro de port de destination. Quelqu'un peut-il suggérer comment surmonter le problème mentionné ci-dessus?

— Amor

@Amor Dans cet exemple, si vous avez utilisé -p alltoutes les --dportrègles de la zone_lan_forwardchaîne, cela pourrait réaliser ce que vous cherchez. Je suppose bien sûr qu'il n'y a pas d'autre moyen d'accéder à cette chaîne avec un protocole non TCP / UDP en raison de la ACCEPT_TCP_UDPchaîne. Évidemment, c'est une stratégie risquée si plusieurs personnes ont accès pour modifier les règles et que quelqu'un arrive et édite vos règles sans comprendre cette subtilité.

— Samuel Harmer

Oups. N'a pas remarqué l'ordre des chaînes. Vous devez également changer l'ordre des chaînes dans cet exemple pour que ce que je viens de dire fonctionne correctement. Alors ACCEPT_TCP_UDPsauts vers zone_lan_forwardlesquels saute ensuite ACCEPT.

— Samuel Harmer

Si vous ne vous souciez pas vraiment du trafic ICMP (que vous pouvez de toute façon bloquer globalement avec une règle), vous pouvez simplement omettre l'indicateur -p et cela couvrira tous les protocoles.

— Nathan C
source

Dois-je me soucier du trafic ICMP? Je m'intéresse principalement à l'accès HTTP.

— Big McLargeHuge

Pas vraiment. Vous pouvez bloquer ICMP (ping) si vous le souhaitez, mais comme il sert de toute façon le trafic HTTP, il n'y a pas grand chose à faire.

— Nathan C

@NathanC, je pense que le conseil d'ouvrir TOUS les ports lorsque l'OP demande comment diviser par deux ses règles peut entraîner des problèmes, maintenant ou à l'avenir.

— Jed Daniels

@JedDaniels, le commutateur -p spécifie les protocoles et non les ports. La réponse ci-dessous a une alternative s'ils souhaitent verrouiller autre chose que tcp & udp.

— Nathan C

@NathanC Oui, et la suppression de -p signifie "ouvrir tous les protocoles, pas seulement tcp ou udp", ce qui est téméraire sinon dangereux.

— Jed Daniels