6 votes

Que signifie -P INPUT ACCEPT dans le cadre d'iptables ?

Je suis assez novice en matière d'iptables, et j'essaie de déterminer si j'ai configuré mon jeu de règles de manière appropriée. En ce qui concerne le -P INPUT ACCEPTER Dans le cadre de ma question, j'essaie de déterminer si cela est valable dans le contexte des règles que je veux appliquer. Veuillez voir ci-dessous pour plus de détails.

J'ai utilisé iptables-restore avec un fichier contenant les règles suivantes. Essentiellement, j'essaie d'autoriser le trafic de bouclage, les connexions établies/liées, SSH et HTTP. Tout autre trafic doit être rejeté.

*filter
:fail2ban-ssh - [0:0]

# Input chain rules
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
# Reject all other inbound traffic
-A INPUT -j REJECT   

# Output chain rules
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Forward chain rules
-A FORWARD -j REJECT                                    

# fail2ban-ssh chain rules
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

COMMIT

Si je cours iptables -S je reçois le message suivant :

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

J'ai fait un peu de lecture sur iptables, et je crois comprendre que les premières lignes (par exemple, " -P INPUT ACCEPTER ") signifie essentiellement que l'action par défaut, si aucune des autres règles ne s'applique, est d'accepter le trafic (dans ce cas, pour l'entrée, le transfert et la sortie).

Si c'est le cas, dois-je mettre explicitement les lignes suivantes dans mon fichier de règles et restaurer iptables à nouveau ?

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

Merci beaucoup par avance à tous ceux qui liront cette question complète ! Elle est un peu longue, mais j'ai pensé qu'il était nécessaire d'inclure tous les détails ci-dessus pour expliquer correctement mon scénario.

1voto

the_velour_fog Points 477

En gros, à part ce que fail2ban bloque, vos règles actuelles signifient que vous n'avez pas de pare-feu.
Examinez comment votre pare-feu réagirait dans le scénario suivant :

Vous exécutez MySQL ou une autre base de données qui écoute sur une connexion TCP pour les connexions locales - mais vous ne voulez pas de connexions distantes.
Ensuite, une machine distante malveillante tente d'accéder à un serveur mysql sur le port 3306 .
En supposant que fail2ban ne les a pas bloqués, la question est la suivante est-ce qu'une de vos règles existantes va vous aider ? Qu'en est-il :

  • -A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable - NOPE
  • -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT - NOPE
  • -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT - NOPE

etc... rien ne correspond et DROP la connexion, donc votre politique INPUT s'applique et la connexion est acceptée.
Considérons ensuite le même scénario pour tous les autres services fonctionnant sur votre machine. - si fail2ban n'a pas bloqué, votre serveur les laissera entrer.
Alors oui, je vous suggère d'ajouter à votre iptables-restore règles

-P INPUT DROP
# Any unmatched packets  on FORWARD chain will be dropped
-P FORWARD DROP

Note : alors que les règles iptables ne persistent généralement pas au-delà d'un redémarrage, une politique le fera. Dans ce cas, la règle ci-dessus verrouillera une session SSH s'il n'y a pas de règle ACCEPT correspondante qui a été verrouillée. règle ACCEPT correspondante qui a été chargée après un redémarrage du serveur - c'est-à-dire que cette politique vous bloquerait.
Personnellement, j'utiliserais toujours la politique de dépôt, mais certaines personnes préfèrent conserver la politique de dépôt. -P INPUT ACCEPT et utiliser à la place

-A INPUT DROP

en tant que règle au bas de votre chaîne INPUT comme une "quasi" politique. Vous devez être prudent avec cela et relire vos règles lorsque vous modifiez votre mur de fichiers, mais si vous n'avez pas configuré iptables pour qu'il restaure ses règles au redémarrage, cet arrangement signifierait que vous pourriez revenir dans votre machine.

1voto

MadHatter Points 77602

Pour répondre à la question que vous avez posée, les polices doivent apparaître dans une fenêtre normale. iptables-save mais pas en tant qu'argument de -P règles.

Ils doivent plutôt figurer au début, avec la déclaration de toute chaîne personnalisée, ainsi que leurs politiques, comme suit :

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]

Le tiret de votre chaîne personnalisée est un argument de politique manquant, car les chaînes définies par l'utilisateur n'ont pas de politique.

Notez qu'avec votre pare-feu tel qu'il est écrit, si vous changez toutes les politiques en DROP votre serveur aura des difficultés à effectuer des recherches DNS et beaucoup de choses échoueront de manière imprévisible.

1voto

Sagar Shedge Points 11

Au fait, je viens de jeter vos règles (les INPUT ) en fffuu pour en extraire une version simplifiée. Elle montre seulement qui peut établir des connexions :

ACCEPT     all  --  127.0.0.0/8          0.0.0.0/0    
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0    dports: 80
DROP       tcp  --  146.0.77.33/32       0.0.0.0/0    dports: 22
DROP       tcp  --  62.75.236.76/32      0.0.0.0/0    dports: 22
DROP       all  --  0.0.0.0/0            0.0.0.0/0    
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Vous pouvez voir que votre approche fail2ban est en fait cassée : La deuxième règle accepte toutes les connexions ssh ; les règles 4 et 5 (les règles DROP) sont cachées (elles ne peuvent jamais être atteintes).

Je suppose que votre politique par défaut est ACCEPT que vous pouvez voir comme la dernière règle dans la liste simplifiée. Comme vous pouvez également le constater, la politique par défaut de INPUT n'a pas d'importance ici car l'avant-dernière règle élimine déjà tous les paquets qui ne correspondent pas à une règle précédente. C'est à cause de votre -A INPUT -j REJECT règle.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X