6. Protection de l'accès Web et fonctionnalités de monitoring associées
6.1 La problématique
Le but d'une attaque de type DoS (Denial of Service) ou DDoS (Distributed Denial of Service) est tout simplement de rendre indisponible
un service. L'exemple typique est représenté par les serveurs Web qui sont très
souvent victimes de ce type d'attaque ! Pour rendre le site Web indisponible,
les pirates tentent tout simplement de surcharger le serveur en lui envoyant un
maximum de requêtes HTTP. Lorsque ces multiples requêtes sont envoyées par de
nombreuses machines différentes, on parle alors d'attaques DDoS.
Notez bien :
- DoS va envoyer des paquets provenant de la même adresse IP vers un ou plusieurs serveurs
- DDoS est une variante de DDoS dans le sens où toutes ces
requêtes simultanées destinées à un ou plusieurs serveurs vont provenir de plusieurs adresses IP
La plupart des pirates prennent le contrôle de centaines, de milliers voir de
dizaines de milliers de postes à l'aide de programmes spécifiques comme des
chevaux de Troie ou des vers. A une heure H, le pirate donne l'ordre à
l'ensemble des machines qu'il contrôle d'envoyer des requêtes HTTP en boucle à
la même URL. Le serveur Web est bien entendu incapable de répondre à ce flot
continu de requêtes, ce qui le rend quasiment inaccessible (timeout,
erreurs 404....).
Bien sur les attaques de type DoS et DDoS peuvent aussi viser d'autres services
comme la messagerie, les accès VPN ou bien encore l'accès aux serveurs DNS
(le but est alors de faire "tomber" l'infrastructure DNS mondiale, mais ces
attaques, de grande envergure, sont relativement rares).
En revanche les attaques de type DoS / DDoS sur les serveurs
Web sont de plus en plus fréquentes ! Parmi les nombreux vers les utilisant on
peut citer les "fameux"
Blaster
et
Sasser
qui ont fait coulé beaucoup d'encre... Pour rappel le but de ces deux vers était
de faire tomber les sites Web suivants : http://windowsupdate.microsoft.com
pour Blaster et http://www.sco.com
pour Sasser. Le schéma ci-dessus illustre une attaque de type DDoS (Blaster).
Remarque : Ce qui va différencier un vers d'un virus va être sa capacité à se propager sur d'autres ordinateurs
à l'insu de l'utilisateur, en utilisant notamment les mails, les logiciels de messagerie instantanée, les réseaux peer to peer, etc.
Un ver de ce type va initialement effectuer des attaques de type DoS puis va rapidement, au fur et à mesure qu'il se propage, effectuer des attaques de types DDoS.
6.2 La réduction du flood
Il n'existe rien dans ISA Server 2004 permettant de lutter efficacement contre ce type d'attaques, en revanche un
limiteur de flood a été implémenté dans ISA Server 2006. L'architecture d'ISA Server 2006 a été spécialement optimisée pour
résister
aux attaques de type DoS ou DDoS ! Le but du système de contrôle des flux
implémenté dans ISA Server 2006 est que le serveur reste disponible pour les
clients mais aussi pour l'administration en cas d'attaque de ce type.
 |
|
Le principe de base de ce limiteur de flood est des plus simples : dès lors que le serveur ISA reçoit un nombre trop important de
requêtes provenant de la même adresse IP dans un laps de temps trop court (1 minute), toutes les
requêtes suivantes provenant de cette adresse sont bloquées et une alerte est créée dans la console de gestion d'ISA Server 2006.
Ce filtre est par défaut activé mais il est possible de le désactiver en décochant la case "Enable mitigation for flood attacks and worm propagation". Dans le cas où l'on souhaite
utiliser ce filtre, il est possible de spécifier le type de trafic ou de connexion que l'on va souhaiter bloquer.
Certaines applications utilisées en entreprise utilisent un grand nombre de connexions simultanées au même serveur et il pourrait être
gênant de les bloquer. Pour palier à ce problème, ISA Server 2006 nous donne la possibilité de spécifier des limites différentes pour certains ensemble d'ordinateurs : les exceptions. Ces exceptions
sont générales à tous les paramètres du limiteur de flood. En revanche il ne sera possible d'appliquer une limite différente que sur certains paramètres. Dans le cas où il n'y a pas de champs prévu pour spécifier une limite de nombre de connexions, cela signifie que les exceptions configurées n'auront pas de limites.
Le champ permettant de configurer le nombre maximum de connexions s'intitule "Limit" et celui permettant de fixer la limite des exceptions s'intitule 'Custom limit".
Les paramètres ne bénéficiant pas de champs "Custom limit" sont "Non-TCP new sessions per minute, per rule", "TCP half-open connections" et "Set event trigger for denied packets".
|
Les paramètres configurables avec ce limiteur de flood sont :
-
TCP connect requests per minute, per IP address : Lorsque le même client, ou plusieurs clients avec la même adresse IP vont tenter de se connecter un nombre de fois supérieur à ce qui a été défini dans ce paramètre dans la même minute, toutes les demandes de connexions qu'ils vont tenter de faire seront refusées.
-
TCP concurrent connections per IP address : Un client a la possibilité d'ouvrir plusieurs sessions TCP en simultané à partir de la même adresse IP, mais lorsque ce nombre devient supérieur à ce qui a été configuré dans ce paramètre et qu'il n'y a pas ou pas assez de connexions fermées, le client va voir ses demandes refusées par le serveur ISA.
-
TCP half-open connections : Lorsqu'un client se connecte sur un serveur via le
protocole TCP, il va envoyer un paquet SYN, le serveur est ensuite sensé répondre au client en envoyant un paquet SYN-ACK, mais si le paquet envoyé initialement au serveur contient une adresse IP source invalide ou inexistante, le serveur ne va pas pouvoir renvoyer de paquet SYN-ACK et va stocker en mémoire les demandes de connexions SYN, d'où le terme connexion semi-ouverte. Si un client envoie un grand nombre de ces paquets au serveur, sa mémoire va très rapidement saturer et il ne sera plus capable de répondre aux
requêtes des clients. Ce paramètre permet de configurer le nombre de demandes de connexions SYN que le serveur va pouvoir garder en mémoire avant de les supprimer. A l'inverse des autres paramètres, on ne peut pas le configurer directement, sa valeur va être la
moitié de la valeur tronquée du paramètre "TCP concurrent connections per IP address".
-
HTTP requests per minute, per IP address : Ce paramètre devrait limiter le nombre de
requêtes HTTP passant par le serveur ISA par minute et par adresse IP mais il n'a
apparemment pas été implémenté dans cette version beta1.
-
Non-TCP new sessions per minute, per rule : Il est possible d'effectuer des attaques DDoS avec des protocoles utilisant UDP, comme DNS par exemple. Le principe est toujours le même, il s'agit de surcharger le serveur avec des
requêtes DNS trop grandes afin qu'il ne soit plus capable de répondre aux
requêtes des clients. Ce paramètre va permettre de bloquer le trafic lorsque le serveur ISA reçoit trop de
requêtes dans la même minute sur un ou des protocoles définis dans la même règle d'accès.
-
UDP concurrent sessions per IP address : Un client a la possibilité d'ouvrir plusieurs sessions UDP en simultané à partir de la même adresse IP, notamment lorsqu'il va faire du streaming, mais lorsque ce nombre devient supérieur à ce qui a été configuré dans ce paramètre et qu'il n'y a pas ou pas assez de connexions fermées, le client va voir ses demandes refusées par le serveur ISA.
-
Set event trigger for denied packets : ???
6.3 Test des fonctionnalités de monitoring
 |
Comme dans la version 2004, on peut trouver dans l'item "Monitoring" un onglet "Alerts" qui permet de visualiser toutes les alertes relatives au fonctionnement du serveur ISA. |
En revanche de nouvelles définitions d'alertes ont étés implémentées. Il s'agit de définitions permettant de déclencher un évènement lorsqu'une alerte apparait suite à une tentative d'attaque via une technique DoS ou DDoS. A chaque paramètre de la limitation de flood correspond une définition d'alertes. Par exemple on trouvera la définition "Concurrent TCP connections from one IP adresse limit exceeded" qui correspondera au paramètre du réducteur de flood "TCP concurrent connections per IP address".
Afin de tester les outils de monitoring et de gestion des alertes, nous avons volontairement infecté une machine avec des vers, virus, spywares
et autres rootkits. Le test a été réalisé sur une machine virtuelle fonctionnant sous Windows 2000
SP4 et connectée directement à Internet sans pare-feu ni antivirus. Après quelques minutes
passées à surfer sur des sites savamment choisis, nous avons récolté une belle
collection de virus en tout genre, puis avons configuré la machine en tant que client SecureNAT
sur notre serveur ISA 2006. Aussitôt connectée, elle a tenté de plusieurs manières différentes de se connecter sur des sites internet du réseau externe via le serveur ISA qui a automatiquement détecté des tentatives d'attaques du serveur ISA et a bloqué toutes les connexions au delà de la limite fixée. (cf. capture ci-dessous).
Comme on peut le voir sur cette capture, le serveur ISA a clairement identifié le type d'attaque ainsi que l'adresse IP de l'assaillant. Les trois alertes en question ont été déclenchées car le client infecté a tenté d'effectuer:
- un nombre trop important de connexions TCP en une minute
- trop de connexions simultanées alors que les premières n'étaient pas terminées
- de manière plus générale trop de connexions non-autorisée en une minute
De la même manière que sous ISA Server 2004, il est possible de spécifier des actions à effectuer lorsqu'une alerte est déclenchée :
envoyer un mail, exécuter un programme, inscrire un événement dans le journal d'événements, d'arrêter ou de démarrer un service, et ce dans le but de tenter de minimiser les conséquences de la tentative d'attaque.
6.4 Un produit encore en version beta...
Depuis environ deux ans, les attaques de type DoS et DDoS ont réellement tendance à se généraliser et à devenir de plus en plus courantes (windowsupdate.microsoft.com, www.sco.com, www.akamai.com, etc.), il était donc nécessaire que Microsoft en tienne compte lors du développement des nouvelles fonctionnalités d'ISA Server.
C'est désormais chose faite ! Cependant, certaines des fonctionnalités liées à
la réduction du flood souffrent de bugs; bugs que l'on imputera à la jeunesse de la fonctionnalité :
-
Le paramètre du réducteur de flood "HTTP requests per minute, per IP address" semble pas fonctionner.
En effet malgré tous nos tests, il a toujours été impossible de limiter le nombre de connexions provenant d'une adresse IP sans jouer sur les autres paramètres ainsi que de
déclencher l'alerte associée à ce paramètre.
 Sommaire
1. Présentation du produit
1.1 Présentation d'ISA Server et bref historique
1.2 Les nouveautés offertes par ISA Server 2006
1.3 Les différentes éditions d'ISA Server 2006
1.4 L'intégration aux Appliances : un enjeu important pour l'avenir
1.5 Vers un produit plus fiable et plus complet ?
1.6 Essayez ISA Server 2006 gratuitement !
2. Déploiement d'ISA Server 2006
2.1 Configuration minimale
2.2 Installation d'ISA Server 2006 édition standard
2.3 Installation d'ISA Server 2006 édition entreprise
2.4 Les différents scénarii de mise à jour vers ISA 2006
2.5 Mise à jour vers ISA Server 2006 SE à partir d'ISA Server 2004 SE SP2
2.6 Mise à jour vers ISA Server 2006 EE à partir d'ISA Server 2004 EE SP2
3. Gestion de la publication sous ISA Server 2006
3.1 Présentation des nouveaux assistants de publication
3.2 Gestion des certificats sur les ports d'écoute Web
3.3 Gestion de la traduction de liens dans ISA 2006
3.4 Publication d'une ferme de serveurs Web
4. Mise en place de l'authentification dans le cadre d'une publication
4.1 Introduction au mécanisme d'authentification
4.2 Intégration de l'authentification basées sur les formulaires
4.3 Implémentation de l'ouverture de session unique (SSO) sur un port
d'écoute Web
4.4 Rappels sur les différentes méthodes d'authentification intégrée à ISA
2006
5. Déploiement d'ISA Server 2006 dans un site distant
5.1 Problématique du déploiement d'ISA Server 2004 EE dans un site distant
5.2 Déploiement automatisé d'ISA Server 2006 SE/EE dans un site distant
5.3 Procédure de déploiement pas-à-pas d'un serveur ISA 2006 dans un site
distant
5.4 Intégration des nouveautés du Service Pack 2 d'ISA Server 2004
6. Protection de l'accès Web et fonctionnalités de monitoring associées
6.1 La problématique
6.2 La réduction du flood
6.3 Test des fonctionnalités de monitoring
6.4 Un produit encore en version beta...
7. Conclusion
7.1 Nos impressions sur la Beta1 d'ISA Server 2006
7.2 Que pouvons-nous attendre pour l'avenir ?
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Tout savoir sur ISA Server 2006 (Beta1 - Codename Wolverine)
Accès
direct aux définitions :