Projet

Général

Profil

Tâche #18328

Distribution EOLE - Scénario #20100: Assistance aux utilisateurs (16-18)

Reproduire le problème d'altération de l'application des regles de pare-feu au démarrage du service bastion

Ajouté par Jean-Marc MELET il y a plus de 7 ans. Mis à jour il y a presque 7 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
Distribution EOLE - sprint 2017 16-18 Equipe MENSR
Début:
09/12/2016
Echéance:
% réalisé:

100%

Temps estimé:
3.00 h
Temps passé:
9.50 h
Restant à faire (heures):
0.0

Description

Mise en place d'une architecture de test :
  • 2 gateways
  • un serveur Amon 2.5.2 configuré avec l'agrégation

Comme je l'évoquais sur la liste de diffusion, je n'ai malheureusement pas pu le proposer à temps pour la sortie de la maj du 23/11 mais en lien avec https://dev-eole.ac-dijon.fr/issues/17579 nous nous sommes aperçu d'un conflit un peu du même ordre.
Nous avons remarqué que l'arret/démarrage/relance du service bastion peut ne pas générer correctement certaines regles, en particulier pour la chaine POSTROUTING de la table nat. Il y a parfois des différences dans l'application des regles de NAT qui semblent attribués à un traitement trop rapide dans les différentes étapes au lancement du service bastion. Nous avions justement pensé à des interférences avec l'activité de agent rvp, mais d'apres nos tests il y a une autre source de perturbation. Nous n'en avons pas identifié précisément l'origine mais on pense à une interaction avec la relance des services d'agrégation et/ou rvp par le script, peut-être la phase de flush des SNAT du script d'agrégation qui se fait avant ou pendant la génération des regles SNAT de lance.firewall.

En tour cas il s'est avéré que le fait de mettre un timer (5 secondes suffisent à priori) dans le script /etc/init.d/bastion avant les phases du lancement de l'agrégation et de RVP permet d'éviter ce comportement indésirable.

En PJ un exemple des regles appliquées aprés différentes relances du service bastion (ne pas tenir compte des regles "-A POSTROUTING -s 10.4.201.0/25 -d 10.104.201.240/28 -o eth0 -j SNAT --to-source 10.104.201.245", c'est une modif académique pour éviter que le réseau de destination pour la zone d'interco externe ne parte dans les tunnels)

Exemple regles bastion.txt Voir (5,3 ko) Jean-Marc MELET, 09/12/2016 17:37

bastion restart.txt Voir (11,8 ko) Jean-Marc MELET, 07/04/2017 18:14

bastion restart-time.txt Voir (3,04 ko) Jean-Marc MELET, 07/04/2017 18:15

bastion-modules (128 octets) Jean-Marc MELET, 07/04/2017 18:18

agregation.conf Voir (1,83 ko) Jean-Marc MELET, 07/04/2017 18:18

hosts.allow (210 octets) Jean-Marc MELET, 07/04/2017 18:18

inclusion_statique (2,27 ko) Jean-Marc MELET, 07/04/2017 18:18

ipset (1006 octets) Jean-Marc MELET, 07/04/2017 18:18

iptables (25,1 ko) Jean-Marc MELET, 07/04/2017 18:18

5zones-AixMars.xml Voir (52,1 ko) Jean-Marc MELET, 10/04/2017 18:35

config.eol (10,6 ko) Jean-Marc MELET, 10/04/2017 18:35

Historique

#1 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Statut changé de Nouveau à En attente d'informations
  • Assigné à mis à Fabrice Barconnière
As-tu remarqué si ça se produit à un moment précis ?
  • au moment du logrotate par exemple (vers 6h25)
  • avec un service bastion restart ?
  • avec un service bastion stop suivi d'un service bastion start ?

#2 Mis à jour par Jean-Marc MELET il y a plus de 7 ans

Oui bien sûr, j'ai reproduit lors de la relance de bastion à la main mais en effet c'est bien lors du logrotate que cela peut se produire automatiquement

#3 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

De quelle façon la relance :
  • restart ou stop + start ?

#4 Mis à jour par Jean-Marc MELET il y a plus de 7 ans

Oupsss pardon j'ai zappé de répondre à cette question.
Oui cela se produit à la fois pour un stop + start et un restart

#5 Mis à jour par Fabrice Barconnière il y a plus de 7 ans

  • Tracker changé de Demande à Tâche
  • Sujet changé de Altération possible de l'application des regles de pare-feu au démarrage du service bastion à Reproduire le problème d'altération de l'application des regles de pare-feu au démarrage du service bastion
  • Description mis à jour (diff)
  • Statut changé de En attente d'informations à Nouveau
  • Temps estimé mis à 3.00 h
  • Tâche parente mis à #18394
  • Restant à faire (heures) mis à 3.0

#6 Mis à jour par Olivier FEBWIN il y a environ 7 ans

Mon problème #19686 est certainement le même...

#7 Mis à jour par Jean-Marc MELET il y a environ 7 ans

Hmmm... je ne pense pas à priori.
Le comportement observé dans #19686 doit en effet être la conséquence du correctif #17579 (mais je ne sais pas pourquoi ton service bastion est détecté comme arrêté)
Le problème évoqué dans le signalement présent est de la même nature que #17579 ("conflit" dans l'execution de regles iptables) mais pas pour les même raisons. Comme je le disais il semble s'agir d'une interaction entre des phases du lancement du service bastion (automatique au logrotate ou manuellement). Une temporisation permet d'éviter le problème.

#8 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • Assigné à Fabrice Barconnière supprimé

#9 Mis à jour par Fabrice Barconnière il y a environ 7 ans

Bonjour Jean-Marc,

le problème est toujours d'actualité en 2.5.2 ? Même avec la correction #17579 ?

#10 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • Statut changé de Nouveau à En cours

#11 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • Assigné à mis à Fabrice Barconnière

#12 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • % réalisé changé de 0 à 50

Test sur une infra etb1.amon avec agrégation en 2.6.1. Le script bastion a été revu (#19422). Le problème ne semble plus se poser. Les règles liées à l'agrégation sont toujours présentes après le logrotate.

#13 Mis à jour par Jean-Marc MELET il y a environ 7 ans

Salut Fabrice,

Oui il me semble l'avoir déja précisé mais le correctif #17579 n'a pas d'effet sur le comportement indésirable exposé dans ce signalement. En effet, le problème n'est pas lié à une interraction entre les service rvp et bastion mais entre différentes phases propres au service bastion.
Je ne peux pas confirmer si cela se reproduit ou pas en 2.6.1 mais en tout cas en 2.5.2 c'est toujours le cas.

#14 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • % réalisé changé de 50 à 70
  • Restant à faire (heures) changé de 3.0 à 2.0

Après analyse, le lock de bastion est mis avant la mise en place des règles iptables de l'agrégation, de la QOS et du VPN.
L'agent Zéphir bastion effectue une sauvegarde des règles qui est susceptible de s'exécuter pendant le restart de bastion au logrotate.
Je n'ai pas réussi à reproduire le problème, mais on pourrait retarder la mise en place du lock après l'agrégation, la QOS et le VPN.
Ainsi, on pourrait ne faire la sauvegarde des règles que si le lock est en place.

#15 Mis à jour par Jean-Marc MELET il y a environ 7 ans

Ca peut être une piste en effet, mais ceci est-il valable uniquement au logrotate? car le problème évoqué se produit à chaque relance de bastion même manuelle.
Sinon tu peux me donner les modifs à apporter pour pouvoir l'expérimenter en maquette et valider ou non cette hypothèse...

#16 Mis à jour par Fabrice Barconnière il y a environ 7 ans

Je t'avais envoyé un mail hier matin avec les modifs, mais si tu reproduis systématiquement le pb en relançant bastion, je ne pense pas que cela règle le problème.
Que donnent (sans le sleep dans bastion):
  • bash -x /etc/init.d/bastion restart ?
  • time /etc/init.d/bastion start ?
Peux-tu me fournir les fichiers suivants s'ils existent :
  • /etc/eole/iptables
  • /etc/eole/bastion-modules
  • /etc/eole/ipset
  • /etc/eole/inclusion_statique
  • /etc/eole/hosts.allow
  • /etc/qoseole.conf
  • /etc/agregation.conf

#17 Mis à jour par Jean-Marc MELET il y a environ 7 ans

Oui j'ai bien eu ton mail, du coup d'apres ta nouvelle réponse je n'ai pas testé la manip.
Tu trouveras les éléments demandés en PJ.

#18 Mis à jour par Fabrice Barconnière il y a environ 7 ans

Bonjour Jean Marc,
J'aurais également besoin du config.eol et du modèle ERA.
Merci

#19 Mis à jour par Fabrice Barconnière il y a environ 7 ans

Dans le fichier Exemple regles bastion.txt , ce sont les règles de SNAT vers eth0 qui disparaissent ?
  • Si c'est ça, c'est le script d'agrégation qui les supprime, ce qui me semble normal mais je ne connais pas toutes les subtilités de l'agrégation.
    Je ne vois pas comment en mettant une tempo de 5s les règles sont toujours là et/ou réapparaissent et/ou ne sont pas supprimées.

#20 Mis à jour par Jean-Marc MELET il y a environ 7 ans

Pas forcément, c'est un peu aléatoire. Parfois c'est des regles de SNAT du marquage des paquets pour les tables T1 et T2 de l'agregation comme celle-ci:
-A POSTROUTING -o eth0 -m mark --mark 0x1 -j SNAT --to-source 10.104.201.245
D'autres fois des regles ACCEPT comme celle-là:
-A POSTROUTING -s 10.4.201.0/25 -d 172.16.0.0/12 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Ou bien au contraire on peut avoir un reste de regle SNAT présente habituellement sans agrégation encore active comme celle-ci:
-A POSTROUTING -s 10.4.201.0/25 -o eth0 -j SNAT --to-source 10.104.201.245

Oui j'ai bien vu qu'il a été publié certaines évolutions du script d'agrégation qui intègre d'ailleurs certaines de nos adaptations académiques, je dois le tester mais cependant je ne pense que cela règle notre problème qui doit se situer dans l'ordre ou le temps d'éxecution des différentes phases du script, enfin c'est une impression.

Voici les fichiers demandés

A l'occasion je tenterais de suivre un redémarrage en bash -x et de faire le rapprochement avec la génération des regles en temps réel pour tenter de mieux comprendre

#21 Mis à jour par Karim Ayari il y a environ 7 ans

c'est vrai que cela ressemble grandement au signalement #17579 et pourtant tu n'as aucune interface vlan
tu as regardé les log de l'agent RVP ? si au moment où tu constates le problème s'il n'y a pas eut un redémarrage des tunnels ?
tu n'as pas une tonne de règles iptables lancée par un script externe ?

#22 Mis à jour par Fabrice Barconnière il y a environ 7 ans

Il y a une différence entre le contenu du cache (/etc/eole/iptables) et le script généré (/sbin/lance.firewall) ?
Le problème ne se pose qu'avec l'agrégation activée ?

#23 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • % réalisé changé de 70 à 90
  • Restant à faire (heures) changé de 2.0 à 1.0

Si dans le cache, toutes les règles sont présentes, tu peux essayer un script de ce genre pour vérifier si éventuellement les règles mettent un certain temps à se mettre en place : 

service bastion stop
ipset restore -exist < /etc/eole/ipset
iptables-restore < /etc/eole/iptables
I=0
while [ $I -lt 5 ]
do
    iptables-save > ipt_save$I
    let I+=1
done

Si on voit évoluer les fichiers ipt_saveX, cela proviendrai alors de iptables-restore qui demanderai un certain délai pour la mise en place des règles.

#24 Mis à jour par Fabrice Barconnière il y a environ 7 ans

  • Statut changé de En cours à Nouveau
  • Assigné à Fabrice Barconnière supprimé
  • Tâche parente changé de #18394 à #20100

Report sur le prochain sprint dans le scénario assistance car il s'agit d'un cas "isolé" qu'on n'arrive pas à reproduire.

#25 Mis à jour par Fabrice Barconnière il y a presque 7 ans

  • Statut changé de Nouveau à Fermé
  • % réalisé changé de 90 à 100
  • Restant à faire (heures) changé de 1.0 à 0.0

Je ferme cette tâche.
Une nouvelle demande pourra être ouverte si on a des informations permettant de corriger ce problème.

#26 Mis à jour par Jean-Marc MELET il y a presque 7 ans

Salut à tous les deux,

Désolé j'ai loupé vos réponses et constaté trop tard que le signalement avait été fermé.
Tout d'abord pour répondre à Karim, mes tunnels sont assez stables et il n'y a pas de lien avec d'enventuels redémarrages de tunnels par l'agent rvp.
Ensuite, je n'ai pas une tonne de regles iptables mais en revanche 2 regles qui utilisent un ipset qui contient environ 7000 IP. J'ai évidemment pensé à ça au début, mais le problème persiste si je désactive la génération de ces regles.
Enfin, oui cela ne semble se produire qu'avec l'agrégation activée.

Pour la question du cache d'iptables, ce serait trop fastidieux de comparer chaque regle contenue dans /etc/eole/iptables et /sbin/lance.firewall, par contre on se traine depuis le début une erreur dans le diagnose au niveau du pare-feu dont je ne suis jamais arrivé à comprendre l'origine, cela ne nous gêne pas car tout fonctionne sans problème au niveau des accès.

Ensuite pour répondre à Fabrice, en faisant les essais avec le script proposé, je constate qu'il n'y a aucune différence entre les fichiers ipt_saveX générés. La seule chose à noter c'est qu'ils ne contiennent pas les regles qui utilisent le fameux ipset que l'on a ajouté car pour pouvoir l'intégrer nous avions opté pour ajouter notre ipset dans /usr/share/era/ipset-tor et la condition suivante dans les inclusions statiques de notre modèle:

if [ -e /usr/share/era/ipset-tor ] ; then
. /usr/share/era/ipset-tor > /dev/null
iptables -I OUTPUT -o eth0 -p tcp -m tcp -m set --match-set bastion-tor dst -j DROP
iptables -I FORWARD -o eth0 -p tcp -m tcp -m set --match-set bastion-tor dst -j DROP
fi

Ce qui explique je pense le fait qu'on ne retrouve pas ces 2 regles dans iptables-save avec ce script mais uniquement si on relance complètement bastion.

Quoiqu'il en soit, merci pour y avoir passé du temps.
J'avoue que je serais curieux de trouver une solution à ce problème, ne peut-on pas quand même envisager une tres legere évolution en ajoutant un sleep de 5 s entre les étapes comme évoqué au début du signalement, cela ne ralongerait le lancement du service que de 10 s et permettrait de regler notre problème et éviter peut-être de risquer d'autres phénomènes de bord dans la génération de regles que l'on aurait pas encore détecté?

Formats disponibles : Atom PDF