Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de seginus :
- [25/09@06:43] Dvorak : Josselin Mouette VS Bépo (1 / N)
- [03/04@06:04] Lecteur Ogg pas bon marché
- [05/02@20:47] Coup de gueule contre la poste
- [13/01@23:16] utilité du i386
- [02/09@14:37] Ion
- [05/08@07:02] Firefox avec Real ?
- [19/07@08:15] encore une perle du journalisme
- [04/07@07:09] rénumération des auteurs de logiciels libres
- [03/06@07:11] recueil de documentation
- [29/05@08:10] Sauvegarde d'un disque
- [24/05@19:52] DIVX IDX et NFS
- [20/05@17:45] konqueror et redimentionnement des images
- [19/05@21:39] envoi fichier par ftp
- [12/05@20:08] Connaitre les XP
- [28/04@20:32] conseil programmation grahique
- [20/04@18:16] Wanadoo -> Free
- [19/04@19:20] logiciel de sauvegarde
- [15/04@21:24] Samba pour Linux
- [15/04@19:41] Montage démontage.
- [14/04@18:51] creation site sur Windows
Journal : Les pare-feu
Posté par seginus () le 02 mars 20081) 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.
> Lire le journal (40 commentaires, moyenne: 3).
Moi
1- Tu raisonne comme si une machine appartenait à un seul réseau, et avec une seule interface réseau, ce qui n'est pas toujours le cas. Maintenant, comme je fais, si je veux autoriser un service uniquement sur une patte précise ?
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 () le 02/03/2008 à 09:52. (lien). Évalué à 6.Merci.
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 (page perso, ) le 02/03/2008 à 10:32. (lien). Évalué à 9.Sous windows (il y en a sous Linux mais c'est plus rare) les pare-feu sont le plus souvent applicatif, ce qui, souvent, pond des trucs du style:
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.--
La hiérarchie, c'est comme les étagères : plus c'est haut, moins ça sert.-
[^]Re: Moi
Posté par Obsidian () le 03/03/2008 à 01:21. (lien). Évalué à 5.C'est une des choses qui m'agacent profondément dans le monde Windows. Les pare-feux personnels en tant qu'applications, en soi, c'est déjà une hérésie, parce qu'ils fonctionnent sur la machine qu'ils sont censés protéger. On a tous trouvé ça absurde quand c'est sorti, mais maintenant, les gens se sentent en sécurité parce qu'ils « ont fait les démarches nécessaires ».
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 () le 03/03/2008 à 03:29. (lien). Évalué à 3.1) Donc si j'ai bien compris, a la maison chez toi, tu ne penseras jamais a avoir un coffre-fort parce que la porte de la maison et les fenetres sont sensees etre sures ?
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 () le 03/03/2008 à 07:11. (lien). Évalué à 7.1°) Donc si j'ai bien compris, a la maison chez toi, tu ne penseras jamais a avoir un coffre-fort parce que la porte de la maison et les fenetres sont sensees etre sures ?
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, ...) ...--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Moi
Posté par Obsidian () le 03/03/2008 à 13:01. (lien). Évalué à 5.Et moi, je te propose de commencer par mettre des serrures à tes portes si tu comptes installer un coffre-fort chez toi.
"Defense in depth". Non mais je rêve !-
[+] [^]Re: Moi
Posté par pasBill pasGates () le 03/03/2008 à 19:47. (lien). Évalué à -1.Ah ben ca tombe bien, j'esperes que tu vas me montrer ou est-ce que les serrures ne sont pas installees.
-
-
-
[^]Re: Moi
Posté par z a (Jabber id, ) le 03/03/2008 à 18:17. (lien). Évalué à 2.c'est pas un peu ce que font SELinux, AppArmor & cie. mais pas au niveau TCP/IP ? (c'est une vraie question)
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 () le 03/03/2008 à 01:28. (lien). Évalué à 5.Par exemple ,je peux rediriger le port 653984 vers le port 22 d'une mmachine qui elle interdira les connexions root.
Tu arrives à rediriger le port 653984 en TCP/IP ? Faudra que tu me montres comment tu fais :-)-
[^]Re: Moi
Posté par kowalsky () le 03/03/2008 à 11:29. (lien). Évalué à 2.C'est de l'IP V12 !
--
You got the money, I got the soul.-
[^]Re: Moi
Posté par briaeros007 () le 03/03/2008 à 12:00. (lien). Évalué à 4.plutot du tcp²
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Moi
Posté par Thomas Douillard () le 03/03/2008 à 13:33. (lien). Évalué à 3.TCP et IP ont fusionnés pour la version 8 de IP.
-
[^]Re: Moi
-
-
-
Poser le problème
Salut,
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
Salut,
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 (Jabber id, ) le 02/03/2008 à 15:25. (lien). Évalué à 3.À propos de routeurs qui routent, seginus pourra rétorquer que ce n'est pas utilisé dans les réseaux familiaux derrière une FAIbox.
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 (Jabber id, page perso, ) le 02/03/2008 à 16:26. (lien). Évalué à 1.Si tu as l'IPv6, la box IPv4 ne bloque plus rien. Il te faut alors faire gaffe à, par exemple, tes partages samba qui sont accessibles depuis le net (Ca peut se configurer dans samba et non dans le firewall).
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
-
-
Freebox en mode routeur fainéant
Ne pas se fier aux boiboites des fai pour la sécurité de son réseau.
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.
-
[^]Re: Freebox en mode routeur fainéant
Posté par FärvÄrdiN (page perso, ) le 02/03/2008 à 16:54. (lien). Évalué à 2.effectivement j'ai déjà eu cela sur une freebox.
--
RMS is like sex, it's better when it's clean...
-
[^]Re: Freebox en mode routeur fainéant
Posté par Olivier (page perso, ) le 04/03/2008 à 10:16. (lien). Évalué à 1.à la suite d'un reboot des boites, que celles-ci se comporte en bridge !
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
Je me suis posé la même question, mais pour un serveur dédié chez un hébergeur plutôt que pour mon PC à la maison.
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 (Jabber id, page perso, ) le 02/03/2008 à 16:29. (lien). Évalué à 2.Yep, pour éviter que le type qui s'amuse à placer une backdoor puisse s'y connecter.
-
[^]Re: Même question
Posté par Grégoire G (Jabber id, page perso, ) le 02/03/2008 à 16:37. (lien). Évalué à 2.Ce que tu peux faire aussi :
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-
[^]Re: Même question
Posté par Zenitram (page perso, ) le 02/03/2008 à 17:56. (lien). Évalué à 5.(tu es libre de créer tes propres règles), sur des ports précis (règles à déterminer) éventuellement fermés.
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 Grégoire G (Jabber id, page perso, ) le 02/03/2008 à 18:33. (lien). Évalué à 3.tu sera chez un client, qui aura autorisé seulement les ports classiques 22/80/443
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é... :)
-
-
[^]Re: Même question
Posté par kowalsky () le 03/03/2008 à 11:35. (lien). Évalué à 3.Sans vouloir t'offencer, c'est laid !
OpenSSH fais bien son boulot, pourquoi se torturer
a mettre en place une surcouche ?--
You got the money, I got the soul.-
[^]Re: Même question
Posté par Christophe HENRY (Jabber id, page perso, ) le 03/03/2008 à 12:31. (lien). Évalué à 2.>OpenSSH fais bien son boulot, pourquoi se torturer
>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 () le 03/03/2008 à 13:23. (lien). Évalué à 3.Oui, mais ça déporte le problème de faille sur l'autre logiciel.
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. :)--
You got the money, I got the soul.
-
[^]Re: Même question
Posté par ptifeth (page perso, ) le 03/03/2008 à 14:42. (lien). Évalué à 3.C'est une forme de protection par l'obscurité.
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!
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é.
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!
-
[^]Re: DROP!
Posté par Obsidian () le 06/03/2008 à 14:20. (lien). Évalué à 3.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 ...
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 () le 06/03/2008 à 15:10. (lien). Évalué à 0.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 !
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).--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: DROP!
Posté par Benjamin G. ( Prae ) (page perso, ) le 08/03/2008 à 00:47. (lien). Évalué à 1.> 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 !
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 () le 08/03/2008 à 09:06. (lien). Évalué à 1.Ben euh, si la backdoor ouvre le port sur ton parefeu, le tipiak peut y accéder, non ? Ou j'ai raté quelque chose ...
-
[^]Re: DROP!
Posté par Benjamin G. ( Prae ) (page perso, ) le 09/03/2008 à 00:03. (lien). Évalué à 1.Bah non, il ne peut pas y accéder.
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!
-
-
-
-
ma config
Salut,
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.
Cette page a été générée par Templeet en 0.1564s (dont 0.0263 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.