Pourquoi Debian est livré sans pare-feu activé par défaut?


15

J'utilise Debian 9.1 avec KDE et je me demande pourquoi il vient sans pare-feu installé et activé par défaut? gufw n'est même pas dans les packages de DVD1.

Les gens doivent-ils se connecter à Internet avant d' obtenir un pare-feu? Pourquoi? Même si tous les ports sont fermés par défaut, divers programmes installés, mis à jour ou téléchargés pourraient les ouvrir (ou pas?) Et je ne souhaite même pas un seul bit laissant ma machine sans ma permission.

Edit: Donc je viens de découvrir iptables mais je suppose que la question reste aussi iptables que le pare-feu semble être plutôt inconnu de la plupart, ses règles par défaut, son accessibilité et sa facilité d'utilisation et le fait que par défaut toutes les règles iptable sont réinitialisées au redémarrage .


Très bonne question. Le serveur Ubuntu n'est même pas livré avec iptablespré-installé! Je suppose que les gens essaient simplement de pousser le principe de bout en bout à la couche 7 extrême ...
rlf

8
Quelle est votre raison de dire que iptables est "inconnu de la plupart"?
SaAtomic

1
J'ai demandé quelque chose de similaire il y a quelque temps unix.stackexchange.com/questions/127397/…
StrongBad

1
"Même si tous les ports sont fermés par défaut, divers programmes installés, mis à jour ou téléchargés pourraient les ouvrir ..." - Si vous supposez la malveillance, les programmes installés, mis à jour ou téléchargés pourraient également effacer les règles du pare-feu.
marcelm

1
@mYnDstrEAm par exemple parce que vous donnez un accès root aux scripts d'installation de ces programmes lorsque vous donnez sudovotre mot de passe en tant quesudo apt-get install package ...
cat

Réponses:


28

Premièrement, Debian a tendance à supposer que vous savez ce que vous faites et essaie d'éviter de faire des choix pour vous.

L'installation par défaut de Debian est assez petite et sécurisée - elle ne démarre aucun service. Et même les extras optionnels standard (par exemple, serveur Web, ssh) qui sont ajoutés à une installation sont généralement assez conservateurs et sécurisés.

Ainsi, un pare-feu n'est pas nécessaire dans ce cas. Debian (ou ses développeurs) suppose que si vous démarrez des services supplémentaires, vous saurez comment les protéger et pouvez ajouter un pare-feu si nécessaire.

Plus important encore, peut-être, Debian évite de faire le choix pour vous quel logiciel de pare-feu utiliser. Il existe un certain nombre de choix disponibles - lequel devrait-il utiliser? Et même en ce qui concerne un paramètre de pare-feu de base, quel paramètre doit être choisi? Cela dit, iptablesest d'une priorité importante, il est donc installé par défaut. Mais bien sûr, Debian ne sait pas comment vous voulez qu'il soit configuré, donc il ne le configure pas pour vous. Et vous préférerez peut-être utiliser iptablesle successeur de nftables, de toute façon.

Notez également que la fonctionnalité de pare-feu est déjà intégrée dans le noyau Linux dans une certaine mesure; par exemple nftableset netfilter. Debian et d'autres distributions Linux fournissent des outils d'espace utilisateur comme iptablespour gérer cette fonctionnalité. Mais ce que vous en faites dépend de vous.

Notez que ces entités ne sont pas nommées de manière cohérente. Pour citer la page Wikipedianftables :

nftables est configuré via l'utilitaire d'espace utilisateur nft tandis que netfilter est configuré via les utilitaires iptables, ip6tables, arptables et ebtables.


4
@sourcejedi Pour autant que je me souvienne, l'installation par défaut de Debian est très similaire depuis au moins Potato, c'est à ce moment-là que j'ai commencé à l'utiliser. Donc, je ne sais pas ce que tu veux dire.
Faheem Mitha

1
@FaheemMitha la valeur par défaut précédente n'était pas pour qu'il accepte les connexions de l'extérieur, de toute façon :)
hobbs

1
+1 pour tente d'éviter de faire des choix pour vous. . Il existe de nombreux outils différents pour gérer les pare-feu, chacun avec des avantages et des inconvénients différents, chacun avec des cas d'utilisation différents. et il existe un nombre encore plus grand de façons de configurer un pare-feu. une défense en profondeur (par exemple, un pare-feu / routeur autonome et des règles iptables par hôte) est bonne, mais je trouverais très ennuyeux si l'installateur Debian présumait savoir comment mon réseau était configuré et quelles règles de pare-feu je voulais. c'est à moi de savoir et à moi de décider.
cas

4
Bonne réponse, bien que "Debian évite de faire le choix pour vous [car] il y a un certain nombre de choix disponibles" n'a pas beaucoup de sens pour moi. Debian fait déjà des choix (par exemple choisir Apache sur lighttpd lorsque je sélectionne "serveur Web", deb sur rpm ... eh bien évidemment) où des alternatives sont disponibles. Le but même d'une distribution n'est-il pas celui de faire des choix?
gd1

1
@ gd1 C'est vrai; Debian fournit et installe par défaut - par exemple Exim, historiquement. Mais ils sont faciles à changer. Et je suppose que iptablesc'est aussi un défaut pour Debian. Mais une chose que Debian ne fait pas seule est une configuration système non évidente pour l'utilisateur.
Faheem Mitha

12

Tout d'abord, je veux répéter ce qui a déjà été dit: Debian s'adresse à un groupe d'utilisateurs plutôt différent que de nombreuses autres distributions grand public, en particulier Ubuntu. Debian s'adresse aux personnes qui connaissent le fonctionnement du système et qui n'ont pas peur de bricoler de temps en temps en échange d'un degré élevé de contrôle sur le système. Ubuntu, par exemple, s'adresse à un public cible très différent: les gens qui veulent juste que les choses fonctionnent et ne se soucient pas (vraiment) de ce qui se passe sous le capot, et ne veulent certainement pas avoir à modifier la configuration du système pour faire des choses travail. Cela a un impact sur un certain nombre d'aspects du système résultant. Et dans une certaine mesure, c'est une beauté de Linux; le même système de base peut être utilisé pour créer des environnements qui répondent à différents besoins. N'oubliez pas qu'Ubuntu est un dérivé de Debian,

gufw n'est même pas dans les packages de DVD1.

Le premier disque contient le logiciel le plus populaire, déterminé par la collecte opt-in de statistiques anonymes à partir des systèmes installés. Le fait que gufw ne soit pas sur le premier disque indique simplement qu'il ne s'agit pas d'un paquet très populaire (en termes de base installée) dans Debian. Il est également facile à installer une fois que vous avez le système de base avec un réseau opérationnel, si vous le préférez aux alternatives.

Les gens doivent-ils se connecter à Internet avant d'obtenir un pare-feu? Pourquoi?

Eh bien, pour une chose, je crois que Debian permet l'installation sur un réseau. (Non seulement le téléchargement de packages à partir du réseau lors d'une installation normale, mais le démarrage littéral de l'installation à partir d'un hôte différent de celui en cours d'installation .) Un pare-feu configuré par défaut avec un ensemble de règles restrictives risquerait d'interférer avec cela. Idem pour les installations qui ont besoin d'un accès réseau sortant pendant le processus d'installation à des fins autres que le simple téléchargement des versions les plus récentes des packages en cours d'installation.

Pour un autre, il y a ce que j'ai mentionné ci-dessus; en règle générale, Debian s'attend à ce que vous sachiez ce que vous faites. Si vous voulez un pare-feu, vous êtes censé pouvoir le configurer vous-même, et vous devez savoir mieux que les responsables Debian quels sont vos besoins particuliers. Debian est un peu comme OpenBSD à cet égard, mais pas aussi extrême. (Lorsqu'ils ont le choix entre rendre le système de base un peu plus sécurisé et le rendre un peu plus utilisable, les responsables d'OpenBSD optent presque toujours pour la sécurité. Cela apparaît dans leurs statistiques de vulnérabilité de sécurité du système de base, mais a d'énormes implications sur la convivialité.)

Et bien sûr, la technicité: la prise en charge du pare-feu est incluse dans le système de base. C'est juste qu'il est défini sur une règle permissive définie par défaut par le noyau, et une installation Debian de base ne fait rien pour changer cela. Vous pouvez exécuter quelques commandes pour limiter le flux de trafic.

Même si tous les ports sont fermés par défaut, divers programmes installés, mis à jour ou téléchargés pourraient les ouvrir (ou pas?) Et je ne souhaite même pas un seul bit laissant ma machine sans ma permission.

Premièrement, les pare-feu sont généralement utilisés pour limiter le trafic entrant . Si vous souhaitez restreindre les sortiesle trafic, c'est une marmite de poisson assez différente; certainement faisable, mais doit être beaucoup plus adapté à votre situation spécifique. Un pare-feu de trafic sortant à blocage par défaut qui laisse ouverts les ports couramment utilisés (où les ports couramment utilisés peuvent être ftp / 20 + 21, ssh / 22, smtp / 25, http / 80, https / 443, pop3 / 110, imap / 143 et un ensemble d'autres), en plus d'autoriser le trafic lié aux sessions établies, ne serait pas beaucoup plus sûr qu'un pare-feu autorisé par défaut. Il est préférable de s'assurer que l'ensemble des packages installés par le système de base est limité à un ensemble de packages bien compris, configurés de manière sécurisée et livrés, et de permettre à l'administrateur de configurer les règles de pare-feu appropriées s'il a besoin de plus de protection que cela.

Deuxièmement, un port fermé (celui qui répond à un TCP SYN avec un TCP RST / ACK, généralement signalé comme "connexion refusée" - il s'agit généralement de l'état par défaut d'un port TCP sur un système en direct prenant en charge TCP / IP en l'absence de configuration contraire ou d'écoute logicielle) n'est pas une vulnérabilité importante, même sur un système non connecté via un pare-feu séparé. La seule vulnérabilité importante dans une configuration entièrement fermée serait s'il y a une vulnérabilité dans l'implémentation de la pile TCP / IP du noyau. Mais les paquets transitent déjà par le code netfilter (iptables) dans le noyau, et un bogue pourrait également s'y cacher. La logique pour répondre avec ce qui aboutit à une "connexion refusée" à l'autre extrémité est suffisamment simple pour que j'aie du mal à croire que ce serait une source majeure de bogues, sans parler des bogues liés à la sécurité;

Troisièmement, les packages sont généralement installés en tant que root, à partir duquel vous (le package) pouvez de toute façon modifier les règles iptables à votre insu. Ce n'est donc pas comme si vous gagniez quelque chose comme demander à l'administrateur humain d'autoriser manuellement le trafic via le pare-feu hôte. Si vous voulez ce type d'isolement, vous devez avoir un pare-feu distinct de l'hôte qu'il protège en premier lieu.

Je viens donc de découvrir iptables mais je suppose que la question reste aussi iptables que le pare-feu semble être plutôt inconnu de la plupart, ses règles par défaut et l'accessibilité et la facilité d'utilisation.

Je dirais en fait que le contraire est vrai; iptables en tant que pare-feu est bien connu . Il est également disponible sur pratiquement tous les systèmes Linux que vous rencontrerez probablement. (Il a remplacé ipchains pendant le développement qui a conduit à la version 2.4 du noyau Linux, vers l'an 2000 environ. Si je me souviens bien, le plus grand changement visible par l'utilisateur entre les deux pour le cas d'utilisation courant du pare-feu était que la règle intégrée les chaînes sont désormais nommées en majuscules, comme INPUT, au lieu de minuscules, comme input.)

Si quoi que ce soit, iptables peut faire autre chose que le pare-feu qui n'est pas largement utilisé ou compris. Par exemple, il peut être utilisé pour réécrire les paquets IP avant qu'ils ne passent par le pare-feu.


Excellent et détaillé résumé du problème. Cependant, vous avez écrit "Deuxièmement, un port fermé n'est pas une vulnérabilité importante, même sur un système non connecté via un pare-feu séparé." Vouliez-vous éventuellement écrire «ouvert»? Sinon, pouvez-vous expliquer en quoi un port fermé est une vulnérabilité? Merci.
Faheem Mitha

"Il a remplacé ipchains quelque temps dans le développement du noyau 2.5, si je me souviens bien. C'est quelque chose comme il y a 15 ans maintenant." - 2,3, en fait. Ce qui le rapproche de 20.
Jules

Excellente réponse, d'accord. J'ajouterais également que lorsque vous installez à partir de l'iso d'installation minimale possible, actuellement netinstall, une partie du processus d'installation consiste en fait à installer les packages d'apt sur le réseau, de sorte que votre installation n'est pas obsolète dès le départ, c'est actuel, ce qui est exactement ce que vous voulez, mais vous pouvez également choisir d'installer à partir du disque, de sorte que l'installation a vraiment besoin d'une connexion réseau immédiatement opérationnelle. Mais cette réponse était très bonne.
Lizardx

1
Commentaire tardif: "Souvenez-vous qu'Ubuntu a commencé comme un fork de Debian, et conserve à ce jour une grande similitude avec Debian." Pour autant que je sache, Ubuntu est toujours dérivé de Debian. Ce n'est pas une fourchette.
Faheem Mitha

6

Si je devais deviner, sans être à la tête d'une génération de développeurs et de mainteneurs Debian, ma supposition serait la suivante:

Debian est principalement conçue comme un système d'exploitation serveur, les branches sid et testing ont pour objectif principal la création de la prochaine branche stable, et, au moment du gel, elles sont gelées, et la nouvelle écurie est tirée des tests, comme est arrivé avec Stretch.

Compte tenu de cela, je suppose en outre, je devrais confirmer cela avec un ami sysadmin, que les pare-feu de centre de données sont des périphériques externes, une sécurité beaucoup plus élevée (au moins on espère que ce soit le cas)), aux serveurs et gérer le principal tâches de pare-feu. Même sur un petit LAN avec un routeur, c'est le cas, le routeur est le pare-feu, je n'utilise aucune règle de pare-feu locale sur aucun de mes systèmes, pourquoi le ferais-je?

Je pense que peut-être les gens confondent leurs installations locales de Debian de bureau ou d'un serveur de fichiers unique dans un bureau ou à la maison avec le travail réel connecté à Debian, qui je crois se concentre principalement sur l'utilisation en production.

Je ne suis pas sûr de cela, mais après plus d'une décennie d'utilisation de Debian, c'est mon sentiment, à la fois en tant que développeur et partisan de Debian à bien des égards.

Je peux vérifier cela, car c'est en fait une bonne question, mais je suppose que les vrais réseaux sont pare-feu aux points d'entrée du réseau, pas par machine, ou du moins, c'est l'idée de base qui pourrait peut-être conduire Debian. De plus, bien sûr, si ce n'était pas le cas, l'administrateur système configurerait les règles du pare-feu par machine, en utilisant quelque chose comme Chef, sans compter sur une installation par défaut, ce qui ne serait pas quelque chose que vous auriez tendance faire confiance, par exemple, aux configurations par défaut de Debian ssh ne sont pas celles que j'utiliserais personnellement par défaut, par exemple, elles autorisent la connexion root par défaut, et c'est au sysadmin de corriger cela s'il trouve que c'est une mauvaise pratique .

Autrement dit, il y a une supposition de compétence, je pense à propos de Debian, qui peut être absente dans d'autres distributions. Comme dans, vous changez ce que vous voulez changer, créez des images, gérez-les avec un logiciel de gestion de site, etc. Ce ne sont là que quelques possibilités. Par exemple, vous n'utiliseriez jamais le DVD pour créer un nouveau serveur, du moins jamais en production, vous utiliseriez probablement quelque chose comme le netinstall minimal, c'est ce que j'utilise toujours, par exemple (j'utilisais une image encore plus petite , mais ils l'ont abandonné). Si vous regardez ce qui est inclus dans cette installation de base, vous obtenez une bonne idée de ce que Debian considère comme crucial et de ce qu'il ne fait pas. ssh est là, par exemple. Xorg ne l'est pas, Samba ne l'est pas.

On pourrait également demander pourquoi ils sont retournés à GNOME en tant que bureau par défaut, mais ce ne sont que des décisions qu'ils prennent et que leurs utilisateurs ignorent fondamentalement car vous pouvez créer les systèmes comme vous le souhaitez (c'est-à-dire, pour obtenir des bureaux Xfce, je ne fais pas n'installez pas Xdebian (comme dans Xubuntu), j'installe simplement le noyau Debian, Xorg et Xfce, et c'est parti). De la même manière, si je voulais un pare-feu, je le configurerais, j'apprendrais les tenants et aboutissants, etc., mais je ne m'attendrais pas personnellement à ce que Debian soit livré avec cette option activée, ce serait en fait assez ennuyeux pour moi si c'était le cas. . Peut-être que mes vues à ce sujet reflètent une sorte de consensus que vous pourriez également trouver en interne dans Debian.

De plus, bien sûr, il n'y a vraiment rien de tel que Debian, il existe diverses images d'installation, netinstall, installation complète, toutes varient de barebones, cli uniquement, à un bureau utilisateur raisonnablement complet. Les utilisateurs de production créeraient probablement des images par exemple, qui seraient configurées comme l'utilisateur le souhaite, je sais que si je configurais un serveur Debian, je commencerais par les bases brutes et je le construirais jusqu'à ce qu'il fasse ce que je voulais.

Ensuite, vous avez le monde des serveurs Web, qui est une boule de cire entièrement différente, ceux-ci ont des questions de sécurité très différentes, et, comme l'a dit un vieil ami à moi bien connecté au piratage souterrain, quelqu'un qui gère un serveur Web sans savoir comment sécuriser il peut également être appelé quelqu'un dont le serveur appartient à des crackers.


Je n'aime généralement pas les réponses longues comme celle-ci :) mais vous touchez un point très pertinent. Si vous exécutez un serveur Web, il doit accepter les connexions au serveur Web. On peut se demander quelle valeur vous obtenez de la configuration d'un deuxième logiciel pour dire: oui, je veux accepter les demandes Web envoyées à mon serveur Web. Et ce cas d'utilisation semble être plus soigné à l'intérieur de Debian que le bureau.
sourcejedi

sourcejedi, lol, si ça n'avait pas été long, je ne serais pas arrivé à la question du serveur web, c'est la dernière chose que j'ai ajoutée. Mais dans ce cas, vous avez un utilisateur clairement nouveau, moins expérimenté, qui peut ne pas se rendre compte que différentes distributions couvrent des cas d'utilisation et des utilisateurs radicalement différents. Donc, ils n'ont fondamentalement aucune information, et à ce stade, il est difficile de savoir ce qu'ils savent et ne savent pas, ergo, trop de mots. Ou juste assez. Difficile à savoir.
Lizardx

"De plus, bien sûr, il n'y a vraiment rien de tel que Debian". Je ne suis pas sûr de ce que vous entendez par là - il y a certainement une telle chose comme Debian. C'est le système d'exploitation produit par le projet Debian. Techniquement, il s'agit d'une famille de systèmes d'exploitation, mais bien sûr, la variante Linux est très dominante. Il existe différentes méthodes d'installation, mais elles installent toutes le même système. Bien sûr, vous avez beaucoup de liberté sur les parties à installer.
Faheem Mitha

Pas dans le sens où cela fait référence à une chose. Ce que vous notez comme c'est techniquement, c'est ce que je veux dire. Autrement dit, Debian est-elle l'image d'installation du DVD à laquelle cette personne a fait référence? Est-ce l'installation principale que vous obtenez sur netinstall? S'agit-il du pool de packages apt pour l'architecture spécifique? Est-ce la piscine secondaire pour ça? Le pool de tests? etc. En ce qui concerne la façon dont les utilisateurs définissent quelque chose, je dirais qu'il n'y a rien de tel, ce qui existe réellement est le projet, Debian, qui régit les règles de conditionnement et les paquets qui définissent apt et .deb. C'est pourquoi je l'aime d'ailleurs, ce sont les règles qui définissent le projet.
Lizardx

Difficile à expliquer, mais je vais essayer: je n'installe pas 'Debian', j'installe disons, Debian Testing / Buster, variante 64 bits, à partir de l'iso netinstall. Debian est donc le parapluie qui fonctionne et crée ce que j'installe. C'est au cours des années que j'ai réalisé pourquoi j'aime tant Debian, ils ont des règles strictes, et ces règles sont pour moi ce qui définit vraiment quelque chose comme Debian et non Ubuntu. Ainsi, par exemple, si vous prenez un ensemble de paquets de Debian et créez Ubuntu, quand cesse-t-il d'être Debian? ce sont les mêmes packages, au moins pendant un certain temps, et je dirais, cela s'arrête lorsque vous cessez de suivre les règles dfsg.
Lizardx

5

L'idée générale est que vous ne devriez pas avoir besoin d'un pare-feu sur la plupart des systèmes, sauf pour les configurations complexes.

SSH est en cours d'exécution ,, lorsque vous avez installé un serveur. Rien d'autre ne devrait être à l'écoute et vous voudrez probablement pouvoir vous connecter à ssh.

Lorsque vous installez un serveur Web, vous vous attendez à ce que le serveur Web soit disponible, n'est-ce pas? Et pour le réglage de base, vous pouvez lier le serveur Web à l'interface du réseau privé uniquement, par exemple 192.168.172.42 (votre IP LAN local), au lieu de 0.0.0.0 (toutes les ips). Vous n'avez toujours pas besoin d'un pare-feu.

Bien sûr, tout peut ouvrir un port> 1024, mais lorsque vous rencontrez des logiciels non approuvés (ou des utilisateurs non approuvés), vous devez faire plus que simplement installer un pare-feu. Au moment où vous devez vous méfier de quelque chose ou de quelqu'un, vous avez besoin d'un concept de sécurité non seulement d'un logiciel. C'est donc une bonne chose lorsque vous devez réfléchir activement à votre solution de pare-feu.

Maintenant, il y a bien sûr des scénarios plus complexes. Mais lorsque vous en avez un, vous devez vraiment régler le pare-feu vous-même et ne pas laisser un système semi-automatique comme ufw le faire. Ou vous pouvez même utiliser ufw, mais vous l'avez décidé et non la valeur par défaut du système d'exploitation.


1
IIRC, les pare-feu pour ordinateurs personnels étaient une réponse à l'une des failles de sécurité de Windows 95, à savoir que tous les ports étaient ouverts par défaut. Sur la plupart des systèmes d'exploitation, avant et depuis, un port n'est ouvert que si un service écoute réellement sur ce port. Secondairement, les pare-feu sont souvent configurés pour supprimer les paquets en silence, plutôt que de les rejeter explicitement, de sorte qu'il est difficile de dire qu'il existe un système avec une adresse IP.
bgvaughan

Je ne sais pas ce que vous voulez dire avec un port ouvert sans service d'écoute. Où le paquet doit-il aller et pourquoi devrait-il s'agir d'une faille de sécurité? Et laisser tomber des paquets dans votre pare-feu ne vous cachera pas, mais rendra encore plus évident qu'il existe une machine avec un pare-feu. Lorsque votre système n'est pas en ligne, le routeur avant votre système envoie une réponse «inaccessible». Ce n'est pas le cas lorsque votre machine est là (ni lorsque vous acceptez, rejetez ou supprimez des paquets). Vous pouvez vérifier l'effet vous-même en faisant un tracerouteà votre système.
allo

1
Lorsque je lance un traceroute vers vous, je peux voir 7 sauts. Le premier est mon PC, le dernier est le point d'entrée de votre réseau. Lorsque votre PC est hors ligne, le 6e saut envoie une réponse "inaccessible". Lorsque votre PC est connecté mais protégé par un pare-feu, le 6e saut envoie une réponse normale et le 7e supprime (ou rejette) le paquet. Et vous ne contrôlez pas le 6e saut, vous ne pouvez donc pas truquer ou déposer des paquets là-bas.
allo

1
"les anciens systèmes Windows, comme 95 et je pense que XP, garderaient tous les ports ouverts, même s'il n'y avait pas de services en cours d'exécution" Je n'ai absolument aucune idée de ce que vous voulez dire en maintenant un port ouvert sans l'écouter. Lorsqu'un paquet arrive, vous pouvez soit l'envoyer vers un programme d'écoute, rejectlui ou droplui. Il n'y a pas de concept de "port ouvert sans écoute". Peut-être que vous voulez dire abandonner (accepter sans l'envoyer à un programme).
allo

1
Personnellement, j'ai un refus par pare-feu par défaut ainsi qu'un repli sûr. Mais je comprends quand Debian laisse l'utilisateur installer le pare-feu. J'expérimente beaucoup, d'autres choisissent le serveur Web dans la tâche et ont terminé. Aucune idée de la chose win95, mais je suppose que cela n'a pas d'importance aujourd'hui de toute façon;).
allo

4

Les gens doivent-ils se connecter à Internet avant

Oui

obtenir un pare-feu?

Même si tous les ports sont fermés par défaut

Désolé, ils ne le sont pas. rpcbindsemble être installé, activé et écouter sur le réseau par défaut.

EDIT: Je pense que cela a été corrigé dans le dernier programme d'installation, c'est-à-dire pour Debian 9 (Stretch) . Mais avec les versions précédentes de Debian, je ne me sentirais pas très sûr de les installer (puis de les mettre à jour) sur un réseau wifi public.

Pourquoi?

Je soupçonne que les gens supposent que

  1. le réseau local n'attaquera pas vos services réseau
  2. il existe déjà un pare-feu entre votre réseau local et Internet en général.

Bien que ce dernier soit une pratique courante, par exemple pour les routeurs grand public, je ne pense pas qu'il soit garanti. Sans surprise, la première hypothèse n'est pas documentée; elle n'est pas non plus sensée.

À mon avis, le problème avec rpcbind est un exemple d'un point plus général. Les gens peuvent essayer de promouvoir Debian, et il a de nombreuses fonctionnalités intéressantes. Mais Debian est à la traîne d'Ubuntu en ce qui concerne sa politesse et sa convivialité, ou même sa fiabilité pour ceux qui souhaitent apprendre de tels détails.

les programmes téléchargés pourraient les ouvrir (ou pas?) et je souhaite même pas un seul bit de quitter ma machine sans ma permission.

Vous êtes certainement libre d'installer un pare-feu avant de commencer à télécharger et à exécuter un logiciel aléatoire dont vous n'êtes pas sûr de ce qu'il fait :-p.

Je suis d'accord en partie, il est alarmant d'installer Linux et de ne trouver aucune interface configurée pour ce qui est une couche de sécurité très connue. Personnellement, j'ai trouvé utile de comprendre comment le pare-feu Windows par défaut est configuré. Il veut que vous puissiez "faire confiance" à un réseau domestique, et dans les versions plus récentes, l'installation express ignorera même si vous faites confiance au réseau actuel. L'objectif principal semble être de faire la distinction entre les réseaux domestiques, les connexions non protégées comme un modem directement connecté et les réseaux wifi publics. Notez que UFW ne prend pas cela en charge de toute façon.

Fedora Linux seul a essayé de fournir quelque chose comme ça, dans firewalld. (Les paquets semblent également disponibles dans Debian ...). L'interface graphique n'est pas aussi "conviviale", disons, que GUFW.


Je suis heureux que vous ayez qualifié le commentaire re ubuntu de `` pour quelqu'un qui essaie d'apprendre '', je pense que dans un sens, c'est la vraie réponse, debian n'est pas un système créé pour ce groupe, et l'existence d'ubuntu pourrait en fait se résumer à ce fait. En tant que personne n'essayant pas d'apprendre, c'est la raison exacte pour laquelle je préfère toujours Debian à Ubuntu, par exemple. Je jouais avec des pare-feu locaux, mais à la fin, j'ai commencé à les voir plus comme des jouets que de véritables utilitaires, je veux dire des trucs gui, pas des iptables etc. Vos points 1. et 2. je pense couvrent la pensée derrière cette décision, Je suis d'ailleurs d'accord avec cette décision.
Lizardx

@Lizardx que j'ai édité pour essayer de souligner à quel point je décourage la situation avec les réseaux wifi publics rpcbind + :). Je pense que je sais d'où vous venez dans ce commentaire, mais je ne suis pas entièrement d'accord. Je suis heureux d'avoir accès à un arsenal d'armes de poing dans le référentiel, mais j'aime avoir un défaut défini (ou plusieurs, par exemple si vous comptez XFCE comme l'option populaire "pas GNOME3") comme base fiable pour construire à partir de .
sourcejedi

Le wifi public est évidemment le cas d'utilisation où les pare-feu sur un système sont très importants pour les utilisateurs réguliers. Mais comme indiqué dans d'autres réponses, Debian suppose que vous le savez si vous l'installez et que vous l'utilisez de cette façon. Peut-être plus proche de la façon dont FreeBSD ou OpenBSD pourraient voir cette question? Parlant uniquement pour moi, je suis un ÉNORME fan des sélections de groupes de paquets par défaut Debian, je ne les ai jamais vu créer quelque chose que je voudrais réellement exécuter, contrairement à XUbuntu, ou divers spins Debian qui ont créé de belles installations par défaut . Cela dit, je suis d'accord, une option non GNOME 3, XFCE serait très agréable.
Lizardx

4
gufw est horrible. ufw n'a presque aucun sens, et ne stocke-t-il pas les règles en XML? Pouah. même un ensemble de règles iptables manuel est plus facile à gérer.
user2497

3

La philosophie traditionnelle d'Unix a toujours été BAISER et d'exécuter / d'exposer le minimum de services.

Plusieurs services doivent également être installés explicitement, et même certains sont liés à localhost, et vous devez activer leur visibilité sur votre réseau local / sur Internet (MySQL, MongoDB, snmpd, ntpd, xorg ...). Il s'agit d'une approche plus judicieuse que d'activer un pare-feu par défaut.

Vous n'avez besoin que de la complexité qu'un pare-feu apporte à partir d'un certain point, et ce besoin peut être diminué étant derrière un routeur d'entreprise ou un appareil domestique, il semble donc raisonnable de laisser la décision à l'utilisateur. Un pare-feu, comme tant d'autres logiciels de sécurité, peut également fournir une fausse sensation de sécurité s'il n'est pas correctement géré.

L'orientation de Debian a toujours été les gens les plus techniquement orientés qui savent ce qu'est iptables; il existe également plusieurs wrappers bien connus, des interfaces en mode texte ou graphique qui peuvent être facilement installés.

En plus de cela, qu'il s'agisse de trop ou de moins de logiciels installés, c'est une question d'opinion. Pour un vétéran de longue date, il est livré avec trop de logiciels et de services installés par défaut, en particulier en mode serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.