Université Montpellier II – 2007 & 2008
Les Pare-Feu et attaques Web
Définition, classification, fonctionnement
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
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)
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
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.
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 – [email protected]
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 –
[email protected] 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.
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.
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
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
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 –
[email protected] 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é
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
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 – [email protected]
Les attaques WEB
Application Web
Fonctionnement d’une attaque Web
Attaques d’URL
Attaques SQL
Prévention
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
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
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
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
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.
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 …).
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.
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.
