Question Quelle est la différence entre ces 2 règles iptables?


Essayer d'autoriser le trafic ssh entrant sur le port 22. Le comportement par défaut consiste à supprimer tout le trafic entrant.

Je suis tombé sur 2 articles sur la façon de permettre le trafic. Cependant, ils sont différents.

## open port ssh tcp port 22 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT

Contre

# Allow all incoming SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

Il semble que le premier autorise tout le trafic et spécifie ensuite un réseau spécifique. On dirait que ceux-ci sont mutuellement exclusifs?

Quelles sont les différences entre ces 2 et lequel devrais-je utiliser?


6
2017-08-23 00:30


origine


ce n'est pas vraiment un problème si les règles iptables s'excluent mutuellement. Puisque iptables fonctionne en chaîne, la première règle qui correspond à un paquet sera appliquée. Si une règle ultérieure correspond au même paquet, il est simplement ignoré / même pas vérifié. - mauro.stettler
Je pense que le premier est destiné à être utilisé sur un pare-feu / routeur Linux, pas sur l'hôte SSH. Et le second est destiné à être utilisé sur l'hôte SSH. Je ne peux pas dire si vous configurez une passerelle ou le serveur SSH. - Dru
Serveur Web avec accès SSH - csi


Réponses:


Ces deux ensembles de règles ont des problèmes et je ne les utiliserais pas tels quels.


Dans le premier ensemble, la première règle autorise le nouveau trafic entrant sur le port de destination 22 depuis n'importe où. Ce n'est pas un problème.

Le premier problème est que la deuxième règle autorise le nouveau trafic entrant sur le port de destination 22 à partir d'un sous-réseau spécifique. Ceci est complètement redondant car la première règle a permis le trafic de n'importe où.

Mon hypothèse est que vous avez lu un tutoriel qui utilisait ces règles comme exemples (mutuellement exclusifs), vous conseillant de sélectionner l'une ou l'autre, mais pas les deux.

Le deuxième problème est qu'une autre règle est nécessaire avant que cette règle rende le pare-feu complètement avec état, et cette règle manque ici. Sans cette règle, seul le paquet SYN serait autorisé et la connexion ne serait jamais terminée.

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Le deuxième ensemble de règles a un problème similaire. Je ne sais pas qui a écrit ce jeu de règles à l'origine, mais il a été largement copié sur Internet. Il semble avoir été écrit par quelqu'un qui ne connaissait pas les pare-feu à états, en général, ou iptables en particulier.

Dans cet ensemble de règles, la règle d'entrée autorise le trafic entrant nouveau et établi vers le port de destination 22 depuis n'importe où. Ensuite, la règle de sortie autorise le trafic établi depuis le port source 22 vers n’importe où. C’est essentiellement un miroir de la première règle et quelque chose de similaire est nécessaire si votre politique par défaut sur sortant le trafic est de laisser tomber ou de le rejeter.

Le problème est que ces règles sortantes deviennent rapidement superflues, ce qui entraîne des problèmes de performances ainsi que des problèmes de compréhension pour tous les humains qui doivent lire les règles plus tard. Si vous supprimez du trafic sortant, une seule règle est requise pour le trafic sortant établi (correspondant au trafic entrant autorisé) sur n’importe quel port, quel que soit le nombre de ports entrants que vous autorisez.

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pour un pare-feu hôte où la stratégie d'entrée par défaut consiste à refuser le trafic et la stratégie de sortie par défaut consiste à autoriser le trafic, la plupart de vos règles seront dans la table INPUT. Il suffit d'avoir la règle avec état puis les règles pour ouvrir les ports pour tout trafic entrant dont vous avez besoin.

Par exemple, pour autoriser les connexions ssh et http:

-P INPUT DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

Si vous refusez également le trafic de sortie par défaut, vous devez également autoriser le trafic de retour pour ces connexions entrantes autorisées.

-P OUTPUT DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Et c'est un pare-feu qui est aussi simple et efficace que peut l'être iptables.


16
2017-08-23 01:32



Excellente réponse complète. - Joel E Salas
J'aimerai pouvoir inverser cette réponse 2x. - csi
@MichaelHampton En règle générale, devrions-nous refuser le trafic de sortie par défaut? Serveur Web simple avec courrier sortant et base de données mysql - csi
@ChristopherIckes Cela dépend de votre politique de sécurité et de vos objectifs. Ce n'est généralement pas dangereux, tant que vous autorisez le trafic sortant nécessaire pour vos applications. - Michael Hampton♦


Le premier semble un peu confus quant à ce qu'il essaie de faire. Il semble seulement autoriser les paquets ssh à entrer si iptables n'a pas vu le trafic dans les deux sens, ce qui est très étrange.

La dernière est beaucoup plus judicieuse, mais la deuxième ligne est redondante sauf si vous avez une politique autre que ACCEPT sur votre chaîne OUTPUT. (iptables -L et recherchez "Chain OUTPUT (policy XXXXXX)").

Vous voulez probablement juste la première ligne du bas.


2
2017-08-23 01:14





la ligne 1 du premier ensemble autorisera le trafic du port 22 INBOUND si la connexion = NOUVELLE CONNEXION. La ligne 2 du premier ensemble semble ne pas être nécessaire car elle n'autorise que le trafic du port 22 pour une plage de réseau définie, ainsi que pour les nouvelles connexions. Cependant, la règle précédente de la ligne 2 permettait déjà au trafic de passer.
Cela semble faux ou incomplet

2ème set ligne 1, autoriser le trafic INBOUND sur the0 si port = 22 et correspond à des connexions nouvelles ou établies Ligne 2, tout le trafic OUTBOUND si device = eth0 & port = 22 & la connexion est établie

Cela autorisera les connexions SSH avec cet hôte et autorisera également les connexions SSH sortantes.

2 ème set est votre meilleure option


2
2017-08-23 01:12