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
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'.
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.
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.
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.
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).
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
Toutes les tables disponibles sont listées avec la commande :
cat /proc/net/ip_tables_names
Bug connu. Veuillez mettre à jour avec le dernier CVS ou utilisez iptables >= 1.2.1
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.
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).
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
httpd_accel_single_host off
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".
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.
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
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.
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.