Effacement règles Iptables

Il y a longtemps que ça ne m’était pas arrivé mais j’ai de nouveau eu cette mauvaise surprise lors de ma sauvegarde hebdomadaire. J’ai rajouté un “iptables-save” à mon script e sauvegarde, ainsi, je contrôle chaque semaine s’il y a modification (fail2ban).
Hier soir, mauvaise surprise, ‘iptables-save’ réduit au strict minimum ... *filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT ...
Vérification de config_parefeu = idem, bein sûr.
J’ai aussitôt rétabli avec ‘iptables-restore’ qui est mis à jour à chaque modif de mon parefeu mais, n’ayant rien fait qui puisse concerner Iptables, ce mystère d’effacement m’interpelle.
Question :
J’aimerais vérifier les logs mais
1/ je ne sais pas lequel peut être concerné ???
2/ quoi mettre comme filtre dans une éventuelle recherche car les fichiers de logs comme ‘messages’ ou ‘système’ sont énormes. je cherche donc un mot-clef.
J’ai oublié de préciser qu’il s’agit de ma machine principale et non de mon serveur, ce dernier étant bien clean.
Tout avis est bienvenu.
:006

La modification des règles iptables n’écrit pas de logs par elle-même. Par contre les règles ne se modifient pas toutes seules, donc quelque chose le fait, et seul ce quelque chose peut éventuellement écrire des logs… ou pas.

Ben c’est bien ce quelque chose qui m’inquiète…
Dans quelle direction chercher ?
J’ai une idée qui pourrait ptet être la cause et je te la soumets :
Mon script de départ, toujours le même, écrit par Matt, même si le fil est à mon pseudo, remet systématiquement, Iptables à nu (ACCEPT pour tout) et passe le relais à config_parefeu.
Ne serait-ce pas mieux, au contraire, que ce script place tout à DROP ?
Pour éviter la lourdeur du message, je te mets le lien du fil
https://www.debian-fr.org/installation-parefeu-iptables-pour-les-nuls-t1901.html

Si je comprends bien, au démarrage de la machine, il ‘restore’ ce qu’il trouve dans /etc/config_parefeu. Mais, ce qui se trouve dans ce fichier est ce qui y a été inscrit lors de la dernière déconnexion .
Ensuite, il met tout “à blanc” avec 'clean’
Tout ça me semble pas très logique.
Peux-tu jeter un œil sur ce script et me dire ce que tu en penses.

Ce n’est pas ce que fait le script de démarrage figurant dans le T&A dont tu fournis le lien. L’action ‘start’ ne fait que restaurer le jeu de règles à partir du fichier /etc/config_parefeu.

Guère d’intérêt dans un sens ou dans l’autre dans la mesure où iptables-restore va tout écraser. Le seul cas où ce serait utile est si le fichier est manquant ou invalide.

Oui, et c’est cette action systématique qui me gêne le plus dans ce script.

Non, le script ne met tout à blanc que s’il est invoqué avec l’argument ‘clean’, ce qui n’arrive jamais au démarrage ni à l’arrêt du système.

Une observation.
Le T&A mentionne la commande suivante pour installer le script de démarrage :

Mais cette syntaxe n’est plus prise en compte si la gestion des dépendances (insserv) est activée, ce qui est le cas par défaut depuis Squeeze au moins. Dans ce cas ce sont les runlevels et les dépendances figurant dans les en-têtes LSB du script qui sont prises en compte. Or les runlevels spécifiés y sont différents de la ligne de commande.

J’y vois deux effets de bord :

  • le pare-feu est activé à l’entrée dans les runlevels normaux (2 à 5) donc après l’activation du réseau qui a lieu dans le runlevel S, ce qui laisse une petite fenêtre de vulnérabilité (sauf si le réseau est configuré par network-manager qui démarre dans les runlevels normaux) ;
  • le script n’est pas exécuté si on démarre en mode “single” (“mode de dépannage” dans le menu de grub) puisque le démarrage s’arrête à la fin du runlevel S, donc les règles ne sont pas mises en place ; en revanche si on redémarre ou arrête le système sans être entré dans un runlevel normal ensuite, le script est exécuté avec l’argument ‘stop’ et enregistre un jeu de règles vide.

Questions :

  • Dans quels runlevels (/etc/rc*.d/) ton script de pare-feu est-il installé ?
  • As-tu récemment démarré en mode single ?

[quote=“PascalHambourg”]…
Questions :

  • Dans quels runlevels (/etc/rc*.d/) ton script de pare-feu est-il installé ?
  • As-tu récemment démarré en mode single ?[/quote]

Je ne pense pas avoir démarré en ‘single’ dernièrement.
Pour les Rc :
Kill :
rc0.d
rc1.d
rc6.d

Start :
rc2.d
rc3.d
rc4.d
rc5.d

EDIT :
Je crois comprendre, d’après ta 1ere question, qu’il y a un certain risque à ouvrir en mode single et qu’il serait souhaitable de vérifier l’état d’Iptables après une telle ouverture ???

Comme prévu ce sont les en-têtes LSB qui prévalent. Attention donc en cas de démarrage en mode single.

Une précision, le contenu du fichier /etc/config_parefeu était-il aussi réduit au minimum ou seulement le jeu de règles actif dans le noyau ?

Je crois que tout était réduit au minimum. :005

Il n’y avait que la table ‘filter’ ou aussi d’autres tables (nat, mangle…) ?
Il n’y avait que les chaînes par défaut ou aussi des chaînes utilisateur (comme celle créée par fail2ban) ?
Tu pourrais fournir ton script pour voir les différences avec celui du T&A ?

[quote=“PascalHambourg”]Il n’y avait que la table ‘filter’ ou aussi d’autres tables (nat, mangle…) ?
Il n’y avait que les chaînes par défaut ou aussi des chaînes utilisateur (comme celle créée par fail2ban) ?
Tu pourrais fournir ton script pour voir les différences avec celui du T&A ?[/quote]
De mémoire, tout était vidé comme après un ‘clean’.
Je voudrais bien recréer ce truc pour le mettre de côté mais est-ce faisable ,
Mon script actuel :
effacé

Je veins de me rendre compte que ce n’est pas ce que tu demandais, je reviens

Le script de init.d

[code]#!/bin/sh

BEGIN INIT INFO

Provides: iptables

Required-Start:

Should-Start:

Required-Stop:

Should-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-description: iptables

Description: Firewall

END INIT INFO

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]

A une ligne vide près, ton script est identique à celui du T&A. Contrairement à ce que tu avais décrit, l’action ‘start’ charge directement le contenu du fichier config_parefeu, sans réinitialiser iptables auparavant.

Justement, après un ‘clean’ toutes les tables doivent être présentes (et vides), pas seulement la table ‘filter’. D’où ma question pour essayer de savoir si un ‘clean’ intempestif peut être à l’origine du problème.

je crois me souvenir que les tables faol2ban n’étaient plus présentes.
Je viens d’essayer de me connecter en mode ‘single’ et je ne peux pas le faire donc il est certain que ce n’est pas là que ça a dû arriver.
Je n’ai plus de ligne ‘single’ sur ce Grub (2.0XXX ?)
Je crois que j’avais dû en supprimer la possibilité car je l’ai sur Ubuntu (même DD)
Je vais rétablir ça.
Pour retrouver l’état, est-ce que je ne pourrais pas tenter de faire un ‘clean’ rapide, le temps de copier iptables-save et de restaurer aussitôt ?
C’est ma machine de travail, pas le serveur et j’ai deux clones récents.

Bien sûr, tu peux faire un ‘clean’, iptables-save et un ‘start’ (mais surtout pas un ‘restart’) qui effacerait le fichier de règles.

Note : si tu n’as pas verrouillé le menu de grub tu peux toujours démarrer en single en éditant la ligne de commande du noyau, en ajoutant ‘single’.

Voilà le résultat après un clean mais il me semble que c’était encore plus succinct que ça ???
Allez, on va aller à la soupe et on verra ça demain.
Merci pour le temps passé :

[code]# Generated by iptables-save v1.4.18 on Sat Jun 8 19:23:38 2013
*filter
:INPUT ACCEPT [15:892]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17:1046]
:fail2ban-apache - [0:0]
:fail2ban-apache-multiport - [0:0]
:fail2ban-ssh - [0:0]
COMMIT

Completed on Sat Jun 8 19:23:38 2013

Generated by iptables-save v1.4.18 on Sat Jun 8 19:23:38 2013

*raw
:PREROUTING ACCEPT [15:892]
:OUTPUT ACCEPT [17:1046]
COMMIT

Completed on Sat Jun 8 19:23:38 2013

Generated by iptables-save v1.4.18 on Sat Jun 8 19:23:38 2013

*mangle
:PREROUTING ACCEPT [15:892]
:INPUT ACCEPT [15:892]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17:1046]
:POSTROUTING ACCEPT [17:1046]
COMMIT

Completed on Sat Jun 8 19:23:38 2013

Generated by iptables-save v1.4.18 on Sat Jun 8 19:23:38 2013

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:60]
:POSTROUTING ACCEPT [1:60]
COMMIT

Completed on Sat Jun 8 19:23:38 2013[/code]

Ouvert en mode single, pratiqué quelques manoeuvres, arrêté la machine, redémarré, vérif iptables-save = normal !
On va attendre la prochaine anomalie et alors, je ne manquerai pas de copier le résultat.
En attendant, je vérifierai iptables-save avant chaque fermeture.
:006
Je ne passe pas en ‘résolu’ mais on oublie pour l’instant.