iptables : DROP par défaut, le LAN accède à Tux mais Tux sort pas (sauf pour surfer)
6 réponses
sittiherve
Bonjour,
Voilà donc, après deux jour de recherche sans résultat, je vous soumets mon
problème.
Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui
fait passerelle sur notre LAN.
J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux
pour les trojans ...etc.)
Depuis,
- nous pouvons aller surfer (sauf si on utilise squid).
- impossible de recevoir les email : lorsque je fais un telnet
ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion.
J'ai donc un problème sur INPUT et OUTPUT (d'ailleurs, en les remettant à
ACCEPT par defaut, ca fonctionne.
Aussi, je vousais vous dire : "j'en ai
mmmmmmmmmmmmmaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrreeeeeeeeeeeeeeeeeeeee"
Merci de votre compréhension ... et de votre solution.
# Accept all local (loopback) traffic on the lo interface
/sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
# Accept extern traffic on the public interface for Apache
/sbin/iptables -A INPUT -i $outif -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A FORWARD -i $outif -d $net/$mask -p tcp --sport
80 -mstate --state RELATED,ESTABLISHED -j ACCEPT
## Règles concernant le forwarding :
# Activation du routage NAT: translation d'adresse
/sbin/iptables -t nat -A POSTROUTING -s $net/$mask -o $outif -j MASQUERADE
# Acceptation des paquets en entrée sur out uniquement si correspondant à
des connexions établies ou necessitant une nouvelle connexion.
/sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state
RELATED,ESTABLISHED -j ACCEPT
# on accepte tous les paquets sortants du réseau local
/sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
# Log all other traffic
/sbin/iptables -A INPUT -j LOG
/sbin/iptables -A OUTPUT -j LOG
/sbin/iptables -A FORWARD -j LOG
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 Hambourg
Salut,
Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui fait passerelle sur notre LAN. J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux pour les trojans ...etc.)
Les trojans, bof... C'est mieux de bloquer par défaut et d'accepter au cas par cas simplement parce que c'est plus sûr : si on oublie d'accepter quelque chose on s'en rend vite compte, la preuve avec ton cas.
Depuis, - nous pouvons aller surfer (sauf si on utilise squid).
Donc ça passe en FORWARD, je suppose.
- impossible de recevoir les email : lorsque je fais un telnet ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion.
Normalement c'est inutile tout ça, les modules nécessaires devraient être chargés automatiquement par les règles qui en ont besoin.
# Effacement des règles des tables /sbin/iptables -t nat -F /sbin/iptables -F /sbin/iptables -X
# Define default policy to DROP packets /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -P FORWARD DROP
net2.168.0.0 mask%5.255.255.0
J'aurais rassemblé adresse réseau et masque en une seule variable contenant le préfixe 192.168.0.0/24.
inif=eth1 outif=eth0
# Accept all local (loopback) traffic on the lo interface /sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT /sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
Trop restrictif. 127.0.0.1 n'est pas la seule adresse utilisée sur l'interface de loopback. Il y a toute la plage 127.0.0.0/8 et aussi les adresses de toutes les autres interfaces locales (eth0, eth1). Bref, pas la peine de vérifier l'adresse source ou destination du trafic local. La fonction de routage du noyau s'en charge déjà très bien toute seule.
## Règles concernant les INPUT/OUTPUT # Permit DNS traffic /sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT
Trop permissif, ça laisse passer un paquet UDP entrant vers n'importe quel port destination du moment qu'il provient du port source 53. Pour le trafic retour, toujours utiliser le suivi de connexion.
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Quid des requêtes DNS sur TCP ?
# Accept local-network return traffic from private network 192.168.0.0/24: /sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state INVALID -d 192.168.0.0/24 -j ACCEPT
- Pourquoi n'autoriser que les connexions à partir d'un port source non privilégié ? Cela bloque notamment les connexions de données FTP en mode actif (port source 20). - Quid des protocole autres que TCP (UDP, ICMP...) ? - Vérifier l'interface d'entrée est plus sûr que vérifier l'adresse source. Avec ces règles un paquet provenant de l'extérieur dont l'adresse source est usurpée ("spoofée") pourrait être accepté à tort.
# Accept all HTTP connections /sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state ESTABLISHED,RELATED -j ACCEPT
- Le trafic HTTP n'est jamais dans l'état RELATED, seulement NEW et ESTABLISHED. - La gestion du trafic retour/établi/lié est inutilement compliquée. Inutile de vérifier le port à chaque paquet une fois que le paquet initial a été accepté, le suivi de connexion s'en charge déjà. Une seule règle par sens et éventuellement par interface suffirait pour gérer *tout* ce trafic.
# Accept local (192.168.0.0/24) POP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) IMAP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMTP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMB traffic /sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT /sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SQUID traffic /sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Mêmes remarques que pour HTTP pour toutes ces applications. Et mieux vaut vérifier l'interface d'entrée/sortie que l'adresse source/destination.
- Il n'y pas d'état RELATED dans HTTP. - Ça ne sert à rien de vérifier le port source d'un paquet ESTABLISHED puisque le suivi de connexion s'en charge. - Je n'ai pas déjà dit tout ça ? - Que fait une règle FORWARD à cet endroit du script et quel rapport avec la règle INPUT qui la précède ?
## Règles concernant le forwarding : # Activation du routage NAT: translation d'adresse
Note : dans Linux et Netfilter/iptables, il n'y a pas de "routage NAT" : routage et NAT (sous toutes ses formes) sont des opérations indépendantes.
# Acceptation des paquets en entrée sur out uniquement si correspondant à des connexions établies ou necessitant une nouvelle connexion. /sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state RELATED,ESTABLISHED -j ACCEPT
Il manque un(e) espace entre '-m' et 'state'.
# on accepte tous les paquets sortants du réseau local /sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Il serait plus simple de vérifier l'interface d'entrée.
# Log all other traffic /sbin/iptables -A INPUT -j LOG /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
Je ne vois aucune règle autorisant les connexions sortantes à partir de la passerelle vers l'extérieur. Par exemple, pour le proxy HTTP/HTTPS et le POP3, il faudrait :
iptables -A OUTPUT -p tcp -m multiport --dports 80,443,110 -m state --state NEW,ESTABLISHED -j ACCEPT
Et la règle correspondante pour le trafic retour dans INPUT.
Salut,
Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui
fait passerelle sur notre LAN.
J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux
pour les trojans ...etc.)
Les trojans, bof... C'est mieux de bloquer par défaut et d'accepter au
cas par cas simplement parce que c'est plus sûr : si on oublie
d'accepter quelque chose on s'en rend vite compte, la preuve avec ton cas.
Depuis,
- nous pouvons aller surfer (sauf si on utilise squid).
Donc ça passe en FORWARD, je suppose.
- impossible de recevoir les email : lorsque je fais un telnet
ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion.
Normalement c'est inutile tout ça, les modules nécessaires devraient
être chargés automatiquement par les règles qui en ont besoin.
# Effacement des règles des tables
/sbin/iptables -t nat -F
/sbin/iptables -F
/sbin/iptables -X
# Define default policy to DROP packets
/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP
net2.168.0.0
mask%5.255.255.0
J'aurais rassemblé adresse réseau et masque en une seule variable
contenant le préfixe 192.168.0.0/24.
inif=eth1
outif=eth0
# Accept all local (loopback) traffic on the lo interface
/sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
Trop restrictif. 127.0.0.1 n'est pas la seule adresse utilisée sur
l'interface de loopback. Il y a toute la plage 127.0.0.0/8 et aussi les
adresses de toutes les autres interfaces locales (eth0, eth1). Bref, pas
la peine de vérifier l'adresse source ou destination du trafic local. La
fonction de routage du noyau s'en charge déjà très bien toute seule.
## Règles concernant les INPUT/OUTPUT
# Permit DNS traffic
/sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT
Trop permissif, ça laisse passer un paquet UDP entrant vers n'importe
quel port destination du moment qu'il provient du port source 53. Pour
le trafic retour, toujours utiliser le suivi de connexion.
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Quid des requêtes DNS sur TCP ?
# Accept local-network return traffic from private network 192.168.0.0/24:
/sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state
ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state
INVALID -d 192.168.0.0/24 -j ACCEPT
- Pourquoi n'autoriser que les connexions à partir d'un port source non
privilégié ? Cela bloque notamment les connexions de données FTP en mode
actif (port source 20).
- Quid des protocole autres que TCP (UDP, ICMP...) ?
- Vérifier l'interface d'entrée est plus sûr que vérifier l'adresse
source. Avec ces règles un paquet provenant de l'extérieur dont
l'adresse source est usurpée ("spoofée") pourrait être accepté à tort.
# Accept all HTTP connections
/sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j
ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state
ESTABLISHED,RELATED -j ACCEPT
- Le trafic HTTP n'est jamais dans l'état RELATED, seulement NEW et
ESTABLISHED.
- La gestion du trafic retour/établi/lié est inutilement compliquée.
Inutile de vérifier le port à chaque paquet une fois que le paquet
initial a été accepté, le suivi de connexion s'en charge déjà. Une seule
règle par sens et éventuellement par interface suffirait pour gérer
*tout* ce trafic.
# Accept local (192.168.0.0/24) POP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) IMAP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMTP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMB traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
/sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SQUID traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Mêmes remarques que pour HTTP pour toutes ces applications.
Et mieux vaut vérifier l'interface d'entrée/sortie que l'adresse
source/destination.
- Il n'y pas d'état RELATED dans HTTP.
- Ça ne sert à rien de vérifier le port source d'un paquet ESTABLISHED
puisque le suivi de connexion s'en charge.
- Je n'ai pas déjà dit tout ça ?
- Que fait une règle FORWARD à cet endroit du script et quel rapport
avec la règle INPUT qui la précède ?
## Règles concernant le forwarding :
# Activation du routage NAT: translation d'adresse
Note : dans Linux et Netfilter/iptables, il n'y a pas de "routage NAT" :
routage et NAT (sous toutes ses formes) sont des opérations indépendantes.
# Acceptation des paquets en entrée sur out uniquement si correspondant à
des connexions établies ou necessitant une nouvelle connexion.
/sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state
RELATED,ESTABLISHED -j ACCEPT
Il manque un(e) espace entre '-m' et 'state'.
# on accepte tous les paquets sortants du réseau local
/sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Il serait plus simple de vérifier l'interface d'entrée.
# Log all other traffic
/sbin/iptables -A INPUT -j LOG
/sbin/iptables -A OUTPUT -j LOG
/sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
Je ne vois aucune règle autorisant les connexions sortantes à partir de
la passerelle vers l'extérieur. Par exemple, pour le proxy HTTP/HTTPS et
le POP3, il faudrait :
iptables -A OUTPUT -p tcp -m multiport --dports 80,443,110
-m state --state NEW,ESTABLISHED -j ACCEPT
Et la règle correspondante pour le trafic retour dans INPUT.
Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui fait passerelle sur notre LAN. J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux pour les trojans ...etc.)
Les trojans, bof... C'est mieux de bloquer par défaut et d'accepter au cas par cas simplement parce que c'est plus sûr : si on oublie d'accepter quelque chose on s'en rend vite compte, la preuve avec ton cas.
Depuis, - nous pouvons aller surfer (sauf si on utilise squid).
Donc ça passe en FORWARD, je suppose.
- impossible de recevoir les email : lorsque je fais un telnet ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion.
Normalement c'est inutile tout ça, les modules nécessaires devraient être chargés automatiquement par les règles qui en ont besoin.
# Effacement des règles des tables /sbin/iptables -t nat -F /sbin/iptables -F /sbin/iptables -X
# Define default policy to DROP packets /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -P FORWARD DROP
net2.168.0.0 mask%5.255.255.0
J'aurais rassemblé adresse réseau et masque en une seule variable contenant le préfixe 192.168.0.0/24.
inif=eth1 outif=eth0
# Accept all local (loopback) traffic on the lo interface /sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT /sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
Trop restrictif. 127.0.0.1 n'est pas la seule adresse utilisée sur l'interface de loopback. Il y a toute la plage 127.0.0.0/8 et aussi les adresses de toutes les autres interfaces locales (eth0, eth1). Bref, pas la peine de vérifier l'adresse source ou destination du trafic local. La fonction de routage du noyau s'en charge déjà très bien toute seule.
## Règles concernant les INPUT/OUTPUT # Permit DNS traffic /sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT
Trop permissif, ça laisse passer un paquet UDP entrant vers n'importe quel port destination du moment qu'il provient du port source 53. Pour le trafic retour, toujours utiliser le suivi de connexion.
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Quid des requêtes DNS sur TCP ?
# Accept local-network return traffic from private network 192.168.0.0/24: /sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state INVALID -d 192.168.0.0/24 -j ACCEPT
- Pourquoi n'autoriser que les connexions à partir d'un port source non privilégié ? Cela bloque notamment les connexions de données FTP en mode actif (port source 20). - Quid des protocole autres que TCP (UDP, ICMP...) ? - Vérifier l'interface d'entrée est plus sûr que vérifier l'adresse source. Avec ces règles un paquet provenant de l'extérieur dont l'adresse source est usurpée ("spoofée") pourrait être accepté à tort.
# Accept all HTTP connections /sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state ESTABLISHED,RELATED -j ACCEPT
- Le trafic HTTP n'est jamais dans l'état RELATED, seulement NEW et ESTABLISHED. - La gestion du trafic retour/établi/lié est inutilement compliquée. Inutile de vérifier le port à chaque paquet une fois que le paquet initial a été accepté, le suivi de connexion s'en charge déjà. Une seule règle par sens et éventuellement par interface suffirait pour gérer *tout* ce trafic.
# Accept local (192.168.0.0/24) POP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) IMAP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMTP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMB traffic /sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT /sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SQUID traffic /sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Mêmes remarques que pour HTTP pour toutes ces applications. Et mieux vaut vérifier l'interface d'entrée/sortie que l'adresse source/destination.
- Il n'y pas d'état RELATED dans HTTP. - Ça ne sert à rien de vérifier le port source d'un paquet ESTABLISHED puisque le suivi de connexion s'en charge. - Je n'ai pas déjà dit tout ça ? - Que fait une règle FORWARD à cet endroit du script et quel rapport avec la règle INPUT qui la précède ?
## Règles concernant le forwarding : # Activation du routage NAT: translation d'adresse
Note : dans Linux et Netfilter/iptables, il n'y a pas de "routage NAT" : routage et NAT (sous toutes ses formes) sont des opérations indépendantes.
# Acceptation des paquets en entrée sur out uniquement si correspondant à des connexions établies ou necessitant une nouvelle connexion. /sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state RELATED,ESTABLISHED -j ACCEPT
Il manque un(e) espace entre '-m' et 'state'.
# on accepte tous les paquets sortants du réseau local /sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Il serait plus simple de vérifier l'interface d'entrée.
# Log all other traffic /sbin/iptables -A INPUT -j LOG /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
Je ne vois aucune règle autorisant les connexions sortantes à partir de la passerelle vers l'extérieur. Par exemple, pour le proxy HTTP/HTTPS et le POP3, il faudrait :
iptables -A OUTPUT -p tcp -m multiport --dports 80,443,110 -m state --state NEW,ESTABLISHED -j ACCEPT
Et la règle correspondante pour le trafic retour dans INPUT.
Sam
Bonjour,
Je vais essayer de répondre,
Bonjour, Voilà donc, après deux jour de recherche sans résultat, je vous soumets mon problème. Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui fait passerelle sur notre LAN. J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux pour les trojans ...etc.) Depuis, - nous pouvons aller surfer (sauf si on utilise squid). - impossible de recevoir les email : lorsque je fais un telnet ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion. J'ai donc un problème sur INPUT et OUTPUT (d'ailleurs, en les remettant à ACCEPT par defaut, ca fonctionne. Aussi, je vousais vous dire : "j'en ai mmmmmmmmmmmmmaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrreeeeeeeeeeeeeeeeeeeee" Merci de votre compréhension ... et de votre solution. # Chargement des modules /sbin/modprobe iptable_nat /sbin/modprobe ip_tables /sbin/modprobe ip_conntrack /sbin/modprobe iptable_filter /sbin/modprobe iptable_nat /sbin/modprobe iptable_mangle /sbin/modprobe ipt_state /sbin/modprobe ipt_MASQUERADE # Effacement des règles des tables /sbin/iptables -t nat -F /sbin/iptables -F /sbin/iptables -X # Define default policy to DROP packets /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -P FORWARD DROP net2.168.0.0 mask%5.255.255.0 inif=eth1 outif=eth0 # Accept all local (loopback) traffic on the lo interface /sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT /sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT #/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-) Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
## Règles concernant les INPUT/OUTPUT # Permit DNS traffic /sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT /sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Il faut pas oublier tcp pour le port 53 Il manque l'interface Puisque par la suite tu gères les états, mets les aussi maintenant : iptables -A INPUT -i $wan -p udp --sport 53 -m state --state ESTABLISHED -J ACCEPT iptables -A OUTPUT -o $wan -p udp --dport 53 -m state NEW,ESTABLISHED -j ACCEPT
# Accept local-network return traffic from private network 192.168.0.0/24: /sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT
Et pourquoi que tcp, pas udp ? En faisant ça, tu risques d'accepter les adresses spoofées privées venant d'Internet car pas d'interface désignée. iptables -A INPUT -i $lan -p tcp etc ....
/sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state INVALID -d 192.168.0.0/24 -j ACCEPT
Il manque l'interface Je ne comprends pas trop pourquoi un état invalid devrait être accepté.
# Accept all HTTP connections /sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state ESTABLISHED,RELATED -j ACCEPT
Je comprends de moins en moins. Normalement pour forward lan -> wan: iptables -A FORWARD -i $lan -o $wan -p tcp --sport 1024:65535 --dport 80 -m state --state NEW, ESTABLISHED -j ACCEPT iptables -A FORWARD -i $wan -o $lan -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
puis pour passerelle -> $wan
iptables -A OUTPUT -o $wan -p tcp --dport 80 --sport 1024:65535 -m state --state NEW -j ACCEPT iptables -A INPUT -i $wan -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
# Accept local (192.168.0.0/24) POP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) IMAP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SMTP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SMB traffic /sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT /sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SQUID traffic /sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Plusieurs remarques :
Plutôt que de traiter X fois l'état invalid, tu le traites une bonne fois pour toutes à part :
iptables -N INVALID_PACKET iptables -F INVALID_PACKET iptables -A FORWARD -m state --state INVALID -j INVALID_PACKET
# Accept extern traffic on the public interface for Apache /sbin/iptables -A INPUT -i $outif -p tcp --dport 80 -j ACCEPT /sbin/iptables -A FORWARD -i $outif -d $net/$mask -p tcp --sport 80 -mstate --state RELATED,ESTABLISHED -j ACCEPT
## Règles concernant le forwarding : # Activation du routage NAT: translation d'adresse /sbin/iptables -t nat -A POSTROUTING -s $net/$mask -o $outif -j MASQUERADE
# Acceptation des paquets en entrée sur out uniquement si correspondant à des connexions établies ou necessitant une nouvelle connexion. /sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state RELATED,ESTABLISHED -j ACCEPT
# on accepte tous les paquets sortants du réseau local /sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Et on pollue Internet avec les vers qui infectent le réseau local. Je dis ça parce qu'en début tu dis que tu veux affiner tes règles. Le réseau local ne doit sortir en NEW que les ports désignés par les règles précédentes (et c'est pour ça aussi qu'il y a des règles précédentes ;-) ).
services_autorises="25,80,110,993" etc ... iptables -A FORWARD -i $lan -o $wan -p tcp -m multiport --sport 1024:655535 --dport $services_autorises -m state --state NEW -j ACCEPT iptables -A FORWARD -i $wan -o $lan -p tcp -m multiport --sport $services_autorises --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
# Log all other traffic /sbin/iptables -A INPUT -j LOG /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
J'ai fais ça rapidement, y'a peut-être des erreurs, mais tu dois revoir ton script entièrement, c'est trop mélangé. Gère interface pas interface, n'hésite pas à détailler les connexions (états etc ...).
$lan -> passerelle iptables -A INPUT -i $lan $lan -> $wan iptables -A FORWARD -i $lan -o $wan passerelle -> $wan iptables -A OUTPUT -o $wan
Sam ... qui passait par là pour voir s'il avait une réponse ;-)
Bonjour,
Je vais essayer de répondre,
Bonjour,
Voilà donc, après deux jour de recherche sans résultat, je vous soumets mon
problème.
Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui
fait passerelle sur notre LAN.
J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux
pour les trojans ...etc.)
Depuis,
- nous pouvons aller surfer (sauf si on utilise squid).
- impossible de recevoir les email : lorsque je fais un telnet
ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion.
J'ai donc un problème sur INPUT et OUTPUT (d'ailleurs, en les remettant à
ACCEPT par defaut, ca fonctionne.
Aussi, je vousais vous dire : "j'en ai
mmmmmmmmmmmmmaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrreeeeeeeeeeeeeeeeeeeee"
Merci de votre compréhension ... et de votre solution.
# Chargement des modules
/sbin/modprobe iptable_nat
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe iptable_mangle
/sbin/modprobe ipt_state
/sbin/modprobe ipt_MASQUERADE
# Effacement des règles des tables
/sbin/iptables -t nat -F
/sbin/iptables -F
/sbin/iptables -X
# Define default policy to DROP packets
/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP
net2.168.0.0
mask%5.255.255.0
inif=eth1
outif=eth0
# Accept all local (loopback) traffic on the lo interface
/sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
#/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-)
Sauf que si par la suite il y a une règle qui dit le contraire (puisque
tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui
l'emporte.
## Règles concernant les INPUT/OUTPUT
# Permit DNS traffic
/sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Il faut pas oublier tcp pour le port 53
Il manque l'interface
Puisque par la suite tu gères les états, mets les aussi maintenant :
iptables -A INPUT -i $wan -p udp --sport 53 -m state --state ESTABLISHED
-J ACCEPT
iptables -A OUTPUT -o $wan -p udp --dport 53 -m state NEW,ESTABLISHED -j
ACCEPT
# Accept local-network return traffic from private network 192.168.0.0/24:
/sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state
ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT
Et pourquoi que tcp, pas udp ?
En faisant ça, tu risques d'accepter les adresses spoofées privées
venant d'Internet car pas d'interface désignée.
iptables -A INPUT -i $lan -p tcp etc ....
/sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state
INVALID -d 192.168.0.0/24 -j ACCEPT
Il manque l'interface
Je ne comprends pas trop pourquoi un état invalid devrait être accepté.
# Accept all HTTP connections
/sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j
ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state
ESTABLISHED,RELATED -j ACCEPT
Je comprends de moins en moins.
Normalement pour forward lan -> wan:
iptables -A FORWARD -i $lan -o $wan -p tcp --sport 1024:65535 --dport 80
-m state --state NEW, ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $wan -o $lan -p tcp --sport 80 --dport 1024:65535
-m state --state ESTABLISHED -j ACCEPT
puis pour passerelle -> $wan
iptables -A OUTPUT -o $wan -p tcp --dport 80 --sport 1024:65535 -m state
--state NEW -j ACCEPT
iptables -A INPUT -i $wan -p tcp --sport 80 --dport 1024:65535 -m state
--state ESTABLISHED -j ACCEPT
# Accept local (192.168.0.0/24) POP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) IMAP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMTP traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SMB traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
/sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
# Accept local (192.168.0.0/24) SQUID traffic
/sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s
192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state
ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Plusieurs remarques :
Plutôt que de traiter X fois l'état invalid, tu le traites une bonne
fois pour toutes à part :
iptables -N INVALID_PACKET
iptables -F INVALID_PACKET
iptables -A FORWARD -m state --state INVALID -j INVALID_PACKET
# Accept extern traffic on the public interface for Apache
/sbin/iptables -A INPUT -i $outif -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A FORWARD -i $outif -d $net/$mask -p tcp --sport
80 -mstate --state RELATED,ESTABLISHED -j ACCEPT
## Règles concernant le forwarding :
# Activation du routage NAT: translation d'adresse
/sbin/iptables -t nat -A POSTROUTING -s $net/$mask -o $outif -j MASQUERADE
# Acceptation des paquets en entrée sur out uniquement si correspondant à
des connexions établies ou necessitant une nouvelle connexion.
/sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state
RELATED,ESTABLISHED -j ACCEPT
# on accepte tous les paquets sortants du réseau local
/sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Et on pollue Internet avec les vers qui infectent le réseau local.
Je dis ça parce qu'en début tu dis que tu veux affiner tes règles.
Le réseau local ne doit sortir en NEW que les ports désignés par les
règles précédentes (et c'est pour ça aussi qu'il y a des règles
précédentes ;-) ).
services_autorises="25,80,110,993" etc ...
iptables -A FORWARD -i $lan -o $wan -p tcp -m multiport --sport
1024:655535 --dport $services_autorises -m state --state NEW -j ACCEPT
iptables -A FORWARD -i $wan -o $lan -p tcp -m multiport --sport
$services_autorises --dport 1024:65535 -m state --state ESTABLISHED -j
ACCEPT
# Log all other traffic
/sbin/iptables -A INPUT -j LOG
/sbin/iptables -A OUTPUT -j LOG
/sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
J'ai fais ça rapidement, y'a peut-être des erreurs, mais tu dois revoir
ton script entièrement, c'est trop mélangé.
Gère interface pas interface, n'hésite pas à détailler les connexions
(états etc ...).
$lan -> passerelle
iptables -A INPUT -i $lan
$lan -> $wan
iptables -A FORWARD -i $lan -o $wan
passerelle -> $wan
iptables -A OUTPUT -o $wan
Sam ... qui passait par là pour voir s'il avait une réponse ;-)
Bonjour, Voilà donc, après deux jour de recherche sans résultat, je vous soumets mon problème. Nous avons un serveur Mandriva (smb, postfix, fetchmail, squid, ...) qui fait passerelle sur notre LAN. J'ai modifié mes iptables pour tout dropper par défaut (voir script ) (mieux pour les trojans ...etc.) Depuis, - nous pouvons aller surfer (sauf si on utilise squid). - impossible de recevoir les email : lorsque je fais un telnet ip.mon.fai. 110 ... la résolution DNS est Ok mais pas de connexion. J'ai donc un problème sur INPUT et OUTPUT (d'ailleurs, en les remettant à ACCEPT par defaut, ca fonctionne. Aussi, je vousais vous dire : "j'en ai mmmmmmmmmmmmmaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrrrrrrreeeeeeeeeeeeeeeeeeeee" Merci de votre compréhension ... et de votre solution. # Chargement des modules /sbin/modprobe iptable_nat /sbin/modprobe ip_tables /sbin/modprobe ip_conntrack /sbin/modprobe iptable_filter /sbin/modprobe iptable_nat /sbin/modprobe iptable_mangle /sbin/modprobe ipt_state /sbin/modprobe ipt_MASQUERADE # Effacement des règles des tables /sbin/iptables -t nat -F /sbin/iptables -F /sbin/iptables -X # Define default policy to DROP packets /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -P FORWARD DROP net2.168.0.0 mask%5.255.255.0 inif=eth1 outif=eth0 # Accept all local (loopback) traffic on the lo interface /sbin/iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT /sbin/iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT #/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-) Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
## Règles concernant les INPUT/OUTPUT # Permit DNS traffic /sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT /sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
Il faut pas oublier tcp pour le port 53 Il manque l'interface Puisque par la suite tu gères les états, mets les aussi maintenant : iptables -A INPUT -i $wan -p udp --sport 53 -m state --state ESTABLISHED -J ACCEPT iptables -A OUTPUT -o $wan -p udp --dport 53 -m state NEW,ESTABLISHED -j ACCEPT
# Accept local-network return traffic from private network 192.168.0.0/24: /sbin/iptables -A INPUT -m state -p tcp --dport 1024:65535 --state ESTABLISHED,RELATED -s 192.168.0.0/24 -j ACCEPT
Et pourquoi que tcp, pas udp ? En faisant ça, tu risques d'accepter les adresses spoofées privées venant d'Internet car pas d'interface désignée. iptables -A INPUT -i $lan -p tcp etc ....
/sbin/iptables -A OUTPUT -m state -p tcp --sport 1024:65535 ! --state INVALID -d 192.168.0.0/24 -j ACCEPT
Il manque l'interface Je ne comprends pas trop pourquoi un état invalid devrait être accepté.
# Accept all HTTP connections /sbin/iptables -A INPUT -m state -p tcp --dport 80 ! --state INVALID -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 80 --state ESTABLISHED,RELATED -j ACCEPT
Je comprends de moins en moins. Normalement pour forward lan -> wan: iptables -A FORWARD -i $lan -o $wan -p tcp --sport 1024:65535 --dport 80 -m state --state NEW, ESTABLISHED -j ACCEPT iptables -A FORWARD -i $wan -o $lan -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
puis pour passerelle -> $wan
iptables -A OUTPUT -o $wan -p tcp --dport 80 --sport 1024:65535 -m state --state NEW -j ACCEPT iptables -A INPUT -i $wan -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
# Accept local (192.168.0.0/24) POP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 110 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 110 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) IMAP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 443 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 443 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SMTP traffic /sbin/iptables -A INPUT -m state -p tcp --dport 25 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 25 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SMB traffic /sbin/iptables -A INPUT -m state -p tcp --dport 139 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 139 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT /sbin/iptables -A INPUT -m state -p tcp --dport 445 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 445 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT # Accept local (192.168.0.0/24) SQUID traffic /sbin/iptables -A INPUT -m state -p tcp --dport 3128 ! --state INVALID -s 192.168.0.0/24 -j ACCEPT /sbin/iptables -A OUTPUT -m state -p tcp --sport 3128 --state ESTABLISHED,RELATED -d 192.168.0.0/24 -j ACCEPT
Plusieurs remarques :
Plutôt que de traiter X fois l'état invalid, tu le traites une bonne fois pour toutes à part :
iptables -N INVALID_PACKET iptables -F INVALID_PACKET iptables -A FORWARD -m state --state INVALID -j INVALID_PACKET
# Accept extern traffic on the public interface for Apache /sbin/iptables -A INPUT -i $outif -p tcp --dport 80 -j ACCEPT /sbin/iptables -A FORWARD -i $outif -d $net/$mask -p tcp --sport 80 -mstate --state RELATED,ESTABLISHED -j ACCEPT
## Règles concernant le forwarding : # Activation du routage NAT: translation d'adresse /sbin/iptables -t nat -A POSTROUTING -s $net/$mask -o $outif -j MASQUERADE
# Acceptation des paquets en entrée sur out uniquement si correspondant à des connexions établies ou necessitant une nouvelle connexion. /sbin/iptables -A FORWARD -i $outif -d $net/$mask -mstate --state RELATED,ESTABLISHED -j ACCEPT
# on accepte tous les paquets sortants du réseau local /sbin/iptables -A FORWARD -s $net/$mask -o $outif -j ACCEPT
Et on pollue Internet avec les vers qui infectent le réseau local. Je dis ça parce qu'en début tu dis que tu veux affiner tes règles. Le réseau local ne doit sortir en NEW que les ports désignés par les règles précédentes (et c'est pour ça aussi qu'il y a des règles précédentes ;-) ).
services_autorises="25,80,110,993" etc ... iptables -A FORWARD -i $lan -o $wan -p tcp -m multiport --sport 1024:655535 --dport $services_autorises -m state --state NEW -j ACCEPT iptables -A FORWARD -i $wan -o $lan -p tcp -m multiport --sport $services_autorises --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
# Log all other traffic /sbin/iptables -A INPUT -j LOG /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A FORWARD -j LOG
echo 1 >/proc/sys/net/ipv4/ip_forward
J'ai fais ça rapidement, y'a peut-être des erreurs, mais tu dois revoir ton script entièrement, c'est trop mélangé. Gère interface pas interface, n'hésite pas à détailler les connexions (états etc ...).
$lan -> passerelle iptables -A INPUT -i $lan $lan -> $wan iptables -A FORWARD -i $lan -o $wan passerelle -> $wan iptables -A OUTPUT -o $wan
Sam ... qui passait par là pour voir s'il avait une réponse ;-)
Sam
Mes excuses à Pascal pour la réponse en double, j'avais commencé ma réponse avant qu'il n'ait envoyé la sienne.
Sam.
Mes excuses à Pascal pour la réponse en double, j'avais commencé ma
réponse avant qu'il n'ait envoyé la sienne.
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-)
Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles de la chaîne s'interrompt et les règles suivantes sont ignorées.
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-)
Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le
trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire (puisque
tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui
l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès
qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles
de la chaîne s'interrompt et les règles suivantes sont ignorées.
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie ;-)
Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles de la chaîne s'interrompt et les règles suivantes sont ignorées.
Sam
#/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT Là ça sent le gars désespéré qui veut que le port 110 marche en sortie
;-) Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le
trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles de la chaîne s'interrompt et les règles suivantes sont ignorées.
Oui grosse erreur de ma part ... j'avais oublié (ça fait de long mois que je ne pratique plus trop iptables).
Sam.
#/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT
Là ça sent le gars désespéré qui veut que le port 110 marche en sortie
;-)
Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le
trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire
(puisque tu dis que ça marche pas), et ben c'est la dernière règle
bloquante qui l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès
qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles
de la chaîne s'interrompt et les règles suivantes sont ignorées.
Oui grosse erreur de ma part ... j'avais oublié (ça fait de long mois
que je ne pratique plus trop iptables).
#/sbin/iptables -A OUTPUT -p tcp --dport 110 -s 192.168.0.0/24 -j ACCEPT Là ça sent le gars désespéré qui veut que le port 110 marche en sortie
;-) Mais qui n'a pas mis la bonne adresse source et a oublié d'accepter le
trafic retour...
Sauf que si par la suite il y a une règle qui dit le contraire (puisque tu dis que ça marche pas), et ben c'est la dernière règle bloquante qui l'emporte.
Non, c'est la première règle avec une cible "terminale" qui gagne. Dès qu'une règle accepte, bloque ou rejette une paquet, l'examen des règles de la chaîne s'interrompt et les règles suivantes sont ignorées.
Oui grosse erreur de ma part ... j'avais oublié (ça fait de long mois que je ne pratique plus trop iptables).
