Tester une règle IPtable


Je ne sais plus du tout où j’ai lu ça, mais vu le nombre de fois où je me suis fais connement kické de mon serveur parce que j’ai joué avec iptable et ai coupé mon accès SSH, je partage.

En gros, on fait comme votre OS quand vous changez la résolution de l’écran : on attend 30 secondes et on remet la configuration précédente :

sudo iptables-save > /etc/iptables.bak && sudo iptables votre_nouvelle_regle && sleep 30 && sudo iptables-restore < /etc/iptables.bak

N’oubliez pas que le dernier sudo ne marchera pas si votre sleep dure trop longtemps (je crois que sudo ne demande pas le password dans les 5 minutes qui suivent la dernière commande avec sudo) donc n’augmentez pas trop ce chiffre.

Bon, warning, je l’ai pas encore testé (si la connexion se coupe, est-ce que le shell se ferme pas ?), donc c’est juste là pour l’inspiration.

18 thoughts on “Tester une règle IPtable

  • Cocotte

    À priori, IPTables ne coupera pas la connexion TCP (il empêchera juste les nouveaux paquets de le traverser). Donc si le temps où la règle bloque la connexion est inférieur au timeout de ssh (désactivable, et de toutes façons assez long par défaut), tu devrais te retrouver sur ton shell sans soucis ;)

  • beastie

    Si le shell tourne dans un screen/tmux, il reste vivant même après déconnexion.
    Le timeout de sudo est de 15 minutes par défaut, sauf si on s’amuse à le changer dans le fichier de conf (et si on fait ça, c’est qu’on sait ce qu’on fait :-))

  • Cocotte

    Haha,
    Bon alors je confirme et certifie : tant que le timeout de SSH n’a pas lieu, tu retrouveras toujours ton shell dès que iptables arrêter de bloquer les paquets.

    et c’est logique, tant que le processus de ssh tourne (pas le daemon, mais le processus (ou thread, à vérifier) qui est lancé lorsque tu te connectes sur le serveur, et le processus sur ton client, la connexion tcp existe (et netfilter ne la coupera pas même si tu ajoutes une règle iptables qui empêche les paquets de passer).

    d’ailleurs j’ai dis une connerie sur mon post précédent, je crois pas qu’il y ait un timeout par défaut sur ssh en fait (par contre, il est possible d’ajouter une directive qui force l’envoi d’un message toutes les x secondes, dans le cas où on passe par un parefeu qui coupe les connexions tcp actives où aucun échange n’a été fait plus d’un certain temps)

  • Cocotte

    une façon très simple de me montrer c’est de mettre un serveur dans une vm, de s’y connecter de l’hôte, et de s’amuser avec iptables sur la vm.

  • Gauthier Monserand

    Déjà fait :

    man iptables-apply

    iptables-apply will try to apply a new ruleset (as output by iptables-save/read by iptables-restore) to iptables, then prompt the user whether
    the changes are okay. If the new ruleset cut the existing connection, the user will not be able to answer affirmatively. In this case, the
    script rolls back to the previous ruleset after the timeout expired. The timeout can be set with -t.

  • N

    Tester du iptables en prod? o_0
    Autant faire des regexp pour parser du HTML !

  • Encolpe Degoute

    Sauf que si quelque chose se passe mal, la sérialisation des instructions avec ‘&&‘ va faire planter l’ensemble. Il vaut mieux utiliser le ‘;‘ pour séparer les instructions ou faire un script un poil plus compliqué.
    L’utilisation de nohup, screen ou un équivalent est recommandé sur les accès distants dans tous les cas (un routeur qui lâche pendant n’importe qu’elle commande peut avoir des conséquences fâcheuses).

  • jptuzc

    si la connexion se coupe, est-ce que le shell se ferme

    Oui ! (enfin je crois)
    Bref il faut juste utiliser “screen” avant de commencer a travailler

  • thican

    Salut,

    Bonne idée, j’aime bien, 2-3 fois ça m’aurait bien sauvé la mise, plutôt que de forcer le hard reboot du serveur distant par l’interface web.

    Pour le problème avec sudo, il y a une solution : utiliser “su -c, – -commande COMMANDE”

    Ça donne donc :

    sudo su --commande 'iptables-save > /etc/iptables.bak && iptables votre_nouvelle_regle && sleep 30 &amp;&amp; iptables-restore < /etc/iptables.bak'

    Et voili-voilou :-)

    PS : oui, j’ai mis un espace _volontaire_ entre les 2 traits d’union, car WordPress les transforme en –. Maudit soit-il.

  • Sam Post author

    @e-Jim: c’est chez lui que j’ai piqué le truc. Merci d’avoir retrouvé la source.

  • atome

    est-ce que le shell se ferme pas ?

    Si, mais uniquement quand SSH aura “timeouté”. Le plus prudent est de lancer ça dans un screen ou tmux.

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.