[Wiki]Protection du serveur avec iptables

Nous avons assez peu parlé de sécurité jusqu’ici sur Homeserver-DIY. Mais, comme pour toute machine exposée sur un réseau, un serveur doit avoir un pare-feu bien configuré. C’est donc un tuto sur la configuration de netfilter que Seboss666 nous propose sur le wiki :

Iptables est un utilitaire en ligne de commande permettant de manipuler le pare-feu integré au noyau Linux, Netfilter. Et quoi qu’on en dise, même sous Linux, en particulier si vous hébergez et donc proposez des services sur Internet, il est nécessaire de serrer un peu la vis. Et iptables fait ça très bien.

 

C’est par là : Protection du serveur avec iptables

You can leave a response, or trackback from your own site.

9 Responses to “[Wiki]Protection du serveur avec iptables”

  1. ced dit :

    Très bon article pour appréhender le fonctionnement d’IPTABLES. Cependant, je voudrais faire un retour d’expérience au sujet des IP bloquées par IPTABLES.
    Si on bloque les IP comme indiqué : « iptables -A INPUT -s adresse_ip -j DROP » cela marche très bien quand on a un petit nombre d’adresses à bloquer. S’il y a un certain nombre (environ une 50aine) cela ralenti grandement le rechargement d’IPTABLES. La solution que j’ai trouvé et donc de renseigner les IP dans un fichier séparé et demander à IPTABLES de lire ce fichier (lors de l’éxécution du script de démarrage). Pour ce faire, j’ai fait comme ceci :

    1- On créer une chaîne pour logguer et dropper
    /sbin/iptables -t filter -N BLACKLST_LOGDROP
    /sbin/iptables -t filter -F BLACKLST_LOGDROP
    /sbin/iptables -t filter -A BLACKLST_LOGDROP -m limit –limit 1/min -j LOG –log-prefix « BLACKLST »
    /sbin/iptables -t filter -A BLACKLST_LOGDROP -j DROP

    2- Pour lire le fichier et marquer les IP comme étant à bloquer :
    for i in `cat chemin_vers_fichier_contenant_les_ip_refusées`
    do
    /sbin/iptables -t mangle -I PREROUTING 1 -s $i -j MARK –set-mark 1
    done

    3- On inscrit les ip (qui sont marquées : –set-mark 1) dans la chaîne de blacklist qui va les dropper :
    /sbin/iptables -t filter -I INPUT 1 -m mark –mark 1 -j BLACKLST_LOGDROP

    Le temps de chargement a été grandement réduit. Voilà j’espère que cette petite remarque pourra être utile à quelqu’un.

    ced

    • Tom23 dit :

      Merci pour l’info ced.
      Je pense effectivement que ça sera utile aux lecteurs. Je vais voir avec Seboss666, mais si ça ne te gêne pas, on pourrait intégrer ton astuce à son l’article.

      • ced dit :

        OK pas de soucis si cette astuce peut servir à quelqu’un j’en serais ravi.

        • Seboss666 dit :

          C’est en effet très intéressant, même si on aimerait le plus souvent ne pas avoir à bloquer un trop gros nombre d’ip. J’en ai malheureusement eu la douloureuse expérience avec une vague d’attaque par rebond sur un serveur cod4. J’ai bloqué des plages entières.

          C’est une méthode intéressante, et effectivement, même si on passe à un niveau un peu au dessus par rapport à ce que je voulais volontairement faire, à savoir une « simple » introduction, si ça ne te dérange pas, je vais m’atteler à ajouter un petit paragraphe.

          Encore merci pour ce petit retour 😉

  2. kaliko dit :

    Il peut être intéressant de déporter la conf hors du script de démarrage grâce aux commandes iptables-{save,apply}.

    Cela présente l’avantage de dissocier la configuration de l’exécutable (pour facilement jongler entre différents jeux de règles), mais surtout une erreur sur une règle ne laisse pas le pare-feu dans un état incohérent.

    De plus l’entête LSB du script de démarrage déclare « $network » dans les « Required-Start », cela implique un montage du réseau avant l’application des règles de pare-feu.

    Une alternative à la modification de l’entête LSB et de passer par une instruction « pre-up » dans la configuration de l’interface réseau :

    http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s5.14.3.3

    • Seboss666 dit :

      Cet article est une introduction, et je dois l’admettre, résume à peu près l’ensemble de mes connaissances actuelles sur iptables. J’ai encore un peu de mal à comprendre comment les commandes iptables-save/restore fonctionnent, plus par paresse j’avoue. Cela pourrait éventuellement faire l’objet d’un deuxième article d’approfondissement. Merci pour les indications 🙂

      Concernant le chargement en lui-même, là encore, si je connais un peu la méthode pre-up, je ne l’ai jamais appliqué moi-même, et je la considère moins « première approche » que je voulais donner à l’article au départ. La différence est-elle si grande entre un préchargement avant activation de l’interface, ou juste après, pendant le processus de démarrage avant la mise en ligne des services ? Quel est le risque ? (non pas qu’une méthode soit moins bonne qu’une autre, hein)

      • kaliko dit :

        Le chargement via « pre-up » dans la conf de l’interface réseau permet de s’assurer de ne jamais monter l’interface sans avoir le pare-feu pleinement configuré, cela peut contenter les plus paranoïaque d’entres nous. Cela permet aussi de gérer des jeux de règles en fonctions de différents profils/interfaces réseaux.

        Mais en effet, dans le cadre d’une configuration de machine domestique l’approche via un script de démarrage est tout à fait acceptable, je tenais juste à présenter des alternatives.

  3. Tremendous issues here. I’m very happy to look your post.

    Thanks so much and I’m looking forward to touch you.
    Will you kindly drop me a e-mail?

  4. I was curious if you ever thought of changing
    the layout of your blog? Its very well written; I love what youve got to say.

    But maybe you could a little more in the way of content so people could
    connect with it better. Youve got an awful lot of text for only having 1 or
    two images. Maybe you could space it out better?

Leave a Reply