Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Iptable et DNS Local :(

Iptable et DNS Local :(

15 réponses
Avatar
Troumad
Bonsoir

J'ai un problème avec mon DNS Local, il ne marche sur mon réseau local
que si je mets shorewall à la place d'IpTable et ce depuis hier soir !!!!!
Voici les règles mises pour mon DNS dans iptable. est-ce bon ?


iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT

nb : avec shorewall, je laisse tout passer localement.
--
Amicalement vOOotre Troumad Alias Bernard SIAUD
mon site : http://troumad.free.fr : AD&D maths WEB sectes
Pour la liberté http://lea-linux.org http://www.eurolinux.org/index.fr.html
N'envoyez que des documents avec des formats ouverts, comme
http://fr.openoffice.org


--
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
Signaler un problème avec ce contenu

5 réponses

Supprimer
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
1 2
Avatar
Pascal
David Dumortier a écrit :
Le Thu Apr 28 2005 à 11:29:34PM +0200, dit :

AMA il vaut mieux gérer explicitement les différents types de requêtes
ICMP et laisser la règle suivante s'occuper des ICMP qui sont des
réponses ou des messages d'erreur relatifs à des connexions existantes.



# ICMP
# Autorise tout en local
iptables -A INPUT -i $LAN -p icmp -j ACCEPT
iptables -A OUTPUT -o $LAN -p icmp -j ACCEPT
iptables -A FORWARD -i $LAN -o $EXT -p icmp -j ACCEPT



Je fais pareil, j'ai confiance en mon réseau. ;-)

#iptables -A FORWARD -i $EXT -o $LAN -p icmp --icmp-type source-quench -j ACCEPT
iptables -A FORWARD -i $EXT -o $LAN -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT



Je suppose qu'il s'agit plutôt du type echo-reply, la réponse au ping. Si
la machine fait du NAT, il est peu courant que les requêtes de ping
soient redirigées vers le réseau local.

iptables -A INPUT -i $EXT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i $EXT -p icmp --icmp-type host-unreachable -m limit --limit 1/s -j ACCEPT



Il manque l'indispensable time-exceeded que l'on attend notamment en
réponse à un traceroute. Et chaque type est à prendre en compte à la fois
dans INPUT et dans FORWARD.

Aussi, AMA une gestion saine des ICMP doit prendre en compte les états du
suivi de connexion :
- echo-request -> NEW
- echo-reply -> ESTABLISHED
- erreurs (destination-unreachable, source-quench, parameter-problem,
time-exceeded) -> RELATED
- le reste : inutile ou potentiellement néfaste (ex: redirect) -> DROP

# Rejète les ICMP "dangereux" vers l'extèrieur [1], [2]
# [3] pour les limites
iptables -A OUTPUT -o $EXT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT



Euh, il ne vaudrait pas mieux limiter les echo-request dans INPUT plutôt
que les echo-reply dans OUTPUT ?

iptables -A OUTPUT -o $EXT -p icmp --icmp-type source-quench -m limit --limit 1/s -j ACCEPT
iptables -A OUTPUT -o $EXT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A OUTPUT -o $EXT -p icmp --icmp-type host-unreachable -m limit --limit 1/s -j ACCEPT
iptables -A OUTPUT -o $EXT -p icmp -j DROP



Pas très utile après la règle du début qui accepte tous les ICMP dans OUTPUT.

Si quelqu'un peut m'expliquer le source-quench je suis un peu feneant sur
les RFC ...



Une machine peut l'envoyer quand elle détruit un paquet ou risque de le
faire à cause par exemple d'un buffer de réception plein. Le but est de
demander à l'expéditeur de ralentir.

et le rejet (logs-fi est ma règle de "log and drop") :
iptables -A logs-fi -j REJECT --reject-with icmp-port-unreachable



Pour ma part j'aime bien moduler le type d'erreur en fonction du type de
paquet, par exemple :
- TCP -> tcp-reset
- UDP -> icmp-port-unreachable
- autre -> icmp-proto-unreachable

Le tout avec des limitations en cas de flood.


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
Pascal
Troumad a écrit :
[...]
# MISE à ZERO des règles de filtrage
iptables -F
iptables -t nat -F



Ajoute une commande -X pour chaque table pour supprimer les
éventuelles chaînes utilisateur comme dans le choix stop.



iptables -t nat -F -X
ou
iptables -t nat -F
iptables -t nat -X



Je ne suis pas sûr que la première forme soit valide. man iptables.

iptables -A INPUT -p icmp -j ACCEPT



# accepter le protocole ICMP (ex.ping)
AMA il vaut mieux gérer explicitement les différents types de requêtes
ICMP et laisser la règle suivante s'occuper des ICMP qui sont des
réponses ou des messages d'erreur relatifs à des connexions existantes.



Donc un ping de l'extérieur ne marchera pas ?



Dans ta configuration actuelle, si puisque n'importe quel type ICMP est
accepté sans condition. Ce qui n'est pas forcément souhaitable.

iptables [...] -p tcp -m multiport --dports 111,2049 -j [...]
iptables [...] -p tcp --dports 4000:4003 -j [...]



Mais la différence entre ces deux lignes est où ? La première ports
isolé et la seconde ports concécutifs ?



Exactement.

ou encore plus simplement :

iptables [...] -p tcp -m mport --dport 111,2049,4000:4003 -j [...]



El là, tout d'un coup ! C'est encore mieux !



En effet, la correspondance 'mport' permet de combiner des ports isolés
et des intervalles de ports, ce qui manque à 'multiport'. Mais c'est une
option du patch-o-matic Netfilter qui n'est pas incluse dans le noyau
Linux standard.

[Par contre je me suis mélangé les pinceaux dans la syntaxe : c'est
--dport pour la correspondance simple tcp|udp et --dports pour les
correspondances multiport et mport.]


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
Troumad
Troumad a écrit il y a bien longtemps :

Il manque : iptables -A OUTPUT -i lo -j ACCEPT vers iptables -A
INPUT -i lo -j ACCEPT



Ça fait quoi exactement.



# /etc/init.d/firewall restart
Mise en place du mur de feu
iptables v1.2.9: Can't use -i with OUTPUT

Ça fait planter mon iptable !
--
Amicalement vOOotre Troumad Alias Bernard SIAUD
mon site : http://troumad.free.fr : AD&D maths WEB sectes
Pour la liberté http://lea-linux.org http://www.eurolinux.org/index.fr.html
N'envoyez que des documents avec des formats ouverts, comme
http://fr.openoffice.org


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
Cyprien
On Sat, May 14, 2005 at 03:34:12PM +0200, Troumad wrote:
Troumad a écrit il y a bien longtemps :

>>Il manque : iptables -A OUTPUT -i lo -j ACCEPT vers iptables -A
>>INPUT -i lo -j ACCEPT
>
>Ça fait quoi exactement.



Ca accepte les communications passant par l'interface "lo"opback,
souvent avec l'ip 127.0.0.1. Utile si la règle par défaut (de tout bon
firewall) et de ne pas accepter les paquets.

# /etc/init.d/firewall restart
Mise en place du mur de feu
iptables v1.2.9: Can't use -i with OUTPUT

Ça fait planter mon iptable !



Pas lu les précédents mails, mais l'option -i iface n'est pas
utilisable avec OUTPUT, de même que -o iface avec INPUT.

Normal que iptables n'aime pas.

Cyprien


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
Troumad
a écrit :

Troumad a écrit :

Voilà, c'est long... et ça doit mériter des améliorations !




Certes, mais je n'ai rien vu qui soit susceptible de bloquer le trafic
DNS entrant ou sortant sur le réseau local.

LOCAL="eth0"
NET="eth1"

case "$1" in
start)
echo "Mise en place du mur de feu"

# /etc/network/if-pre-up.d/iptables-start
# Script qui démarre les règles de filtrage "iptables"
# MISE à ZERO des règles de filtrage
iptables -F
iptables -t nat -F




Ajoute une commande -X pour chaque table pour supprimer les
éventuelles chaînes utilisateur comme dans le choix stop.

[...]

restart)
$0 stop




Pourquoi faire puisque le $0 start qui suit vide aussi les chaînes et
redéfinit les politiques par défaut ?




Je ne sais pas si la cause est là, mais après pleins de tests
différents, je ne pouvais plus que faire du ftp passif vers
l'extérieur... La seule possibilité a été de relancer shorewall à la
place de ce script : tout à remarché. Puis de nouveau ce script (qui ne
tente rien n'a rien) et tout fonction avec ce script !

Je me demande si les règle de mise à zéro sont bonnes !
--
Amicalement vOOotre Troumad Alias Bernard SIAUD
mon site : http://troumad.free.fr : AD&D maths WEB sectes
Pour la liberté http://lea-linux.org http://www.eurolinux.org/index.fr.html
N'envoyez que des documents avec des formats ouverts, comme
http://fr.openoffice.org


--
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
with a subject of "unsubscribe". Trouble? Contact
1 2