Forum Linux.debian/ubuntu Iptables sur serveur web

Posté par  .
Étiquettes : aucune
0
20
mai
2007
Bonjour,


Afin de sécuriser mon serveur (dédié chez un hébergeur) , je vais mettre en place le script suivant:


iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# regles pour serveur web

iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT

# regles ssh (modification du port par defaut)
iptables -I INPUT -p tcp --dport 2602 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 2602 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP

# regles icmp (permet le ping de l'hebergeur vers mon serveur web)
iptables -A INPUT -i eth0 -p icmp --source IP de l'hebergeur -j ACCEPT


iptables -A INPUT -i eth0 -j REJECT

Mes questions sont les suivantes:

-Le script ci-dessous est-il correct pour securiser un serveur web ?
-Comment rajouter dans mon script , le port knocking ?

Merci pour vos réponses.
  • # ICMP

    Posté par  . Évalué à 1.

    Pourquoi tu bloques l'ICMP ...
    • [^] # Re: ICMP

      Posté par  . Évalué à 1.

      surement pour eviter les ping flood et autres truc dans le genre
      • [^] # Re: ICMP

        Posté par  (site web personnel) . Évalué à 5.

        Je suis loin d'être un expert en sécurité, mais il me semble que c'est plus ou moins inutile. On n'est plus à l'époque du ping of death, même sous windows.

        Un flood TCP est tout aussi simple, et sans doute plus efficace. L'ICMP existe justement pour effectuer des diagnostiques, je trouve stupide de s'en passer.
        • [^] # Re: ICMP

          Posté par  . Évalué à 2.

          ne fut-ce que pour les négociations de mtu, la présence de l'icmp est totalement justifiable...

          Maintenant, il faut bien se dire que si l'icmp est très intéressant pour le diagnostique réseau, c'est aussi celà qui en fait une source d'informations pour un hacker (le ping n'est pas le seul élément intéressant dans l'icmp)
          • [^] # Re: ICMP

            Posté par  (site web personnel) . Évalué à 4.

            ICMP ou pas, une personne mal intentionnée trouvera les informations qui l'intéressent. Encore une fois, on peut faire beaucoup de choses avec TCP. Ça lui prendra juste un tout petit peu plus de temps, le temps de changer d'outils (tracepath, hping, etc -- s'il fait ça à la mano comme un grand).

            Donc je maintiens ma position, bloquer l'ICMP ne vaut pas le coup.
            • [^] # Re: ICMP

              Posté par  . Évalué à 2.

              Donc je maintiens ma position, bloquer l'ICMP ne vaut pas le coup


              Je n'ai pas dit le contraire... sans icmp il peut y avoir des problèmes de transmission assez costauds car les intervenants dans la communication ne peuvent négocier les tailles de paquets... Vu que sur internet on a des clients configurés de manière variable, bloquer l'icmp revient à refuser parfois le dialogue.
              • [^] # Re: ICMP

                Posté par  . Évalué à 2.

                c'est tout à fait exact. Bloquer l'ICMP tout en ayant une stack avec la PMTUD activée, c'est une grave erreur.
  • # debian-administration.org

    Posté par  . Évalué à 3.

    Un site a retenir

    http://www.debian-administration.org/articles/268

    et vive Debian :)
  • # .

    Posté par  . Évalué à 3.

    Une petite chose interressante à savoir à propos du flag NEW d'iptables : Toute tentative de connexion non précédement enregistré dans la table est considéré comme nouvelle.
    Ainsi tu peux te retrouver avec un paquet ayant le flag ACK mais pas de flag SYN accepté comme nouvelle connexion. Et moi, j'aime pas ca, c'est pas propre car une connexion TCP se fait en 3 états et vouloir les sauter n'est jamais une bonne idées ;)

    Ensuite, pourquoi considère tu les connexion ESTABLISHED, RELATED, mais jamais NEW ?

    Donc je verrais au final un script ressemblant plus à ca :

    iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED ! --syn -j ACCEPT

    # regles pour serveur web
    iptables -A INPUT -i eth0 -p tcp --dport 21 -m state --state NEW --syn -j ACCEPT
    iptables -A INPUT -i eth0 -p tcp --dport 25 -m state --state NEW --syn -j ACCEPT
    iptables -A INPUT -i eth0 -p tcp --dport 53 -m state --state NEW --syn -j ACCEPT
    iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
    iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW --syn -j ACCEPT
    iptables -A INPUT -i eth0 -p tcp --dport 110 -m state --state NEW --syn -j ACCEPT
    iptables -A INPUT -i eth0 -p tcp --dport 443 -m state --state NEW --syn -j ACCEPT

    # regles ssh (modification du port par defaut)
    iptables -I INPUT -p tcp --dport 2602 -i eth0 -m state --state NEW --syn -m recent --set
    iptables -I INPUT -p tcp --dport 2602 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP

    # regles icmp (permet le ping de l'hebergeur vers mon serveur web)
    iptables -A INPUT -i eth0 -p icmp --source IP de l'hebergeur -j ACCEPT
    iptables -A INPUT -i eth0 -j REJECT


    Ensuite, comme dit au dessus, bloquer l'icmp, ca fait jolie, mais ca ne fait que retarder de quelques minutes les infos. Alors que pour les utilisateurs, ca peut etre utile (négociation du mtu et autres). Surtout que tu ne t'autorise meme pas le ping sur ta propre machine la ;)
    • [^] # Re: .

      Posté par  . Évalué à 1.

      iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED ! --syn -j ACCEPT

      qui casse tout de suite le RELATED ...
  • # Plusieurs réponses:

    Posté par  . Évalué à 0.

    -Le script ci-dessous est-il correct pour securiser un serveur web ?

    La non. Absolument pas pour un serveur _web_.

    D'emblée tu autorises les ports en entrée:
    21, 25, 53, 110, 2602; j'accepte le 443 est en bonus.

    Pour sécuriser un serveur web, il n'y a pas 350 regles:

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

    iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACEPT
    iptables -A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

    (pas besoin du RELATED pour le serveur WEB, c'est utile pour des connexions comme le ftp).
    Il doit y avoir moyen de blinder encore un peu plus en vérifiant vraiment quel paquet entre, mais c'est un bon début.

    Pour l'ICMP, il y a plusieurs écoles. Sur mes machines, j'autorise, d'autres sont farouchement opposés; à toi de voir.

    De manière globale, pour firewaller une machine de type _serveur_.
    1. tu mets les trois règles de policy en DROP (attention à ne pas te couper l'herbe sous les pieds si tu es connecté en distant!!)
    2. tu autorises en entrée vers le service que tu souhaites (par exemple tcp-80), puis le ESTABLISHED en sortie
    3. si ta machine doit sortir, tu n'autorises que vers des IP connues! par exemple, uniquement vers les IP des DNS connus, genre:
    iptables -A OUTPUT -p udp --dport 53 -d -j ACCEPT
    iptables -A INPUT -p udp --sport 53 -s -j ACCEPT
    4. N'autoriser que le ssh comme protocole de gestion de machine. On peut changer de port, ca evitera aux logs d'etre pourris de portscan et de brute force (quoique...) mais l'idee c'est de ne faire que du ssh pour administrer la machine (le ftp est a bannir, utilisez sftp / scp)

    Et surtout rien de plus.

    Ensuite, pour tes questions:
    Pourquoi pour un serveur web autoriser du ftp, du smtp, du pop3?

Suivre le flux des commentaires

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