Comme je l'avais écrit dans un fil précédent, je suis en train d'écrire
un script de firewall basé sur iptables pour un routeur. Mais pour
commencer, je préfère vous soumettre une version allégée pour une simple
station (sans routage ni NAT) ayant une interface sur un réseau non sûr
afin de valider mes choix, particulièrement en matière de politique
générale et de gestion des états du suivi de connexion.
C'est là :
http://www.plouf.fr.eu.org/firewall/firewall-station.html
Note : j'ai un petit souci avec les protocoles non autorisés autres que
TCP, UDP et ICMP. Pour se conformer le plus possible au standard, mon
script renvoie un message d'erreur ICMP "protocol unreachable" en
réponse aux paquets NEW qui n'ont pas déjà été acceptés ni bloqués. Mais
les paquets envoyés par le scan IP de nmap (option -sO) que j'ai utilisé
pour tester sont tous vus comme INVALID et mon script n'envoie donc
aucune erreur ICMP dans ce cas. Pourtant, le premier paquet GRE envoyé
par un client PPTP est bien vu comme NEW.
Voilà, merci de vos commentaires féroces mais constructifs :)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier
Salut,
Comme je l'avais écrit dans un fil précédent, je suis en train d'écrire un script de firewall basé sur iptables pour un routeur. Mais pour commencer, je préfère vous soumettre une version allégée pour une simple station (sans routage ni NAT) ayant une interface sur un réseau non sûr afin de valider mes choix, particulièrement en matière de politique générale et de gestion des états du suivi de connexion.
C'est là : http://www.plouf.fr.eu.org/firewall/firewall-station.html
Note : j'ai un petit souci avec les protocoles non autorisés autres que TCP, UDP et ICMP. Pour se conformer le plus possible au standard, mon script renvoie un message d'erreur ICMP "protocol unreachable" en réponse aux paquets NEW qui n'ont pas déjà été acceptés ni bloqués. Mais les paquets envoyés par le scan IP de nmap (option -sO) que j'ai utilisé pour tester sont tous vus comme INVALID et mon script n'envoie donc aucune erreur ICMP dans ce cas. Pourtant, le premier paquet GRE envoyé par un client PPTP est bien vu comme NEW.
Voilà, merci de vos commentaires féroces mais constructifs :) Bonsoir,
Après une lecture rapide: - par principe, je mettrais les règles ESTABLISHED en tête: comme elles sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets en cours de connexion qui représentent la majorité. - d'autres part, les règles "-p tcp --syn" doivent être accompagnées de "-m state --state NEW", sinon, les règles ESTABLISHED ne servent à rien... idem pour les "-p udp"
@+ Xavier
Salut,
Comme je l'avais écrit dans un fil précédent, je suis en train d'écrire
un script de firewall basé sur iptables pour un routeur. Mais pour
commencer, je préfère vous soumettre une version allégée pour une simple
station (sans routage ni NAT) ayant une interface sur un réseau non sûr
afin de valider mes choix, particulièrement en matière de politique
générale et de gestion des états du suivi de connexion.
C'est là :
http://www.plouf.fr.eu.org/firewall/firewall-station.html
Note : j'ai un petit souci avec les protocoles non autorisés autres que
TCP, UDP et ICMP. Pour se conformer le plus possible au standard, mon
script renvoie un message d'erreur ICMP "protocol unreachable" en
réponse aux paquets NEW qui n'ont pas déjà été acceptés ni bloqués. Mais
les paquets envoyés par le scan IP de nmap (option -sO) que j'ai utilisé
pour tester sont tous vus comme INVALID et mon script n'envoie donc
aucune erreur ICMP dans ce cas. Pourtant, le premier paquet GRE envoyé
par un client PPTP est bien vu comme NEW.
Voilà, merci de vos commentaires féroces mais constructifs :)
Bonsoir,
Après une lecture rapide:
- par principe, je mettrais les règles ESTABLISHED en tête: comme elles
sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets
en cours de connexion qui représentent la majorité.
- d'autres part, les règles "-p tcp --syn" doivent être accompagnées de
"-m state --state NEW", sinon, les règles ESTABLISHED ne servent à
rien... idem pour les "-p udp"
Comme je l'avais écrit dans un fil précédent, je suis en train d'écrire un script de firewall basé sur iptables pour un routeur. Mais pour commencer, je préfère vous soumettre une version allégée pour une simple station (sans routage ni NAT) ayant une interface sur un réseau non sûr afin de valider mes choix, particulièrement en matière de politique générale et de gestion des états du suivi de connexion.
C'est là : http://www.plouf.fr.eu.org/firewall/firewall-station.html
Note : j'ai un petit souci avec les protocoles non autorisés autres que TCP, UDP et ICMP. Pour se conformer le plus possible au standard, mon script renvoie un message d'erreur ICMP "protocol unreachable" en réponse aux paquets NEW qui n'ont pas déjà été acceptés ni bloqués. Mais les paquets envoyés par le scan IP de nmap (option -sO) que j'ai utilisé pour tester sont tous vus comme INVALID et mon script n'envoie donc aucune erreur ICMP dans ce cas. Pourtant, le premier paquet GRE envoyé par un client PPTP est bien vu comme NEW.
Voilà, merci de vos commentaires féroces mais constructifs :) Bonsoir,
Après une lecture rapide: - par principe, je mettrais les règles ESTABLISHED en tête: comme elles sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets en cours de connexion qui représentent la majorité. - d'autres part, les règles "-p tcp --syn" doivent être accompagnées de "-m state --state NEW", sinon, les règles ESTABLISHED ne servent à rien... idem pour les "-p udp"
Ça dépend, à quel endroit étant donné que j'utilise les deux ?
Oups, excuse-moi, j'avais mal lu. Effectivement, tel que tu l'utilises, ça me semble très bien de ce point de vue.
Pascal
Xavier wrote:
Après une lecture rapide: - par principe, je mettrais les règles ESTABLISHED en tête: comme elles sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets en cours de connexion qui représentent la majorité.
Principe de bon sens que, sauf erreur, j'ai appliqué aussi tôt que possible, c'est-à-dire juste après la correspondance de l'interface d'entrée. Mais comme j'utilise des chaînes utilisateur, le script serait peut-être plus facile à comprendre en commençant à le lire par la fin.
- d'autres part, les règles "-p tcp --syn" doivent être accompagnées de "-m state --state NEW", sinon, les règles ESTABLISHED ne servent à rien... idem pour les "-p udp"
Sauf erreur c'est le cas, ces règles sont placées dans un chaîne appelée suite à correspondance avec l'état NEW.
Xavier wrote:
Après une lecture rapide:
- par principe, je mettrais les règles ESTABLISHED en tête: comme elles
sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets
en cours de connexion qui représentent la majorité.
Principe de bon sens que, sauf erreur, j'ai appliqué aussi tôt que
possible, c'est-à-dire juste après la correspondance de l'interface
d'entrée.
Mais comme j'utilise des chaînes utilisateur, le script serait peut-être
plus facile à comprendre en commençant à le lire par la fin.
- d'autres part, les règles "-p tcp --syn" doivent être accompagnées de
"-m state --state NEW", sinon, les règles ESTABLISHED ne servent à
rien... idem pour les "-p udp"
Sauf erreur c'est le cas, ces règles sont placées dans un chaîne appelée
suite à correspondance avec l'état NEW.
Après une lecture rapide: - par principe, je mettrais les règles ESTABLISHED en tête: comme elles sont lues dans l'ordre, ça permet d'accélérer le traitement des paquets en cours de connexion qui représentent la majorité.
Principe de bon sens que, sauf erreur, j'ai appliqué aussi tôt que possible, c'est-à-dire juste après la correspondance de l'interface d'entrée. Mais comme j'utilise des chaînes utilisateur, le script serait peut-être plus facile à comprendre en commençant à le lire par la fin.
- d'autres part, les règles "-p tcp --syn" doivent être accompagnées de "-m state --state NEW", sinon, les règles ESTABLISHED ne servent à rien... idem pour les "-p udp"
Sauf erreur c'est le cas, ces règles sont placées dans un chaîne appelée suite à correspondance avec l'état NEW.
