Comment interpréter une configuration de string iptables dans OpenWrt

Il s'agit de donner un sens aux strings trouvées dans la configuration par défaut d' iptables sur un routeur domestique standard exécutant OpenWrt (un Linux dépouillé pour les périphériques de routing), mais qui peut finalement ne pas être spécifique à ce système particulier.

Concentrons-nous sur la string principale INPUT ici, et ignorons FORWARD et OUTPUT de la même table , ainsi que PREROUTING et POSTROUTING de la table nat .

Faire un iptables -L -t filter montre un grand nombre de règles. J'ai réarrangé la sortie ci-dessous pour la rendre less intimidante et pour tenter de déterminer les parties qui entravent ma compréhension.

Il y a trois strings embeddedes dans la table de filter , qui apparaissent en haut de la sortie. (J'ai spécifié -v parce que je le trouve less confus .)

 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 1260 133K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 8 544 ACCEPT all -- lo any anywhere anywhere 787 41632 syn_flood tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN 13012 1249K input_rule all -- any any anywhere anywhere 13012 1249K input all -- any any anywhere anywhere Chain FORWARD … # not considering this chain here Chain OUTPUT … # not considering either

Comme vous pouvez le voir, j'ai coupé les strings référencées de FORWARD et OUTPUT afin de se concentrer sur INPUT . (J'aurais pu choisir l'un des deux autres car ils sont construits de manière similaire.)

INPUT a une politique d' ACCEPT , et il spécifie cinq règles. Les trois premiers sont clairs pour moi. Tout d'abord, acceptez les choses qui sont «établies» ou «liées». (Par exemple, acceptez la réponse d'une requête HTTP ou DNS que j'ai faite.) Secondes, acceptez tout ce qui va au périphérique de bouclage ( 127.0.0.1 ). (Cela ne peut provenir que d'un localhost lui-même, et je veux que cela fonctionne.) Sinon, il n'y a pas de sens.) Troisièmement, ayez une protection anti-synchro. (Ce qui protège contre un certain type d'attaque.)

 Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 787 41632 RETURN tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 0 0 DROP all -- any any anywhere anywhere

Mais alors, il y a deux règles qui se ramifient en deux strings appelées input et input_rule , et la question est de savoir pourquoi y en a-t-il deux, et lequel êtes-vous censé utiliser pour quoi?

Descendons la stack de sauts de ces règles.

 Chain input_rule (1 references) pkts bytes target prot opt in out source destination

Il n'y a rien ici encore. Il est destiné à moi d'append des règles. Mais quel genre de règles?

 Chain input (1 references) pkts bytes target prot opt in out source destination 6315 482K zone_lan all -- br-lan any anywhere anywhere 6697 767K zone_wan all -- pppoe-wan any anywhere anywhere

D'accord, celui-ci a des trucs, sauter plus bas dans LAN et WAN, ce qui est logique pour un routeur domestique.

 Chain zone_lan (1 references) pkts bytes target prot opt in out source destination 6315 482K input_lan all -- any any anywhere anywhere 6315 482K zone_lan_ACCEPT all -- any any anywhere anywhere Chain zone_wan (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:bootpc 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request 6697 767K input_wan all -- any any anywhere anywhere 6697 767K zone_wan_REJECT all -- any any anywhere anywhere

Comme vous pouvez le voir, chacune de ces règles saute plus bas dans la stack vers des règles plus définies par l'user.

 Chain input_lan (1 references) pkts bytes target prot opt in out source destination Chain zone_lan_ACCEPT (2 references) pkts bytes target prot opt in out source destination 4 1322 ACCEPT all -- any br-lan anywhere anywhere 6315 482K ACCEPT all -- br-lan any anywhere anywhere

Quel est le but de input_lan ? L'autre est probablement d'accepter des packages, mais cela me fait me requestr … la politique pour INPUT est ACCEPT , alors pourquoi répéter ACCEPT ici?

Maintenant, l'input de WAN. Si vous faites défiler vers le haut, vous pouvez voir que certains trucs UDP et ICMP sont acceptés. C'est pour DHCP et, fondamentalement, ping . C'est clair. Ce qui est less clair, encore une fois, c'est le contenu partiellement vide suivant ces règles:

 Chain input_wan (1 references) pkts bytes target prot opt in out source destination

Même question que pour input_lan .

 Chain zone_wan_REJECT (2 references) pkts bytes target prot opt in out source destination 0 0 reject all -- any pppoe-wan anywhere anywhere 6697 767K reject all -- pppoe-wan any anywhere anywhere

Ok, c'est une input de WAN (non établie ou apparentée), et oui, nous voulons probablement la rejeter, et maintenant il y a deux types de rejet ici, l'un fermant le socket ( tcp-reset ) pour les tentatives de connection TCP et l'autre un via la réponse ICMP ( icmp-port-unreachable ) pour les messages ICMP (pensez ping ).

 Chain reject (5 references) pkts bytes target prot opt in out source destination 595 31817 REJECT tcp -- any any anywhere anywhere reject-with tcp-reset 4858 582K REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable

Ce dernier est un fourre-tout. Donc, rien ne sera accepté ici.

Enfin, voici une list d'autres strings trouvées dans la table de filter qui ne sont pas référencées par la string INPUT embeddede dans la table net . Juste pour être complet, et pour voir qu'ils semblent avoir des constructions analogues.

 # other chains, not reached from the INPUT chain, so truncated and moved here Chain forward (1 references) Chain forwarding_lan (1 references) Chain forwarding_rule (1 references) Chain forwarding_wan (1 references) Chain nat_reflection_fwd (1 references) Chain output (1 references) Chain output_rule (1 references) Chain reject (5 references) Chain zone_lan_DROP (0 references) Chain zone_lan_REJECT (1 references) Chain zone_lan_forward (1 references) Chain zone_wan_ACCEPT (2 references) Chain zone_wan_DROP (0 references) Chain zone_wan_forward (1 references)

Tellement bien. Désolé pour ce long post. Il y a eu quelques questions en cours de route. Je ne sais pas comment mettre cela de manière plus simple ou plus courte. Cette configuration iptables n'est pas vraiment facile à comprendre car il y a des détails peu clairs qui se répandent ici et là. J'espère que vous pouvez clarifier cela et expliquer la justification sous-jacente. Merci de votre attention.

Pour autant que je sache, le pare-feu est généré à partir d'un file de configuration de niveau supérieur sur openwrt. Comme de nombreuses possibilités différentes doivent être sockets en charge, les règles de génération réelle ne sont pas optimisées et peuvent donc contenir des strings inutiles / inutilisées / vides. Voir l' article wiki d'OpenWRT pour plus de détails.

Pour répondre à certaines de vos questions

pourquoi "input_rule" est vide

Comme vous l'avez mentionné, il pourrait être un endroit où l'user peut facilement insert des règles personnalisées. Une autre possibilité est que "input" était à l'origine "input_rule" et que "input_rule" est toujours créé pour une compatibilité descendante avec les anciens scripts.
Quel est le but de input_lan / input_wan?

Vous pouvez bloquer le trafic des hôtes internes sur le réseau local vers le routeur (par exemple pour protéger son interface de configuration) ou activer l'access depuis l'extérieur.
ACCEPTER la valeur par défaut pour INPUT, alors pourquoi répéter ACCEPTER ici?

Comme vous l'avez remarqué, ce n'est pas nécessaire ici. Mais comme zone_lan_REJECT existe, il semble que le script soit indépendant de la politique.

C'est une séparation claire des préoccupations. Les règles d'access au réseau WAN doivent être différentes de celles du réseau local.

La configuration par défaut ne fournit pas de règles d'acceptation pour les services qui ne sont pas nécessairement offerts sur votre réseau. En règle générale, la plupart des users ne devraient offrir aucun service sur Internet. L'ajout de règles appropriées aux jeux de règles appropriés activera les services. L'interface Web d'OpenWrt devrait fournir l'aide via des lists déroulantes.

La documentation de Shorewall Basic Two-Interace Firewall devrait vous donner une bonne compréhension de ce qui est et devrait se passer. Il est possible de replace le pare-feu OpenWrt par un pare-feu Shorewall-lite, mais pour un pare-feu de base, le pare-feu existant le fera. Certains packages supposent qu'ils fonctionnent avec le pare-feu par défaut et prendront du travail si vous ne l'êtes pas.

Je suis d'accord avec jofel.

input_rule, input_lan et input_wan est compatible avec les anciens scripts.

Pour de meilleures statistics de packages pour le nouvel UCI, mettez vos règles dans zone_lan et zone_wan devrait être mieux. Et aussi, la zone_lan_accept il y a probablement utilisé pour entrer et sortir le nombre de packages.

En fait, les règles openwrt iptables sont bien organisées.

Prenez delegate_input par exemple (une autre string a une structure similaire):

deux ACCEPTs: acceptent lo et tcp trafic CONNEXE, ETABLI
syn_flood: baisse le trafic d'inondation syn
input_rule: gère les inputs provenant du trafic LAN et WAN
zone_lan: traiter l'input UNIQUEMENT à partir de LAN, ACCEPTERa le trafic sans correspondance
zone_wan: traiter avec input UNIQUEMENT de wan, rejettera le trafic sans correspondance

J'ai écrit un outil précisément pour cette tâche . Il reformate la sortie iptables -S dans un tree de strings lors de leur application.

En analysant sa sortie, j'ai déduit que les strings de _rule sont destinées à des règles ajoutées manuellement.

L'outil est également utile pour le diagnostic des règles: si vous réinitialisez les counturs de règles, effectuez un test réseau et alimentez la sortie avec des counturs de packages, vous pourrez voir quel (s) path (s) dans l'arborescence de votre trafic de test.