Bienvenu dans l’informatique nazi.
Donc toi, t’es le numéro 12851, tu restes dans ton 2m² sinon on te tue.
J’veux dire, relax, le libre c’est aussi la possibilité de customiser son système, et ne pas avoir à modifier 150k rules pour ce faire est bon.
Et je dois qu’interdire l’accès à tout et n’importe quoi augmente la sécurité, d’autant plus que la majorité des serveurs actuels n’ont qu’une tâche ou un service à gérer.
[quote=“Cluxter”]
[quote]Un parefeu pour augmenter la sécurité ? Pourquoi pas un cure-dent pour guérir le cancer ?
Un parefeu n’a rien à voir avec la sécurité, dans 98% des cas.[/quote]
Parce que ?[/quote]
Heu, mpff, si t’as du mal à comprendre, tu peux acheter un livre sur les bases du réseau …
J’vais cependant faire un résumer sur le sujet suivant : "mettre une policy input à DENY est débile"
De base, je pars dans l’idée que les policy sont ACCEPT, sans autre règle.
- Le trafic entrant ne passe le kernel que si une application est en écoute sur le port (un serveur est lancé avec un accept(2), ou le paquet fait parti d’une connexion déjà initiée
- L’administrateur est au courant des serveurs installés sur la machine, il l’est a configurer et ne souhaites donc pas qu’ils soient injoignable
- Les clients qui initient des connexions doivent pouvoir avoir des réponses sur la connexion
À ce point, tu devrais déjà avoir compris que mettre une policy input à DENY est débile, parcque tu ne peux que bloquer :
- du trafic désiré (par un serveur que tu as installé, ou par un client)
- du trafic déjà bloqué par le kernel (parcque personne n’est en écoute)
Bon, histoire de pousser un peu plus loin, nous allons étudier la grande résistance de la configuration suivante :
- policy input DENY
- policy output ACCEPT
- rule input ACCEPT (established)
Je suis un méchant, je cherche à transmettre des trucs avec la machine.
Deux cas:
- Je ne suis pas déjà sur la machine
- Je suis déjà sur la machine
Dans le premier cas, avec les deux configurations, tu ne pourras joindre qu’un gentil processus déjà placés sur le serveur (rappel: le méchant n’est pas sur la machine, cette dernier est clean). Un parefeu ne peut protéger les gentils processus contre eux même, il est inutile.
Dans le deuxième cas, étudions le comportement le plus efficace, rationnel et logique à déployer pour, mettons, faire un botnet, ou dump le disque sur un serveur “pirate”.
- Initier la connexion depuis l’extérieur
- Initier la connexion depuis l’intérieur
Alors je sais pas toi, mais moi, concepteur de botnet, je ne vais pas scanner quelque 3.5milliards d’IP de façon à savoir lesquels sont en lignes et corrompus, avant de lancer mon attaque “pirate”.
Je pense qu’il est quand même “un peu” plus simple de mettre en place l’algorithme suivant :
- Le client corrompu, lorsqu’il le peut, créé une connexion vers un serveur “pirate” et lui dit “coucou, je suis à tes ordres, que puis-je faire pour toi ?”.
Et dans ce cas précis, ben le méchant passe tes règles de parefeu.
[quote]
Ce n’est pas avec ce genre d’attitudes qu’on démocratisera Linux. Je ne me plaçais pas d’un point de vue poweruser de PC qui sait coder les yeux fermés mais d’un point de vue “je suis un type qui veut un système d’exploitation correct pour utiliser son ordinateur sans avoir besoin de savoir ce qu’est un kernel”. 95% des gens quoi.
Ca serait un peu comme si un pilote de rallye disait “pas besoin de clignotants sur les voitures”.[/quote]
Donc pour toi, la démocratisation de Linux passe par un esclavage massif ?
Je préfère rester dans “un groupe d’élite” qui respectent un minimum les droits humains.
Les relations informatiques ne sont pas compliqués, elles sont même binaire. Dans toute relation informatique, on trouve un maître, et un esclave.
Dans beaucoup de systèmes (ios, android, dos, macos ?), le maître est rarement l’humain …
Avoir une opinion comme la tienne est, franchement, écoeurante …