Forum Linux.debian/ubuntu IPtables -configuration

Posté par . Licence CC by-sa.
1
24
avr.
2019

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 0

J'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 . Évalué à 2 (+2/-1).

    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

    iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

    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

    iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT

    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 . Évalué à 1 (+0/-0).

      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.

      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.

      C'est là que le ESTABLISHED rentre en compte.

      Non. En gros ESTABLISHED sert à autoriser les réponses aux initiations de connexion de la machine.

      • [^] # Re: port dynamique

        Posté par (page perso) . Évalué à -1 (+0/-3).

        Revoir le cours réseau TCP.

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: port dynamique

          Posté par (page perso) . Évalué à 2 (+0/-0).

          C'est moi qui était dedans, mes neurones ont mixé socket et port…

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Commencer par le début

    Posté par . Évalué à 2 (+2/-1).

    Ç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 . Évalué à 1 (+1/-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 !

    • [^] # Re: Commencer par le début

      Posté par . Évalué à -1 (+1/-4).

      Pour la suite, par contre, j'ai passé des heures et des heures à tester chaque règle jusqu'à ce que firefox, transmission etc. fonctionne…

      Un pare-feu sur une machine de bureau sous Linux est inutile (dans 99,9% des cas).

      • [^] # Re: Commencer par le début

        Posté par (page perso) . Évalué à 2 (+0/-0).

        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:

        1. 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)

        2. 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 …

        • [^] # Re: Commencer par le début

          Posté par . Évalué à 3 (+2/-1).

          Je veux bien que tu m’expliques en quoi un pare-feu va répondre à chacune de ces deux problématiques.

          • [^] # Re: Commencer par le début

            Posté par (page perso) . Évalué à 2 (+0/-0).

            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 ?

            • [^] # Re: Commencer par le début

              Posté par . Évalué à 3 (+2/-1).

              Non.

              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.

              Si tu as déployé à l'arrache et que ce devait être accessible de l'extérieur, le pare-feu avec les ports http/https ouverts n'y aurait donc rien changé.
              Mysql n'est en écoute que sur l'interface de bouclage et ce n'est généralement pas installable sans mot de passe « root » (Celui-ci n'est plus nécessaire sur les versions récentes de toute façon).

              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).

              On est dans le même cas que précédemment, si le service SSH devait être accessible de l'extérieur le port a été ouvert et le pare-feu n'y change rien.

              Eviter qu'un petit malin exploite des failles dites 0 days (failles non divulguées au publique qu'un pirate garde pour lui).

              Tu connais beaucoup de cas où de telles failles ont été exploitées sur un système GNU/Linux ? De toute façon si ce sont des failles dans un service, on est toujours dans le même cas: tu as probablement ouvert le port concerné de ton pare-feu parce que tu avais besoin d'y accéder de l'extérieur. La faille est donc toujours potentiellement exploitable.

              Eviter qu'un partage samba sur lequel t'as mis tes photos soit browseable par n'importe qui

              Si tu as mis en place un partage samba c'est que tu es sur un réseau local privé. Personne (enfin j'espère) n'utilise de partage SMB accessible sur l'Internet.

              Eviter qu'un petit malin s'amuse à vider les cartouches d'encre de ton imprimante à cause d'un CUPS mal configuré

              Par défaut CUPS n'est en écoute que sur l'interface de bouclage. Si ce n'est pas le cas c'est que tu as volontairement partager ton imprimante sur un réseau (privé en principe).

              De manière générale la sécurité commence par la sécurisation des services qui sont en écoute plutôt que d'essayer d'enfoncer des portes ouvertes (ouvrir des ports sur lesquels un service est déjà en écoute) ou de mettre des cadenas sur les murs (fermer des ports sur lesquels aucun service n'est en écoute).

              Et si comme tu me dis tu fais n'importe quoi sur ton poste de travail : installer des tas de services sans passer par les dépôts officiels, tu finiras par avoir des problèmes et le pare-feu n'aurafait que te donner un faux sentiment de sécurité.

              • [^] # Re: Commencer par le début

                Posté par (page perso) . Évalué à 2 (+0/-0).

                Si tu as déployé à l'arrache et que ce devait être accessible de l'extérieur, le pare-feu avec les ports http/https ouverts n'y aurait donc rien changé.

                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).

                Mysql n'est en écoute que sur l'interface de bouclage et ce n'est généralement pas installable sans mot de passe « root » (Celui-ci n'est plus nécessaire sur les versions récentes de toute façon).

                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 ?

                On est dans le même cas que précédemment, si le service SSH devait être accessible de l'extérieur le port a été ouvert et le pare-feu n'y change rien.

                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.

                Tu connais beaucoup de cas où de telles failles ont été exploitées sur un système GNU/Linux ?

                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.

                De toute façon si ce sont des failles dans un service, on est toujours dans le même cas: tu as probablement ouvert le port concerné de ton pare-feu parce que tu avais besoin d'y accéder de l'extérieur. La faille est donc toujours potentiellement exploitable.

                Dixit ma remarque plus haut. Que le service soit là à ne rien faire n'implique pas qu'on l'ouvre sur l'extérieur…

                Si tu as mis en place un partage samba c'est que tu es sur un réseau local privé. Personne (enfin j'espère) n'utilise de partage SMB accessible sur l'Internet.

                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é …

                De manière générale la sécurité commence par la sécurisation des services qui sont en écoute plutôt que d'essayer d'enfoncer des portes ouvertes (ouvrir des ports sur lesquels un service est déjà en écoute) ou de mettre des cadenas sur les murs (fermer des ports sur lesquels aucun service n'est en écoute).

                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 (page perso) . Évalué à 2 (+0/-0).

                J'ai oublié de répondre à ça:

                Et si comme tu me dis tu fais n'importe quoi sur ton poste de travail : installer des tas de services sans passer par les dépôts officiels, tu finiras par avoir des problèmes et le pare-feu n'aurafait que te donner un faux sentiment de sécurité.

                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 . Évalué à 2 (+1/-1). Dernière modification le 24/04/19 à 16:16.

              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).

              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 (page perso) . Évalué à 1 (+1/-2).

                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 (page perso) . Évalué à 2 (+0/-0).

                  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 . Évalué à 2 (+1/-1).

                    C'était un exemple.

                    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 (page perso) . Évalué à 1 (+0/-1).

                      Bin oui mais c'est facile de prendre les gens de haut en donnant des exemples dans le vide.

                      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.
                      > On égraine les autres exemples aussi ?

                      Vazy je t'en prie.

                      La seule règle de firewall que j'ai vu passer dans tes commentaires c'est iptables -P INPUT DROP.

                      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.

                      • [^] # Re: Commencer par le début

                        Posté par . Évalué à 3 (+2/-1).

                        Et quelle est la règle de pare-feu qui permet de se prémunir contre cet exploit ?

                        • [^] # Re: Commencer par le début

                          Posté par (page perso) . Évalué à 3 (+1/-0).

                          Je vais replacer une dernière fois le contexte car ça a l'air confus dans ton cerveau:

                          1. On est sur une station de travail qui n'est pas sensé offrir un service réseau.
                          2. On y a installé un wordpress pour "tester"
                          3. On a pas nettoyé derrière.

                          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.

                          • [^] # Re: Commencer par le début

                            Posté par . Évalué à 3 (+1/-0).

                            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.

                            C'est toi qui fait de ton usage particulier une généralité.
                            Un débutant n'installe pas de services (web, ssh, ou autre) donc pas de ports ouverts, sa machine est généralement sur un réseau privé derrière une box : le pare-feu y est totalement inutile.

                            Le rôle du pare-feu (pour ton usage) est de bloquer ou filtrer l'accès à des ports ouverts qu'on ne veut pas laisser accessibles. C'est un usage légitime mais bien particulier et même dans ce cas on peut très bien se passer de pare-feu : il suffit de faire attention à ce que l'on installe et surtout comment on le configure. Et les services cela peut se lancer à la demande.

                            Le problème c'est qu'on a tellement bourré le crâne des gens avec la soi-disant nécessité absolue du pare-feu pour se protéger des « attaques » qu'ils se croient en sécurité alors qu'ils oublient d'appliquer les principes de base : ne pas faire tourner de services inutiles, séparation des privilèges, droits d'accès minimaux, etc.
                            Ton exemple avec Wordpress le montre bien : si le service est accessible de l'Internet aucune règle iptables ne peut te prémunir contre cette faille, les principes que j'évoque le peuvent (ou au moins minimiser son impact).

                            • [^] # Re: Commencer par le début

                              Posté par (page perso) . Évalué à 2 (+0/-0).

                              C'est toi qui fait de ton usage particulier une généralité.

                              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.

                              Un débutant n'installe pas de services (web, ssh, ou autre)

                              Bien souvent, des services font partie de l'installation par défaut.

                              donc pas de ports ouverts, sa machine est généralement sur un réseau privé derrière une box : le pare-feu y est totalement inutile.

                              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 ?

                              Le rôle du pare-feu (pour ton usage) est de bloquer ou filtrer l'accès à des ports ouverts qu'on ne veut pas laisser accessibles. C'est un usage légitime mais bien particulier

                              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 ?)

                              et même dans ce cas on peut très bien se passer de pare-feu : il suffit de faire attention à ce que l'on installe et surtout comment on le configure. Et les services cela peut se lancer à la demande.

                              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 …).

                              Le problème c'est qu'on a tellement bourré le crâne des gens avec la soi-disant nécessité absolue du pare-feu pour se protéger des « attaques » qu'ils se croient en sécurité

                              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.

                              alors qu'ils oublient d'appliquer les principes de base : ne pas faire tourner de services inutiles, séparation des privilèges, droits d'accès minimaux, etc.

                              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 ;-)

                              Ton exemple avec Wordpress le montre bien : si le service est accessible de l'Internet aucune règle iptables ne peut te prémunir contre cette faille, les principes que j'évoque le peuvent (ou au moins minimiser son impact).

                              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 . Évalué à 3 (+2/-1).

                        Quel est l'objet de cette remarque ?

                        Tu dis que le firewall est la solution à ces problèmes, mais tu ne dis pas avec quelle règle.

                        Oui, c'est, de mon point de vue, la seule règle à mettre sur un firewall de desktop.

                        Si c'est pour dire ça, c'est pas iptables qu'il te faut, mais ifdown.

                        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 (page perso) . Évalué à 3 (+1/-0).

                          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 . Évalué à 1 (+0/-1). Dernière modification le 25/04/19 à 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 (page perso) . Évalué à 2 (+0/-0).

                              Quel argumentaire ! Tu es si constructif…

                              • [^] # Re: Commencer par le début

                                Posté par . Évalué à 1 (+0/-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 (page perso) . Évalué à 2 (+0/-0).

                                  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 . Évalué à 1 (+0/-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 (page perso) . Évalué à 2 (+0/-0).

                                      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 . Évalué à 2 (+2/-2).

          Affirmer ce genre de chose avec tant d'aplomb est d'une stupidité rare …

          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 (page perso) . Évalué à 4 (+2/-0).

      Les flags

      Concernant les flags TCP, une connection TCP/IP "normale" se déroule ainsi:

      1. client --- SYN ---> serveur
      2. serveur --- SYN,ACK ---> client
      3. client --- ACK ---> serveur

      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:

      • Les autres flags peuvent également être utilisés mais de façon plus marginale.
      • Chaque OS traite les paquets "invalides" à sa façon.

      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 (page perso) . Évalué à 4 (+2/-0). Dernière modification le 24/04/19 à 14:02.

        Ajout:

        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 (page perso) . Évalué à 2 (+0/-0).

          Dernier ajout (car les règles iptables ça passent souvent mieux après plusieurs lectures ;-p)

          iptables -A INPUT -m state --state ESTABLISHED -p udp --dport 51413 -j ACCEPT
          iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT
          
          ta règle INPUT, si je ne me trompe pas, n'autorise que les connections établies... mais n'autorise pas les connections à s'établir pour autant.
          
          D'ailleurs, cette règle ne sert à rien car déjà couverte par tes premières règles:
          
          iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
          iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
          
          
          Et dernier truc, quand tu listes tes règles avec iptables -L, rajoute un -v, ça va te rajoute devant chaque ligne le nombre et le volume des paquets que la règle a matché.
          Utile pour savoir si une règle sert à quelque chose.
          
    • [^] # Re: Commencer par le début

      Posté par . Évalué à 3 (+2/-0).

      un peu moins la partie avec les --tcp-flags (c'est ma lecture du moment, tout lire sur ce qui suis ce paramètre).

      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.

      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

      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.

      Où se trouve les erreurs dans ce qui suis ?

      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 DROP
      Avec ça tu bloques tout le trafic TCP.

      ̀iptables -A FORWARD -m state --state INVALID -j DROP
      La chaîne FORWARD ne sert à rien sur une machine qui ne fait pas routeur.

      iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
      De l'ESTABLISHED dans la chaîne OUTPUT n'a pas trop de sens.

      iptables -A INPUT -p icmp -j DROP
      Mauvaise 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 . Évalué à 1 (+0/-0).

        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 (page perso) . Évalué à 3 (+1/-0).

        Globalement d'accord avec toi Bernez.
        Juste une petite correction:

        iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
        Avec ça tu bloques tout le trafic TCP.

        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 . Évalué à 1 (+0/-0).

          Non, ce n'est pas le cas. Il va bloquer tout les packets ou tout les flags sont à 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 . Évalué à 1 (+0/-0). Dernière modification le 24/04/19 à 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 . Évalué à 1 (+0/-0). Dernière modification le 25/04/19 à 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 (page perso) . Évalué à 2 (+0/-0).

        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 . Évalué à 1 (+0/-1).

          C'est à cela que sert les lignes s'appuyant sur l'état ESTABLISHED

          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 (page perso) . Évalué à 2 (+0/-0). Dernière modification le 25/04/19 à 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 . Évalué à 1 (+0/-0).

              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 (page perso) . Évalué à 2 (+0/-0).

                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é ?

                C'est ça.

                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 ?

                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 . Évalué à 1 (+0/-0).

                  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 (page perso) . Évalué à 2 (+0/-0).

                    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 conntrack qui te permet de montrer justement les connections dont le noyau s'occupe, c'est très instructif :)

                    • [^] # Re: Merci ! Encore quelques questions...

                      Posté par . Évalué à 1 (+0/-0).

                      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 . Évalué à 3 (+1/-0).

                    Après tout, le port est finalement ouvert de même ?

                    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 . Évalué à 1 (+0/-0). Dernière modification le 26/04/19 à 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 . Évalué à 1 (+0/-0). Dernière modification le 25/04/19 à 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 . Évalué à 2 (+0/-0).

      NB : comment faire sur ce forum pour que # ne soit pas interpreté comme titre

      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 . Évalué à 1 (+0/-0).

        Merci !

        Pas de pistes pour ip6tables ? j'avoue que je n'y comprend plus rien.

  • # Avis

    Posté par . Évalué à 1 (+0/-0).

    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 . Évalué à 1 (+0/-0).

      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 . Évalué à 1 (+0/-0).

    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 !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.