Firewall Checkpoint V3.0b
--------------------------------------------------------------------------------
But de l'étude
Le but de cette evaluation est de vérifier la validité 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 possibilités 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 primordiale de vérifier la tenu à 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 développement. Il est primordial que le firewall sache filtrer correctement ces nouveaux protocoles, ou offre un moyen à l'administrateur de les integrer soi-même dans le système.
--------------------------------------------------------------------------------
Plateforme de test
L'evaluation à été réalise avec les machines suivantes :
Le firewall (colotte.loria.fr):
sun ultra1 140 64 MB de mémoire, avec 2 cartes Sun Fast Ethernet sur SBus (SUNW,501-2739)
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
La machine land1 est une machine banale (en 10 Mb/s). Elle n'a en fait pas été utilisée.
Toutes ces machines étant connectées directement sur un switch catalyst 5000 (cisco) en 100 Mb/s Full duplex.
schéma logique :
schéma physique :
--------------------------------------------------------------------------------
Installation
L'installation de FW-1 version 3.0b est relativement facile. Il s'agit juste de répondre aux questions...
Nous avons installé FireWall-1 Enterprise Product complet.
L'installation modifie quelques fichiers, dont certains avec des bugs (/etc/init.d/rootusr) !. Ce n'est pas très convivial, et nous avons du refaire plusieurs fois l'install avant d'être à peu près bien.
L'installation prends environ 30 Mgs sur disque. C'est testé àl'install.
L'installation du client graphique (26 Mgs)
Il remplace/rajoute un objet dans le kernel, et le lancement d'un utilitaire (fw) dans le démarrage.
Tout s'install par défaut dans /etc/fw (modifiable). Attention, les logs y vont aussi...
L'installation est simple. Un bug lors de la première, avec la modification du fichier de boot /etc/init.d/rootusr qui s'est mal passé et interdisait tout reboot (même en single).
Les droits des fichiers, binaires mis par le script d'install sont corrects. Le firewall démarre immédiatement.
--------------------------------------------------------------------------------
démarrage
Lors du boot de la station, le module de FW-1 est lancé très tôt (avant le single). Puis il charge une masse de règles par défaut lui permettant de booter, et en passant en multi, lance fw, avec la base de règle finale.
Il veut aussi installer son propre demon snmpd. Celui-ci se plante au lancement, car le port est déjà utilisé par celui du système. Il suffit de le remplacer.
Le boot est assez long. le temps de chargement / initialisation du premier module est long.
Il est possible de l'arrêter et de le démarrer sans forcement rebooter la machine. Ca fonctionne. Penser simplement à remmettre l'ip-forwarding,
qu'il enlève systématiquement.
Les process qui tournent :
ps -edf |grep fw
root 576 1 0 17:32:55 ? 0:00 fwm
root 571 1 0 17:32:55 ? 0:02 fwd
root 574 1 0 17:32:55 ? 0:00 /etc/fw/bin/snmpd
f( wd - FireWall-1 daemon )
--------------------------------------------------------------------------------
Espace disque utilisé
Tout se trouve dans /etc/fw (ou modifiable)
drwxrwx--- 2 root fire 1024 Dec 30 13:36 bin
drwxrwx--- 2 root fire 512 Aug 27 1997 cisco
drwxrws--- 8 root fire 512 Aug 28 1997 clients
drwxrws--- 3 root fire 1024 Feb 26 17:32 conf
drwxrws--- 3 root fire 512 Feb 26 17:32 database
drwxrwx--- 2 root fire 512 Aug 27 1997 doc
-rwxrwx--- 1 root fire 11155 Dec 30 11:18 fwinstall
drwxrwx--- 3 root fire 1024 Aug 27 1997 lib
drwxrws--- 2 root fire 512 Feb 26 17:31 log
drwxrwx--- 5 root fire 512 Aug 27 1997 man
drwxrwx--- 2 root fire 512 Dec 30 11:18 modules
drwxrwx--- 2 root fire 1024 Aug 27 1997 scripts
drwxrwx--- 2 root fire 512 Aug 27 1997 spool
drwxrws--- 2 root fire 1024 Feb 26 17:27 state
drwxrws--- 2 root fire 1024 Feb 26 17:27 tmp
drwxrwx--- 2 root fire 512 Aug 27 1997 well
Partie fixe :
Espace total sans les logs : 30 Mgs
Partie variable :
Taille des logs : ~48 octets par entrée.
Elles se compressent très bien, on gagne un facteur 10 avec un gzip -9
Attention, il garde les numéros IP. La résolution DNS se fait seulement a l'affichage ==> On peut avoir des soucis, lors de DNS Spoofing, ou de machines ayant été remplacées, avec le numéro IP de reutilisé.
Taille des fichiers de confs : ~ 35 octets par règles en non-compilé, 66 en compilé, soit ~100-110 octets par règles sur le disque.
Le reste est tout aussi négligeable.
--------------------------------------------------------------------------------
La configuration vt100
FW-1 est configurable en mode plein ecran. En éffet, toutes les modifications reviennent à faire des changements dans des fichiers textes
(base de règles, base d'objets).
Ces fichiers sont humainement lisibles, c'est à dire qu'on peut facilement les modifier à la main sans trop risquer l'erreur de syntax. Celle-ci n'etant pas trop compliquée (juste quelques parentheses à
compter). Un mode emacs, avec font-lock associé, aurait été bienvenu.
FW- reste donc 100 % configurable en mode vt100, et donc en batch (pour tous nos tests en tout cas)
--------------------------------------------------------------------------------
La configuration graphique
Il y a deux modes graphiques possibles : Une version openwindow (look olwm) (ancienne version) , et une version motif (nouvelle version).
Des nos tests, elles ont sensiblement les mêmes fonctionnalités. Ces modes graphiques sont des programmes qui se contentent de modifier les
fichiers de conf, et de lancer des commandes accessibles en mode vt100 (compilation des règles par exemple).
Look olwm :
C'est le client graphique fourni avec le module de management. C'est du look olwm, et bien évidemment pose des problèmes de fonts (résolvables avec un tour de font path - path). Il a le merite de bien fonctionner et de présenter toutes les fonctionnalites du logiciels. Tous les modules (logs, policies, etc...) sont appelable individuellement, ou par interface graphique. Elle fonctionne directement sur le firewall. Pas de problèmes majeurs décelés. Elle n'est pas très intuitive.
Look motif :
C'est nettement plus beau. La visualisation des règles est très claire. Elle est très intuitive.C'est en fait un module à part de firewall-1 (FireWall-1 GUI client), car il est possible de l'installer sur une autre machine que le firewall. Elle plante encore régulierement, en core dump, suivant les manips sur le firewall. Après purge du fichier de lock, elle redemarre sans problèmes. Elle pose notamment des problèmes de rafraichissement (fenêtre figée) et d'allocation de couleurs (16 couleurs mini). De plus, il n'a pas de man.
--------------------------------------------------------------------------------
La gestion des administrateurs
Il est possible de permettre à des gens non root sur la machine de gérer le firewall. Nous avons eu quelques deboires avec ce systeme, car tout n'est pas permis. FW-1 gère sa propre base (fichier) des administrateurs. Il faut s'authentifier lors du lancement de l'interface. Pour être en concordance avec les droits unix, il propose à l'installation de choisir un groupe unix, et d'y affecter les fichiers de confs. Ca permet aux gens appartenant à ce groupe de faire des modifs via l'interface, ou à la main, des fichiers de conf, de logs, etc... Cependant, le lancement et l'arrêt de FW-1 n'a pas été possible sans être root (droit sur /dev/tcp, /dev/fw), droits sur les demons.
Seul un administrateur peut lancer l'interface en mode Write, les autres seront alors en read only. Le lock est au niveau de l'interface, dans un simple fichier.
--------------------------------------------------------------------------------
La gestion à distance
Il est possible de gérer le firewall à distance, et ce même de l'extérieur. Le module fwpolicy peut-être installé sur n'importe quelle machine, Il dialogue ensuite en client-serveur avec le firewall. Après une authentification par administrateur, il donne l'accès à trois fenêtres :
configuration du firewall,
visualisation des logs,
visualisation de l'état du firewall.
Il est possible de gérer plusieurs firewall depuis une seule station. Les locks (dans le cas de plusieurs administrateurs simultanés) sont
géres (cf La gestion des administrateurs). Pour la gestion de l'extérieur, il faut que le firewall laisse passer les ports 256 à 261, 18181 à 18182 (groupe FW).
--------------------------------------------------------------------------------
Le filtrage
Il fonctionne sur un principe de règles, déroulées dans l'ordre, à chaque paquet. Ces règles semblent être mises de facon globale à la machine, et non pas par carte réseau, en in ou out, comme on peut le voir sur les ciscos. Il s'arrête à la première règle trouvée pour laquelle le paquet adhère. L'ordre est donc très important.
Pour une règle :
La source
Il faut definir l'objet source (réseau, sous-réseau, machine ou groupe). L'interface est bien pour ce genre de definitions.
La destination
Même principe que la source.
Les ports
FW-1 propose en standard une impressionnante liste de ports. Nous en utilisons que très peu. Ces ports sont definis de trois façons :
par numéro de service.
c'est un numéro de port, égalité ou > ou <
par numéro de programme
C'est le cas des services géres par le portmapper.
par groupe
On peut grouper les services, pour ne faire qu'une entrée.
L'action
Au dela du simple premit / deny, il y à d'autres actions.
accept
No comments
drop
On jette tout simplement.
reject
On ferme la communication.
User Auth
Identification de l'utilisateur
Client Auth
Authentification du client
Session Auth
Pas regardé.
Encrypt
C'est le tunnel crypté entre 2 Firewalls.
Client Encrypt
Client crypté avec le firewall.
La trace
Il y a plusieurs formats de traces, la quantité d'information (et donc de tailles de logs) en decoule directement.
long
Vas dans les logs
short
Vas dans les logs, avec un peu moins d'infos.
account
????
Alert
Un pop-up (je le déconseille fortement)
Mail
Un mail (bof)
snmp trap
Pas testé.
User defined
Pas testé.
Pour une redirection des logs vers les syslogs, le User defined doit être utilisable. Cependant, nous ne l'avons pas testé.
La plage de temps
Il est possible d'appliquer cette règle sur une période de temps donné. Non testé.
exemple
--------------------------------------------------------------------------------
Les ports absents de la liste
Nous avons rencontré un certain nombre de ports absents de la liste par défaut. Certains étaient facilement corrigeables, d'autres pas :
NFSV3. Bien qu'il connaisse NFS et sache le filtrer, la définition de NFS n'est qu'en UDP... Nous l'avons rajouté en tcp.
netperf. Nous avons utilisé netperf pour les tests de performance. Celui-ci fonctionne sur 2 ports. Le premier est fixe (facile à rajouter donc), le second est helas variable...
flexlm, qui n'est pas en standard. Il est notamment utilisé entre les sites INRIA pour les licences Framemaker.
AFS n'est pas connus. Nous n'avons pas pu tester pour le moment (pas de client AFS sur DEC à Nancy. Cependant, AFS etant filtrable sur un routeur CISCO, il l'est forcement sur FW-1.
Le bit establish a été implémenté sous la fonction "FASTPATH". Ce n'est pas clair du tout dans la doc. Il permet cependant de considérablement augmenter les perfs TCP.
Mar 12 Fév - 11:10