Transcript BTS Services informatiques aux organisations Session 2014 E4
BTS Services informatiques aux organisations Session 2014 E4 – Conception et maintenance de solutions informatiques
Coefficient 4
DESCRIPTION D’UNE SITUATION PROFESSIONNELLE
Épreuve ponctuelle
Contrôle en cours de formation
PARCOURS SISR
NOM et prénom du candidat
Sébastien DESMARETS
PARCOURS SLAM
M326080595
Contexte de la situation professionnelle
remédier.
:
La Maison des Ligues de Lorraine (M2L) a pour mission de fournir des espaces et services à différentes ligues sportives de la région Lorraine. Ayant pris de l'ampleur, la M2L a vu son Système d'Information s'étoffer et se complexifier au fil du temps, ce à quoi elle veut Dans cette optique de refonte il a été fait appel à nous afin de sécuriser les accès au réseau informatique de l'organisation, de sorte à assurer un service sûr et de qualité, aux utilisateurs réguliers comme aux visiteurs de passage.
Intitulé de la situation professionnelle :
Pare-feu : sécurisation d'un Système d'Information & filtrage des flux de données.
Période de réalisation : Modalité :
Deuxième année de formation Individuelle
Lieu :
Infosup En équipe
Conditions de réalisation
(ressources fournies, résultats attendus) :
Ressources fournies : archive présentant le contexte M2L, produite par le CERTA ; Serveur : NEC,
Express5800/T120a-M
(bi-processeur Xeon, 7Go RAM DDR3, 1 To HDD SATA-II).
Résultats attendus : empêcher l'accès depuis l’extérieur (internet) aux machines et équipements présents sur le réseau interne, tout en maintenant disponible certains services spécifiques tels qu'un serveur Web ou un VPN.
Productions associées :
Fichiers de configuration & sauvegardes.
Modalités d’accès aux productions :
Il s’agit, par exemple, des identifiants, mots de passe, URL d’un espace de stockage et de la présentation de l’organisation du stockage.
www.sebastiendesmarets.fr
Présenter au verso une description détaillée de la situation professionnelle retenue et des productions réalisées en mettant en évidence la démarche suivie, les méthodes retenues.
1 2 3 4 En CCF, de l’étudiant.
À renseigner en cas d’épreuve ponctuelle.
Conformément au référentiel du BTS SIO, le contexte doit être conforme au cahier des charges national en matière d’environnement technologique dans le domaine de spécialité correspondant au parcours du candidat.
En référence à la description des activités des processus prévue dans le référentiel de certification.
BTS S.I.O.
option SISR session 2014 1/7
Sébastien DESMARETS
M326080595
Table des matières
I. Introduction 3 II. De l'utilité d'un pare-feu 3 4 IV.Mise en œuvre A. Prise en main & phase de tests B. Mise en production 5 V. Conclusion personnelle 6 [Annexe] Ressources et documentation 7
BTS S.I.O.
option SISR session 2014 2/7
Sébastien DESMARETS
M326080595
I – Introduction
Nous présentons ici l'un des projets réalisés dans le cadre de l'épreuve E4 de notre BTS S.I.O. option SISR. L'objectif est de mettre en place un pare-feu afin d'isoler de l’extérieur (le
) l'infrastructure réseau interne (le
) ainsi que les serveurs publics (la
Maison des Ligues de Lorraine, dans le cadre d'une refonte globale de son Système d'Information.
Nous considérerons rapidement le rôle d'un pare-feu, puis les grandes différences entre les solutions disponibles sur le marché.
Ensuite nous aborderons la mise en œuvre : les tests, puis l'implémentation sur le serveur mis à notre disposition.
Enfin nous verrons quelques réflexions personnelles, ainsi que des pistes potentielles.
II – De l'utilité d'un pare-feu
« Une adresse IP publique, c'est une porte qui donne sur la rue : il ne faut donc pas l'ouvrir au premier venu...» – parole d'Hébergeur La raison d'être d'un pare-feu est de cloisonner des réseaux (des zones de confiance plus ou moins fortes) pour empêcher toute connexion non légitime, c'est-à-dire non initiée par un utilisateur ou une application interne. Il s'agit donc d'une passerelle filtrante, qui permet en outre la mise en place d'une politique d'accès aux ressources du réseau.
Aujourd'hui nombre de *
box
internet, y compris grand public, intègrent des fonctionnalités de filtrage plus ou moins avancées allant du simple « tel ordinateur a-t-il le droit de passer : OUI / NON » jusqu'à pouvoir mettre en place des règles de transfert de port.
Néanmoins dans un contexte d’entreprise une telle solution montre ses limites : afin d'absorber le nombre de connexions et de permettre un filtrage plus fin, il est alors nécessaire de se tourner vers une solution dédiée, qui peut être logicielle ou matérielle.
Mini-serveur à part entière spécifiquement conçu autour cette tâche, un pare-feu matériel sera à même de traiter un flux de données très important mais les premiers prix sur le marché sont déjà conséquents. De plus le micrologciel est bien souvent propriétaire, et donc le code fermé : l'on est alors contraint de faire avec les options disponibles, ni plus ni moins (bien que l'on puisse se
tourner par exemple vers DD-WRT
, un micrologiciel libre basé sur un noyau Linux minimal, à la
condition que l'équipement soit supporté) : c'est une "boite noire", qu'il faut choisir avec soin lors du processus d'achat car il sera dificile d'en changer par la suite.
8 5 6 7 Un pare-feu logiciel peut être installé sur une machine quelconque, du serveur dédié au vieil ordinateur personnel même très peu puissant (idéal pour recycler une tour vieillissante par exemple) et peut offrir les mêmes fonctionnalités, parfois très avancées, de traitement des flux réseaux.
De plus dans le cas d'une solution libre il a l'avantage d'être modulable, s'adaptant ainsi à l'usage de chacun et sans autre coût que celui du matériel puisqu'
open-source
est souvent synonyme de gratuit.
Wide Area Network
ou réseau étendu, soit le réseau opérateur puis, par extension, internet (zone de confiance faible).
Local Area Network
soit le réseau local, propre à l'organisation (zone de confiance forte).
DeMilitarized Zone
ou zone démilitarisée, un réseau distinct du LAN où sont placés les serveurs qui doivent pouvoir être accessibles par internet (zone de confiance intermédiaire).
Site du projet : http://www.dd-wrt.com
BTS S.I.O.
option SISR session 2014 3/7
Sébastien DESMARETS
M326080595
III – Solutions disponibles
Comme évoqué plus haut l'idéal est une solution physique. De tels équipement sont disponibles au catalogue de nombreux fabricants : CISCO/Linksys, D-Link ou Netgear parmi les plus connus, mais aussi TP-Link,WatchGuard ou ZyXEL pour les plus exotiques. Nous l'avons vu, c'est l'option la plus robuste mais également la plus coûteuse.
Or une telle puissance de traitement n'est pas réellement nécessaire dans le cas de la M2L dont le réseau reste, somme toute, relativement modeste : une solution logicielle saura amplement remplir cette fonction. Par ailleurs la M2L possède en propre plusieurs serveurs, cette approche permettra ainsi de limiter les frais en réemployant l'une de ces machine déja à disposition.
Au delà de l'aspect idéologique, nous prendrons ici le parti d'exclure toute solution non libre au motif que de tels outils ne laissent pas la main sur l'ensemble des réglages possibles d'une part et sont soumis à licence d'autre part. Partant de là, deux approches sont donc envisageables : ◦ L'installation d'un OS vierge puis configuration des règles de filtrage "à la main" : ▪ base Debian / Ubuntu ▪ ▪ base Fedora / RHEL / CentOS base *BSD ◦ ▪ ▪ base Slackware etc.
Opter pour une distribution "clé en main" qui propose une interface graphique de gestion : ▪ ClearOS ▪ ▪ ▪ ▪ ▪ ▪ IPCop Firewall pfSense Endian Firewall mOnOwall Smoothwall
Nous nous retrouvons face à un très large panel, qu'il nous faut donc affiner : • Si pour un puriste l'administration d'un serveur ne peut se faire proprement qu'en ligne de commande, cela requiert de solides connaissances techniques. Or, notre mission s’arrêtant à la mise en place de la solution et non à son administration sur la durée, il faut que la solution retenue soit accessible à tout un chacun afin que la future personne en charge de l'administration puisse modifier aisément les règles mises en place pour les adapter aux futures évolutions du réseau de la M2L →nous excluons donc l'OS vierge et nous orientons vers une solution tout-en-un.
• • De telles solutions s'appuient sur des bases logicielles et/ou système d'exploitation différents →nous recherchons une distribution proche de ce que nous connaissons déjà.
La facilité de prise en main et d'utilisation est est bien sûr importante mais cela ne doit pas se faire au détriment de l'efficacité et/ou des fonctionnalités →il ne nous reste plus qu'à tester quelques candidats potentiels afin de nous faire une idée.
9 Voir par exemple fr.wikipedia.org/wiki/Liste_de_pare-feu , distrowatch.com/search.php?category=Firewall ou encore sourceforge.net/directory/system-administration/networking/firewalls
BTS S.I.O.
option SISR session 2014 4/7
Sébastien DESMARETS
M326080595
IV – Mise en œuvre
Nous avons finalement retenu IPCop Firewall
Pourquoi ce choix : ● ● ● base LinuxFromScratch et proche de Debian ="terrain connu" et gage de stabilité le moteur du pare-feu est iptable (identique à Debian) que nous avons justement étudié existe depuis longtemps (2001) =maturité & communauté d'utilisateurs importantes ● ● ● ● dernière mise à jour récente (3 avril 2014) =projet actif et réactualisé (important!)
téléchargée de nombreuses fois & bien notée sur SourceForge
=gage d'efficacité nombreux modules sont disponibles
pour affiner le traitement et/ou proposer d'autres
services (blacklists, proxy, système de détection d'intrusion, cache de téléchargement...) quantité de ressources en ligne tels que tutoriels, exemples ou vidéos
A. Prise en main & phase de tests
source.
Nous avons opté pour la virtualisation sous VirtualBox, solution la plus souple à nos yeux car simple à utiliser mais néanmoins puissante et disponible sous Windows & Linux puisqu'open Dès la fin de l'installation initiale nous avons dupliqué notre machine virtuelle afin de pouvoir facilement la restaurer en cas de besoin. Il nous est aussi possible de nous échanger nos VMs respectives, d'en avoir plusieurs versions en parallèle, ainsi que déployer toute son infrastructure en quelques clics, sur le principe d'un Cloud public...
Afin de coller au plus près à la situation finale nous avons donc créé directement une instance ayant 3 cartes réseau, réparties comme suit : • interface Rouge en accès par pont, qui prend alors classiquement son adresse IP via DHCP et est ainsi sur le même réseau que l'hôte qui l'héberge, • interfaces Vert et Orange en adressage statique (*.254 puisque c'est la passerelle) sur deux réseaux internes créés pour l'occasion et cohérents avec le plan d'adressage de la M2L, respectivement le 172.16.0.0/16 pour le LAN et 10.54.0.0/24 pour la DMZ.
Nous avons placé en DMZ un serveur web des plus basiques (debian+apache2="
It works!
") ainsi qu'un poste client dans le LAN (qui doit donc pouvoir accéder à internet et qui permet d'administrer IPCop via son interface web), notre hôte physique jouant le rôle du client sur Internet via par exemple un transfert du port 80 depuis l'interface Rouge vers l'adresse de notre WWW, qui tient lieu d'extranet.
B. Mise en production
Nous avons simplement utilisé la fonctionnalité de sauvegarde intégrée à IPCop pour transférer notre configuration du serveur virtualisé vers la machine physique, ainsi les règles de filtrage, les groupes d’hôtes et groupes de services que nous avons mis en place sont maintenus sans devoir refaire l'ensemble de la configuration.
Nous avons ensuite ajusté ces groupes d'hôtes, c'est-à-dire ajouté les adresses des machines de nos collègues une fois les différents projets mis en commun et connectés au sein de la nouvelle infrastructure afin d'effectuer le recettage et valider nos configurations respectives.
Comme évoqué plus haut il y a parmis les modules disponibles des options intéressantes mais nous avons manqué de temps pour les tester proprement et les implémenter sur notre configuration : si elle est fonctionnelle, elle n'en reste donc pas moins largement perfectible et ajustable aux besoins à venir.
10 11 12 ipcop.org
sourceforge.net/projects/ipcop sourceforge.net/p/ipcop/wiki/Addons - cobin.de/binary.php
BTS S.I.O.
option SISR session 2014 5/7
Sébastien DESMARETS
M326080595
V – Conclusion personnelle
Quelques problèmes rencontrés, du plus au moins gênants : • Flux à traiter : dans le contexte de la M2L, chaque groupe d'élèves s'est focalisé sur un service donné ; il nous a été difficile de connaître les adresses IP des hôtes du futur réseau (bien souvent définie à 192.168.0.1 dans un premier temps) afin de créer nos règles de filtrage. La solution a été d'utiliser non pas de l'adresse IP de l'hôte concerné mais en l'appliquant à un groupe d'hôte, complété par la suite.
• • • • Solution tout-en-un composant la distribution sans risquer de "tout casser" (problème d'ailleurs identique dans le cas d'un : impossible de mettre à jour soi-même l'un des modules ou programme
Control Panel
web, comme par exemple cPanel ou Plesk ). En cas de mise à jour de l'un des composants il est nécessaire d'attendre une mise à jour de l'ensemble de la distribution, ce qui n'est pas idéal d'un point de vue sécurité.
RAID : notre serveur a certes un disque de 1 Tio...mais il n'en a qu'un, nous exposant ainsi à une panne matérielle de ce dernier.
Virtualisation production du fait de la mutualisation d'un hôte entre plusieurs serveurs, un pare-feu est difficilement virtualisable car, le cas échéant, les différents flux réseau passent tous par la carte réseau de l'hôte physique.
Traduction : si cette approche est idéale en phase de test et permet de réduire les coûts en de l'interface parfois approximative : la laisser en anglais fait très bien l'affaire.
Ainsi quelques pistes à explorer : • Redondance : La solution que nous proposons n'est pas optimale car notre pare-feu constitue le point unique de défaillance (
SPOF
en anglais,
Single Point of Failure
) de cette infrastructure, clairement visible dans le schéma présenté ci-après : si pour une raison ou pour une autre le pare-feu venait à ne plus être disponible (panne matérielle, bug/plantage, attaque...) alors l'ensemble du réseau interne de la M2L serait isolé de l'internet et/ou que de la DMZ, ce qui peut être fortement problématique.
Ucarp permet cela, en partageant une adresse IP "virtuelle" entre plusieurs machines
faudrait un second lien vers internet dans le cas où la première *box "tomberait"...
◦ Gestion des fichiers de journalisation (point non exclusif à notre pare-feu) : De manière générale il est intéressant de pouvoir conserver au maximum les logs d'un serveur et plus encore d'un pare-feu, aussi bien pour du debug qu'à des fins de forensique dans le cadre d'une attaque. Néanmoins dans les faits cela peut rapidement occuper beaucoup d'espace disque, la taille de ces fichiers étant directement fonction des connexions transitant pas la machine.
Dans le pire des scénarios le disque en arrive à saturer : le système n'a plus de place pour ses opérations de routine et cela aboutit à un serveur totalement indisponible. Afin de palier à cela, il est important de placer le répertoire /var/log/ sur une partition distincte de /, ainsi même s'il advenait que les fichiers journaux saturent l'espace qui leur est alloué, le système ne sera pas impacté, il sera toujours temps de prendre la main sur ma machine (nb: c'est le cas par défaut sur IPCop).
De plus s'il est aisé de gérer les logs d'une seule machine, d'un serveur dévolu à ce rôle (via
rsyslog
l'ensemble des logs d'un coup d’œil, avec ou
syslog-ng logwatch
ou
tail -f
devient rapidement insuffisant lorsqu'il s'agit d'administrer l'ensemble d'un parc. On pourra envisager la mise en place ) qui centralisera et consolidera ainsi en un point unique les journaux des différents équipements de l'infrastructure. Cela permettra de consulter
par exemple, ainsi que d'en faire
des sauvegardes plus simplement qu'en passant machine par machine...
– (voir aussi
logrotate
) 13 14 pureftpd.org/project/ucarp www.8pussy.org
- - fr.wikipedia.org/wiki/Ucarp sourceforge.net/projects/syslog-analyzer/
BTS S.I.O.
option SISR session 2014 6/7
Sébastien DESMARETS
M326080595
Annexe – Ressources & documentation
Voici un schéma de la nouvelle infrastructure réseau de la M2, notre pare-feu se trouvant dans la zone blanche il est entre internet, le LAN et la DMZ : IPCop Firewall ▪ Ainsi que quelques sites internet sur lesquels nous nous sommes appuyés : startpage.com
// les résultats de Google, le tracking en moins ▪ distrowatch.com
// "annuaire" des distributions GNU/Linux ▪ frameip.com
& frameip.com/firewall/ // véritable mine d'informations ▪ wiki.korben.info/firewall__filtres_ip ▪ max-ipcop.blogspot.fr
▪ commentcamarche.net/contents/992-firewall-pare-feu & commentcamarche.net/contents/237-systemes-de-detection-d-intrusion-ids ▪ technet.microsoft.com/fr-fr/library/dd772723(v=ws.10).aspx
// ports requis pour AD ▪ fr.wikipedia.org/wiki/Liste_de_ports_logiciels ▪ it-connect.fr/configurer-des-transferts-de-ports-sur-ipcop/
BTS S.I.O.
option SISR session 2014 7/7
Sébastien DESMARETS
M326080595