=========================================== Réunion OSSIR groupe sécurité Windows Lundi 10 mars 2003 =========================================== Ordre du jour : 1- Présentation du produit de sécurité Web Deny-All (Patrick ASTY / Deny-All) 2- Présentation de l'IDS TopLayer (Jean Patrice HIRA / TopLayer) 3- Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== 1- Présentation du produit de sécurité Web Deny-All (Patrick ASTY / Deny-All) ==================================================== Deny-All est une société française, "spin-off" de la Société Générale créée il y a 2 ans pour commercialiser des produits de sécurité Web développés en interne. Le produit phare qui fait l'objet de la présentation s'appelle "rWeb". Il s'agit d'un "reverse proxy" HTTP/HTTPS permettant d'effectuer un filtrage de sécurité applicatif. Le produit rWeb comprend deux composants : le RPC (Reverse Proxy Cache), chargé de la réception des requêtes et de la mise en cache des réponses ; le SFP (Secure Filtering Proxy) qui assure les fonctions de sécurité telles que l'authentification et le filtrage. Ces deux composants peuvent être installés sur le même serveur ou sur deux serveurs distincts. Dans ce dernier cas deux modes de communication sont possibles : le mode push (le RPC s'adresse au SFP) ou le mode pull (le SFP vient récupérer les requêtes sur le RPC, permettant un filtrage à sens unique entre les deux composants). Remarque : le mode pull, également disponible chez un produit concurrent, permet de limiter les risques liés à la possibilité d'utiliser le verbe CONNECT sur le proxy SFP en cas compromission du RPC pou rebondir sur la DMZ où se trouvent les serveurs Web. La dégradation des performances est peu sensible (de l'ordre de 10%). Le RPC assure les fonctions suivantes : - Chiffrement SSL software ou hardware - Mise en cache - Compression à la volée (si le client le supporte) - Réécriture des URI afin d'assurer l'unicité - Génération de traces au format CLF (Common Log Format) Le SFP assure les fonctions suivantes : - Authentification (RADIUS, LDAP, SSLv3, etc. - même NTLM est supporté) - Génération de traces - Filtrage * Par blacklist (attaques connues sur IIS, Apache, iPlanet, etc. en techno ASP, CFM, PHP, etc.) * Par whitelist * Avec une liste de règles applicables aux pages statiques (sans arguments) ou dynamiques (avec contrôle de validité et typage des arguments). Cette liste de règles est stockée dans un fichier texte et prise en compte sans interruption de service. Le filtrage peut être appliqué en mode "standard" ou en mode "strict", ce dernier mode permettant également de générer des rapports sur le fonctionnement du site. Un mode apprentissage est disponible pour faciliter l'écriture des règles. Il est important de noter que le filtrage intervient avant les mécanismes d'authentification, qui sont eux-mêmes protégés par ce mécanisme. Concernant HTTPS, le produit rWeb est capable de : - Filtrer les requêtes HTTPS. Pour celà il est possible d'importer sur le RPC un certificat SSL existant afin d'opérer un déchiffrement/rechiffrement transparent. - Supporter les authentifications client SSLv3. Pour cela le client s'authentifie avec le SFP qui régénère de manière transparente un pseudo-certificat avec le même "sujet" à destination du serveur Web final. L'administration s'effectue par le Web ou par une console Java. Q: Comment est-il possible de marier le produit avec du Load Balancing et de la Haute Disponibilité ? R: Ces fonctions peuvent être réalisées par des boîtiers externes chaînés avec rWeb, ou sous forme de cluster rWeb. Q: Est-il possible de faire du Load Balancing en mode "transparent" ? R: Non. Q: Quel est le moteur utilisé ? R: Apache, qui a été largement transformé et soumis à tests exhaustifs de conformité avec les RFC. Q: Le produit fonctionne-t-il avec les extensions IIS ou WebDAV ? R: Oui tout standard RFC est supporté, et même des extensions non standard de type Outlook Web Access. Q: Faut-il dupliquer le certificat SSL (RPC + serveur Web) dans le cas où le site est accédé aussi bien en interne qu'en externe ? R: Oui, ou alors utiliser une architecture de type "extranet". Q: Comment est assurée la maintenance de la "blacklist" ? R: Deny-All effectue une veille technologique et met à jour cette liste automatiquement dans le cadre du contrat de support. Q: Existe-t-il des règles de filtrage en sortie ? R: Oui des règles peuvent aussi bien être appliquées en entrée qu'en sortie. Cette dernière fonction permet par exemple de lutter contre le XSS et les messages d'erreur verbeux. Q: Comment est packagé le produit ? R: Disponible en software pour plusieurs versions d'Unix ou sous forme d'appliance. Pas de version Windows. Q: Quelles sont les performances obtenues ? R: Entre 3 000 et 10 000 pages statiques par seconde, ce qui est supérieur à la capacité de la plupart des serveurs Web. Pour les pages dynamiques un gain de performance de l'ordre de 10% à 20% par rapport à un système sans rWeb est souvent constaté ! Ce comportement s'explique par la fait que le proxy maintient le serveur Web en deçà de sa limite d'écroulement. Q: Quelle est la politique tarifaire ? R: La licence est vendue au nombre d'instances (nombre de sites Web desservis). Q: Quels sont les avantages concurrentiels du produit ? R: 7 ans de production, un tarif dans la moyenne pour des performances et des fonctionnalités meilleures que la concurrence. Q: Y a-t-il un support du protocole ICAP ? R: Non mais il est possible de spécifier des règles SENDTO, PIPE ou EXEC à destination de n'importe quelle application externe. ==================================================== 2- Présentation de l'IDS TopLayer (Jean Patrice HIRA / TopLayer) ==================================================== L'intervenant ne s'est pas présenté. ==================================================== 3 - Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== Les vulnérabilités les plus récentes des environnements Windows sont passées en revue, en particulier la propagation du ver SQL/Slammer qui a donné lieu à de nombreux débats. La prochaine réunion du groupe est fixée au lundi 12 mai 2003 pour cause de JSSI (3 avril 2003). Le groupe est ouvert à toute proposition d'intervention et/ou d'hébergement. ion et/ou d'hébergement.