Page suivante Page précédente Table des matières

3. Problèmes au lancement.

3.1 `NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb'

Ce message est affiché par le code de NAT parce que des paquets multicast atteignent la table de NAT, et que le code de suivi de connexion ne gère pas actuellement les paquets multicast. Si vous n'avez aucune idée de ce qu'est le multicast ou si vous n'en avez pas besoin, utilisez :

iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8

3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Syslog ou ma console affiche le message :

NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Ce message est affiché par le code de NAT. Il détruit le paquet, parce que pour pouvoir mener à bien la NAT, NAT a besoin d'avoir un paquet ayant des infos valides de suivi de connexions. Ce message est affiché pour chaque paquet dont le code de suivi de connexions ne permet pas de déterminer les informations de suivi.

Les raisons possibles sont :

Si vous voulez avoir plus de détails pendant le log de ces paquets (si vous suspectez que ce sont des paquets de scanners), utilisez la règle suivante :

iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

Et oui! Vous devez mettre cette règle dans la table `mangle', parce que le paquet sera détruit par le code de NAT avant qu'il ne parvienne dans la table `filter'.

3.3 Je n'arrive pas à utiliser netfilter avec le code de Bridging.

Donc vous voulez construire un firewall totalement transparent ? Bonne idée ! A partir du noyau 2.4.16, vous avez toujours besoin de patcher votre noyau pour que ça marche. Vous le trouverez sur la page web du projet suivant.

3.4 Le module IRC est incapable de gérer le DCC RESUME.

Et bien... c'est à moitié vrai. Seul le module de NAT est incapable de les gérer. Si vous utilisez le firewall seul, donc sans NAT, ça devrait marcher impeccablement.

3.5 Comment fonctionne SNAT vers plusieurs adresses ?

Netfilter essaye de modifier les paquets aussi peu que possible. Donc si vous avez une machine fraîchement redémarrée, et que quelqu'un derrière la NAT ouvre une connexion avec un port local 1234, la partie netfilter modifie seulement l'adresse IP et ne touche pas au numéro de port.

Aussitôt que quelqu'un d'autre ouvre une autre connexion avec le même port source, netfilter devra modifier l'adresse IP et le numéro de port si il y a seulement une IP pour la SNAT.

Mais s'il y en plus d'une disponible, alors encore une fois netfilter ne changera que l'adresse IP.

3.6 ip_conntrack: maximum limit of XXX entries exceeded

Si vous voyez ce message d'erreur dans votre syslog, ça veut dire que le code de suivi de connexions ne dispose plus d'assez de place pour ajouter une entrée. Le code de suivi de connexions gère par défaut jusqu'à 4096 connexions simultanées en général, mais cela dépend de la RAM que vous avez. Pour augmenter cette limite, tapez par exemple:

echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max

Bien sur, vous pouvez utiliser n'importe quel nombre qui rentre dans un `int' sur votre hardware (c'est à dire 32 bits pour la plupart des plates-formes). Veuillez noter que chaque connexion suivie peut avoir besoin d'un certain montant de mémoire noyau non-swappable (  500 octets par connexion, pour vous donnez un ordre d'idée).

3.7 Comment puis-je lister toutes les connexions suivies/masqueradées, l'équivalent de `ipchains -L -M', qu'on utilisait dans les 2.2 ?

Il y à un fichier dans le système de fichiers `/proc' qui s'appelle /proc/net/ip_conntrack. Et voila :

cat /proc/net/ip_conntrack

3.8 Comment puis-je lister toutes les tables disponibles ?

Toutes les tables disponibles sont listées avec la commande :

cat /proc/net/ip_tables_names

3.9 iptables-save / iptables-restore de iptables-1.2 génère un segfault.

Bug connu. Veuillez mettre à jour avec le dernier CVS ou utilisez iptables >= 1.2.1

3.10 `iptables -L' prend beaucoup de temps pour afficher les règles.

C'est parce que iptables résout les adresses IP avec le DNS, et fait une requête au DNS pour chaque adresse. Comme chaque règle consiste en deux adresses IP, le pire des cas revient à deux requêtes par règle.

Le problème est que, si vous utilisez des adresses IP privées (comme 10.x.x.x ou 192.168.x.x), DNS est incapable de résoudre le nom d'hôte et va faire un timeout. La somme de tous ces timeouts peut être extrêmement long, selon votre ensemble de règles.

Utilisez l'option `-n' (numérique) avec iptables pour éviter qu'il ne tente de résoudre les adresses IP.

3.11 Comment faire pour que la target LOG arrête d'envoyer vers la console ?

Vous devez configurer votre syslogd/klogd correctement : La target LOG enregistre en utilisant le canal `kernel' à la priorité `warning' (4). Voir la page man de syslogd.conf pour en apprendre plus sur les canaux et les priorités.

Par défaut, tous les messages du noyau, ayant une sévérité supérieure à `debug' (7), sont envoyés sur la console. Si vous le montez à 4, à la place de 7, ça fera que les messages de la target LOG ne seront plus affichés sur la console.

Gardez à l'esprit que ça peut aussi empêcher d'autres messages importants d'apparaître sur la console (ça n'affecte pas syslog).

3.12 Comment construire un proxy transparent avec squid et iptables ?

D'abord, bien sûr, vous avez besoin d'une règle DNAT ou REDIRECT qui fonctionne. Utilisez REDIRECT seulement si squid tourne sur la même machine que la machine qui fait NAT. Exemple :

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128

Après ça, vous devez configurer squid correctement. Nous ne pouvons donner que des exemples courts ici, allez voir la doc de squid pour plus d'infos.

Le fichier squid.conf pour squid 2.3 a besoin de quelque chose comme ça :

http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Squid 2.4 a besoin d'une ligne additionnelle :
httpd_accel_single_host off

3.13 Comment dois-je utiliser la cible LOG / comment LOGuer et DROPper ?

La target LOG est ce qu'on appelle une target "non terminale", en effet, elle ne stoppe pas la traversée des paquets. Si vous utilisez la target LOG, le paquet sera enregistré, et la traversée des règles continuera à la règle suivante.

Comment dois-je faire pour LOGuer et DROPper en même temps ? Rien de plus simple, créez une chaîne custom avec deux règles :

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Maintenant, à chaque fois que vous voulez LOGuer et DROPper un paquet, vous pouvez utiliser simplement "-j logdrop".

3.14 Comment faire pour arrêter le vers (`worm') XYX avec netfilter ?

La réponse courte est que vous ne pouvez pas faire ça correctement avec netfilter. La plupart des vers utilisent des protocoles de haut niveau tout à fait légitimes (ex: HTTP, SMTP (ex: un script VB attaché au courrier), ou n'importe quel exploit d'une vulnérabilité qui se trouve dans un démon qui gère un protocole de haut niveau). Par protocole de haut niveau, on entend ici un protocole qui se trouve au dessus de TCP ou IP. Comme iptables ne comprend pas ces protocoles, il est presque impossible de filtrer une partie de ces protocoles. Pour ça, vous devez utiliser un proxy filtrant.

N'utilisez pas la target string disponible dans patch-o-matic à la place d'un proxy filtrant. Ça serait attaquable en permanence avec des paquets fragmentés (ex: une requête HTTP qui est à cheval sur deux paquets TCP), par des techniques d'évasion d'IDS, etc... La target string est utile, mais pour d'autres buts.

3.15 Logs noyaux: `Out of window data xxx'

Vous utilisez le patch tcp-window-tracking de patch-o-matic, qui s'occupe de garder trace des paquets acceptables pour les flux TCP autorisés, par rapport au numéro de séquence/accusé de réception, taille de segments, etc... des paquets. Si il détecte qu'un paquet n'est pas acceptable (`out of the window': en dehors de la fenêtre/fourchette), il le marque invalide et affiche le message de dessus.

Les nouvelles versions enregistrent le paquet et la raison exacte du problème.

De plus, dans les nouvelles version, le log peut être totalement supprimé via sysctl :

echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window

3.16 Pourquoi le code de suivi de connexions suit les connexions marquées UNREPLIED avec un timeout très long ?

Donc vous avez lu et analysé `/proc/net/ip_contrack' et trouvé des entrées UNREPLIED avec un timer très élevé (il peut monter jusqu'à 5 jours), et vous vous demandiez pourquoi gâcher des entrées avec des connexions UNREPLIED (qui ne sont naturellement pas des connexions) ?

La réponse est simple: les entrées UNREPLIED sont des entrées temporaires, c'est-à-dire que dès que l'on n'a plus d'entrées de suivi de connexion de libre, c'est-à-dire que l'on atteint `/proc/sys/net/ipv4/ip_conntrack_max', alors on va effacer quelques vielles entrées UNREPLIED. C'est-à-dire que plutôt que d'avoir des entrées de suivi de connexions vides, on préfère garder des informations qui peuvent de temps en temps être utiles.

3.17 Pourquoi l'option `iptables -C' (--check) n'est-elle pas implémentée ?

Bon, d'abord, on est fainéant ;-) Pour être honnête, implémenter une option de vérification est pratiquement impossible dés que l'on commence à faire du `stateful' firewalling. Le traditionnel `stateless firewalling' base ses décisions juste sur les informations présentes dans l'entête du paquet. Mais le suivi de connexions (et les règles basées sur `-m state'), les résultat du filtrage dépendent de l'en-tête et du contenu du paquet, et aussi de l'en-tête et du contenu des paquets précédents, à l'intérieur de cette connexion.


Page suivante Page précédente Table des matières