Documentation

Getting started

Vulture est un reverse-proxy:
- Il accepte des connexions HTTP / HTTPS depuis Internet,
- Il analyse la légitimité de la requête HTTP qu’il reçoit,
- Il transmet les requêtes légitimes aux applications Web qu’il protège

Vulture étant en coupure, il peut modifier la requête, transformer la réponse, compresser les pages, …

Pour fonctionner Vulture a besoin:

  • D'être installé sur une machine virtuelle ou un serveur physique
  • D'une ou plusieurs adresses IP pour recevoir des connexions Web
  • De contacter les applications Web qu'il protège sur leurs ports habituels (80 et 443 en général)
  • D'un accès HTTPS vers dl.vultureproject.org pour s'enregistrer et télécharger les mises à jour
  • D'une résolution de noms fonctionnelle (soit par serveur DNS soit via /etc/hosts sur l'OS Vulture)
  • D'un serveur NTP

Vulture stocke par défaut ses logs sur le système d’exploitation sous forme de fichiers plats ou dans sa base MongoDB pour la visualisation depuis l’IHM. Si vous souhaitez qu’il envoie ses logs dans un cluster ElasticSearch ou MongoDB, il faut qu’il puisse contacter ces clusters sans filtrage.

Vulture possède un filtre de paquets, il peut-être placé en frontal sur Internet. Il peut aussi être placé derrière un firewall, sur lequel vous activerez la translation d’adresse ou de port.

Vulture fonctionne sous FreeBSD. Une fois l’OS installé, nous vous recommandons de vérifier que la configuration réseau est optimale (connexion Internet, dns, ntp, passerelles…) avant de lancer le bootstraping de Vulture. Si le réseau fonctionne parfaitement, l’installation de Vulture se déroulera sans problème.

Vulture supporte IPv4 et IPv6 et utilise le protocole CARP pour la gestion des adresses virtuelles. Les informations de session utilisateurs (pour le SSO et l’authentification) sont stockées dans un cluster REDIS partagé entre tous les noeuds Vulture. Sa configuration est stockée dans une base MongoDB partagée entre tous les noeuds Vulture.

Vulture fonctionne parfaitement sur une seule machine, mais peut si nécessaire fonctionner au sein d’un cluster dont la scalabilité s’étend en rajoutant des noeuds. Le cluster s’administre depuis n’importe quel noeud (Il est possible d’arrêter / démarrer des processus Vulture sur un noeud distant sans avoir besoin de s’y connecter).

Les communications entre les noeuds Vulture s’effectuent via HTTPS. Les communications entre Vulture et MongoDB sont chiffrées. Les communications entre Vulture et le cache REDIS sont en clair.

Les informations sensibles qui doivent être stockées dans REDIS (ex: un mot de passe SSO pour rejouer une authentification ‘autologon’) sont chiffrées par AES256. Les profils SSO sont stockés dans le repository interne de Vulture (MongoDB) et sont chiffrés par AES256.

Les clés de chiffrement utilisées sont générées dynamiquement sur la base des attributs stockés, de l’utilisateur et d’identifiants internes à Vulture. Ces clés pourraient être compromises en cas d’intrusion sur Vulture (obtention d’un accès SSH illicite sur Vulture avec un compte système).