L'installation locale
Le premier test était d'arriver à avoir des règles telles qu'elles terminent en "@any @any drop", c'est à dire tout interdire par défaut, et que la machine derrière le firewall, tout comme le firewall, fonctionne en réseau local, tous les serveurs étant externes au réseau protege.
Nous y sommes grosso modo arrive en quelques heures. Tous les services pes plus courants sont déjà connus, et permettent à une machine de fonctionner en réseau local facilement (DNS, NIS, NFS, telnet, ftp, r*, shell, X11)
--------------------------------------------------------------------------------
Les problèmes divers de nos tests
La règle 0
Nous faisons un chapitre sur la règle 0, car celle-ci nous a posé quelques soucis. En éffet, les règles commencent à 1, et certains paquets étaient rejetes et loggués comme tel, indiquant qu'ils n'ont pas passés la règle 0. D'autre part, nous avions beau interdire les icmps (pour tester), ils passaient toujours...
Les règles concernant l'ip-spoofing, le syn flooding, les ports négociés passent dans cette règle, rajoute sans rien dire par le système, avant toutes les autres. Une recherche dans l'aide n'avait rien donne sur ce sujet...
trop violent
Dans nos essais de config réseau local (cf L'installation locale), nous avons étés bien souvent trop violent dans nos règles, de sorte que le firewall n'arrive plus à démarrer. Il s'interdit lui même. il faut alors le rebooter en single, et modifier le fichier de règles a la main avant redémarrage.
hme
Le sun tournant le firewall avait 2 cartes SUNW,hme, et le fait de modifier le driver (passer en l'occurence en full duplex), n'affectait que la derniere carte configurée. Un appel hot ligne à été nécessaire pour decouvrir la variable instance (non documenté) qui permet de sélectionner la carte à configurer.
--------------------------------------------------------------------------------
La hot ligne
--------------------------------------------------------------------------------
L'aide en ligne
L'aide en ligne n'est pas performante.
La forme
Elle a un look d'aide windows,
qui rassurera sans doute les inconditionnels du genre, mais qui n'est pas très portable, ni très aisé d'utilisation. On se retrouve facilement avec un grand nombre de fenêtres ouvertes. La navigation y est moins aisée que dans des pages html.
Le contenu
Elle a un look d'aide windows ;-)
Les renseignements y figurants sont très basiques. Ils indiquent uniquement l'enchainement de click à réaliser. peu d'eclaircissement sur les erreurs rencontrées, sur le fonctionnement du logiciels, sur les fichiers...
--------------------------------------------------------------------------------
Attaques diverses
FW-1 permet de se prémunir contre quelques attaques réseau classiques :
syn flooding.
Pas testé à ce jour. Il peut les déceler et les indiquer.
ip spoofing.
Il permet d'affecter à chacune de ces interface une liste d'adresses ip authorisées ou interdites. Ca fonctionne bien. Il a cependant fallu l'enlever pour nos tests, car le réseau était loria (152.81) de part et d'autre du firewall.
Facilement réalisable sur un routeur
broadcasts.
Il est facile de se protéger des broadcast, en rajoutant une règle. Ca fonctionne. Nous avons du le faire, car le réseau devant le firewall étant un réseau interne, beaucoup de broadcasts polluaient les logs (arp, bootp, netbios ...)
Facilement réalisable sur un routeur
--------------------------------------------------------------------------------
Les performances
Les tests de performances ont étés réalisés avec ttcp et netperf2.1pl1.
Voici les résultats :
Taille des paquets = MTU; test sur 30 secondes ou plus.
Commandes netperf :
netperf -l 60 -H hostname -t UDP_STREAM -- -m 41096 -s 32768 -S 32768
netperf -l 60 -H hostname -t TCP_STREAM -- -s 65535 -S 65535
Ces tests ont été éffectués dans un seul sens.
Tests unidirectionnels TCP UDP
Sans le firewall 90 94
Peu de règles (<10) 34 38
20 règles 32 29
40 règles 28 18
60 règles 27 18
80 règles 28 17
100 règles 30 15
2 tests éffectués simultanément, de la source(1) vers la destination(2), et en même temps de la destination vers la source.
Une seule valeur tcp, car elles sont sensiblement identiques.
Tests bidirectionnels TCP (1 = 2) UDP(1) UDP(2)
Sans le firewall 75 86 86
Peu de règles (<10) 30 4 26
20 règles 16 4 19
40 règles 15 3 14
60 règles 13 2 14
80 règles 13 2 13
100 règles 14 0 14
débits en fonction de la taille des paquets
en UDP
Taille des paquets Sans Firewall
débit (Mb/s) / % paquets perdus 20 Règles
débit (Mb/s) / % paquets perdus 60 règles
débit (Mb/s) / % paquets perdus
10 2.93 / 37.23 0.38 / 91.43 0.29 / 93.90
100 27.97 / 39.13 3.82 / 91.40 2.96 / 93.49
300 55.67 / 0.17 11.52 / 81.88 8.32 / 87.06
500 69.34 / 0 19.14 / 72.03 14.91 / 78.64
700 73.16 / 0 26.69 / 64.48 20.35 / 73.37
900 77.34 / 0 34.23 / 56.81 26.47 / 66.91
1100 84.57 / 0 42.50 / 49.31 31.97 / 62.93
1300 83.58 / 0 51.65 / 41.38 37.78 / 57.11
1400 85.10 / 0 55.60 / 37.43 41.47 / 53.32
en TCP
Taille des paquets Sans Firewall
débit (Mb/s) 20 Règles
débit (Mb/s) 60 règles
débit (Mb/s)
10 22.89 24.95 20.54
100 86.19 33.03 29.90
300 85.21 32.45 30.35
500 86.03 32.24 29.94
700 85.73 33.11 30.20
900 85.22 32.76 30.66
1100 87.42 32.91 30.17
1300 88.15 33.16 29.96
1400 87.76 32.22 29.48
conclusion provisoire
Il semble qu'au meilleur des cas, le firewall nous sort du 35 Mb/s. C'est faible. Cependant, nos tests TCP n'ont pas été éffectués avec l'option FASTPATH (bit establish). On peut gagner de l'ordre de 20 Mgs je pense en TCP. Concernant UDP, on reste à ces valeurs bien évidemment.
Le firewall semble perdre beaucoup de paquets lors de tests dans les 2 sens en même temps. Les perfs arrivent alors à l'ordre du Mega...
Concernant la charge mémoire, ces tests ne l'influencent pas. fw n'en prends pas beaucoup.
Concernant la charge CPU, la charge reste faible, même dans les très forts trafics (<1).
Seul le bus de la station semble être aussi à la source de ralentissement. Il n'a pas été possible de tester sur différentes plateformes matériel. Il semblerait qu'un ultra 2 (enterprise 2) permettrait d'avoir 50 Mb/s sans FASTPATH (source Checkpoint).
--------------------------------------------------------------------------------
Language inspect
FW-1 à la base est un language : inspect.
Tous les filtres, y compris les plus compliqués (ceux qui se négocient des ports comme ftp / ftp-data, netperf, etc...) sont decrits en inspect.
Le but est d'essayer de faire un script inspect pour un protocol nouveau, afin de voir si c'est réalisable ou pas (je sais, ca depends de nos connaissances, donc c'est pas gagné !). Ceci permettrait de pouvoir tenir compte assez rapidement de tous les nouveaux protocoles, dans le cas ou Checkpoint ne le ferait pas. Il faudrait bien sur s'y plonger.
Lorsque l'on définit les règles de sécurité depuis l'interface graphique un script INSPECT est généré. Ce dernier est ensuite compilé avant d'être chargé dans le module Firewall-1. Ce script est un fichier texte que l'on peut éventuellement crée avec un éditeur de texte classique pour définir une police de sécurité sans utiliser l'interface graphique.
INSPECT a été spécialement conçu pour FW-1. Ainsi, de nombreuses commandes permettent de mettre en oeuvre des commandes de filtrage (accept, reject, log...). Dans un souci de fiabilité et d'éfficacité, INSPECT dispose des caractéristiques suivantes :
Pas de boucle,
Pas de récursivité,
Pas d'allocation explicite de mémoire,
Une fonction ne retourne qu'une valeur,
Passage des paramètres de fonction par valeur.
Voici un exemple de règles écrites en langage INSPECT montrant la manière de filtrer des paquets :
#define ip_p [ 9 : 1]
define tcp { ip_p = 6 };
define udp { ip_p = 17 };
accept ( tcp, telnet or ftp ) or ( udp, snmp );
Avec cette " police de sécurité ", seuls les paquets TELNET, FTP et SNMP sont acceptés ; les autres sont rejetés.
#define est la directive du préprocesseur C,
define est une commende INSPECT qui évalue ses arguments.
accept ( tcp, telnet or ftp ),
(( ip_src = rhea ) or ( ip_src = cronos )),
( ip_dst = gaia );
Cette commande autorise uniquement les commandes telnet et ftp ayant comme source Rhéa ou Cronos et à destination de Gaïa.
De nombreuses macros sont prédéfinies dans le fichier fwui_head.def qu'il est possible d'inclure dans son script INSPECT, comme le montre l'exemple suivant :
#include 'fwui_head.def'
SRV_tcp (telnet, 23)
SRV_tcp (ftp, 21)
inbound all@gaia
accept // Action
( tcp, telnet or ftp ) // Services
( ip_src = rhea ) // Source
( ip_dst = cronos ) // Destinations
LOG ( long, LOG_NOALERT, 1 ); // Track
La règle spécifiée ici s'applique à toutes les interfaces d'entrée du Firewall (celui-ci est supposé être installé sur Gaia).
Une fois le script INSPECT défini, il faut le compiler et l'installer sur le firewall.
Utiliser la commande fwc pour compiler le script INSPECT.
Vérifier que le démon du firewall est en fonction. Le cas échéant, utiliser la commande fwstart pour démarrer le module Firewall.
Utiliser la commande fw load pour installer la police de sécurité sur le firewall
Vérifier que la politique mise en place respecte bien ce qui a été prévu
Mar 12 Fév - 11:12