Rapport de stage BTS...7 Rapport de stage BTS SIO 2 – SISR Guillaume de Brébisson L’ICOA n’a pas de chiffre d’affaire, le laboratoire produit du savoir et forme à la recherche

1 Rapport de stage BTS SIO 2 – SISR Guillaume de Brébisson

Rapport de stage BTS

Guillaume de Brébisson | Institut de Chimie Organique et

Analytique 12/02/2018 – 30/03/2018

Rue de Chartres 02.38.41.73.54 http://www.icoa.fr/fr

45100 Orléans


SOMMAIRE Remerciements …………………………………………………………………. 3 Introduction ……………………………………………………………………… 4 Présentation de l’Institut …………………………………………………… 5-8 Contexte et environnement ……………………………………………….. 9-12 Mise en place d’un serveur DHCP ………………………………………. 13-15 Script bash : génération du fichier de configuration ……………. 16-19 Outils et fonctionnalités ajoutés autour des serveurs DHCP … 20-22 Création d’un VLAN dédié aux imprimantes ……………………….. 23 Bilan …………………………………………………………………………………. 24-25


REMERCIEMENTS

Avant toute chose je voulais remercier mon tuteur, Monsieur Laurent ROBIN

d’avoir placé sa confiance en moi en m’acceptant en tant que stagiaire au sein de

l’institut ainsi que pour sa disponibilité et son aide durant ces semaines. Je tiens

également à remercier mon professeur Monsieur Jean-Luc MOUCHARD pour

m’avoir conseillé ce terrain de stage.

De plus je voudrais citer et remercier les personnes qui m’ont accompagné

et qui ont été disponibles en cas de besoin pendant ces sept semaines de stage :

Cédric MAFFRE et Nicolas DETTLING qui m’ont accueilli lors de la première

semaine de stage lorsque mon tuteur n’était pas présent et les semaines à venir

où j’ai pu compter sur eux pour m’accompagner et m’aider.

Un grand merci au service informatique (Laurent ROBIN, Nicolas

DETTLING, Cédric MAFFRE) pour leur accueil, leur bonne humeur et leur

gentillesse qui m’ont permis de m’intégrer facilement et rapidement ce qui m’a

permis de me sentir à l’aise pour travailler à leurs côtés.


INTRODUCTION

Dans le cadre de ma seconde année de formation en BTS SIO option

Solutions d’Infrastructures Systèmes et Réseaux, j’ai eu à effectuer un stage en

entreprise de 7 semaines (12 février au 30 mars) afin de valider cette seconde

année mais aussi l’ensemble de mon BTS.

J’ai donc effectué ce stage dans l’Institut de Chimie Organique et Analytique

d’Orléans dont je vais parler un peu plus en détail par la suite avant de développer

mes projets et tirer une conclusion de tout ceci.


PRESENTATION DE L’INSTITUT

Situation géographique

L’Institut de Chimie Organique et Analytique est situé à Orléans la Source

sur le campus de l’université ou est regroupé la faculté de lettres, de droit

économie gestion, de STAPS, de l’IUT GEA etc… à côté du pôle de Chimie.


PRESENTATION GENERALE DE L’INSTITUT

L’ICOA (dirigé par Pascal BONNET, qui a été élu par le personnel puis validé

par les tutelles pour un mandat de 5 ans) est un laboratoire de recherche sous les

tutelles de l’Université d’Orléans et du CNRS (UMR 7311), situé sur le campus de

l’Université et installé dans un bâtiment d’environ 4000 m². Le Laboratoire a pour

mission l’identification de nouvelles molécules bioactives pouvant trouver des

applications en thérapeutique (Médicaments) et en cosmétique (Produits de

beauté : activité plus récente).

La démarche scientifique s’étend de la conception de nouvelles structures par

modélisation moléculaire, à la synthèse de nouvelles molécules organiques

(composés hétérocycliques, dérivés de sucres et analogues de nucléosides), à

l’extraction du milieu naturel (plantes) par les techniques séparatives les plus

performantes et l’analyse par spectrométrie de masse, et à l’enzymologie, pour

connaître les récepteurs de certaines molécules bioactives.

L’ICOA est fortement intégré au niveau régional, par de nombreux partenariats

avec des pôles de compétitivité et des entreprises, et comme Laboratoire de

Recherche correspondant du CEA (LRC M09) et membre de la Fédération de

Recherche FR 2708 avec le CBM (UPR 4301). Le Laboratoire jouit d’une

reconnaissance au niveau national et international, grâce en particulier à son

importante productivité scientifique. L’ICOA est partenaire depuis 2012 de deux

Laboratoires d’Excellence en réseau (LABEX), SYNORG et IRON.

http://www.univ-orleans.fr/

http://www.cnrs.fr/

http://www.cea.fr/

http://fr2708.prod.lamp.cnrs.fr/

http://fr2708.prod.lamp.cnrs.fr/

http://www.labex-synorg.fr/

http://www.labex-iron.com/


L’ICOA n’a pas de chiffre d’affaire, le laboratoire produit du savoir et forme à la

recherche. La production est mesurée grâce aux publications, aux brevets fait par

les équipes.

Le laboratoire est « séparé » en 3 parties :

- Chémoinformatique, modélisation moléculaire : Ici c’est la phase de

conception d’un médicament, ils utilisent des protéines modélisées par des

biologistes, ils vont prendre des bibliothèques de plusieurs millions de

molécules qu’ils vont cribler sur la protéine. La protéine est la serrure et la

molécule est la clé. Ils vont sélectionner un certain nombre de molécule qui

vont interagir avec la protéine. Ici les chercheurs font eux même leur

algorithme de criblage. Ils utilisent la 3D sur leur poste et lancent leurs

calculs par des Clusters de CPU ou GPU.

- Chimie Organique : Ce sont ceux qui synthétisent les molécules, ils ont une

molécule cible qu’ils veulent « fabriquer ». Leur travail va être de trouver le

chemin de synthèse de cette molécule à partir de produits chimiques que

l’on trouve dans le commerce. Ils utilisent toutes sortes de réactions

chimiques, chaque réaction va transformer la molécule, entre chaque étape

le chimiste caractérise la molécule obtenue.

- Science Analytique : Correspond à la séparation, l’identification et la

purification de molécules dans un mélange complexe (extrait de plante par

exemple). Cela permet de travailler sur les produits cosmétiques mais peut

aussi intervenir dans la recherche anti dopage. Il s’agit de trouver les

substances actives dans un mélange de plante.


Entre 130 et 140 personnes travaillent à l’ICOA : environ 50 fonctionnaires

dont un peu plus de 30 enseignants chercheurs et chercheurs et le reste des non-

permanents (CDD, stagiaires, etc…).

Le budget de l’ICOA en 2017 était d’environ 5 463 852 € pour l’achat des

produits chimiques, l’entretien et l’achat des machines, etc…

Des financements peuvent être attribués si des projets de recherches intéressants

sont déposés.

Depuis 1990 le laboratoire a produit :

1630 publications :

o 1481 Articles à comité de lecture (rang A)

o 67 Articles à comité de lecture (rang B)

o 24 Chapitres de livre et Livres

o 49 Actes de colloque

o 9 articles de vulgarisation

3364 Communications :

o 285 Conférences

o 368 Communications orales

o 944 Communications par poster

o 1755 Communications non classées (1990-2007)

76 Brevets

231 Thèses

22 Habilitations à diriger des recherches

16 Mémoires CNAM

4 Thèses d’état Marocain


BESOIN INFORMATIQUE DE L’ICOA

L’ICOA passe en ZRR (Zone à Régime Restrictif), cette zone est définie pour

protéger certains intérêts de l’état que ce soit dans des laboratoires, dans le milieu

militaire etc… Avec ce passage en ZRR l’ICOA a pour consigne de passer son réseau

à un niveau de sécurité élevé et d’être équipé au mieux. L’équipe informatique

cherche donc à améliorer son réseau et à l’enrichir au niveau des services et de la

gestion. Cela se fait par des services de gestion de parc, de supervision, de gestion

de logs etc… Cependant chaque chose se fait petit à petit il n’est pas possible et

pas conseillé de tout faire en même temps.

Pour ma part j’ai dû monter un serveur DHCP pour faciliter la gestion des

adresses IP sur le réseau.

QUELLE SOLUTION CHOISIR ?

Windows :

Avantages :

Facilité d’installation, de gestion via l’interface graphique

Inconvénients :

Prix, Sécurité moins élevée

Linux :

Avantages : Plus d’outils disponibles, 100% gratuit, meilleure sécurité, client léger

Inconvénients : Prise en main de l’interface en ligne de commande et des

commandes.


SOLUTION CHOISIE

A regarder il y a beaucoup plus de raisons de choisir une solution Linux pour

monter notre serveur DHCP et c’est la solution qui a été retenue principalement

car l’Institut cherche à utiliser des solutions gratuites dès que possible. Le choix

de la distribution s’est penchée sur Debian 9 (Stretch) en partie car j’avais toutes

les connaissances sur celle-ci et que l’équipe informatique n’avait pas de machine

Linux Debian encore, c’était pour eux l’occasion de découvrir.

ENVIRONNEMENT

L’ICOA héberge ses serveurs grâce à la virtualisation via VMware vSphere.

VMware vSphere est un logiciel d'infrastructure de Cloud Computing de

l'éditeur VMware. VMware vSphere constitue un composant nécessaire de vCloud

Suite pour le Cloud Computing, comprend un grand nombre d’éléments, en voici

une petite liste qui peut être largement complétée :

VMware ESXi – Hyperviseur qui virtualise les processeurs, la mémoire, le

stockage, ainsi que d'autres ressources dans plusieurs machines virtuelles.

VMware vCenter Server - Point de contrôle central destiné aux services du Da-

tacenter, tels que le contrôle des accès, la surveillance des performances.

VMware vSphere Client - Permet aux utilisateurs de se connecter à distance à

ESXi ou à vCenter Server, depuis n'importe quel PC Windows.

https://fr.wikipedia.org/wiki/Cloud_computing

https://fr.wikipedia.org/wiki/VMware

http://www.lemagit.fr/definition/Cloud-computing

http://www.lemagit.fr/definition/ESXi-VMware

http://www.lemagit.fr/definition/Hyperviseur-de-type-1


LES AVANTAGES DE LA VIRTUALISATION

La virtualisation est de plus en plus utilisée nous allons donc voir quels sont ses

avantages mais aussi ses inconvénients :

Elle permet de diminuer le nombre de machines physiques, ce qui entraine un re-

tour sur investissement intéressant :

- En terme d’espace nécessaire, un serveur capable de faire fonctionner dif-

férents systèmes d’exploitation sur une seule machine réduit en moyenne

de moitié l’espace réservé aux serveurs dans une entreprise.

- En plus de cette réduction de place, la diminution du nombre de machines

physiques entraine une réduction de la consommation électrique.

- Enfin, moins de machines veut dire moins de contrats de supports matériels

(souvent très cher sur les serveurs, où la maintenance doit intervenir rapi-

dement en cas de panne matérielle).

En plus de ces avantages, la virtualisation permet une gestion simplifiée du parc serveurs.

- La virtualisation permet de réduire le temps et le coût souvent élevés con-

sacrés à l’administration des serveurs. La gestion du parc machine est plus

facile, ce qui allège la charge des administrateurs.

- Elle simplifie la mise en place de plateformes de tests ou de production en

réduisant le temps de mise à disposition d’un serveur.

- Enfin, elle augmente la disponibilité des serveurs avec une reprise d’activité

plus rapide que pour une machine physique.

- Elle permet un réseau plus sécurisé. En effet, la machine hébergeant les sys-

tèmes virtuels n’est pas visible par l’attaquant.


LES INCONVENIENTS DE LA VIRTUALISATION

- La mise en œuvre de la virtualisation induit une complexité de gestion et

apporte son lot de risques inhérents au “tout virtuel”. C’est une autre façon

d’organiser son parc informatique, qui peut demander un temps d’adapta-

tion.

- Un autre problème se pose : la gestion des données. Comment en effet re-

trouver ses données quand elles sont partagées sur plusieurs disques phy-

siques, mais stockées sur des volumes logiques ? Il faut absolument faire

une cartographie détaillée à un instant T de ses données. Les LUN (Logical

Unit Number) doivent être normés, avoir un nom et un numéro.

- Si la machine qui héberge tous les OS s’arrête ou si la montée en charge

d’une application est flagrante, la situation va vite être critique.

- Pour une virtualisation redondante il est capital de dupliquer les machines

virtuelles. Dans tous les cas la virtualisation n’est pas à prendre à la légère

et doit être mûrement réfléchie.


MISE EN PLACE D’UN SERVEUR DHCP SOUS LINUX

Dans le cadre de mon stage il m’a donc été demandé de monter un serveur

DHCP afin de faciliter la gestion des adresses IP sur le réseau. Mon projet principal

était donc de monter un serveur DHCP cependant celui-ci doit être basé sur une

association d’adresse IP fixée sur une adresse MAC afin de viser un niveau de sé-

curité plus élevé. Mise à part les adresses IP à attribuer il faut indiquer les DNS

utilisés et la passerelle bien sûr.

Lors de ma première semaine je me suis penché sur l’installation de Debian

et du service DHCP en « mode classique » sur les machines virtuelles afin de

m’adapter à l’environnement et de voir les problèmes que je pourrai rencontrer,

voir les obstacles à la mise en place du service au sein de l’institut.

J’avais à la base 2 machines virtuelles à ma disposition dont une me servant

de test et l’autre qui devait être la machine finale qui confirmait mes tests. J’ai donc

installé le service DHCP en le mettant sur le réseau principal de l’institut puisque

j’avais un poste Windows sur ce réseau qui me permettait de vérifier l’attribution

du DHCP. Au fil de la semaine je me suis vite rendu compte que le pare-feu général

de l’institut bloquait des requêtes, il a donc fallu étudier les règles de pare-feu afin

de rencontrer le moins de problème possible par la suite.

Après avoir réglé le problème du pare-feu et notamment les requêtes DHCP

via le port 67 et 68 j’ai pu attribuer le DHCP sur le réseau sans problème. Je me

suis orienté vers l’autre aspect du DHCP que j’allais devoir mettre en place qui est

donc de faire du DHCP « fixe », c’est certes un peu contradictoire avec la notion de

DHCP mais c’est bien comme ça que ce que je devais faire est défini. Pour cela j’ai

pris le même poste de test, j’ai récupéré l’adresse MAC de la carte réseau et je lui

ai attribué une IP souhaitée. Cela m’a permis de découvrir un nouvel aspect du

service DHCP, une nouvelle façon de le configurer, une syntaxe différente et une

organisation différente puisque qu’il faut bien sûr récupérer toutes les adresses

MAC des postes par la suite. Après quelques recherches j’ai pu vite comprendre

comment déclarer une IP à une adresse MAC, la syntaxe est la suivante :


host exemple1 {

hardware ethernet 11:11:11:11:11:11;

fixed-address 192.168.1. 1;

}

Il faut donc à la suite de la déclaration du réseau insérer 4 lignes afin de définir un

seul hôte sur le réseau (en rouge ce qu’il faut changer pour chaque nouvel hôte) :

- La première ligne correspond à un repère, le nom que l’on donne pour sa-

voir quel hôte recevra l’IP, dans mon cas j’ai pris le nom donné à l’ordinateur

directement.

- La deuxième ligne correspond à l’adresse MAC de la carte réseau sur la-

quelle on va fixer une adresse IP

- La troisième ligne permet de définir l’adresse IP voulue sur l’adresse MAC

précédemment inscrite.

- La dernière ligne permet juste de finir la déclaration de l’hôte.

Après que mes tests se soient montrés concluants j’ai proposé de prendre mon

serveur de test comme DHCP secondaire afin de faire de la tolérance de panne. Je

suis donc reparti du DHCP en déclaration de réseau classique pour pouvoir tester

si déjà la tolérance de panne se faisait bien dans un cas de base. J’ai pu voir que

cela fonctionnait, j’ai donc testé de le mettre en place sur ma déclaration d’hôte

par adresse MAC, après quelques problèmes dans la syntaxe j’ai pu voir que tout

fonctionnait également dans ce cas.

C’est par la suite que j’ai dû m’intéresser un peu plus en profondeur au ré-

seau de l’institut, en sachant qu’il possède plusieurs plages d’adresse IP diffé-

rentes, j’ai dû me pencher sur un souci d’attribution du DHCP sur plusieurs ré-

seaux différents. Il faut savoir que mon serveur est placé sur un réseau dédié à la

gestion et qu’il fallait distribuer le DHCP sur 3 autres réseaux par la suite. Pour

cela nous avons mis en place sur le routeur de l’institut le « relay dhcp » permet-

tant via certaines interfaces de transmettre les requêtes vers le serveur. C’est-à-

dire que les réseaux (autres que celui du réseau où se trouve mes serveurs DHCP)


vont envoyer les requêtes à une interface puis elle va les rediriger vers le bon ré-

seau. Sur le pare-feu il suffit donc d’installer le paquet « dhcrelay » et dans un fi-

chier spécifique rentrer une ligne avec l’adresse du ou des serveurs DHCP puis

derrière les interfaces qui vont écouter les requêtes et les retransmettre au(x) ser-

veur(s). Par la suite j’ai pu essayer d’attribuer mes adresses sur les autres réseaux,

et cette simple manipulation l’a permis.

Une fois tous les tests réalisés : DHCP de base, DHCP basé sur l’adresse MAC,

tolérance de panne dans les deux cas, DHCP qui passe à travers les réseaux. J’ai

commencé l’écriture des fichiers de configuration, il a fallu que je récupère les

adresses IP des postes sur les différents réseaux. Pour cela j’ai utilisé le logiciel de

gestion de parc GLPI qui est présent à l’institut. Grâce à cet outil j’ai pu rechercher

chaque poste par réseau, et en tirer leur nom, leur adresse MAC ainsi que l’IP sans

besoin particulier de me déplacer. Les informations sont remontées grâce au plu-

gin FusionInventory déployé sur les postes par GPO dans le cas des machines Win-

dows. J’ai donc tapé à la main les 4 lignes que j’ai indiquées plus haut pour chaque

hôte en plus de la déclaration du réseau. On verra un peu plus tard qu’une solution

a été trouvé afin de simplifier pour le service informatique la création du fichier

de configuration et sa gestion.

Pour le déploiement des postes en DHCP il a fallu passer sur environ 130

machines dans les bureaux et les laboratoires et le faire à la main. Un compte ad-

ministrateur du domaine m’a été créé afin d’accéder aux paramètres IP sans quoi

je ne peux rien faire. La manipulation sur l’ordinateur est très rapide donc le dé-

ploiement qui peut paraître fastidieux s’est déroulé assez facilement sur 2 jours

en sachant que la plupart du temps je suis intervenu sur les postes quand les em-

ployés ou les étudiants travaillaient dessus. En 3 ou 4 minutes en restant sur la

session active s’il y en a une, je change le mode d’adressage IP en rentrant mon

compte administrateur du domaine quand il est demandé puis je vérifie l’attribu-

tion des DNS de la bonne connexion au serveur, l’accès à internet et ce qui se passe

si je relâche l’adresse IP et que je la récupère à nouveau.


SCRIPT PERMETTANT LA GENERATION DU FICHIER DE CONFIGU-

RATION DU DHCP

Comme je l’ai déjà dit j’ai commencé par écrire les fichiers de configuration

à la main, une fois terminé nous voulions mettre en place un moyen de générer les

fichiers de configuration, du serveur DHCP principal et du secondaire, qui sont

différents à quelques lignes près. Mon tuteur a pensé à un script qui irait chercher

dans un fichier .csv les noms d’hôtes, les adresses MAC et les IP et les mettre dans

les bonnes lignes. J’ai donc réalisé un script bash permettant de répondre à cette

demande.

Avant tout il faut un fichier .csv par réseau, pour cela il j’ai créé un fichier

Excel par réseau contenant 4 colonnes :

- La première colonne contient les noms des ordinateurs

- La deuxième les adresses MAC

- La troisième la partie hôte de l’adresse IP (seulement la partie hôte pour

trier sous Excel plus facilement).

- La dernière contient seulement un espace. Ceci est obligatoire dans mon

script pour que la syntaxe du fichier de configuration soit respectée.

Dans tous les cas il faudra donc ré écrire tous les hôtes et toutes les adresses dans

un fichier Excel mais cela simplifiera la gestion et la visualisation des postes du

réseau de plus pas besoin de recopier les mots clés devant les adresses etc…

Voilà un exemple de fichier Excel correspondant aux colonnes à rentrer :

Ne pas oublier l’espace

dans la colonne D


Pour mieux comprendre ce que va écrire le script voici un exemple de fichier de

configuration dhcpd.conf :


Dans cet exemple on à notre fichier de configuration du DHCP principal avec plu-

sieurs parties distinctes, la première sert à déclarer le «Failover», c’est ici que la

différence se fait entre le fichier de configuration du premier serveur ou du se-

cond. Vient ensuite la déclaration d’un premier réseau et ses options avec ensuite

la déclaration des hôtes. Ici j’ai mis la déclaration d’un deuxième réseau avec des

hôtes.

C’est donc tout ceci (avec plus de réseaux et beaucoup plus d’hôtes) que

notre Script doit écrire. Pour les champs qui ne change pas comme la déclaration

du Failover, on utilisera la commande « echo » afin d’afficher simplement ce que

l’on veut. Idem pour les déclarations des réseaux. La partie intéressante du script

se fait sur la déclaration des hôtes d’un réseau. Dans notre script nous allons faire

grâce à une boucle « while » cette déclaration.

while IFS=";" read Nom MAC IP

do

echo "

host $Nom {

hardware ethernet $MAC;

fixed-address 192.168.1.$IP

}"

done < monficher.csv >> dhcpd.conf

En résumé cette boucle dit que : tant que sur une ligne il y a des valeurs

séparées par un point-virgule (valeurs dans notre fichier csv correspondant à un

hôte) il faudra lire les variables $NOM $MAC et $IP et les réattribuées sur les lignes

indiquées. De plus on fait un « echo » des mots clé pour respecter la syntaxe du

fichier de configuration.

Après avoir testé le script pour un et plusieurs réseaux, nous voulions tota-

lement automatiser la génération. L’idée est de mettre ce script dans un script. La

condition pour exécuter le script qui viendra générer le fichier et écraser l’ancien


est comparer l’heure et la date à laquelle a été importé le fichier csv avec l’heure

et la date de la machine.

Pour être plus clair, le script s’exécutera automatiquement chaque heure

(nous verrons comment le script se lancera chaque heure plus loin dans le rap-

port) pour vérifier la condition suivante : si le fichier csv d’UN SEUL des réseaux

présents dans le script a été importé sur le serveur dans un répertoire précis il y

a moins d’une heure alors le script lancera l’écriture du nouveau fichier de confi-

guration et redémarra le service DHCP. Dans le cas contraire j’ai choisi d’écrire

dans un fichier nommé « rapport » un message disant que le fichier de configura-

tion n’a pas été changé, car le script ne respectait pas les conditions à telle heure.

Concernant la comparaison des heures, j’ai choisi une méthode qui retourne

une valeur, une suite de chiffres qui correspond au nombre de secondes écoulées

depuis le 1 er janvier 1970. Cette valeur est comparée à l’heure actuelle de la ma-

chine moins une heure. Cela permet de savoir si le fichier a été importé il y plus

ou moins d’une heure.

Pour comprendre la comparaison elle se fait avec la commande : stat –c %Y

fichier.csv (pour le fichier) qui retourne donc une suite de chiffre et on la compare

en disant que si le chiffre retourné est supérieur à la valeur retournée par la com-

mande : date +%s -d 'today - 1 hour' (qui donne une suite de chiffres correspon-

dant à l’heure de la machine moins une heure) alors le script effectue sa tâche.

En résumé de ce script, il permet d’automatiser complétement la génération

du fichier de configuration. La seule à faire et de modifier un ou plusieurs csv lors-

que l’on veut retirer, modifier ou ajouter un hôte sur le réseau, puis retirer du ser-

veur l’ancien fichier csv et enfin ajouter le nouveau (à l’aide de FileZilla par

exemple). Par la suite le script se lancera toutes les heures et saura que le fichier

a été importé récemment pour ré écrire le fichier de configuration.

Autre chose à modifier si l’on veut ajouter un nouveau réseau ou retirer un

réseau, il faudra juste modifier une petite partie du script qui n’est pas très com-

pliqué, il faut juste prendre exemple sur le bloc de déclaration d’un réseau et chan-

ger quelques adresses.


PRÉSENTATION DES OUTILS MONTÉS AUTOUR DU SERVEUR

I) FIREWALL BUILDER

Firewall Builder est un logiciel permettant de gérer son ou ses pare-feu grâce

à une interface graphique. Celui-ci permet une meilleure visualisation des règles,

une meilleure compréhension et une meilleure gestion. Il existe bien sûr des pare-

feu présent sur le réseau de l’institut cependant il m’a été demandé de faire des

règles de pare-feu directement sur mes serveurs Linux afin d’assurer d’autant plus

de sécurité.

Concernant la mise en place du logiciel, il faut bien sûr avoir le logiciel installé

sur une machine Windows où l’on paramétrera toutes nos règles. Sur nos serveurs

Linux il va falloir réaliser plusieurs étapes pour le bon fonctionnement par la suite.

Tout d’abord on crée un répertoire nommé « fwbuilder » avec un fichier ou sera

contenu un script lors de l’envoi des règles sur le serveur. Par la suite on attribut

les droits sur le répertoire à un nouvel utilisateur que l’on créé. On modifie ensuite

le fichier rc.local qui va permettre d’exécuter le Script au démarrage pour appli-

quer les règles de pare-feu. Par la suite il faudra faire quelques paramétrages sur

le logiciel, comme par exemple rentrer l’adresse du serveur, l’utilisateur qui va ap-

pliquer les règles etc…

Une fois sur le logiciel on peut créer comme on veut les règles mais il faut créer ce

dont on a besoin : les hôtes, un groupe de machine, les interfaces etc…


Sur l’image (prise sur internet pour des raisons de confidentialités de l’en-

treprise) on peut voir à quoi ressemble l’interface. A gauche il y a un menu ou est

regroupé les hôtes, les interfaces, les adresses réseau etc… Au centre on a la visua-

lisation des règles que l’on fait avec tous les éléments qui les composent : source,

destination, le service que l’on prend dans le menu de gauche ou alors que l’on

crée, le sens, l’interface, l’action : refusé ou accepté. On peut même ajouter des

commentaires pour chaque règle pour vraiment se repérer. Une fois nos règles

créées on les compiles et les envoie par SSH sur le serveur.

Cet outil a été très pratique car il m’a permis de vraiment visualiser mes

règles, ce qui permet un gain de temps. Je m’en suis servi pour accepter certains

postes en connexion SSH, pour accepter les communications entre mes deux ser-

veurs, pour accepter les requêtes DHCP mais aussi accepter la synchronisation

avec les serveurs NTP, la recherche DNS, l’envoi de mail etc… De plus pour les

mises à jour et la sortie sur internet, j’ai paramétré une plage horaire (une colonne

« time » est présente sur l’interface) qui va permettre de faire les mises à jour à

une certaine heure comme ça les machines restent le moins possible exposées sur

internet.

II) CRONTAB

Crontab est un programme de Linux permettant de planifier certaines tâches.

Juste avant j’ai parlé de la sortie des machines sur internet à certaines heures pour

faire les mises à jour. Cette plage horaire est synchronisé en fait avec la commande

de mise à jour que j’ai rentré dans le fichier « crontab –e ». J’ai rentré l’heure à

laquelle la commande « apt update && apt upgrade –y » doit se lancer, comme ceci

pas besoin de faire les mises à jour manuellement juste de vérifier qu’elles se sont

bien faites à la limite.

J’ai également évoqué le fait que mon script afin de générer le fichier de con-

figuration se lançait automatiquement, c’est également grâce à cet utilitaire que

j’ai pu faire ceci. J’ai rentré que chaque heure la commande « bash /ScriptDHCP »

devait se lancer.


III) SORTIE VIA PROXY

Un point rapide sur une demande qui m’a été faite, la sortie sur internet de mes

serveurs via le proxy que l’institut utilise. J’ai donc dû modifier quelques fichiers

afin que mes serveurs passent bien par le proxy pour les connexions internet.

IV) LOGWATCH

Logwatch permet une remontée des logs localement sur le serveur mais aussi

grâce à l’envoi de mail. Dans mon cas cela envoie chaque jour par mail un certain

nombre de log : les connexions SSH effectuées sur les serveurs, le rapport IP-

TABLES qui remontent les informations des règles de pare-feu, les paquets accep-

tés et refusés, les connexions par les utilisateurs ou l’administrateur sur la ma-

chine, l’espace disque total et restant. Cela permet d’avoir les informations par

mail plus visiblement chaque jour mais également de supprimer les logs sur le

serveur pour ne pas qu’il y en ai trop. Logwatch peut être paramétré de façon à ce

que l’on puisse voir des logs sur certains services.

V) POSTFIX

Postfix permet le transfert des mails. On peut paramétrer des redirections.

Dans mon cas j’ai utilisé Logwatch et chaque jour un rapport est envoyé par

mail, il a fallu l’installer et le paramétrer rapidement pour que l’envoi de mail

soit opérationnel.


CREATION D’UN VLAN DEDIÉ AUX IMPRIMANTES

Après la mise en place de mon serveur DHCP, des outils autour de celui-ci

ainsi que du script pour le fichier de configuration il m’a été demandé de créer un

VLAN qui sera dédié aux imprimantes ainsi que de les passer sur un autre ré-

seau et les passer en configuration DHCP pour plusieurs raisons : cela permettra

de libérer un certain nombre d’adresse IP sur leur réseau principal qui a besoin

de place et puis pour une question de sécurité.

J’ai donc effectué cette tâche en relevant d’abord toutes les imprimantes

connectées au réseau (25 environ) encore une fois grâce à GLPI, relever leur nom,

adresse IP et leur adresse MAC. De plus je suis allé relever le nom des prises réseau

où étaient connectées chaque imprimante. En les changeant de réseau je garde la

même partie hôte des adresses IP puis je les associe à l’adresse MAC pour mon

DHCP.

Avant tout j’ai créé le VLAN sur les Switch nécessaires. Après avoir rentré

les adresses dans mon DHCP à l’aide de mon script j’ai pu passer sur chaque im-

primante une par une pour d’abord les passer en DHCP. Avant le passage de

chaque imprimante en DHCP il fallait les changer de VLAN et donc repérer grâce

aux plans des Switch le port ou était connecté l’imprimante grâce à la prise relevée

plus tôt. On taguait le port pour qu’il soit dans plusieurs VLAN afin qu’il puisse

communiquer avec les postes sur l’autre réseau / VLAN. Une fois fait je passe sur

l’imprimante, dans les configurations je change le mode d’adressage IP, je vérifie

si la nouvelle adresse est prise sinon je redémarre l’imprimante. Dans la plupart

des cas il fallait redémarrer pour bien prendre en compte tous les changements.

Quand l’adresse est prise on teste que l’on peut imprimer dessus, pour cela il faut

d’abord ajouter dans l’annuaire l’imprimante car elle a changé d’adresse IP. Sur

les postes des employés on regarde s’il faut ou non la réinstaller.

Il y a un cas spécifique ou il fallait faire encore plus de modifications. Pour

les copieurs qui envoient les documents scannés directement par mail, il fallait

modifier l’adresse de l’imprimante sur le pare-feu pour le protocole SMTP et pour

la recherche DNS.

A noter que les modifications sur les Switchs pour les ports etc… se faisaient via

une interface graphique (petit serveur web) du switch.


BILAN DES PROJETS :

Mes projets ont tous été réalisés dans les temps. Concernant les serveurs

DHCP, l’ensemble des réseaux ont été passés en adressage dynamique à l’excep-

tion de quelques postes que l’on a dû laisser en configuration statique car ils ser-

vent à la manipulation de machines spécifiques et il est préférable de ne pas y

toucher. De plus toutes les tâches autour du DHCP (pare-feu, gestion des logs,

scripts) ont été réalisées comme l’a souhaité mon maître de stage. Pour le VLAN

correspondant aux imprimantes rien à redire tout s’est déroulé correctement sans

trop de souci.

Dans l’ensemble j’ai mis quand même un peu plus de temps que ce que j’au-

rai pensé mais l’intervention dans un cadre réel et professionnel permet de voir

les obstacles que l’on peut rencontrer et il faut surtout prendre le temps de bien

comprendre et corriger ces obstacles.

J’ai remis au service informatique tous les mots de passe nécessaires, toutes

les documentations qui ont été revues par le personnel et qui ont été validées par

rapport à leur contenu.

BILAN PERSONNEL :

A première vu mon sujet principal de stage est un sujet assez basique et

simple à mettre en place. Cependant il a été intéressant et enrichissant pour les

raisons déjà évoquées :

- Le nouvel aspect du DHCP que j’ai pu mettre en place, un DHCP basé sur les

adresses MAC qui m’a permis de découvrir un peu plus de fonctionnalité

qu’un DHCP classique m’a permis de comprendre les différences dans la

syntaxe du fichier de configuration et les éléments à prendre en compte

dans ce genre de cas. Avec cette méthode je pense avoir vraiment une con-

naissance assez complète du DHCP.


- Cet aspect du DCHP qui m’a permis également de faire un Script Bash pour

générer un fichier de configuration. Ceci permet de découvrir aussi l’utilité

de l’automatisation de certaines choses dans le milieu de l’entreprise pour

faciliter la gestion mais également de voir comment récupérer des informa-

tions d'un fichier csv.

- Le cadre professionnel et réel qui m’a permis de vraiment me mettre dans

des conditions d’entreprise ce qui permet de vraiment découvrir même

pour ce genre de service basique les obstacles et faire bien attention à tous

les détails avant de passer aux tests et à la mise en production.

- Tous les outils encore une fois que j’ai énumérés. Tous ces outils m’ont per-

mis de découvrir pas mal de choses qui me seront certainement utiles dans

le futur pour d’autres situations.

Documents

Rapport de stage BTS...7 Rapport de stage BTS SIO 2 – SISR Guillaume de Brébisson L’ICOA n’a pas de chiffre d’affaire, le laboratoire produit du savoir et forme à la recherche