Pour modifier le wiki : créer un compte (cliquer sur Login) et demander un accès en écriture à ads@intrinsec.com

Roadmap

• Sessions en memoire
• Sqlite3
• packaging pour le choix entre mpm-worker ou prefork sous debian

• debug de l'ajax et reload avec HUP -> si mpm-prefork alors pas de cgi pour l'interface d'admin (ifModule)

• merge du code dans un seul .pm
• découpage des fonctionnalités VPN dans un .pm different
• re-test gentoo
• après modification d'une application mettre un rappel si il faut redemarrer l'interface
• simplification du changement de mdp
• URL du formulaire d'authentification non vide

Patchs

Contributing a new patch

Bugs

• Visiblement on peut activer de l'authentification sans qu'il y ait un portail SSO pour l'interface en question (http://groups.open-source.fr/viewtopic.php?t=571)

• Peut être un bug si url par défaut NULL ou vide... (mauvaise distinction entre NULL et vide)

• http://groups.open-source.fr/viewtopic.php?t=793

Feature request

• Permettre l'authentification via une popup de type htaccess (permettra le CONNECT).
• Permettre de spécifier une URL qui déclenche le logout également de Vulture

Misc

• ProxyPassReverseCookiePath a disparu ? -> dans VirtualHost et pas dans proxy

• Eventuellement interdir de mettre une URI dans l'url privée

IDEES

• Demander a l'utilisateur si il souhaite créer un certificat associé à son login-mot de passe. Si oui installation automatique du certificat dans le navigateur et association du profil avec le certificat.

TODO

• Templates en BDD
• Pouvoir utiliser des scripts pour les redirections
• Jouer avec les permissions pour que seule l'interface d'admin puisse ecrire dans la base et pas les process Vulture (seulement lecture).

• Configuration par défaut pour RT : http://groups.open-source.fr/viewtopic.php?p=2387

  • Permettre d'avoir accès aux champs de certificat dans les scripts SSO Forward
  • Faire une fiche vulture sur securityfocus
  • Plusieurs methodes d'authentification (testées successivement)
  • Permettre de choisir pour chaque application quelle base est utilisé pour les sessions (permet de partager les sessions entre plusieurs Vulture)

  • Redirection en fonction du user ... => http://machin/?user=toto

  • MAJ packaging Mandriva
  • clean des requêtes
  • benchmark mod_proxy / Vulture

  • authentification PAM => juste à ajouter dans la liste (pas de configuration)

  • Dans SSO Forward, mettre variable name en dessous du field_type et l'afficher uniquement si pas de type "hidden"
  • Option : suivre redirections de l'authentification (SSO Forward)

  • Mémo dans l'interface d'admin pour le fichier sudors (demander de cocher un truc quand c'est fait) -> avoir un concept de mémo, personnalisable, partout dans l'interface (cf bulles sur download activeperl).

  • signature GPG des RPMS
  • avoir des alias qui ne conflictent pas
  • chroot mod_security
  • accents dans le LDAP ok ?
  • virer la commande ldconfig dans les packages (faire un source avec LD_LIBRARY_PATH=/opt/... dans les scripts d'init).
  • logs de l'interface d'admin
  • meilleur load_balancer (utilisation de celui de mod_proxy sans conflit avec les features Vulture ?)
  • Pour le bug du portail SSO : sur toutes les interfaces ajouter le(s) vhost du portail SSO (y compris si il n'appartient pas à l'interface en question).

Par défaut dans la base

Templates

• SPIP
• Squirelmail
• sitescape

Mod log debug

Découpage des règles mod_security

• Chroot
• (Experimental)
• Identity masking
• PHP
• IIS and frontpage
• SQL
• MIME types
• Default (scanpost on, eviter le DOS) cf Appendix A
• Samples
• Deny upload

CR Salon Sécu - rWeb

La pres était orientée rWeb + Sign&Go (produit de la société Ilex). En effet, DenyAll s'associe désormais à Ilex pour la gestion de l'aspect SSO: d'après la personne de DenyAll avec laquelle j'avais discutée, DenyAll n'a plus l'intention d'améliorer la partie SSO initialement intégrée à leur produit et délèguera cette fonction au produit Sign&Go.

Les fonctionnalités sont assez identiques à celle de Vulture, j'inciste donc ici essentiellement les points différentiateurs

Reverse Proxy initialement basé sur Apache, mais ils ont ré-écrits plusieurs modules

• la majeure partie de mod_proxy pour en améliorer les perfs: le gars m'a parlé d'un problème de mod_proxy qui fait du N vers N (N connexions arrivant vers rWeb ne génèrent pas systématiquement N connexions vers le serveur privé (en génère moins afin de sauver les perfs).
• ils ont ré-écrits le module de cache car il est (parait-il) buggué dans Apache ce qui génère des pages non à jour
• Compatibilité avec les applications: ils ont déjà identifié et traient donc les différents pbs de liens ré-écriture de liens absolu dans les pages ou les scripts, les redirections Meta, ...

Authentification forte (biométrie, Radius, OTP, ...)

• Je pense qu'ils supportent notamment Radius dans le cas d'authent en Challenge/Response (plusieurs échanges Radius avant l'authent), ce que ne supporte pas encore Vulture

Auditabilité

• les logs sont conformes au différentes règlementations en termes de journalisation et d'audit

SSO Profils utilisateurs (Ilex)

• Stockés sur un serveur Ilex séparé du Reverse Proxy: ce serveur critique est en général protégé derrière un FW, ce que ne permet pas encore Vulture
• compatibles SAMLv2 ce qui facilite à terme les échanges avec d'autres applications

SSO gestion de session (Ilex)

• Gèrent, d'après eux, tout type de session: Cookie, Formulaires, URLs

Règles de sécurité des appli Web

• possède des "listes noires" avec des signatures d'attaques (~mod_security) (XSS, SQL injection, LDAP injection, ...)

• possède des listes blanches où "tout est interdit sauf les requêtes correspondant à un ensemble de formats pré-définis": par exemple toute requête doit être de la forme http://monappli/index.php?toto=XXX&tata=YYY ou http://...

• Le point fort est l'existance d'un scanner automatique qui analyse la structure du site web, les différents formulaires et qui construit déjà un ensemble de règles que l'on peut ensuite personnaliser (par exemple liste des éléments statiques, et surtout typage des champs des formulaires, ...)
• filtres SOAP/XML

Règles de contrôle d'accès classiques

• selon l'adresse IP du client,
• le niveau d'authentification,
• un contrôle d'accès basé sur les Rôles (support de groupes ldap)

Ils annoncent durant l'année, l'apparition d'un rWeb en mode Bridge et pas en mode reverse proxy.

Autres données:

Performances (basées sur un site Web comportant 1 page dynamique et 4 éléments statiques)

• 5000 à 7000 requêtes par seconde pour les appliances les plus petites
• jusqu'à 20000 req/s pour les plus grosses appliances
• les appliances sont des PC rackables Compaq/HP
• prix publique d'entrée de gamme à la louche ~12K€

Voila ce que j'ai pu collecter comme info (sachant que je ne connaissais pas du tout le produit avant).

Comparatif (à completer)