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.
À 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 ;)
Si perte du ssh le shell se coupe … donc … à faire dans un screen :)
Pour la fermeture de shell : tmux !
Arrêtez d’être tous d’accord comme ça.
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 :-))
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)
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.
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 whetherthe 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.
OOOOh. Merci à tous.
Tester du iptables en prod? o_0
Autant faire des regexp pour parser du HTML !
Nicolas Hennion a proposé ça : http://blog.nicolargo.com/2013/06/ma-methode-pour-gerer-les-regles-iptables.html
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).
C’est drôle, Nico Largo a proposé une solution pour ça il y a quelques jours: http://blog.nicolargo.com/2013/06/ma-methode-pour-gerer-les-regles-iptables.html
Mais lui il a carrément fait un script qui s’occupe de toute sa gestion des règles IPtable, qui inclut une partie test.
Un chouia plus compliqué, mais une fois que c’est mis en place, ça devient enfantin de faire des tests sans se bruler les doigts.
Oui ! (enfin je crois)
Bref il faut juste utiliser “screen” avant de commencer a travailler
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 :
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.@e-Jim: c’est chez lui que j’ai piqué le truc. Merci d’avoir retrouvé la source.
Il y a plus simple non ?
Par exemple :
echo « /sbin/iptables -F » | at now+3min
Source : http://www.secuip.fr/linux/tester-les-regles-diptables-sans-prendre-de-risque
Si, mais uniquement quand SSH aura “timeouté”. Le plus prudent est de lancer ça dans un screen ou tmux.