Bonjour, je poste ce journal au sujet d'une question que je me pose et à laquelle je n'ai jamais eu de réponses qui m'ont satisfait. Ce sont les pare-feux et dans deux cas :
1) C'est celle de l'utilité des pare-feux sur un système sûr.
Je parle aussi uniquement du pare-feu « simple », celui qui se contente d'ouvrir ou fermer les ports. Je ne prend pas non plus en compte le cas ou l'on ferme un port vers internet mais qui reste ouvert sur le réseau local. Je parle bien du type courant de pare-feu « tout ou rien ».
En effet, si je ne me trompe pas : Le pare-feu autorise ou refuse une connexion à un port. Hors, un port non utilisé est toujours fermé. Un exemple, si je n'ai pas de connexion ssh, et rien sur le port 22, personne ne pourra rentrer sur ma machine par là. J'ai lu plusieurs fois : « Si tu n'utilises pas un service, bloque le port ». La réponse me venant à l'esprit est bien évidemment de tout simplement couper le service. Je ne vais pas faire tourner ssh sur ma machine et fermer le port l'utilisant, ça me semble un peu insensé.
Quelque chose m'aurait-il donc manqué quelque part, où c'est quelque chose d'inutile dans un cas aussi simple.
2) Un pare-feu derrière un routeur :
Deuxième cas. La majorité des gens sont derrière un routeur, leur modem Machin-box autre que Freebox configurer par défaut (auquel cas il n'est pas en routeur). À quoi sert un pare-feu sur les ordinateurs présent derrière le routeur ? En effet, ces ordinateurs ne sont simplement pas visible depuis l'extérieur à moins de rediriger un port. Alors à quoi bon fermer les ports ? Le premier cas était dans le cas d'un système sûr dans lequel on a confiance, mais ce deuxième point s'applique même à un système mal configurer où l'on ne sait rien de ce qui tourne dessus. Quelque-chose m'échappe peut-être sur le fonctionnement du pare-feu et des routeurs, mais ceci m'étonne.
Et vous, quel est votre politique de sécurité sur vos ordinateurs ? ceux reliés directement à internet et ceux en local. Pare-feu pour tous ? juste sur le serveur (pour ceux qui ne sont pas derrière un routeur)… Pensez-vous qu'un pare-feu est vraiment utile, ou juste un patch pour système mal conçu ?
Je parle bien des pare-feu les plus basique, pas du cas ou on laisse l'on veut ouvrir un port juste à quelques postes particuliers.
Voilà, c'était mon questionnement du dimanche matin.
PS : routeur ne semble pas connu par le correcteur de Linuxfr ce que je trouve assez amusant.
Journal Les pare-feu
2
mar.
2008
# Moi
Posté par libre Cuauhtémoc . Évalué à 1.
Néanmoins, en effet, tout cela doit se faire par des firewall intermédiaire en général en cas de grand réseau,plus simple àexploiter qu'un firewall sur toutes les machines finale.
2- A protéger des attaques du réseau local ? Bon, certes quand tu as quelques machines dans ton LAN, c'est complétement absurde. Mais , sur de grands réseau, les attaques viennent plus souvent de l'interieur.
Moi ce que je fais, je laisse tout psser depuis le LAN, je laisse passer quelques services sur le routeur, mais sur des ports exotique, que j'apprends par coeur. Par exemple ,je peux rediriger le port 653984 vers le port 22 d'une mmachine qui elle interdira les connexions root.
PS: vite , file à la messe, tu va être en retard ;-)
[^] # Re: Moi
Posté par seginus . Évalué à 6.
1) J'ai bien précisé que je parle du cas simple avec une connexion simple, pas du cas où l'on veut activer un service que sur une portion du réseau (bien que dans ce cas, ça doit bien souvent pouvoir se faire de l'application elle-même).
2) C'est là un cas bien particulier de gros réseaux locaux, je parle plutôt du cas de l'utilisation familiale avec une machin-box qui partage internet à tout au plus une dizaine d'ordinateurs. Dans ceux cas, à quoi ça sert les pare-feu sur les ordinateurs branchés derrière ? Surtout que dans bien des cas, le réseau derrière, c'est juste une seule machine.
[^] # Re: Moi
Posté par pix (site web personnel) . Évalué à 9.
L'application notepad.exe veut se connecter a 23.45.75.135 (vilainpirate.com), Autoriser ? Oui/Non
Ce qui permet de protéger la passoire de tout ce qui est déjà rentré par l'intermédiaire de couveuses a virus style outlook, ie et compagnie de ne pas pouvoir sortir. Du coup le cheval de Troie rentré va avoir bien du mal à se rendre utile sans pouvoir téléphoner maison.
[^] # Re: Moi
Posté par Obsidian . Évalué à 5.
L'application notepad.exe veut se connecter a 23.45.75.135 (vilainpirate.com), Autoriser ? Oui/Non Ce qui permet de protéger la passoire de tout ce qui est déjà rentré par l'intermédiaire de couveuses a virus style outlook, ie et compagnie de ne pas pouvoir sortir. Du coup le cheval de Troie rentré va avoir bien du mal à se rendre utile sans pouvoir téléphoner maison.
C'est hallucinant parce que :
1) Il vaut mieux empêcher le spyware de rentrer et, à tout le moins, le nettoyer plutôt que de mettre une couche par dessus quelque chose qui est percé en soi.
2) Qu'est-ce qui empêche un programme malfaisant installé en local de tripatouiller le pare-feu pour s'octroyer les droits dont il a besoin ?
[^] # Re: Moi
Posté par pasBill pasGates . Évalué à 3.
Je te propose de chercher les mots "defense in depth" sur google...
2) Faut avoir les droits de changer la config du firewall pour ca, ce qui n'est pas donne si t'es un user.
[^] # Re: Moi
Posté par briaeros007 . Évalué à 7.
Il disait plutôt "j'évite qu'un voleur s'introduise chez moi, plutot que de le laisser s'introduire puis essayer de l'empecher de sortir".
En tout cas c'est ce que j'ai compris.
2°) Comme la majorité des user travaillent en mode "root", car historiquement, si on était pas dans ce mode, on ne pouvait pas avoir accés à un certain nombre de fonctionnalité (utilisation de certaines devices, ...) ...
[^] # Re: Moi
Posté par Obsidian . Évalué à 5.
"Defense in depth". Non mais je rêve !
[^] # Re: Moi
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Moi
Posté par z a . Évalué à 2.
ensuite, si ton service réseau est troué et qu'on lui injecte du code qui va faire des trucs réseaux inhabituels (autrement dit que tu n'auras pas autorisés explicitement, et on ne va pas considérer le cas du blocage/acceptation interactive), et ben il aura plus de mal.
[^] # Re: Moi
Posté par Obsidian . Évalué à 5.
Tu arrives à rediriger le port 653984 en TCP/IP ? Faudra que tu me montres comment tu fais :-)
[^] # Re: Moi
Posté par kowalsky . Évalué à 2.
[^] # Re: Moi
Posté par briaeros007 . Évalué à 4.
[^] # Re: Moi
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Moi
Posté par suJeSelS . Évalué à 1.
# Poser le problème
Posté par ahuillet (site web personnel) . Évalué à 6.
je ne suis pas sûr que tu poses très bien le problème.
Ce que tu appelles pare-feu « simple » ca n'existe pas vraiment sous Linux - ce que je veux dire c'est que ton pare-feu « simple » c'est juste une configuration possible de Netfilter. Et qu'un pare-feu pas « simple », c'est une autre configuration de Netfilter, qui est même pas forcément plus compliquée.
Et je ne vois pas en quoi ce type est courant... sous Windows peut-être j'en sais rien, mais c'est bien tout.
Bref l'intérêt du pare-feu déjà c'est d'imposer une politique de sécurité (autant que faire se peut), c'est-à-dire que si quelqu'un lance un serveur Apache et que toi tu l'interdis, si tu bloques son port ton interdiction sera respectée. Il faut nuancer cela parce que si le mec lance un serveur Apache qui écoute sur le port 80 ca veut dire qu'il est root et donc qu'il peut reconfigurer Netfilter. Mais ça marche pour les ports > 1024 avec les utilisateurs normaux.
Ensuite, bon, si le service tourne pas ça n'a pas forcément beaucoup de sens de mettre un pare-feu pour bloquer le port correspondant. Mais ça te permet de dropper les paquets (-j DROP) au lieu de renvoyer RST (-j REJECT ou je ne sais comment ça s'appelle). C'est pas révolutionnaire mais ca rend la machine plus discrète et ça embête les scanners.
Pour ton deuxième point, j'avoue que c'est pas forcément très utile. Maintenant c'est pas pour les ressources que ça bouffe sur un système Linux, mon firewall je l'ai configuré une fois y a cinq ans, et en cinq ans ma config a changé - j'ai pas toujours été derrière un routeur notamment. Je vois une réponse possible - bloquer les ports en sortie peut être utile, j'utilise pas Windows mais j'ai entendu parler de mochetés qui essayaient d'établir des connexions en sortie on sait pas trop pourquoi.
Enfin, ma politique de sécurité actuelle (config actuelle: le modem routeur de Tele2 en première ligne, toutes mes machines derrière) est pare-feu pour tous,
qui autorise tout en sortie dans toutes les directions, ainsi que tout ce qui rentre du réseau local, droppe les paquets par défaut, et n'autorise que ssh en entrée de l'extérieur - sur un port bizarre que je connais par coeur (ça évite les tentatives de bruteforce). L'intérêt c'est qu'il y a un seul point d'entrée de l'extérieur (ssh), c'est bien moins difficile à gérer.
Donc pour conclure :
1 - pas de réponse claire de ma part, juste quelques pistes
2 - tu parles "des pare-feux les plus basiques" (attention l'orthographe...), ceux là ne servent certainement à rien en effet, c'est pour ça qu'on fait des configurations plus élaborées
3 - chez moi politique de sécurité assez basique mais qui je crois marche plutôt bien
Je me relis pas j'ai la flemme. :)
# un pare-feu derrière un routeur
Posté par Benjamin (site web personnel) . Évalué à 5.
Le point "un pare-feu derrière un routeur" s'intitule dans ton cas "un pare-feu derrière un routeur à translation d'adresse" qui, en effet, ne fait rien rentrer si aucun port n'est configuré pour laisser entrer ...
Dans mon cas le plus courant (ma boite) où l'on a des routeurs qui routent :) des blocs d'ip, on a un pare-feu sur le routeur qui filtre port par port les machines de l'intérieur, en entrant comme en sortant. Très utile pour imposer une politique et contrôler les services autorisés.
Si un client me dit "j'ai un apache et ssh uniquement sur ce serveur" je ne vais ouvrir que 80 et 22 tcp, et d'autres trucs internes (dns & ntp en udp typiquement, et ce uniquement vers les machines dédiées à ces services)
Après, on ouvre aussi en sortie des ports classiques à la demande des clients (http, ssh etc.). Dans le cas contraire, comme tout est fermé, le vilain pirate ne pourra pas faire grand chose :
- pas possible de virer le pare-feu interne de la machine : c'est le routeur qui s'en charge
- pas possible de rentrer autrement que par un service officiellement ouvert (genre faille applicative, toutça)
- une fois entré, pas possible d'aller chercher son script à la mode avec fetch ou wget : cela limite l'usage de bots de piratage parallèles ...
- pas possible d'écouter sur un port exotique pour y laisser une backdoor : ce port sera fermé en entrée sur le routeur.
Bref, cela complique quand même rudement la tâche de piratage.
[^] # Re: un pare-feu derrière un routeur
Posté par Aldoo . Évalué à 3.
Mais avec l'avènement d'IPv6, ce genre de chose devrait remplacer de plus en plus la translation d'adresses, d'où l'intérêt d'avoir des règles de filtrage explicites.
[^] # Re: un pare-feu derrière un routeur
Posté par eon2004 . Évalué à 1.
Il faut aussi faire attention que certains firewalls bloquent les ports en IPv4 mais pas en IPv6 !
[^] # Re: un pare-feu derrière un routeur
Posté par kowalsky . Évalué à 3.
ecoute sur son port quand même, et ne laisse passer que
les bons réseaux, mais une faille dans Samba, et hop, c'
est cuit :)
# Freebox en mode routeur fainéant
Posté par pralines . Évalué à 8.
Il m'est arrivé 2 ou 3 fois, sur 2 installation distinctes que des freebox configurées en mode routeur, à la suite d'un reboot des boites, que celles-ci se comporte en bridge !
Non, je ne fume pas.
Mes machines (et celles de mes parents) sont sous ubuntu, en mode dhcp (avec ip déterminées par adresse mac).
A la suite d'un reboot de freebox, mes machines n'arrivaient plus à contacter d'autres équipements dur le réseau local en 192.168.0.x, et là je m'aperçois que le machine sur laquelle je travaille a reçu une adresse du genre 88.163.xxx.xxx, comme si la freebox était en mode bridge...
comme si la freebox n'avait pas eu le temps de charger sa configuration (depuis les serveurs de free ?) et que ma machine avait reçu une ip fournie par un routeur/dhcp de free.
heureusement que je n'avais pas de machine sous windows, sinon j'étais bon pour un déverminage en règle, voire une réinstallation.
Envoyé depuis mon Archlinux
[^] # Re: Freebox en mode routeur fainéant
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Freebox en mode routeur fainéant
Posté par Olivier (site web personnel) . Évalué à 1.
Non, je ne fume pas.
Oui, c'est effectivement le cas. En cas de "hard reset" de la freebox (le fait de la brancher/débrancher plusieurs fois), cela supprime la configuration actuelle, et remet la configuration par défaut : Mode bridge.
La première machine du LAN qui fait alors une requête DNS se retrouve à ce moment là avec une adresse IP internet (88.X.X.X).
Ce genre de "hard reset" peut arriver si tu as des micro-coupures de courant à répétition.
# Même question
Posté par Wawet76 (site web personnel) . Évalué à 1.
Sur un serveur que j'ai configuré pour ma boite chez OVH, seul SSH et Apache sont ouverts sur l'extérieur. Les autres services (MySQL et Tomcat en particulier) sont configurés pour n'accepter les connexions que sur l'interface 127.0.0.1
Si j'utilise nmap depuis une machine distante, je ne ne vois bien que les port 22 et 80 d'ouvert. Y a-il un intérêt à mettre en place un firewall sur la machine dans ce cas ?
[^] # Re: Même question
Posté par alexissoft . Évalué à 2.
[^] # Re: Même question
Posté par GG (site web personnel) . Évalué à 2.
C'est installer Knockd (un truc qui ressemble à ça).
Le principe, pour se connecter en SSH:
Tu envois des signaux particuliers (à définir) dans un ordre précis avec un contenu précis (tout est à définir, précis ou pas, tu es libre de créer tes propres règles), sur des ports précis (règles à déterminer) éventuellement fermés.
Alors, Knocd te reconnaissant, va ouvrir le port prédéterminé (au choix, celui que tu auras défini), pour ton adresse IP.
Et hop, tu n'as plus qu'à lancer ton authentification Ssh, par login/pass ou mieux par clef.
Et voilà, ton serveur reste tout le temps fermé de partout, mais tu peux quand même t'y connecter.
Je n'ai jamais essayé ça, mais c'est bien tentant :)
On est loin du réseau familliale, mais si c'est pour intervenir sur le poste de ta grand-mère (sous Linux), il n'y a pas de raisons de laisser des ports ouverts.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Même question
Posté par Zenitram (site web personnel) . Évalué à 5.
Et au moment où tu auras besoin d'accéder à ta machine en urgence, tu sera chez un client, qui aura autorisé seulement les ports classiques 22/80/443 (normal, ils vont pas ouvrir tous les ports... Déja que si tu as le droit au port 22, c'est bien, dans mon entreprise c'est 80/443 seulement. Mais tu peux pas utiliser ces ports pour ton test, puisque tu as Apache dessus :) ). Avec ta super-protection, tu te seras protégé de... Toi-même.
Les protections, c'est bien, mais en faire trop, c'est pas bon non plus...
Un petit fail2ban suffit amplement pour virer les emmerdeurs sans que ça t'embête toi.
[^] # Re: Resttrictions de port
Posté par GG (site web personnel) . Évalué à 3.
Mon frère à un serveur qui écoutes sur le 443 et qui lui permettra ensuite de se connecter plus librement ailleurs.
Cela lui fait une machine pour rebondir, à maintenir en état, à sécuriser... c'est vrai.
Sinon, tu peux aussi configurer knockd pour écouter d'une manière spéciale sur le 22.
Sinon, oui, c'est dommage d'être bloqué par un excès de sécurité... :)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Même question
Posté par kowalsky . Évalué à 3.
OpenSSH fais bien son boulot, pourquoi se torturer
a mettre en place une surcouche ?
[^] # Re: Même question
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
>a mettre en place une surcouche ?
C'est une forme de protection par l'obscurité. En principe, Ssh fera son travail. Mais s'il existe une faille, elle ne pourra pas être activée car l'attaquant n'aura pas toqué correctement.
[^] # Re: Même question
Posté par kowalsky . Évalué à 3.
Je comprend que ça puisse attirer certaine personnes, moi
je trouve que c'est sale, générateur de bug, de faille, de dos
et autre joyeuseté qui font qu'OpenSSH, c'est bien. :)
[^] # Re: Même question
Posté par feth . Évalué à 3.
Qui plus est à peine plus efficace qu'un telnet : tout passe en clair ! Ça pourrait avoir du sens si tu dois toquer sur des machines distinctes et jamais les mêmes pour ouvrir d'autres machines, et encore. Si on veut fermer les ports chez mémé tout en continuant à avoir du ssh simplement, ce qu'il faut à mon sens c'est monter un simple VPN (connexion sortante depuis la machine de mémé).
# DROP!
Posté par Prae . Évalué à 1.
Tu pars du principe que ta machine sera la plus sûr du monde ad-vitam eternam.
Hors, si un méchant tipiak arrives à t'executer un backdoor sur ta machine pour ouvrir un port telnet/ssh/whatever-avec-un-shell sur un port que tu n'as pas bloqué sur le firewall de ton système, et bien, pleure ...
[^] # Re: DROP!
Posté par Obsidian . Évalué à 5.
L'orthographe correcte est « Or, ... »
Merci de votre attention.
[^] # Re: DROP!
Posté par Obsidian . Évalué à 3.
Si c'est un méchant Tipiak, qu'il arrive à installer une backdoor sur ta machine et que ton firewall tourne sur cette même machine, alors le programme lui-même va faire ouvrir le port dont il a besoin ! C'est ridicule !
La seule chose vraie est que n'importe quel programme user sur un Unix normalement constitué peut écouter légitimement les ports au dessus de 1024 sans priviliège. Maintenant, si ce n'est pas souhaitable, il faut empêcher ton méchant pirate d'accéder à ta machine, pas bloquer des ports à postériori, sinon tu vas empêcher les programmes réguliers de fonctionner normalement.
C'est dingue, çà, d'ailleurs : on s'efforce toujours de pallier les conséquences directes d'un problème au lieu d'essayer d'en déterminer les causes. Ca semble être du pur bon sens et, pourtant, c'est encore tellement fréquent que c'est enseigné dans les cours de management.
[^] # Re: DROP!
Posté par briaeros007 . Évalué à 0.
Parce que n'importe quel utilisateur peut modifier la conf du fw ?
Avoir une backdoor ne veut pas forcément dire "avoir quelqu'un en root sur la machine".
il faut empêcher ton méchant pirate d'accéder à ta machine,
tout a fait d'accord.
pas bloquer des ports à postériori,
Tu voulais peut etre dire "a priori".
Et puis l'un n'empêche pas l'autre.
sinon tu vas empêcher les programmes réguliers de fonctionner normalement.
Si tu gère le firewall , tu es admin. Si tu es admin, tu sais quel programme s'execute sur ta machine, et il a besoin de quel port.
En bref :
Même si je ne suis pas forcément pour un fw qui s'execute sur le système, avoir un fw qui
drop+log les paquets attaquant de mauvais ports:
- plus discret lors des (nombreux) scans
- evite, si il y a un probleme de sécu avec un port fermé (leak d'information permettant une attaque autre part avec les numéro de séquence par ex) d'être vulnérable.
- surveille (avec la regle log) les personnes non autorisé essayant de se connecter (a couplé avec un fwlogwatch par exemple)
- surveille l'état de la/des machines /du réseau
verifie les données sur les ports ouverts
- empeche le syn flood, le ping of death, ....
etc...
C'est dingue, çà, d'ailleurs : on s'efforce toujours de pallier les conséquences directes d'un problème au lieu d'essayer d'en déterminer les causes.
On peut faire les deux !
on pallie aux conséquences directe d'un problème de façon génériques.
Et cette "palliation" permet aussi de nous avertir quand on rencontre ce problème, et a partir de là on recherche les causes (0-day).
[^] # Re: DROP!
Posté par Prae . Évalué à 1.
Oui et ?
S'il ouvre un port, le mec de l'extérieur, il se connecte à quoi s'il y a du firewalling sur l'ensemble des ports ?
Le but est pas d'empécher l'installation d'une backdoor: c'est d'empécher son utilisation de l'extérieur !
(Voire même que les données du programme "tipiak" n'envoie rien sur le réseau)
[^] # Re: DROP!
Posté par Batchyx . Évalué à 1.
[^] # Re: DROP!
Posté par Prae . Évalué à 1.
Fait un "iptables [...] --port 2222 -j DROP" puis fait un "socket -sl 2222"
Et enfin, fait un telnet de l'extérieur sur l'adresse IP de la machine et le bon port ... tu verras que tu te verras rejeter.
[^] # Re: DROP!
Posté par Batchyx . Évalué à 1.
# ma config
Posté par Gasp75 . Évalué à 1.
je ne sais pas si c'est une méthode sûre, mais voilà comment je protège mes serveurs :
- sur les serveurs : le pare-feu accepte tout en entrée et en sortie. Les seules règles restrictives sont celles de fail2ban.
- en frontal : une machine sur laquelle tourne un IPCOP avec l'extension BOT (Block out traffic). Les ports des services publics sont redirigés tels quels (80, 443), et les ports d'administration (ssh, webmin) sont redirigés sur des ports exotiques. Tout connexion initiée depuis l'intérieur du réseau est refusée (ça me pose des problèmes avec les apt-get update d'ailleurs).
Donc, à priori, je pense que mon réseau est à peu près protégé, puisque si une backdoor est installée à la faveur d'une faille, elle ne pourra pas atteindre l'extérieur, ni modifier les règle du pare-feu, puisqu'elles sont présentes sur une autre machine, inaccessible depuis la dmz (impossible de pinguer ou de se connecter ou quoi que ce soit à ipcop depuis une dmz).
Cela dit, il y a sans doute beaucoup mieux à faire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.