vérifier l'utilisation d'une règle Iptables

Pascal

13/05/2005 à 21:10

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu dans
la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3
autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est déjà
d'avoir fait du filtrage dans la table nat.

--
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

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu dans
la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3
autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est déjà
d'avoir fait du filtrage dans la table nat.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu dans
la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3
autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est déjà
d'avoir fait du filtrage dans la table nat.

--
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

Seb

14/05/2005 à 11:30

Bonjour,

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Merci pour ces précisions concerant la table NAT et la chaine
PREROUTING, je n'avais pas conscience de çà.
Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.
Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

Merci pour toutes ces explications.

A+
SEB

wrote:

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance
mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis
l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu
dans la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3 autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est
déjà d'avoir fait du filtrage dans la table nat.

--
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

Bonjour,

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Merci pour ces précisions concerant la table NAT et la chaine
PREROUTING, je n'avais pas conscience de çà.
Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.
Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

Merci pour toutes ces explications.

A+
SEB

Pascal@plouf wrote:

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance
mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis
l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu
dans la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3 autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est
déjà d'avoir fait du filtrage dans la table nat.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Merci pour ces précisions concerant la table NAT et la chaine
PREROUTING, je n'avais pas conscience de çà.
Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.
Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

Merci pour toutes ces explications.

A+
SEB

wrote:

Salut,

Seb a écrit :

Sur ma passerelle, j'ai ajouté des règles Iptables pour améliorer la
sécurité, en empêchant par exemple les trames venant d'Internet qui ont
comme source des IP de classes A, B, C et D.

Alors tes règles ne doivent pas laisser passer grand chose, dans la
mesure ou la plupart des adresses internet appartiennent à ces anciennes
classes. Classes qui sont désormais obsolètes depuis l'adoption de CIDR,
c'est-à-dire un bon moment.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s 10.0.0.0/8 -j DROP

Dans ce cas, je sais quelles fonctionnent avec "iptables -t nat -L -n
- -v" et le nb de paquets donné.

Remarque : bien que supportant les cibles ACCEPT et DROP, les chaînes
PREROUTING, OUTPUT et POSTROUTING de la table nat ne sont pas prévues
pour faire du filtrage mais uniquement du NAT (SNAT, DNAT, MASQUERADE,
REDIRECT, NETMAP...), à cause de leur fonctionnement particulier en
relation avec le suivi de connexion : seul le premier paquet d'une
connexion est examiné par les règles des chaînes de la table nat, et le
résultat détermine également le traitement des paquets suivants dans les
deux sens.

Le filtrage (ACCEPT, REJECT, DROP...) doit avoir lieu dans les chaînes
INPUT, OUTPUT et FORWARD de la table filter (table par défaut) qui sont
prévues pour ça. A la limite, si on a besoin de filtrer sur des critères
qui peuvent être altérés après la traversée de la chaîne PREROUTING
(comme par exemple l'adresse destination en cas de port forwarding), il
vaut mieux le faire dans la table mangle (toujours traversée avant la
table nat) que dans la table nat. Mais une solution plus élégante
consiste à marquer les paquets à filtrer dans la table mangle avec la
cible MARK et à les filtrer dans la table filter avec la correspondance
mark.

Exemple pour rejeter l'accès aux adresses privées du LAN depuis
l'extérieur :

iptables -t mangle -A PREROUTING -i $WAN_INTERFACE -d $LAN_NETWORK
-j MARK --set-mark 0x1234

iptables -A INPUT -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

iptables -A FORWARD -i $WAN_INTERFACE -m mark --mark 0x1234
-j REJECT --reject-with network unreachable

J'ai voulu ajouté des règles pour l'accès à POP3 (tcp/110) où seules les
IP des serveurs POP3 choisis seront accessibles (en fait je drop les
trames qui ne corresponde pas).
iptables -t nat -A PREROUTING -i $LAN_INTERFACE -s $LAN_NETWORK -p tcp
- --dport 110 -d ! $ipPopServer -j DROP

Remarque 1: comme expliqué plus haut, ce filtrage devrait avoir lieu
dans la chaîne FORWARD de la table filter.

Remarque 2: pour ce genre de filtrage il vaut mieux utiliser la cible
REJECT avec émission d'un RST (option --reject-with tcp-reset) pour
signaler immédiatement à l'émetteur que la connexion est refusée au lieu
de le laisser réessayer plusieurs fois et attendre en vain une réponse
avant d'abandonner finalement.

Remarque 3: tu fais comment s'il y a plusieurs adresses de serveurs POP3 autorisées ?

Pour les tests j'ai mis "-j ACCEPT"

Si c'est pour compter on peut aussi ne pas spécifier de cible, ainsi le
paquet continue à traverser les règles suivantes.

Mais dans ce cas, même en allant relever mes mails, je n'ai pas d'info
sur le nb de paquets pris par la règle.

Mais encore ? Le compteur de paquets reste à zéro ?
Le serveur POP interrogé est-il celui autorisé ou un autre ?

Une erreur de ma part, c'est sûr, mais je ne vois pas où.
Une petite idée ??

Il faudrait voir les règles précédentes. Mais la première erreur est
déjà d'avoir fait du filtrage dans la table nat.

--
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

Pascal

14/05/2005 à 12:50

Seb a écrit :

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Je m'en doutais. ;-) Tu peux aussi ajouter dans FORWARD le bloc
169.254.0.0/16 qui correspond aux adresses non routables de type
link-local, utilisées entre autres par le mécanisme APIPA de Windows
(attribution automatique d'une adresse de repli en cas d'échec de DHCP).
Même chose dans INPUT sauf si la liaison entre ta passerelle et ton FAI
utilise ces adresses.

Pour information, je n'utilise plus de règles iptables pour filtrer ces
adresses sur ma passerelle. A la place, j'ajoute des routes "reject" avec
une métrique élevée dans la table de routage en conjonction avec le
paramètre du noyau /proc/sys/net/ipv4/conf/*/rp_filter (reverse path
filter) mis à 1 sur toutes les interfaces. C'est donc la pile IP qui fait
le filtrage. J'y trouve un triple avantage :
- élimine les paquets venant du WAN avec ces adresses source ;
- rejette les paquets venant du LAN ou de la passerelle avec ces adresses
destination, ce qui a pour effet d'empêcher l'émission de tels paquets
vers le WAN (pas très propre), avec envoi vers l'émetteur d'un ICMP
destination-unreachable ;
- si je veux router un sous-réseau appartenant à un de ces blocs sur mon
LAN, il suffit de créer une route avec une métrique normale, pas besoin
de modifier les règles iptables.

Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

En fait la table mangle sert à toutes sortes de modifications des
en-têtes de paquets portant sur autre chose que les adresses et les
ports. Le marquage, qui est une modification "virtuelle", peut servir à
faire de la QoS, du routage avancé sur plusieurs interfaces, ou pour
faire du filtrage comme ici. Sur ma passerelle, je me sers de la table
mangle pour modifier le TTL des paquets IP entrants (et son équivalent le
hop-limit en IPv6) et compenser un bug des routeurs de mon FAI.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Tu peux le faire aussi sur la patte WAN, les gens qui se trompent
d'adresse et tombent par erreur sur la tienne t'en seront reconnaissants.
Eventuellement tu peux introduire une limite (-m limit) dans la règle
pour éviter de consommer trop d'upload et réduire les dommages
collatéraux d'une attaque par spoofing. Idem pour le ping.

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

S'il y a plusieurs serveurs, il faudra plusieurs règles.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.

Il suffisait de tester avec un autre serveur POP. ;-)

Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

C'est classique. C'est pourquoi je répète à chaque fois qu'on ne peut pas
déduire grand chose d'une règle isolée, il faut toujours la replacer dans
son contexte avec les autres règles qui précèdent et qui suivent.

--
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

Seb a écrit :

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Je m'en doutais. ;-) Tu peux aussi ajouter dans FORWARD le bloc
169.254.0.0/16 qui correspond aux adresses non routables de type
link-local, utilisées entre autres par le mécanisme APIPA de Windows
(attribution automatique d'une adresse de repli en cas d'échec de DHCP).
Même chose dans INPUT sauf si la liaison entre ta passerelle et ton FAI
utilise ces adresses.

Pour information, je n'utilise plus de règles iptables pour filtrer ces
adresses sur ma passerelle. A la place, j'ajoute des routes "reject" avec
une métrique élevée dans la table de routage en conjonction avec le
paramètre du noyau /proc/sys/net/ipv4/conf/*/rp_filter (reverse path
filter) mis à 1 sur toutes les interfaces. C'est donc la pile IP qui fait
le filtrage. J'y trouve un triple avantage :
- élimine les paquets venant du WAN avec ces adresses source ;
- rejette les paquets venant du LAN ou de la passerelle avec ces adresses
destination, ce qui a pour effet d'empêcher l'émission de tels paquets
vers le WAN (pas très propre), avec envoi vers l'émetteur d'un ICMP
destination-unreachable ;
- si je veux router un sous-réseau appartenant à un de ces blocs sur mon
LAN, il suffit de créer une route avec une métrique normale, pas besoin
de modifier les règles iptables.

Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

En fait la table mangle sert à toutes sortes de modifications des
en-têtes de paquets portant sur autre chose que les adresses et les
ports. Le marquage, qui est une modification "virtuelle", peut servir à
faire de la QoS, du routage avancé sur plusieurs interfaces, ou pour
faire du filtrage comme ici. Sur ma passerelle, je me sers de la table
mangle pour modifier le TTL des paquets IP entrants (et son équivalent le
hop-limit en IPv6) et compenser un bug des routeurs de mon FAI.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Tu peux le faire aussi sur la patte WAN, les gens qui se trompent
d'adresse et tombent par erreur sur la tienne t'en seront reconnaissants.
Eventuellement tu peux introduire une limite (-m limit) dans la règle
pour éviter de consommer trop d'upload et réduire les dommages
collatéraux d'une attaque par spoofing. Idem pour le ping.

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

S'il y a plusieurs serveurs, il faudra plusieurs règles.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.

Il suffisait de tester avec un autre serveur POP. ;-)

Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

C'est classique. C'est pourquoi je répète à chaque fois qu'on ne peut pas
déduire grand chose d'une règle isolée, il faut toujours la replacer dans
son contexte avec les autres règles qui précèdent et qui suivent.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Seb a écrit :

Je ne refuse pas toutes les IP de classes A, B, C et D, mais seulement
les réseaux 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4 et
240.0.0.0/5 arrivant sur la pate Internet de ma passerelle.

Je m'en doutais. ;-) Tu peux aussi ajouter dans FORWARD le bloc
169.254.0.0/16 qui correspond aux adresses non routables de type
link-local, utilisées entre autres par le mécanisme APIPA de Windows
(attribution automatique d'une adresse de repli en cas d'échec de DHCP).
Même chose dans INPUT sauf si la liaison entre ta passerelle et ton FAI
utilise ces adresses.

Pour information, je n'utilise plus de règles iptables pour filtrer ces
adresses sur ma passerelle. A la place, j'ajoute des routes "reject" avec
une métrique élevée dans la table de routage en conjonction avec le
paramètre du noyau /proc/sys/net/ipv4/conf/*/rp_filter (reverse path
filter) mis à 1 sur toutes les interfaces. C'est donc la pile IP qui fait
le filtrage. J'y trouve un triple avantage :
- élimine les paquets venant du WAN avec ces adresses source ;
- rejette les paquets venant du LAN ou de la passerelle avec ces adresses
destination, ce qui a pour effet d'empêcher l'émission de tels paquets
vers le WAN (pas très propre), avec envoi vers l'émetteur d'un ICMP
destination-unreachable ;
- si je veux router un sous-réseau appartenant à un de ces blocs sur mon
LAN, il suffit de créer une route avec une métrique normale, pas besoin
de modifier les règles iptables.

Pour la table MANGLE, je m'étais arrêté à son utilisation pour le QOS,
mais je vais m'y intéresser maintenant.

En fait la table mangle sert à toutes sortes de modifications des
en-têtes de paquets portant sur autre chose que les adresses et les
ports. Le marquage, qui est une modification "virtuelle", peut servir à
faire de la QoS, du routage avancé sur plusieurs interfaces, ou pour
faire du filtrage comme ici. Sur ma passerelle, je me sers de la table
mangle pour modifier le TTL des paquets IP entrants (et son équivalent le
hop-limit en IPv6) et compenser un bug des routeurs de mon FAI.

Comme les communications viennent du LAN, je peux donner un minimum
d'infos, et ajouter " --reject-with tcp-reset" ne fait pas de mal..

Tu peux le faire aussi sur la patte WAN, les gens qui se trompent
d'adresse et tombent par erreur sur la tienne t'en seront reconnaissants.
Eventuellement tu peux introduire une limite (-m limit) dans la règle
pour éviter de consommer trop d'upload et réduire les dommages
collatéraux d'une attaque par spoofing. Idem pour le ping.

Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
récupérer les IP du serveur POP3 et de les utiliser dans une règle IPTABLES.

S'il y a plusieurs serveurs, il faudra plusieurs règles.

Pour mes tests sur ces règles, j'ai fait 2 erreurs.
J'ai oublié de supprimer le ! dans la règle avec le "-j ACCEPT" pour
matcher les connexions aux serveurs POP3.

Il suffisait de tester avec un autre serveur POP. ;-)

Et surtout j'ai oublié que l'ordre des règles était important (juste
avant ces règles une autre règle matchait les communications vers POP3
(p3scan pour vérifier les virus) )

C'est classique. C'est pourquoi je répète à chaque fois qu'on ne peut pas
déduire grand chose d'une règle isolée, il faut toujours la replacer dans
son contexte avec les autres règles qui précèdent et qui suivent.

--
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

Jacques L'helgoualc'h

14/05/2005 à 13:30

Bonjour,

a écrit, samedi 14 mai 2005, à 12:28 :

Seb a écrit :

[...]

>Sur ma passerelle, j'ai aussi un serveur DNS, il est donc facile de
>récupérer les IP du serveur POP3 et de les utiliser dans une règle
>IPTABLES.

S'il y a plusieurs serveurs, il faudra plusieurs règles.

Mais on peut n'en écrire qu'une :

$ host pop.free.fr
pop.free.fr has address 212.27.42.11
pop.free.fr has address 212.27.42.12
pop.free.fr has address 212.27.42.13
pop.free.fr has address 212.27.42.14

et

# iptables -A OUTPUT [...] -d pop.free.fr -j ACCEPT

crée les quatre règles. Et la même commande avec s/-A/-D/ va aussi les
détruire toutes les quatre d'un seul coup ...

--
Jacques L'helgoualc'h

--
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

vérifier l'utilisation d'une règle Iptables

4 réponses

Veuillez sélectionner un problème