NdM : Un grand merci à switcher pour son journal dont est tiré la dépêche. Les défauts d'iptables
Pour l'utilisateur lambda, iptables est relativement simple à utiliser. Il faut, certes, en comprendre l'architecture pour écrire des règles efficaces, et cela peut prendre du temps, mais les limitations en terme de performances ne se feront pas vraiment sentir. Au sein d'une infrastructure où l'on peut avoir plusieurs milliers de règles, le tout enregistré dans syslog, avec des ajouts et suppressions plus ou moins réguliers, la difficulté est tout autre.
Mac Hardy a listé ces limitations lors de sa présentation en septembre dernier lors du Netfilter Workshop 2008 qui s'est déroulé à Paris :
- le noyau et l'espace utilisateur sont intimement liés, les modules doivent être implémentés des deux cotés (avec une relation 1:1), les structures doivent rester identiques car dumpés dans les deux sens ;
- dans le noyau, un jeu de règle est un seul blob qui doit être déchargé et rechargé complètement à chaque ajout/suppression de règle. Quand il y en a 5000, ça calme : pour l'ajout d'une règle, iptables (en espace utilisateur) réalise un dump complet des règles dans le noyau, insère la nouvelle et renvoie le dump complet au kernel. Le noyau perd alors les états entre les anciennes règles et les nouvelles.
- le code est sale : 138 modules dans le 2.6.26, pas tous compatibles 64 bits, beaucoup de fonctions de matching qui font la même chose.
La ré-écriture
Bref, c'est pas propre. Mieux vaut tout remettre à plat, en conservant ce qui est bon et en prenant en compte les desideratas des utilisateurs. C'est ce qui a été présenté en septembre dernier et l'annonce de version de la semaine dernière marquent la fin de cette première étape de développement.
Dans le noyau
nftables est d'abord une modification du noyau pour éviter les pépins qu'a amené iptables. On revient donc à une règle de base : le noyau est idiot ! Il fait ce qu'on lui dit et ne réfléchit pas d'ailleurs, il n'a pas le temps de réfléchir car il a trop de travail a coté.
Donc, le noyau, Mac Hardy veut qu'il en fasse le moins possible pour pouvoir le faire le plus vite possible. Le comptage des paquets et des octets deviennent optionnels, les tables sont créées en espace utilisateur (sauf la table NAT), etc.
Après, on ajoute de la flexibilité. Beaucoup de flexibilité : le matching peut pointer vers plusieurs cibles (log et drop, par exemple) dans la même règle. Plus besoin de bricoler les JUMP pour faire du LOG avec le DROP. On aura une règle simple du type :
# nft add rule output tcp dport 22 log accept
pour accepter les paquets sortant vers le port SSH tout en loguant.
Autre avancée : le support des ensembles (comme le fait ipset) et des dictionnaires pour matcher plusieurs ensembles dans une seule règle. L'exemple qui illustre le mieux cette nouvelle fonctionnalité est la gestion de plusieurs réseaux dans une règle :
ip daddr { 192.168.0.0/24 => drop, 192.168.0.100 => accept}
Ci-dessus, on voit que l'accept a lieu sur une IP unique, alors que son domaine d'appartenance est en DROP. Ceci est désormais possible car la règle du « plus précis gagne » est appliquée sur les ensembles. Comme en routage BGP.
La représentation des données dans le noyau a également changée, afin de la rendre plus générique. Il est donc possible d'utiliser n'importe quelle fonction de matching avec n'importe quelle donnée. La correspondance "n" match sur "n" données ayant disparue, les possibilités de filtrages vont rapidement exploser.
Et enfin, la grosse fonctionnalité de nftables est le commit incrémental des règles qui évite de balancer un blob de 4000 règles entre l'espace utilisateur et le noyau dès que la règles 832 change !
Lors des Netfilter User Day, Jesper Brouer avait montré que le listing de 50 000 chaines prenait environ 5 minutes ! (et il a écrit un patch pour corriger cela). Désormais, avec nftables, ce problème ne devrait plus se produire.
(Happy) User-land
Mais tout cela, c'est pour les utilisateurs avancés, ce qui intéresse la majorité des utilisateurs c'est l'interface ! La nouvelle interface s'appelle justement nftables, et elle a été complètement refondue. Fini la syntaxe « iptables -A INPUT -t superinput -p tcp --sport emule -j ACCEPT », maintenant, il faudra faire du « nft add rule input tcp sport emule accept ».
Aussi, la nouvelle langue de nftables (qui utilise bison) vient avec une boîte à outils complète de vérification sémantique. L'intérêt ? C'est de pouvoir valider toutes les règles avant de les passer au noyau, mais aussi de pointer les erreurs. Et comme rien ne vaut un exemple...
- conflict detection:
... ip protocol tcp udp dport 53
results in:
:1:37-45: Error: conflicting protocols specified: tcp vs. udp
add filter output ip protocol tcp udp dport 53
^^^^^^^^^
... ip6 filter output ip daddr 192.168.0.1
:1:19-26: Error: conflicting protocols specified: ip6 vs. ip
ip6 filter output ip daddr 192.168.0.1
^^^^^^^^
(exemple extrait de l'annonce de Mac Hardy)
De fait, le débogage des règles devrait en être facilité. Mais en fait, pour les administrateurs, c'est un véritable cadeau empoisonné car il faudra tout réapprendre. À en lire le mail de Mac Hardy, rien n'a été conservé ! Pfiou !
Mais au final
Tout cela regorge de fonctionnalités qui se montrent plus excitantes les unes que les autres. Avec le temps viendront des fonctionnalités pour contrôler TC (Traffic Control) depuis nftables, ou encore l'ajout de nouvelles possibilités de matching, venant des U32 ou d'ailleurs.
Historique
La première implémentation de parefeu Linux s'appellait ipfwadm. ipchain l'a remplacé dans Linux 2.2. Linux 2.4 aura vu apparaitre iptables. nftables sera donc la 4e génération de parefeu pour Linux 2.6.
Hors série Linux Magazine dédié à Netfilter
Une interview de Patrick Mac Hardy (et d'autres développeurs majeur de Netfilter), un compte rendu du Netfilter Workshop 2008, ainsi que de nombreux articles sur les développements en cours dans Netfilter sont disponibles dans le dernier Hors Série (n°41) de GNU/Linux Magazine.
Aller plus loin
- Annonce de Mac Hardy : First release of nftables (79 clics)
- Netfitler Workshop 2008 (26 clics)
- Hors Série Linux Magazine n°41 dédié à Netfilter (320 clics)
- Journal à l'origine de la dépêche (56 clics)
# bonne dépêche
Posté par Bourdieu . Évalué à 4.
# Attention, jargon
Posté par lrbabe . Évalué à 4.
Je la garde précieusement celle là. Merci
[^] # Re: Attention, jargon
Posté par e-t172 (site web personnel) . Évalué à -2.
LOG
This is a "non-terminating target", i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).
Source : iptables(8).
[^] # Re: Attention, jargon
Posté par Eric Leblond (site web personnel) . Évalué à 7.
La problématique d'iptables est qu'une des actions les plus fréquentes et de journaliser (target *LOG) puis bloquer ce même paquet (target DROP). Comme les règles *LOG ne sont pas terminales, il est nécessaire d'utiliser deux règles pour fixer cela (une LOG suivi d'une DROP). On a donc deux fois plus de règles que nécessaire.
Une méthode de contournement consiste à créer une chaine utilisateur LOGDROP qui journalise puis bloque les paquets. On utilise alors -j LOGDROP (-j pour JUMP) pour journaliser et bloquer les paquets en une seule règle.
En permettant l'utilisation de plusieurs targets dans une même règle, nftables simplifie cela.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Attention, jargon
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Si tu veux loguer le traffic que tu acceptes pour des raisons légales, vérifier le bon fonctionnement de ton réseau, etc., hé bien tu dois dupliquer chaque règle iptables :
iptables (... beaucoup d'arguments....) -j NFLOG (... paramètres de log ...)
iptables (... beaucoup d'arguments....) -A ACCEPT
Niveau performance, c'est très pénalisant car Netfilter est très sensible au nombre de règles étant donné qu'il les teste séquentiellement !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Attention, jargon
Posté par jve (site web personnel) . Évalué à 3.
Un firewall sous Netfilter peux tout loguer, du moment que tu fait ca intelligemment :
1. syslog peux manger des lignes de logs plus vite que tu ne pourra jamais lui en fournir, et niveau I/O je doute que ton noyau ou ton disque soit saturés avant ta carte réseau
2. Les DROP, ca se logs par connexions, ou par paquets si ya pas de connexions. Pour ca, tu met pas de politique par défaut car elle ne permet pas de loguer. Par contre tu peux mettre ca a la fin de tes règles :
echo "Default log drop, at the end so we just drop what doesn't match the previous rules"
iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
iptables -A LOGDROP -j DROP
iptables -A INPUT -i eth0 -j LOGDROP
iptables -A OUTPUT -o eth0 -j LOGDROP
3. Les accepts, ca se log aussi. Mais pas tout, juste les etablissements de connexions. La plupart des protocoles sur TCP garde une seule connexion TCP ouverte (sauf HTTP sans le keep alive). De fait, tu aura que peux de logs pour les accepts en comparaison du nombre de paquets.
Bon, ca peux quand meme faire quelques gigas, mais quels machines n'a pas 40 gigas de disques aujourd'hui ? Et puis, pas besoin de garder les logs pendant 30 jours, si tu n'a pas vu l'attaque passer dans la semaine, alors il faut changer de métiers ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Attention, jargon
Posté par jve (site web personnel) . Évalué à 1.
Pas tenu la charge ? Il me semble avoir vu des résultats de Bench pour syslog qui allaient largement au dessus de ces valeurs.
Après, les questions d'espace disque sont indépendantes des capacités du système. C'est sur que si tu souhaite tout loguer sur une connexion 10Gbits, vaut mieux avoir un gros RAID5 de plusieurs tera sous la main.
Concernant le déni de service, je vois pas trop comment ca peux arriver... a moins que tu décide de mettre du swap sur un firewall, mais le je comprend pas l'intérêt.
Ha ba non alors, si on dit la même chose, tout va bien :)
# Patrick Mc Hardy présentera nftables aux RMLL 2009 de Nantes
Posté par Christophe Brocas . Évalué à 6.
Patrick Mc Hardy devrait y présenter nftables. Eric Leblond, contributeur Netfilter, y présentera aussi uLogd2, sous-projet de netfilter, dont il est le responsable.
# syntaxe similaire à pf
Posté par TeXitoi (site web personnel) . Évalué à 7.
# nft add rule output tcp dport 22 log accept
contre
pass in log proto tcp port ssh
Bon, ça va, pf est toujours mieux, mais bon, il y a de l'amélioration... ;-)
[^] # Re: syntaxe similaire à pf
Posté par Dup (site web personnel) . Évalué à 6.
De plus tu compares une règles pf lu dans un fichier à une règle nftable lancée depuis la ligne de commande (je suppose que le add rule devient inutile si on parle de fichier de conf)
Bref pf peut être un poil meilleur mais faut pas cracher sur nftable alors qu'il n'est pas encore sorti.
[^] # Re: syntaxe similaire à pf
Posté par tinou . Évalué à 3.
Il y a quand même (au moins) un truc qu'on peut dire avant que nftable soit sorti: Sur le même projet, par les mêmes auteurs ou presque, c'est la deuxième ré-écriture de la fonction de filtrage de paquets dans le noyau Linux. On avait ipchains, qui a été réécrit pour donner iptables, qui vient lui-même d'être réécrit pour donner nftable.
Ca soulève quand même la question de savoir pourquoi on a encore besoin de le ré-écrire, et ça nécessite d'apprendre une nouvelle syntaxe. Pas dramatique, mais un peu pénible.
(Je pourrais aussi parler de ipfwadm, mais je ne sais pas s'il s'agissait des mêmes auteurs)
[^] # Re: syntaxe similaire à pf
Posté par barmic . Évalué à 2.
Je n'affirme pas que PF est moins bon que NF mais qu'ils s'équivales relativement bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: syntaxe similaire à pf
Posté par TeXitoi (site web personnel) . Évalué à 1.
http://www.openbsd.org/faq/pf/fr/authpf.html
[^] # Re: syntaxe similaire à pf
Posté par bubar🦥 (Mastodon) . Évalué à 4.
pour rappel NuFW est capable de faire (de la conf de) du filtrage sur ip, mais aussi sur utilisateur. Ici AuthPF fait de même avec un fonctionnement "similaire" (tousss) dans la mesure ou le firewall n' est pas capable d' être autonomne : dans le cas de AuthPF il faut modifier les shell de connections des suers, dans le cas de NuFW il faut installer un client. Bref là ça se ressemble un peu fortement : aucune autonomie du firewall.
Mais NuFW fait aussi du filtrage sur Applications (tiens faudrait jeter un oeil à la gestion de groupe de process par nufw juste pour la culture).
NuFW est également capable de travailler en collaboration avec un ids (prélude par exemple).
Egalement capable de souplesse quant à l' authentifiaciton (pam mais pas seulement : ldap ...)
Références :
http://www.nufw.org/docs/references22/index.html
Cordialement.
ps : pour palier à ce (gros, quant même) problème de la nécessité d' un client NuFW, viviement qu' une distribution l' intègre totalement en toute transparence... Et d' ailleurs, pourquoi le client Nufw n' est il toujours pas intrinsèquement lié au système ?
En fait ça marche dans les 2 sens : que le firewall soit plus intégré côté noyau (et nftables : y a t il une intégration prévue pour nufw?) et que le client soit plus intégré côté système.
Je ne plaide pas spécialement pour nufw, ce sont juste des remarques à 2 cents...
[^] # Re: syntaxe similaire à pf
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: syntaxe similaire à pf
Posté par Victor STINNER (site web personnel) . Évalué à 3.
aucune autonomie du firewall
On ne peut pas garantir l'authenticité (l'auteur) des connexions sans modifier le poste client. Un portail captif est une grosse blague par exemple : il réduit un utilisateur à son IP : emprunter son IP (c'est facile) suffit pour récupérer ses autorisations.
(...) client NuFW, viviement qu' une distribution l' intègre totalement en toute transparence
NuFW est intégré à plusieurs distributions comme Debian (et ses dérivés) et Mandriva. Il existe deux clients Linux : nutcpc (ligne de commande) et pam_nufw (lancé par PAM). Le second est transparent pour l'utilisateur : il est lancé en tâche de fond lorsque l'utilisateur se connecte (PAM : login, su, sudo, ssh, ...), puis quitte lorsque l'utilisateur se déconnecte. Le client Windows fonctionne de la même manière.
[^] # Re: syntaxe similaire à pf
Posté par Misc (site web personnel) . Évalué à 4.
Actuellement, pour mettre pam_nufw, faut avoir le même mot de passe sur le firewall et sur sa machine, ce qui implique donc de devoir déployer un ldap en général, en plus d'avoir du mettre nuauth ( à configurer à la main ), et d'avoir mis un nufw, qui lui même implique d'avoir une console de gestion apache avec mod_php.
Et il faut aussi se taper à la main l'import des users dans le ldap, se taper à la main la config de pam pour pam_nufw.
Alors que des solutions d'intégrations directes dans ldap existe ( au moins chez redhat, novell, et mandriva, et sans doute chez ubuntu, j'ai pas vérifié ), il n'y a rien du tout pour l'intégration rapide de nufw ( même si rh a regardé de ce coté il y a un an ).
Donc non, je pense que nufw n'est pas (encore) intégré dans les produits libres connus, en dehors du livecd de démonstration.
[^] # Re: syntaxe similaire à pf
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Et il ne s' agit pas seulement d' une intégration "paquet installé par défaut et pré-configuré" mais bien d' arrêter cette notion de couche : une couche au dessus de netfilter, et une couche au dessus de l' utilisateur. Que la partie firewall soit intégré directement à NFtables, et de l' autre côté que le client soit un module pam_ (sur lequel s' ajoute une authentification pam/ldap/etcetc, c est autre chose. Avec une pré-configuration c' est le bonheur, et avec des pré-scénarios de fonctionnements, alors là c' est le nirvana. Mais "plus simplement" pas une pré-conf mais (au moins avant...) une intégration système et pas ces sur-couches)
Ca serait plus que pas mal qu' il puisse devenir plus qu' un complément : une pièce 'mainline'.
Bon désolé d' être intervenu sur un sujet aussi technique et aussi particulier; j' espère pas avoir trop fait baisser le niveau des commentaires, et j' espère surtout ne pas avoir refroidi ceux souhaitant balancer des commentaires documentés et argumentés. Merci d' avoir pris le temps de répondre. Au plaisir de vous lire. A+
[^] # Re: syntaxe similaire à pf
Posté par TeXitoi (site web personnel) . Évalué à 2.
authpf-noip :
http://www.openbsd.org/cgi-bin/man.cgi?query=authpf-noip
http://undeadly.org/cgi?action=article&sid=2008032414100(...)
# netfilter dans tout ça ?
Posté par barmic . Évalué à 2.
Qu'adevient-il de netfilter avec ces changements en user-space.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: netfilter dans tout ça ?
Posté par jve (site web personnel) . Évalué à 2.
# Linux ou comment on utilisait de la merde pendant 10ans...
Posté par NickNolte . Évalué à 3.
Pendant des années on ventait les mérites de Linux pour faire son firewall/passerelle/routeur de la mort qui tue et vlan, voilà que "maintenant" on présente iptables/netfilter comme étant lourd, monolithique, ergonomiquement rigide etc... etc...
Perso je connais pas, j'utilise NetBSD ces usages.
C'est pareil avec la gestion mémoire, un coup c'est Linux gère la mémoire mieux que... et quand une nouvelle release du noyau sort c'est comme si on avait toujours utilisé que de la merde. :)
Gallium maintenant, on se rend compte à quel point c'était chaotique dans le monde des puces graphiques.
Je passe le passage sur le WiFi qui n'a jamais autant été le point noir du monde linux - que ça soit noyau ou userland - et pourtant combien d'article je n'ai pas lu ventant Linux comme parfaite platforme pour mettre en place des AP, y a accèder etc...
Bref, j'ai vraiment l'impression d'avoir affaire aux marketeux d'Intel à chaque refonte d'un code :)
[^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...
Posté par jve (site web personnel) . Évalué à 3.
IPtables mange plusieurs centaines de mega octets par secondes, et plusieurs dizaines de milliers de connexions simmultannées sur pas mal de GROS sites. Mais non, c'est pas encore assez bien, alors on continue d'améliorer. C'est pas beau ca ?
[^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...
Posté par claudex . Évalué à 7.
On dit que iptables est lourd mais pour des gros besoins qu'il n'y avaient pas forcément avant ou pour des cas particuliers. Même chose pour la gestion de la mémoire, ça mettait du temps quand tu avais des centaines de gigas de RAM (ce qui n'est, même actuellement, pas encore mon cas), il y a plusieurs années, ça servait à rien et personne n'aurait penser au problème mais maintenant que la technologie a avancé, on se rend compte que dans ce cas là c'est gênant. Et de même pour les cartes graphiques, elles ont des besoins qu'elle n'avaient pas avant et en plus, il y a de plus en plus de pilote libre, ce qui permet de se rendre compte des erreurs.
Je suis sûr que NetBSD a déjà réimplémenter des fonctions car ils se sont rendu compte que ça ne correspondait plus aux usages. (mais comme je ne lis pas les changelog NetBSD et qu'il n'y a pas de patrick_g-*-BSD, je ne peux pas de dire lesquels).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...
Posté par helkyn . Évalué à 2.
Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.
En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.
Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).
Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)
# Ha ba tiens !
Posté par jve (site web personnel) . Évalué à 3.
http://jve.linuxwall.info/blog/index.php?post/2009/03/23/nft(...)
et je pensais pas que ca valait la peine d'en faire une dépêche... mais bon, si ca intéresse des gens, c'est cool :)
[^] # Re: Ha ba tiens !
Posté par patrick_g (site web personnel) . Évalué à 6.
Ne jamais penser ça. Toujours proposer la news.
# Temps perdu
Posté par mururoa69 . Évalué à -2.
Ca va juste donner un produit dont les capacités -à terme- vont venir s'intercaler entre iptables et pf. Et vlan une nouvelle syntaxe différente de ce qui existe à se taper.
Alors qu'il aurait été quand même beaucoup plus simple de porter pf sur linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.