Projet

Général

Profil

Anomalie #4500

règle implicite en cas de redirection sélective

Ajouté par Thierry Chich il y a plus de 11 ans. Mis à jour il y a plus de 9 ans.

Statut:
Classée sans suite
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
27/11/2012
Echéance:
% réalisé:

0%

Distribution:
EOLE 2.3

Description

Bonjour,

Nous souhaitons faire une redirection sélective. Dans une zone peda-ext dont le flux est "interdit par défaut", voici les règles que nous avons écrit, via l'era:

            <descendantes default_policy="0">
                <directive service="tous" priority="1" action="16" attrs="0" nat_extr="exterieur_bastion" nat_port="0" src_inv="0" dest_inv="0" serv_inv="0" libelle="pas de description" >
                    <source name="pedago_net"/>
                    <destination name="exterieur"/>
                </directive>
                <directive service="bcdi" priority="1" action="2" attrs="0" src_inv="0" dest_inv="0" serv_inv="0" libelle="pas de description" >
                    <source name="pedago_net"/>
                    <destination name="tout_exterieur"/>
                </directive>
                <directive service="tous" priority="2" action="2" attrs="4" src_inv="0" dest_inv="0" serv_inv="0" libelle="pas de description" >
                    <source name="pedago_net"/>
                    <destination name="cour"/>
                </directive>
                <directive service="http" priority="4" action="4" attrs="0" nat_port="3128" src_inv="0" dest_inv="1" serv_inv="0" libelle="pas de description" >
                    <source name="servSe3"/>
                    <destination name="cour"/>
                </directive>
            </descendantes>

C'est la dernière régle qui nous intéresse.

Et voici les règles iptables que nous obtenons:

/sbin/iptables -t nat -A POSTROUTING -o %%interface_gw -s %%adresse_network_eth2/%%adresse_netmask_eth2 -d 0/0 -j SNAT --to-source %%adresse_ip_eth0
/sbin/iptables -t filter -A ped-ext -m state --state NEW -p tcp --dport 9014 --tcp-flags SYN,RST,ACK SYN -i eth2 -o %%interface_gw -s %%adresse_network_eth2/%%adresse_netmask_eth2 -d 0.0.0.0/0.0.0.0 -j ACCEPT
/sbin/iptables -t filter -A ped-ext -m state --state NEW -i eth2 -o %%interface_gw -s %%adresse_network_eth2/%%adresse_netmask_eth2 -d %%adresse_ip_eth3/%%adresse_netmask_eth3 -j ULOG --ulog-prefix "era ped-ext" 
/sbin/iptables -t filter -A ped-ext -m state --state NEW -i eth2 -o %%interface_gw -s %%adresse_network_eth2/%%adresse_netmask_eth2 -d %%adresse_ip_eth3/%%adresse_netmask_eth3 -j ACCEPT
/sbin/iptables -t filter -A ped-bas -i eth2 -p tcp --dport 3128 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -i eth2 -s %%ip_servSe3/255.255.255.255 -d ! %%adresse_ip_eth3/%%adresse_netmask_eth3 -j REDIRECT --to-ports 3128

Comme on le voit, une règle d'autorisation d'accès au service 3128 sur le bastion est faite par défaut. Problème, ce n'est pas ce qui est demandé. on le demande pour servSe3, pas pour toute la zone pedago.

Cordialement,

Historique

#1 Mis à jour par Gwenael Remond il y a plus de 11 ans

  • Projet changé de Amon à ERA
  • Assigné à mis à Gwenael Remond
  • Distribution changé de EOLE 2.2 à EOLE 2.3

J'ai l'impression que vous avez mis la zone extérieure avec un niveau de sécurité supérieur à la zone pédago, ce qui me semble très bizarre.

Si vous êtes dans une balise "descendantes", (du plus sécurisé vers le moins sécurisé) vous ne pouvez créer que des directives d'interdiction (puisque c'est autorisé par défaut), et pas des directives d'autorisation. Le flux pedago vers extérieur n'est donc pas "interdit par défaut" comme vous le dites, mais autorisé par défaut. Si vous voulez interdire par défaut ce flux, sachez que vous avez dans la fenêtre "liste des directives" la possibilité de cliquer sur "inverser la politique par défaut" :

http://eoleng.ac-dijon.fr/documentations//EraProxy/co/3-DirectiveEdition.html (début de la page, case à cocher "inverser la politique par défaut", fenêtre "liste des directives")

Vous obtiendrez alors dans le xml :

<descendantes default_policy="1">

à la place de

<descendantes default_policy="0">

Est-ce ça ne répondrait pas à votre demande ?

Encore une autre remarque si vous me permettez : vous ayez visiblement modifié à la main le XML sans passer par Era, ce qui me semble dangereux : vous avez des attributs "priority" qui se chevauchent (normalement, Era vous aurait mis des priority à 1,2,3,4 alors que vous avez des priority à 1,1,2,4. vous avez donc copié-collé des directives directement dans le xml). Ce genre de manipulation peut créer des erreurs internes dans Era, surtout si vous les changez de flux...

Enfin, quant à la règle implicite que vous mettez en question, dans votre cas, c'est-à-dire dans le cas d'une redirection sélective, elle n'est effectivement pas adaptée.
Elle l'est dans d'autres cas d'utilisation (redirection globale et pas sélective). La supprimer entrerait en conflit avec les cas d'utilisation actuel. Il faudrait, si vous ne parvenez pas à faire ce que vous souhaitez faire en inversant la politique par défaut, conditionner la règle implicite en ACCEPT et ne pas la générer en cas de redirection sélective. C'est bien sûr possible au niveau du compilateur de règles Era. Mais c'est un comportement qu'il faut discuter et faire acter par les administrateurs réseau EOLE.

De plus, vous avez demandé ce changement pour la 2.2 alors qu'elle est en situation de gel de fonctionnalités. Cet ajout ne pourrait se faire que pour la version 2.3

Cordialement,
Gwen

#2 Mis à jour par Gwenael Remond il y a plus de 11 ans

  • Sujet changé de Bug era à règle implicite en cas de redirection sélective

#3 Mis à jour par Thierry Chich il y a plus de 11 ans

Pour répondre au questions que vous posez:
  • non, cela ne répond pas à ma demande. Je souhaite bien que ma zone pedagogique ne sorte pas par defaut.
  • nous n'avons pas modifié le xml à la main (ça ne serait pas du jeu de vous parler d'un bug dans éra si j'avais modifié le résultat). Par contre, je ne sais pas pourquoi il y a deux fois priority=1. Il me semble avoir enlevé des règles non significative dans le xml en faisant la recopie, mais je n'ai pas intégré de nouvelle choses dans le xml.

Sur le dernier point, je suis d'accord que ce changement pourrait avoir de sérieuses implications.

#4 Mis à jour par Joël Cuissinat il y a plus de 11 ans

  • Statut changé de Nouveau à A étudier

#5 Mis à jour par Joël Cuissinat il y a plus de 11 ans

  • Assigné à changé de Gwenael Remond à Luc Bourdot

#6 Mis à jour par Redmine Admin il y a plus de 9 ans

  • Statut changé de A étudier à Ne sera pas résolu

#7 Mis à jour par Redmine Admin il y a plus de 9 ans

  • Statut changé de Ne sera pas résolu à Classée sans suite

Formats disponibles : Atom PDF