2 votes

Erreur dans l'application des règles iptables en utilisant iptables-restore

Bonjour, j'utilise Ubuntu 9.04 sur un VPS. J'obtiens une erreur si j'applique une règle iptables. Voici ce que j'ai fait.

1.Sauvegardé les règles existantes

iptables-save > /etc/iptables.up.rules

Créé iptables.test.rules et ajouté quelques règles à celui-ci

nano /etc/iptables.test.rulesnano /etc/iptables.test.rules

Voici les règles que j'ai ajoutées

*filter

 #  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 22- j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

Après l'édition, lorsque j'essaie d'appliquer les règles en

iptables-restore < /etc/iptables.test.rules

J'obtiens l'erreur suivante

iptables-restore : la ligne 42 a échoué

La ligne 42 est commit et si je la commente, j'obtiens

iptables-restore : commit attendu à ligne 43

Je ne suis pas sûr de ce qui est le problème, il attend commit mais si commit est là, il donne une erreur. Est-ce que cela peut être dû au fait que j'utilise un VPS ? Mon fournisseur utilise OpenVZ pour la virtualisation.

0 votes

J'ai essayé de saisir chaque ligne du script ci-dessus manuellement à l'invite. La plupart d'entre elles ont donné lieu à l'erreur suivante "iptables : Aucune chaîne/cible/match de ce nom"

7voto

Drew N Points 51

Très vieux post à ce stade, mais c'est le premier résultat de Google alors j'ai pensé que je mettrais à jour avec ma solution...

Il doit y avoir une ligne vide après commit ou iptables-restore échouera avec une erreur "no command specified" à la ligne où se trouve commit.

1 votes

Ce serait le cas si vous utilisiez un éditeur qui n'ajoute pas automatiquement une nouvelle ligne à la fin de chaque ligne, y compris la dernière.

0 votes

CECI. Je ne peux pas exprimer avec des mots la douleur que ce saut de ligne obligatoire a causé. Merci pour la réponse !

3voto

Ryan Sampson Points 2898

En raison de la façon dont iptables-restore fonctionne, presque toutes les erreurs seront signalées comme étant au niveau du COMMIT point. Les rares fois où j'ai ces erreurs, je vais mettre commits après chaque ligne significative (ou, si je me sens suspicieux, après juste les lignes que je pense pouvoir être le problème) et voir lequel se dégonfle.

Cependant, une brève inspection de vos règles indique que c'est probablement votre problème :

-A INPUT -p tcp -m state --state NEW --dport 22-j ACCEPT

L'absence d'espace entre le 22 y el -j est probablement la cause de la difficulté. "L'attention aux détails échoue", comme disent les jeunes cool.

EDIT : Avec les informations supplémentaires, je vais sortir sur une branche et dire que c'est le problème d'OpenVZ (votre fournisseur de VPS ne vous a pas donné de quota iptables pour ajouter vos propres règles). Je trouverais un nouveau fournisseur de VPS de toute façon, moi-même ; VZ est comme le jouet Fisher Price de la virtualisation. Il a sa place dans les centres de données d'entreprise et dans le segment du marché sensible au prix (0,89 $/décennie), mais pour l'hébergement professionnel de VPS, c'est un chien absolu.

0 votes

Je suis désolé pour l'espace que j'ai accidentellement mis en tapant ici. C'est le script que j'ai utilisé comme référence. articles.slicehost.com/assets/2007/9/4/iptables.txt

0 votes

J'ai essayé d'ajouter les règles à iptables directement à l'invite. Lorsque j'ai exécuté la deuxième ligne, c'est-à-dire iptables -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT, j'ai obtenu l'erreur suivante "iptables : Pas de chaîne/cible/match sous ce nom".

0 votes

Tu as vraiment tapé tout ça à la main ? Je suis sans voix. Qui sait combien de fautes de frappe supplémentaires vous avez ajoutées (je remarque que votre faute de frappe sur le port SSH s'est transformée). Étant donné que ce qui se trouve dans cette URL ne ressemble en rien à votre script, je vous demanderais de mettre exactement ce que vous avez dans votre question afin que nous puissions réellement vous aider. Oh, et vous pourriez vouloir échapper à cette ! sur la ligne de commande. Sinon, Bash s'agite.

1voto

Samat Jain Points 165

Peut-être échoue-t-il à cause du caractère d'espace que vous avez avant commit ?

0 votes

Non, ce n'est pas ça, l'espace est apparu accidentellement lorsque j'ai entré le code ici. A quoi d'autre cela peut-il être dû ?

0 votes

Comment faites-vous pour obtenir un espace au milieu d'un bloc de code collé ? Si ce qui figure dans votre question ne correspond pas à ce que vous avez réellement, modifiez votre question pour la faire correspondre à la réalité.

1voto

leshik Points 11

Un vieux fil de discussion, mais aussi le premier dans les résultats de Google. Peut-être que les informations ci-dessous aideront quelqu'un qui s'arrache les cheveux en essayant de comprendre pourquoi iptables Les règles ne sont pas restaurées au démarrage.

Je suis tombé sur ce problème sur Ubuntu 18.04. Le site netfilter-persistent Le service a échoué de manière aléatoire au démarrage alors qu'il fonctionnait correctement lorsqu'il était lancé manuellement. Il s'est avéré qu'il y avait un conflit avec sshguard service en raison de systemd en essayant de tout charger en parallèle. Ce qui m'a aidé est de mettre ENABLE_FIREWALL=0 en /etc/default/sshguard puis en ajoutant sshguard chaîne et règle manuellement pour /etc/iptables/rules.v4 y /etc/iptables/rules.v6 .

0voto

Je sais que c'est un vieux message, mais il pourrait résoudre le problème de quelqu'un.

J'ai eu la même erreur, et c'est parce que j'ai une faute de frappe.

L'erreur qui a été lancée était dans "commit", la dernière ligne, mais en fait c'était celle-ci :

-A RH-Firewall-1-INPUT -p tcp -m udp --dport 161 -j ACCEPT

L'erreur était qu'il est dit dans la même ligne "tcp" et ensuite "udp". . Donc, changer cette ligne pour :

-A RH-Firewall-1-INPUT -p udp -m udp --dport 161 -j ACCEPT

A résolu mon problème

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X