Project

General

Profile

Tâche #23723

Scénario #23986: Assistance aux utilisateurs (23-25)

Permettre un usage académique d'ipset en dehors des groupes de machines

Added by Laurent HAEFFELE almost 5 years ago. Updated almost 5 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Gwenael Remond
Start date:
04/24/2018
Due date:
% Done:

80%

Estimated time:
0.00 h
Spent time:
Remaining (hours):
0.0

Description

Nous souhaiterions pouvoir utiliser des ipset au niveau académique, que ce soit pour gérer des listes d'adresses IP externes autorisées ou la répartition de charge.

Amon considère que tous les ipset sont des groupes de machines qu'il devrait lui-même gérer.
En particulier, lors de la création d'un groupe de machine ou de la génération des règles du bastion, il tente de supprimer tous les ipset qu'il ne connaît pas et retourne un message d'erreur.

Serait-il possible de préfixer les ipset gérés par le amon et de ne pas toucher aux autres ou à l'inverse autoriser des ipset préfixés par "local_" ou "acad_" qui ne seraient pas touchés le serveur Amon ?

Capture d’écran de 2018-06-13 09-43-20.png View (157 KB) Laurent HAEFFELE, 06/13/2018 09:50 AM


Related issues

Related to ERA - Scénario #24284: Le comportement ipsets est à revoir sur EOLE 2.7 Terminé (Sprint) 04/24/2018 07/13/2018
Copied to ERA - Tâche #24223: Documenter le fait que les ipsets débutant par "local_" sont protégés de la suppression Fermé 04/24/2018

Associated revisions

Revision c2513d7b (diff)
Added by Gwenael Remond almost 5 years ago

doesn't flush local ipset, ref #23723

Revision aea24424 (diff)
Added by Gwenael Remond almost 5 years ago

doesn't flush local ipset, ref #23723

History

#1 Updated by Gwenael Remond almost 5 years ago

  • Assigned To set to Gwenael Remond

Bonjour,

Les règles ipsets gérées par amon sont déjà préfixés (par bastion-), et donc ça n'engendrerait aucun développement de ne pas choisir d'effacer tous les ipsets.

Mais il se trouve que la politique actuelle du pare-feu amon est de centraliser les règles, donc d'effacer toutes les règles iptables et toutes les règles ipsets puis de les re-générer (avec la commande bastion regen).

Si vous voulez que vos règles ipsets soient prises en compte et persistantes, je vous conseille d'ajouter vos règles ipsets dans le modèle XML Era que vous utilisez au niveau des inclusions statiques :

http://eole.ac-dijon.fr/documentations/2.5/partielles/HTML/ERA/co/6-InclusionStatique.html

Dans les inclusions statiques vous pouvez mettre des règles iptables, des règles ipsets, etc... Elles seront exécutées.

Vos règles ipsets spécifiques ne seront pas générées par amon mais elles seront gérées (incluse telles quelles statiquement) à chaque reconfigure, bastion regen, etc.

Cordialement,
Gwen

#2 Updated by Joël Cuissinat almost 5 years ago

  • Parent task set to #23986

#3 Updated by Joël Cuissinat almost 5 years ago

  • Project changed from Amon to Distribution EOLE
  • Status changed from Nouveau to En cours

#4 Updated by Laurent HAEFFELE almost 5 years ago

Le problème, ce n'est pas vraiment l'inclusion des règles statiques (qu'on utilise déjà), mais le fait que l'EAD2 ne semble pas supporter le fait d'avoir des ipsets externes lorsqu'on touche aux règles de filtrage sur un groupe de machine ou qu'on active/désactive une règle optionnelle.
J'ai testé cela sur un Amon 2.5.1. Je peux éventuellement tester cela demain sur un 2.7 si cela peut faire avance le schmilblick.

#5 Updated by Laurent HAEFFELE almost 5 years ago

Le problème est toujours présent sur Amon 2.7.

Exemple de création et utilisation d'un ipset dans les inclusions statiques :

ipset -q create toto hash:ip family inet
ipset add toto 1.1.1.1
iptables -w -I FORWARD -m state --state NEW -i eth2 -o eth0 -m set --match-set toto dst -p tcp --dport "80" -j ACCEPT

On va ensuite dans l'EAD2 pour ajouter un groupe de machine et badaboum:
Message d'erreur (ci-joint) lors de la création d'un nouveau groupe de machine (idem lors de la suppression):

Erreur : erreur lors de la suppression du set d'ip toto

C'est sans doute lié au fait que la commande "ipset destroy toto" retourne "ipset v6.34: Set cannot be destroyed: it is in use by a kernel component" puisque l'ipset est utilisé dans une règle iptables ...

#6 Updated by Gwenael Remond almost 5 years ago

OK j'ai compris le problème.

Je suis en train d'ajouter un préfixe (le choix du préfixe local_ me semble une bonne idée) pour ne plus avoir ce message d'erreur.
Ceci dit c'est un changement de comportement de l'ipset, donc c'est sujet à validation de l'Équipe. On va prendre une décision.

#7 Updated by Gwenael Remond almost 5 years ago

  • Estimated time set to 0.00 h
  • Remaining (hours) set to 0.0

#8 Updated by Gwenael Remond almost 5 years ago

Après réunion de l'équipe, nous avons décidé de faire la modification que tu as demandée.

"J'ai testé cela sur un Amon 2.5.1" -> Attention nous avons fait la modification sur Amon 2.5.2, Amon 2.6.1 et Amon 2.6.2 mais pas sur un 2.5.1

Un Maj-Auto va te récupérer la modif, si tu veux bien re-tester (avec tes règles ipsets nommées local_ donc)

Merci

#9 Updated by Joël Cuissinat almost 5 years ago

  • Copied to Tâche #24223: Documenter le fait que les ipsets débutant par "local_" sont protégés de la suppression added

#10 Updated by Laurent HAEFFELE almost 5 years ago

Je viens de tester sur un Amon 2.5.2.
J'ai effectué un Maj-Auto -D. Cela a mis à jour les paquets suivants : eole-amon eole-amon-all eole-amon-module

Mais j'ai toujours l'erreur dans l'EAD2:
Erreur : erreur lors de la suppression du set d'ip local_link1

#11 Updated by Fabrice Barconnière almost 5 years ago

  • % Done changed from 0 to 80

Le paquet est disponible en candidate sur test-eole.ac-dijon.fr : eole-amon-backend 2.5.2-10

# Query-Auto -C -S test-eole.ac-dijon.fr
# apt-eole install eole-amon-backend
# reconfigure
# Query-Auto

#12 Updated by Laurent HAEFFELE almost 5 years ago

C'est validé sur mon Amon 2.5.2 de test.
Les ipsets nommés local_* ne sont plus touchés.

#13 Updated by Gwenael Remond almost 5 years ago

  • Status changed from En cours to Résolu

#14 Updated by Scrum Master almost 5 years ago

  • Status changed from Résolu to Fermé

#15 Updated by Gwenael Remond almost 5 years ago

  • Related to Scénario #24284: Le comportement ipsets est à revoir sur EOLE 2.7 added

Also available in: Atom PDF