Salut tout le monde,
je vous écris parce que hier soir j'ai fait exactement ce qu'il ne fallait pas faire. En modifiant un script fait-maison avec les règles d'iptables, j'ai malencontreusement décommenté un commentaire qui était placé entre le moment où le script interdit l'accès à toutes les chaines ("policies" à DROP) et le moment où les règles ouvrent explicitement certains ports (80, 22, 21, 25, 53, ...)
Bref, la catastrophe a été de taille quand j'ai lancé le script et il s'est lamentablement vautré sur le commentaire décommenté. Les facteurs aggravants étaient nombreux :
- serveur à 2h30 de chez moi
- c'est arrivé exactement 20 minutes après l'avoir passé en prod et y avoir installé quelques sites. Les proprietaires de ces sites (qui payent!) venaient à peine de recevoir un mail en confirmant la bonne mise en route de leurs sites !
- c'était un dimanche soir, donc pas de technicien sur place avant lundi matin
- pas de prise electrique controllable à distance pour faire un reboot
J'en viens enfin à ma question : existe-t-il un moyen, une astuce, une formule magique, un mantra à se répéter 15 fois par jour,... pour éviter que ce genre de choses n'arrive ?
Mes réponses personnelles :
- pendant le test du firewall (quand il n'était pas en prod), j'avais mis dans la crontab un script qui se lançait toutes les 15 minutes et réinitialisait les règles du firewall en acceptant tous les paquets
- prise electrique controllable à distance et pas de lancement automatique au démarrage du firewall
Idées personnelles :
- Quelqu'un aurait-il par exemple songé à un petit script qui monitore le trafic entrant/sortant et qui soit capable de detecter une panne au niveau du firewall si le trafic s'arrete subitement pendant un temps prédeterminé ?
- Et qu'en diriez-vous d'un script sur le serveur qui vérifie la présence d'un certain fichier sur un compte ftp et qui réinitialise le firewall en présence de ce fichier ? Evidemment ça serait une atteinte à la sécurité et il faudrait que le firewall autorise au moins, par défaut, les paquets sortants et ceux entrants qui ont un rapport avec ceux sortants ("state filter", established/related). Mais le jeu en vaut peut-être la chandelle ?
Voilà, en attendant que les techniciens s'activent, je fais appel à vos experiences ! :)
Forum général.général Amadouer iptables, ou comment ne pas s'interdire l'accès à son propre serveur !
25
oct.
2004
# Et pourquoi pas ...
Posté par snt . Évalué à 4.
Ou alors tant qu'on est dans le trip solution-tordue, je te propose un cron qui interroge une boite pop régulierement pour en tirer eventuellement un nouveau fichier de config du firewall et qui le met en place si il est correctement signé electroniquement par toi.
[^] # Re: Et pourquoi pas ...
Posté par Dario Spagnolo (site web personnel) . Évalué à 2.
Effectivement le coup du mail signé est alambiqué mais devrait fonctionner et reste secure...
[^] # Re: Et pourquoi pas ...
Posté par GCN (site web personnel) . Évalué à 5.
Dans ton cas, tu touches à IPTables... Donc, tu ne peux en aucun cas faire confiance à un quelconque mécanisme mettant en oeuvre le réseau...
Que se passe-t-il si ta machine est bloquée et ne laisse plus passer aucun type de trafic (entrant, sortant, ...) ? Adieux le POP3 (et le FTP aussi d'ailleurs)...
A mon avis, le mieux reste encore une sauvegarde du script avant modification puis, avec at ou cron tu programmes l'exécution de l'ancien script dans X minutes. Tu testes tes nouvelles règles et, si tout est bloqué, tu sais que at ou cron va débloquer la situation en exécutant l'ancien script d'ici X mins.
Là au moins, ça ne fait pas appel au réseau et ça à plus de chances d'aboutir :).
[^] # Re: Et pourquoi pas ...
Posté par Dario Spagnolo (site web personnel) . Évalué à 2.
Mais ça me fait penser à une procédure relativement infaillible :
- avant toute modification (même en prod) du le script du firewall, je remets en place le script cron de secours
- je fais ma modif
- si tout se passe bien je désactive le script cron
- sinon j'attends les 15 minutes et je recommence...
C'est simple, non ? Quels seraient les inconvénients ?
Remarque, c'était peut-être ce que tu proposais FixXxeR :) Loin de moi l'idée de vouloir t'enlever le merite !
[^] # Re: Et pourquoi pas ...
Posté par bergamote23 . Évalué à 1.
Le jour où tu testes un nouveau script iptables, si ca se passe mal, cron remettra les regles par defaut.
Si ca se passe bien, tu remplace les regles par défaut par le nouveau script que tu a testé avec succès.
En fait, cron serais utillisé pour mettre en place toutes les 30 minutes, la dernière version stable de ton script. Dès qu'un script de "test" est jugé "stable", tu dis a cron que désormais, c'est ce script qu'il faut lancer toutes les 30 minutes.
Le seul problème, c'est que meme sit tu ne touche pas a ton script pendant 6 mois, cron continuera de le lancer toutes les 30 minutes. mais est ce vraiment un problème.
C'est ce que je fais depuis un moment, et ca se passe très bien...
# Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par moudj . Évalué à 2.
> Mes réponses personnelles :
> - pendant le test du firewall (quand il n'était pas en prod), j'avais mis dans la crontab un script qui se lançait toutes les 15 minutes et réinitialisait les règles du firewall en acceptant tous les paquets
oui.
mais question bête.
si cela t'es arrivé, c'est que tu relances le script à chaque fois.
pourquoi ne travailles-tu pas à coups d'insert et de delete ?
le risque de planter ton firewall son quand même moindre dans ce cas...
> - prise electrique controllable à distance et pas de lancement automatique au démarrage du firewall
heu... c'est pas un peu bourrin ?
franchement, je préfère le coup d'un script qui t'ouvres l'accès ssh :-)
> Idées personnelles :
> - Quelqu'un aurait-il par exemple songé à un petit script qui monitore le trafic entrant/sortant et qui soit capable de detecter une panne au niveau du firewall si le trafic s'arrete subitement pendant un temps prédeterminé ?
donc ça c'est pour un plantage de quoi ? des régles ? de la machine ? c'est pas vraiment clair là...
> - Et qu'en diriez-vous d'un script sur le serveur qui vérifie la présence d'un certain fichier sur un compte ftp et qui réinitialise le firewall en présence de ce fichier ? Evidemment ça serait une atteinte à la sécurité et il faudrait que le firewall autorise au moins, par défaut, les paquets sortants et ceux entrants qui ont un rapport avec ceux sortants ("state filter", established/related). Mais le jeu en vaut peut-être la chandelle ?
je comprends pas là....
en gros, tu plantes tes règles, donc t'envoies un fichier par ftp, et si le cron détecte le fichier il réinitialise les règles ?
heu... question bête... si ton plantage de règles équivaut à un DROP ALL ;-) tu fais comment pour l'envoyer ton fichier ??
> Voilà, en attendant que les techniciens s'activent, je fais appel à vos experiences ! :)
par expérience : le script en cron quand on bosse sur le firewall et bosser à coups d'insert et de delete plutôt que de travailler directement sur le script et être obliger de le relancer en entier à chaque fois...
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par Dario Spagnolo (site web personnel) . Évalué à 1.
> mais question bête.
> si cela t'es arrivé, c'est que tu relances le script à chaque fois.
> pourquoi ne travailles-tu pas à coups d'insert et de delete ?
> le risque de planter ton firewall son quand même moindre dans ce cas...
Parce que là je n'étais plus en test, j'étais en prod, je savais exactement ce que je devais faire : ouvrir le port 53 suite à l'installation d'un serveur DNS. Bon évidemment, il y en aura toujours pour dire qu'on ne fait pas ça sur un serveur en prod, mais je n'avais pas le choix ! Donc tout ça pour dire que j'étais sur de ma manip, il fallait que je fasse copier-coller de la derniere ligne et que je modifie le numero du port...
Ce que tu me proposes toi est une bonne idée pour faire des tests... Genre, voir si cette règle fonctionne, je l'ajoute à la main et les dégats sont limités si ça marche pas. Quoique, dans ces cas là je prefere encore la technique du firewall réinitialisé automatiquement toutes les 15 minutes.
Mais tu ne veux tout de même pas que je me tape une trentaine de commandes iptables à la main à chaque lancement de la machine, si ? Même si elle doit être redemarrée une fois tous les 3 mois, ça me parait long et d'autres erreurs peuvent être commises de cette façon...
> - prise electrique controllable à distance et pas de lancement automatique au démarrage du firewall
Oui c'est très bourrin, mais je ne devrais pas m'en servir tous les jours... Mais au moins je sais que la solution est là ! :)
> donc ça c'est pour un plantage de quoi ? des régles ? de la machine ? c'est pas vraiment clair là...
Oui, ça c'était pour surveiller un plantage des règles... Parce qu'en gros je me dis, si le serveur était un minimum doué d'intelligence (!) il devrait se poser des questions en voyant qu'il a toujours parfaitement accès au net (paquets sortants autorisés) mais que tout à coup plus personne ne vient chez lui...
> heu... question bête... si ton plantage de règles équivaut à un DROP ALL ;-) tu > fais comment pour l'envoyer ton fichier ??
Je pensais à un serveur ftp externe...
Même si je n'ai pas trouvé une réponse à mon problème, je te remercie de tes conseils, ça aide à réfléchir et à trouver des solutions :)
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par moudj . Évalué à 2.
en tests, c'est pas grave de planter la machine.
la situation que j'évoque ici est pour un serveur en prod.
> Donc tout ça pour dire que j'étais sur de ma manip, il fallait que je fasse copier-coller de la derniere ligne et que je modifie le numero du port...
vi mais tu t'es pris les pieds dans la tapis ;-)
avec un insert, tu testes.
Si ça fonctionne, tu rajoute ta ligne dans le script.
Si ça fonctionne pas, un delete, et hop, t'essayes autre chose...
> Mais tu ne veux tout de même pas que je me tape une trentaine de commandes iptables à la main à chaque lancement de la machine, si ?
non :-)
l'insert c'est pour tester.
si ça marche, tu rajoutes tes lignes dans le script.
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par Dario Spagnolo (site web personnel) . Évalué à 1.
Je teste ma ligne à la main... Ca marche nickel. J'ouvre le script, j'insere ma ligne, mais comme j'ai les doigts lourds je fais une erreur de syntaxe bash... Paf, le script se vautre exactement comme ça m'est arrivé...
Ok c'est de ma faute, je suis un gros nul, tout ce que tu veux... Mais moi je cherche justement une solution à preuve de gros nuls parce que l'erreur est humaine et si on ne laisse pas de place à l'erreur on va droit dans un mur :) Le risque zéro est une invention des hommes en costard cravate qui n'a rien à voir avec la vie réelle...
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par moudj . Évalué à 2.
ok :-)
> Je teste ma ligne à la main...
d'accord
> Ca marche nickel.
là, t'es content :-)
> J'ouvre le script,
ah non.
avant, tu as fait un copie du script : cp /etc/init.d/firewall /etc/cron.hourly/firewall
comme ça, si t'as les doigts lourds, tu récupères la situation précédente 1 heure après.
c'est un petit détail qui t'évites de perdre la main.
faut toujours faire une copie quand on bosse sur un fichier ;-)
> j'insere ma ligne,
ok
> mais comme j'ai les doigts lourds je fais une erreur de syntaxe bash... Paf, le script se vautre exactement comme ça m'est arrivé...
oui mais tu as fait une copie dans /etc/cron.hourly, donc 1 heure après tu récupères la situation précédente.
héhé ;-)
> Ok c'est de ma faute,
un peu :-p
> je suis un gros nul,
meuh non !
> tout ce que tu veux... Mais moi je cherche justement une solution à preuve de gros nuls parce que l'erreur est humaine et si on ne laisse pas de place à l'erreur on va droit dans un mur :) Le risque zéro est une invention des hommes en costard cravate qui n'a rien à voir avec la vie réelle...
:-)))
1. tu fais un script qui regarde dans cron.hourly si le script firewall est présent.
si ce script est présent, il l'active toutes les heures,
s'il n'est pas présent, c'est que tu n'es pas en train de bosser sur le firewall.
2. avant quelque modif que ce soit, tu copies le script de règles qui fonctionne dans :
/etc/cron.hourly
3. tu fais tes modifs à coups d'insert ou de delete.
j'ai un terminal avec cat > /dev/null ouvert en permanence pour les copier/coller
ça marche plutôt bien
4. tu modifies ton script de règles si tes insert fonctionnent.
5. tu relances
6. ça marche ? tu vires /etc/cron.hourly/firewall
voilou :-)
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par Dario Spagnolo (site web personnel) . Évalué à 1.
Ca rejoint donc ce que j'avais écrit ici : http://linuxfr.org/comments/489077.html#489077(...)
Merci ! Dès que je reprends la main sur le serveur je mets ça en place...
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par moudj . Évalué à 2.
ah oui, au temps pour moi :-)
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par Ph Husson (site web personnel) . Évalué à 0.
Tu fais ton iptables insert a la main
apres iptables-save > iptables
et apre a chaque reboot iptables-restore < iptables
Et roule ma poule :p
[^] # Re: Pourquoi "amadouer iptables" ? le problème ne vient pas de là ;-)
Posté par moudj . Évalué à 2.
bon, comme je ne les modifie pas par paquet de 30, c'est vrai que je fais plutôt ça à la main :-)
# Shorewall
Posté par GCN (site web personnel) . Évalué à 3.
=> http://shorewall.net/starting_and_stopping_shorewall.htm(...)
La commande "shorewall try" permet de tester diverses configuration avec un mécanisme de "fallback" vers la dernière configuration fonctionnelle connue.
[^] # Re: Shorewall
Posté par Dario Spagnolo (site web personnel) . Évalué à 1.
Je me dis que la configuration d'un firewall, quand on connait le fonctionnement d'iptables, est une chose très facile et très délicate. Ce qui me pousse à mettre en place des solutions simples (30 lignes en bash), facilement verifiables si quelque chose ne fonctionne pas comme il devrait et entièrement sous mon controle...
Il faut toujours, par contre, prévoir une solution de fallback car l'erreur est humaine !
[^] # Re: Shorewall
Posté par Maillequeule . Évalué à 2.
Connaitre iptables c'est à la portée de tout le monde.
Construire des règles cohérentes et efficaces c'est autre chose.
(Je ne dis pas que les tiennes ne le sont pas)
M
# Un réseau privé d'admin
Posté par mac . Évalué à 2.
De cette facon, en cas de plantage sur les règles de FW, ou de tout autre bricolage sur l'interface primaire, j'ai toujours une route de secours par une interface secondaire (en rebondissant sur une autre machine).
Ca aide (mais pas toujours).
Olivier
P.S on peut aussi jouer avec des cables série sur le port console, c'est pas cher et ça marche même si la couche IP du serveur est HS
[^] # Re: Un réseau privé d'admin
Posté par Dario Spagnolo (site web personnel) . Évalué à 1.
Merci en tout cas, quand j'aurai plus d'un serveur, je le ferai surement :)
# Sleep
Posté par Arnaud Da Costa . Évalué à 1.
iptables-restore < fichierdetest ; sleep 20 ; iptables-restore < fichierminimal
(ne pas remplacer les ";" par des "&&" s'il y a une erreur dans les règles, gros problèmes)
De cette facon, j'ai 20 secondes maximum de coupure si je fait une connerie.
[^] # Re: Sleep
Posté par Damien Metzler . Évalué à 1.
at now + 1 minutes -c "iptables-restore < fichierminimal"
Je suis plus sur de la syntaxe, mais ça doit marcher
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.