1. Installation

1.1. Debian

Récupérer le fichier .deb dans la section téléchagement du site de vulture (http://vulture.open-source.fr/download/) :

# apt-get install libapache2-mod-php5 php5-curl apache2-mpm-prefork apache2.2-common \
libapache-session-perl libapache2-mod-perl2 libauthen-radius-perl libio-socket-ssl-perl \
libconvert-asn1-perl libcrypt-blowfish-perl libcrypt-cbc-perl libcrypt-ssleay-perl \
libdbd-pg-perl libdbd-sqlite2-perl libdigest-sha1-perl libhtml-parser-perl libhtml-tree-perl \
libipc-run-perl libmcrypt4 libnet-ldap-perl libperl5.10 liburi-perl libwww-perl php5-ldap \
libmysqlclient15off libdbd-mysql-perl libcache-memcached-perl libstring-crc32-perl \
openssl php5-pgsql php5-sqlite sqlite sudo memcached libcgi-pm-perl php5
# dpkg -i vulture.deb

L'interface d'administration démarre automatiquement sur http://localhost:9090. Le fichier sudoers est mis à jour automatiquement pour permettre à l'utilisateur apache de lancer d'autres processus apache.

1.2. Gentoo

1. Le fichier /etc/make.conf doit contenir : USE = “ldap apache2 postgres dba pear sqlite session curl cli pcre xml xml2 mpm-worker cgi threads ithreads” (il peut être necessaire de recompiler perl et libperl si ithreads n'était pas activé).
2. Extraire le fichier ebuild/vulture-X.Y.ebuild de vultureng-X.Y.tar.bz et le placer dans /usr/portage/net-proxy/vulture (créer le repertoire préalablement)
3. Copier vulture-X.Y.tar.bz2 dans /usr/portage/distfiles

     ACCEPT_KEYWORDS="~x86" emerge --digest vulture
     echo "apache ALL=NOPASSWD:/usr/sbin/apache2" >> /etc/sudoers
     /etc/init.d/vulture start
     

1.3. Systèmes utilisant RPM

Récuperer le INTRINsec-common correspondant à la distribution cible et désactiver selinux.

  rpm -i INTRINsec-common vulture.noarch.rpm
  echo "apache ALL=NOPASSWD:/opt/INTRINsec/httpd/bin/httpd" >> /etc/sudoers
  /etc/init.d/vulture start

L'interface d'administration démarre automatiquement sur http://localhost:9090

1.4. Installation à partir des sources

1.4.1. Dépendances

• openssl

• httpd >= 2.2

• php (4 ou 5)

• mod_perl >= 2

• libwww-perl
• perl-ldap
• perl-DBI-1.51
• perl-DBD-SQLite 0.33
• perl-DBD-Pg
• perl-Apache-Session
• perl-Convert-ASN1

• perl-ExtUtils-MakeMaker

• perl-CGI
• perl-URI
• perl-Apache-SSLLookup
• perl-Crypt-CBC
• libmcrypt
• perl-Digest-SHA1

• RadiusPerl

• perl-Data-HexDump

• perl-Crypt-Blowfish
• perl-Crypt-SSLeay
• perl-IO-Socket-SSL
• perl-Net_SSLeay
• perl-DBD-mysql
• perl-IPC-Run

1.4.2. Génération d'un certificat autosigné pour l'interface d'administration

cf http://vulture.open-source.fr/wiki/Documentation#head-63848109c38e8e207f360fe5f4878f1be30c0164

1.4.3. Interface d'administration

Les fichiers de configuration apache utilisés pour l'interface d'administration de Vulture sur les distributions à base de RPM, à base de .deb et à base d'ebuild se trouvent respectivement dans les repertoires rpm debian et ebuild des sources de Vulture, dans le fichier httpd.conf. Ces fichiers peuvent servir de base à votre installation à partir des sources.

2. Connexion à l'interface d'administration

Une fois Vulture installé vous pouvez accéder à l'interface d'administration à l'adresse : https://localhost:9090

L’adresse d’écoute de l’interface d’administration de Vulture peut être modifiée dans le fichier /opt/INTRINsec/vultureng/conf/httpd.conf (Directives Listen et VirtualHost). On peut aussi conserver l’adresse par défaut 127.0.0.1:9090 et faire un tunnel SSH pour se connecter à l’interface d’administration.

3. Ajouter une interface

Une interface est en fait un processus apache defini par une IP et un port sur lequel "binder". Les applications seront ensuites rattachées à cette interface. Dans la liste des interfaces différentes icones representent differents états et actions possibles :
: l'interface fonctionne
: l'interface est éteinte
: permet d'éteindre l'interface
: signifie qu'un redémarrage est nécessaire pour appliquer les changements et permet de redémarrer l'interface.

3.1. Interface SSL

Le fichier http://vulture.open-source.fr/download/samples/openssl.cnf est un exemple de configuration utilisé avec la commande suivante pour générer un certificat autosigné (option -x509 pour l'autosignature) :

   openssl req -x509 -days 1825 -newkey rsa:1024 -batch\
                -out server.crt\
                -keyout server.key\
                -nodes -config openssl.cnf

Vous pouvez alors coller les fichiers server.crt et server.key dans l'interface d'édition d'une interface Vulture (activer SSL dans le menu "action" à droite).

Pour renouveller un certificat, auprès de verisign par exemple, il vous faut une CSR (certificat signing request). Vous pouvez regenerer une CSR à partir de la clé privé et du certificat (normalement disponible depuis l'édition de l'interface dans Vulture) :

  openssl x509 -x509toreq -signkey private.key -out newcsr.csr -in oldcert.pem

4. Ajouter une application

Le champ alias permet de définir des noms internet supplémentaires (séparés par une virgule si on souhaite en definir plusieurs). Attention de ne pas utiliser un nom déjà défini pour une autre application. Il est également possible d'utiliser des expressions régulières dans les alias (ex: .*\.mondomaine.fr). Il faut bien comprendre qu'un point dans le champs alias signifie "n'importe quel caractère" car les alias sont exprimés en expressions régulières.

Comme pour les interfaces, il est possible de stopper une application. Lorsqu'un utilisateur souhaitera accéder à une applicat

4.1. Répartition de charge

En cliquant sur l'action "Répartition de charge", l'interface permet de préciser plusieurs URL privées. Vulture selectionnera alors de manière aléatoire les differentes URL privées (sans détéction d'indisponibilité).

5. Authentification

Pour utiliser les méthodes d’authentification, vous devez attribuer à une interface réseau un nom internet pointant sur l’IP de cette interface. C'est sur ce nom de domaine que l'authentification aura lieu. A partir des versions 1.9x ce nom peut être partagé par une application. Le nom internet doit être spécifié via le formulaire de l’action “Activer le portail SSO” dans l’interface d’édition d’une interface.

5.1. SQL

La méthode « vultureng » est définie par défaut lors de l’installation de vulture. Elle permet d’authentifier les utilisateurs présents dans la base interne de Vulture. Cette base est directement alimentée depuis le menu « Utilisateur ». Cette base interne est de type SQLite. Vous pouvez ajouter des utilisateurs dans cette base sans pour autant que ces utilisateurs puissent accéder à l'interface d'administration. Il faut pour cela décocher l'attribut "administrateur" lors de l'ajout ou lors de l'édition de l'utilisateur dans le menu "Utilisateur" de Vulture.

Dans le cas d'une base de type SQLite, la base correspond au chemin du fichier de base de données :

5.2. LDAP

Il est possible de préciser plusieurs IP ou noms de machines dans le champ serveur (séparés par une virgule). Si un LDAP venait à être injoignable, le second serait alors utilisé. Le champs "L'attribut de recherche est un DN" permet de spécifier que les membres d'un groupe sont à chaque fois définis avec leur DN complet (ie : member: cn=ads,ou=Users,dc=intinsec,dc=fr, member:cn=oeufdure,ou=Users...). L'attribut de recherche dans les groupes permet de definir le nom de l'attribut qui contient les utilisateurs du groupe alors que l'attribut du groupe contient uniquement le nom du groupe (utilisé pour l'affichage des groupes lors de la définition d'ACL). Pour une configuration type AD cela donne :

5.3. SSL

Pour l'authentification par certificat il suffit de coller le certificat d'AC. Vulture verifiera alors juste qu'un certificat présenté par un client est signé par cette AC et le jettera le cas écheant si l'option "Obligatoire" a été sélectionnée.

5.3.1. Listes de revocations

Pour utiliser une liste de revocation, il suffit d'ajouter la ligne suivante dans les directives VirtualHost de l'application utilisant la méthode d'authentification SSL (il vous faudra au préalable mettre au point un système permettant d'amener le fichier .crl localement au serveur Vulture) :

SSLCARevocationFile /chemin/vers/la/crl.crl

Pour que la liste de révocation soit prise en compte il faut envoyer un signal HUP à tous les processus Vulture. Etant donné que la rotation de log exige elle aussi un signal HUP (cf http://vulture.open-source.fr/wiki/Documentation#head-0b766ef5148a8ca194be8ec8023c21d7e6dae40a) il suffit de veiller à ce que la rotation de log s'effectue juste après la mise à jour de la CRL. Dans le cas de l'utilisation conjointe du signal HUP pour les CRL et pour la rotation des logs il faut compter 24h maximum pour qu'une revocation soit prise en compte (si le logrotate est lancé toutes les 24h).

5.4. PKI

5.5. RADIUS

6. Afficher la liste des applications accessibles via le portail SSO

Pour les méthodes d'authentification SQL et LDAP, une option permet d'afficher la liste des applications auxquelles un utilisateur à accès. Cet liste s'affiche juste après l'authentification.

Pour utiliser cette fonctionnalité il faut un nom de portail SSO dédié (ne pas utiliser le FQDN d'une application definie dans Vulture).

7. Propagation de l'authentification (SSO Forward)

Le « SSO Forward » permet à Vulture d’aller beaucoup plus loin que le simple SSO. Il est en effet possible d’associer à un identifiant de connexion, sur Vulture, un profil applicatif, et de transférer automatiquement ce profil vers l’application interne (via une methode POST ou une entête "authorization") :

1. L’utilisateur s’authentifie sur Vulture
2. Vulture vérifie si l’utilisateur peut accéder au site
3. Vulture récupère le profil de l’utilisateur
4. Vulture envoi le profil de l’utilisateur vers le site

Si l’utilisateur ne dispose pas encore de profil, Vulture lui demandera de saisir les informations (ou les enverra automatiquement, en fonction du type de profil).

Les mots de passe du profil applicatif sont chiffrés. Le mot de passe de la méthode d’authentification est utilisé comme clé de chiffrement.

Si la méthode d’authentification ne demande pas de mot de passe, comme c’est le cas pour l’authentification SSL, l’utilisateur est invité à saisir un code PIN pour le chiffrement de son profil. Il lui sera demandé à chaque nouvelle connexion à l’application pour déchiffrer son profil.

Lorsque le mot de passe de l’authentification de l’utilisateur sur Vulture change, Vulture demande alors l’ancien mot de passe pour déchiffrer le profil chiffré avec l’ancien mot de passe et le rechiffre automatiquement avec le nouveau mot de passe.

Cela permet de s’authentifier avec un mot de passe unique à des applications necessitant chacune un profil (nom d’utilisateur, mots de passe) different.

7.1. Autologon

La propagation autologon, qu'elle soit de type formulaire POST ou Htaccess, permet de transférer, inchangés, les logins et mots de passe utilisateurs utilisés sur Vulture.

7.2. "Htaccess" versus "Formulaire POST"

Deux types de propagation de l'authentification sont possible :

• L'authentification de type Htaccess et une authentification prévue par le protocole HTTP. Le login et le mot de passe de l'utilisateur sont envoyés dans une entête HTTP encodé en base 64 et séparés par ":". Vous pouvez reperer cette authentification quand votre navigateur ouvre une pop-up de ce type :

FIXME

• L'authentification par formulaire HTML est une authentification qui nécessite de la part de l'utilisateur de remplir un formulaire HTML (le plus souvent avec un login et un mot de passe) et de le valider. La validation se traduit pour le navigateur par l'envoie d'une requête POST au serveur HTTP avec les valeurs saisies par l'utilisateur.

Exemple de requête POST :

POST / HTTP/1.1
Host: app1.domain.fr
Content-Type: application/x-www-form-urlencoded
Content-Length: 19

login=ads&pass=toto

7.3. Exemples

7.3.1. Htaccess autologon

L'application est configuré pour le htaccess_autologon. Le selecteur encadré en rouge n'apparait que si vous avez séléctionné une méthode d'authentification :

Une authentification est demandée par Vulture à toute personne souhaitant accéder à l'application.

7.3.2. Htaccess (avec profil)

L'application est configuré pour le htaccess (htaccess simple).

Cette fois, ET UNIQUEMENT LORS DE LA PREMIERE CONNEXION, les informations de profils sont demandées à l'utilisateur.

Une fois saisies ces informations apparaissent dans le menu "Profils" de l'interface d'administration de Vulture.

7.3.3. POST autologon

Dans cette exemple nous souhaitons propager un couple login/mot de passe vers une application particulière, l'interface d'administration de Vulture.

En analysant le code HTML et/ou en utilisant le plugin LiveHTTPHeaders de firefox (cf http://vulture.open-source.fr/wiki/Documentation#head-595ee4682f38961f36603af8e6605ad66e62316c) nous constatons que trois champs sont envoyés dans la requête POST lors de l'authentification. Ce sont les variables form_login (champ hidden statique), login (le login de l'utilisateur) et pword (le mot de passe).

Pour utiliser la propagation dans une de nos applications il nous faut un composant de type SSO Forward (menu "Composants" -> "SSO Forward").

Analysons le composant SSO Forward "vultureng".



Le composant contient bien :

• un champ de type "hidden" nommé form_login contenant la constante Logon (tel que dans le code HTML).
• un champ de type "text" (c'est à dire un champ que l'utilisateur devra renseigner en clair et qui ne sera pas chiffré dans la base de Vulture) nommé "login". Dans le formulaire de renseignement du profil (lors de la permière connexion), ce champs sera décrit comme "login" comme le nom de la variable.

* un champ de type "password" (c'est à dire protégé par des étoiles dans le formulaire d'apprentissage et qui sera chiffré dans la base de profil de Vulture). Il sera décrit comme Password et renseignera la variable pword.

Nous utilisons ce composant dans l'édition de l'application comme ceci :

7.4. Utilisation de scripts SSO Forward

En plus des types hidden, text et password des variables d'un composant SSO Forward, il existe un type "script" qui permet de faire appel à un script ou à n'importe quel binaire. En valeur, nous saisissons le chemin du script ou du binaire. Il sera passé, en parametre de ce script, dans l'ordre : nom de l'utilisateur, mot de passe de l'utilisateur, url du formulaire (tel que renseigné dans l'édition de l'application), nom de la variable, id de l'application, id du certificat (si présent).

8. Redirections (exemples)

  1. ^/secure => /index.php?do=secure [R]
  2. ^/redirect=(.*) => http://$1 [R]
  3. ^/admin => /administration [P]
  4. ^/admin => [403]
  5. ^/(?!public) => [403]
  6. .* => http://www.exemple.fr/enroll.php [NOCERT,R]
  7. ^/admin => /enroll.php [NOCERT,P]

1. le [R] signifie que la redirection sera envoyé à l'utilisateur (redirection externe). Par exemple, http://www.exemple.fr/secure renverra une redirection vers http://www.exemple.com/index.php?do=secure

2. Il est possible d'utiliser des expressions régulières Perl pour les redirections. Par exemple http://www.exemple.com/redirect=http://www.intrinsec.com renverra vers http://www.intrinsec.com.

3. le [P] signifie que la redirection sera faite de façon interne à Vulture et donc transparente pour l'utilisateur. Par exemple, http://www.exemple.com/admin/index.php renvera le contenu de l'URL http://www.exemple.com/administration/index.php de manière transparente pour l'utilisateur.

4. Des codes de retours peuvent également être utilisés par exemple /admin renverra le code d'erreur {{FORBIDDEN}}.

5. Toute URL qui ne commence pas par public renverra le code 403.
6. Si l'utilisateur ne présente pas de certificat client il sera redirigé
7. Même chose qu'en 6 mais redirection interne.

9. ACL

L’action « Gérer une liste d’accès » dans l'édition d'une application indique à Vulture que seuls les utilisateurs faisant parti d’une liste pourront s’authentifier. Autrement dit:

• Sans liste de contrôle d’accès, tous les utilisateurs ayant un login/mot de passe valides peuvent s’authentifier
• Avec liste de contrôle d’accès, seuls les utilisateurs ayant un login/mot de passe valides ET faisant parti de la liste peuvent s’authentifier

La colonne de gauche est remplie avec la liste des utilisateurs trouvés pour la méthode d’authentification séléctionnée.

On ajoute et supprime un utilisateur de l'ACL en cliquant sur les fleches gauche et droite.

Pour supprimer la liste d’accès, il suffit de cliquer sur « Autoriser pour tous » dans le menu action. puis de cliquer sur « Envoyer ».

9.1. ACL SQL par groupe

La définition et l'édition d'une méthode d'authentification SQL permet de préciser le nom d'une colonne définissant une appartenance à un groupe :

9.1.1. Exemple de table avec association directe du groupe

Dans ce cas nous pouvons indiquer à Vulture que le groupe est défini dans la colonne "group" et cela permet de définir des ACL depuis l'interface d'administration :

9.1.2. Création d'une vue pour associer une colonne groupe à une table

Dans le cas où la colonne du groupe n'est pas directement liée dans la table contenant les utilisateurs il faut passer par la création d'une vue SQL.

Par exemple, si nous avons :

et

Nous pouvons définir la vue "vulture_view" :

CREATE VIEW vulture_view AS SELECT vulture_user.login, vulture_user.password,
vulture_group.name FROM vulture_user, vulture_group WHERE vulture_user.login=vulture_group.member;

Cela équivaut à une table "vulture_view" :

10. Réécritures des entêtes

Vulture permet d’ajouter des headers http aux requêtes à destination des applications via le formulaire de l’action « Entêtes HTTP ».

Il existe des types prédéfinis subsitués par VultureNG dynamiquement:

• REMOTE_ADDR : Adresse du client distant
• SSL_CLIENT_M_SERIAL : Numéro de série du certificat client
• SSL_CLIENT_I_DN : DN de l’autorité de certification signataire du certificat client
• SSL_CLIENT_M_DN : DN du certificat client
• SSL_CLIENT_V_START : Date de debut de validité du certificat client
• SSL_CLIENT_V_END : Date de fin de validité du certificat client

Le type “Personnalisé” permet de definir une entête statique, vous devez donc definir une valeur. Les valeurs dynamiques apparaissent en italique.

11. Vulture en action

11.1. OWA

Il faut au préalable configurer le serveur Exchange pour n'accepter que l'authentification Basic. L'entête Front-End-HTTPS permet d'indiquer à l'Exchange que le front end est en https (pour que les redirections se fassent toujours en HTTPS).

11.2. Haute disponibilité

Cette section détaille la configuration heartbeat à adopter.

11.2.1. /etc/ha.d/authkeys

•    auth 1
     1 sha1 VerySecretPassword
   

11.2.2. /etc/ha.d/haresources

•     # Vulture_1 est le serveur nominal
      Vulture_1 192.168.36.11 vulture
   

11.2.3. /etc/ha.d/ha.cf

Ce fichier diffère d'une machine à l'autre :

•    keepalive 1 
     deadtime 10
     warntime 5
     initdead 10
     udpport 694
     ucast eth0 <IP autre Vulture>
     auto_failback on
  
     node Vulture_1
     node Vulture_2
  
   

11.2.4. Synchronisation

Dans un cron toutes les nuits et uniquement depuis le serveur secondaire (éviter les synchronisations pendant des heures ou la configuration sera modifiée) et après avoir autorisé les clés ssh entre les machines.

Sous Redhat

•     rsync -az -e ssh SRV-RP01:/opt/INTRINsec/vulture/sql/* /opt/INTRINsec/vulture/sql/
      rsync -az -e ssh SRV-RP01:/opt/INTRINsec/vulture/conf/*.\{crt,crl,tpl,key\} /opt/INTRINsec/vulture/conf/
      rsync -az -e ssh SRV-RP01:/opt/INTRINsec/vulture/conf/[0-9]*.conf /opt/INTRINsec/vulture/conf/
   

Sous Debian

•     rsync -az -e ssh s-rproxy:/var/www/vulture/sql/* /var/www/vulture/sql/
      rsync -az -e ssh s-rproxy:/var/www/vulture/conf/*.\{crt,crl,tpl,key\} /var/www/vulture/conf/
      rsync -az -e ssh s-rproxy:/var/www/vulture/conf/[0-9].conf /var/www/vulture/conf/
  
   

11.2.5. Sessions partagées (répartition de charge)

Depuis la version 1.99 de Vulture, les informations de sessions sont stockées dans un démon memcached en écoute sur localhost:9091. Ce démon est lancé et stoppé par le script d’arrêt et démarrage de Vulture (/etc/init.d/vulture). Dans ce mode par défaut, en cas de bascule d’un serveur Vulture à un autre, les informations de sessions sont perdues car chaque instance de Vulture utilise uniquement son serveur de sessions.

Pour modifier ce comportement et ne pas perdre les sessions en cas de bascule 3 modifications doivent être effectuées.

* Mise en commentaire des deux lignes concernant memcached dans le script /etc/init.d/vulture (pour ne pas l’éteindre lors d’une bascule) :

#       $MEMCACHED -d -m 512 -l 0.0.0.0 -p 9091 -u apache
[...]
#       kill -12 `pidof $MEMCACHED`

* Ajout du démarrage du serveur memcached au démarrage du système (pour chaque serveur) : Dans /etc/rc.local :

/usr/bin/memcached -d -m 512 -l 0.0.0.0 -p 9091 -u apache
exit 0

* Modification d’une ligne de code de Vulture dans /opt/vulture/lib/i386-linux-thread-multi/Vulture.pm sur chaque serveur pour utiliser les deux serveurs de sessions :

      tie %$session, 'Apache::Session::Flex', $id, {
                                        Store     => 'Memcached',
                                        Lock      => 'Null',
                                        Generate  => 'MD5',   
                                        Serialize => 'Storable',
                                        Servers => [ '192.168.0.1:9091', '192.168.0.2:9091' ],

12. Deconnexion des applications

Pour que Vulture intercepte l’URL de déconnexion de l’application et redirige vers une page de déconnexion Vulture (ou un message utilisateur ou un code HTML de fermeture de la page), on peut généralement faire ceci dans la section règle de réecriture comme ceci :

^/logout.asp$ => /?vulture_logout [R]

Cependant certaines applications n’ont pas une page de déconnexion mais un paramètre GET dans la requêtes qui indique une déconnexion (ie : index.asp ?action=Logout). La section règle de réecriture Vulture ne permet pas une réecriture en fonction des paramètres GET. Il faut donc utiliser mod_rewrite (plus puissant) dans les directives VirtualHost :

RewriteEngine   On
RewriteCond %{QUERY_STRING}  .*action=Logout.*
RewriteRule index.asp /?vulture_logout [R]

L'utilisation du module mod_rewrite n'est possible de base qu'en utilisant INTRINsec-common car le module est patché comme suit pour intervenir avant mod_proxy. Sous Debian, il faut donc appliquer la patch au mod_rewrite du système.

--- httpd-2.2.11/modules/mappers/mod_rewrite.c.ori      2009-02-01 00:36:56.000000000 +0100
+++ httpd-2.2.11/modules/mappers/mod_rewrite.c  2009-02-01 00:40:07.000000000 +0100
@@ -4867,6 +4867,7 @@
      * escaped accidentally by mod_proxy's fixup.
      */
     static const char * const aszPre[]={ "mod_proxy.c", NULL };
+    static const char * const aszPost[]={ "mod_perl.c", NULL };

     /* make the hashtable before registering the function, so that
      * other modules are prevented from accessing uninitialized memory.
@@ -4881,7 +4882,7 @@

     ap_hook_fixups(hook_fixup, aszPre, NULL, APR_HOOK_FIRST);
     ap_hook_fixups(hook_mimetype, NULL, NULL, APR_HOOK_LAST);
-    ap_hook_translate_name(hook_uri2file, NULL, NULL, APR_HOOK_FIRST);
+    ap_hook_translate_name(hook_uri2file, NULL, aszPost, APR_HOOK_FIRST);
 }

     /* the main config structure */

13. Modules

13.1. mod_security

Vulture permet de mettre en place des filtres de contenu, de manière à bloquer toutes les requêtes potentiellement dangereuses. Ces filtres reposent sur le module Apache mod_security. La syntaxe des directives à employer est donc celle liée à ce module. L’accès à l’interface de gestion des filtres applicatifs se fait depuis le menu « Filtres Applicatifs ». Vulture est installé avec un certain nombre de filtres applicatifs par défaut. Ces filtres sont issus du projet « ModSecurity Core Rules ».

13.2. mod_log

Il est possible de défninir des formats de journalisation personalisés. Ces formats de journalisation permettent de modifier la façon dont Apache enregistre l’activité. La syntaxe des directives à employer est celle utilisée par les modules Apache mod_logio et mod_log_config. L’accès à l’interface de gestion des formats de journalisation se fait depuis le menu «Journaux ». Vulture est installé avec quelques format de journalisation standards :

13.3. mod_env

Il existe un bug entre mod_proxy et IIS qui provoque un message du type "Proxy error". Pour contrer ce problème on peut charger le module mod_env via config.php et ajouter les directives virtualhosts suivantes :

  SetEnv force-proxy-request-1.0 1
  SetEnv proxy-nokeepalive 1

13.4. ModProxyPerlHtml

Le module Perl ModProxyPerlHtml est un filtre mod_perl independant de Vulture très pratique pour la substitution de contenu transitant par Vulture (redirections incorrectes, liens en dur incorrectes, etc). Il est packagé avec Vulture (normalement installé automatiquement avec Vulture).

Il faut parfois ajouter l'entête HTTP Accept-Encoding à "identity" de manière à éviter la compression Gzip et ainsi permettre à ModProxyPerlHtml de fonctionner.

Pour l'activer rendez vous dans l'interface d'édition d'une application, activez "VirtualHost directives" et copiez les lignes suivantes :

PerlInputFilterHandler Apache2::ModProxyPerlHtml
PerlOutputFilterHandler Apache2::ModProxyPerlHtml

Ensuite, par exemple pour remplacer les liens absolus http://app1.domain.fr, en lien relatif (permettant d'utiliser le nom publique de l'application défini dans Vulture) :

PerlAddVar ProxyHTMLURLMap "http://app1.domain.fr /"

Ou par exemple pour remplacer un appel d'une image sur un site distant en un appel en relatif, local :

PerlAddVar ProxyHTMLURLMap "http://www.alfresco.com/img/alfresco.gif /img/monlogo.gif"

13.5. mod_access

Par défaut, Vulture autorise toutes les IP à se connecter sur ses interfaces. Il est possible d'ameliorer encore le niveau de sécurité de vos applications en autorisant spécifiquement certaines IP et/ou en en interdisant d'autres à se connecter.

L'action "Contrôle d'accès" permet de spécifier des règles du module mod_access.

Par défaut :

AllowOverride None
Order deny, allow
Allow from all

Reportez vous à la documentation du module mod_access pour plus d'informations.

13.6. mod_cache

Mod_cache permet a vulture d'activer la fonction de cache sur le reverse proxy. Pour l'activer, décommentez dans le fichier config.php les lignes contenant LoadModule cache_module , LoadModule disk_cache_module ou LoadModule mem_cache_module. Ensuite suivant quel module vous avez activé (disk_cache ou mem_cache), il faut activer "VirtualHost directives" et rajouter les directives suivantes:

Pour mem_cache:

    CacheEnable mem /
    MCacheSize 4096
    MCacheMaxObjectCount 100
    MCacheMinObjectSize 1
    MCacheMaxObjectSize 2048

Pour disk_cache:

    CacheRoot /opt/INTRINsec/vulture/cache
    CacheEnable disk /
    CacheDirLevels 5
    CacheDirLength 3

13.7. mod_evasive

Mod_evasive permet de protéger les applications de vulture contre les attaques DOS. Pour l'activer, décomenter dans le fichier config.php la ligne contenant LoadModule evasive20_module. Ensuite il faut activer "VirtualHost directives" et rajouter les directives suivantes:

    DOSHashTableSize 3097 
    DOSPageCount 2 
    DOSSiteCount 50 
    DOSPageInterval 1 
    DOSSiteInterval 1 
    DOSBlockingPeriod 10 
    DOSLogDir "/var/log/mod_evasive"

Avec:

DOSHashTableSize : table de hashage
DOSPageCount : Seuil du nombre de fois où une même page peut être demandée 
pendant l’intervale définit à DOSPageInterval
DOSSiteCount : Seuil max à partir duquel une personne est bloquée dans la
consultation du site durant l’intervalle définit à DOSSiteInterval
DOSBlockingPeriod : Période en secondes pendant laquelle la personne est blockée
DOSLogDir : où est stocké le fichier de log

13.8. mod_deflate

Activer mod_deflate dans le fichier config.php permet de compresser a la volé le contenu des pages que vous souhaitez. Par exemple vous souhaitez compresser tous ce qui est html, text et xml, il faut rajouter cette directive dans "VirtualHost directives":

 AddOutputFilterByType DEFLATE text/html text/plain text/xml

13.9. Vulture::OutputFilterHandler

Ce module fait partie du contrib de vulture (http://vulture.open-source.fr/download/contrib/) et est a installer manuellement dans le répertoire contenant le fichier ResponseHandler.pm. Il faut aussi passer un patch sur le fichier TransHandler.pm. Pour cela copier le fichier http://vulture.open-source.fr/download/contrib/TransHandler.patch dans le même répertoire que le fichier TransHandler.pm, puis lancer la commande suivante patch -p0 < TransHandler.patch . Ce module permet de modifier une partie du flux entre vulture et le navigateur client en rajoutant de nouvelles directives dans "Règles de réécriture".

Les directives sont les suivantes:

[MH] : Mime Header (Modifie ou rajoute un header par rapport au type mime)
[H] : Header (Ajoute un header sans conditions)
[UH] : Unset Header (Enlève un header)
[F] : Forbiden (Désactive la récupération d'un type mime)
[L] : Link (Réécriture de lien) 
[RH] : Remplace la valeur d'un header par substitution
[HL] : Prend la valeur du header et fait un substitution dans toute la page renvoyé
au navigateur 
[HP] : Fait un reverse proxy sur la valeur du header renvoyé 

Par exemple:

image/png => Cache-Control => max-age=3300 [MH] #Permet de mettre le header Cache-Control
a max-age=3300 seulement pour les images png

Server => GFE/1.3 [H] #Ajoute le header Server a GFE/1.3 dans chaque requette http 

Etag [UH] #Enlève le header Etag

image/jpeg [F] #Permet de ne pas afficher les images de type jpeg sur le navigateur

/administration => /admin [L] #Reécris les liens contenant administration en admin
(Code de ModProxyPerlHtml)

location => www.test.fr => www.monsite.fr [RH] #Remplace pour le header location
la valeur www.test.fr par www.monsite.fr

X-Forwarded-for => www.toto.fr [HL] #Prend la valeur du header X-Forwarded-for
(par exemple www.test.fr) et procède ensuite a une substitution de www.test.fr
par www.toto.fr dans la page html retournée au navigateur client 

Realsite [HP] #Prend la valeur du header Realsite puis vulture utilise ensuite cette
valeur comme url privé (par exemple http://www.test.fr) 

Pour activer ce module, il faut rajouter dans "VirtualHost directives":

PerlOutputFilterHandler Vulture::OutputFilterHandler

13.10. Vulture::PostReadRequestHandler

Ce module fait partie du contrib de vulture (http://vulture.open-source.fr/download/contrib/) et est a installer manuellement dans le répertoire contenant le fichier ResponseHandler.pm Il permet de rediriger automatiquement le navigateur vers la bonne interface contenant l'application. Par exemple si on tape http://www.test.fr mais que l'application est en fait sur une interface ssl, le module va automatiquement rediriger le navigateur sur https://www.test.fr. Pour activer ce module, il faut soit modifier chaque fichier d'interface (1.conf, 2.conf ...) ou modifier le fichier If.php.

Il faut rajouter dans la déclaration générale de l'interface (entre PerlResponseHandler Vulture::ResponseHandler et le premier <virtualHost x.x.x.x>):

PerlPostReadRequestHandler Vulture::PostReadRequestHandler 

14. Mise à jour

La base de donnée contient toutes les informations de configuration de vos applications, vous devez donc en garder une copie avant la mise à jour de VultureNG (fichier /opt/INTRINsec/VultureNG/sql/db). Ici nous donnons l’exemple de la migration d’une version 1.0 vers une version 1.2. Nous executons la commande sqlite de mise à jour pour tous les fichiers sql/sqlite.dump.x.y qui separent la version initiale de la version vers laquelle on souhaite migrer.

rpm -Uvh INTRINsec-common vultureng-1.2.noarch.rpm
mv /opt/INTRINsec/vultureng/sql/db.rpmsave /opt/INTRINsec/vultureng/sql/db
tar vxfj vultureng-1.2.tar.bz2
sqlite /opt/INTRINsec/vultureng/sql/db < vultureng-1.2/sql/sqlite.dump.1.1
sqlite /opt/INTRINsec/vultureng/sql/db < vultureng-1.2/sql/sqlite.dump.1.2

15. Journalisation

15.1. Rotation des fichiers de log

Sur les distributions où Vulture est packagé en RPM, le fichier /etc/logrotate.d/vultureng doit contenir en fonction de la distribution linux :

15.1.1. Distributions RPM

/var/log/Vulture-*log {
    postrotate
        /usr/bin/killall -HUP httpd
    endscript
}

15.1.2. Gentoo / Debian

/var/log/Vulture-*log {
    postrotate
        /usr/bin/killall -HUP apache2
    endscript
}

15.2. Use of uninitialised variable dans les logs (version 1.97 et antérieures)

Pour éviter d'avoir des warnings liés au code dans les fichier de logs il faut commenter les lignes :

use strict;
use warning;

dans les fichiers ResponseHandler.pm et TransHandler.pm (utilisez la commande locate pour touver ces fichiers sur votre distribution).

15.3. Analyse de logs avec webalizer

Pour générer les statistiques de chacunes de vos applications quotidiennement avec Webalizer, vous pouvez par exemple ajouter LE RESULTAT de la commande suivante dans une crontab. Cette commande peut nécessiter certaines adaptations dans les chemins de répertoires selon la distribution que vous utilisez :

echo "SELECT 'mkdir /opt/INTRINsec/vultureng/www/webalizer/'||name||'; webalizer -n \
'||name||' -o /opt/INTRINsec/vultureng/www/'||name||' \
/var/log/Vulture-'||name||'-access_log' FROM app;" | sqlite /opt/INTRINsec/vultureng/sql/db | sh

Vous pouvez par exemple créer le répertoire /opt/INTRINsec/vultureng/www/webalizer/ (/opt/INTRINsec pour les distributions RPM, /var/www pour debian, etc...) et activer le listing de répertoire dans la configuration apache de l'interface d'administration de vulture pour pouvoir accéder à la liste des applications sur https://localhost:9090/webalizer/

Exemple de statistiques webalizer :

16. Nettoyage régulier des sessions (version 1.98 et inférieures)

Pour éviter que les perfs ne deviennent désastreuses au bout d'un certain temps, il faut penser à purger la base de donnée liées aux sessions (dans le cas ou Vulture est utilisé pour l'authentification et/ou le SSO).

Si vous n'avez pas le binaire sqlite pour le format de fichier de la version 2 il vous faut l'installer. Ici, pour éviter de deconnecter tout le monde je n'efface que les sessions les plus anciennes.

• Trouver le fichier "sessions" via la commande `locate sessions'
• Se mettre dans le repertoire du fichier et taper :

#!/bin/sh

SESSION=/var/www/vulture/sql/sessions
SQLITE=/usr/bin/sqlite

echo 'DELETE FROM sessions WHERE id IN (SELECT id FROM sessions LIMIT' \
  `echo 'SELECT COUNT(*) - COUNT(*)*10/100 FROM sessions;' | $SQLITE $SESSION`');' | \
   $SQLITE $SESSION
echo 'VACUUM;' | $SQLITE $SESSION

Cette commande élimine les 90% de sessions les plus anciennes. On peut mettre cette commande dans une crontab pour être effectuée par exemple le 1er de chaque mois à 1h00 (0 1 1 * *).

Attention à bien mettre les chemins complet pour le binaire sqlite et pour le fichier sessions.

17. Personalisation des chartes graphiques

17.1. Mire d'authentification

Le répertoire /opt/INTRINsec/vulture/conf (/var/www/vulture/conf sous debian) contient un fichier default.tpl (utilisez la commande `locate default.tpl' sur les autres distribution pour trouver son chemin). Ce fichier contenant du code HTML est utilisé si aucun fichier de la form <id de l'application>.tpl n'est trouvé dans le même répertoire. Ce fichier doit contenir le mot clé FORM (double underscore avant et après).

La balise optionnelle NAME peut également être utilisée. Elle contient le nom de l'application à laquelle on souhaite accéder.

17.2. Mire pour l'enregistrement d'un profil

Sur le même principe que précédemment, profile.tpl et profile_<id application>.tpl peuvent être crées/modifiés.

18. Utilitaires d'analyse HTTP

18.1. LiveHTTPHeaders et ieHTTPHeaders

Respectivement plugins pour Firefox et IE, LiveHTTPHeaders et ieHTTPHeaders permettent de tracer toutes les requêtes HTTP (y compris les redirections) faites par le navigateur vers Vulture.

Ces plugins sont d'une aide précieuse pour la configuration du SSO Forward car ils permettent de voir exactement les champs postés lors d'une requête POST.

• http://livehttpheaders.mozdev.org/
  

• http://www.blunck.se/iehttpheaders/iehttpheaders.html
  

18.2. TCPDump

TCPDump vient en complement des plugins firefox/IE précedemment cités pour analyser le traffic entre Vulture et l'application.

Les options -X et -s 1024 doivent être activées pour visualiser le contenu des trames.

18.3. Ouadjet

Ouadjet est un programme permettant de créer des règles mod_security à partir d'un fichier de log.

• http://software.inl.fr/trac/trac.cgi/wiki/Ouadjet