BUT de l'étude
Le but de cette évaluation est de vérifier la validite d'une solution de type firewall pour protéger les réseaux INRIA.
Les tests n'avaient pas pour but de tester l'ensemble des possibilites du Firewall, mais de se focaliser sur les critères importants définis par la commission sécurité INRIA :
Les performances :
Chacun des sites INRIA est ou sera connecté à sa plaque régionale à haut débit (>= 100Mb/s). Il est donc primodriale de vérifier la tenue à la charge du firewall.. Celui-ci ne doit pas trop réduire la bande passante, ni devenir le goulot d'étranglement du réseau.
La configurabilite :
Les chercheurs de l'INRIA et des labos associés utilisent un grand nombre de protocoles, souvent recents voir même encore en developpement. Il est primordial que le firewall sache filtrer correctement ces nouveaux protocoles, ou offre un moyen de les intégrer soi-même dans le système.
--------------------------------------------------------------------------------
Plateforme de test
L'évaluation à été réalisée avec les machines suivantes :
Le firewall :
pix firewall à 233 Mhz, max 64 connexions, 2 cartes Fast Ethernet.
La machine interne (dedans1.loria.fr)
un dec alpha PW500 (500au) à 128 MB de mémoire, avec une carte 100 Mb/s
La machine externe (degaulle.loria.fr)
un dec alpha PW500 (500au) à 128 MB de mémoire, avec une carte 100 Mb/s
Toutes ces machines étant connectées directement sur un switch catalyst 5000 (cisco) en 100 Mb/s Full duplex.
--------------------------------------------------------------------------------
Installation
PIX est un firwall "hardware". C'est en gros une boite ressemblant à un routeur, avec diverses carte (ethernet, FDDI, etc...).
Il a aussi un lecteur de disquettes, pour les upgrades de l'IOS.
Le PIX s'installe physiquement très bien (On branche les prises). Puis il faut le configurer, en utilisant tout d'abord une console vt100,avant de pouvoir l'attaquer à distance. Cette étape peut être assez longue, et les commandes minimums à entrer pas très simples.
--------------------------------------------------------------------------------
Les possibilités
Voici une brève liste des possibilités de pix (j'ai enlevé les choses évidentes = conduits / outbounds)
Adaptive Security Algorithme (ASA)
utilise des numéros de séquence TCP pris au hasard (pour éviter le hijack).
NAT
Permet de masquer une partie du réseau interne
PAT (Port Adress Translation)
Masque le port réel de la machine interne.
Cut through Proxies
c'est l'authentification des utilisateurs.
Mail Guard
Verifie et ne laisse passer que certains messages SMTP.
Java Filtering
Filtre les applets.
Flood defender
Protection des SYN attack. voir Attaques diverses.
Netbios
Ben oui, il sait en faire...
HTML interface
Elle doit être superbe.
Multimédia support
Il supporte des protocoles particuliers (RealAudio, Streamworks, CuSeeMe,Internet Phone, IRC, H.323, Vxtreme,VDO Live)
Private-Link
C'est le tunnel crypté.
Failover
C'est la redondance en cas de pannes.
--------------------------------------------------------------------------------
Le démarrage
Au boot, le pix charge sa config comme n'importe quel switch / routeur cisco. Le processus de boot est très rapide.
--------------------------------------------------------------------------------
La configuration vt100
C'est le seul mode testé jusqu'a présent.
Le système ressemble à de l'IOS standard. Donc pas de problèmes majeurs, si ce n'est la longueur des commandes qui est a déplorer, notamment lors d'éffacement (commande no qqchose), ou il est nécéssaire de retaper toute la ligne.
De plus, quelques changements dans les masques on étés éffectués. Certaines commandes utilisent les masques "cisco", d'autres les netmasks standards...
--------------------------------------------------------------------------------
La configuration graphique
Un systeme de configuration graphique est disponible, c'est PIX Firewall Manager. Il est basé sur NT uniquement. Le principe :
Une station NT tourne un service (pixmserv.exe), qui visiblement ressemble à un serveur http. Ensuite, il est possible de lancer dans un navigateur web un client (applets) pour modifier le PIX. Les commandes sont envoyés au pixserv.exe, qui, grosso-modo, fera un telnet sur le PIX pour lui envoyer les commandes en ligne.
Nous n'avons pas réussi à le faire fonctionner. En éffet, ce serveur ne tourne que sur un NT qui n'est pas PDC ou BDC, et qui se trouve dans la zone interne, protégée par le PIX. Après plusieurs essais infructueux, cisco nous a appris que ça devait être un NT anglais...
--------------------------------------------------------------------------------
La gestion des administrateurs
Elle est très basique. Comme sur les routeurs Cisco, il y a un compte avec un mot de passe, puis un mot de passe enable. Ces mots de passes sont visibles de façon encryptés. dans la config. Il sont peut-être crackable (c'est un trou énorme dans l'IOS 11.x).
--------------------------------------------------------------------------------
La gestion à distance
Elle est très basique : telnet
Ca fonctionne comme un routeur. Une restriction cependant :
Il n'est accessible en telnet que des machines définies dans la commande telnet, et ces machines doivent obligatoirement faire partie du réseau interne.
Il n'y a donc pas de mécanisme simple et sécurisé pour l'administration à distance (ie depuis l'extérieur), du PIX, en mode vt100.
Il faut faire un telnet sur une machine interne, et ensuite faire un telnet sur le PIX, avec toutes les conséquences (écoute réseau) que cela engendre.
En mode graphique, il est possible d'administrer différents PIX, le client (applet) communiquant avec le serveur se trouvant derrière le PIX, Non testé.
--------------------------------------------------------------------------------
Le filtrage
Le filtrage a été très dur à appréhender sur le PIX. Il fonctionne de deux façons très différente :
de l'intérieur vers l'extérieur.
Ce filtrage concerne les paquets de données qui proviennent du réseau interne. Par défaut, le firewall applique la politique de sécurité suivante " tout ce qui n'est pas expressément interdit est autorisé"pour les paquets sortants.
Pour réaliser ce filtrage, nous avons utiliser deux commandes. La première est la commande outbound ; elle est équivalente dans sa philosophie d'utilisation aux access-lists des routeurs classiques.. La deuxième commande est apply ; elle permet d'appliquer la politique fixée par les premières commandes sur une interface du firewall.
Les paramètres de la commande outbound sont les suivants :
outbound num [permit | deny | except] ip_address netmask port protocol
num : numéro d'ordre de la commande,
permit : autorise le service,
deny : interdit le service,
except : crée une exception à une commande outbound précédente,
ip_address : adresse de(s) hôte(s) interne(s) concerné(s) par la commande,
netmask : masque réseau de l'adresse donnée précédemment,
port : service concerné par la commande,
protocol : protocole utilisé par le service.
La commande apply s'utilise de la façon suivante :
apply (if_name) outbound_id [outgoing_src | outgoing_dest]
if_name : nom de l'interface interne qui ouvre la connexion
outbound_id : identificateur d'une entrée outbound
outgoing_src : permet ou interdit un hôte interne la possibilité d'initier une connexion pour le service spécifié par la commande outbound.
outgoing_dest : permet ou interdit l'accès à à un hôte externe en utilisant le service spécifié par la commande outbound.
Voici comment on pourrait interdire la machine pix1 d'accéder au World Wide Web
outbound 10 deny 152.81.34.2 255.255.255.255 80
apply (inside) 10 outgoing_src
c'est la commande outbound, dans laquel on précise ce qu'on souhaite interdire ou laisser passer (permit|deny|except). Par défaut, tout est ouvert. Il fonctionne comme une ACL, avec adresse source, adresse destination, protocole port, par exemple :
outbound 1 permit 0.0.0.0 0.0.0.0 20 tcp
outbound 1 permit 0.0.0.0 0.0.0.0 21 tcp
outbound 1 permit 0.0.0.0 0.0.0.0 23 tcp
outbound 1 permit 0.0.0.0 0.0.0.0 513 tcp
Le filtrage des paquets entrants.
Ce filtrage concerne les paquets de données qui proviennent du réseau externe, dans notre cas, le réseau Loria. Par défaut, le firewall applique la politique de sécurité suivante " tout ce qui n'est pas expressément autorisé est interdit " pour les paquets entrants.
Nous allons par la suite détailler la politique minimale qu'il a fallut appliquer pour pouvoir utiliser la machine PIX1 située dans le réseau interne. Ceci est dû à la configuration de la plate-forme de test. (Serveur DNS sur le réseau externe, montage NFS, pages jaunes,...).
static (inside,outside) 152.81.34.0 152.81.34.0 0 0 classC
Cette commande permet de définir les adresses IP internes visibles du réseau externe.
Le premier paramètre spécifie l'adresse du réseau vu de l'extérieur. Le deuxième paramètre précise l'adresse du réseau vu de l'intérieur. (donc pas de translation d'adresse. Les paramètres suivants fixent le nombre maximal de connexions TCP, ici aucune limite n'est fournie. L'option classC précise que la commande s'applique à l'ensemble des adresses du réseau interne.
La commande static est obligatoire pour pouvoir filtrer les paquets entrants. Celle-ci est en éffet utilisée par les commandes conduit suivantes. Le paramétrage de la commande conduit est le suivant.
conduit (internal_ifname,external_ifname) global_ip port protocol foreign_ip netmask
internal_ifname : nom de l'interface du réseau interne (dans notre cas inside).
external_ifname : nom de l'interface du réseau externe (dans notre cas outside).
global_ip : fait référence à l'adresse globale définie par la commande static.
port : numéro du port que l'on souhaite filtrer ou quelques noms littéraux connus par le système tel que http, dns,. telnet, tftp, ...
protocole : nom du protocole à filtrer (udp, tcp, esp et gre).
foreign_ip : adresse de la machine ou du réseau distant pour lequel on autorise la connexion.
netmask : masque du réseau correspond à l'adresse définie dans le champs précédent.
Par exemple, la commande suivante nous a autorisé à ouvrir une connexion telnet depuis n'importe quel hôte distant et vers tous les hôtes du réseaux local :
conduit (inside,outside) 152.81.34.0 23 tcp 0.0.0.0 0.0.0.0
Dans les deux cas, le matching de la ligne qui convient ne se fait pas comme dans les ACL cisco. Elle sont toutes systématiquement parsées, et c'est celle "qui convient le mieux" (best match) qui est appliquée. Il n'y a pas d'ordre dans les conduits / outbound.
Mar 12 Fév - 11:13