Pourquoi avons-nous besoin d'un pare-feu si aucun programme n'est en cours d'exécution sur vos ports?

14

Quand j'essaye de telnet à un port sur un serveur, et s'il n'y a aucun programme écoutant sur ce port telnet meurt avec une erreur «incapable de se relier…». Je comprends que. Mais, pourquoi avons-nous besoin d'un pare-feu s'il n'y a aucun programme à l'écoute sur les ports?

Khaja Minhajuddin
la source
Défense en profondeur. en.wikipedia.org/wiki/Defense_in_Depth_(computing)
Zoredache

Réponses:

31

Il n'y a peut-être pas de service en cours, mais qu'en est-il demain? Vous les avez tous désactivés, mais qu'en est-il de vos utilisateurs? N'importe qui sur un système unix / windows / mac peut ouvrir un port> 1024 sur n'importe quelle machine à laquelle il a accès. Et les logiciels malveillants? Et un virus? Ils peuvent également ouvrir des ports et commencer à fournir des informations au monde, ou commencer à écouter les connexions à partir du réseau.

Le but principal d'un pare-feu n'est pas de bloquer les ports des services dont vous savez qu'ils sont désactivés, mais de bloquer les ports des services que vous ne connaissez peut-être pas. Considérez-le comme un refus par défaut avec seulement certains trous percés pour les services que vous autorisez. Tout utilisateur ou programme démarré par un utilisateur peut démarrer un serveur sur un système auquel il a accès, un pare-feu empêche quelqu'un d'autre de se connecter à ce service.

Un bon administrateur sait quels services doivent être exposés et peut les activer. Un pare-feu sert principalement à atténuer le risque que des serveurs inconnus s'exécutent sur votre système ou votre réseau, ainsi qu'à gérer ce qui est autorisé sur le réseau à partir d'un emplacement central.

Il est important de savoir ce qui fonctionne sur votre machine / serveur et de n'activer que ce dont vous avez besoin, mais un pare-feu offre cette protection supplémentaire contre les choses que vous ne connaissez pas.

gabe.
la source
1
> "Tout utilisateur ou programme démarré par un utilisateur peut démarrer un serveur sur un système auquel il a accès, un pare-feu empêche quelqu'un d'autre de se connecter à ce service." Mais cela ne rendrait-il pas le service inutilisable?
Khaja Minhajuddin
5
@KhajaMinhajuddin oui! C'est exactement le point. (-:
gabe.
2
@KhajaMinhajuddin Vous souhaitez uniquement que les services que vous configurez soient disponibles dans le monde. Vous ne voulez pas que le serveur smtp que super_spam_virus.exe démarre pendant que vous ne cherchiez pas à rechercher des connexions à partir d'autres systèmes infectés. Un pare-feu empêchera cela, même si ce n'est pas une panacée.
gabe.
super_spam_virus.exe ne ressemble pas à Unix et Linux :)
utilisateur inconnu
@userunknown true ... que diriez-vous de a.out, ou d'une version compromise de / bin / ls qui a été copiée sur votre système. Ou, si vous êtes un développeur hg servequi démarre un serveur Web sur votre machine. Le fait est qu'il est trivial de démarrer un serveur sur n'importe quelle machine, qu'il soit utilisé comme «bureau» ou comme «serveur» n'a pas d'importance. Et une fois que ce serveur est démarré, et vous ne savez pas à ce sujet ... eh bien, c'est là que le plaisir commence.
gabe.
3

S'il n'y a aucun programme à l'écoute sur aucun port, vous n'avez pas besoin d'un pare-feu, mais vous ne pouvez pas non plus vous connecter à votre serveur car il est «scellé» du reste du monde.

D'un autre côté ... disons que votre serveur n'a pas de programme s'exécutant localement sur n'importe quel port, mais il sert de passerelle pour les autres ordinateurs derrière lui. Dans ce cas, vous utilisez un pare-feu pour gérer le masquage (NAT) et vous pouvez éventuellement filtrer certains éléments lors du transfert de paquets.

Patkos Csaba
la source
C'est un bon point, mais si je veux que le serveur fasse des choses (je mettrais habituellement openssh et un serveur web). Même avec un pare-feu, je dois ouvrir des ports pour rendre utiles les applications en cours comme openssh et les serveurs Web. Donc, je suppose que ce que je demande, c'est: Existe-t-il des programmes qui ouvrent des ports au monde extérieur qui doivent être bloqués par un pare-feu et qui seraient toujours utiles.
Khaja Minhajuddin
1
Oui il y en a. Pas besoin d'un exemple pour un serveur, mais supposons que vous avez une machine Linux avec X installée et X fonctionnant sur un port réseau. Vous voudriez autoriser votre ordinateur, peut-être quelques autres ordinateurs du LAN à se connecter à votre X. Cependant, vous ne voudriez pas que Joe de France s'y connecte. Un autre exemple, disons que vous configurez plusieurs services VPN sur votre serveur et que vous devez contrôler quels réseaux peuvent voir d'autres réseaux (ou ne pas voir). Ou, disons que vous disposez d'OpenSSH mais que vous souhaitez autoriser la connexion uniquement à partir de votre ordinateur personnel. Il y a beaucoup d'autres exemples.
Patkos Csaba
1
@KhajaMinhajuddin: Pour ssh, vous devez utiliser le /etc/ssh/sshd_configpour sécuriser la machine. PermitRootLogindoit être défini sur Non, vous devez utiliser un mot de passe sécurisé et entretenir la machine avec sudo (vous pouvez utiliser sudo après vous être connecté avec un compte disposant des autorisations sudo). Définir les restrictions avec un pare-feu n'est tout simplement pas le bon outil pour le travail. La même chose serait vraie pour une postgresqlbase de données: utilisez la configuration de la base de données pour définir et révoquer les autorisations.
utilisateur inconnu
3

À strictement parler, il peut ne pas être nécessaire, cependant, gardez à l'esprit qu'un pare-feu peut fournir plus de fonctionnalités que de simplement refuser les connexions sur les ports réseau. Par exemple, DROP contre REJECT.

Tok
la source
1
Quel est l'avantage de DROP par rapport à REJECT?
utilisateur inconnu
Je ne suis pas sûr, mais je crois que DROP ne répond tout simplement pas, donc le demandeur ne sait même pas si la demande a été reçue ou si votre machine existe. REJECT dit que vous êtes définitivement là et que vous ne voulez pas en parler. Et, si quelque chose se cache derrière une porte verrouillée, il pourrait être utile d'essayer de trouver un moyen de découvrir ce qui mérite d'être protégé.
Joe
-5

Mais, pourquoi avons-nous besoin d'un pare-feu s'il n'y a aucun programme à l'écoute sur les ports?

Si vous avez un bureau mono-utilisateur , pas un serveur, vous n'avez pas besoin d'un pare-feu, si aucun service n'est en cours d'exécution, comme sur une installation Ubuntu par défaut.

Windows a eu quelques fois, après avoir pu faire du réseautage, certains services fonctionnant par défaut pour la maintenance, les mises à jour, la transmission des messages internes, etc. Vous ne pouviez pas les arrêter, sans arrêter le fonctionnement des fenêtres, mais elles étaient vulnérables aux attaques externes. Donc, les utilisateurs de Windows avaient besoin d'un pare-feu, et le mème, que tout le monde a besoin d'un pare-feu, se propage rapidement.

Quand ils ont rencontré les gens de Linux, qui étaient souvent des administrateurs de serveur, ils n'ont pas dit "vous n'avez pas besoin d'un pare-feu sur linux" mais "nous avons des pare-feu gratuits comme iptables depuis près d'une décennie".

Un pare - feu personnel , assis sur le système qu'il doit protéger, n'est pas non plus la meilleure idée.

Sur un système de bureau à utilisateur unique, vous n'avez pas besoin d'un pare-feu personnel.

Utilisateur inconnu
la source
3
Regardez la réponse de gabe et repensez. En particulier, les clients Desktop sont vulnérables aux attaques.
Nils
1
@userunknown: un virus peut être un utilisateur de votre bureau. Un démon que vous installez et ne parvenez pas à configurer l'est également.
André Paramés
1
J'exécute des tests de sécurité depuis de nombreuses années et l'accès via des postes de travail est une voie très utile pour propager une attaque. Peu importe que ce soit Windows, Linux, Solaris, peu importe. Verrouillez-le ou perdez-le face à un attaquant. La bonne expression devrait être que vous pourriez avoir besoin d'un pare-feu sur votre bureau - évaluer pleinement les risques dans votre environnement
Rory Alsop
2
@userunknown simplement parce que vous utilisez un ordinateur comme un desktopne signifie pas que ce n'est pas encore serverce ne sont que des mots. Votre desktopa beaucoup de serverscela pourrait potentiellement fonctionner, et peut-être déjà.
gabe.
1
Pensez à CUPS (tout Linux), SLPD (SuSE) et à d'autres choses (KDE-distant, serveur / client iSCSI) qui peuvent s'exécuter sur Linux après une mise à jour. Même si vous avez vérifié avant ces choses peuvent apparaître. S'ils le font, il est bon de les bloquer. BTW - activez votre pare-feu via l'interface graphique (don t allow anything) on RedHat, start CUPS and see if you can connect to it from outside. Then look at iptables-save`: Voila - le port CUPS est ouvert sans apparaître dans l' interface graphique ...
Nils