Configuration du firewall

a marqué ce sujet comme résolu.

Bonjour,

J'ai ouvert un port 2020 sur mon réseau externe qui pointe vers le port SSH de ma Raspberry PI. Je débute en réseau et j'aimerais savoir si il est utile de filtrer les connexions TCP entrantes sur ma PI (par exemple, n'autoriser que le SSH, HTTP, imap2 …) alors que je n'ai ouvert qu'un port UDP/TCP sur mon réseau vers ssh.

Pour filtrer le trafic sortant, on conseille souvent d'accepter les ports ssh, imap2, etc.. (les ports basiques et sécurisés) et également les connexions qui ont déjà été établies (état ESTABLISHED et RELATED). Pourquoi faut-il autoriser les connexions établies sans savoir si elles sont sécurisées ? Si à chaque redémarrage, les règles pare-feu se remettent automatiquement, les connexions n'ont pas le temps de s'établir non ?

Pouvez-vous m'aider avec ces questions ?
Merci d'avance !

+0 -0

Je vais tenter une réponse mais ça fait longtemps que je n'ai pas fait de configuration de pare-feu.

J'ai ouvert un port 2020 sur mon réseau externe qui pointe vers le port SSH de ma Raspberry PI. Je débute en réseau et j'aimerais savoir si il est utile de filtrer les connexions TCP entrantes sur ma PI (par exemple, n'autoriser que le SSH, HTTP, imap2 …) alors que je n'ai ouvert qu'un port UDP/TCP sur mon réseau vers ssh.

La base d'un bon-pare-feu, c'est "j'interdis tout, dans toutes les configurations possibles et je ne laisse passer que ce qui m'intéresse."

Pour filtrer le trafic sortant, on conseille souvent d'accepter les ports ssh, imap2, etc.. (les ports basiques et sécurisés)

Voir ma réponse ci-dessus : on accepte ce dont on a besoin, et on rejette tout le reste.

Pourquoi faut-il autoriser les connexions établies sans savoir si elles sont sécurisées ?

Je commence par related, c'est plus simple : "RELATED" est un état qui signifie qu'il y a une nouvelle connexion mais qui a un rapport avec une connexion déjà existante. On va donc l'accepter. C'est comme ça que marche FTP par exemple, qui utilise 2 ports.

On le sait déjà en fait. Une connexion est "établie" (ESTABLISHED) à partir du moment ou la "poignée de main" en TCP a eu lieu sans erreur (SYN=>SYN/ACK=>ACK). On va donc automatiquement accepter les paquets qui son concernés : ça va plus vite que de devoir vérifier chaque règle.

Un scénario pour bien comprendre :

  • Je souhaite consulter zestedesavoir.com :
  • j'ai autorisé le DNS, je vais donc trouver qui est www.zestedesavoir.com
  • j'envoie une requête sur le port 80 de l'ordinateur : mon pare-feu trouve une règle correspondante (et laisse passer s'il est bien réglé. (flag SYN))
  • je reçois une réponse sur un port aléatoire (flag SYN/ACK). Il y a une règle qui indique de laisser passer, c'est bon.
  • je réponds sur le port 80 de www.zestedesavoir.com (flag ACK) : la première règle s'applique à nouveau. => A partir de là, laz connexion est en état ESTABLISHED. => La règle "-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT" dit qu'en entrée, je regarde l'état et s'il est à ESTABLISHED ou RELATED, (et donc que j'ai déjà autorisé une connexion de ce type en cours) je laisse passer sans réfléchir.

Ca fonctionne comme dans les congrès/réunions. Je montre ma convocation à l'entrée. On vérifie mon identité et on me fournit un badge avec mon nom et ma photo. Si je repasse la sortie et l'entrée, je n'ai qu'à montrer mon badge et pas à refaire toutes les vérifications.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte