Project

General

Profile

Anomalie #4500

règle implicite en cas de redirection sélective

Added by Thierry Chich about 10 years ago. Updated over 8 years ago.

Status:
Classée sans suite
Priority:
Normal
Assigned To:
Category:
-
Target version:
-
Start date:
11/27/2012
Due date:
% Done:

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,

History

#1 Updated by Gwenael Remond about 10 years ago

  • Project changed from Amon to ERA
  • Assigned To set to Gwenael Remond
  • Distribution changed from EOLE 2.2 to 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 Updated by Gwenael Remond about 10 years ago

  • Subject changed from Bug era to règle implicite en cas de redirection sélective

#3 Updated by Thierry Chich about 10 years ago

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 Updated by Joël Cuissinat about 10 years ago

  • Status changed from Nouveau to A étudier

#5 Updated by Joël Cuissinat about 10 years ago

  • Assigned To changed from Gwenael Remond to Luc Bourdot

#6 Updated by Redmine Admin over 8 years ago

  • Status changed from A étudier to Ne sera pas résolu

#7 Updated by Redmine Admin over 8 years ago

  • Status changed from Ne sera pas résolu to Classée sans suite

Also available in: Atom PDF