Université Montpellier II – 2007 & 2008

Les Pare-Feu et attaques Web

Définition, classification, fonctionnement

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Sommaire

‰ Définition d’un pare-feu

‰ Les mécanismes de filtrage
‰ Typologie des pare-feu
‰ Tester et administrer un pare-feu
‰ Exemple de mise en œuvre de filtres

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Définition d’un pare-feu

Un pare-feu est un composant ou un ensemble de composants

restreignant l’accès entre un réseau externe (Internet) et un
réseau interne.
Un pare-feu fait donc office de point de contrôle entre plusieurs hôtes,
réseaux ou segments de réseaux disposant au minimum de deux interfaces
réseaux (cas du pare-feu d’entreprise).

Fonctions :
‰ Autoriser ou interdire l’ouverture d’un service donné (audio-video …)
‰ Autoriser un protocole sur un numéro de port donné
‰ Filtrer une adresse source ou destination IP
‰ Filtrer l’usage des ressources internes à l’entreprise

Positionnement :
Formellement, le pare-feu s’arrête à la couche transport (4) ou session (5),
ce qui impose une redirection vers un équipement tiers pour les couches
Hautes. Problème : opérer à la vitesse du fil (wire speed)

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Les pare-feu dans une topologie de réseau

Acteurs
Serveurs LAN
DMZ

Internet
FTP

HTTP

Relais SMTP

Switch Eth.
+ Carte pare-feu

Pare-feu
autonome Pare-feu (proxy)
sur serveur traditionnel

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Politiques de sécurité

Approches sécurité

1. Politique de sécurité restrictive : interdire tout service qui n’est pas

expressément autorisé
2. Politique de sécurité permissive : autorise tout service qui n’est pas
expressement interdit

Par principe, les équipes qui définissent, mettent en œuvre et testent la

politique de sécurité sont des équipes séparées.

En général, la politique est permissive en communication vers l’extérieur, et

restrictive en communication vers le réseau interne.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Les mécanismes de filtrage

Un pare-feu opère par filtrage, avec pour certains d’entre eux une analyse
de la charge utile du trafic.
Le filtrage s’appuie en priorité sur les en-têtes IP, UDP et TCP.
L’analyse de la partie applicative (couche 5 du modèle TCP-IP) est réservée à une
catégorie particulière de pare-feu.

Filtrage statique des paquets

‰ Adresse IP source
‰ Adresse IP destination
‰ Protocole (TCP, UDP, ou ICMP)
‰ Numéro de port source TCP ou UDP
‰ Numéro de port destination TCP ou UDP
‰ Type de message ICMP
‰ Taille du paquet

Principe : le filtrage statique compare le contenu des en-têtes IP, TCP et UDP
avec les règles définies par l’administrateur pour autoriser ou non un
paquet entrant ou sortant.

Filtrage dynamique des paquets (ou « statefull »)

Tous les paquets ne sont pas analysés, la surveillance étant centrée sur la phase
d’établissement de session TCP.
« Statefull inspection » inclut également une analyse de charge utile, de façon à
identifier les attaques de type « déni de service ».
Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr
 Typologie des pare-feu

Les pare-feu « proxy »

Ces « serveurs mandataires » rompent le modèle client-serveur d’une communication

en interdisant une connexion directe du client sur le serveur.

Réponse
Réponse

Serveur Analyse protocoles Client

proxy proxy

Requête Requête

Proxy applicatifs (« appliance »)

Ces pare-feu interviennent au niveau application (couche 7 du modèle OSI ou 5 du

modèle TCP-IP). En général ces « proxy » sont mono-protocole (DNS, HTTP, FTP…) et
analysent la charge utile.
Un « proxy applicatif » n’est réellement sécurisé qu’à la condition que les couches basses
soient sécurisées également.
Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr
 Typologie des pare-feu

Les proxy de type circuit

Ces « serveurs mandataires » rompent le modèle client-serveur d’une communication

en interdisant une connexion directe du client sur le serveur.

Session TCP 11 Session TCP 10

Serveur Gestion des Client

proxy circuits virtuels proxy

Session TCP 1 Session TCP 2

Ce type de « proxy » n’analyse pas le niveau applicatif en considérant que le contrôle de

l’établissement des circuits (ici TCP) sécurise les flux de données.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Typologie des pare-feu

Autres typologies

‰ Les bastions : hôte servant de plate-forme aux pare-feu de type applicatif ou

circuit (souvent à base de système Unix); il est possible de protéger, en
amont, un bastion par un second bastion « sacrifiel ».

‰ Les pare-feu 100% logiciels : logiciels flexibles, mais problèmes de

performances avec la multiplication des fonctions (Ipsec, VPN …) et de gestion
des correctifs.

‰ Les routeurs avec fonction de pare-feu : souvent « statefull inspection »

(exemple : PIX de Cisco)

‰ Les pare-feu sous forme de boîtiers : OS spécifique, associé au boîtier

(exemple : BSDI de Secure Computing); avantage en rapidité de traitement et
en stabilité des systèmes d’exploitation.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Typologie des pare-feu

Autres typologies

‰ Les commutateurs (niveau 2) avec carte pare-feu : avantage d’un traitement

rapide à la vitesse du commutateur (débit annoncé par Cisco sur Catalyst 7600
: 5 Gbit/s).
‰ Les pare-feu personnels distribués : à l’origine pour les connexions
permanentes ADSL ou modem câble; sous forme de logiciel ou intégré dans la
carte réseau; le terme « distribués » signifie que leur gestion peut être
centralisée (cas dans le milieu professionnel); ils visent principalement à pallier
les lacunes des pare-feu en amont.
‰ Les pare-feu embarqués dans les cartes réseaux : principe de filtrage
statique; inaccessible à l’utilisateur; indépendant de l’OS du système hôte;
possibilité de déporter des calculs Ipsec pour VPN (Virtual Private Network) et
d’économiser du temps CPU sur le processeur de la carte-mère

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Typologie des pare-feu

Autres typologies

‰ Les pare-feu personnels distribués : à l’origine pour les connexions permanentes

ADSL ou modem câble; sous forme de logiciel ou intégré dans la carte réseau; le
terme distribués signifie que leur gestion peut être centralisée (cas dans le milieu
professionnel); ils visent principalement à pallier les lacunes des pare-feu en amont.

Réseau Intranet

Gestion centralisés pare-feu distribués

Pare-feu d’entreprise

Internet

Serveur d’applications

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Tester et administrer un pare-feu

Quand et comment tester ?

Absence de norme … Tests réalisés par des laboratoires dits « indépendants » sujets
à caution … Méthodologie dépendante des topologies mises en œuvre (solution
unique ou composite, produits etc …).
Une règle : un pare-feu doit être testé par une équipe différente de celle qui a
procédé à la mise en œuvre.

Un pare-feu doit être testé dans 3 cas de figure :

‰ à l’installation
‰ en cas de changement significatif
‰ de manière périodique de façon à verifier la conformité du pare-feu avec la
politique de sécurité

L’administration d’un pare-feu comprend :

‰ l’exploitation des fichiers de log

‰ la vérification régulière de la cohérence des règles de filtrage
‰ une documentation écrite (et confidentielle) sur l’ensemble des règles de
filtrage et sur les procédures à suivre en cas d’incident ou de tentatives
d’intrusion.
‰ L’application rapide des patchs nécessaires
Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr
 Tester et administrer un pare-feu

Fenêtre de vulnérabilité

La réduction de la taille des fenêtres de vulnérabilité doit être un souci constant

pour les RSSI (Responsables de la Sécurité des Sytèmes d’Information).

La faille devient Apparition du Déploiement du

publique correctif correctif en entreprise

Apparition des outils

Découverte d’une d’exploitation de la Test du correctif
vulnérabilité faille en entreprise

Temps écoulé

Fenêtre de vulnérabilité

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Exemple de mise en œuvre de filtres

Système de routage : filtres de niveau 3

version 11.0
logging 192.9.200.1
!
interface FastEthernet 0/0
ip address 192.9.200.254 255.255.255.0
ip access-group 101 out
ip accounting access-violations
!
interface FastEthernet 0/1
ip address 192.9.100.1 255.255.255.0
!
router rip
network 192.9.200.0
!
! Les access-lists
!
access-list 101 deny ip 192.9.200.0 0.0.0.255 any log
access-list 101 deny ip 127.0.0.0 0.255.255.255 any log

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Exemple de mise en œuvre de filtres

Système de routage, suite : filtres de niveaux 4 et 3

! Acces aux services usuels :

!
access-list 101 permit udp any host 192.9.200.1 eq ntp
access-list 101 permit tcp any host 192.9.200.1 eq ftp
access-list 101 permit tcp any host 192.9.200.1 eq ftp-data
access-list 101 permit tcp any host 192.9.200.1 eq telnet
access-list 101 permit tcp any host 192.9.200.1 eq smtp
access-list 101 permit tcp any host 192.9.200.1 eq www
access-list 101 deny all all

!
! Acces aux terminaux virtuels de ce Cisco
! On n'autorise l'acces au Cisco que depuis le réseau interne
!
access-list 98 permit 192.9.200.0 0.0.0.255
!
line vty 0 4
password 7 xxxxxxxxx
access-class 98 in
Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr
 Les attaques WEB

‰ Application Web
‰ Fonctionnement d’une attaque Web
‰ Attaques d’URL
‰ Attaques SQL
‰ Prévention

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Application Web

Définition

L’OWASP (Open Web Application Security Project) définit une application

Web comme « une application logicielle client-serveur qui interagit avec les
utilisateurs ou d’autres systèmes en utilisant le protocole HTTP ».

Architecture trois-tiers

Client + Navigateur Routeur

Pare-feu Serveur HTTP + serveur

d’application + SGBD

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Application Web

Zones d’attaque application Web Types d’attaque application Web

Zone 1 : client avec navigateur Zone 1 : Cross Site Scripting (rebond

routeur vers un client final),
pare-feu modification identifiants de
session …
Zone 2 : serveur HTTP
Zone 2 : manipulation des URL …
Zone 3 : serveur d’applications
Zone 3 : manipulation des données
Zone 4 : SGBD utilisateur pour exécution
de codes hostiles (ex :
injection de code SQL dans
un mot de passe)

Zone 4 : déni de service applicatif

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Fonctionnement d’une attaque Web

Recueillir le maximum d’informations avec son navigateur

Version HTTP ? Serveur utilisé (Apache, IIS …) ? Serveur applicatif utilisé ?

Base de données utilisée (Oracle, DB2, SQL Server, PostgreSQL ..) ? Langages
utilisés côté client comme côté serveur ?
En résumé : établir une liste de toutes les technologies utilisées mises en
œuvre pour attaquer à la fois côté client et côté serveur.
Outils disponibles : NetCat, Nmap, Nessus, Whisker, Brutus, Webcracker…

Les attaques sur les langages et protocoles web

HTML : éléments et attributs <form>, <form action>, <input>, <form

method>, <object>, <applet>, <embed> …
HTTP : problème avec les méthodes HTTP.1 « options », « trace »;
possibilité de modification d’en-tête (ex : pour traversée de
répertoires)
HTTPS (HTTP over SSL) : problème si absence de certificat client

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Top 10 des attaques Web (source : OWASP)

Paramètres non validés : requête Web non validée avant son utilisation

Contrôle d’accès rompu : mauvaise gestion des droits d’accès

Gestion de la session : crédits et jetons mal protégés

Faille CSS : souvent pour un vol de session après

rebond sur un client en ligne

Buffer overflow : crash du serveur par débordement (ou autres

effets)

Injection de commandes : passages de paramètres par les serveur HTTP

vers d’autres serveurs applicatifs

Condition d’erreur : fournit des informations détaillées sur le

système

Utilisation non sécurisée de la crytpographie : protection faible

Administration à distance : Fonctions administratives mal protégées

Mauvaise configuration des serveurs : mauvaise sécurisation par défaut

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Attaques d’URL (Uniform Resource Locator)

RFC 1738 (1994) – RFC 1808 (url relatives)

Structure URL : Protocole://serveur/numéro-de-port/chemin-d’accès-à-la

ressource/ressource?paramètres

Protocoles les plus connus : HTTP, FTP, MAILTO, HTTPS, NEWS …

Points faibles : utilisation des métacaractères (%, @, $, *, # etc…) pour

modifier le comportement d’une application en étant insérés dans les
paramètres d’une URL, vérifier l’existence d’un utilisateur sur un site
(avec ~), lister les fichiers d’un répertoire (avec *), lancer la
commande « cmd.exe » sous Windows NT/2000, traverser des
répertoires (avec /) etc…

Formats d’encodage : possibilité d’exploiter un mauvaise application de la

spécification UTF-8, UTF-16 ou UTF-32; de plus les serveurs HTTP
fonctionnent souvent sans connaître l’encodage choisi, donc sans
toujours reconnaître les métacaractères utilisés.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Attaques SQL (Structured Query Langage)

Rappels SQL

4 ensembles de commandes : DDL (Data Definition Language), DML (Data

Manipulation Language), DQL (Database Query Langage), DCL (Data Control
Language)
2 catégories supplémentaires : commandes de contrôle des transactions
(COMMIT, ROLLBACK, SET TRANSACTION) et commandes de programmation
SQL (EXPLAIN, FETCH, DECLARE …)

Sybase et Microsoft SQL Server mettent à disposition des utilisateurs des

procédures stockées (envoi d’un email, définition d’un nouvel utilisateur,
adaptation à un trafic réseau réduit …).

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Attaques SQL

Attaques SQL indirectes

Exemples de référence : www.silksoft.co.za et www.sqlsecurity.com

Injection de commandes via formulaire HTML :

placer des commandes SQL dans un formulaire HTML (via PERL, ASP,
CGI ou PHP); si les champs ne sont pas validées par le serveur, du code
hostile peut être alors exécuté (login + password sur un SGBD)

Utilisation de messages d’erreur de la base de données :

utiliser des messages d’erreur pour identifier les noms de tables et

colonnes d’un SGBD; si l’application prévoit la possibilité de créer un
utilisateur, les ressources habituelles peuvent ensuite être utilisées
pour tester des login+password.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

 Prévention

Principales règles à suivre (liste non limitative)

Valider systématiquement les entrées utilisateurs dans chaque script orienté

serveur

Limiter précisément les droits d’accès des utilisateurs, et éviter d’utiliser des
comptes système par défaut (sa de SQL Server); definir des comptes précis
pour des besoins précis

Sécuriser les login+password (règles habituelles en sécurité)

Limiter au niveau d’un pare-feu la taille des URL, pour éviter l’injection de
requêtes SQL)

Gérer les métacaractères interdits dans les scripts

Gérer au plus précis les fonctions d’administration à distance (adresse IP,

numéro de port …) au niveau du serveur HTTP comme au niveau des pare-feu
et routeur.

Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr