Evolution #5723
eole-firewall : séparation des accès aux services des restrictions d'accès
Description
L'activation d'un serveur devrait rendre accessible ce service (soit par NAT soit en ouvrant firewall sur ce port).
Par ailleurs il faudrait pouvoir restreindre l'accès à des services pour une classe d'utilisateur.
Demandes liées
Révisions associées
Il est maintenant possible de définir n'importe quel type d'objet tiramisu (et pas seulement les symlink)
Ajout de service_access (ref #5723)
ouvre le firewall (ref #5723)
prise en compte des balises service_access pour eole-firewall (ref #5723)
la génération de hosts.allow et nat_rules.sh est maintenant fait par un template (ref #5723)
problème dans la dtd (ref #5723)
ajout de service_restriction (ref #5723)
ouvre.firewall est maintenant un template. Cela permet de reconstruire les règles de NAT lorsqu'on ouvre le firewall.
tmpl/nat_rules.sh gère maintenant tous les cas (sur le maitre, dans le conteneur, avec ou sans NAT, ...)
ref #5723
Voir commit precedent
ref #5723
Gestion des balises firewall ref #5723
conversion du .fw en balise (ref #5723)
ajoute le support de 'activate' pour les access_restriction (ref #5723)
support de 'activate' + ne pas prendre en compte les restrictions avec variable desactivee (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
ajout du support de service_accessslist + copie des requires du service vers les balises service_* (ref #5723)
ajout du support de service_accessslist (ref #5723)
retrait de *list inutile (ref #5723)
conversion du .fw en balise (ref #5723)
pour la balise ip, le type etait network_type, pas assez clair, remplacé par ip_type (ref #5723)
pour la balise ip, le type etait network_type, pas assez clair, remplacé par ip_type (ref #5723)
support du protocole dans le port (ref #5723)
pour la balise ip, le type etait network_type, pas assez clair, remplacé par ip_type (ref #5723)
conversion du .fw en balise (ref #5723)
Ajout echo-request et chmod +x 00-static_rules
ref #5723 @1h
Adaptation firewall à run-parts
ref #5723 @30m
ne pas généré de règle si le port/tcpwrapper est une variable et la variable n'existe pas (ref #5723)
ne pas appliquer de règle de firewall si le firewall est désactive (ref #5723)
redefine à oui variable activer_firewall
ref #5723 @15m
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
remplacement de hidden_if_(not_)in par des disabled_if_(not_)in
avoir le droit d'avoir plusieurs restriction puor la même ip (ref #5723)
gestion des doublons de rèlge : le dernier a raison (ref #5723)
conversion du .fw en balise (ref #5723)
remplacement des hidden_*_in par disabled_*_in
conversion du .fw en balise (ref #5723) + remplacement des hidden_*_in en disabled_*_in
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723) + remplacement des hidden_*_in en disabled_*_in
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723) + remplacement des hidden_*_in en disabled_*_in
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
pouvoir utiliser une variable pour interface (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723)
conversion du .fw en balise (ref #5723) + remplacement des hidden_*_in en disabled_*_in
suppression du fichier .fw inutile (ref #5723)
conversion du .fw en balise (ref #5723)
suppression du fichier .fw inutile (ref #5723)
conversion du .fw en balise (ref #5723)
support des interfaces 'auto' (ref #5723)
ajout de la fonction eosfunc get_interface_from_ip (ref #5723)
lightsquid_port est lié à eole-proxy, pas ead (ref #5723)
lightsquid_port est lié à eole-proxy, pas ead (ref #5723)
creole.dtd : ajout de service_accesslist|service_restrictionlist à target (ref #5723)
dicos/25_nginx.xml : correction mauvaises fins de balise
ref #5723 @30m
Historique
#1 Mis à jour par Emmanuel GARETTE il y a plus de 10 ans
Proposition :
rajouter le port/tcpwrapper/protocol dans la balise service.
Par exemple :
<service port="80" tcpwrapper="httpd">apache2</service>
Puis pouvoir rajouter des règles de firewall type :
<firewall service='apache2' ....>
#2 Mis à jour par Daniel Dehennin il y a plus de 10 ans
Voici une idée de balisage pour les services :
<services>
<!-- New service -->
<service>
<name>
bidule
</name>
<tcpwrapper>
bidule
</tcpwrapper>
<ports>
<port>42</port>
<port>4242</port>
</ports>
</service>
<service>
<name>
chose
</name>
<ports>
<!--
<port-start/end /> are exclusive with <port />
-->
<port-start>43</port-start>
<port-end>48</port-end>
</ports>
</service>
<!-- Redefine a service -->
<service>
<name>
truc
</name>
<!--
Delete any tcpwrapper settings
Just define an empty element
-->
<tcpwrapper />
</service>
</services>
Embarquer des sous éléments au lieu d’attributs permet d’intégrer plus de choses, par exemple pour les variables on pourrait y mettre l’aide et les contraintes ;-)
#3 Mis à jour par Emmanuel GARETTE il y a plus de 10 ans
Le problème c'est que cela casse la compatibilité avec la 2.3.
Je propose la solution suivante :
- pas de modification de la balise <service/>
- ajout de la base <service_access/> suivante :
<service_access name="nom_du_service"> <ports>...</ports> <tcpwrappers>...</tcpwrappers> </service>
#4 Mis à jour par Emmanuel GARETTE il y a plus de 10 ans
- Tracker changé de Anomalie à Evolution
- % réalisé changé de 0 à 40
<containers> <container name="proxy" id='20'> <service method='upstart'>squid3</service> <service_access service='squid3'> <port type="SymLinkOption">test_port</port> <port>3129</port> </service_access> <service_restriction service='squid3'> <ip interface='eth0'>192.168.1.1</ip> <ip interface='eth1' netmask='netmask_admin_eth0' type_netmask='SymLinkOption' type_ip='SymLinkOption'>ip_admin_eth0</ip> </service_restriction> </container> </containers>
La déclaration se fait donc en 3 temps :
- déclaration du service en tant que tel :
- déclaration des accès (port + tcpwrapper)
- déclaration des autorisations (0/0 sinon)
Cela génère 3 templates :
- hosts.allow pour tcpwrapper
- nat_rules.sh pour restreindre les accès au niveau iptables
- ouvre.firewall pour ajouter uniquement les règles de nat
Reste à faire :
- valider le fonctionnement ;
- lancer le script avec les règles de firewall.
#5 Mis à jour par Joël Cuissinat il y a plus de 10 ans
- Version cible changé de Eole 2.4-dev-3 à Eole 2.4-alpha
#6 Mis à jour par Joël Cuissinat il y a plus de 10 ans
- Version cible
Eole 2.4-alphasupprimé
#7 Mis à jour par Emmanuel GARETTE il y a environ 10 ans
- Version cible mis à Eole 2.4-beta3
#8 Mis à jour par Joël Cuissinat il y a environ 10 ans
- Version cible changé de Eole 2.4-beta3 à Eole 2.4-RC2
#9 Mis à jour par Joël Cuissinat il y a environ 10 ans
- Assigné à mis à Emmanuel GARETTE
- Version cible changé de Eole 2.4-RC2 à Eole 2.4-RC1
#10 Mis à jour par Emmanuel GARETTE il y a environ 10 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 40 à 100
Appliqué par commit eole-annuaire:f92d9c09ba039bdf66a7ded5ca0b528b8426ad6f.
#11 Mis à jour par Fabrice Barconnière il y a environ 10 ans
- Echéance mis à 17/01/2014
- Version cible changé de Eole 2.4-RC1 à Eole 2.4-beta3
paquet refait
#12 Mis à jour par Gilles Grandgérard il y a environ 10 ans
- Assigné à changé de Emmanuel GARETTE à Gilles Grandgérard
#13 Mis à jour par Gilles Grandgérard il y a environ 10 ans
- Statut changé de Résolu à Fermé
incomplet en bêta 3, se poursuit en RC1 sous forme de demandes particulières.
Les évolutions liées à cette demande sont validées par les demandes suivantes (RC1)