Journal Script Iptables

Posté par .
Tags : aucun
2
29
juin
2009
Le script de Tero Karvinen permet de mettre en place un pare-feu léger pour un ordinateur personnel. J'ai juste fais quelques ajustements pour ceux que ça intéresse :
  • Organisation plus claire
  • Pas de réponse aux demande de ping
  • Survie des règles au redémarrage qui fonctionne pour Debian

#!/bin/sh
# firewall.sh - Configurable per-host firewall for workstations and
# servers.(c) 2003 Tero Karvinen - tero karvinen at iki fi - GPL

# Policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Cleanup old rules
iptables --flush
iptables --delete-chain

# Rules
iptables -A INPUT -i lo -s localhost -d localhost -j ACCEPT
iptables -A INPUT -m state --state "ESTABLISHED,RELATED" -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# Holes
#iptables -A INPUT -p udp -s mafreebox.freebox.fr -j ACCEPT
#iptables -A INPUT -p tcp --dport 51413 -j ACCEPT

# Save
iptables-save > /etc/iptables.up.rules
echo "#!/bin/sh" > /etc/network/if-up.d/iptables
echo "iptables-restore < /etc/iptables.up.rules" >> /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables
echo "Firewall(.sh) : done"
  • # Troll

    Posté par . Évalué à 10.

    Quel est l’intérêt d’utiliser une licence de plusieurs dizaines de pages pour un script d’une dizaines de lignes que n’importe qui est en mesure de refaire en lisant une page de man ?
    Quel est, de base, l’intérêt de simplement spécifier une licence pour un truc comme ça ? Si encore c’étaient dix lignes de Ook ou de Brainfuck, je pourrai comprendre, mais là…

    Vous pouvez moinser.
    • [^] # Re: Troll

      Posté par . Évalué à 3.

      Tout à fait d'accord.

      Qui plus est, même pour une portée éducative, ce script ne comporte pas le moindre commentaire expliquant la signification de chaque ligne.

      Je doute enfin que Tero ait pu ajouter quelques lignes concernant sa freebox finlandaise, même en commentaire.

      Quel peut donc bien être l'intérêt de ce script ?

      Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

      • [^] # Re: Troll

        Posté par . Évalué à 4.

        Moi il m'a été utile, donc j'ai penser qu'il le serait pour d'autre, tout simplement...
        • [^] # Re: Troll

          Posté par (page perso) . Évalué à 2.

          Moi il m'a été utile, donc j'ai penser qu'il le serait pour d'autre, tout simplement...

          Certes, il est fonctionnel mais pour une personne qui un jour ou l'autre aura besoin d'affiner une règle ou deux ce sera un peu plus dur de broder autour.

          Non pas que les règles soient mauvaises ou que ce soit impossible, mais sans explication sur les options, l'importance de l'ordre des règles, ... cela fera sûrement perdre beaucoup de temps au départ.

          À moins d'être dans un univers hostile ouvert à tout vent (hotspot wifi public, ...) autant prendre le temps de consulter un bon tutoriel sur le sujet pour préparer ses règles au fur et à mesure.

          pub subliminale
          http://olivieraj.free.fr/fr/linux/information/firewall/index(...) mais il y a sûrement d'autres sites de la même veine
    • [^] # Re: Troll

      Posté par . Évalué à 2.

      L'intérêt de ce script est de donner un bon exemple de l'utilisation d'iptable. Un best-pratice en quelque sorte, a savoir :
      - déterminer une politique générale (tout rejeter ou tout accepter
      - effacer les anciennes règles (ça peut être drôlement embêtant si on l'oublie)
      - des exemples basiques mais néanmoins très didactiques sur des autorisations spécifiques.
      - etc

      C'est beaucoup plus facile de lire une page de man ensuite en se basant sur ce genre d'exemples, car on voit déjà comment utiliser concrètement iptables dans les grandes lignes. Les pages man se contentent malheureusement trop souvent d'être un listing d'options commentées.
      • [^] # Re: Troll

        Posté par (page perso) . Évalué à 4.

        Dans ce cas pourquoi ne pas proposer de modifier la page de man afin d'y inclure ces exemples et de les commenter (comme dans la page de man de Packet Filter) ? Ça sera toujours mieux que d'avoir l'exemple dissocié de la signification des options.
  • # claire

    Posté par . Évalué à 9.

    Je ne sais pas pour vous, mais claire et iptables ensembles ça sonne assez faux...
    On peut faire la même chose en 2 fois moins long avec packet filter et lisible facilement.
    • [^] # Re: claire

      Posté par . Évalué à 7.

      Oui mais tu perds de ta superbe et de ton aura, tel un médecin et son ordonnance indéchiffrable ...

      Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

      • [^] # Re: claire

        Posté par . Évalué à 3.

        Oui, mais tu gagnes en tant qu'informaticien feignant par définition qui cherche à automatiser le plus simplement possible quelque chose d'à priori compliqué.
        • [^] # Re: claire

          Posté par . Évalué à 2.

          Je pense que tu voulais dire : fainéant, et pas feignant (du verbe feindre) qui n'a pas grand chose à voir.
          • [^] # Re: claire

            Posté par . Évalué à 3.

            ah oui effectivement, j'ai été fainéant sur sa relecture!!!
          • [^] # Re: claire

            Posté par (page perso) . Évalué à 2.

            oui mais les profs adorent dire feignant pour confondre les élèves
            ils disent même feeeeeiiiiignant
            et autrefois on devait dire fait-néant
            du coup les élèves survivants ne savent plus quoi dire
            et personne n'engueule les profs
            ah il est loin le temps des cahiers au feu
            et la maîtresse au milieu

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: claire

            Posté par (page perso) . Évalué à 3.

            Consulte le TLFI, et tu verras qu'il a raison.
          • [^] # Re: claire

            Posté par (page perso) . Évalué à 3.

            Encore une couche :

            Si, de fait, les formes faignant ou feignant sont aujourd’hui « populaires », elles sont les premières attestées, et c’est fainéant qui a constitué une altération populaire, d’après fait (forme verbale de faire) et néant, de faignant, feignant, participe présent de feindre, au sens ancien de « se dérober (à la tâche), rester inactif ».

            source : http://academie-francaise.fr/langue/questions.html#faineant
    • [^] # Re: claire

      Posté par . Évalué à 1.

      C'est qui Claire ?

      C'est moi ou c'est devenu à la mode de mettre des "e" à la fin des mots quand ils n'en nécessites pas ? Une histoire de parité ? Une volonté de supplanter l'erreur fréquemment commise "é" VS "er" des verbes ?
      • [^] # Re: claire

        Posté par . Évalué à 1.

        Tiens je viens de me rendre compte que dans ce cas précis c'était peut-être justifié.
        op je me cache.
        J'ai craqué et posté sur le mauvais exemple, les lois de Murphy sont impénétrable...
      • [^] # Re: claire

        Posté par (page perso) . Évalué à 3.

        ils n'en nécessites pas
        "nécessitent"
        L'arozeure arozé :-)
    • [^] # Re: claire

      Posté par . Évalué à 3.

      Je suis d'accord en ce qui concerne cet exemple. Avec pf c'est plus lisible et plus abordable.

      Par contre je suis plus mitigé en ce qui concerne un exemple compliqué, par exemple un grand nombre de serveurs avec du nat.

      Dans ce cas, moi qui ait appris à maîtriser la syntaxe netfilter (dans la douleur, certes), pf me pose des soucis. Par exemple, je n'arrive pas à saisir le cheminement d'un paquet dans les différentes règles. Avec netfilter, à défaut d'être simple et clair c'est bien expliqué, y'a même un schéma [1].

      Je n'ai jamais été fichu de me mettre dans la tête à quoi faisait référence « in » et « out » : à l'interface ? au système ?

      Intellectuellement j'aurais envie de dire l'interface, mais à chaque fois j'ai un doute.

      Autre chose qui fait que c'est parfois pas facile à lire, toujours dans le cas d'un grand nombre de serveurs avec du nat, c'est qu'on est obligé de mettre d'abord les règles de nat etc, et ensuite les règles de filtrage. Pas moyen de faire des blocs de règles nat + filtrage par serveur par exemple.

      Après, qu'on ne me fasse pas dire ce que je n'ai pas dit, techniquement je n'ai rien à reprocher à pf bien au contraire. Notamment la notion d'ancres (dommage qu'on ne puisse pas hériter des macros) et de tables est géniale (netfilter a ipset mais c'est plus compliqué à mettre en oeuvre). Ah si, un truc qui m'embête quand même : l'absence de conntrack pour le ftp. ftp-proxy, sur un grand nombre de serveurs NATés, c'est pas gérable [2].



      [1] http://fr.wikipedia.org/wiki/Fichier:Netfilter_schema.png - Si quelqu'un me trouve l'équivalent pour PF je suis preneur.
      [2] oui, le NAT c'est mal, et le ftp aussi, mais il faut bien faire avec l'existant, et c'est quand même bien pratique.
  • # Pas de réponse aux demande de ping

    Posté par (page perso) . Évalué à 6.

    Pourquoi ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Pas de réponse aux demande de ping

      Posté par . Évalué à -2.

      Ça sert à rien de laisser passer du traffic pour rien. J'ai pas besoin que ma machine réponde aux ping. La machine apparaît hors ligne lors d'un ping scan, c'est toujours ça.
    • [^] # Re: Pas de réponse aux demande de ping

      Posté par . Évalué à 7.

      Je vais même aller plus loin, et proposer quelque chose de bien plus malin, une limitation de débit sur les réponses au ping (protection anti-ping flood) :

      <pre>
      # Protection ping-flood
      iptables -A ICMPINPUT -p icmp -m state --state ESTABLISHED -j ACCEPT
      iptables -A ICMPINPUT -p icmp --icmp-type echo-request -m limit --limit 3/s -j ACCEPT
      iptables -A ICMPINPUT -p icmp --icmp-type echo-request -m limit --limit 6/m -j LOG --log-prefix "[PING_FLOOD] "
      iptables -A ICMPINPUT -p icmp -j REJECT

      # L'icmp entrant passe a travers la chaine ICMPINPUT
      iptables -A INPUT -p icmp -j ICMPINPUT
      </pre>

      Un équivalent existe pour le SYN flood, laissé à la sagacité du lecteur ;)
    • [^] # Re: Pas de réponse aux demande de ping

      Posté par (page perso) . Évalué à 2.

      Pour rien. Franchement, à part un scrtAccessoirement le script doit pas laisser passer les messages de MTU discovery, ce qui promet des problèmes sympatiques.

      iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT
      iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
      • [^] # Re: Pas de réponse aux demande de ping

        Posté par . Évalué à 4.

        Je rajouterai même qu'il ne faudrait pas du tout bloquer l'ICMP, ça sert à plein de choses : le source-quench pour la QoS, le framentation-needed pour la découverte de MTU, etc.
        Bon, ils peuvent aussi être utilisés à mauvais escient aussi (respectivement pour ralentir une connexion, mais bon, c'est le but de la QoS, augmenter le travail effectué par la pile IP, et puis aussi spoofer grâce à l'icmp-redirect), mais quand même, les OS modernes sont à peu près protégés de ça.

        Et surtout, SURTOUT, en IPv6, l'ICMP sert à tout : le router-advertisement pour broadcaster son préfixe et faire ainsi l'autoconfiguration, pour le neigbour discovery (équivalent d'ARP), la distribution de paramètres comme les serveurs DNS, etc.

        Bref, ne bloquez pas tout inutilement, vous pourriez le regretter un jour où vous aurez oublié que vous le bloquiez, et vous ne comprendrez pas pourquoi ça ne marche pas ...
        • [^] # Re: Pas de réponse aux demande de ping

          Posté par . Évalué à 3.

          Dans l'icmp il y a deux choses qui me dérangent :
          · le fait qu'il soit très simple de tuneller à peu près n'importe quoi dans le ping (bon ça marche aussi avec les requêtes DNS, et d'autres trucs...)
          · il y a beaucoup de types / codes inusités, qui servent beaucoup au fingerprinting et à la découverte de réseaux (http://www.securitypronews.com/securitypronews-24-20030929OS(...) est un bon résumé)

          En ce qui concerne le premier point, un bon IDS fait l'affaire pour la majeure partie des cas (et quand le contenu est crypté au point d'être invisible, ben c'est qu'on est tombé sur un sacré balaise, et là on a du souci à se faire). De plus, limiter le nombre de réponses au ping va poser des problèmes à l'utilisateur du tunnel (par exemple ne répondre qu'à 1 ping sur 3).

          Pour le second, il y a des méthodes qui relèvent plus de la configuration des systèmes protégés que du pare-feu lui même. Par exemple, sous linux, ne pas répondre à un ping sur l'adresse de réseau ou de diffusion. Ce genre de chose se configure à coup de sysctl. De plus, on peut limiter les réponses aux types de messages considérés comme légitimes.

          Voici ce que j'ai sur un pare-feu ipv4 only (en ipv6 j'ai pas encore creusé la question) :

          for icmptype in echo-request echo-reply fragmentation-needed port-unreachable host-unreachable ttl-exceeded; do
          $ipcmd -A INPUT -m limit --limit 2/second -p icmp --icmp-type $icmptype -j ACCEPT
          $ipcmd -A OUTPUT -p icmp --icmp-type $icmptype -j ACCEPT
          done


          $ipcmd contient évidemment "/sbin/iptables <les options que je veux toujours mettre>"

          (dans certains cas on peut vouloir autoriser l'icmp redirect en plus, mais c'est à limiter à l'interface sur laquelle on en a besoin).
          • [^] # Re: Pas de réponse aux demande de ping

            Posté par (page perso) . Évalué à 3.

            Pourquoi ça te dérange qu'il y ait des tunnels ? Pourquoi un tel gaspillage de moyens pour les empêcher ?

            Moi en ma qualité d'utilisateur, j'estime devoir être en mesure de me connecter en ssh à mon PC chez moi quand j'en ai envie. Et également j'estime avoir droit au respect de ma vie privée, donc mon firefox utilise une connexion SSL vers mon proxy SOCKS perso chez moi. Et si mon admin estime que ce n'est pas normal, celà signifie qu'il veut pouvoir surveiller à quel site je me connecte, et donc que j'ai raison de vouloir protéger ma vie privée.
            Après, il peut filtrer les procs, je mettrai mon proxy sur le porc 80, ou 443, ou whatever. Il peut essayer de détecter les communications qu'il ne veut pas avec un IDS comme toi, mais ça commence à être du grand n'importe quoi :
            * quel sont les buts recherchés ?
            * pourquoi l'entreprise ne peut pas faire confiance à ses salariés ?
            * qu'est-ce qui justifie d'investir autant là-dedans ?
            * n'est-ce pas de toutes façons voué à l'échec ? Un mec qui veut passer des données y arrivera, quitte à utiliser sa connxion 3G ou une bête clé USB.

            Il faudrait un peu arrêter avec ces conneries de flicage en entreprise, c'est pire que sarkoland dans bien trop d'endroits.
            • [^] # Re: Pas de réponse aux demande de ping

              Posté par . Évalué à 2.

              bon je sais c'est tardif mais c'était les vacances....

              Toujours est-il que ce n'est pas forcément une question de confiance, c'est une question de contrat.

              Quand on parle de réseau, ce n'est pas forcément un réseau d'utilisateurs... Ca peut être des serveurs, le tunnel icmp peut être une manière furtive de sortir des données, et ça peut poser un problème aux utilisateurs du dit serveur. Il y a peut-être des données confidentielles et personnelles dessus. Si quelqu'un parvient à s'introduire sur le serveur (mettons par une faille php, classique), l'idée est qu'il ne puisse pas sortir d'information sans que ça se voie... En plus j'ai déjà vu un gros truc bien évident (type reverse backdoor bloquée par le firewall, tentatives maladroite d'escalade de privilège) qui servait surtout à dissimuler une fuite d'information via un tunnel icmp ou DNS...

              Et puis bon, pour les réseaux interne, la question n'est pas de savoir si c'est bien ou pas, c'est de savoir si tu veux avoir la maîtrise de ton réseau. Si on bloque le ssh à l'extérieur, c'est pas pour laisser passer un truc aussi vieux qu'un tunnel icmp. Si on ne le bloque pas, on loggue au moins les accès externe pour savoir qui se connecte où, et faire la différence entre le gars qui se connecte de temps en temps chez lui pour faire de l'irc (inoffensif et pas gênant a priori) et celui qui uploade une énorme quantité de données en ukraine... Personnellement je n'ai aucun problème à laisser sortir un utilisateur en ssh pour se connecter à un serveur perso entre midi et deux, mais le jour où ça sert à sortir des infos confidentielles, c'est que je n'ai pas joué mon rôle. Sans parler du jour où ça sert à lancer des attaques dictionnaire un peu partout... ;-)

              La sécurité, c'est pas simple, ce n'est pas les gentils utilisateurs contre les vilains admins, ni l'inverse ; et surtout ça ne peut se faire que si tout le monde y met du sien. Il ne s'agit pas de s'aliéner les utilisateurs (même si parfois il y a des têtes de c**), mais de se protéger contre les indélicats (le gars qui passe plus de temps à bosser sur des trucs perso que pour l'entreprise, celui qui joue double jeu et tente de récupérer des clients à son compte avant de démissionner...), et contre les maladresses (j'ai cliqué sur le mauvais lien, ça m'a installé un troyen et maintenant on est attaqués en justice parce que notre ip de sortie a servi à pirater un ordinateur du minefi).

              Bien sûr qu'un type déterminé y arrivera. Ce n'est qu'une question de savoir faire, de motivation et de temps. Mais moi je suis payé pour lui compliquer la vie ! ;-)
          • [^] # Re: Pas de réponse aux demande de ping

            Posté par . Évalué à 2.

            Holala, t'as l'air parano quand même :
            - le tunneling par icmp ping, tu me parleras de l'efficacité ... franchement, c'est ce prendre la tête pour un problème minime
            - pour le fingerprinting : et alors ? je m'en fous qu'on sache que je tourne sous un OS sécurisé ;-) Et pour la découverte de réseau ... t'as une référence ?

            Je trouves ces problématiques bien trop tatillonnes pour ce que c'est. Bon, d'un autre coté, je ne suis pas admin réseau !
            • [^] # Re: Pas de réponse aux demande de ping

              Posté par . Évalué à 2.

              Problème minime, problème minime... Après, tout dépend de ce contre quoi tu veux te protéger, hein. C'est juste une histoire de gestion du risque, de confidentialité des données traitées (quand les données en question sont tes données personnelles, tu es bien content que l'entreprise qui en a la charge fasse attention à ce qu'elles ne se retrouvent pas dans la nature).

              Pour l'exemple de découverte du réseau, l'icmp c'est quand même le plus vieux protocole pour ça :-)

              Sinon, un exemple typique de découverte du réseau et de fingerprinting en une passe : envoyer un paquet icmp echo request sur l'adresse broadcast, et regarder qui répond quoi. Ou encore sur l'adresse du réseau, même principe. Les fonctionnement par défaut des os sont assez disparates (y'a ceux qui répondent normalement, ceux qui l'ignorent, ceux qui répondent un truc spécifique...).

              Quand aux dangers du fingerprinting, je suis assez d'accord à la base, mais au final c'est, plus qu'une véritable mesure de sécurisation (assimilable à une porte blindée ou une serrure), un truc qui permet de ralentir ou de décourager le pirate de passage. Ca ne fera que ralentir un peu le vrai gars déterminé, mais déjà si on s'est débarrassé des attaques automatiques et des Jean-Kévin c'est toujours ça de pris. On peut comparer ça au fait de mettre sa maison sur une colline un peu escarpée :-)

              Bon, après, le défaut c'est que ça peut avoir l'effet inverse chez le hacker - le vrai - curieux : « tiens ça m'a l'air bien protégé par ici... Est-ce que je vais réussir à passer, et qu'est-ce que ça cache ? » ;-)

              En plus on parle théorie, là, dans la vraie vie on n'a pas toujours le loisir de mettre autant de protections de manières systématique. Encore une fois, c'est une question de gestion du risque, il faut faire le rapport entre le risque qu'on prend quand on ne le fait pas et ce que ça coûte (en argent, temps, énergie...).
  • # serveur dedié (un poil hs)

    Posté par . Évalué à 2.

    bon je voulais ecrire un petit journal mais un petit commentaire suffira c'est dans le sujet.

    j'ai loué un serveur dedié avec une mise en place a 1H. aprés 1 journée d'attente je ne l'attendais plus. 48H plus tard ils m'envoient un mail vers 10h00 du matin que je lis vers les 20H00 comme quoi c'est bon mon serveur dedié sous debian 5.0 m'attend

    arg ! 10h00 tous seul sur le ternet, je m'empresse de mettre des regle iptable qui bloque tous entrée et sortie sauf ssh, j'avais deja fais une bourde a ce sujet \o/

    maintenant j'ouvre gentiment ce que j'ai besoin, histoire de de voir ce qui arrive sur mon serveur, j'utilise iftop http://www.ex-parrot.com/~pdw/iftop/ c'est simple et c'est efficace. bon je remarque que pas mal de personnes aimeraient avoir mon serveur pour leur propre besoin sans rien payer, et j'ai des tentatives de connection vers l'exterieur dont je n'arrive pas trouver l'origine snif...

    CONCLUSIONS: je pensai naivement qu'avec un dedié je serais un poil plus tranquille niveau securité qu'a la maison c'est faux, et c'est pire !

    sinon maintant j'eteind mes ordinateurs la nuit ainsi que ma freebox, j utilise le dedié principalement pour la compilation et d'autre truc necessitant de la puissance, et aussi comme support de sauvegarde.
    je saisis mieux l'interet d'avoir un eeepc, a la place de mon portable bruyant et de la tour qui prend de la place. En plus tous cela est bien au frais et en securité.
    • [^] # Re: serveur dedié (un poil hs)

      Posté par (page perso) . Évalué à 3.

      je pensai naivement qu'avec un dedié je serais un poil plus tranquille niveau securité qu'a la maison c'est faux, et c'est pire

      En fait c'est totalement logique. Un serveur dédié se trouve généralement dans un datacenter, ce qui est une assurance (en temps normal) de stabilité de la connectivité réseau et électrique. Ajoute à cela la grosse bande passante disponible (souvent symétrique d'ailleurs) et, dans une moindre mesure l'espace de stockage, les serveurs dédiés sont une cible de choix.

      On compare un serveur branché sur du 100Mbit/s symétrique avec 300Gio de disque et allumé 24x7 avec un pc domestique avec l'adsl 20Mbit/s en download et environs 1Mbit/s en upload et allumé on ne sait trop quand.
      • [^] # Re: serveur dedié (un poil hs)

        Posté par . Évalué à 4.

        J'ajouterai que du point de vue d'un individu malveillant, les machines domestiques sont surtout intéressantes pour les botnets, parce que ça permet de mieux distribuer, et parce qu'elles ont tendance à être moins surveillées.

        Du coup la cible c'est plutôt du windows, tout simplement parce qu'il y a moins de chances de se faire repérer (un utilisateur de système alternatif a tendance à s'intéresser à ce qui se passe sur son système), et qu'il y en a plus donc les attaques de masse sont plus rentables. En plus le layer 8 est généralement plus vulnérable.

        Par contre un serveur dédié, c'est royal pour tout ce qui demande de la bande passante ou une faible latence, et les machines unix-like sont idéales comme machines rebond pour attaquer d'autres machines.
        La finalité des attaques n'est donc pas la même (mais elles ne sont pas moins nombreuses pour autant, surtout que la durée de vie d'une machine piratée n'est pas forcément très longue, on se fait parfois repérer assez vite donc il faut en avoir un certain nombre sous le coude).

        Du coup, le "public" à l'origine des attaques est différent. D'ailleurs les moyens de sécurisation les plus rentables ne sont pas les mêmes non plus (par rentables, j'entend qui rapporte le meilleur ratio attaques/protection).

        Un serveur unix-like qui ne peut pas établir de connexions vers l'extérieur et qui n'a que du 80 et du 22 ouvert en entrée, et ce par un par feu sur une machine distincte, présente peu d'intérêt. Par contre toute possibilité de sortie (p2p, irc, web, ssh...) le rend particulièrement attrayant, si on a le moyen de le contrôler (et les connect-back servent à ça).
  • # Soit dit en passant.

    Posté par (page perso) . Évalué à 2.

    • [^] # Re: Soit dit en passant.

      Posté par (page perso) . Évalué à 2.

      Tu en fait collection ?

      Si tu en as trop, contacte moi en MP ;)
      • [^] # Re: Soit dit en passant.

        Posté par . Évalué à 3.

        Y'a pas la réponse à ma question de schéma (ci-dessus : https://linuxfr.org/comments/1044615.html#1044615) dedans par hasard ?
        • [^] # Re: Soit dit en passant.

          Posté par (page perso) . Évalué à 3.

          Alors, en fait, au tout début du Chapitre 3, y'a un paragraphe 3.1.1 qui s'appelle, je cite, Les passerelles, et le piège de in, out et on (pages 31 à 33). Cela devrait t'intéresser :).

          En gros, tu détermines le sens in et out par rapport au sens de l'interface "principale" de la machine qui sert de routeur (en règle générale c'est $ext_if vu que c'est celle qui a accès à Internet).

          Sinon, pour l'histoire des blocs NAT + filtrage, c'est à vérifier, mais maintenant que set require-order est à no par défaut (arrivé dans -current y'a quelques semaines, ce sera pour 4.6), y'a peut-être moyen de moyenner ce genre de construction...

          Le bouquin sort jeudi en librairie, alors tu pourras l'acheter et progresser. =)


          Cordialement,
          Maxime


          PS : Le livre donne deux exemples de scripts minimaux pour ordinateur personnel. C'est *beaucoup* plus court et vraiment très beaucoup plus lisible que le script donné dans ce journal...
          • [^] # Re: Soit dit en passant.

            Posté par . Évalué à 3.

            Mouais. C'est bien ce que je disais plus haut, c'est super trompeur dès qu'on sort du contexte (le plus répandu je veux bien l'admettre) de la passerelle de lan... Pour mon schéma clair je sens que je vais devoir demander à quelqu'un qui a lu le code (je suis bien conscient qu'étant donné que ça ne fonctionne pas du tout avec des hooks comme netfilter, ce type de schéma n'est pas forcément évident ni même nécessaire pour la compréhension, mais moi ça m'aiderait) ;-)

            Exemple de cas gênant : si ma machine c'est une passerelle dont le rôle est de tagguer des vlan (disons 500 interfaces) et de les filtrer, et qui n'est pas « connectée à internet » mais fait partie d'un backbone, in/out ça devient complètement arbitraire comme appellation... Et du coup vachement moins lisible.

            D'ailleurs je ne vois pas comment on filtre entre deux vlans à ce compte là, il faudrait que je recreuse.

            Le set require-order à no c'est une bonne nouvelle. Je ne savais pas que ça existait. C'est un paramètre noyau ou pf ? Ca existe (même à yes par défaut) dans des versions antérieure ? Faut que j'attende son apparition dans une version stable de FreeBSD pour pouvoir en profiter sur l'existant :-).

            (Ben oui les nouveaux trucs, sauf pour la gestion de la QoS, j'ai tendance à les mettre sous linux du coup).
            • [^] # Re: Soit dit en passant.

              Posté par (page perso) . Évalué à 2.

              Ben j'imagine que tu mets bien quelque chose comme passerelle par défaut pour ton routeur ; c'est par rapport à ça que tu peux déterminer le sens in et le sens out.

              Y'a eu une discussion pas plus tard que tout-à-l'heure sur misc@ concernant set require-order : http://marc.info/?l=m=124638546506021. Apparemment, cette option existe depuis 2002, soit depuis le tout début. Elle était par défaut à yes. Et c'est une option de PF, (mal documentée, je te l'accorde).

              Cordialement,
              Maxime
              • [^] # Re: Soit dit en passant.

                Posté par . Évalué à 2.

                Ah ! Ben comme ça je le saurais. Merci. Bon ça simplifie pas le filtrage pour les flux qui ne passent pas par la passerelle, mais au moins c'est clair.

                Je prends note sur set require-order. J'ai passé pas mal de temps sur cette problématique et la seule réponse que j'avais trouvé c'était que j'étais obligé de respecter l'ordre, et ça me gênait énormément (le pire étant les ancres). Il faut que je regarde ce que ça implique pour les ancres, justement, mais au pire je me passerait d'ancres quitte à générer le pf.conf à la volée pour séparer en plusieurs fichiers.

                Moralité, il vaut mieux se plaindre sur DLFP que sur un chan irc, fut-il consacré à *BSD. On a plus de réponses utiles ;-P
              • [^] # Re: Soit dit en passant.

                Posté par (page perso) . Évalué à 1.

                L'adresse correcte est http://marc.info/?m=124638546506021 ; désolé.
      • [^] # Re: Soit dit en passant.

        Posté par (page perso) . Évalué à 1.

        Non, je n'en n'ai pas trop, j'estime les avoir gagnés honnêtement, à la sueur de mon front. Désolé. =)
  • # Règles par défaut

    Posté par (page perso) . Évalué à 3.

    Attention, ton script ne marche pas en interactif. En effet, les règles par défaut bloque la connexion... En script cela marche car la connexion est coupé mais avant que ssh coupe la connexion via un timeout et donc que le noyau tue ton script, celui-ci est finit.

    Bref, je n'aime pas les scripts de firewall qui joue sur les timeout système pour leur mise en place. J'aime bien pouvoir faire un copier coller et que les choses ait exactement le même comportement. Dans mes scripts à moi, je comme TOUJOURS par les lignes suivantes :


    # Policies
    iptables -P INPUT ACCEPT
    iptables -P OUTPUT ACCEPT
    iptables -P FORWARD ACCEPT


    Puis, j'accepte en entrée sortie (deux règles écrites explicitement) tout ce qui concerne la loopback (lo). Dans ton script à toi, il n'y en a qu'une car il y a une règle implicite sur la loopback. Je n'aime pas les règles implicites...

    Enfin, je finit sur le bas du script par les règles par défaut définitive


    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP


    En effet, j'écris aussi des règles explicites sur la chaîne OUTPUT. Je trouve plus clair d'écrire à coté des règles d'entrée INPUT le correspond pour la sortie OUTPUT que de laisser tout sortir.

Suivre le flux des commentaires

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