Pourquoi Debian est livré sans pare-feu activé par défaut?
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 non?) Et je ne souhaite même pas un seul bit laissant ma machine sans ma permission.
Edit: 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, 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 .
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, iptables est prioritaire, 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 le successeur de iptables, 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. nftables et netfilter. Debian et d'autres distributions Linux fournissent des outils d'espace utilisateur comme iptables pour 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 Wikipedia nftables :
nftables est configuré via l'utilitaire d'espace utilisateur nft tandis que netfilter est configuré via les utilitaires iptables, ip6tables, arptables et ebtables.
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 haut niveau 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 et conserve à ce jour une grande similitude avec 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 littéralement le démarrage de l'installation à partir d'un hôte différent de celui sur lequel est installé .) Un pare-feu configuré par défaut, un ensemble de règles restrictives risquerait d'interférer avec cela. Même chose avec 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 tout 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 non?) 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 restreindre le trafic entrant . Si vous voulez restreindre le trafic sortant , 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 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, sécurisés 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é "- il s'agit généralement de l'état par défaut d'un TCP sur un système en direct prenant en charge TCP/IP en l'absence de configuration contraire ou de logiciel qui l'écoute) n'est pas un 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 filtre réseau ( iptables) dans le noyau, et un bogue pourrait se cacher là aussi. 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é; les bogues liés aux services réseau sont presque toujours dans les services eux-mêmes, et s'ils ne le sont pas en cours d'exécution ou n'écoutant rien d'autre que des interfaces de bouclage, il n'y a vraiment rien pour qu'un attaquant puisse se connecter et exploiter.
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 de l'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 l'opposé 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 quelque chose, iptables peut faire des choses autres que le pare-feu qui ne sont pas largement utilisées ou comprises. Par exemple, il peut être utilisé pour réécrire les paquets IP avant qu'ils ne passent par le pare-feu.
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 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 réseau local 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 de 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 ce 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 hypothèse de compétence, je pense concernant 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 la netinstall minimale, 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 avez 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 faire 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 un peu ennuyeux pour moi si c'était le cas. . Peut-être que mes opinions à 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.
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 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 fiables (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.
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. rpcbind semble être installé, activé et à l'écoute sur le réseau par défaut.
EDIT: je crois 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
- le réseau local n'attaquera pas vos services réseau
- 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 par les routeurs grand public, je ne pense pas que ce 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 en retard sur Ubuntu en ce qui concerne sa politesse et sa convivialité, ou même sa fiabilité pour ceux qui veulent apprendre ces détails.
les programmes téléchargés pourraient les ouvrir (ou pas?) et je ne souhaite même pas un seul bit 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.
La philosophie traditionnelle d'Unix a toujours été KISS et exécuter/exposer le minimum de services.
Plusieurs services doivent également être installés explicitement, et même certains viennent 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 à l'utilisateur cette décision. 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é celle des 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.