Re: critique sur script iptables
Salut,
J'ai ajouté "iptables" dans le sujet afin qu'il soit plus explicite.
Christophe Delcenserie a écrit :
J'aimerais que de l'exterieur on puisse acceder a mon serveur web,
et que les machines dans mon lan puissent aller sur le net.
Je souhaite la sortie que de quelques ports et que de l'exterieur,
on n'accepte pas a mon lan.
Il faudrait que tu précises quelques points :
- à quelle machine est destiné ce script ? la passerelle internet ?
- où est le serveur web ? sur une machine du LAN ?
[...]
# Je veux que les connexions destinées à être forwardées soient acceptées par défaut
iptables -P FORWARD ACCEPT
Ça commence mal si tu veux restreindre le trafic entre internet et ton LAN !
###############################################################################
# INPUT
###############################################################################
# ppp0
###############################################################################
# Detruit les connexions sur ppp0 <- Internet qui aurait pour adr_ip celles d'une classe privée !
# Une variante de 'no-spoofing' !
iptables -A INPUT -i ppp+ -s 127.0.0.0/8 -j log_input_wan_drop # adr de Loopback
[etc.]
Tu fais comme tu veux, mais à quoi cela va-t-il te servir de logger des
paquets dont l'adresse source est spoofée ?
[...]
# J'autorise les connexions TCP entrantes sur le port 22 uniquement sur l'interface "eth0"
# (pour que mon serveur Ssh soit joignable depuis mon LAN seulement)
iptables -A INPUT -p tcp -i eth0 --dport ssh -j log_input_lan_accept
Encore une fois tu fais comme tu veux, mais est-il vraiment souhataible
de logger *tous* les paquets des connexions SSH provenant du LAN ?
Le premier, je ne dis pas - et encore, il y a déjà les logs de sshd -
mais les suivants ?
# J'accepte les packets entrants relatifs à des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -i eth0 -j log_input_lan_accept
iptables -A INPUT -m state --state RELATED,ESTABLISHED -i ppp+ -j log_input_wan_accept
Ces règles devraient être placées en tête de la chaîne pour un maximum
d'efficacité.
Je pose à nouveau la question de l'opportunité de logger *tous* les
paquets entrants acceptés.
# pour le reste on supprime
iptables -A INPUT -i eth0 -j log_input_lan_drop
iptables -A INPUT -i ppp+ -j log_input_wan_drop
Brutal, expéditif, et contraire aux normes. En un mot, mauvais.
Je me permets de citer l'excellente réponse faite aujourd'hui par un
contributeur dans le forum Usenet news:fr.comp.os.linux.configuration :
"Dans un soucis de transparence (la sécurité par l'obscurantisme
n'existe pas), de respect des normes (RFC), de courtoisie (répondre
poliment à une connexion erronée) et de confort (répondre au lieu de
faire attendre inutilement ; timeout), un firewall avec une bonne
politique devrait répondre à ces deux principes :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont
l'état est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
- Devraient être rejetés (REJECT), avec le bon message (TCP RST pour
TCP, ICMP port unreachable pour UDP, ICMP protocol unreachable pour un
protocole autre, ...), les paquets dont l'état est valide (! INVALID)
mais qu'on ne veut pas accepter.
Enfin, comme je le sous-entendais précédemment, pour limiter les
attaques qui pourraient conduire à un trafic montant important, on peut
utiliser le match limit d'iptables afin de limiter le nombre de REJECT
émis."
[...]
###############################################################################
# J'accepte les packets sortants pour internet :
iptables -A OUTPUT -o ppp+ -p tcp --dport 20 -m state --state ! INVALID -j log_output_wan_accept # ftp data
Si c'est pour du FTP actif, cette règle est inutile si le module de
suivi FTP ip_conntrack_ftp est chargé.
iptables -A OUTPUT -o ppp+ -p tcp --dport 21 -m state --state ! INVALID -j log_output_wan_accept # ftp
iptables -A OUTPUT -o ppp+ -p tcp --dport 25 -m state --state ! INVALID -j log_output_wan_accept # smtp
[etc.]
Quelle lourdeur ! Pourquoi ne pas commencer par une règle qui bloque les
paquets invalides ? Après, on n'en parle plus. On peut aussi utiliser
une chaîne utilisateur pour regrouper des règles ayant des paramètres
communs.
Je réitère mon interrogation sur l'intérêt de tout logger.
# J'accepte les packets sortants relatifs à des connexions déjà établies
# iptables -A OUTPUT -o ppp+ -m state --state RELATED,ESTABLISHED -j log_output_wan_accept
Comme précédemment, cette règle devrait se trouver en début de chaîne.
[...]
# J'autorise les connexions TCP sortantes sur le port 22 uniquement sur l'interface "eth0"
# (pour que mon serveur Ssh soit joignable depuis mon LAN seulement)
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state ! INVALID -j log_output_lan_accept # ssh
Si tu veux que le serveur SSH puisse répondre, il faut accepter le port
*source* 22 (--sport), pas le port destination.
Accessoirement, cette règle acceptera n'importe quel paquet valide
pourvu qu'il ait le port source 22. Pas terrible. Je sais bien que c'est
un port privilégié et que sshd écoute déjà dessus, mais pas terrible
quand même dans le principe. Le suivi de connexion sert justement à
éviter ce genre de choses.
# pour le reste on supprime
iptables -A OUTPUT -o eth0 -j log_output_lan_drop
Et dans "le reste", il y a des messages ICMP utiles dont le blocage peut
causer des désagréments. Une règle acceptant les paquets appartenant ou
relatifs aux connexions établies, comme pour ppp+ et dans INPUT, serait
préférable. De plus elle rendrait inutile la règle acceptant les paquets
émis par le serveur SSH.
[...]
# Je veux que les requêtes TCP reçues sur le port 80 soient forwardées
# à la machine dont l'IP est 192.168.0.3 sur son port 80
# (la réponse à la requête sera forwardée au client)
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.0.3:80
Rappel : il n'y a aucune règle de filtrage ni de log dans la chaîne
FORWARD et la politique par défaut est ACCEPT : cela signifie que *tout*
le trafic dans les deux sens entre internet et le LAN (y compris les
adresses sources spoofées, les paquets invalides...) est accepté sans
trace. J'espère au moins que chaque machine du LAN dispose de son propre
jeu de règles de filtrage.
Reply to: