Pourquoi ne puis-je pas utiliser la politique REJECT sur ma chaîne de sortie iptables?

11

J'ai actuellement ma chaîne OUTPUT réglée sur DROP. Je voudrais le changer en REJETER, afin d'avoir une idée que c'est mon pare-feu qui m'empêche d'accéder à quelque chose plutôt qu'un problème avec le service auquel j'essaie d'accéder (rejet immédiat au lieu de temporiser). Cependant, iptables ne semble pas s'en soucier. Si j'édite manuellement mon fichier de règles enregistré et que j'essaye de le restaurer, j'obtiens iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy nameet il refuse de charger les règles. Si j'essaye de régler ceci manuellement ( iptables -P OUTPUT REJECT), j'obtiens iptables: Bad policy name. Run 'dmesg' for more information.mais il n'y a aucune sortie dans dmesg.

J'ai confirmé que la règle appropriée est compilée dans le noyau et j'ai redémarré pour m'assurer qu'elle est chargée:

# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y

(Des astérisques ont été ajoutés pour mettre en évidence la règle applicable)

Tout ce que je peux trouver indique que REJETER est une politique / cible valide (en général), mais je ne trouve rien qui dise qu'il n'est pas valide pour les chaînes INPUT, FORWARD ou OUTPUT. Mon Google-fu n'aide pas. Je suis sur Gentoo, si cela fait une différence. Quelqu'un ici a une idée?

networking iptables gentoo

— ND Geek
source

Pouvez-vous montrer la ou les iptablesrègles en question?

— bahamat

15

REJECTest une extension cible , tandis qu'une stratégie de chaîne doit être une cible . La page de manuel dit que (bien que ce ne soit pas vraiment clair), mais une partie de ce qu'elle dit est complètement fausse.

La politique ne peut être que sur ACCEPTou DROPsur des chaînes intégrées. Si vous voulez avoir pour effet de rejeter tous les paquets qui ne correspondent pas aux règles précédentes, assurez-vous simplement que la dernière règle correspond à tout et ajoute une règle avec une REJECTextension cible. En d'autres termes, après avoir ajouté toutes les règles pertinentes, faites-le iptables -t filter -A OUTPUT -j REJECT.

Voir le fil "quelles sont les politiques de chaîne possibles" sur la liste netfilter pour plus de détails.

— Shawn J. Goff
source

Cela a du sens, et un REJET générique à la fin devrait fonctionner. Par curiosité, la définition de l' extension cible est-elle quelque part assez évidente et je l'ai juste ratée, ou est-ce l'un des bits mal documentés?

— ND Geek

1

En lisant toute la page de manuel, il est clair que REJECT est une extension cible, mais la page de manuel est très longue, donc "TL; DR" a tendance à s'appliquer. Cela implique également que DROP, ACCEPT et QUEUE sont des cibles de politique valides; du code actuel, QUEUE ne l'est pas!

— StarNamer

4

Je n'ai pas pu le trouver documenté, mais une référence ici indique que les seules politiques autorisées sont ACCEPTor DROP. Ceci est confirmé en regardant la source de libiptc(qui est responsable de la manipulation des règles) autour de la ligne 2429, où le code a

2429         if (strcmp(policy, LABEL_ACCEPT) == 0)
2430                 c->verdict = -NF_ACCEPT - 1;
2431         else if (strcmp(policy, LABEL_DROP) == 0)
2432                 c->verdict = -NF_DROP - 1;
2433         else {
2434                 errno = EINVAL;
2435                 return 0;
2436         }

Le fil d' origine suggère que la meilleure chose à faire est d'ajouter REJECT à la fin de la chaîne qui devrait l'être iptables -A OUTPUT -j REJECT.

Notez que le code juste avant c'est:

2423         if (!iptcc_is_builtin(c)) {
2424                 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425                 errno = ENOENT;
2426                 return 0;
2427         }
2428

Vous ne pouvez donc pas du tout définir la stratégie sur une chaîne définie par l'utilisateur.

— StarNamer
source

Cette commande dans le thread est incorrecte; -pest pour l'appariement sur un protocole; il voulait dire -Acomme ma réponse le dit.

— Shawn J. Goff

C'est assez intéressant. La curiosité en moi se demande s'il y a une raison derrière cela, ou si c'est juste la façon dont les choses sont, peut-être pour des raisons de simplicité (un code plus simple signifie moins de taches possibles pour les vulnérabilités après tout). Si j'étais même un développeur modéré, je serais peut-être tenté de le pirater localement, mais comme je ne le suis pas, et étant donné que c'est un élément de sécurité, je ne vais pas y toucher.

— ND Geek

2

REJECTon OUTPUTn'a aucun sens; a REJECTrenverra un paquet ICMP qui devra traverser un réseau.

Ajoutez un nouveau -j LOGcomme dernière règle (donc avant la DROPpolitique) pour voir ce qui arrive si loin dans la OUTPUTchaîne.

— Aaron D. Marasco
source

1

Le REJECTpaquet ICMP ne pouvait-il pas revenir sur l'interface lo? Je suis d'accord sur le fait que a LOGest utile pour le dépannage, mais ce que j'espérais vraiment est un moyen de me rappeler que "Oh, oui ... c'est probablement bloqué par mon DROPiptables par défaut" au lieu de dépanner pendant 5 minutes demande à un collègue de accéder au serveur XYZ se rend compte qu'il est probablement local , ce qui est mon approche la plus courante, car ma journée de travail typique touche rarement des choses pour lesquelles je n'ai pas déjà ouvert de trou. Bien sûr, je dois peut-être mieux garder cela à l'esprit, mais un appartement REJECTest plus évident.

— ND Geek

Je ne pense pas que vous souhaitiez que l' ethXinterface génère du trafic sur l' lointerface pour de nombreuses raisons. Ils sont très indépendants; vous pouvez facilement appliquer des chaînes à l'une et non à l'autre.

— Aaron D. Marasco