|
Partie II : Mise en
place du firewall d’AQSACOM sous LINUX |
TABLE DES MATIERES :
1- Mise
en place de la maquette de test.
2- Mise
en place réelle dans l’architecture existante
a) Interconnexion des trois parties
b) ARP (Address Resolution Protocol)
c) Configuration du Firewall avec Bastille - ipchains/iptables
g)
Augmentation de la rapidité des connexions
h)
Service NNTP (Network News Transfer Protocol)
i)
Mise en place d’un filtrage d’URL
____________________________________________________
1. Mise en place de la maquette de test
a) Présentation
Dans un premier temps, j’ai du mettre
en place une petite maquette représentant l’architecture réelle pour faire
quelques tests. Cette architecture se trouve à la figure ci-dessous :
Figure 1 : Schéma de la maquette de test
Comme indiqué ci-dessus, la maquette de test est constituée par :
-
une
machine simulant Internet via un serveur http Apache.
-
une deuxième
simulant une machine du réseau interne de l’entreprise.
-
une
troisième simulant le "vrai" routeur Cisco que nous ne pouvons pas
utiliser dans le cadre de tests car ce dernier est déjà en place dans
l’architecture réelle.
-
une
quatrième simulant le Firewall.
-
et une
dernière servant de machine de supervision et se trouvant comme la machine 2
sur le réseau interne.
Toutes ces machines sont sous LINUX.
Remarque préalable : dans ce qui suit, je distinguerai Intranet et réseau
interne. L’Intranet sera le réseau de la
société tout entier, et décomposé dans ce cas-ci en une DMZ (regroupant les serveurs mail, ftp, http,
…dans le cas réel) et un réseau interne, comme le montre le schéma
suivant :
Figure 2 : Différence entre une DMZ, un Intranet et un réseau interne
On appelle DMZ (DeMitarized Zone)
un sous-réseau du réseau global à sécuriser (Intranet) comportant en général les serveurs http, ftp, POP3, SMTP, …, c’est-à-dire toutes les machines qui ne contiennent pas de données vitales
pour la société comme des serveurs contenant par exemple des fichiers clients,
les sources des produits en phase de développement, … ; et qui ne sont pas
les machines de travail des employés.
Il n’est cependant pas indispensable de configurer un Firewall comme le
montre la figure 1 ci-dessus, i.e. avec trois branches (Internet, réseau
interne et DMZ) ; et il se trouve aussi bien des Firewalls qui ne font
l’interface qu’entre l’Internet et l’Intranet à sécuriser (cf. Annexe 5)
que des firewalls qui ont une dizaine de cartes réseau comme j’ai eu l’occasion
d’étudier pendant mon stage de fin d’études à la Société Générale.
Cependant, au vu de la structure physique relativement simple de l’Intranet,
il est apparu préférable de segmenter l’Intranet en deux, DMZ et
"vrai" réseau interne, ce qui est généralement fait.
La mise en place d’une DMZ (avec un Firewall) présente les avantages
suivants :
1.
Possibilité de faire de la Traduction
d’adresse ou (NAT-Network Address
Translation), i.e.
les adresses privées ne sont pas visibles de l’extérieur car le routeur
remplace les adresses sources internes par l’adresse de son interface externe,
ce qui permet de garder les adresses internes secrètes et également de
dupliquer virtuellement les adresses IP.
2.
Filtrage des adresses IP pour bloquer un
trafic entrant/sortant.
3.
Isolation de la DMZ : isolement
physique des réseaux interconnectés. Un flux direct Internet/Intranet est
interdit.
4.
Définition des règles de filtrage
spécifiques à la DMZ et modifiables à tout moment sur le script de
configuration.
Par contre, les inconvénients les plus importants sont les suivants :
1. La
mise en place nécessite une infrastructure lourde en général, surtout si on met
en pace des redondances pour augmenter la sécurité ou pratiquer de la "load-balancing".
2.
Coût généralement élevé.
Dans un premier temps, le réseau sur lequel a été installé le Firewall a été sniffé à l’aide du sniffeur ETHEREAL qui est d’ailleurs
extrêmement bien fait, simple d’utilisation et gratuit. On rappelle que sniffer
revient à analyser le trafic qui passe sur ce réseau pendant un certain
laps de temps (le plus long possible dans notre cas pour avoir le meilleur
aperçu). ETHEREAL affiche alors le type, le nombre, et le pourcentage des
trames qui passent sur le réseau comme le montre la capture d’écran
ci-contre. Ceci nous permet de savoir quels sont les flux utilisés, de
manière à interdire les autres… et à ne pas interdire des flux utilisés! Plus de détails sur les services offerts par ce sniffer sont rassemblés
à la partie 5 de l’annexe 4.
b) Logiciels utilisés
En termes de logiciels, j’ai
installé sur les machines correspondantes les logiciels suivants :
-
Pour la supervision du trafic Ethernet : NTOP et WEBALISER
-
Pour la détection d’intrusions : SNORT
-
Pour les tests de robustesse du firewall par
attaques : SAINT
-
Pour la supervision des machines réseau
local : CHEOPS
-
Pour le sniffage en temps réel : les sniffers
ETHEREAL et ANALYSER.
-
Pour simuler le serveur HTTP (web) : APACHE
-
Pour simuler le serveur FTP : SQUID
Des captures
d’écran montrant ce que fait chacun de ces différents logiciels sont visibles à
l’annexe 4.
2. Mise en place réelle dans l’architecture existante
Figure 3 : Architecture finale avec Firewall
a) Interconnexion des trois parties
Elle est réalisée grâce
à l’ajout de routes statiques sur la machine Firewall. Concernant les machines
du réseau interne, la mise en place du Firewall est transparente, i.e. il n’y a
rien à changer du point de vue de l’utilisateur pour se connecter à Internet.
b)
ARP
(Address Resolution Protocol)
La segmentation du réseau en deux provoque un
petit problème au niveau de la résolution d’adresses ARP. En effet, une machine
du réseau interne ne pourra récupérer les adresses MAC des machines sur la DMZ
(et vice-versa) ainsi que celles situées sur le routeur car elles se situent
sur un autre domaine de diffusion MAC à cause du Firewall qui sépare la DMZ du
réseau interne. En effet, les requêtes du genre MAC ou ARP ne sont diffusées
que sur un sous-réseau donné, i.e. elle ne sont pas transmises par un firewall
par exemple… Ainsi, lorsqu’une machine de la DMZ (ou du réseau interne) envoie
une requête ARP, le Firewall doit se substituer aux machines n’appartenant pas
à ce segment et à qui la requête ARP est adressée en réalisant un proxy ARP et
donc en répondant à leur place. Ceci a été réalisé à l’aide d’un script
d’ipchains/iptables qui à l’origine sont des pare-feu (cf. ce qui suit).
c) Configuration du Firewall avec Bastille + ipchains/iptables
Pour avoir une sécurisation homogène du
système d’exploitation du Firewall, j’ai choisi d’utiliser les scripts Perl de
Linux-Bastille (InteractiveBastille.pl) qui va générer des règles de firewall
selon les réponses apportées à une série de questions. Toutefois, pour que
l’ensemble des règles de filtrage soit compatible avec l’architecture
tripartie, j’ai dû développer et rajouter un script de commandes
iptables/ipchains. En effet, les règles générées par Bastille ne sont adaptées
qu’à une situation où l’architecture est composée de seulement deux parties,
sûre et non sûre, ce qui n’était pas le cas ici ; d’où la mise en place de
ces iptables et ipchains modifiables à souhait.
Remarques:
1. Il
faut bien remarquer que Bastille n’est pas une nouvelle version de Linux, mais
un ensemble de scripts qui permet de mieux protéger son système contre des
vulnérabilités potentielles et de renforcer la sécurité de Linux. Les réponses
à ces questions dépendent évidemment du type de sécurité recherché, du niveau
de sécurité voulu, des habitudes et contraintes des utilisateurs de
l’entreprise, … Cependant, Bastille a un principal défaut pour l’utilisateur
non-expert : bien souvent, le choix aux questions est limité à oui ou non
alors que parfois il serait utile de pouvoir nuancer ; et certaines
questions sont trop pointues ou tout simplement inutiles dans mon cas…alors qu’une
réponse est obligatoire. A l’inverse, le script d’ipchains et d’iptables est
modifiable à souhait (rajouter des permissions ou en enlever relève presque du
"copier-coller"), mais requiert une meilleure compréhension de
l’écriture de ce script.
2. Il
est important de noter que le comportement du Firewall se situe au niveau du
remplissage des tables (partie 10 du script de configuration du firewall). Toute
modification ultérieure des règles de sécurité sera restreinte à cette partie,
ce qui est un avantage de rapidité et de facilité évident...nous ne devons pas
répondre à nouveau à toutes les questions de Bastille !
d) Proxy SQUID
J’ai installé sur la machine simulant la DMZ
le logiciel proxy SQUID, qui est un
proxy ftp/http. Cependant la contrainte de rendre ce proxy totalement
transparent pour les deux services n’a pu être honorée qu’en partie. Ainsi, à
ma connaissance et d’après ce que j’ai pu trouver sur Internet dans par exemple
les "FAQ" et les "HowTo", SQUID ne permet de réaliser
un proxy transparent que pour le service http (ce que j’ai fait). Par
conséquent, pour le service ftp, j’ai choisi d’autoriser dans un premier temps
l’accès direct entre le LAN et le WAN ; puis plus tard, lorsque la
solution globale sera éprouvée, de rendre le proxy transparent pour le service
ftp, en installant par exemple un autre logiciel pour remplacer le proxy ftp
SQUID. Le détail des scripts pour le proxy SQUID est ici.
e) POP3, SMTP et DNS
Pour les services POP3, SMTP et DNS, nous avons opté pour le relayage automatique sur le proxy sans traitement des trames. Pour cela, des règles de transformation d’adresses (NAT source et destination) ont été réalisées sur le proxy et le Firewall (cf. de nouveau les scripts ci-dessus).
f) Supervision
Une machine sous LINUX a été
installée sur le réseau interne pour servir de superviseur. Cette machine
permet d’avoir à tout instant des statistiques sur le nombre de connexions, qui
est connecté à quoi et quand, pendant combien de temps, les pics de connexions
à Internet sur une durée prédéfinie, le classement des sites les plus regardés,
les alertes en cas d’attaque, … le tout trouvé par WEBALIZER et NTOP.
g) La bonne nouvelle : l’augmentation de la rapidité des connexions
J’ai remarqué que la mise en place du Firewall a augmenté la rapidité lors
de connexions à Internet. Cela est dû au fait que les règles du Firewall ne
permettent que le trafic sélectionné et filtre donc tous les autre trafics par
défaut comme par exemple les requêtes NetBios
(occupant dans mon cas près de 70% de l’ancien trafic sur le réseau, et n’étant
pas utilisé vu que c’était plutôt TCP/IP), ce qui allège donc considérablement
celui-ci et permet entre autre des connexions beaucoup plus rapides à Internet.
h) Les mauvaises nouvelles : les services NNTP & HTTPs
Lors de la mise en
place de l’architecture sécurisée, un problème a été détecté. Ainsi, lors de
l’audit des services transitant entre l’Internet et le réseau local, le service
NNTP (les News) avait été omis. Par
conséquent, j’ai dû rajouter des règles de filtrage et de traduction d’adresse
sur le Firewall et le proxy pour permettre ce nouveau service.
Il en a été de même
pour le protocole HTTPS (version de http qui utilise SSL) qui est utilisé par certains serveurs pour permettre par
exemple à certains utilisateurs d’accéder à leur messagerie externe de façon
sécurisée (ex. : Hotmail ou Club-Internet) qui utilisent ce protocole.
J’ai donc dû autoriser son passage à travers le Firewall.
Ainsi, ceci montre
bien qu’une maquette ne montre pas forcément tous les problèmes qui peuvent
survenir lors de la mise en place de l’architecture réelle.
i) Mise en place d’un filtrage d’URL
J’ai aussi mis en
place un filtrage d’URL (qui est une des options de SQUID) pour restreindre
l’accès à Internet. Il fonctionne comme suit : lors de la connexion à
Internet, chaque mot mis dans l’URL va être comparé à ceux contenus dans une
liste modifiable de "mots interdits" (fichier Liste_mots_interdits.txt) qui se trouve sur la machine supportant
le proxy SQUID ; et dans le cas d’une similitude, une page d’erreur
personnalisée sera affichée sur le l’écran de l’utilisateur, lui annonçant que
l’accès à ce site lui est interdit. Cette liste est facilement trouvable sur Internet
par un moteur de recherche, et souvent mise à jour par un robot de recherche.
Il est possible sous
Microsoft Internet Explorer de configurer la page qui apparaîtra à l’écran de
l’utilisateur voulant se connecter à un site figurant dans la liste des sites
interdits. Il suffit d’aller, lorsque la fenêtre Microsoft Internet Explorer
est ouverte, dans :
"Tools/Internet Options/Advanced/ Show
Friendly HTTP error messages"
Le seul inconvénient
est qu’il faut répéter cette opération pour tous les ordinateurs où l’on veut
que cette page puisse s’afficher.
RAPPORT :
***
Le sniffage discret d’un réseau