Mauvais exemple. On ne ferme pas un port ouvert avec un pare-feu mais en arrêtant le service qui l’a ouvert, ou en le configurant pour ne pas l’ouvrir si ce n’est pas utile. Et si ce port est utile, alors bloquer l’accès à celui-ci avec un pare-feu aura des conséquences sur le fonctionnement de la machine.
[quote=“fluo”]Un autre exemple : je vais tenter de rentrer sur ton pc via le port 22 qui est le port ssh.
Mais grâce au pare-feu, tu as fermé ce port 22 et ouvert un port d’un autre numéro pour le ssh.[/quote]
Encore un mauvais exemple. Si tu as changé le port d’écoute pour ssh, alors le port 22 est fermé sans qu’il y ait besoin de faire intervenir un pare-feu.
PascalHambourg :
Ce que tu nous dis c’est bien que le rôle du pare-feu tel qu’il est présenté dans cette discussion est seulement de pallier aux éventuelles failles de sécurité des services qui tournent ?
Je suis dans un cas avec une DMZ derrière mon routeur, le pare-feu du routeur désactivé, et pas de pare-feu configuré sur la DMZ.
Est-ce que je prends des risques si je fais confiance aux quelques services qui tournent sur la DMZ ?
Si je peux me permettre, on securise surtout en amont sa navigation pour palier aux regies de pubs indésirables : malvertising.stopmalwares.com/20 … ate-pages/ , flash pourris, Javascript “tordu” etc… parceque pour GNU_Linux ça existe aussi les merdouilles par ce biais
Il est important de surfer avec un navigateur non propriétaire, pour encore une fois des questions de fiabilité, de sécurité et pour que celui ci ne transmette pas directement un ensemble de données que vous utilisez/visualisez (comme c’est le cas de Chrome avec Google). Il est fortement recommandé d’utiliser Firefox\Iceweasel, pour ces raisons et pour son aspect modulable, fonctionnant avec des modules comme Ad-block ( comme son nom l’indique, bloquer les publicités ), NoScript pour gérer flash ( voir 3 - Le format SWF (Flash) et les risques liés à son utilisation - forum.malekal.com/les-exploits-s … t3563.html - )!!
Donc Iceweasel + Adblock + Noscript
Mettre “actif” d’un clic les modules ci dessous qui apparraissent apres installation de ADBlock : chrome://adblockplus/content/ui/firstRun.html
NOTE POUR Adblock :
Certains sites abusent des publicités, dont leurs pages peuvent en être inondées (cela ralentit la navigation etc). Mais notez que les publicités sont parfois le seul revenus des sites WEB.
Filtrer toutes les publicités peuvent, par exemple, pénaliser ces sites.
Si vous pensez que certains sites le méritent, vous pouvez les ajouter en liste blanche.
[quote=“angelique”]…
Il est important de surfer avec un navigateur non propriétaire, pour encore une fois des questions de fiabilité, de sécurité et pour que celui ci ne transmette pas directement un ensemble de données que vous utilisez/visualisez (comme c’est le cas de Chrome avec Google). Il est fortement recommandé d’utiliser Firefox\Iceweasel…[/quote]
Je viens de regarder sur mon Iceweasel 24.8.0 cet après midi. Résultat, il fait exactement comme Firefox. C’est impressionnant comme rien n’est parfait en ce bas monde…
Rhaa, un nième topic sur des questions abscons et délétères …
La vérité :
un parefeu est très utile. Son utilisation pour “bloquer des ports” est inutile.
bloquer des ports peut cependant être utile pour des OS débile (dos …) qui font fonctionner une trallée de service bidon et troué. Dans ce cas, mettre en place un parefeu est une solution saine pour corriger les nombreux défauts de ton OS. Changer d’OS est aussi une bonne idée. Sous Debian, tu n’as aucun service en écoute, sauf si tu en ajoutes (netstat ne montre aucun processus en écoute). Sous Debian, tu rentres donc dans la case ci-dessus.
un serveur est un client, une machine simple est un serveur. Dans les deux cas, ce sont intrinséquement les mêmes choses, et doivent donc être traité de la même manière.
Ne pas paramètrer iptables est une très bonne idée, surtout si tu n’en as pas besoin. Franchement, si c’était réellement une faille de sécurité, pourquoi penses-tu que c’est ainsi sous Debian ? Tout simplement parcque c’est sécurisé, simple et efficace.
L’usage d’un parefeu ne dépend pas de la présence d’un autre équipement sur le réseau. Avoir un autre parefeu ne change rien à l’équation, de même quant à la présence (ou l’absence) de cochonnerie tel que le nat.
[quote=“fluo”]
Exemple simple : fermer tous les ports inutilisés pour éviter toute intrusion.
Un autre exemple : je vais tenter de rentrer sur ton pc via le port 22 qui est le port ssh.
Mais grâce au pare-feu, tu as fermé ce port 22 et ouvert un port d’un autre numéro pour le ssh.[/quote]
Ce genre d’exemple ne peut que mettre en valeur ta méconnaissance des protocoles réseaux et du fonctionnement de tous les OS moderne (à ma connaissance).
Il n’y a pas de “port fermé” ou de “port ouvert”.
Lorsqu’un paquet arrive sur la machine, et est à destination de cette machine, le paquet transit vers le kernel.
Ce dernier doit savoir qu’en faire.
Plusieurs cas possible :
tu as mis une règle iptables pour supprimer le paquet : ce dernier est supprimé, sinon, le paquet continu dans les entrailles du kernel
le kernel cherche un processus en écoute pour lui donner les données. Deux cas possibles :
un processus est en écoute : les données lui sont fourni, fin
aucun processus n’est en écoute : le paquet est supprimé
Donc, pour résumer, deux cas possibles :
tu as un service en écoute, tu as installé ce service, tu veux logiquement pouvoir l’utiliser : la règle iptables est nocive
tu n’as pas de service en écoute. Le kernel va supprimer le paquet comme un grand : la règle iptables est inutile
[quote=“grandtoubab”]
C’est pas parce qu’il y a un digicode à l’entrée de l’immeuble que je ne mettrai pas de verrous à ma porte.[/quote]
Très mauvaise métaphore.
En voici une autre :
Tu as une chambre d’hôtel, gardé par une vingtaine d’homme de garde entrainé et armé jusqu’aux dents (c’est le noyau). Ils ont ordre de défoncer tout ceux qui veulent entrer, sauf une certaine personne (tu as dit de laisser passer cette personne).
Mettre un parefeu revient à dire aux types : “hey les gars, j’ai une consigne pour vous : si une personne autre que celle là cherche à passer, vous le zigouillez !”.
Dans la vraie vie (et si ton kernel pouvais parler), ils te diraient un truc du genre “ok, t’es gentil, c’est déjà ma consigne, merci de ton aide, dégage”.
[quote=“fran.b”]
Le parefeu est utile pour
protéger ta machine de requêtes non désirées sur des ports ouverts pour des machines précises (souvent ton LAN) mais pas pour les autres.
protéger les autres de ta machine potentiellement vérolées (exemple: tu interdis les requêtes sortante vers le port 25 excepté vers ton serveur SMTP préféré).
Filtrer d’éventuelles requêtes (interdiction de contact des serveurs Apple, de serveurs traceurs, etc)
Filtrer le trafic si ta machine sert de routeur.
D’autres choses moins importantes que j’oublie[/quote]
C’est déjà un peu plus juste.
La bonne pratique concernant le premier point est de, comme l’écrit Pascal, configurer le service.
Protéger les autres de ta machine vérolé : à mon avis, c’est difficile de faire cela, sinon pour un petit extrait des problèmes potentiels (dans ton cas : le spam). Et encore : tu comptes t’interdire d’envoyer des mails ? Cela va être difficile pour toi de configurer ton parefeu pour l’empêcher d’être un botnet, entendu que le champ important est variable (port source), et que tu ne peux filter sur le port destination (bloquer le port 80 ?!)
Quant à l’autocensure, c’est une bonne pratique, même si le réglage de ton parefeu doit être plutôt délicat.
Filtrer le trafic si ta machine est un routeur : je ne comprends pas le sens, le but ou l’utilité … Je ne censure pas mes clients sous prétexte d’avoir le plein contrôle sur le routeur. (ou alors, tu parles du point précédant, généralisé à tout les équipements de ton LAN ?)
Quant aux autres choses que tu oublies, c’est à mes yeux les choses plus utiles, passionnantes et constructives que l’on puisse faire avec un parefeu : altération et analyse des paquets.
[quote=“vv222”]
Ce que tu nous dis c’est bien que le rôle du pare-feu tel qu’il est présenté dans cette discussion est seulement de pallier aux éventuelles failles de sécurité des services qui tournent ?[/quote]
Ce n’est pas ton parefeu qui va t’aider dans ce cas.
Un parefeu n’est pas efficace pour faire de l’analyse de données applicatives.
Et ce n’est pas ton parefeu qui va corriger ton code de merde.
Merci pour ton explication haleth, dans mon cas je continuerai donc sans configurer iptables, sans pour autant avoir l’impression que ma machine est à poils.
Mes différents services en écoute sont déjà configurés soit par une liste blanche d’IPs, soit par un système d’authentification par clés, je vais donc me contenter de laisser le noyau faire son boulot.
vv222 > heu… moi, je serai pas rassuré d’avoir une machine comme ça…
Déjà au travers de la boxe, de fail2ban et de quelques iptables, je suis horrifié quand je vois les logs certains jours…
Je me dis surtout que, j’aimerai éviter de me retrouver en garde à vue parce qu’on a utilisé mon serveur pour faire une connerie…
Même si on arrive à pénétrer ma machine un jour, je me dis que le fait qu’on voit tous ces efforts de sécurisation, m’aidera à me disculper plus facilement…
protéger les autres de ta machine potentiellement vérolées (exemple: tu interdis les requêtes sortante vers le port 25 excepté vers ton serveur SMTP préféré).[/quote]Et encore : tu comptes t’interdire d’envoyer des mails ? Cela va être difficile pour toi de configurer ton parefeu pour l’empêcher d’être un botnet, entendu que le champ important est variable (port source), et que tu ne peux filter sur le port destination (bloquer le port 80 ?!)
Quant à l’autocensure, c’est une bonne pratique, même si le réglage de ton parefeu doit être plutôt délicat.
Filtrer le trafic si ta machine est un routeur : je ne comprends pas le sens, le but ou l’utilité [/quote]
Très simple, exemple immédiat.
-A OUTPUT -p tcp -m tcp --dport 25 -j SMTP
-A SMTP -d 193.251.214.114/32 -o wlan0 -p tcp -j ACCEPT
-A SMTP -o wlan0 -j DROP
Tu procèdes de même pour un routeur:
# iptables-save | grep "port 25"
-A PREROUTING -d IP_PUBLIC/32 -i eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 25 -j DNAT --to-destination 192.168.1.1:25
-A PREROUTING -i eth1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 25 -j DNAT --to-destination 192.168.1.1:25
-A POSTROUTING -s 192.168.0.0/16 -o eth0 -p tcp -m tcp --dport 25 -j MASQUERADE
-A FORWARD -d 192.168.1.1/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -s 192.168.1.1/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -o eth1 -p tcp -m tcp --dport 25 -j DROP
(politique par défaut usuelles pour un routeur. Cela interdit les paquets à destination des serveurs SMTP sortants sauf pour le serveur SMTP local lui même.
À noter qu’il y a deux réseaux ici (192.168.1.0/24 et 192.168.1.0/24), les règles PRE et POSTROUTING permettent aux locaux de prendre l’adresse publique comme nom de serveur.
Cela a évité aux machines infectés parmi les 180 machines sous windows de balancer du spam à tout va sans que je ne le vois. (obligation de passer par mon serveur). Je procède de même chez moi.
L’altération des paquets tient plus du routage et de la gestion du trafic que du filtrage et sort de ce qu’on appelle un parefeu, même si c’est iptables qui fait cela, mais c’est abuser des mouches à ce niveau.
Je pense que tout les débat et toutes les polémiques viennent des box. Il est indiscutable qu’il faut un parefeu en amont du LAN (aujourd’hui, quasiment tout les foyers ont plus d’une machine qui se connecte au wan).
Les box font elles de bon parefeux ? Je n’ai pas la réponse, et je ne cherche plus à l’avoir.
J’ai intercalé un vrai routeur parefeu derriere ma box (netgear), qui n’est plus utilisée qu’un vulgaire modem.
Même derrière la box qui fait routeur et même si iptables est livré dans Debian, encore faut-il savoir la gérer, voilà pourquoi j’ai choisi ufw et son interface graphique gufw
Quoiqu’il en soit voici ce que j’ai pour faire du Mediacenter entre la TV, via le decodeur TV de la box, et mon PC ainsi que du FTP entre ma tablette et mon PC
[code]
root@ubuntu-desktop:~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip
To Action From
192.168.1.23 ALLOW IN 192.168.1.22
192.168.1.23 ALLOW IN 192.168.1.31
[quote=“vohu”]vv222 > heu… moi, je serai pas rassuré d’avoir une machine comme ça…
Déjà au travers de la boxe, de fail2ban et de quelques iptables, je suis horrifié quand je vois les logs certains jours…[/quote]
J’ai bien un fail2ban qui tourne, mais il n’a encore jamais eu à bloquer quoi que ce soit.
Il faut tout de même préciser que je n’ai pas de nom de domaine, je ne suis donc une cible que pour ceux qui attaquent directement des séries d’IP.
Si le pc est sous debian, il n’y a pas grand chose qui ouvre des ports par défaut.
Il y a bien cups et exim qui ouvre respectivement le 631 et 25 mais qui écoutent sur 127.0.0.1 .
Et évidement le server ssh n’est pas installé par défaut.
Donc un pc sous debian, derrière une box, un firewall ne sert à rien puisqu’il n’y a pas de ports ouvert sur le lan, alors sur le public …
Par extension je dirai que même sur un wifi public dans ce cas là ça ne sert à rien puisque il n’y a pas de port à boucher, mais ça reste un long sujet de discution …
Votre raisonnement ne tiens pas. Vous oubliez les zéro days.
Je ne suis pas un expert, mais via le navigateur par exemple, (port 80 forcément ouvert), un attaquant peux se faire un service avec les droits de l’utilisateur du navigateur. Si vous avez un pare feu trés peu permissif, ce service ne sera pas accessible depuis le net et ne lui servira à rien.
Si par malheur, il arrive à prendre les droits root via une autre faille, vous limiterez la casse, si:
votre LAN est protégé en tête par un pare-feu
vos autres machines ont un pare feu chacune
C’est un cas extrême, j’en convient.
Mais on revient un problème de base: si vus avez un attaquant aussi déterminé, c’est qu’il cherche quelque chose qui a de la valeur (au moins pour lui), et donc si vous possédez une telle information aussi attrayante, il n’est pas idiot d’avoir une protection en profondeur un peu sophistiquée.
[quote]
Je ne suis pas un expert, mais via le navigateur par exemple, (port 80 forcément ouvert), un attaquant peux se faire un service avec les droits de l’utilisateur du navigateur. Si vous avez un pare feu trés peu permissif, ce service ne sera pas accessible depuis le net et ne lui servira à rien.
Si par malheur, il arrive à prendre les droits root via une autre faille, vous limiterez la casse, si:
votre LAN est protégé en tête par un pare-feu
vos autres machines ont un pare feu chacune
C’est un cas extrême, j’en convient.
Mais on revient un problème de base: si vus avez un attaquant aussi déterminé, c’est qu’il cherche quelque chose qui a de la valeur (au moins pour lui), et donc si vous possédez une telle information aussi attrayante, il n’est pas idiot d’avoir une protection en profondeur un peu sophistiquée.[/quote]
Je confirme, tu n’es pas expert
Un navigateur n’ouvre pas de port en écoute.
Si tu arrives à te placer sur la machine cible, il est infiniment plus simple de te connecter à un serveur distant. Les données seront envoyés en utilisant le canal initié par ta machine.
Le port local est aléatoire, le port distant est 80, tu vas passer les nat, les parefeu, tout.
Et en plus, il est plus simple, pour connaitre les cibles qui sont en ligne, de les faire se manifester, plutôt que de scanner des millions d’IP dans l’espoir, avec un peu de chance, de tomber sur une cible.
In fine, et logiquement, un parefeu ne te sert à rien.
Pour le routeur en tête du LAN, c’est effectivement pas clair dans mon esprit. Si l’attaquant est un minimum compétent, il fera comme tu dis. Les connexions initiées depuis le client ne sont pas filtrées, ou alors si elles le sont, le client n’est pratiquement plus utilisable.
Mais pour les autres machines, le pare feu sert quand même à protéger les autres machines du LAN si elles sont protégées individuellement par un par feu.
Ca évite la propagation.
Ou alors je me fais des illusions ?
Est-ce que ton pécé dans ta maison sous ton bureau a besoin d’un pare feu ? bin déjà il se trouve en général dans un réseau privé (192.168.x.x) routé par un modem/routeur de ton opérateur (la fameuse box). Par défaut toute tentative de connexion depuis l’internet est vouée à être bênné (mis en ben, supprimé, > /dev/null) par la box. Donc de l’Internet, aucune demande de connexion de l’Internet ne peut aboutir à ton pécé.
Si en plus ton pécé est sous Debian et que tu fais une installation standard, il n’y a que des services attachés à l’adresse local (localhost ou 127.0.0.1), ou peut s’en faut, donc pas accessibles depuis le réseau local, donc a fortiori depuis l’internet et plus encore si tu es derrière un routeur.
Quant à filtrer les flux sortants de ton pécé, il s’agirait de Windows, j’dirais ouaip… mais sous Linux, peu d’intérêt mais ça se discute
