Discussion autour de Netfilter

Magazine
Marque
MISC
Numéro
64
Mois de parution
novembre 2012
Spécialité(s)


Résumé

Netfilter est la couche pare-feu de Linux depuis 2001. Ensemble de logiciels très complet, il n'en reste pas moins que sa puissance est assez méconnue car son adaptabilité et ses fonctions avancées sont souvent sous-estimées.


Body

1. Présentation rapide

1.1. Le projet Netfilter

Netfilter [NETFILTER] est la couche pare-feu intégrée au noyau Linux depuis la version 2.4. Il s'agit d'un pare-feu IPv4 et IPv6 avec suivi d'états qui intègre des fonctionnalités de modifications de paquets et de traduction d'adresses. Le projet se décompose en une partie noyau et un ensemble d'outils en ligne de commandes ou de démons.

Netfilter est un projet indépendant qui n'est rattaché à aucune société. Les grandes décisions sont prises au sein de la coreteam qui regroupe les développeurs clés et dont les membres sont cooptés. Les membres de la coreteam participent à l'élection de leur chef. Il s'agit depuis plusieurs années de Patrick Mchardy, un consultant indépendant allemand. Ils'est mis en retrait en 2012 et Pablo Neira Ayuso, professeur à l'université de Séville, a exercé l'intérim.

Si le chef a un droit de décision finale (tacite) en cas de conflit entre les développeurs, son rôle principal est la gestion des interactions avec le noyau Linux. Il rassemble l'ensemble des contributions noyaux et les propose comme un tout cohérent et fonctionnel au mainteneur de la couche réseau de Linux (David Miller actuellement) qui les transmet alors à Linus Torvalds pour intégration dans les sources officielles. Les principaux développeurs se réunissent tous les ans lors d'un atelier de travail d'environ une semaine pour discuter du travail effectué et des projets à venir.

L'outil le plus associé à Netfilter est iptables qui permet de configurer les règles de filtrage et les deux noms sont parfois confondus, ce qui n'est pas rendre honneur à un projet beaucoup plus vaste. En effet, si l'on exclut les bibliothèques partagées, les composants de Netfilter sont Iptables, conntrack-tools, ulogd, nfacct, ipset et xtables-addons.

Le projet conntrack-tools [CONNTRACK] est un des plus conséquents. Son composant principal est le démon conntrackd qui est en charge d'assurer la réplication du suivi d'états entre plusieurs machines assurant ainsi la haute disponibilité. L'autre outil majeur de conntrack-tools est l'utilitaire en ligne de commandes conntrack qui interroge et/ou modifie le suivi d'états.

ulogd est le démon de journalisation de Netfilter. Il reçoit les événements venant de la journalisation de paquets ou encore du suivi d'états et réalise leur stockage dans des bases de données ou des fichiers. La version actuelle est la version 2.0 qui est une réécriture du vénérable ulogd dont il augmente considérablement les fonctionnalités.

nfacct est un nouveau venu dans la galaxie Netfilter. C'est un outil en ligne de commandes utilisé pour paramétrer et récupérer les informations issues de la fonctionnalité noyau NFACCT de Netfilter. Le but de ce système est de fournir des compteurs de volumétrie réseau précis et flexibles mais ayant un faible impact sur les performances.

ipset est un projet de « matching » haute-performance. Il autorise la définition de liste d'objets réseau de tailles importantes et il réalise un filtrage peu coûteux sur ces ensembles.

Enfin, xtables-addons est une bibliothèque de patches pour Netfilter et iptables. Elle contient des fonctionnalités qui ne sont pas (ou pas encore) intégrées au noyau. On trouve par exemple des extensions comme xt_geoip pour filtrer les adresses IP source ou destination en utilisant les informations géographiques contenues dans la base geoip ou encore xt_condition qui lie l'activation de certaines règles de filtrage à des entrées dans /proc. Successeur de patch-o-matic-ng, xtables-addons est maintenu par Jan Engelhardt qui a réalisé une glu entre le code des modules et le code noyau, ce qui permet de maintenir le code des modules stables en faisant uniquement évoluer la glu.

1.2. Quelques mots sur l'architecture

Une des spécificités du filtrage dans Netfilter est d'utiliser des chaînes différentes suivant la nature du paquet. Si le paquet est à destination du pare-feu, il est filtré dans la chaîne INPUT. S'il est émis par le pare-feu, il est filtré dans la chaîne OUTPUT. Enfin, si le paquet est routé par le pare-feu, il est filtré dans la chaîne FORWARD.

 

netfilter-flow-1

 

Ce mécanisme paraît perturbant à beaucoup mais il offre certains avantages. Il réalise une séparation nette des fonctions lorsque l'on considère un pare-feu réseau. Les règles gérant l'accès au pare-feu sont bien séparées de la fonction principale du pare-feu. Il est ainsi potentiellement plus difficile de se couper l'accès. L'un des autres intérêts est de séparer la politique par défaut qui est appliquée sur ces chaînes.

Il ne faut cependant pas voir là une volonté d'ergonomie puisque l'existence de ces trois chaînes semble plus liée à des contraintes d'implémentation laissées apparentes au niveau de l'utilisateur. Ces chaînes sont le reflet direct des points d'ancrages (hook) de Netfilter dans le code de Linux. L'appel aux fonctions de filtrage se fait grâce à l'appel de la macro NF_HOOK qui est placée aux endroits clés pour le filtrage : réception IP avant l'envoi à la couche protocolaire, envoi IP après la couche protocolaire, et enfin, routage des paquets.

Ces trois hooks génèrent les trois chaînes de filtrage (table filter) disponibles dans Netfilter. La fonctionnalité de filtrage étant complétée par d'autres fonctions, il faut compter sur les chaînes de translation d'adresses de la table nat et de modification de paquets de la table mangle. Un choix cette fois-ci ergonomique a été fait et des chaînes séparées sont utilisées pour ne pas mélanger les différentes tâches. Dans le cas de mangle, la séparation était vraiment arbitraire et depuis quelque temps, il est possible de modifier les paquets dans la table de filtrage. Le NAT réalise des transformations (modification d'adresse IP source, réécriture de port) qui doivent avoir lieu au début d'une session et s'appliquer à son intégralité. Par conséquent, les chaînes de NAT ne reçoivent que les premiers paquets de chaque session, à l'inverse des chaînes de filtrage qui les traitent tous. La séparation des tables filter et nat n'est donc pas qu'un simple artefact de présentation.

Dans le cas du Destination NAT, la traduction d'adresse est capable de modifier le chemin d'un paquet par rapport au routage. Ainsi, un paquet qui aurait dû être routé peut être redirigé vers un port local par l'action du NAT (cas d'un serveur mandataire transparent). Il faut donc agir avant le routage et cela a entraîné la création de la chaîne PREROUTING. Le NAT est aussi utilisé pour masquer les adresses internes lorsque l'on se connecte à l'extérieur. En faisant cette transformation dans la chaîne PREROUTING, le système de filtrage ne verrait plus les adresses internes et il a donc été décidé de faire cette modification au plus tard, à savoir après le routage, ce qui a conduit à la chaîne POSTROUTING.

 

netfilter-flow-2

 

Dans chaque chaîne, l'administrateur peut positionner des règles iptables réalisant le filtrage ou une transformation de type NAT ou mangle. Une règle iptables est une directive comportant un ensemble de critères de sélection et une action à effectuer si les critères de sélection sont remplis. Les règles sont stockées dans des chaînes ordonnées et la politique de filtrage qui s'applique à un paquet est donc le résultat de l'évaluation séquentielle des règles de la chaîne qui s'applique. Le parcours d'un paquet dans Netfilter est donc le résultat des transformations et décisions prises dans chaque chaîne. Les deux actions les plus courantes sont ACCEPT et DROP. Cette dernière action entraîne la destruction immédiate du paquet. Au contraire, lorsqu'un paquet se voit appliquer la décision ACCEPT dans un chaîne, il passe dans la chaîne suivante relativement au flux de traitement des paquets. On trouve aussi l'action REJECT qui bloque le paquet mais prévient l'émetteur au moyen d'un message ICMP. Dans le cas d'un paquet TCP, REJECT peut aussi répondre avec un paquet TCP reset pour simuler un port qui n'est pas à l'écoute.

La commande iptables est utilisée pour gérer l'ensemble des tables. Elle agit de manière unitaire en ajoutant les règles une par une. C'est donc très souvent une série de commandes iptables qui est donnée dans les exemples. Sa syntaxe est la suivante :

iptables [-t table] operation chain rule-specification

operation -A -D -I -P

rule-specification [matches...] [target]

match = -m matchname [per-match-options]

target = -j targetname [per-target-options]

Pour autoriser le passage des paquets routés à destination du port 80 et du serveur 1.2.3.4, on peut écrire :

iptables -t filter –append FORWARD -p tcp –dport 80 -d 1.2.3.4 -j ACCEPT

Comme la table filter est utilisée par défaut, ceci s'écrit plus fréquemment :

iptables -A FORWARD -p tcp –dport 80 -d 1.2.3.4 -j ACCEPT

Les modules d'extensions s'utilisent avec l'option -m qui charge le module et qui permet ensuite d'utiliser les mots-clés qu'il exporte. L'exemple suivant montre comment utiliser l'option --dports du module multiport :

iptables -A FORWARD -p tcp -m multiport --dports 22,25:26,80 -j ACCEPT

1.3. Suivi de connexions

Le suivi d'états est un des points essentiels et critiques de l'infrastructure Netfilter. Appelé suivi de connexions ou encore conntrack, il traque l'établissement des connexions traversant le pare-feu qu'elles soient TCP, UDP ou encore SCTP.

Si un suivi de connexions peut surprendre pour un protocole non connecté comme UDP, ce système répond néanmoins à un besoin réel et apporte en termes de sécurité. Dans la plupart des cas, il y a, même en UDP, un serveur et un client, et une communication sur UDP a donc le plus souvent la cinématique suivante : le client initie la communication avec le serveur puis il y a émission de paquets potentiellement dans les deux sens. Le suivi de connexions se calque sur ce fonctionnement en déclarant une session UDP dès qu'il a constaté un échange entre les deux pairs. La session expire au bout d'un délai assez court (30 secondes par défaut) ensuite si aucun paquet n'est envoyé.

Le jeu de règles minimal pour autoriser les requêtes vers un serveur DNS est le suivant :

iptables -P FORWARD DROP

iptables -A FORWARD -m conntrack --ctstate NEW -d $SERVER -p udp --sport 1024: --dport 53 -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT

La première règle positionne simplement la politique par défaut à DROP. La seconde autorise les paquets à destination du port 53 et provenant d'un port source supérieur à 1024 (l'oubli du port source 53 est ici volontaire). Une condition supplémentaire est exigée pour ces paquets : l'état dans le conntrack du paquet doit être NEW, c'est-à-dire que le paquet ne doit appartenir à aucune connexion en cours. Ceci nous garantit donc que l'on a un paquet d'ouverture de connexion. La seconde règle décrète que l'ensemble des paquets qui appartiennent à une connexion établie doivent être autorisés.

La tâche du suivi de connexions semble ainsi bien établie, mais c'est sans considérer la problématique de la traduction d'adresse. Au passage du pare-feu, certains des paramètres IP peuvent être réécrits. C'est ainsi souvent le cas de l'adresse source lors du passage d'un pare-feu donnant accès à Internet qui en IPv4 modifie l'adresse source pour n'utiliser que son adresse publique sur le réseau extérieur. Cela impose au pare-feu de savoir à qui renvoyer le paquet retour qui sera dirigé vers son adresse publique sans trace de la connexion venant du réseau privé. Une table de correspondances est donc nécessaire. Dans Netfilter, elle est maintenue au sein du suivi de connexions qui contient ainsi les données correspondant aux paramètres IP avant et après transformation. Le premier sens appelé ORIG contient les informations du paquet initial et le second, REPLY, contient les informations que le paquet aura au retour. Ainsi, la sortie suivante présente une connexion modifiée par le NAT.

tcp      6 429619 ESTABLISHED src=192.168.42.86 dst=209.85.148.101 sport=59857 dport=443 src=209.85.148.101 dst=1.2.3.4 sport=443 dport=59957 [ASSURED] mark=0 use=1

Un point intéressant ici est l'absence d'information autre qu'IP dans cette sortie. En effet, le suivi de connexions travaille uniquement à ce niveau. Il est ainsi à même de prendre en compte les solutions de routage asymétriques et autres configurations complexes où les couches basses peuvent varier de manière aléatoire. Cependant, cela signifie aussi qu'aucun contrôle de conformité topologique des flux n'est effectué par le conntrack.

Le suivi de connexions effectue néanmoins des vérifications de conformité au niveau protocolaire et l'état INVALID désigne un paquet dont le contenu IP ou protocolaire n'est pas valide par rapport au moteur à état du protocole concerné (paquet TCP avec une fenêtre incorrecte pour la session à laquelle il est censé appartenir par exemple). Autre point remarquable, la détection de ces incohérences protocolaires est implémentée dans Netfilter et ne repose en rien sur la couche protocolaire du système hôte. Le point positif est de permettre de coder les inconséquences de certains systèmes d'exploitation sans modifier le comportement classique de Linux. Le point négatif est qu'il s'agit d'un code séparé qu'il est nécessaire de maintenir et de faire évoluer.

Avec l'ajout du NAT et des contrôles protocolaires, la tâche du suivi de connexions s'avère ainsi plus complexe qu'elle peut paraître au premier abord. Mais c'est sans compter sur les protocoles multi-connexions comme FTP, SIP ou encore IRC. Des protocoles comme FTP ou SIP ouvrent une connexion de signalisation et échangent des informations sur ce canal pour négocier les paramètres de connexions parallèles. L'exemple le plus simple est celui de FTP. La connexion de signalisation a lieu sur le port 21 et deux messages sont échangés entre le client et le serveur pour définir les paramètres d'une connexion dédiée à l'échange d'un flux de données.

Prenons ainsi une session FTP :

Logged in to ftp . lip6 . fr .

ncftp / > ls

etc / jussieu / lip6 /

Au niveau protocolaire, la session FTP consiste en l'échange de commandes suivant :

Client: PASV

Serveur: 227 Entering Passive Mode (195,83,118,1,199,211)

Client: MLSD

Serveur: 150 Opening ASCII mode data connection for ’MLSD’.

Serveur: 226 MLSD complete.

Client: QUIT

Le client demande à ouvrir une connexion de données et le serveur lui répond qu'il peut se connecter sur 195.83.118.1 sur le port 51155 (199*256+211).

Au niveau TCP, on distingue bien deux sessions TCP séparées :

195.83.118.1.21 > 10.62.101.203.52994

195.83.118.1.21 > 10.62.101.203.52994

10.62.101.203.57636 > 195.83.118.1.51155

10.62.101.203.52994 > 195.83.118.1.21

195.83.118.1.51155 > 10.62.101.203.57636

Considérons maintenant le filtrage d'un tel échange. L'autorisation de la connexion de signalisation est similaire à l'autorisation des requêtes DNS :

iptables -A FORWARD -m conntrack --ctstate NEW -d $SERVER -p tcp –sport 1024 : –dport 21 -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT

Maintenant, si l'on prend en compte les connexions de données du mode actif et du mode passif, il faut ajouter :

iptables -A FORWARD -m conntrack --ctstate NEW -d $SERVER -p tcp –sport 1024 : –dport 1024 : -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate NEW -s $SERVER -p tcp –sport 1024 : –dport 1024 : -j ACCEPT

On vient tout simplement d'autoriser tout Internet à se connecter vers le serveur sur les ports au dessus de 1024 et d'autoriser le serveur à se connecter partout sur les ports hauts. « On a tué des chatons pour moins que ça ».

Il est donc nécessaire de trouver une méthode pour limiter les ouvertures au strict minimum. Peu de solutions sont disponibles ici. Les paramètres des connexions secondaires se trouvent dans le contenu applicatif et il faut donc l'étudier. Nous voilà donc à l'heure du choix, le noyau peut indiquer : « je ne sais pas faire ce parsing » et il passe la main à l'espace utilisateur pour le faire (cas de PF et ipfw qui utilisent des serveurs mandataires) ou le noyau prend ses responsabilités et réalise lui même l'étude des flux pour découvrir les paramètres des connexions secondaires (cas de Netfilter, Checkpoint, Juniper, …). Cette dernière technique est réalisée au sein de composants logiciels génériquement appelés Application Level Gateway. Dans le domaine de Netfilter, ils portent le nom de helpers.

Leur tâche est bien définie, ils parsent les flux pour leur protocole et détectent les négociations de connexion secondaires. Ils créent alors une expectation qui contient l'ensemble des paramètres IP possibles correspondant à la probable future connexion. Cette expectation a une durée de vie limitée car il y a forcément un écart de temps relativement court entre le message sur le contrôle de signalisation et l'ouverture de la connexion secondaire. Lorsqu'un paquet avec des paramètres IP correspondant à une expectation arrive, une connexion est ajoutée au conntrack et l'expectation est détruite. Si l'on prend l'exemple précédent et que l'on utilise l'utilitaire conntrack pour afficher en temps réel les événements relatifs aux expectations, on observe bien la création d'une expectation et sa destruction lorsque la connexion de donnée s'établit :

# conntrack -E expect

[ NEW ] 300 proto =6 src =10.62 .101.2 03 dst =195.83.118.1 sport =0 dport =51155

[ DESTROY ] 300 proto =6 src =10.62 .101.2 03 dst =195.83.118.1 sport =0 dport =51155

La connexion créée à partir d'une expectation est marquée comme étant relative à la connexion de signalisation. Les paquets de ce type peuvent être acceptés en utilisant l'état RELATED, ce qui donne :

iptables -A FORWARD -m conntrack --ctstate NEW -d $SERVER -p tcp –sport 1024 : –dport 21 -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT

iptables -A FORWARD -m conntrack –ctstate RELATED -j ACCEPT

Ce mécanisme réduit drastiquement l'ouverture nécessaire pour assurer un fonctionnement des protocoles multi-connexions. Seule une ouverture temporaire sur les paramètres négociés est possible.

L'esprit avisé aura remarqué qu'un tel mécanisme ne peut pas passer la traduction d'adresses. En effet, l'IP communiquée par un client NATé dans l'annonce protocolaire n'aura rien à voir avec ce qui est vu sur Internet puisque les paquets sont réécrits avec l'adresse externe du pare-feu effectuant la transformation. Les helpers sont donc aussi chargés de modifier les messages en indiquant les vraies adresses IP et les vrais ports. Ces derniers peuvent en effet être modifiés dans le cas du NAT puisque la transformation de NAT n'est rien d'autre qu'une application injective entre un sous-ensemble de l'espace des adresses sources et des ports sources vers l'ensemble des ports sources disponibles sur le pare-feu. La conservation du port source n'est pas une hypothèse viable et celui-ci est donc fréquemment modifié pour éviter les conflits. Le pare-feu réalise donc une substitution au sein des messages échangés entre le serveur et le client en mettant à jour les entrées qu'il a modifiées ou en restaurant les données originales. Chacun voit ainsi la réalité qui lui convient.

2. Maîtrise de l'impact des helpers

2.1. Danger des helpers

2.1.1. Know your protocol

Il convient de bien comprendre ce qu'implique l'activation d'un helper. Prenons ainsi le cas du protocole IRC et supposons que le helper IRC soit chargé. Si l'association automatique port/helper est faite (cas par défaut), on a ainsi activation de l'étude de toutes les connexions pour tout flux à destination du port 6667 et donc potentiellement création d'expectation. Dans le cas d'IRC, l'utilisation du helper est uniquement nécessaire pour l'activation des messages DCC qui ne sont autres que des communications directes (pour échange de données) entre clients d'un même serveur IRC. Ce n'est donc pas l'objectif premier du protocole qui reste quasi fonctionnel sans activation du helper.

Par un message DCC, un client annonce qu'il écoute sur un port donné à une IP donnée et qu'il est prêt à recevoir une connexion depuis un point arbitraire d'Internet (puisqu'il ne connaît pas l'adresse réelle de son pair). Si le helper est actif, l'envoi de ce message par le client vers un serveur écoutant sur le port 6667 lui permet donc d'accepter une connexion depuis Internet sur un port de son choix. C'est loin d'être anecdotique et malheureusement aussi loin d'être une conséquence connue et assumée.

L'outil opensvp [OPENSVP] a été développé à des fins éducatives pour montrer la simplicité avec laquelle cette « attaque » est exploitable. Supposons que nous soyons connectés sur une machine dans un réseau privé caché derrière une box ADSL ou une appliance de sécurité basée sur Linux. Si on lance sur un serveur (dont l'adresse est 1.2.3.4) :

$ opensvp --server --helper irc -v

on peut alors démarrer opensvp sur le client :

$ opensvp --client -t 1.2.3.4 --helper irc --port 23 -v

2.3.4.5:23 should be opened from outside

Sur le serveur, on voit apparaître le message :

You should be able to connect to 2.3.4.5:23

Il est alors possible de se connecter depuis n'importe où sur Internet sur le port 23 de l'IP 2.3.4.5 et l'on sera alors redirigé par le pare-feu sur le port 23 de la machine du réseau interne.

2.1.2. One port to pown them all

La sensibilité des helpers aux entrées utilisateurs est donc inquiétante. La création des expectations est basée sur des messages dont certains sont envoyés par le serveur et d'autres par le client. Il est donc intéressant d'étudier quelle est la sensibilité de ce système aux entrées utilisateurs. Une des questions principales étant de savoir si un utilisateur peut ouvrir des connexions arbitraires en abusant de ces messages.

Une étude du code montre qu'après des débuts difficiles (faille FTP de 2001 [FTP2011]), une convention implicite mais ayant le mérite d'exister a été utilisée : l'ouverture de connexions par le client à destination du serveur en utilisant des paramètres fournis par le client ne doit pas être autorisée par défaut. De plus, les communications doivent avoir lieu entre les deux pairs à l'origine de la communication. Si le protocole exige l'ouverture de connexions à destination d'autres IP que les pairs, il est nécessaire d'activer la variable adéquate dans /proc (cas de SIP).

Cependant, et comme le montre l'attaque présentée à SSTIC en 2012 [CONN2012], ce mécanisme est sensible et, si le système n'est pas convenablement protégé, il est possible pour un utilisateur sur un réseau directement connecté au niveau Ethernet d'ouvrir des connexions arbitraires sur un serveur pour peu que celui-ci serve un protocole comme FTP. Cette attaque est contrée par des mesures strictes d'anti-spoofing qui préviennent le système de filtrage des injections de commandes dans les flux. Cette attaque constitue une évolution de la menace constituée par le spoofing. Jusqu'ici, l'anti-spoofing était principalement considéré pour lutter contre des attaques en déni de service visant à saturer certaines tables par des ouvertures de connexions (invalides) très nombreuses. Ici, il s'agit d'injection de paquets dans un trafic légitime.

2.2. Mise en place des protections

L'étude des helpers et l'attaque par spoofing obligent à une mise à niveau des protections. Aussi, les recommandations de protection pour Netfilter ont été mises à jour dans le document « Secure use of iptables and connection tracking helpers » [SECUSE] qui décrit des méthodes de limitations de l'impact des helpers. Celles-ci se résument à deux grandes lignes : suppression de l'association automatique des helpers à un port (et donc activation manuelle de l'association entre flux et helper) et anti-spoofing strict.

2.2.1. Anti-spoofing

Pour IPv4, l'anti-spoofing peut être fait de manière très simple car une fonctionnalité de reverse path filtering est disponible de manière standard. Ce mécanisme est décrit dans la RFC 3704 [RFC3704] qui date de 2004. Le principe du reverse path filtering strict consiste à regarder au moment de la réception d'un paquet si ce dernier arrive sur l'interface sur laquelle on l'aurait routé. Ce n'est donc rien d'autre qu'une vérification de la conformité topologique de la provenance du paquet. L'activation de cette fonctionnalité est faite en standard par les scripts de pare-feu et l'auteur de cet article vous invite à changer de script si ce n'est pas le cas.

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

La fonction rp_filter est uniquement implémentée pour IPv4 et ne protège en rien le système IPv6. Et il n'existe malheureusement même pas d'équivalent pour ce protocole dans les couches réseau.

Depuis le noyau 3.3, un nouveau module de match implémentant la RFC 3704 pour IPv4 et IPv6 a fait son apparition dans Netfilter. Il est appelé rpfilter et si il est chargé dans une règle iptables, une vérification de conformité topologique est faite. La syntaxe pour bloquer les paquets indésirables en IPv4 et en IPv6 est alors la suivante :

iptables -A PREROUTING -t raw -m rpfilter --invert -j DROP

ip6tables -A PREROUTING -t raw -m rpfilter --invert -j DROP

Le lecteur attentif aura remarqué l'utilisation d'une table raw PREROUTING qui n'a pas encore été mentionnée jusqu'ici. Cette table est placée en tout début de processus, son nom « raw » a été choisi car elle est placée avant tout traitement et notamment avant les opérations de conntrack. En réalisant le blocage sur cette table, on économise ainsi tous les traitements et allocations de ressources liés au conntrack. L'impact d'un bombardement de paquets illégitimes est donc réduit au maximum.

Si vous n'avez pas la chance d'avoir un noyau récent, la seule solution en IPv6 est une série de règles manuelles :

ip6tables -A PREROUTING -t raw -i eth0 -s $NET_ETH1 -j DROP

ip6tables -A PREROUTING -t raw -i eth0 -s $ROUTED_VIA_ETH1 -j DROP

ip6tables -A PREROUTING -t raw -s fe80::/64 -j ACCEPT #autorisation du trafic local

ip6tables -A PREROUTING -t raw -i eth1 -s $NET_ETH1 -j ACCEPT

ip6tables -A PREROUTING -t raw -i eth1 -s $ROUTED_VIA_ETH1 -j ACCEPT

Une fois encore ces règles sont positionnées en raw PREROUTING pour limiter les traitements et la consommation de ressources en cas d'attaque.

2.2.2. Activation manuelle des helpers

Depuis le noyau 3.5, il est possible de désactiver l'assignation de tous les flux d'un port à un helper par défaut. L'assignation des flux à un helper doit alors être faite de manière manuelle grâce à la cible CT. Ce nouveau comportement peut être obtenu en chargeant le module nf_conntrack avec un paramètre :

modprobe nf_conntrack nf_conntrack_helper=0

ou aussi pour un système déjà initialisé en utilisant une entrée dans /proc :

echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper

Attention toutefois, dans ce dernier cas, les connexions déjà établies conservent le comportement précédent.

Sur les anciens noyaux, ce comportement est simulable pour bon nombre de helpers en chargeant les modules de helpers avec une variable ports positionnée à 0.

modprobe nf_conntrack_$PROTO ports=0

La cible CT est utilisée pour paramétrer la manière dont un paquet doit être traité vis-à-vis du conntrack, ceci incluant le paramétrage de certains aspects de la connexion à laquelle il sera potentiellement rattaché. Comme cette cible modifie le comportement du conntrack, elle est placée avant les opérations qui y sont relatives et les règles doivent donc être écrites dans raw PREPROUTING. Pour assigner un helper à un flux, c'est l'option helper qu'il faut utiliser, ce qui nous donne par exemple :

iptables -A PREROUTING -t raw -p tcp --dport 21 -d 1.2.3.4 -j CT –helper ftp

Cette méthode est plus contraignante que ce qui se faisait auparavant, mais elle offre un contrôle beaucoup plus fin sur l'impact des helpers.

2.2.3. Autorisation fine des flux relatifs

La sécurité peut encore être renforcée en spécifiant de manière précise quels sont les flux RELATED que l'on autorise à passer. Ainsi, si un serveur FTP est paramétré pour ouvrir des connexions relatives sur les ports de l'intervalle 30000-40000, on peut écrire une règle d'autorisation parfaitement calibrée :

iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \\

--helper ftp -d $MY_FTP_SERVER -p tcp \\

--dport 40000:60000 -j ACCEPT

Cette règle spécifie qu'une connexion TCP entre les ports 40000 et 60000 du serveur FTP est autorisée s'il s'agit d'une connexion relative générée par le helper FTP. Elle ne s'appliquera donc pas pour une connexion relative au helper IRC ou à tout autre helper, ce qui nous protège contre l'utilisation abusive d'un autre helper.

2.3. Haute disponibilité avec conntrackd

Lorsque l'on a un seul pare-feu, toute défaillance conduit à une interruption de service. Ceci est fâcheux pour un équipement critique et il est bien souvent mis en place deux pare-feu dans des configurations dupliquées. La configuration la plus souvent rencontrée est celle du maître et de l'esclave. Ce dernier est juste là en cas de problème planifié (mise à jour) ou non (panne) sur le maître. Lors d'une bascule, l'esclave prend les ressources du maître et récupère son trafic. Si l'on se place du point de vue de l'esclave, il recevra ainsi brutalement des paquets provenant d'un trafic établi qu'il n'a jamais vu auparavant. Le suivi de connexions de l'esclave considérera donc qu'il s'agit d'un trafic illicite et les paquets seront bloqués. L'effet pour l'utilisateur du réseau sera une coupure des sessions applicatives établies. Pour éviter ce problème, l'une des solutions les plus efficaces est de dupliquer les informations du suivi de connexions entre les deux pare-feu. En cas de coupure, l'esclave connaîtra alors les connexions en cours sur le maître et ne bloquera donc plus les sessions des utilisateurs.

Assurer la réplication du suivi de connexions est le but du logiciel conntrackd qui fait partie des conntrack-tools. C'est le fruit du travail de Pablo Neira Ayuso, qui était le concepteur et principal développeur des différentes couches qui ont été nécessaires pour mener à bien ce projet. Le Netfilter originel était en effet bien loin de permettre une construction aisée de ce genre de fonctions. La principale problématique était l'absence de moyen de communication entre le noyau et l'espace utilisateur. Il a fallu attendre le noyau 2.6.14 pour voir arriver un nouveau système de communication appelé nfnetlink, qui a été la base de toute une nouvelle série de bibliothèques dédiées aux échanges des sous-systèmes de Netfilter avec l'espace utilisateur. Nfnetlink est basé sur netlink, qui est un moyen d'échange entre le noyau et l'espace utilisateur. Netlink est utilisé par des couches comme le routage ou encore par iptables. Nfnetlink réalise un multiplexage sur un seul canal netlink et fait donc passer l'ensemble des sous-systèmes de Netfilter sur ce seul canal.

Le sous-système qui nous intéresse ici est le suivi de connexions et il est géré par la bibliothèque libnetfilter_conntrack. Le choix fait pour conntrackd a été de s'appuyer sur cette bibliothèque pour réaliser la tâche de transfert d'informations en espace utilisateur. conntrackd récupère ainsi les entrées du suivi de connexions, les transfère par le réseau au conntrackd de l'esclave qui les conserve en mémoire. En cas de besoin, par exemple lorsque le maître ne répond plus, les informations de connexion sont envoyées par le conntrackd de l'esclave vers son propre conntrack.

L'échange du suivi de connexions entre un maître et un esclave n'est pas protégé par un mécanisme garantissant la confidentialité. Il est donc plus que recommandé de dédier un lien Ethernet physique sur chacune des machines. Ceci est aussi important pour des raisons de fiabilité des données puisque le flux lié à la réplication peut être intensif.

La paramétrage de conntrackd se fait au moyen d'un fichier de configuration dans lequel l'administrateur précise notamment quelle est l'interface dédiée à utiliser et quel est le mode de fonctionnement souhaité. Des modèles de configuration pour chaque mode sont disponibles dans les sources de conntrackd. Le mode le plus classique est FT-FW, qui est un protocole fiable dupliquant les entrées en continu et qui est aussi capable de déclencher des synchronisations globales s'il en détecte le besoin.

La malédiction du filtrage applicatif

La reconnaissance automatique des protocoles n'est pas officiellement disponible au sein du projet Netfilter. Aucun des projets de filtrage de niveau 7 existant n'a en effet réussi à être intégré dans le code officiel. La raison était souvent le manque de qualité du code. Parmi les projets intéressants, citons ipp2p, spécialisé sur le peer to peer, ou encore OpenDPI. Ce dernier est mort suite au rachat de sa société mère (entraînant d'ailleurs ipp2p dans son sillage) et a été repris sous le nom de nDPI par l'équipe de Ntop. Mais il a perdu en passant son lien avec Netfilter. Un port de l'ancien code [NDPIFILTER] existe, mais il reste très expérimental. Il reste donc l7-filter [L7FILTER], qui a était développé à l'origine comme une solution de reconnaissance de protocole. En difficulté lui aussi, il n'a connu, à l'heure de l'écriture de ces lignes, aucune mise à jour depuis près d'un an.

Pablo Neira Ayuso avait présenté en 2011 un projet prometteur appelé nfgrep, mais il semble qu'il soit lui aussi victime de la malédiction puisque le code n'est toujours pas disponible.

3. Ipset ou la gestion de listes complexes

Comme nous l'avons vu plus haut, l'évaluation des règles dans Netfilter est séquentielle. Il s'ensuit que leur multiplication entraînera une baisse des performances. Le tableau n'est cependant pas si noir si l'on regarde le filtrage tel qu'il est effectué de manière classique. L'une des premières règles est celle autorisant les paquets correspondant à des connexions établies. Or sur un trafic standard, cette règle traite en fait 99 % du trafic et l'impact de la taille du jeu de règles est donc limité. Il n'en reste pas moins que la linéarité de l'évaluation est un des points faibles de Netfilter. Ceci est d'autant plus vrai que les règles se multiplient parfois très vite. C'est par exemple le cas dès que l'on veut gérer des listes noires pour éviter tout trafic provenant de machines suspectes. Dans ce cas, les seuls critères de filtrage à disposition sont les opérateurs adresse source ou destination qui ne prennent en paramètre qu'un simple réseau. Gérer une liste noire revient donc à avoir une règle par machine. Certains objecteront peut-être que la liste noire peut être gérée ailleurs, mais le problème de la multiplication se pose dans d'autres cas, comme lorsque l'on veut appliquer un traitement différencié à un ensemble de machines.

À ce problème s'ajoute également une problématique lors des mises à jour. La communication entre iptables et Netfilter souffre en effet d'un problème de taille. Chaque modification unitaire se fait en rapatriant la table sur laquelle la modification est effectuée depuis le noyau, en la mettant à jour puis en injectant le résultat dans le noyau. Si l'opération est rapide lorsque le nombre de règles est limité, elle devient vite très longue lorsqu'il augmente. Les personnes utilisant des scripts de filtrage basés sur des appels successifs à iptables auront remarqué ce problème et beaucoup seront passés à une utilisation de la commande iptables-restore qui, partant d'un fichier texte, met à jour les règles en une seule opération.

Si la solution iptables-restore résout le problème des scripts, la faiblesse du processus de mise à jour condamne le jeu de règles à une certaine stabilité et l'évaluation linéaire limite l'utilisation de listes. Jozsef Kadlecsik a donc écrit ipset, qui est inclus dans Linux depuis 2.6.39, pour pallier ce problème. Ce logiciel introduit la notion d'ensembles complexes. Ils sont définis et nommés grâce à la commande ipset et peuvent être ensuite accédés dans iptables avec un module de match dédié. Supposons que l'on ait défini l'ensemble ipset blacklist, il est alors possible d'écrire ce genre de règle de filtrage :

iptables -A PREROUTING -t raw -m set –match-set blacklist src -j DROP

Cette règle va bloquer tout paquet dont la source a une de ses composantes qui appartient à l'ensemble blacklist.

Les types d'ensembles gérés par ipset sont nombreux. Pour une liste noire d'adresses IP, l'ensemble adapté est hash:ip, qui stocke une liste d'adresses IP dans une table de hachage de taille arbitraire. La plupart des ensembles supportent de plus une expiration temporelle des entrées. Des ensembles plus complexes sont aussi disponibles, comme hash:ip:port qui stocke une liste de couples adresse et port dans une table de hachage.

Un ensemble se crée avec la commande ipset. La commande suivante définit par exemple un ensemble de type hash:ip appelé blacklist dont la durée d'expiration des éléments est 1200 secondes :

ipset create blacklist hash:ip timeout 1200

Les éléments peuvent alors être ajoutés un par un au moyen de la commande ipset, par exemple pour ajouter 2.3.4.5 à blacklist :

ipset add blacklist 2.3.4.5

Il est aussi possible de les ajouter en utilisant la cible SET. Si une règle utilisant la cible SET est déclenchée pour un paquet, celui-ci est alors utilisé pour construire un nouvel élément de l'ensemble passé en option. Ainsi, la commande suivante ajoute à la blacklist toutes les adresses sources des paquets à destination du port 22 :

iptables -I INPUT -p tcp --dport 22 -j SET --add-set blacklist src

La configuration que nous venons de décrire (à l'exception de la dernière règle) est une bonne base pour lutter contre un déni de service. Il suffit d'alimenter la liste des IP attaquantes pour les bloquer au plus tôt. De nombreuses méthodes sont possibles pour alimenter cette liste noire, mais nous ne verrons ici qu'une solution basée sur iptables. Supposons que notre serveur web 1.2.3.4 soit attaqué, une solution pour alimenter la liste est la suivante :

iptables -p tcp –syn -d 1.2.3.4 --dport 80 -m connlimit --connlimit-above 16 \

  -j SET --add-set blacklist src –timeout 300 --exist

Le module connlimit va produire un match dès qu'une adresse IP aura plus de 16 connexions simultanément ouvertes sur le serveur web. Ceci déclenchera alors l'ajout de l'adresse dans l'ensemble blacklist avec un timeout de 300 secondes. L'option --exist assure que le délai d'expiration sera remis à 30 secondes si l'entrée existe déjà dans l'ensemble blacklist. Cette option est inutile dans notre configuration puisque tous les paquets des éléments de blacklist sont bloqués dès la table raw, mais elle a été mentionnée ici car elle peut devenir utile si l'on change la technique de blocage.

La combinaison de deux modules réussit ainsi ici à construire une solution efficace et pertinente pour lutter contre un déni de service sur un serveur web.

4. Iptables comme langage

4.1. iptables peut être vu comme un langage

La syntaxe d'iptables est structurellement simple et l'on se trouve à première vue devant une succession de règles de filtrage qui sont évaluées de manière linéaire. Un regard plus attentif montre qu'il existe un certain nombre de fonctionnalités qui changent la donne. Parmi celles-ci, les deux principales sont les chaînes utilisateurs et les marques.

La chaîne utilisateur est une chaîne nommée et définie par l'utilisateur qui peut y ajouter des règles iptables arbitraires. Elle est accédée par deux moyens, l'opérateur jump (-j) et l'opérateur goto (-g). Avec l'opérateur jump, le filtrage continue à la règle suivant la règle appelante lorsque l'évaluation des règles de la chaîne utilisateur est terminée. Dans le cas de l'opérateur goto, l'évaluation est finie lorsque la fin de la chaîne utilisateur est atteinte. En termes de programmation, une chaîne utilisateur est donc l'équivalent d'une procédure. Elles sont généralement utilisées à des fins de clarté et à des fins de performances. Prenons le cas évoqué plus haut d'une famille de serveurs à qui le même ensemble de règles s'applique. Sans chaîne utilisateur, il faut pour chaque port (ou presque) et pour chaque serveur ajouter une règle. En créant une chaîne utilisateur contenant les règles protocolaires, on simplifie l'écriture :

iptables -N serveur

iptables -A serveur -p tcp –dport 80 -j ACCEPT

iptables -A serveur -p tcp –dport 22 -s $NET_ADMIN -j ACCEPT

iptables -A serveur -p tcp –dport 21 -s $NET_WEBEUX -j ACCEPT

On peut alors ajouter les serveurs :

iptables -A FORWARD -s $IP_SERVEUR1 -j serveur

iptables -A FORWARD -s $IP_SERVEUR2 -j serveur

ou continuer à factoriser avec ipset :

ipset create serveurs hash:ip

ipset add serveurs $IP_SERVEUR1

iptables -A FORWARD -m set –match-set serveurs src -j serveur

ipset add serveurs $IP_SERVEUR2

Cette technique apporte de la lisibilité au jeu de règles et provoque également un gain en performance que l'on peut mesurer par la baisse du nombre de règles évaluées au maximum pour un paquet. En effet, si on note n le nombre de serveurs et p le nombre de règles nécessaire pour un serveur, alors le nombre d'évaluations de règles maximum est n*p pour la version développée, n+p pour la version factorisée iptables et 1+p pour la version factorisée avec ipset.

Les marques sont le deuxième élément clé dans les constructions logiques basées sur iptables. Il s'agit d'une variable entière qui est posée sur le paquet par une cible et qui peut ensuite être matchée dans une autre règle ou utilisée par un autre sous-système réseau, comme la qualité de service. Les marques sont vite incontournables dès que l'on essaie de faire collaborer différentes couches réseau. La marque est fréquemment utilisée comme un bitmask et elle stocke alors un certain nombre d'informations, étant ainsi comparable à une variable locale.

L'exemple suivant utilise la marque pour différencier les paquets NATés des accès directs au serveur mandataire tournant sur le port 8080 :

iptables -A PREROUTING -t mangle -s 192.168.1.0/24 -p tcp --dport 80 -j MARK --set-mark 0x10/0xf0

iptables -A PREROUTING -t nat -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 8080

iptables -A INPUT -m mark --mark 0x10/0xf0 -p tcp --dport 8080 \

  -m comment --comment 'redirection' -j ACCEPT

iptables -A INPUT -p tcp --dport 8080 -m comment --comment 'direct access' -j ACCEPT

La chaîne mangle PREROUTING est située avant la chaîne PREROUTING nat et donc la marque 0x10 est posée sur le paquet avant que la transformation sur le port destination ne soit réalisée. En INPUT, la transformation de NAT est faite et seule la marque permet alors de différencier les paquets NATés de ceux résultant d'une connexion directe.

La marque et son filtre associé constituent donc l'équivalent d'une conditionnelle qui porte sur les paquets. L'un des problèmes de la marque est qu'elle est locale. Elle est non diffusée sur le réseau et elle est uniquement rattachée à un paquet. Le deuxième point a pour conséquence une absence totale d'historique ce qui nuit notamment lorsque l'on veut appliquer le même traitement à l'ensemble des paquets d'une même connexion. Henrik Nordström a donc développé CONNMARK, qui est une marque posée sur les connexions qui assure donc une persistance de la marque au cours du temps.

L'utilisation de CONNMARK est assez gymnique. Les lignes suivantes définissent : tous les paquets des connexions FTP (et même ceux appartenant des connexions de données) sont marqués 1 et tous les paquets des connexions HTTP sont marqués 2 :

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark

iptables -A POSTROUTING -t mangle -m mark ! --mark 0 -j ACCEPT

iptables -A POSTROUTING -p tcp --dport 21 -t mangle -j MARK --set-mark 1

iptables -A POSTROUTING -p tcp --dport 80 -t mangle -j MARK --set-mark 2

iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

Le mécanisme de base de l'utilisation de CONNMARK est la bascule de la marque des paquets vers la marque de leur connexion. Cette opération est réalisée par la dernière ligne qui positionne la marque du paquet sur la connexion à laquelle il appartient. La cible CONNMARK n'est pas finale et l'évaluation des règles de la chaîne se poursuit ensuite. L'écriture de la marque est effectuée en fin de parcours dans le noyau puisque la règle est positionnée en POSTROUTING. Cela garantit que l'ensemble des modifications de marques ont été effectuées.

En début de parcours, la première règle réalise la tâche inverse et copie la marque de connexion sur la marque de paquet. La deuxième ligne fait sortir de la chaîne POSTROUTING mangle tous les paquets ayant une marque non nulle. Les troisième et quatrième lignes posent les marques suivant les ports. MARK tout comme CONNMARK n'est pas une cible terminale et l'évaluation de la chaîne se poursuit jusqu'à la dernière ligne, ce qui nous garantit que la marque est bien sauvée.

Lors de l'utilisation de CONNMARK, il est nécessaire de concevoir le mécanisme en prenant en compte l'enchaînement des paquets. Ici, le premier paquet d'une connexion sur le port 21 (ou 80) va rencontrer la première règle et rester inchangé puisque la connexion est vierge, gardant ainsi une marque à 0. La deuxième règle ne va pas matcher puisque la marque est 0. Le paquet sera donc modifié par la troisième ou la quatrième règle et la dernière règle sauvera la marque de paquet dans la marque de connexion. Les paquets suivants de cette connexion verront leur marque restaurée par la première règle et la deuxième règle matchera, les faisant sortir de la chaîne.

Les paquets appartenant à des connexions de données relatives à la connexion FTP auront la même marque appliquée car la marque de connexion d'une connexion relative est initialisée avec la marque de sa connexion mère.

4.2. Iptables-SubnetSkeleton ou la méthode danoise

Comme nous l'avons vu précédemment, l'évaluation des règles est séquentielle et il s'ensuit un problème de performance lorsque le nombre de règles augmente. Jesper Dangaard Brouer a été confronté au problème lorsqu'il travaillait pour un ISP danois. Il devait gérer des pare-feu mutualisés servant chacun plusieurs dizaines de clients et la flexibilité autorisée sur le jeu de règles de chaque client avait pour conséquence d'avoir jusqu'à 80 000 règles sur un seul pare-feu. L'utilisation d'ipset n'est pas une solution ici car la factorisation par ensemble est peu effective en raison de la variation des jeux de règles entre les différents clients. Une autre approche est de chercher à diminuer le nombre d'évaluations nécessaire pour chaque paquet lorsqu'il parcourt le jeu de règles en l'organisant de manière adéquate. Dans le cas de l'ISP, la complexité est générée par la multiplication des réseaux et une factorisation efficace est donc réalisable en diminuant le nombre de règles parcourues avant d'arriver au jeu de règles du client. Jesper Dangaard Brouer a donc écrit Iptables-SubnetSkeleton [IPTSKEL] qui crée une structure de tables utilisateurs arborescentes dans laquelle sont aiguillés progressivement les paquets. En filtrant sur des réseaux imbriqués de plus en plus étroits, les paquets parviennent vers le filtrage correspondant à son client et le nombre de règles évaluées pour parvenir au jeu de règles du client est donc égal à la profondeur du réseau.

Conclusion

Netfilter est devenu au fil du temps un ensemble de logiciels de plus en plus puissants. La combinaison de leurs fonctionnalités rend possible la création de solutions élégantes à des problèmes complexes. Des administrateurs et des développeurs de talent utilisent et font évoluer ces logiciels depuis des années. Ils ont sans doute déjà résolu les problèmes que vous pouvez avoir maintenant. À vous de voir comment vous pouvez combiner les différentes briques pour parvenir à vos fins.

Références

[NETFILTER] Netfilter, http://www.netfilter.org/

[CONNTRACK] conntrack-tools, http://conntrack-tools.netfilter.org/

[OPENSVP] Opensvp, https://home.regit.org/software/opensvp/

[FTP2001] Problème de conception du helper FTP, Cristiano Lincoln Mattos, http://lwn.net/2001/0419/a/netfilter.php3

[CONN2012] Utilisation malveillante du suivi de connexions, Éric Leblond, https://www.sstic.org/2012/presentation/utilisation_malveillante_des_suivis_de_connexions/

[RFC3704] RFC 3704, http://www.armware.dk/RFC/rfc/rfc3704.html

[SECUSE] Secure use of iptables and connection tracking helpers, É. Leblond, P. Neira Ayuso, P. McHardy, J. Engelhardt, Mr Dash Four, https://home.regit.org/netfilter-en/secure-use-of-helpers/

[L7FILTER] L7 Filter, http://l7-filter.clearfoundation.com/

[NDPIFILTER] ndpi-netfilter, https://github.com/ewildgoose/ndpi-netfilter

[IPTSKEL] IPTables SubnetSkeleton, https://github.com/netoptimizer/IPTables-SubnetSkeleton

 



Article rédigé par

Par le(s) même(s) auteur(s)

Nftables, une révolution dans le pare-feu Linux

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
76
Mois de parution
janvier 2015
Spécialité(s)
Résumé

Après 10 ans d'une domination implacable sur le monde des pare-feu open source, iptables est sur le point d'être remplacé par nftables. Les développeurs de Netfilter ont choisi de revoir leur copie et proposent un nouveau système de filtrage en rupture avec l'existant. Quelles sont leurs motivations et qu'apporte nftables par rapport à son vénérable ancêtre ?

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 67 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous