Documentation

Présentation de Vulture

Présentation générale

Vulture est un reverse-proxy Open Source basé sur Apache 2.4.

Schema-overview

Vulture se place entre les utilisateurs et les applications Web à protéger et permet :

  • D’authentifier les utilisateurs avant de les autoriser à accéder aux applications. Vulture peut authentifier les utilisateurs sur une base de données SQL (MySQL, PostgreSQL, Oracle), MongoDB, LDAP / Active Directory ou encore Kerberos. Il sait demander les identifiants utilisateurs depuis un portail HTML, une authentification Basic ou Négociée (authentification Kerberos transparente).

  • Une fois l’authentification réalisée, Vulture sait propager l’identité de l’utilisateur vers les applications protégées (SSO Forward). Et si l’utilisateur souhaite accéder à une seconde application protégée par Vulture, ce dernier ne demandera plus de mot de passe, grâce au Web Single Sign On !

  • De protéger les applications Web grâce à son firewall applicatif. Grâce à un puissant moteur de règles (ModSecurity), Vulture filtre les requêtes et réponses HTTP à destination de vos applications. Il peut repérer et bloquer les attaques Web comme les injections SQL, le cross Site scripting…

  • Vulture sait également empêcher l’exploitation des failles de vos applications Web: Scannez vos sites Web avec le scanner de votre choix (Acunetix, Qualys WAS, Zed Attack Proxy supportés) Importez les résultats du scan dans Vulture Générez automatiquement la politique de protection qui empêche l’exploitation des failles découvertes Simple, non ?

  • D’améliorer la visibilité sur les accès aux applications sensibles Vulture collecte les traces de tous les accès et de toutes les attaques à destination de vos applications Web. Il sait directement stocker les logs dans un cluster big-data de type MongoDB ou ElasticSearch. Grâce à son moteur de recherche dans les logs et ses algorithmes de détection d’anomalies, découvrez facilement les requêtes suspectes parmi des Téra-octets de logs.

Pourquoi choisir Vulture

Une solution Open Source éprouvée (Version 1 sortie en 2003), stable et performante.

Un support professionnel et des offres de services délivrées par aDvens:

  • Contrats de support H24 7/7
  • Management complet de votre plateforme Vulture
  • Vulture as-a-service, en mode SaaS chez aDvens
  • Des offres de sécurité managées de bout en bout : scan de vulnérabilités, patching virtuel, analyse de logs, détection d’anomalies, protection DDOSS…

Contactez nous pour plus d’informations !

Vulture OS

Vulture 3 est basé sur FreeBSD-11.0.

L’installation de Vulture peut se faire par :

  • Une image de machine virtuelle contenant un système FreeBSD préinstallé pour Vulture.
  • Un script d’installation à executer sur un FreeBSD-11.0 vierge.

Vulture Engine

Le reverse proxy est basé sur Apache et sur plusieurs modules spécifiquement sélectionnés et compilés pour VultureOS:

  • Version Apache 2.4 en MPM Threaded
  • Module « mod_vulture », développé en C
    • En charge de l’authentification des utilisateurs
    • En charge de la gestion des sessions utilisateurs

Les sessions utilisateurs sont stockées dans un cache haute performance: Redis, packagé dans l’OS. La configuration de Vulture est stockée dans une base de données haute performance: MongoDB, packagé dans l’OS.

Grâce à Redis et MongoDB, la scalabilité horizontale de Vulture est triviale: Il suffit d’ajouter des noeuds pour étendre la performance du cluster et sa haute-disponibilité.

L’image ISO de l’installeur Vulture est librement téléchargeable depuis Internet. La version « appliance » de Vulture est distribuée par aDvens (https://www.advens.fr) et repose sur un hardware sélectionné pour offrir des performances garanties.

SSO Forward

Le mécanisme SSO de Vulture 3 est similaire à celui de Vulture 2:

  • Il y a un cookie d’authentification par application
  • Il y a un cookie d’authentification pour le portail (Plus d’infos ici)

Lorsque 2 applications protégées partagent le même entrepôt d’authentification, Vulture authentifie l’utilisateur automatiquement s’il s’est déjà authentifié une fois dessus. Lorsque les entrepôts sont différents, l’utilisateur doit s’authentifier à nouveau.

Le login et le mot de passe fourni à Vulture dans cette phase d’authentification sont conservés en cache Redis sous forme chiffrée afin de pouvoir être rejoués automatiquement dans le cas où le SSO Forward est configuré sur les applications protégées.

La durée de vie des sessions applicatives se défini au niveau de la configuration de chaque application. La durée de vie de la session portail est identique à la durée de vie de la session applicative qui a conduit vers le portail.

Vulture 3 peut authentifier l’utilisateur sur les applications Web protégées:

  • Soit en forwardant le login / mot de passe saisi lors de l’authentification Vulture (« Autologon »)
  • Soit en forwardant des informations différentes (un profil utilisateur). Si les informations de profil ne sont pas connues de Vulture, il les demandera à l’utilisateur après sa connexion (Apprentissage, ou « Learning »)

Schema-overview

Le principe de fonctionnement général de l’authentification et du SSO Forward est le suivant :

  1. L’utilisateur s’authentifie sur Vulture (via un entrepôt SQL, LDAP, MongoDB, Kerberos)
  2. Vulture vérifie si l’utilisateur peut accéder à l’application
  3. Vulture récupère les identifiants de l’utilisateur (son profil)
  4. Vulture envoie les identifiants de l’utilisateur sur l’application
    • Soit à l’aide d’une requête POST
    • Soit via une authentification HTTP basique
    • Soit via la propagation d’un jeton Kerberos

Ainsi l’utilisateur est authentifié automatiquement sur l’application lorsqu’il y accède pour la première fois.

Responder Oauth2

Vulture 3 propose une fonctionnalité de fédération d’identité basée sur le protocole Oauth2.

Cette fonctionnalité est disponible de base pour toute application disposant d’un entrepôt d’authentification initialisé dans Vulture.

Oauth2 permet à des applications tierces de s’authentifier au sein de l’entrepôt et de gérer les permissions que vous accordez à chacun des utilisateurs. Pour se faire il s’appuie sur un système de tokens servant à fédérer l’identité des utilisateurs enregistrés dans l’entrepôt.

Plus d’infos ici