!

Filtrage réseau
Partie 1!
!
SWRAD - 22 novembre 2013!
!
!
CAMUS Yann-Pierrick!
!
!
!
!
!
!

FILTRAGE RÉSEAU - PARTIE 1 1

 Cri$ques  de  l’architecture  et  risques  associés  
!
!
Injec$on  SQL  

!
a. Vulnérabilité  

Le  site  internet  peut  être  exploité  afin  d’obtenir  des  informa9ons  de  la  base  de  données.  

b. Scénario  

Le  script  PHP  du  site  internet  pourrait  perme>re  d’obtenir  le  nom  d'un  client  dans  la  base  de  données.  Le  
nom  est  passé  d'une  page  à  l'autre  par  l'intermédiaire  de  l'URL  (par  $_GET).  On  pourrait  injecter  la  
requête  :  UNION  SELECT  name  FROM  clients  WHERE  id=1  dans  l’URL  afin  de  récupérer  les  informa9ons.  

c. Besoin  de  sécurité  violé  

Ce>e  vulnérabilité  viole  plusieurs  besoins  de  sécurité  :  confiden9alité  et  intégrité.  Un  a>aquant  pourrait  
facilement  modifier,  ajouter,  supprimer  ou  lire  des  informa9ons  contenu  dans  la  base  de  données.    

d. Proposi9on  

Il  faut  avant  tout  modifier  la  façon  d’accéder  à  la  base  de  donnée  afin  d’u9liser  un  moyen  plus  sûr.  La  
modifica9on  de  la  base  de  données  pourrait  s’effectuer  via  un  client  lourd.  

!
Serveurs  Web  et  MySQL  

a. Vulnérabilité  

Si  un  des  deux  serveurs  tombe  suite  à  une  a>aque  ou  un  problème  technique,  le  site  web  n’est  plus  
disponible.  Cela  peut  nuire  fortement  à  l’image  de  la  société.  

b. Scénario  

A>aque  DDOS  sur  le  serveur  web.  Le  site  internet  devient  inaccessible.  On  peut  aussi  imaginer  une  
augmenta9on  brutale  du  trafic  sur  le  site,  qui  ferait  tomber  le  serveur  web.  

c. Besoin  de  sécurité  violé  

Le  besoin  de  sécurité  violé  est  la  disponibilité.  

FILTRAGE RÉSEAU - PARTIE 1 2

d. Proposi9on  

Mise  en  place  de  deux  backups  :  un  pour  le  serveur  MySQL  et  un  autre  pour  le  serveur  web.  Ces  backups  
servent  en  cas  d’indisponibilité  du  serveur  principal,  et  aussi  à  des  fins  de  load  balancing.  Tout  cela  afin  
d’améliorer  de  façon  significa9ve  la  disponibilité  du  site  internet.  

!
DMZ  

a. Vulnérabilité  

L’architecture  ne  possède  qu’une  seule  DMZ  publique.  L’An9virus  et  WSUS  et  les  serveurs  web  devraient  
être  déplacés  vers  une  DMZ  privée  afin  de  les  isoler  du  LAN.  

b. Besoin  de  sécurité  violé  

Disponibilité,  intégrité,  confiden9alité.  

c. Proposi9on  

Ajout  d’une  DMZ  privée,  hébergeant  l’An9virus,  WSUS,  le  proxy  web  et  un  reverse  proxy.  

!
Reverse  Proxy  

a. Vulnérabilité  

Le  serveur  web  n’est  pas  protégé  de  l’extérieur  (hormis  le  firewall).  

b. Besoin  de  sécurité  violé  

Disponibilité,  traçabilité.  

c. Proposi9on  

U9lisa9on  d’un  Reverse  Proxy  dans  la  DMZ  publique.  Cet  équipement  peut  réaliser  les  fonc9ons  suivantes  :  
répar9teur  de  charge  (entre  les  deux  serveur  web),  fournir  des  logs  de  connexion,  filtrage  des  connexions  
entrantes.  L’adresse  publique  du  serveur  web  sera  assigné  au  reverse  proxy.  Via  NAT  le  reverse  proxy  
redirigera  les  connexions  sur  un  des  deux  serveurs.  

FILTRAGE RÉSEAU - PARTIE 1 3

Equipement  de  sécurité  

a. Vulnérabilité  

L’architecture  actuelle  ne  possède  qu’un  firewall  afin  de  filtrer  le  traffic  entrant  et  sortant  dans  le  LAN.  

b. Besoin  de  sécurité  violé  

Intégrité,  confiden9alité.  

c. Scénario  

A>aque  du  firewall  et  désac9va9on  de  ce  dernier.  Le  LAN  est  donc  à  nu.  

d. Proposi9on  

Mise en place d’un IDS entre le firewall et le LAN. L’IDS permet d’analyser tous les paquets, et de bloquer
les suspicions. De plus, même en cas d’attaque du firewall, l’IDS reste disponible car il est invisible sur le
réseau (pas d’adresse IP, ni d’adresse MAC.

!
SNMP  

a. Vulnérabilité  

Le  monitoring  SNMP  n’est  pas  implémenté  de  façon  op9mal.  Seul  les  pools  SNMP  sont  effectués.  Ils  
perme>ent  d’obtenir  une  traçabilité  régulière  sur  l’état  et  la  disponibilité  du  réseau  et  de  ses  équipements.  

b. Besoin  de  sécurité  violé  

Traçabilité.  

c. Scénario  

Si  un  équipement  réseau  tombe,  ou  que  le  réseau  devient  instable,  l’admin  n’est  pas  au  courant  dans  les  
plus  brefs  délais.  Cela  impact  donc  les  délais  de  remise  en  route  du  réseau  ou  d’un  des  équipements.  

d. Proposi9on  

Mise en place de trappes SNMP permettant de remonter en temps réel un accident sur un équipement réseau,
en fonction de seuils prédéfinis.


FILTRAGE RÉSEAU - PARTIE 1 4

!
VLAN  

a. Vulnérabilité  

L’architecture  ne  possède  pas  de  compar9menta9on  VLAN.  

b. Besoin  de  sécurité  violé  

L’intégrité  et  la  confiden9alité  du  réseau  peuvent  être  impactées.  

c. Scénario  

Si  une  a>aque  «  man  in  the  middle  »  venait  a  être  effectué,  l’a>aquant  aurait  la  visibilité  de  tout  le  
LAN.  

d. Proposi9on  

Avec  une  sépara9on  virtuelle  des  LANs  (VLAN)  on  peut  isoler  les  LAN  les  uns  des  autres  et  ainsi  ne  
pas  exposer  tous  les  LANs  lors  d’une  a>aque  «  man  in  the  middle  ».L’architecture  proposée  
comporte  deux  VLANs,  un  pour  les  postes  u9lisateurs  et  un  pour  les  serveurs  MySQL,  FTP,  DHCP,  
etc.  On  pourra  pousser  ce>e  compar9menta9on  jusqu’à  séparer  les  postes  u9lisateurs  en  fonc9on  
du  mé9er  (un  VLAN  RH,  un  VLAN  direc9on,  etc).  

!
!
!
!
!
!
!
!
!

FILTRAGE RÉSEAU - PARTIE 1 5

!
Architecture  proposée  
!

!
!
Détails  de  l’architecture  proposée  
!
Table  NAT  
!
Adresse  publique  du  Reverse  Proxy  :  31.33.73.3  traduite  en  192.168.0.3  ou  192.168.0.4  (répar99on  de  la  
charge).  

Serveur  mail  SMTP  :  

31.33.73.6:25  traduite  en  192.168.0.2  
31.33.73.6:587  traduite  en  192.168.0.2  
31.33.73.6:465  traduite  en  192.168.0.2  

FILTRAGE RÉSEAU - PARTIE 1 6