Firehol: iptables pour les êtres humains (Arch)

Tout d'abord, tous les crédits vont à @YukiteruAmano, parce que cet article est basé sur le tutoriel vous avez posté sur le forum. La différence est que je vais me concentrer sur voûte, bien que cela fonctionne probablement pour d'autres distributions basées sur systemd.

Qu'est-ce que Firehol?

firehol, est une petite application qui nous aide à gérer le pare-feu intégré au noyau et son outil iptables. Firehol, n'a pas d'interface graphique, toute configuration doit se faire via des fichiers texte, mais malgré cela, la configuration reste simple pour les utilisateurs novices, ou puissante pour ceux qui recherchent des options avancées. Tout ce que Firehol fait est de simplifier autant que possible la création de règles iptables et d'activer un bon pare-feu pour notre système.

Installation et configuration

Firehol n'est pas dans les dépôts officiels d'Arch, nous allons donc nous référer au AUR.

yaourt -S firehol
Ensuite, nous allons au fichier de configuration.

sudo nano /etc/firehol/firehol.conf

Et nous y ajoutons les règles, vous pouvez utiliser ces.

Continuez à activer Firehol pour chaque démarrage. Assez simple avec systemd.

sudo systemctl enable firehol

Nous avons lancé Firehol.

sudo systemctl start firehol

Enfin, nous vérifions que les règles iptables ont été créées et chargées correctement.

sudo iptables -L

Désactiver IPv6

Comme Firehol ne gère pas ip6tables et comme la plupart de nos connexions ne prennent pas en charge IPv6, ma recommandation est de le désactiver.

En voûte nous ajoutons ipv6.disable = 1 à la ligne du noyau dans le fichier / etc / default / grub


...
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="rw ipv6.disable=1"
GRUB_CMDLINE_LINUX=""
...

Maintenant, nous régénérons le grub.cfg:

sudo grub-mkconfig -o /boot/grub/grub.cfg

En Debian assez avec:

sudo echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   Felipe dit

    Je ne comprends pas. Suivez-vous le tutoriel et vous avez déjà le pare-feu en cours d'exécution et bloqué toutes les connexions? Autre chose Un tutoriel pour Arch est complexe par exemple je n'ai jamais utilisé sudo ou yaourt Firewall. Cependant, il est compris. Ou peut-être que quelqu'un de nouveau écrit yaourt et obtiendra une erreur. Pour Manjaro, c'est plus correct.

    1.    Yukiteru dit

      Comme vous dites @felipe, en suivant le tutoriel et en mettant dans le fichier /etc/firehol/firehol.conf les règles données par @cookie dans la pâte, vous aurez déjà un simple pare-feu pour protéger le système à un niveau basique. Cette configuration fonctionne pour chaque distribution où vous pouvez mettre Firehol, avec la particularité de chaque distribution, elle gère ses services de différentes manières (Debian via sysvinit, Arch avec systemd) et quant à l'installation, tout le monde sait ce qu'il a, dans Arch vous devez utilisez les dépôts AUR et yaourt, dans Debian les dépôts officiels vous suffisent, et donc dans beaucoup d'autres, il vous suffit de chercher un peu dans les dépôts et d'adapter la commande d'installation.

  2.   ci dit

    Merci, je prends note.

  3.   Config dit

    Tout cela est très bien ... mais le plus important manque; Vous devez expliquer comment les règles sont créées !!, ce qu'elles signifient, comment en créer de nouvelles ... Si cela n'est pas expliqué, ce que vous mettez est de peu d'utilité: - /

    1.    Yukiteru dit

      Créer de nouvelles règles est simple, la documentation Firehol est claire et très précise en termes de création de règles personnalisées, donc en lire un peu vous permettra de la personnaliser et de l'adapter facilement à vos besoins.

      Je pense que la raison initiale du post @cookie comme le mien sur le forum était de donner aux utilisateurs et aux lecteurs un outil qui leur permet de donner un peu plus de sécurité à leurs ordinateurs, le tout à un niveau basique. Le reste est laissé à la dérive pour que vous vous adaptiez à vos besoins.

    2.    gâteau dit

      Si vous lisez le lien vers le tutoriel Yukiteru, vous vous rendrez compte que l'intention est de faire connaître l'application et la configuration d'un pare-feu de base. J'ai précisé que mon message n'était qu'une copie centrée sur Arch.

  4.   maacub dit

    Et c'est «pour les humains»? o_O
    Essayez Gufw sur Arch: https://aur.archlinux.org/packages/gufw/ >> Cliquez sur Statut. Ou ufw si vous préférez le terminal: sudo ufw enable

    Vous êtes déjà protégé si vous êtes un utilisateur normal. C'est `` pour les humains '' 🙂

    1.    animé dit

      Firehol est vraiment un Front-End pour IPTables et si on le compare à ce dernier, c'est assez humain 😀

    2.    Yukiteru dit

      Je considère ufw (Gufw n'est qu'une interface de celui-ci) comme une mauvaise option en termes de sécurité. Raison: pour plus de règles de sécurité que j'ai écrites dans ufw, je n'ai pas pu éviter que dans les tests de mon pare-feu à la fois via le Web et ceux que j'ai effectués à l'aide de nmap, des services tels que avahi-daemon et exim4 apparaissaient ouverts, et seulement un L'attaque "furtive" était suffisante pour connaître les plus petites caractéristiques de mon système, du noyau et des services qu'il exécutait, ce qui ne m'est pas arrivé en utilisant le firehol ou le pare-feu d'arno.

      1.    giskard dit

        Bon, je ne sais pas pour vous, mais comme je l'ai écrit plus haut, j'utilise Xubuntu et mon pare-feu est compatible avec GUFW et j'ai réussi TOUS les tests du lien que l'auteur a mis sans problème. Tout furtif. Rien d'ouvert. Donc, d'après mon expérience ufw (et donc gufw), ils sont parfaits pour moi. Je ne critique pas l'utilisation d'autres modes de contrôle de pare-feu, mais gufw fonctionne parfaitement et donne d'excellents résultats en matière de sécurité.

        Si vous pensez que certains tests peuvent générer des vulnérabilités dans mon système, dites-moi ce qu'ils sont et je les exécuterai volontiers ici et vous informerai des résultats.

        1.    Yukiteru dit

          Ci-dessous, je commente quelque chose au sujet de ufw, où je dis que l'erreur que j'ai vue en 2008, en utilisant Ubuntu 8.04 Hardy Heron. Qu'ont-ils déjà corrigé? La chose la plus probable est que c'est le cas, donc il n'y a aucune raison de s'inquiéter, mais même ainsi, cela ne signifie pas que le bogue était là et que je pourrais le montrer, même si ce n'était pas une mauvaise chose de mourir, j'ai seulement arrêté les démons avahi-daemon et exim4, et problème déjà résolu. Le plus étrange de tous est que seuls ces deux processus avaient le problème.

          J'ai évoqué le fait comme une anecdote personnelle, et j'ai pensé de la même manière quand j'ai dit: «Je considère ...»

          Salutations 🙂

    3.    giskard dit

      +1

  5.   costales dit

    @Yukiteru: Avez-vous essayé depuis votre propre ordinateur? Si vous cherchez depuis votre PC, il est normal que vous puissiez accéder au port de service X, car le trafic qui est bloqué est celui du réseau et non localhost:
    http://www.ubuntu-es.org/node/140650#.UgJZ3cUyYZg
    https://answers.launchpad.net/gui-ufw/+question/194272

    Sinon, merci de signaler un bug 🙂
    salutations

    1.    Yukiteru dit

      Depuis un autre ordinateur utilisant un réseau LAN dans le cas de nmap, et via le Web en utilisant cette page https://www.grc.com/x/ne.dll?bh0bkyd2En utilisant l'option de ports personnalisés, ils ont tous deux convenu qu'avahi et exim4 écoutaient depuis le net même si ufw avait configuré son blocage.

      J'ai résolu ce petit détail d'avahi-daemon et d'exim4 en désactivant simplement les services et c'est tout ... Je n'ai pas signalé de bogue à l'époque, et je ne pense pas qu'il soit logique de le faire maintenant, car c'était en 2008, en utilisant Hardy.

      1.    giskard dit

        2008 était il y a 5 ans; de Hardy Heron à Raring Ringtail, il y a 10 * buntus. Ce même test sur mon Xubuntu, fait hier et répété aujourd'hui (août 2013) donne parfait en tout. Et je n'utilise que UFW.

        Je le répète: avez-vous des tests supplémentaires à effectuer? Avec plaisir je le fais et je rapporte ce qui sort de ce côté.

        1.    Yukiteru dit

          Faites une analyse SYN et IDLE de votre PC à l'aide de nmap, cela vous donnera une idée de la sécurité de votre système.

          1.    giskard dit

            L'homme nmap a plus de 3000 lignes. Si vous me donnez les commandes à exécuter avec plaisir, je le ferai et je rapporterai le résultat.

          2.    Yukiteru dit

            Hmm, je ne connaissais pas les 3000 pages de manuel de nmap. mais zenmap est une aide pour faire ce que je vous dis, c'est une interface graphique pour nmap, mais toujours l'option pour SYN scan avec nmap est -sS, tandis que l'option pour idle scan est -sI, mais la commande exacte Je serai.

            Faites le scan depuis une autre machine pointant vers l'ip de votre machine avec ubuntu, ne le faites pas depuis votre propre PC, car ce n'est pas ainsi que cela fonctionne.

          3.    Yukiteru dit

            LOL !! Mon erreur sur 3000 pages, quand c'étaient des lignes 😛

  6.   Jeus Israël Perales Martinez dit

    Je ne sais pas mais je pense qu'une interface graphique pour cela dans GNU / Linux pour gérer le pare-feu serait quelque chose de prudent et de ne pas tout laisser à découvert comme dans ubuntu ou tout ce qui est couvert comme dans fedora, vous devriez être un bon xD, ou quelque chose pour configurer les putain d'alternatives de tueur xD hjahjahjaja Il a peu à me battre avec eux et le jdk ouvert mais de toute façon il faut aussi garder le principe du baiser

  7.   Ile Maurice dit

    Grâce à tous les trébuchements qui se sont produits dans le passé avec iptables, je peux aujourd'hui comprendre niverl raw, c'est-à-dire lui parler directement car il vient de l'usine.

    Et ce n'est pas quelque chose de si compliqué, c'est très facile à apprendre.

    Si l'auteur du message me le permet, je publierai un extrait du script de pare-feu que j'utilise actuellement.

    ## Règles de nettoyage
    iptables -F
    iptables -X
    iptables -Z
    iptables -t nat -F

    ## Définir la politique par défaut: DROP
    iptables -P BAISSE D'ENTRÉE
    iptables -P DROP DE SORTIE
    iptables -P DROP FORWARD

    # Fonctionner sur localhost sans limitations
    iptables -A INPUT -i lo -j ACCEPTER
    iptables -A OUTPUT -o lo -j ACCEPTER

    # Autoriser la machine à accéder au Web
    iptables -A INPUT -p tcp -m tcp –sport 80 -m conntrack –ctstate RELATED, ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp –dport 80 -j ACCEPTER

    # Déjà aussi pour sécuriser les sites Web
    iptables -A INPUT -p tcp -m tcp –sport 443 -m conntrack –ctstate RELATED, ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp –dport 443 -j ACCEPTER

    # Autoriser le ping de l'intérieur vers l'extérieur
    iptables -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPTER
    iptables -A INPUT -p icmp –icmp-type écho-réponse -j ACCEPTER

    # Protection pour SSH

    #iptables -I INPUT -p tcp –dport 22 -m conntrack –ctstate NEW -m limit –limit 30 / minute –limit-burst 5 -m commentaire –comment "SSH-kick" -j ACCEPT
    #iptables -A INPUT -p tcp -m tcp –dport 22 -j LOG –log-prefix "SSH ACCESS TENTATIVE:" –log-level 4
    #iptables -A INPUT -p tcp -m tcp –dport 22 -j DROP

    # Règles pour amule pour autoriser les connexions sortantes et entrantes sur le port
    iptables -A INPUT -p tcp -m tcp –dport 16420 -m conntrack –ctstate NOUVEAU -m commentaire –comment "aMule" -j ACCEPTER
    iptables -A OUTPUT -p tcp -m tcp –sport 16420 -m conntrack –ctstate RELATED, ESTABLISHED -m comment –comment "aMule" -j ACCEPT
    iptables -A INPUT -p udp –dport 9995 -m commentaire –comment "aMule" -j ACCEPTER
    iptables -A OUTPUT -p udp –sport 9995 -j ACCEPTER
    iptables -A INPUT -p udp –dport 16423 -j ACCEPT
    iptables -A OUTPUT -p udp –sport 16423 -j ACCEPTER

    Maintenant une petite explication. Comme vous pouvez le voir, il y a les règles avec la politique DROP par défaut, rien ne sort et n'entre dans l'équipe sans que vous leur disiez.

    Ensuite, les bases sont passées, l'hôte local et la navigation vers le réseau de réseaux.

    Vous pouvez voir qu'il existe également des règles pour ssh et amule. S'ils ont l'air bien comme ils sont faits, ils peuvent établir les autres règles qu'ils veulent.

    L'astuce consiste à voir la structure des règles et à s'appliquer à un type spécifique de port ou de protocole, que ce soit udp ou tcp.

    J'espère que vous pouvez comprendre ce que je viens de publier ici.

    1.    gâteau dit

      Vous devriez faire un post pour l'expliquer, ce serait génial.

  8.   @Jlcmux dit

    J'ai une question. Si vous souhaitez rejeter les connexions http et https, je mets:

    serveur "http https" drop?

    Et ainsi de suite avec n'importe quel service?

    merci