Bien le bonjour !
J'ai lu des dizaines d'articles, tutos et posts sur des forums, j'ai bidouillé dans tous les sens, en modifiant/supprimant chaque règle une par une. Et malgré tout je me pose toujours des questions sur mon IPtables…
Il ressemble à ceci :
## On drop les scans XMAS et NULL.
iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# Dropper silencieusement tous les paquets broadcastés.
iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
# Droping all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
# Autorise les connexions déjà établies et localhost
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
#iptables -A OUTPUT -o lo -j ACCEPT
#TOR
#iptables -A INPUT -p tcp -m tcp --dport 9050 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 9050 -j ACCEPT
# ICMP (Ping)
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j DROP
# SSH
iptables -A INPUT -p tcp --dport 666 -j DROP
iptables -A OUTPUT -p tcp --dport 666 -j DROP
# DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
#iptables -A INPUT -p tcp --dport 53 -j ACCEPT
#iptables -A INPUT -p udp --dport 53 -j ACCEPT
# HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
#iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# FTP
#iptables -A OUTPUT -p tcp --dport 20:21 -j DROP
#iptables -A INPUT -p tcp --dport 20:21 -j DROP
# Mail SMTP
#iptables -A INPUT -p tcp --dport 25 -j DROP
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
#iptables -A INPUT -p tcp --dport 587 -j DROP
#iptables -A OUTPUT -p tcp --dport 587 -j DROP
#Transmission
iptables -A INPUT -m state --state ESTABLISHED -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT
#NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
#On log les paquets en entrée.
iptables -A INPUT -j LOG
# On log les paquets en sortie.
iptables -A OUTPUT -j LOG
# On log les paquets forward.
iptables -A FORWARD -j LOG
exit 0J'ai retrouvé les premiers blocs un peu partout, et j'ai plus ou moins compris leur fonctionnement.
Mon problème est pour la suite : il me semble avoir tout fait pour laisser passer le trafic de manière à pouvoir utiliser transmission et surfer sur internet.
Donc, normalement, en supprimant la ligne acceptant les Established, je devrais pouvoir accéder au net.
Sauf que non. Du coup, je commence de plus en plus à avoir l'impression que seule les règles established me permettent d'accéder au net, et non le reste des règles.
J'ai beau lire et relire des docs, je ne comprend pas…
Un peu d'aide, s'il vous plait ? Merci d'avance.
# port dynamique
Posté par cimcim . Évalué à 2.
je ne suis pas un grand lecteur de iptables, mais de ce que j'en sais au niveau règles générales de fonctionnement de serveurs et de pare feu :
quand tu te connectes à une page web distante (disons http), ton browser contacte le serveur sur le port 80, ce qui est possible grâce à la rêgle
Mais une fois ce contact établi, le serveur te renvoie un autre numéro de port aléatoire pour que la communication réelle puisse se faire, sans bloquer un autre utilisateur voulant accéder à la même page web, qui se retrouverait à attendre que tu veuilles bien libérer le port 80.
C'est là que le ESTABLISHED rentre en compte. Les rêgles
indiquent que iptables doit laisser passer les connections "déjà établies", car sinon, la réponse de la part du serveur, et la tentative de connexion vers le nouveau port attribué serait bloqué par ton pare feu.
L'idée générale est là (de ce que j'en sais (ou de ce que j'en ai compris :) )), je laisse des gens plus expérimentés que moi mieux préciser ces mécanismes.
[^] # Re: port dynamique
Posté par Bernez . Évalué à 1.
Absolument pas. Les ports utilisés tout le temps de la connexion ne changent pas. Les serveurs sont capables de gérer plusieurs connexions simultanées sur un même port, et encore heureux.
Non. En gros ESTABLISHED sert à autoriser les réponses aux initiations de connexion de la machine.
[^] # Re: port dynamique
Posté par lolop (site web personnel) . Évalué à -1.
Revoir le cours réseau TCP.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: port dynamique
Posté par lolop (site web personnel) . Évalué à 2.
C'est moi qui était dedans, mes neurones ont mixé socket et port…
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Commencer par le début
Posté par Bernez . Évalué à 2.
Ça va peut-être paraître dur, mais l'ensemble de règles que tu utilises n'a ni queue ni tête. On dirait que tu as fait des copier-coller de règles de droite et de gauche sans comprendre à quoi elles servent. Iptables n'est pas utilisable si on n'a pas un minimum de connaissance sur TCP/IP.
Si ton objectif est d'apprendre à utiliser iptables de façon autodidacte, je te conseille de commencer par acquérir les bases de TCP/IP. Ensuite il faut apprendre les grands principes d'iptables. Une fois que c'est fait, tu peux commencer à écrire toi-même des règles que tu comprends.
# Commencer par le début
Posté par redraven . Évalué à 1.
Merci bien cimcim ! C'est ce que j'avais cru comprendre. Du coup, mon utilisation d'established reste sécurisée ? c'est mettre un new à cet endroit qui serait une jolie bêtise.
Bernez : aucun problème, comme je disais, je débute.
Je m’intéresse à iptables en parallèle de la lecture de plusieurs tutos/articles sur les réseaux, les protocoles etc.
Les premiers paragraphes sont du copier coller, oui. Et après lecture, je comprend parfaitement la partie sur les invalid, qui semble logique, un peu moins la partie avec les --tcp-flags (c'est ma lecture du moment, tout lire sur ce qui suis ce paramètre).
Pour la suite, par contre, j'ai passé des heures et des heures à tester chaque règle jusqu'à ce que firefox, transmission etc. fonctionne, avec le nombre de ligne minimal. Il me semblait avoir tout compris à ces paragraphes là, pourtant. J'ai fait du netstat et tcpdump pour savoir quel process, quel port etc.
Où se trouve les erreurs dans ce qui suis ?
Merci en tout cas !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Affirmer ce genre de chose avec tant d'aplomb est d'une stupidité rare …
Il y a au minimum deux cas ou un firewall sur une machine de bureau est utile:
Dans un environnement "hostile" (au bureau avec des collègues blagueurs, machine qui se connecte souvent à des wifis publiques, machine dans un LAN de fac)
Si il se connecte directement au net sans passer par une box de FAI et donc qu'il a une IP publique directement sur sa bécane.
En général et en sécurité en particulier, quand on sait pas, c'est quand même mieux de se taire …
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Un pare-feu ne rendra pas le réseau auquel tu es connecté plus sûr, évidemment.
Par contre, il rendra inexploitable certaines failles laissées béantes par oubli.
Il va servir en vrac à:
Eviter qu'un petit malin s'amuse à exploiter un truc que t'aurais déployé à l'arrache à des fins de tests (apache + wordpress, mysql ouvert sans pass root, serveur upnp/minidlna) pour executer du code sur ta bécane.
Eviter qu'un petit malin exploite des failles avant que tu n'aies le temps de te mettre à jour (failles des clefs SSH faibles sur debian).
Eviter qu'un petit malin exploite des failles dites 0 days (failles non divulguées au publique qu'un pirate garde pour lui).
Eviter qu'un partage samba sur lequel t'as mis tes photos soit browseable par n'importe qui
Eviter qu'un petit malin s'amuse à vider les cartouches d'encre de ton imprimante à cause d'un CUPS mal configuré
Le problème d'une machine dite "de bureau", c'est que généralement, on y fait plein de trucs à l'arrache sur un coin de table en prenant rarement le temps de nettoyer derrière et on se retrouve avec des services en écoute, pas nécessairement installés via le gestionnaire de paquets et donc sans suivi de sécurité…
Je t'ai convaincu ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Comme je te l'écrivais: "à des fins de tests".
Et oui, à des fins de tests, il m'est arrivé de dire à mysql d'écouter sur autre chose que la "boucle locale" (vrai traduction de loopback).
Sur debian, un MySQL s'installe sans soucis sans mdp root …
Dernière élément: que se passe-t-il si, un jour, le mainteneur se loupe sur une évolution d'un fichier de config ou autre et que ton MySQL se met à écouter sur INADDR_ANY plutôt que sur 127.0.0.1 ?
Je ne vois pas l'intérêt d'autoriser un quelconque port sur un desktop, que ce soit ssh ou autre.
Dans l'idée, je préfère faire:
iptables -P INPUT DROP
plutôt que:
apt-get remove --purge openssh-server samba …
Ca permet d'ouvrir le service temporairement en cas de besoin.
Généralement, quand les mecs s'emmerdent à trouver des failles et à ne pas les divulguer, c'est pas pour juste les garder au chaud sur un coin du disque mais bien pour les exploiter oui …
Après, effectivement, dans le cas d'une station de travail, on va plus avoir à composer avec des bots scanner de SSH et de SMTP en open-relay qu'avec un vilain black hat.
Dixit ma remarque plus haut. Que le service soit là à ne rien faire n'implique pas qu'on l'ouvre sur l'extérieur…
Oui sauf que sur une machine portable, un jour t'es sur un réseau local privé et le lendemain t'es sur un réseau local de gare.
D'habitude t'oublie pas de faire /etc/init.d/samba stop, mais il se trouve que ce jour là, t'as oublié …
Pas tout à fait d'accord.
L'un des principes de base de la sécurité informatique est celui du moindre privilège (et c'est pas moi qui le dit mais l'ANSSI).
L'article wikipedia à ce sujet parle principalement de code, mais ce principe s'applique aussi au réseau: n'ouvrir que ce dont on a besoin.
Avoir un firewall qui droppe tout ce qui arrive en entrée est la première application de ce principe.
Ensuite vient la sécurisation des services.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
J'ai oublié de répondre à ça:
Même sur Debian, il arrive que des softs ne soient pas packagés.
Souvent sur Debian il arrive que des softs soient packagés mais franchement ancien et pas toujours dans debian-backports.
Dans ces cas là, une seule issue: la compil' à la mano.
Ce n'est pas parce que c'est quelque chose que, dans ton utilisation d'une machine Linux, tu ne fais pas que c'est nécessairement "n'importe quoi"…
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 24 avril 2019 à 16:16.
Excellent exemple ! Tu peux donner la règle qui protège de ça ? Que je la mette de suite sur mon bastion SSH.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par BAud (site web personnel) . Évalué à 1.
c'est censé avoir été corrigé depuis… (un paquet de ~4 Mo dans la plupart des distributions révoquant les clés debian faibles)
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
C'était un exemple.
Et comme je l'ai dit plus haut, avoir un service en écoute sur une machine n'implique pas nécesasirement qu'on souhaite le laisser joignable depuis l'extérieur.
SSH fait bien souvent partie de l'install de base, filtrer le port sur un desktop et l'ouvrir au besoin ("hey collègue, tu peux me scp-er le dernier album de dick rivers ?") me parait plus pertinent que de tout bonnement supprimer le service et le reinstaller si un jour t'en as besoin.
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 2.
Bin oui mais c'est facile de prendre les gens de haut en donnant des exemples dans le vide. On égraine les autres exemples aussi ?
La seule règle de firewall que j'ai vu passer dans tes commentaires c'est
iptables -P INPUT DROP.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 1.
Allé, tiens, après une recherche de 10 secondes sur google:
https://blog.ripstech.com/2019/wordpress-image-remote-code-execution/
L'intro du billet en question:
This blog post details how a combination of a Path Traversal and Local File Inclusion vulnerability lead to Remote Code Execution in the WordPress core. The vulnerability remained uncovered in the WordPress core for over 6 years.
Vazy je t'en prie.
Quel est l'objet de cette remarque ?
Oui, c'est, de mon point de vue, la seule règle à mettre sur un firewall de desktop.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 3.
Je vais replacer une dernière fois le contexte car ça a l'air confus dans ton cerveau:
Dans ce cas précis (et pas un autre), avec un firewall qui interdit toutes les connections entrantes sur l'IP publique, on est tranquille.
Le commentaire sur lequel j'ai réagi dit qu'un parefeu sur un poste de travail est inutile… Mes réponses visent à démontrer que cette affirmation est infondée.
Alors OK, si le seul usage d'un Linux pour toi consiste à mater youtube sur firefox, alors OK pas besoin de pare-feu.
Si par contre, t'es un peu développeur, un peu sysadmin et un peu passionné (c'est mon cas), il est probable que t'installe plein de trucs sur ton poste de travail a des fins de tests.
Et, dans l'éventualité ou tu nettoies pas après, avoir un pare-feu évitera d'exposer sur le réseau des services qui n'ont qu'une raison d'être: le test.
Maintenant, chacun fait bien ce qu'il veut hein… Si vous estimez que, pour votre usage, un pare-feu est inutile, grand bien vous fasse.
Mais, par pitié, ne faites pas de votre petit cas particulier une généralité et ne sortez pas des conneries du genre "un parefeu sert à rien sur un poste de travail" à un débutant.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Lol … ah bon, tu crois que bidouiller sous Linux c'est un usage particulier ?
Et moi qui pensait que c'était un OS de bidouilleur…
Au delà de ça tu as exprimé une opinion qui relève de ton cas particulier. Si quelqu'un, un peu bidouilleur, appliquait ton opinion sans réfléchir, il se priverait d'une protection peut être inutile dans 90% des cas mais qui au final, ne mange pas de pain et qui peut sauver la mise un jour.
Au contraire, si on applique bêtement mon opinion, ça n'enlève rien à l'utilisateur, ça ne bride pas son utilisation d'internet, ça surcharge peu ou pas la machine … en fait, c'est transparent. Juste, t'as une protection supplémentaire.
Bien souvent, des services font partie de l'installation par défaut.
Sache qu'il y a pas mal de protocole qui permettent de traverser ce genre de chose. DLNA en est un.
Et au delà de ça, faire une confiance aveugle en une box opérée et administrée par un FAI me parait quelque peu dangereux.
Dernière chose: quid des wifi public que tout le monde utilise de plus en plus ?
Euh … je pensais que c'était pourtant la base d'un pare feu. Faudra que tu m'expliques quels sont les usages qui ne sont pas "bien particulier" dans ce cas. vraiment.
(Et si tu me parles du NAT, alors je te répondre qu'avec l'arrivée prochaine d'IPv6, on ne devrait donc plus avoir besoin de pare-feu ?)
Bien sûr … mais encore une fois, je préfère mettre directement un jeu de règle iptables qui me bloque tout par défaut plutôt que de faire des
update-rc.dà gogo pour enlever des services du runlevel (d'autant que lors d'un update le rc.d sera réinstallé si je ne me trompe pas …).Rassure toi, ce n'est pas mon cas.
Au contraire.
En faisant la promotion d'un pare-feu, j'applique également un principe de base de la sécurité informatique: ne pas mettre tout ses oeufs dans le même panier.
Ce n'est pas pour rien que, lorsqu'on monte une infra réseau, on va généralement préférer utiliser des marques d'équipements différentes dans une même "chaine" réseau: si l'équipementier A a une faille et que tout le coeur de réseau s'appuie sur ses équipements, alors tout le réseau est vulnérable.
En mixant les équipementiers, on modère les impacts d'une éventuelle faille chez l'un d'entre eux.
A l'échelle d'un OS, on peut se dire qu'appliquer ce principe de précaution n'est pas totalement déconnant.
Imagine demain une régression dans le noyau qui fait que, par une manigance habile, on parvienne à arriver à accéder à un service qui n'écoute que sur localhost ?
Un parefeu aurait tout son intérêt.
Je suis d'accord, un pare-feu ne doit pas se substituer à une rigueur dans la gestion de son système.
Cependant, comme je te le disais:
1. C'est toujours une protection supplémentaire qui peut être utile.
2. Une machine de travail d'un dév bidouilleur finira, par nature, un peu en vrac ;-)
On est d'accord.
Mais on est d'accord aussi sur le fait que le sujet ici, c'est un pare-feu sur un poste de travail.
Hors, je ne pense pas qu'il soit souhaitable de laisser accessible quoi que ce soit sur ce type de setup.
Donc on reste bien dans une démarche de se protéger de soi-même et d'éventuels oublis suite à expérimentation.
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 3.
Tu dis que le firewall est la solution à ces problèmes, mais tu ne dis pas avec quelle règle.
Si c'est pour dire ça, c'est pas
iptablesqu'il te faut, maisifdown.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 3.
Rolalala … tant de mauvaise foi !
ifdown, t'as plus de réseau…. c'est pratique le réseau, non ?iptables -P INPUT DROP, bein t'as juste plus de connections entrante possible.Si tu parviens pas à déceler la différence entre les deux approches, je crois qu'il vaut mieux arrêter de discuter, on se comprendra pas.
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 1. Dernière modification le 25 avril 2019 à 11:36.
Quel aplomb !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Quel argumentaire ! Tu es si constructif…
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 1.
Je reste admiratif devant tant d'aplomb, c'est tout.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Ok, erratum, my bad, il faut deux règles.
iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Ca ne change cependant strictement rien à l'opinion que j'ai exprimé sur le sujet du "firewall inutile sur un poste de travail"
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 1.
Je voudrais déjà que ça change un peu ta façon de parler.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Peux tu me dire au juste à quel moment je t'ai "mal" parlé à toi ? (d'ailleurs, c'est plutôt "écrire" dans le cas présent… mais bon).
J'ai effectivement dit à Bruno que sa façon d'affirmer ça était stupide…. Mais, Bruno peut se défendre tout seul non ? Il a pas besoin d'un preux chevalier pour se faire respecter … à moins que ce soit ton petit frère, je sais pas …
Dans l'absolu, je crois que mes contributions à ce thread, même si parfois discutable sur la forme, ont beaucoup plus apporté a l'OP que les tiennes, non ?
[^] # Re: Commencer par le début
Posté par gUI (Mastodon) . Évalué à 2.
Quel aplomb !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 4.
Les flags
Concernant les flags TCP, une connection TCP/IP "normale" se déroule ainsi:
C'est ce qu'on appele la Three Way Handshake.
Ensuite le client qui souhaite mettre fin à la connection utilisera un flag FIN.
Ensuite ce qu'il faut savoir c'est que:
Le truc de base quand on écrit un scanner de port, c'est d'envoyer un paquet avec le flag SYN placé et de voir si:
* on se prend un SYN/ACK: le port est ouvert.
* on se prend un FIN ou RST : le port est fermé.
* on se prend rien : le port est filtré, sur un linux à coup de -j DROP (le -j REJECT aurait pour conséquence de répondre "non" et renverrai donc le port comme fermé).
L'astuce ici, c'est que des scanneur de ports comme nmap s'appuie justement sur les spécificités d'implémentation de la pile TCP/IP pour chaque OS pour découvrir justement quel OS tourne sur la machine (c'est ce qu'on appelle de l'OS Fingerprinting).
Tes règles interdisant des paquets avec certains flags visent vraisemblablement à empêcher ce fingerprinting.
Les bonnes pratiques
J'ai jeté un oeil rapide à ton jeu de règle, et globalement, tu l'as un peu "écris à l'envers": en effet, tu mixes les règles permettant le traffic (-j ACCEPT) et celle l'interdisant (-j DROP) pour finir par une règle "catchall" de log (-J LOG).
Le hic avec cette démarche, c'est que si un paquet est droppé par une règle que tu as mis en place, tu ne le verras pas dans ton log …
Généralement, on fait plutôt
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
le -P permet de préciser la "politique par défaut", celle qui est appliqué si aucune des règles n'a matché ton paquet.
Ensuite, tu autorises chacun des services qui t'intéresse à coup de
iptables -A [..] -j ACCEPT
Enfin, tout à la fin, tu mets ta règle de log
iptables -A INPUT LOG
Comme ça, tout les paquets qui ne sont pas explicitement autorisés seront entraineront une ligne de log avant d'être droppés.
Note qu'il est plutôt rare pour un poste de travail de filtrer le "OUTPUT".
On fait plutôt ça sur les serveurs pour éviter la prise de contrôle par un pirate qui se servirait d'un shellcode avec "connect back" (en gros, le serveur va se connecter à une machine détenue par le pirate).
Ultime conseil
As tu bien vérifié que ton routeur/ta box internet/ton modem/ton FAI autorisait par défaut le protocole torrent ?
Pour t'en assurer, tu dégages toutes tes règles iptables et tu testes. Si avec un iptables vide et les policy à "ACCEPT" ton trafic ne passe toujours pas, il faut plutôt regarder du côté de ta box internet …
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 4. Dernière modification le 24 avril 2019 à 14:02.
Ajout:
L'état //related//
Dans tes règles, tu utilises les état //new// et //established//.
Un état qui peut t'être utile est également l'état //related//.
Prenons un exemple: le protocole FTP utilise, de base, les ports 20 et 21. Sauf que en fonction du type de fonctionnement demandé par le client, il peut également utiliser des ports hauts (aka > 1024) de façon dynamique.
Ces ports hauts vont être négociés à travers le port ftp-data (21 de mémoire).
L'état related sert justement à ça: à ouvrir à la volée les ports négociés dans le protocole.
Pour cela, le noyau utilise ce qu'on appele des "helpers conntrack" qui sont chargés d'analyser les paquets pour justement détecter ces ouvertures de port dynamiques.
Je ne sais pas si torrent:
* utilise ce mécanisme
* a son conntrack helper dans linux
Mais c'est une piste à creuser …
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 2.
Dernier ajout (car les règles iptables ça passent souvent mieux après plusieurs lectures ;-p)
[^] # Re: Commencer par le début
Posté par Bernez . Évalué à 3.
Le pare-feu iptables est conçu d'une façon telle qu'il faut d'abord apprendre TCP/IP avant de réussir à l'utiliser. Tu t'y prends à l'envers à lire la doc d'iptables avant de la doc généraliste sur TCP/IP.
Encore une fois c'est une approche qui me semble bien plus laborieuse que de commencer par lire un peu de doc sur TCP/IP et les grands principes d'iptables.
Difficile de faire un retour cohérent tellement tes règles partent dans tous les sens. Voici juste des commentaires sur quelques unes d'entre elles :
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROPAvec ça tu bloques tout le trafic TCP.
̀
iptables -A FORWARD -m state --state INVALID -j DROPLa chaîne FORWARD ne sert à rien sur une machine qui ne fait pas routeur.
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPTDe l'ESTABLISHED dans la chaîne OUTPUT n'a pas trop de sens.
iptables -A INPUT -p icmp -j DROPMauvaise idée de bloquer tout l'ICMP comme ça. Non seulement tu empêches l'utilisation de ping, mais en plus tu bloques des messages utiles de routeurs (style host unreachable).
̀
# SSH`iptables -A INPUT -p tcp --dport 666 -j DROP
Le protocole SSH utilise le port 22 (par défaut).
Sinon, comme dit par Gérald, ce n'est pas très utile de bloquer des paquets dans OUTPUT.
Il faut aussi avoir conscience qu'un pare-feu ne sert à peu près à rien sur un ordinateur de particulier derrière une box qui fait du NAT.
[^] # Re: Commencer par le début
Posté par redraven . Évalué à 1.
Merci !
Je lis pas mal sur le sujet, mais j'avance à petit pas, et il me faut un but concret pour me motiver, d'où l'idée d'iptables sur une machine de bureau, avant un éventuel serveur une fois les bases des notions de réseaux acquises et la config de iptables, fail2ban et ce genre de chose maîtrisée. Juste source de motivation, et curiosité. Aussi, il y a quelque chose de rassurant à un pare-feu bien configuré pour un PC souvent utilisé en déplacement.
Ceci dit, je reviendrai sans doute poster un autre iptables avant d'avoir pleinement maîtrisé la doc de TCP/IP. Ne m'en veux pas, s'il te plait. Ahah.
Aussi, et parce que la qualité des sources comptent, auriez vous quelques liens et tutos à partager, peut-être mieux conçu que ce que j'ai ? (je suis entre openclassrooms et un cours d'un ami en info).
Merci encore.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . Évalué à 3.
Globalement d'accord avec toi Bernez.
Juste une petite correction:
Non, ce n'est pas le cas. Il va bloquer tout les packets ou tout les flags sont à 1, dixit cette doc dont j'ai collé un extrait ci-dessous.
--tcp-flags
suivi d'un `!' optionnel, puis 2 chaînes de caractères pour les fanions, vous permet de filtrer sur des fanions TCP spécifiques. La première chaîne correspond au masque : la liste de fanions que vous désirez examiner. La deuxième chaîne précisent lesquels doivent être présents. Par exemple :
[^] # Re: Commencer par le début
Posté par Bernez . Évalué à 1.
En effet. Je n'ai jamais utilisé l'option --tcp-flags et j'ai interprété un peu vite le ALL comme un ANY. Merci pour la correction.
# Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1. Dernière modification le 24 avril 2019 à 15:15.
Merci tout le monde !
Sincèrement, toutes ces infos me sont précieuses.
Il n'y a aucun intérêt, dans mon cas, à avoir un pare-feu, à part l'occasionnelle connexion à un réseau public ce genre de chose.
C'est de la pure curiosité. J'ai lu un article, puis j'ai voulu comprendre comme ça fonctionnait. Aussi, je n'exclu pas du tout d'avoir un serveur un jour, juste par… curiosité et pour quelques projets, donc pas nécessairement inutile non plus comme compétence.
Les torrents fonctionnent ! Mais on m'avait fait remarqué que sans mes deux lignes established, mes règles ne servaient à rien, et vrai que sans elles rien ne marche. Du coup, bien perdu ! Est-ce correct, ou ça ne l'est pas ?
J'avais bien vu related, et vu que je me suis amusé à tout essayé règle par règle, sans, tout marche. Donc j'ai laissé sans.
Donc à revoir :
1) La façon de loguer
2) plein de drop spécifiés inutiles vu que policy drop par défaut
3) quant au doublon established pour transmission… je ne ferai pas justement mieux de précsier established ligne par ligne, port par port, plutôt que toutes les autorisées.
Et.. je me tentais à faire de même avec ip6tables, vu qu'apparement je suis en ipv6… Sauf que je partait du principe qu'à règles identiques, tout marcherai de même. Sauf que nom, c'est l'envoi de mail via smtp qui ne fonctionne plus.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1. Dernière modification le 25 avril 2019 à 13:34.
Je reviens à la charge, même si ça ne va pas plaire à tout le monde.
De là où j'en suis dans ma compréhension de tcp/ip et d'iptables, après avoir tout configuré en drop (mais si inutile pour output et forward, mais bref), un code minimal devrait suffire :
iptables -A INPUT -i lo -j ACCEPT
DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
Sauf que non. Ce que je ne comprend pas, c'est pourquoi sans les lignes :
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
rien ne fonctionne. Autoriser lo, dns, http et https devrait pourtant pouvoir suffire à accéder au net, de ce que je comprend. Non ?
Mes excuses, après ça je vous laisserai en paix jusqu'à lecture complète de ce que je suis sensé lire.
[^] # Re: Merci ! Encore quelques questions...
Posté par LaBienPensanceMaTuer . Évalué à 2.
Tes règles autorisent le flux sortant (à savoir ton PC vers le port (80|443|53) du serveur).
Mes tes règles n'autorisent pas implictement le flux retour (la réponse du serveur à ton PC).
C'est à cela que sert les lignes s'appuyant sur l'état ESTABLISHED: autoriser les flux correspondant… et ça, c'est parce qu'on a la chance d'avoir un firewall statefull sur Linux.
Sur un firewall stateless, il t'aurait fallu te faire toutes les règles à la main …
Voir cette page : https://inetdoc.net/guides/iptables-tutorial/userlandstates.html
A noter que, si ma mémoire est bonne, il n'est pas utile d'autoriser le TCP/53 car celui c'est n'est utilisé que pour les "grosses" requêtes DNS type transfert de zone.
A ce sujet, tu peux lire l'article de M Bortzmeyer : https://www.bortzmeyer.org/dns-over-tcp.html
[^] # Re: Merci ! Encore quelques questions...
Posté par gUI (Mastodon) . Évalué à 1.
Faudrait savoir. Je croyais que
iptables -P INPUT DROPétait la seule règle nécessaire sur un desktop.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Merci ! Encore quelques questions...
Posté par LaBienPensanceMaTuer . Évalué à 2. Dernière modification le 25 avril 2019 à 14:40.
Tu veux pas arrêter de faire ton idiot 5 minutes ?
Je viens pas ici pour du combat de quequette, mais pour aider un(des) débutant(s) à mieux comprendre quelque chose.
Ta contribution ne sert qu'à une chose ici: rendre confus quelque chose qui est déjà suffisament compliqué comme ça.
Je t'ai vexé ? Tu veux qu'on en parle ? Pas de soucis, mais arrête de faire ch**r sur ce thread, le pauvre redraven n'a rien fait pour ça.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1.
A vrai dire, votre "conflit" m'est utile, sans ça ce thread n'avancerai pas autant, et je n'aurai pas appris autant de chose en aussi peu de temps ahah !
Merci encore, vraiment.
Donc si je comprend bien, la règle input established ne laisse passer que le retour des ports que j'ai autorisé, donc tout reste sécurisé ?
Du coup, la règle established que j'avais précisé dans le script initial pour transmission est des plus superflu!.
Je vais retravailler tout ça et vous pondrai une version finale ce soir.
Ce qui m'intrigue c'est que sur un autre forum, ainsi qu'un ami, m'ont dit "que tes règles ne servent à rien, sans ta ligne acceptant les established, rien ne passe". Commentaire à prendre en compte et possibilité de faire fonctionner le tout sans cette ligne, via une autre solution ? Ou on m'a juste embrouillé et commentaires à oublier ?
[^] # Re: Merci ! Encore quelques questions...
Posté par LaBienPensanceMaTuer . Évalué à 2.
C'est ça.
Bein, effectivement, tes règles n'autorisent que le début de la connection. Sans le established, elles ne servent donc "virtuellement" à rien.
Si tu veux faire sans la règle established, alors il te faut autoriser tout les flux un à un (comme on le ferait sur un firewall dit stateless).
Par exemple, pour le web:
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT #flux sortant
iptables -A INPUT -p tcp --sport 80 -j ACCEPT #flux retour
Sauf que:
1/ C'est un poil pénible à faire.
2/ Ca pourrait être exploiter par un petit malin qui, connaissant ta façon de filtrer, utiliserait un port source == 80 pour passer.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1.
Merci bien !
Et donc, si je comprend bien, la règle established, elle, ne permettrai pas à un petit malin de faire la même chose ? Après tout, le port est finalement ouvert de même ?
[^] # Re: Merci ! Encore quelques questions...
Posté par LaBienPensanceMaTuer . Évalué à 2.
Oui car dans ce cas là, ton noyau va maintenir une table ip source/port source/ip destination/port destination et n'autoriser le flux que selon ces informations.
C'est le côté statefull.
Alors qu'en stateless, dès que tu viens du port 80, c'est open.
Regarde un peu du côté de l'outil en ligne de commande
conntrackqui te permet de montrer justement les connections dont le noyau s'occupe, c'est très instructif :)[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1.
Parfait ! Merci encore !
Et petite question, maîtrises-tu par extension ip6tables ?
J'avais lu qu'il suffisait de transposer ses règles iptables. Mais juste avec iptables, smtp fonctionne, avec iptables + ip6tables, il ne fonctionne plus. Or je l'utilise pour m'envoyer des rapports type logwatch etc.
[^] # Re: Merci ! Encore quelques questions...
Posté par LaBienPensanceMaTuer . Évalué à 2.
Pas du tout :-(
Me former à IPv6 est dans ma todo list depuis quelques années …
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1.
Bonne chance ahah !
Encore une petite question, tu me disais que iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT ne faisait pas de sens (established sur output).
Mais sans, qu'avec le input established, ça ne marche plus ! Plus d'accès au net.
Les deux sont donc bien nécessaires finalement ?
[^] # Re: Merci ! Encore quelques questions...
Posté par gUI (Mastodon) . Évalué à 3.
A te lire, on a le sentiment que le port ouvert c'est le point faible de ta sécurité. Attention, il y a des nuances, et c'est là toute le cœur de la discussion entre Gérald d'une part et Bruno et moi d'autre part.
Ce qu'il faut bien comprendre, c'est que de base, ton kernel, il va dropper tous les messages. Tout ce qui entre va partir directement à la poubelle. En effet, le kernel n'implémente aucun service réseau (j'oublie ICMP pour les besoins de la démonstration - et peut-être autre chose ?), il n'est pas là pour ça. Donc pas besoin de "INPUT DROP", c'est ce qu'il fera de toutes façons.
Si un jour tu veux jouer avec Apache par exemple, tu vas lancer le programme Apache, et la première chose qu'il va faire c'est dire au kernel "bon, dès que t'as un truc sur le port 80, tu me l'envoies". Du coup, quand un message arrive sur le port 80, le kernel l'envoie au processus Apache (au lieu de le jeter).
Et attention, la faille potentielle, le trou de sécurité, la peur du petit malin, elle n'est pas dans le fait que le port 80 soit ouvert. La faille si elle existe, elle est dans Apache et nulle part ailleurs. Au moment où tu installes Apache, tu dois te dire "merde, j'ajoute un programme qui va traiter des messages venant de l'extérieur, je ne dois pas faire n'importe quoi". C'est ça LE réflexe de sécurité. Sur quel port j'écoute, et sur quelle interface j'écoute (ou quelle plage d'adresse j'autorise). Les règles de firewall qui se contentent d'ouvrir ou de fermer des ports ne te serviront à rien : en effet tu vas ouvrir le port 80 (sinon ça marche pas), et Apache les traitera, exactement comme si tu n'avais pas de règles du tout. Les règles dont vous parlez depuis le début de ce thread ne serviront en rien à mieux protéger ton ordinateur, même dans cette situation (un desktop avec qques serveurs bien définis comme SSH, Apache, MySQL etc.)
Des règles firewall intéressantes c'est par exemple ce qui te permet de bannir une IP qui tente un peu trop de se connecter à ton SSH (style fail2ban), ou qui limitent une attaque DDOS (des milliers de requêtes qui arrivent simultanément sur ton Apache pour tenter de mettre à plat ton serveur). Là oui, tu améliores la situation par rapport à si tu n'avais pas de firewall du tout. Là oui tu te protèges mieux.
Voilà donc le message c'est attention au faux sentiment de sécurité : "j'ai mis Apache, mais j'ai un firewall donc ça va". Si le firewall en question se contente de tout fermer sauf le port 80, en fait il ne t'aide pas spécialement, le kernel l'aurait fait tout seul.
Tu peux par exemple faire un simple
netstat -l, qui va te lister tous les ports en écoute sur ta machine. Ça veut dire que derrière il y a un service prêt à répondre (et donc potentiellement une faille). Vérifie déjà que tu es d'accord avec cette liste et que tu as bien compris chaque service à quoi il sert. Une fois ceci fait tu peux dormir tranquille, même sans INPUT DROP :)En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . Évalué à 1. Dernière modification le 26 avril 2019 à 07:46.
Ok, ça, ça me permet d'y voir plus clair quand l'utilité de ma démarche.
Ceci dit, comme je disais, l'utilité n'est pas ce qui m'intéresse, j'ai envie de répondre à ma curiosité, et à ma paranoïa dans une moindre mesure (plus exactement, sensation de sécurité).
Si configurer IPtables me permet de répondre à ces deux exigences, quand bien même ça ne serait pas utile d'un strict point de vue sécurité vu les conditions dans lesquelles j'utilise ce PC…
Mais je comprend parfaitement ce que tu me dis. Et ça m'aide grandement, parce que je me prennai bien la tête à vouloir tout régler au plus vite.
Vu qu'il n'y a pas de vraie utilité, et donc aucune urgence, au moins maintenant je me prendre mon temps.
# IP6tables
Posté par redraven . Évalué à 1. Dernière modification le 25 avril 2019 à 19:09.
Pour rappel, j'en suis à ceci :
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
// Autorise les connexions déjà établies et localhost
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
// TOR
iptables -A OUTPUT -p tcp -m tcp --dport 9050 -j ACCEPT
// DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
// HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
// HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
// Mail SMTP
// iptables -A INPUT -p tcp --dport 25 -j DROP
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
// iptables -A INPUT -p tcp --dport 587 -j DROP
// iptables -A OUTPUT -p tcp --dport 587 -j DROP
// Transmission
iptables -A INPUT -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p udp --dport 51413 -j ACCEPT
// NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
Qui me semble fonctionnel et minimal.
Sauf que le même ensemble de règles avec ip6tables en plus, tout fonctionne sauf smtp.
Merci d'avance.
NB : comment faire sur ce forum pour que # ne soit pas interpreté comme titre, afin de gagner en lisibilité ? Remplacé par // bien que ça ne fasse aucun sens, en attendant.
[^] # Re: IP6tables
Posté par gUI (Mastodon) . Évalué à 2.
Il faut que tu déclares du code : 3 backquotes seules sur une ligne, en début et en fin de ton listing. C'est pas très clair dans l'aide mémoire (en bas de la page d'édition), reprend l'exemple du code Ruby, mais sans mettre le mot 'ruby'
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: IP6tables
Posté par redraven . Évalué à 1.
Merci !
Pas de pistes pour ip6tables ? j'avoue que je n'y comprend plus rien.
# Avis
Posté par redraven . Évalué à 1.
Bonjour !
Un petit avis sur la dernière version de mon iptables ci-dessus ?
Des optimisations ?
Pas d'oubli, bien sécurisé ?
Merci d'avance !
[^] # Re: Avis
Posté par redraven . Évalué à 1.
Et une petite chose que je ne comprend pas :
Pour transmission j'ai :
iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT
J'avais par mégarde modifié en dport, et ça ne fonctionnait plus.
En revanche tout mes output http, https etc. fonctionnent avec du ouput --dport.
Que se passe-t-il ?!
Merci d'avance
# Petit up
Posté par redraven . Évalué à 1.
Je me permet un petit up pour ma dernière question.
Et même si ça sera redondant avec mon autre post, je me permet de les poser ici aussi :
Quelle est la meilleure solution pour appliquer mes règles avant la connexion au réseau via le networkmanager ? On m'a fait remarquer que /etc/network/if-pre-up.d/iptables n'allait pas, et init.d/ non plus… Je suis coincé.
Tout ce que je vois comme littérature sur le sujet ne mentionne que ces possibilités là (ou iptables-persistent qui n'est visiblement plus d'actualité).
Aussi, d'autres optimisations quant aux règles ?
A part un pare-feu bien configuré, d'autres outils nécessaires pour assouvir ma fichue paranoïa ? ahah.
Merci d'avance !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.