Upgrade et disparition de iptables

Support Debian
#1

Je viens de mettre à jour ma sid et, par acquis de confiance, je tape un

iptables-save

:cry: retour à l’invite :cry:
heureusement que mes règles sont conservée dans /etc/iptables-save, donc

iptables-restore < /etc/iptables-save

et je retrouve mon parefeu.
Question : est-ce que ça vous est déjà arrivé de voir votre “iptables” disparaître sans que vous ne l’ayez commandé :question:

#2

Ton sujet m’a fait peur, ce n’est pas le programme iptables qui a disparu mais seulement ses tables dans le noyau. Car si iptables-save n’afficher rien, cela signifie que les modules gérant ces tables (iptable_filter, iptable_mangle, iptable_nat, iptable_raw) ne sont pas chargés. Vidanger les règles ne serait pas suffisant, il resterait les politiques par défaut des chaînes prédéfinies. Chacun de ces modules est automatiquement chargé lorsqu’on exécute une commande iptables dans la table correspondante. Tu as redémarré le système entre la mise à jour et le moment où tu as exécuté iptables-save ?

Pour répondre à ta question : non ça ne m’est jamais arrivé, mais je n’utilise pas sid. :stuck_out_tongue:

#3

[quote=“PascalHambourg”] Tu as redémarré le système entre la mise à jour et le moment où tu as exécuté iptables-save ?
[/quote]
Ben je crois que oui mais pas sûr à 100%.
En général, quand je mets à jour (3 ou 4 fois / mois), je redémarre toiujours la machine pour voir si je n’ai pas de problèmes.
depuis, j’ai éteint/redémarré deux fois et iptables-save répond bien de nouveau :unamused:
Je tente la même expérience sur mon autre machine pour comparer et je reviens donner la réponse en “edit”

EDIT :
Idem avec le PC bureau.
J’avais mis à jour cet aussitôt après l’autre mais je n’avais pas vérifié. Ben pas de retour à iptables-save :cry:
Réparé facilement avec iptables-restore mais faut y penser.

Tu as une explication Pascal :question:

Estce que le warning suivant peut avoir une incidence :
"All config files need .conf: etc/modprobe.d/nvidia-kernel-nkc, it wil be ignored in a future release"
Cette ligne est apparue sitôt après ma commande de “restore” sur le PCbureau qui est Nvidia, lui.

#4

Tu veux dire qu’au redémarrage qui suit la mise à jour les règles iptables ne sont pas recréées mais le sont aux redémarrages suivants ? Non, je n’ai pas d’explication. Tu n’as pas eu de message d’erreur lié à iptables au démarrage ? Par quel mécanisme tes règles iptables sont-elles créées au démarrage ?

Je ne pense pas que le warning soit lié, je doute qu’un fichier nommé nvidia-kernel-nkc ait un rapport avec iptables (mais tu peux regarder dedans pour vérifier). AMA il vient de modprobe qui est invoqué par iptables-restore pour charger les modules netfilter et iptables nécessaires au jeu de règles.

#5

Non, aucun message !
J’attends encore quelques jours, en vérifiant chaque jour que

iptables-save

réponde bien
ensuite, je referai un essai de mise à jour, en vérifiant ce qu’il en est avant de rebouter et après reboute.
Je te tiendrai au courant.

#6

Retour sur ce sujet !

iptables-save

retour à l’invite :cry:

Ça vient de me le refaire ce matin et poutant, je n’ai pas, ni updaté, ni upgradé depuis 3 jours.
C’est vraiment un mystère, cette disparition ???
J’ai restauré avec

iptables-restore < /etc/iptables-save

et c’est redevenu “normal”,

iptables-save

me donne toutes mes règles.
Le script (dans /etc/init.d/mon_parefeu) est le suivant :

[code]#!/bin/sh

chargement/déchargement d’iptables

case “$1” in
’start’)
/sbin/iptables-restore < /etc/config_parefeu
RETVAL=$?
;;
‘stop’)
/sbin/iptables-save > /etc/config_parefeu
RETVAL=$?
;;
‘clean’)

clean le parefeu pendant que la machine tourne

ça peut être une faille de sécurite si on l’exécute lors de l’extinction avant l’arrêt des interfaces

pensez à refaire un start après sinon la sauvegarde se fera automatiquement à l’extinction

/sbin/iptables -t filter -F
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -t raw -F
/sbin/iptables -t filter -P INPUT ACCEPT
/sbin/iptables -t filter -P OUTPUT ACCEPT
/sbin/iptables -t filter -P FORWARD ACCEPT
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P PREROUTING ACCEPT
/sbin/iptables -t mangle -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P POSTROUTING ACCEPT
/sbin/iptables -t mangle -P FORWARD ACCEPT
/sbin/iptables -t mangle -P INPUT ACCEPT
/sbin/iptables -t raw -P OUTPUT ACCEPT
/sbin/iptables -t raw -P PREROUTING ACCEPT
RETVAL=$?
;;
‘restart’)
$0 stop && $0 start
RETVAL=$?
;;
*)
echo "Usage: $0 { start | stop | restart | clean}"
RETVAL=1
;;
esac
exit $RETVAL
[/code]

et mes règles (dans /etc/config_parefeu) :

[code]# Generated by iptables-save v1.4.4 on Sat Aug 8 12:18:33 2009
*filter
:INPUT DROP [23:1604]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2056:449693]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 31336 -j ACCEPT
-A INPUT -j LOG
-A INPUT -s 192.168.0.0/24 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
COMMIT

Completed on Sat Aug 8 12:18:33 2009

Generated by iptables-save v1.4.4 on Sat Aug 8 12:18:33 2009

*nat
:PREROUTING ACCEPT [6:2231]
:POSTROUTING ACCEPT [18:1093]
:OUTPUT ACCEPT [278:19081]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Completed on Sat Aug 8 12:18:33 2009

Generated by iptables-save v1.4.4 on Sat Aug 8 12:18:33 2009

*mangle
:PREROUTING ACCEPT [1725:1015521]
:INPUT ACCEPT [1693:1008879]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2056:449693]
:POSTROUTING ACCEPT [2065:452224]
COMMIT

Completed on Sat Aug 8 12:18:33 2009

Generated by iptables-save v1.4.4 on Sat Aug 8 12:18:33 2009

*raw
:PREROUTING ACCEPT [1725:1015521]
:OUTPUT ACCEPT [2056:449693]
COMMIT

Completed on Sat Aug 8 12:18:33 2009

[/code]

On a l’impression que init.d n’est pas lu au boute ???

J’y pense à l’instant, hier, j’ai eu une vérification de la partition ‘/’ au boute, comme toutes les 50 connexions.
N’y aurait-il pas un rapport :?:

#7

ton script /etc/init.d/mon_parefeu a t’il un lien dans /etc/rc2.d/ lui disant de le lancer au démarrage?sinon effectivement il a beau etre dans /etc/init.d c’est normal qui ne soit pas exécuter au boot

A mon avis non et ça expliquerais que tu te retrouve avec un parefeu vierge comme les règles iptables sont stockées en mémoire vive

#8

Oui, j’ai bien ce lien et il reprends (bien sûr :smt003 ) le fichier /etc/init.d/mon_parefeu.
S20mon_parefeu

... case "$1" in 'start') /sbin/iptables-restore < /etc/config_parefeu RETVAL=$? ...

#9

Ricardo :
C’est arrivé après un (re)démarrage ?
Est-ce que /etc/config_parefeu ne serait pas vide quand ça arrive ?
Pour la prochaine fois tu pourrais créer un log pour vérifier si ton script s’exécute, avec ou sans erreur.

ReNzO_08 :
Je mettrais plutôt le lien dans /etc/rcS.d/ afin que les règles soient actives avant l’activation des interfaces réseau par /etc/rcS.d/S40networking.

#10

[quote=“PascalHambourg”]Ricardo :
C’est arrivé après un (re)démarrage ?
Est-ce que /etc/config_parefeu ne serait pas vide quand ça arrive ?[/quote]
Je vérifie (maintenant) chaque jour avec iptables-save et si bon, je vérifie aussi ‘config_parefeu’.
Quand iptables-save répond, config_parefeu et plein
mais quand iptables-save retourne à l’invite directement, config_parefeu est, lui aussi, VIDE.
Ça paraît logique mais maintenant, je vérifierai en premier config_parefeu, si jamais c’était la commande ‘iptables-save’ qui provoquait son “vidage”.

“créer” un log ? comment je fais ça :question:
À moins que tu veuilles dire “vérifier” les logs (lesquels ?)
Merci de ton aide.

#11

Complètement vide (zéro caractère), pas même les lignes du début avant les règles du style de ce qui suit ?

*filter :INPUT DROP [23:1604] :FORWARD DROP [0:0] :OUTPUT ACCEPT [2056:449693]

iptables-save elle-même, je ne vois pas comment. A moins que tu veuilles dire quand elle est appelée par ton script avec la commande stop ?

[quote=“ricardo”]
“créer” un log ? comment je fais ça :question:[/quote]
En fin de script tu écris quelques informations dans un fichier par exemple :

Comme ça pour chaque invocation tu auras la date, la commande (start, stop…), et le code résultat.

#12

Entièrement vidé = 0 octet

#13

Log créé, résultat = 0
Qu’y aura-t-il quand ça ne passera pas :question:

Sun Aug 9 17:02:04 CEST 2009 stop 0 Sun Aug 9 17:03:11 CEST 2009 start 0

#14

Ce serait plus pratique si tu disais à quelle(s) action(s) de ta part correspondent ces événements. Je suppose que tu as fais un reboot ?

Qu’y aura-t-il quand ça ne passera pas ? Ce sera la surprise. Si je le savais, je ne te ferais pas perdre ton temps à vérifier par toi-même, je ne suis pas pervers à ce point.

Je ne vois pas 50 explications possibles à ce que le fichier config_parefeu se retrouve complètement vide.

  • Soit iptables-save plante pour une raison que j’ignore lors du stop et sa sortie est vide. Dans ce cas le code résultat dans le log devrait être différent.
  • Soit iptables-save fonctionne lors du stop bien mais sa sortie est vide. Pour autant que je sache, effacer toutes les règles et chaînes utilisateur comme le fait la commande “clean” de ton script ne suffirait pas pour obtenir ce résultat : il resterait les tables et les politiques par défaut. Une sortie complètement vide signifie que les tables elles-mêmes et les modules noyau correspondants iptable_ ne sont pas ou plus chargés.
  • Soit quelque chose d’autre écrase le fichier config_parefeu entre la sauvegarde et la restauration des règles, mais quoi ? La date de modification du fichier peut éventuellement donner une indication.

    • Il y a peut-être (sûrement) d’autres explications, mais je ne vois pas lesquelles pour le moment. En tout cas si c’était iptables-restore qui plantait au start, le fichier config_parefeu ne serait pas vide jusqu’au stop (ensuite il le serait, forcément).

#15

Merci de ces explications, je surveillerai systématiquement tous ces fichiers à chaque connexion.
pour l’explication des logs, la voici :

Un vrai mouchard ce script :mrgreen: