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 . Évalué à 1.
[^] # Re: ICMP
Posté par NeoX . Évalué à 1.
[^] # Re: ICMP
Posté par Amand Tihon (site web personnel) . Évalué à 5.
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 . Évalué à 2.
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) . Évalué à 4.
Donc je maintiens ma position, bloquer l'ICMP ne vaut pas le coup.
[^] # Re: ICMP
Posté par ragoutoutou . Évalué à 2.
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 . Évalué à 2.
# debian-administration.org
Posté par other . Évalué à 3.
http://www.debian-administration.org/articles/268
et vive Debian :)
# .
Posté par Toto . Évalué à 3.
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 . Évalué à 1.
qui casse tout de suite le RELATED ...
# Plusieurs réponses:
Posté par octane . Évalué à 0.
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.