Pare-feu iptables et UFW contrôlent les connexions qu'un serveur web accepte et celles que je bloque - cela détermine la surface d'attaque et les pannes. Dans cet article pratique, je présente des règles claires, des paramètres par défaut sûrs et des commandes testées pour SSH, HTTP(S), les bases de données, la journalisation, IPv6 et Docker - directement utilisables sur des hôtes de production.
Points centraux
Les points clés suivants me donnent une orientation rapide avant de commencer la configuration.
- Restrictif démarrer : déni par défaut pour entrant, ouverture ciblée
- SSH autoriser d'abord : ne pas risquer l'accès
- UFW comme interface : syntaxe simple, iptables en arrière-plan
- Enregistrement activer le système : Vérifier les règles, détecter les attaques
- Persistance s'assurer qu'ils sont bien en place : Obtenir des règles sur les redémarrages
Les bases : iptables et UFW en un coup d'œil
Je mise sur iptablesJ'utilise Uptow lorsque j'ai besoin d'un contrôle fin sur les paquets, les chaînes et les correspondances. J'utilise UFW quand je veux appliquer rapidement des règles fiables qui finissent en interne comme règles iptables [1]. Je combine ainsi des commandes simples avec la puissance du netfilter Linux, sans me perdre dans les détails. Pour les serveurs web, cela signifie que je construis un filtre clair avant Apache, Nginx ou Node, afin que seul le trafic souhaité arrive [2]. Cette séparation réduit les surfaces d'attaque et permet aux attaques de tomber plus souvent dans le vide.
Les deux outils se complètent et je décide en fonction de la situation lequel convient le mieux. UFW marque des points avec une lisibilité propre, en particulier sur Ubuntu et Debian [3]. iptables me donne des options étendues, par exemple pour NAT, des interfaces spécifiques et des correspondances complexes. Important : je documente mes règles de manière concise afin de faciliter la maintenance ultérieure. Ceux qui souhaitent approfondir le concept de sécurité trouveront une introduction compréhensible ici : Un pare-feu comme bouclier.
Configuration de démarrage : définir des politiques par défaut en toute sécurité
Je commence par Défaut-politiques : bloquer en entrée, autoriser en sortie. J'évite ainsi que de nouveaux services soient involontairement accessibles. J'autorise toujours le bouclage pour que les processus internes fonctionnent de manière stable. J'accepte les connexions existantes afin d'éviter les interruptions. Cet ordre permet de minimiser les erreurs lors de l'activation du pare-feu [2][5].
Avec UFW, je définis la base en quelques commandes. Je vérifie ensuite l'état en détail afin de remarquer immédiatement les erreurs de frappe. Pour les hôtes particulièrement sensibles, je limite également les ports sortants. Je réduis ainsi le risque de fuite de données si un service a été compromis. J'utilise souvent les commandes suivantes :
# UFW : règles par défaut
sudo ufw default deny entrant
sudo ufw default allow outgoing
# Politique alternative plus stricte en sortie
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 80
sudo ufw allow out 443
# Vérifier le statut
sudo ufw status verbose
Stateful Filtering : états et séquence
Un flux de paquets propre dépend de États de Conntrack. J'accepte d'abord les connexions établies, je rejette rapidement les paquets non valides et je laisse le loopback ouvert. Cela réduit la charge et évite les effets de bord dus aux drops tardifs. Pour iptables, j'établis l'ordre de manière consciente :
# iptables : une base solide
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Toujours autoriser le bouclage
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Autoriser les connexions existantes/associées
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Rejeter les paquets invalides au plus tôt
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Avec UFW, ESTABLISHED/RELATED sont déjà pris en compte en interne. Je fais en plus attention à savoir si je préfère DROP (silencieux) ou REJECT (actif, basculement plus rapide). Pour les réseaux internes, je préfère REJECT, pour le réseau public, je préfère généralement DROP.
Règles essentielles pour les serveurs web : SSH, HTTP et HTTPS
J'enclenche SSH d'abord libre, sinon je me bloque facilement. Ensuite, j'autorise HTTP et HTTPS pour que le serveur web soit accessible. Je ne définis que les ports dont j'ai vraiment besoin. Plus tard, j'ajoute en option la limitation du débit ou Fail2ban pour atténuer les tentatives brutales de connexion. Je contrôle immédiatement chaque modification avec des commandes de statut ou de liste.
Les commandes pour cela sont simples. UFW propose des alias parlants pour les ports web, ce qui améliore la lisibilité. Avec iptables, je peux définir des ports et des protocoles précis. J'enregistre ensuite les règles iptables pour qu'elles résistent au redémarrage. Voici les étapes minimales :
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Sécuriser le système SSH : Limiter et ouvrir de manière ciblée
En plus de la validation, j'atténue les attaques avec Limitation du taux ou des listes blanches. UFW apporte une protection simple :
# Limitation du débit SSH (UFW)
sudo ufw limit 22/tcp comment "Limite de débit SSH
Avec iptables, je fixe des limites plus fines. Cela évite de tester massivement les mots de passe sans exclure les administrateurs légitimes :
# SSH : limiter les tentatives de connexion par source
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m récent --nom SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m récent --nom SSH --update --secondes 60 --hitcount 10 -j DROP
Dans la mesure du possible, je n'autorise SSH qu'à partir de Adresses IP des administrateurs et travaille avec des clés SSH. Le changement de port ne remplace pas la sécurité, mais il peut réduire le bruit. Je documente les exceptions et les vérifie régulièrement.
Sécuriser les bases de données et limiter les sources IP
Je n'ouvre jamais les ports de la base de données de manière globale, mais seulement local ou pour des adresses IP sources définies. J'évite ainsi que les scanners ne trouvent des ports MySQL, PostgreSQL ou MongoDB ouverts. Pour les apps locales, 127.0.0.1 suffit comme destination, je contrôle les accès admin externes strictement par IP. Je documente brièvement les modifications, par exemple dans le wiki du serveur. Cela me permet de gagner du temps lors des audits.
J'utilise souvent les exemples suivants dans des projets. Je vérifie au préalable l'exactitude de chaque IP autorisée. UFW permet une notation "from-to" propre, iptables met techniquement en œuvre la même logique. Pour les fenêtres de maintenance temporaires, j'utilise des règles d'autorisation supplémentaires et je les supprime ensuite. Ainsi, l'interface reste petite :
# Local uniquement : MySQL
sudo ufw allow from 127.0.0.1 to any port 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Autoriser une seule IP
sudo ufw allow from 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Autoriser le port pour une IP spécifique
sudo ufw allow from 10.1.2.3 to any port 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Bloquer les attaquants connus
sudo ufw deny from 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Traiter proprement la journalisation, les interfaces et IPv6
J'enclenche Enregistrement pour vérifier les règles et détecter le trafic suspect. Le niveau "on" dans UFW suffit pour la plupart des hôtes, je n'utilise les niveaux supérieurs que de manière ciblée. J'évalue les logs avec journalctl, fail2ban ou des outils SIEM. Cela me permet de reconnaître les modèles de scans ou de tentatives de force brute. En cas d'anomalies, j'adapte les règles en temps réel [2].
Je lie souvent les règles à un certain Interfacepar exemple eth0 sur les réseaux publics. J'évite ainsi d'affecter inutilement les réseaux internes. UFW peut "allow in on eth0 to any port 80", iptables utilise -i pour les interfaces d'entrée. Pour IPv6, je vérifie l'activation dans /etc/default/ufw pour "IPV6=yes" et j'utilise ip6tables pour les règles natives [2]. Cette séparation évite les lacunes pour les hôtes à double pile.
ICMP et ICMPv6 : une accessibilité sans faille
Je laisse les choses nécessaires ICMP-pour que la découverte du Path MTU, les délais d'attente et les diagnostics fonctionnent. ICMP n'est pas un ennemi, mais le cœur du protocole IP. Je ne fais que limiter les échos excessifs.
# IPv4 : limiter l'écho, autoriser les types ICMP importants
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW : autoriser ICMP en général (réglage fin possible dans before.rules)
sudo ufw allow in proto icmp
À l'adresse suivante : IPv6 ICMPv6 est absolument nécessaire (Neighbor Discovery, Router Advertisement). J'autorise les types de noyau et je limite les demandes d'écho :
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbor-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbor-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Utiliser correctement la restriction sortante et le NAT/Masquerading
Je limite le trafic sortant si je veux Profil de risque et de la conformité. J'autorise le DNS et le HTTPS, je bloque tout le reste sauf les cibles définies. Cela réduit les données exfiltrées si un service est détourné. Pour les applications nécessitant des mises à jour ou des API, je crée des exceptions définies. Je documente proprement ces exceptions et je les vérifie régulièrement.
Pour les configurations de routage, j'utilise le NAT/Masquerading via des règles UFW-Before ou de manière brute avec iptables. Ce faisant, je fais attention à l'ordre des chaînes afin que les paquets soient correctement réécrits. Après les modifications, je teste la connectivité et les latences. Pour les systèmes de production, je planifie une fenêtre de maintenance et sécurise la configuration. De cette manière, je conserve la traçabilité des chemins d'accès au réseau [7].
Détails sortants : services système et protocoles
Dans le cadre d'une politique d'outbound stricte, j'autorise de manière ciblée DNS (53/udp), HTTPS (443/tcp) et si nécessaire NTP (Pour les serveurs de messagerie, j'ajoute 25/tcp et 587/tcp. Je ne résous pas les exceptions basées sur le domaine au niveau des paquets, mais via des proxys ou une logique d'application.
# UFW : services système typiques
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - seulement si serveur de messagerie
sudo ufw allow out 587/tcp # Soumission - seulement si nécessaire
# iptables : allow ciblé
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker et les pare-feux : éviter les pièges
Docker utilise ses propres iptables-qui peuvent influencer ma politique. C'est pourquoi je vérifie les chaînes NAT et FORWARD après chaque démarrage de Compose ou de Daemon. Je libère volontairement les ports exposés et j'évite "-p 0.0.0.0:PORT". Au lieu de cela, je les lie à l'IP de gestion ou au proxy inverse. Ainsi, le vecteur d'attaque reste plus petit et plus visible [1].
Je garde les pare-feux des hôtes actifs malgré Docker. En outre, je contrôle les groupes de sécurité au niveau de l'infrastructure, s'ils existent. En cas de conflit entre UFW et Docker, j'utilise des solutions de contournement documentées ou j'établis des règles dans DOCKER-USER. Il est important de définir clairement les responsabilités : l'hôte bloque en principe, les conteneurs n'ouvrent que de manière explicite. Cet ordre empêche les partages inconscients.
# DOCKER-USER : appliquer la politique globale de l'hôte avant les règles de Docker
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Paramètres de précision de l'UFW : Ordre, profils et trafic acheminé
Quand la précision compte, j'utilise "insert", "numbered" et les profils d'application. Ainsi, je garde l'ordre des règles propre et j'utilise des définitions de services testées.
# Contrôler l'ordre
sudo ufw insert 1 deny in from 198.51.100.0/24
# Vue numérotée et suppression ciblée
sudo ufw status numéroté
sudo ufw delete 3
# Profils d'apps (par ex. Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw allow "Nginx Full"
# Bloquer le trafic routed par défaut (forwarding)
sudo ufw default deny routed
J'enregistre les exceptions plus complexes dans before.rules respectivement after.rules. Je peux y placer avec précision le réglage fin ICMP ou le NAT sans perdre la lisibilité des règles standard.
Règles persistantes : Enregistrer et restaurer
Avec UFW, les règles sont persistant et résistent automatiquement aux redémarrages. Cela simplifie considérablement l'administration sur les hôtes Debian/Ubuntu. Avec iptables, j'enregistre les règles après les avoir modifiées et je les réinstalle au démarrage. Pour cela, j'utilise iptables-save/restore ou netfilter-persistent. Sans cela, je perdrais les modifications après un redémarrage [5].
Je teste la persistance de manière planifiée : prévoir un redémarrage, puis vérifier l'état. Si les compteurs et les chaînes sont corrects, la configuration est solide. S'il manque des règles, je corrige le chemin de chargement dans le contexte Init ou Systemd. Cette routine évite les surprises pendant la maintenance. La documentation et la sauvegarde des fichiers de règles complètent la procédure.
# Debian/Ubuntu : persistance pour iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save
# Sauvegarder manuellement
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
# Restaurer (si nécessaire)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Performance et protection : limites, ensembles et réglage du noyau
En cas de charge élevée, je réduis le nombre de règles et utilise des Limites de taux. Pour les grandes listes de blocage, je travaille avec ipset afin de réduire les temps de recherche. En outre, je mets en place des mécanismes de protection proches du système :
# Contenir le flot de SYN (noyau)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Limiter le taux de connexion HTTP par IP source (exemple)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Je garde la taille de la Tableau Conntrack dans le champ de vision. En cas de nombreuses connexions simultanées, j'augmente nf_conntrack_max, mais je teste d'abord les effets.
Gestion, tests et prévention des erreurs
Je laisse SSH avant d'activer "deny incoming". Ensuite, je teste à partir d'une deuxième session si l'accès reste stable. Je vérifie chaque nouvelle règle avec "ufw status verbose" ou "iptables -L -v". Cela me permet d'identifier les compteurs d'occurrences et de voir si les paquets arrivent dans la chaîne attendue. Je sauvegarde les fichiers du pare-feu avant de procéder à des modifications importantes.
Pour une sécurité globale, je combine le pare-feu avec des étapes de durcissement du système. Cela comprend des paramètres SSH sécurisés, la gestion des correctifs et des services minimaux. J'utilise volontiers un guide pratique comme liste de contrôle : Renforcement des serveurs pour Linux. Je répète régulièrement ces contrôles et je respecte des fenêtres de maintenance fixes. Cela permet de maintenir mes serveurs en forme de manière fiable.
Tests et observation avancés
Je vérifie l'impact extérieur avec Balayage des ports d'un réseau externe et vérifie les sockets ouverts en interne. Au début, je surveille de près les logs afin de détecter rapidement les erreurs de conclusion.
# Sockets ouverts
ss -lntup
# Aperçu d'iptables compact
sudo iptables -S
sudo iptables -L -v -n
# UFW : statut détaillé et logs
sudo ufw status verbose
journalctl -k | grep -i ufw
# Vérification externe (depuis un autre hôte/réseau)
nmap -Pn -p 22,80,443
Pour les changements à haut risque, je prévois une Niveau de repli est activé. Je travaille en screen/Tmux et, si nécessaire, je mets en place une réinitialisation programmée si je me déconnecte. Une fois le test réussi, j'annule la réinitialisation.
# Exemple : désactivation automatique comme ancre de secours (à utiliser avec précaution)
echo "ufw disable" | at now + 2 minutes
# Supprimer à nouveau après un test réussi : atrm
Comparaison des fournisseurs d'hébergement : L'intégration de pare-feu en point de mire
Pour l'hébergement, je mise sur Sécurité proche de la plate-forme. Des politiques individuelles, des déploiements de règles rapides et une bonne surveillance sont payants. Dans les comparaisons actuelles, webhoster.de convainc par des options de pare-feu bien intégrées et un support rapide. Ceux qui préfèrent les configurations de tableau de bord profitent d'instructions claires sur la manière de procéder. Pare-feu Plesk. Le tableau suivant classe les principaux critères.
| Fournisseur | Intégration du pare-feu | Performance | Soutien | Placement |
|---|---|---|---|---|
| webhoster.de | Configuration individuelle | très élevé | top | 1 |
| Fournisseur B | Standard | élevé | bien | 2 |
| Fournisseur C | Standard | bien | satisfaisant | 3 |
Exemples de cas pratiques : Du test à la règle productive
Je commence chaque ensemble de règles dans le Écran ou dans une deuxième session SSH. Ainsi, je peux encore me sauver en cas d'erreur de manipulation. Ce n'est que lorsqu'un hôte de test fonctionne correctement que j'adopte des règles en production. Des règles de retour en arrière et un plan de rollback me donnent une sécurité supplémentaire. À la fin, je documente les modifications de manière succincte dans le journal des modifications.
Pour les serveurs web, j'utilise des modules récurrents : autoriser SSH, libérer HTTP/S, lier localement les ports internes, activer la journalisation, limiter ICMP, bloquer les protocoles superflus. Ensuite, je m'occupe des règles de miroir IPv6 pour qu'aucune faille ne subsiste. Je vérifie toujours les chaînes Docker séparément, car elles définissent leurs propres chemins d'accès. Pour finir, je valide les accès via des contrôles et une surveillance externes. Ainsi, l'interface reste propre et compréhensible [1][2].
Résumé pour les admins
Avec des Règles et quelques commandes, je sécurise les serveurs web de manière fiable. Désengagement par défaut, SSH d'abord, autoriser HTTP/S - cela constitue la base stable. Ports de base de données uniquement locaux ou par liste blanche, journalisation active, respect d'IPv6, vérification des chaînes de dockers. Le stockage persistant et les tests réguliers évitent les mauvaises surprises. Cette routine permet de maintenir les services accessibles et de réduire sensiblement les risques.
Que j'utilise UFW ou directement iptables, l'essentiel est d'avoir une politique claire et économe. Je documente brièvement, je vérifie régulièrement et je limite les exceptions. La restriction en sortie arrête les connexions inutiles et limite les dommages en cas de compromission. Grâce à un regard exercé sur les logs, je détecte plus rapidement les anomalies et réagis de manière appropriée. Le serveur web reste ainsi résistant et la surface d'attaque réduite.
