Il s'agit d'une question canonique proposée sur la compréhension et le débogage du pare-feu logiciel sur les systèmes Linux.

En réponse à la réponse de l' EEAA et au commentaire de @ Shog, nous avons besoin d'un Q&A canonique approprié pour clore les questions courantes relativement simples sur iptables.

Qu'est-ce qu'une méthode structurée pour déboguer des problèmes avec le pare-feu logiciel Linux, le cadre de filtrage de paquets netfilter , communément appelé par l'interface utilisateur iptables ?

Quels sont les pièges courants, les questions récurrentes et les choses simples ou légèrement plus obscures pour vérifier qu'un administrateur de pare-feu occasionnel pourrait ignorer ou bénéficier d'une autre manière de savoir?

Même lorsque vous utilisez des outils tels que UFW , FirewallD (aka firewall-cmd), Shorewall ou similaire, vous pourriez bénéficier de regarder sous le capot sans la couche d'abstraction offerte par ces outils.

Cette question n'est pas conçue comme un guide pratique pour la construction de pare-feu: consultez la documentation du produit pour cela et, par exemple, contribuez des recettes à iptables Trips & Tricks ou recherchez dans les questions marquées iptables ufw firewalld firewall-cmd pour les scores élevés fréquents et bien considérés Questions et réponses.

En général:

L'affichage et la modification de la configuration du pare-feu nécessitent des privilèges d'administrateur ( root), tout comme l'ouverture de services dans la plage de numéros de port restreinte. Cela signifie que vous devez être connecté en tant que rootou utiliser sudopour exécuter la commande en tant que root. J'essaierai de marquer ces commandes avec l'option [sudo].

Contenu:

1. Les questions d'ordre ou la différence entre -Iet-A
2. Afficher la configuration actuelle du pare-feu
3. Interpréter la sortie de iptables -L -v -n
4. Connaissez votre environnement
5. Les chaînes INPUT et FORWARD
6. Modules du noyau

1. Ordonner des questions ou la différence entre -Iet-A

La chose à retenir est que les règles de pare-feu sont vérifiées dans l'ordre où elles sont répertoriées. Le noyau arrêtera de traiter la chaîne lorsqu'une règle sera déclenchée qui autorisera ou interdira un paquet ou une connexion.

Je pense que l'erreur la plus courante pour les administrateurs de pare-feu novices est qu'ils suivent les instructions correctes pour ouvrir un nouveau port, comme celui ci-dessous:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

puis découvrez qu'il ne prendra pas effet.

La raison en est que l' -Aoption ajoute cette nouvelle règle, après toutes les règles existantes et puisque très souvent la règle finale dans le pare-feu existant était celle qui bloque tout le trafic qui n'est pas explicitement autorisé, ce qui entraîne

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Ou équivalent dans iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

et la nouvelle règle ouvrant le port TCP 8080 ne sera jamais atteinte. (comme en témoignent les compteurs restant obstinément à 0 paquets et zéro octet).

En insérant la règle avec -Ila nouvelle règle aurait été la première de la chaîne et fonctionnera.

2. Affichez la configuration actuelle du pare-feu

Ma recommandation pour l'administrateur du pare-feu est de regarder la configuration réelle du noyau Linux, plutôt que d'essayer de diagnostiquer les problèmes de pare-feu à partir d'outils conviviaux. Souvent, une fois que vous comprenez les problèmes sous-jacents, vous pouvez facilement les résoudre dans une affaire prise en charge par ces outils.

La commande [sudo] iptables -L -v -nest votre ami (bien que certaines personnes aiment iptables-savemieux). Souvent, lors de la discussion des configurations, il est utile d'utiliser également l' --line-numbersoption pour numéroter les lignes. La référence à la règle #X facilite leur discussion un peu plus facilement.
Remarque: les règles NAT sont inclus dans la iptables-savesortie , mais doivent listés séparément en ajoutant l' -t natoption de savoir [sudo] iptables -L -v -n -t nat --line-numbers.

L'exécution de la commande plusieurs fois et la vérification des compteurs d'incrémentation peuvent être un outil utile pour voir si une nouvelle règle est réellement déclenchée.

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

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

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Alternativement, la sortie de iptables-savedonne un script qui peut régénérer la configuration du pare-feu ci-dessus:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

C'est une question de préférence ce que vous trouverez plus facile à comprendre.

3. Interpréter la sortie de iptables -L -v -n

La stratégie définit l'action par défaut que la chaîne utilise lorsqu'aucune règle explicite ne correspond. Dans la INPUTchaîne définie sur ACCEPTER tout le trafic.

La première règle de la chaîne INPUT est immédiatement intéressante, elle envoie tout le trafic (source 0.0.0.0/0 et destination 0.0.0.0/0) destiné au port TCP 22 ( tcp dpt:22) le port par défaut pour SSH vers une cible personnalisée ( fail2ban-SSH) . Comme son nom l'indique, cette règle est maintenue par fail2ban (un produit de sécurité qui, entre autres, analyse les fichiers journaux du système pour détecter d'éventuels abus et bloque l'adresse IP de l'agresseur).

Cette règle aurait été créée par une ligne de commande iptables similaire à iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHou se trouve dans la sortie d'iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Vous trouverez souvent l'une de ces notations dans la documentation.

Les compteurs indiquent que cette règle a mis en correspondance 784'000 paquets et 65 mégaoctets de données.

Le trafic correspondant à cette première règle est ensuite traité par la fail2ban-SSHchaîne qui, en tant que chaîne non standard, est répertoriée sous la chaîne OUTPUT.

Cette chaîne se compose de deux règles, une pour chaque abuseur (adresse IP source 117.253.221.166 ou 58.218.211.166) qui est bloquée (avec un reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

Les paquets SSH qui ne proviennent pas de ces hôtes bloqués ne sont pas encore autorisés ni interdits et, maintenant que la chaîne personnalisée est terminée, seront comparés à la deuxième règle de la chaîne INPUT.

Tous les paquets qui n'étaient pas destinés au port 22 ont passé la première règle de la chaîne INPUT et seront également évalués dans la règle INPUT # 2.

La règle INPUT numéro 2 fait que cela est destiné à être un pare-feu d'état , qui suit les connexions. Cela présente certains avantages, seuls les paquets pour les nouvelles connexions doivent être vérifiés par rapport à l'ensemble de règles complet, mais une fois autorisés, les paquets supplémentaires appartenant à une connexion établie ou associée sont acceptés sans vérification supplémentaire.

La règle d'entrée n ° 2 correspond à toutes les connexions ouvertes et connexes et les paquets correspondant à cette règle n'auront pas besoin d'être évalués plus avant.

Remarque: les changements de règles dans la configuration d'un pare-feu avec état n'affecteront que les nouvelles connexions, pas les connexions établies.

En revanche, un simple filtre de paquets teste chaque paquet par rapport à l'ensemble de règles complet, sans suivre l'état de la connexion. Dans un pare-feu pareil, aucun mot clé d' état ne serait utilisé.

La règle INPUT # 3 est assez ennuyeuse, tout le trafic se connectant à l' lointerface de bouclage ( ou 127.0.0.1) est autorisé.

Les règles INPUT 4, 5 et 6 sont utilisées pour ouvrir les ports TCP 22, 80 et 443 (les ports par défaut pour respectivement SSH, HTTP et HTTPS) en accordant l'accès aux NOUVELLES connexions (les connexions existantes sont déjà autorisées par la règle INPUT 2).

Dans un pare-feu sans état, ces règles apparaissent sans les attributs d'état:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

ou

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

La dernière règle INPUT, # 7 est une règle qui bloque tout le trafic auquel l'accès n'a pas été accordé dans les règles INPUT 1-7. Une convention assez courante: tout ce qui n'est pas autorisé est refusé. En théorie, cette règle aurait pu être omise en définissant la POLITIQUE par défaut sur REJETER.

Examinez toujours toute la chaîne.

4. Connaissez votre environnement

4.1. Les paramètres d'un pare-feu logiciel n'affecteront pas les paramètres de sécurité maintenus ailleurs sur le réseau, c'est-à-dire que malgré l'ouverture d'un service réseau avec iptablesles listes de contrôle d'accès non modifiées sur les routeurs ou autres pare-feu de votre réseau, il est possible que le trafic soit bloqué ...

4.2. Si aucun service n'écoute, vous ne pourrez pas vous connecter et obtenir une erreur de connexion refusée , quels que soient les paramètres du pare-feu. Donc:

• Confirmez qu'un service écoute (sur la bonne interface réseau / adresse IP) et utilise les numéros de port que vous attendez [sudo] netstat -plnutou utilisez ss -tnlp.
• Si vos services ne sont pas encore supposés fonctionner, émulez un simple écouteur avec par exemple netcat: [sudo] nc -l -p 123ou openssl s_server -accept 1234 [options] si vous avez besoin d'un écouteur TLS / SSL (vérifiez les man s_serveroptions).
• Vérifiez que vous pouvez vous connecter à partir du serveur lui-même, c'est-à-dire telnet <IP of Server> 123ou echo "Hello" | nc <IP of Server> 123lorsque vous testez le service sécurisé TLS / SSL openssl s_client -connect <IP of Server>:1234, avant d'essayer la même chose à partir d'un hôte distant.

4.3. Comprenez les protocoles utilisés par vos services. Vous ne pouvez pas activer / désactiver correctement les services que vous ne comprenez pas suffisamment. Par exemple:

• TCP ou UDP est-il utilisé ou les deux (comme avec DNS)?
• le service utilise-t-il un port fixe par défaut (par exemple quelque chose comme le port TCP 80 pour un serveur Web)?
• est-il également choisi un numéro de port dynamique qui peut varier (c.-à-d. les services RPC comme le NFS classique qui s'enregistrent avec Portmap)?
• Le fameux FTP utilise même deux ports , à la fois un numéro de port fixe et un numéro de port dynamique lorsqu'il est configuré pour utiliser le mode passif ...
• les descriptions de service, de port et de protocole /etc/servicesne correspondent pas nécessairement au service réel utilisant un port.

4.4. Le filtre de paquets du noyau n'est pas la seule chose qui peut restreindre la connectivité réseau:

• SELinux peut également restreindre les services réseau. getenforceconfirmera si SELinux est en cours d'exécution.
• Bien qu'ils deviennent légèrement obscurs, les enveloppeurs TCP restent un outil puissant pour renforcer la sécurité du réseau. Vérifiez avec ldd /path/to/service |grep libwrapet les /hosts.[allow|deny]fichiers de contrôle.

5. INPUTou FORWARDchaînes

Le concept de chaînes est expliqué plus en détail ici, mais en bref:

La INPUTchaîne est l'endroit où vous ouvrez et / ou fermez les ports réseau pour les services s'exécutant localement, sur l'hôte où vous émettez les commandes iptables.

La FORWARDchaîne est l'endroit où vous appliquez des règles pour filtrer le trafic qui est transféré par le noyau vers d'autres systèmes, des systèmes réels mais aussi des conteneurs Docker et des serveurs Virtual Guest Servers lorsque votre machine Linux agit comme un pont, un routeur, un hyperviseur et / ou fait une adresse réseau traduction et redirection de port.

Une idée fausse courante est que, comme un conteneur Docker ou un invité KVM s'exécute localement, les règles de filtrage qui s'appliquent devraient se trouver dans la chaîne INPUT, mais ce n'est généralement pas le cas.

6. Modules du noyau

Étant donné que le filtre de paquets s'exécute dans le noyau Linux, il peut également être compilé en tant que module dynamique, plusieurs modules en fait. La plupart des distributions incluent Netfilter en tant que modules et les modules Netfilter requis seront chargés dans le noyau selon les besoins, mais pour certains modules, un administrateur de pare-feu devra s'assurer manuellement qu'ils sont chargés. Cela concerne principalement les modules de suivi des connexions, tels que ceux nf_conntrack_ftpqui peuvent être chargés insmod.

Les modules actuellement chargés dans le noyau en cours d'exécution peuvent être affichés avec lsmod.

La méthode permettant de s'assurer que les modules sont chargés de manière persistante lors des redémarrages dépend de la distribution Linux.

Problèmes courants avec différents protocoles

DNS: DNS utilise le port 53 UDP par défaut, mais les messages qui ne rentrent pas dans un seul datagramme UDP seront transmis à la place via TCP (généralement les transferts de zone, etc.), ce qui nécessite l'ouverture du port 53 TCP également lorsque vous exécutez un serveur de noms. .

Courriel: de nombreux FAI consommateurs bloquent le trafic SMTP (ou au moins le port par défaut TCP 25), ce qui rend impossible la réception ou l'envoi directs de courriels et leurs clients sont obligés d'utiliser le relais SMTP du FAI pour tous les courriels sortants et parfois pour les courriels entrants également. . Concerne le §1.1.

FTP: FTP est un protocole étrange dans la mesure où deux connexions sont utilisées. Le premier est la connexion de contrôle, par défaut un serveur FTP écoutera cela sur le port TCP 21. La connexion de contrôle est utilisée pour l'authentification et l'émission de commandes. Les transferts de fichiers réels et des choses telles que la sortie d'une liste de répertoires passent par une deuxième connexion TCP, la connexion DATA. Dans le FTP actif, cette connexion DONNÉES sera établie à partir du serveur FTP à partir du port TCP 20 et se connectera au client FTP. Le FTP actif ne fonctionne pas trop bien avec les utilisateurs derrière les pare-feu et les passerelles NAT, il est donc principalement tombé en désuétude. La plupart des serveurs FTP prennent en charge le FTP passif à la place. Avec FTP passif, le serveur FTP ouvre un écouteur pour la connexion DATA sur un second port, auquel le client FTP peut alors se connecter. Le problème pour un pare-feu est que le port DATA peut être n'importe quel port non privilégié disponible entre 1024-65536.

Dans un pare-feu sans état qui est généralement résolu en limitant le nombre de ports passifs que le serveur FTP peut affecter, puis en ouvrant explicitement ces ports. c'est à dire

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

Dans un pare-feu avec état, vous n'avez pas besoin d'ouvrir explicitement le port DATA, le module d'assistance netfilter reconnaît le port dynamique qui est attribué et ouvre dynamiquement ce port pour le client correct en marquant la connexion DATA comme RELATEDaprès quoi il correspondra à la règle générique :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Cela nécessite que le module de noyau correct soit chargé, dans le cas FTP manuellement en exécutant par exemple insmod nf_conntrack_ftp, ce qui fait que la persistance dépend du redémarrage dépend de la distribution.

Remarque: Le module de suivi de connexion FTP échouera lorsque FTP est utilisé avec SSL, car la connexion de contrôle sera cryptée et le nf_conntrack_ftp ne pourra plus lire la répétition PASV.

NFS et services RPC similaires : Le problème avec les services RPC est que, par conception, ils n'utilisent pas de port fixe spécifique. Ils peuvent choisir n'importe quel port disponible au hasard, qui sera ensuite enregistré avec le démon RPC Portmap. Un client essayant de se connecter interrogera le démon Portmap, puis se connectera directement au port approprié. Cela a résolu le problème de manquer de ports réservés ...

Du point de vue du pare-feu, le port TCP / UDP 111 doit être ouvert et le port réel que le service RPC utilise actuellement. Le problème de l'ouverture d'un tel port aléatoire dans un pare-feu est généralement résolu en restreignant le service RPC, tel que le serveur NFS, à utiliser un port fixe prédéfini.

Iptables / Firewall "introduction"

Un pare-feu est essentiellement un filtre réseau basé sur des règles. Les pare-feu Linux sont construits autour de Netfilter; le framework de traitement de paquets réseau du noyau qui est composé de plusieurs modules du noyau effectuant des tâches spécifiques:

1. Le module FILTER (toujours chargé par défaut) nous permet principalement d'accepter ou de supprimer des paquets IP en fonction d'un certain critère de correspondance.
2. L'ensemble de modules NAT nous permet d'effectuer des traductions d'adresses réseau (SNAT, DNAT, MASQUERADE).
3. Le module MANGLE nous permet de modifier certains champs de paquets IP (TOS, TTL).

Les utilisateurs configurent le framework Netfilter pour répondre à leurs besoins de pare-feu en utilisant iptables à partir de la ligne de commande. Avec iptables, nous définissons des règles qui indiquent au noyau ce qu'il doit faire des paquets IP lorsqu'ils arrivent, passent ou quittent notre boîte Linux. Chaque processus principal de Netfilter est représenté par une TABLE (FILTER, NAT, MANGLE) sur le jargon iptables. Ils ont plusieurs points de raccordement spécifiques sur la carte de flux de paquets réseau où ils sont invoqués par le noyau pour effectuer leurs tâches. Certaines séquences d'appels TABLE localisées spécifiquement sont génériquement appelées CHAINES intégrées recevant les noms PREROUTING, INPUT, FORWARD, OUTPUT et POSTROUTING. Il est facile de se souvenir si nous associons une TABLE à un "type de processus" et une CHAINE à "l'emplacement" sur la carte de flux de paquets réseau où les instances de ces processus sont appelées.

Puisqu'un paquet IP est reçu sur une interface réseau, ou créé par un processus local, jusqu'à ce qu'il soit finalement livré ou jeté, le moteur Netfilter testera et appliquera séquentiellement les règles contenues le long de la carte de flux de paquets réseau. À chaque bloc identifié par une paire TABLE @ CHAIN, l'utilisateur peut ajouter une ou plusieurs de ces règles consécutives contenant un critère de correspondance de paquet IP et un plan d'action correspondant. Il y a des actions (ie ACCEPT, DROP, etc.) qui peuvent être exécutées par plus d'une TABLE et d'autres actions (ie SNAT, DNAT, etc.) qui sont spécifiques à TABLE.

c'est-à-dire lorsqu'un paquet IP arrive d'une interface réseau, il est d'abord traité par la chaîne PREROUTING en invoquant les règles définies par l'utilisateur de la table MANGLE le cas échéant. S'il n'y a pas de règles qui correspondent au paquet actuel, le plan d'action ou la "politique" par défaut MANGLE @ PREROUTING correspondant s'applique. À ce stade, si le paquet n'a pas été abandonné, le processus continuera maintenant à appeler les règles de la table NAT au niveau de la chaîne PREROUTING (voir la carte) et ainsi de suite. Afin de faciliter la disposition des règles, les utilisateurs peuvent également créer leurs propres chaînes personnalisées et «sauter» à partir de différents points de la carte comme ils le souhaitent.

Alors que les chaînes intégrées peuvent avoir des politiques définies par l'utilisateur de paquets ACCEPT ou DROP, les chaînes définies par l'utilisateur ont toujours une politique par défaut inchangeable de RETOUR à l'appelant pour continuer le processus.

Commandes Iptables

Les commandes principales d'iptables remplissent la carte de flux de paquets réseau avec les règles de traitement requises.

La règle générique iptables peut s'écrire:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Cela pourrait être lu comme:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Les commandes auxiliaires iptables complètent le scénario définissant les conditoins par défaut, les règles de listage, les règles de vidage, etc.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables charge nos commandes dans le moteur Netfilter au moment de l'exécution, Netfilter applique immédiatement les règles et les paramètres chargés mais ils ne sont pas persistants. Après le redémarrage, toutes les règles et tous les paramètres Netfilter précédemment chargés seront perdus. Pour cette raison, il existe des utilitaires iptables qui permettent d'enregistrer l'ensemble de règles actuellement actif dans un fichier et de le recharger ultérieurement.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Résumé Iptables

Netfilter est un framework extrêmement flexible et puissant mais il y a un prix à payer pour cela; Iptables est complexe. D'un point de vue utilisateur, certains termes comme TABLE, CHAINE, CIBLE ne correspondent pas vraiment très bien au concept qu'ils représentent et n'ont pas beaucoup de sens au premier abord. Le sujet est long, les commandes semblent avoir une liste interminable de paramètres. Pour aggraver les choses, il n'y a pas un seul livre qui maîtrise vraiment Iptables. Ils se répartissent principalement en deux catégories: "livre de recettes" ou "livre de pages de manuel". Je pense que cette introduction vous donne un aperçu du paysage Netfilter / Iptables ainsi que la dose nécessaire de pages de manuel pré-digérées. Si vous êtes nouveau chez iptables, après avoir lu ces paragraphes plusieurs fois, vous serez prêt à lire des exemples d'iptables. Avec un peu de pratique, vous vous retrouverez bientôt à écrire vos propres règles.

Pare-feu

Un pare-feu est principalement conçu pour autoriser ou refuser dynamiquement le trafic réseau en fonction d'un ensemble de règles. À ce stade, il est facile de comprendre pourquoi le cadre Linux Netfilter / Iptables est parfait pour la construction de pare-feu. En regardant la carte de flux de paquets réseau, nous trouvons deux endroits particulièrement intéressants sur la table FILTER au niveau des chaînes INPUT et FORWARD; Nous pouvons y décider de l'adresse IP source, du protocole IP (UDP / TCP), du port de destination (80, 21, 443, etc.), etc. C'est ce que fait un pare-feu 80% du temps lorsqu'il protège un serveur Web contre les demandes réseau non autorisées. Les 20% restants manipulent (NAT, MANGLE) les paquets réseau.

Scénarios de pare-feu

Il existe des centaines de configurations de pare-feu différentes répondant à des besoins différents, mais 3 d'entre elles pourraient être considérées comme les scénarios de pare-feu les plus typiques.

1. Serveur Web simple avec une ou plusieurs interfaces connectées à Internet. La stratégie comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant non restreint et des règles anti-usurpation. Le transfert IP est désactivé.
2. Ce pare-feu se connecte à Internet et à une zone interne protégée. La stratégie comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant non restreint et des règles anti-usurpation. Étant donné que la zone protégée utilise des adresses IP privées, le NAT source est nécessaire. Le transfert IP est activé.
3. Ce pare-feu se connecte à Internet, à une zone interne protégée et démilitarisée. La politique comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant non restreint et des règles anti-usurpation. Étant donné que les zones protégées et DMZ utilisent des adresses IP privées, elles ont besoin du NAT source et de destination. Le transfert IP est activé.

J'ai écrit ceci pour: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html