Après quelques bidouilles acrobatiques, voilà que j'ai vidé toutes mes
règles d'iptables...
Comme c'était avant bourré de règles que je ne me souvenais pas avoir
installées, qui vérifiaient l'intégrité des paquets par exemple. Je sais
grosso modo ouvrir ou fermer tel ou tel port, mais là ça dépassait
largement mes compétences.
Je pensais pouvoir les récupérer en réinstallant iptables.
Or non.
Donc ma question : y a-t-il un "jeu de règles" minimum ou par défaut
quelque part ?
Merci d'avance,
F.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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
Pascal
Salut,
Eric Reinbold a écrit :
Fabrice Chaillou a écrit :
Après quelques bidouilles acrobatiques, voilà que j'ai vidé toutes mes règles d'iptables...
Comme c'était avant bourré de règles que je ne me souvenais pas avoir installées, qui vérifiaient l'intégrité des paquets par exemple. Je sais grosso modo ouvrir ou fermer tel ou tel port, mais là ça dépassait largement mes compétences.
Je pensais pouvoir les récupérer en réinstallant iptables. Or non.
Normal, Le paquetage iptables ne crée aucune règle par lui-même. Soit tu as mauvaise mémoire, ;-) soit tu as installé/utilisé un gestionnaire de firewall de niveau supérieur comme Shorewall par exemple qui avait créé ces règle.
Donc ma question : y a-t-il un "jeu de règles" minimum ou par défaut quelque part ?
Si ca peut t'aider...
[...]
############################################################################### # Règles de connexion au reseau local ###############################################################################
# Connexions firewall <-> réseau iptables -t filter -A OUTPUT -o eth0 -s 192.168.1.1 -d 192.168.1.0/24 -p all -j ACCEPT iptables -t filter -A INPUT -i eth0 -s 192.168.1.0/24 -d 192.168.1.1 -p all -j ACCEPT
iptables -t filter -A INPUT -i eth0 -s 192.168.1.255 -d 192.168.1.1 -p all -j ACCEPT
Redondant avec la règle INPUT précédente. De toute façon, la pile IP devrait ignorer ces paquets car une adresse de broadcast n'est pas une adresse source valide.
############################################################################### # Règles de connexion à Internet ###############################################################################
iptables -t filter -A OUTPUT -o ppp0 -d 0.0.0.0/0 -p all -m state --state ! INVALID -j ACCEPT iptables -t filter -A INPUT -i ppp0 -s 0.0.0.0/0 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Remarque générale : les -p all et les -s ou -d 0.0.0.0/0 alourdissent l'écriture sans apporter d'information, on peut s'en passer.
############################################################################### # Règles pour le port forwarding ###############################################################################
Même si la règle DNAT ci-dessous redirige tout le trafic HTTP entrant vers le serveur local, il vaut mieux n'autoriser les paquets que vers la seule adresse de celui-ci.
Je ne comprends pas bien, 192.168.1.1 est l'adresse du serveur web ou l'adresse interne de la passerelle (d'après les règles INPUT et OUTPUT) ? D'autre part, c'est une bonne idée de remplacer les adresses en dur par des variables définies en début de script, ça améliore la lisibilité et la maintenabilité.
PS: ces règles bloquent les ping et traceroute, c'est une mauvaise idée quand on héberge des services en plus d'être inutile (un serveur web n'a pas de raison de se cacher).
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
Eric Reinbold a écrit :
Fabrice Chaillou a écrit :
Après quelques bidouilles acrobatiques, voilà que j'ai vidé toutes mes
règles d'iptables...
Comme c'était avant bourré de règles que je ne me souvenais pas avoir
installées, qui vérifiaient l'intégrité des paquets par exemple. Je sais
grosso modo ouvrir ou fermer tel ou tel port, mais là ça dépassait
largement mes compétences.
Je pensais pouvoir les récupérer en réinstallant iptables.
Or non.
Normal, Le paquetage iptables ne crée aucune règle par lui-même. Soit tu
as mauvaise mémoire, ;-) soit tu as installé/utilisé un gestionnaire de
firewall de niveau supérieur comme Shorewall par exemple qui avait créé
ces règle.
Donc ma question : y a-t-il un "jeu de règles" minimum ou par défaut
quelque part ?
Si ca peut t'aider...
[...]
###############################################################################
# Règles de connexion au reseau local
###############################################################################
# Connexions firewall <-> réseau
iptables -t filter -A OUTPUT -o eth0 -s 192.168.1.1 -d 192.168.1.0/24 -p all -j ACCEPT
iptables -t filter -A INPUT -i eth0 -s 192.168.1.0/24 -d 192.168.1.1 -p all -j ACCEPT
iptables -t filter -A INPUT -i eth0 -s 192.168.1.255 -d 192.168.1.1 -p all -j ACCEPT
Redondant avec la règle INPUT précédente. De toute façon, la pile IP
devrait ignorer ces paquets car une adresse de broadcast n'est pas une
adresse source valide.
###############################################################################
# Règles de connexion à Internet
###############################################################################
iptables -t filter -A OUTPUT -o ppp0 -d 0.0.0.0/0 -p all -m state --state ! INVALID -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -s 0.0.0.0/0 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Remarque générale : les -p all et les -s ou -d 0.0.0.0/0 alourdissent
l'écriture sans apporter d'information, on peut s'en passer.
###############################################################################
# Règles pour le port forwarding
###############################################################################
Même si la règle DNAT ci-dessous redirige tout le trafic HTTP entrant
vers le serveur local, il vaut mieux n'autoriser les paquets que vers la
seule adresse de celui-ci.
Je ne comprends pas bien, 192.168.1.1 est l'adresse du serveur web ou
l'adresse interne de la passerelle (d'après les règles INPUT et OUTPUT) ?
D'autre part, c'est une bonne idée de remplacer les adresses en dur par
des variables définies en début de script, ça améliore la lisibilité et
la maintenabilité.
PS: ces règles bloquent les ping et traceroute, c'est une mauvaise idée
quand on héberge des services en plus d'être inutile (un serveur web n'a
pas de raison de se cacher).
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Après quelques bidouilles acrobatiques, voilà que j'ai vidé toutes mes règles d'iptables...
Comme c'était avant bourré de règles que je ne me souvenais pas avoir installées, qui vérifiaient l'intégrité des paquets par exemple. Je sais grosso modo ouvrir ou fermer tel ou tel port, mais là ça dépassait largement mes compétences.
Je pensais pouvoir les récupérer en réinstallant iptables. Or non.
Normal, Le paquetage iptables ne crée aucune règle par lui-même. Soit tu as mauvaise mémoire, ;-) soit tu as installé/utilisé un gestionnaire de firewall de niveau supérieur comme Shorewall par exemple qui avait créé ces règle.
Donc ma question : y a-t-il un "jeu de règles" minimum ou par défaut quelque part ?
Si ca peut t'aider...
[...]
############################################################################### # Règles de connexion au reseau local ###############################################################################
# Connexions firewall <-> réseau iptables -t filter -A OUTPUT -o eth0 -s 192.168.1.1 -d 192.168.1.0/24 -p all -j ACCEPT iptables -t filter -A INPUT -i eth0 -s 192.168.1.0/24 -d 192.168.1.1 -p all -j ACCEPT
iptables -t filter -A INPUT -i eth0 -s 192.168.1.255 -d 192.168.1.1 -p all -j ACCEPT
Redondant avec la règle INPUT précédente. De toute façon, la pile IP devrait ignorer ces paquets car une adresse de broadcast n'est pas une adresse source valide.
############################################################################### # Règles de connexion à Internet ###############################################################################
iptables -t filter -A OUTPUT -o ppp0 -d 0.0.0.0/0 -p all -m state --state ! INVALID -j ACCEPT iptables -t filter -A INPUT -i ppp0 -s 0.0.0.0/0 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Remarque générale : les -p all et les -s ou -d 0.0.0.0/0 alourdissent l'écriture sans apporter d'information, on peut s'en passer.
############################################################################### # Règles pour le port forwarding ###############################################################################
Même si la règle DNAT ci-dessous redirige tout le trafic HTTP entrant vers le serveur local, il vaut mieux n'autoriser les paquets que vers la seule adresse de celui-ci.
Je ne comprends pas bien, 192.168.1.1 est l'adresse du serveur web ou l'adresse interne de la passerelle (d'après les règles INPUT et OUTPUT) ? D'autre part, c'est une bonne idée de remplacer les adresses en dur par des variables définies en début de script, ça améliore la lisibilité et la maintenabilité.
PS: ces règles bloquent les ping et traceroute, c'est une mauvaise idée quand on héberge des services en plus d'être inutile (un serveur web n'a pas de raison de se cacher).