Forum Linux.debian/ubuntu Iptables sur serveur web

Posté par ayyoub le 20 mai 2007 à 17:15.

Étiquettes : aucune

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 TazForEver le 20 mai 2007 à 23:34. Évalué à 1.

Pourquoi tu bloques l'ICMP ...
- [^] # Re: ICMP
  
  Posté par NeoX le 20 mai 2007 à 23:56. Évalué à 1.
  
  surement pour eviter les ping flood et autres truc dans le genre
  - [^] # Re: ICMP
    
    Posté par Amand Tihon (site web personnel) le 21 mai 2007 à 08:20. É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 ragoutoutou le 21 mai 2007 à 09:15. É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 Amand Tihon (site web personnel) le 21 mai 2007 à 10:04. É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 ragoutoutou le 21 mai 2007 à 13:19. É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 TazForEver le 21 mai 2007 à 20:40. É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 other le 21 mai 2007 à 00:54. Évalué à 3.

Un site a retenir

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

et vive Debian :)
# .

Posté par Toto le 21 mai 2007 à 11:59. É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 TazForEver le 21 mai 2007 à 20:45. É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 octane le 21 mai 2007 à 12:32. É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.