En général:
L'affichage et la modification de la configuration du pare-feu nécessitent des privilèges d'administrateur ( root
), tout comme l'ouverture de services dans la plage de numéros de port restreinte. Cela signifie que vous devez être connecté en tant que root
ou utiliser sudo
pour exécuter la commande en tant que root. J'essaierai de marquer ces commandes avec l'option [sudo]
.
Contenu:
- Les questions d'ordre ou la différence entre
-I
et-A
- Afficher la configuration actuelle du pare-feu
- Interpréter la sortie de
iptables -L -v -n
- Connaissez votre environnement
- Les chaînes INPUT et FORWARD
- Modules du noyau
1. Ordonner des questions ou la différence entre -I
et-A
La chose à retenir est que les règles de pare-feu sont vérifiées dans l'ordre où elles sont répertoriées. Le noyau arrêtera de traiter la chaîne lorsqu'une règle sera déclenchée qui autorisera ou interdira un paquet ou une connexion.
Je pense que l'erreur la plus courante pour les administrateurs de pare-feu novices est qu'ils suivent les instructions correctes pour ouvrir un nouveau port, comme celui ci-dessous:
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
puis découvrez qu'il ne prendra pas effet.
La raison en est que l' -A
option ajoute cette nouvelle règle, après toutes les règles existantes
et puisque très souvent la règle finale dans le pare-feu existant était celle qui bloque tout le trafic qui n'est pas explicitement autorisé, ce qui entraîne
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
Ou équivalent dans iptables-save:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
et la nouvelle règle ouvrant le port TCP 8080 ne sera jamais atteinte. (comme en témoignent les compteurs restant obstinément à 0 paquets et zéro octet).
En insérant la règle avec -I
la nouvelle règle aurait été la première de la chaîne et fonctionnera.
2. Affichez la configuration actuelle du pare-feu
Ma recommandation pour l'administrateur du pare-feu est de regarder la configuration réelle du noyau Linux, plutôt que d'essayer de diagnostiquer les problèmes de pare-feu à partir d'outils conviviaux. Souvent, une fois que vous comprenez les problèmes sous-jacents, vous pouvez facilement les résoudre dans une affaire prise en charge par ces outils.
La commande [sudo] iptables -L -v -n
est votre ami (bien que certaines personnes aiment iptables-save
mieux). Souvent, lors de la discussion des configurations, il est utile d'utiliser également l' --line-numbers
option pour numéroter les lignes. La référence à la règle #X facilite leur discussion un peu plus facilement.
Remarque: les règles NAT sont inclus dans la iptables-save
sortie , mais doivent listés séparément en ajoutant l' -t nat
option de savoir [sudo] iptables -L -v -n -t nat --line-numbers
.
L'exécution de la commande plusieurs fois et la vérification des compteurs d'incrémentation peuvent être un outil utile pour voir si une nouvelle règle est réellement déclenchée.
[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
Alternativement, la sortie de iptables-save
donne un script qui peut régénérer la configuration du pare-feu ci-dessus:
[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
C'est une question de préférence ce que vous trouverez plus facile à comprendre.
3. Interpréter la sortie de iptables -L -v -n
La stratégie définit l'action par défaut que la chaîne utilise lorsqu'aucune règle explicite ne correspond. Dans la INPUT
chaîne définie sur ACCEPTER tout le trafic.
La première règle de la chaîne INPUT est immédiatement intéressante, elle envoie tout le trafic (source 0.0.0.0/0 et destination 0.0.0.0/0) destiné au port TCP 22 ( tcp dpt:22
) le port par défaut pour SSH vers une cible personnalisée ( fail2ban-SSH
) . Comme son nom l'indique, cette règle est maintenue par fail2ban (un produit de sécurité qui, entre autres, analyse les fichiers journaux du système pour détecter d'éventuels abus et bloque l'adresse IP de l'agresseur).
Cette règle aurait été créée par une ligne de commande iptables similaire à iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
ou se trouve dans la sortie d'iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
. Vous trouverez souvent l'une de ces notations dans la documentation.
Les compteurs indiquent que cette règle a mis en correspondance 784'000 paquets et 65 mégaoctets de données.
Le trafic correspondant à cette première règle est ensuite traité par la fail2ban-SSH
chaîne qui, en tant que chaîne non standard, est répertoriée sous la chaîne OUTPUT.
Cette chaîne se compose de deux règles, une pour chaque abuseur (adresse IP source 117.253.221.166 ou 58.218.211.166) qui est bloquée (avec un reject-with icm-port-unreachable
).
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
Les paquets SSH qui ne proviennent pas de ces hôtes bloqués ne sont pas encore autorisés ni interdits et, maintenant que la chaîne personnalisée est terminée, seront comparés à la deuxième règle de la chaîne INPUT.
Tous les paquets qui n'étaient pas destinés au port 22 ont passé la première règle de la chaîne INPUT et seront également évalués dans la règle INPUT # 2.
La règle INPUT numéro 2 fait que cela est destiné à être un pare-feu d'état , qui suit les connexions. Cela présente certains avantages, seuls les paquets pour les nouvelles connexions doivent être vérifiés par rapport à l'ensemble de règles complet, mais une fois autorisés, les paquets supplémentaires appartenant à une connexion établie ou associée sont acceptés sans vérification supplémentaire.
La règle d'entrée n ° 2 correspond à toutes les connexions ouvertes et connexes et les paquets correspondant à cette règle n'auront pas besoin d'être évalués plus avant.
Remarque: les changements de règles dans la configuration d'un pare-feu avec état n'affecteront que les nouvelles connexions, pas les connexions établies.
En revanche, un simple filtre de paquets teste chaque paquet par rapport à l'ensemble de règles complet, sans suivre l'état de la connexion. Dans un pare-feu pareil, aucun mot clé d' état ne serait utilisé.
La règle INPUT # 3 est assez ennuyeuse, tout le trafic se connectant à l' lo
interface de bouclage ( ou 127.0.0.1) est autorisé.
Les règles INPUT 4, 5 et 6 sont utilisées pour ouvrir les ports TCP 22, 80 et 443 (les ports par défaut pour respectivement SSH, HTTP et HTTPS) en accordant l'accès aux NOUVELLES connexions (les connexions existantes sont déjà autorisées par la règle INPUT 2).
Dans un pare-feu sans état, ces règles apparaissent sans les attributs d'état:
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
ou
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
La dernière règle INPUT, # 7 est une règle qui bloque tout le trafic auquel l'accès n'a pas été accordé dans les règles INPUT 1-7. Une convention assez courante: tout ce qui n'est pas autorisé est refusé. En théorie, cette règle aurait pu être omise en définissant la POLITIQUE par défaut sur REJETER.
Examinez toujours toute la chaîne.
4. Connaissez votre environnement
4.1. Les paramètres d'un pare-feu logiciel n'affecteront pas les paramètres de sécurité maintenus ailleurs sur le réseau, c'est-à-dire que malgré l'ouverture d'un service réseau avec iptables
les listes de contrôle d'accès non modifiées sur les routeurs ou autres pare-feu de votre réseau, il est possible que le trafic soit bloqué ...
4.2. Si aucun service n'écoute, vous ne pourrez pas vous connecter et obtenir une erreur de connexion refusée , quels que soient les paramètres du pare-feu. Donc:
- Confirmez qu'un service écoute (sur la bonne interface réseau / adresse IP) et utilise les numéros de port que vous attendez
[sudo] netstat -plnut
ou utilisez ss -tnlp
.
- Si vos services ne sont pas encore supposés fonctionner, émulez un simple écouteur avec par exemple netcat:
[sudo] nc -l -p 123
ou openssl s_server -accept 1234 [options]
si vous avez besoin d'un écouteur TLS / SSL (vérifiez les man s_server
options).
- Vérifiez que vous pouvez vous connecter à partir du serveur lui-même, c'est-à-dire
telnet <IP of Server> 123
ou echo "Hello" | nc <IP of Server> 123
lorsque vous testez le service sécurisé TLS / SSL openssl s_client -connect <IP of Server>:1234
, avant d'essayer la même chose à partir d'un hôte distant.
4.3. Comprenez les protocoles utilisés par vos services. Vous ne pouvez pas activer / désactiver correctement les services que vous ne comprenez pas suffisamment. Par exemple:
- TCP ou UDP est-il utilisé ou les deux (comme avec DNS)?
- le service utilise-t-il un port fixe par défaut (par exemple quelque chose comme le port TCP 80 pour un serveur Web)?
- est-il également choisi un numéro de port dynamique qui peut varier (c.-à-d. les services RPC comme le NFS classique qui s'enregistrent avec Portmap)?
- Le fameux FTP utilise même deux ports , à la fois un numéro de port fixe et un numéro de port dynamique lorsqu'il est configuré pour utiliser le mode passif ...
- les descriptions de service, de port et de protocole
/etc/services
ne correspondent pas nécessairement au service réel utilisant un port.
4.4. Le filtre de paquets du noyau n'est pas la seule chose qui peut restreindre la connectivité réseau:
- SELinux peut également restreindre les services réseau.
getenforce
confirmera si SELinux est en cours d'exécution.
- Bien qu'ils deviennent légèrement obscurs, les enveloppeurs TCP restent un outil puissant pour renforcer la sécurité du réseau. Vérifiez avec
ldd /path/to/service |grep libwrap
et les /hosts.[allow|deny]
fichiers de contrôle.
5. INPUT
ou FORWARD
chaînes
Le concept de chaînes est expliqué plus en détail ici, mais en bref:
La INPUT
chaîne est l'endroit où vous ouvrez et / ou fermez les ports réseau pour les services s'exécutant localement, sur l'hôte où vous émettez les commandes iptables.
La FORWARD
chaîne est l'endroit où vous appliquez des règles pour filtrer le trafic qui est transféré par le noyau vers d'autres systèmes, des systèmes réels mais aussi des conteneurs Docker et des serveurs Virtual Guest Servers lorsque votre machine Linux agit comme un pont, un routeur, un hyperviseur et / ou fait une adresse réseau traduction et redirection de port.
Une idée fausse courante est que, comme un conteneur Docker ou un invité KVM s'exécute localement, les règles de filtrage qui s'appliquent devraient se trouver dans la chaîne INPUT, mais ce n'est généralement pas le cas.
6. Modules du noyau
Étant donné que le filtre de paquets s'exécute dans le noyau Linux, il peut également être compilé en tant que module dynamique, plusieurs modules en fait. La plupart des distributions incluent Netfilter en tant que modules et les modules Netfilter requis seront chargés dans le noyau selon les besoins, mais pour certains modules, un administrateur de pare-feu devra s'assurer manuellement qu'ils sont chargés. Cela concerne principalement les modules de suivi des connexions, tels que ceux nf_conntrack_ftp
qui peuvent être chargés insmod
.
Les modules actuellement chargés dans le noyau en cours d'exécution peuvent être affichés avec lsmod
.
La méthode permettant de s'assurer que les modules sont chargés de manière persistante lors des redémarrages dépend de la distribution Linux.