Configuration pare-feu sur serveur domestique

Le
mpg
Bonjour,

J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web, mail,
imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de configurer le
pare-feu, me reposant sur le fait que la machine en question n'a pas d'IP
publique (elle est derrière une freebox en mode routeur), mais d'après ce
que j'ai lu sur ce groupe, ce n'est pas à considérer comme une protection
suffisante.

Pour les conseils techniques, je lirai la page de man d'iptables ou me
renseignerai sur un autre groupe. Mon premier problème est que je dois
déterminer une politique de filtrage, choisir des règles; et que j'ai un
peu de mal (même après avoir lu la FAQ firewalls ici). Parmi les questions
que je me pose :

- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus

- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes
services en conséquence ?

- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Quand on parle de bloquer les connexions, il s'agit uniquement des
nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un
parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il
essaye ensuite de parler à un autre port ?

Merci d'avance pour vos réponses.

Manuel.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
m3rlin
Le #882645
Salut Manuel,

- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...


Aucune application visible.. mais en cas de rootkit tu n'est jamais
sur, il est donc preferable de bloquer par default tout les ports en
entrée, et juste d'authoriser ceux voulu!

- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes
services en conséquence ?


Je pense pas, ton serveur web (par exemple) ecoutera toujours sur le
port voulu.
Par contre si tu souhaite filtrer tes ports en sortie le probleme peu
ce poser.
Il te faudra donc plus que filtrer les ports de sortie, filtrer les
ports de destination.

- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Quand on parle de bloquer les connexions, il s'agit uniquement des
nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un
parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il
essaye ensuite de parler à un autre port ?


Je pense que le terme "connexion nouvelle" designe la "poignet de
main" entre les deux machines, et bloquer les nouvelles connexion
permet de bloquer certaine attaque (comme le SYNFlood)

Voilà j'espere avoir pu t'aider un peu

Michael

Fabien LE LEZ
Le #882643
On 09 Sep 2007 16:24:19 GMT, mpg
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...


Aujourd'hui, 16:24, tu penses qu'aucune application n'écoute sur ces
ports. Peut-être te trompes-tu ; peut-être la situation
évoluera-t-elle sans que tu t'en rendes forcément compte.

- D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).


Une application serveur écoute sur un port donné (par exemple, 80 pour
Apache). Si une machine tente de se connecter sur ce port, la
connexion peut être bloquée (par le firewall), refusée (par
l'application en question, pour celles qui permettent ce genre de
configuration), ou acceptée.
Une fois qu'elle est acceptée, il peut effectivement y avoir un
changement de port, mais tout ça est très bien géré automatiquement,
tu n'as pas à t'en préoccuper, que ce soit dans la configuration du
firewall (et/ou du routeur -- ici, la freebox), ou dans la config de
l'application.

- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ?


Il y a le protocole FTP, qui est une chiotte à gérer ; mais
heureusement, comme il est bien connu, un bon firewall doit être
capable de reconnaître le protocole et de faire passer les connexions
qui vont bien. Tu peux te contenter d'ouvrir le port 21 en entrée.

Certaines applications peuvent décider d'écouter sur un port différent
à chaque démarrage (ou sur plusieurs ports). Exemple : utorrent. Il
faut alors désactiver cette fonctionnalité.

D'autres protocoles moins connus peuvent avoir des comportements
bizarres ; il faut bien lire la documentation, et gérer au cas par
cas. Mais comme il s'agit d'un serveur local, sans connexion entrante
depuis Internet, je ne pense pas que tu rencontres le cas.

Eric PETIT
Le #882641
Dans le message :fc16n7$1jrl$,
mpg a écrit:
Bonjour,

J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web,
mail, imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de
configurer le pare-feu, me reposant sur le fait que la machine en
question n'a pas d'IP publique (elle est derrière une freebox en mode
routeur), mais d'après ce que j'ai lu sur ce groupe, ce n'est pas à
considérer comme une protection suffisante.


"freebox en mode routeur"

- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer
les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...


Tu a au moins un problème de terminologie ;-)
Plutôt qu' "entrée" tu devrais utiliser le terme "écoute" .
Je te conseille de chercher de la prose sur les réseaux en général et les
firewall en particulier notamment ce qui peut toucher à la sécurité. On en
trouve généralement assez facilement. Tu perdra peut être moins de temps à
lire et comprendre qu'a tenter de mettre en place un iptable pas forcément
utile. Et ensuite tu saura quoi faire ;-)

.....
- (Peut-être lié à la question précédente.) D'après ce que j'ai
compris, il y a plusieurs « états » pour une connexion (nouvelle ou
déjà établie). Quand on parle de bloquer les connexions, il s'agit
uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion
établie : si quelqu'un parle à mon port 22 (ouvert), la connexion
est-elle toujours établie s'il essaye ensuite de parler à un autre
port ?


cette question est en contradiction avec la première citation, as tu
redirigé des ports vers ton serveur ?
Si oui alors il est bon de se préoccuper de la sécurité, y compris si ton
serveur n'a pas d'IP publique.


--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!

Publicité
Poster une réponse
Anonyme