Gestion de LetsEncrypt sous FreeBSD avec nginx et une jail

LetsEncypt est une autorité de certification utilisant une API basée sur des appels HTTP et un client côté serveur qui va générer des tokens lus par les serveurs LetsEncrypt.

Nous allons ici voir une architecture LetsEncrypt typique dans laquelle nous allons utiliser le client acme-client d’OpenBSD disponible dans les ports et les packages FreeBSD.

Installation

Dans un premier temps installez le client sur votre machine hôte (et pas votre jail web):

Continuer à lire

Apache: obtenir l’IP source depuis un en-tête conditionel dans les logs

Dans le cadre d’un environnement web haute disponibilité il y a généralement des répartiteurs de charge HTTP comme HAproxy ou des reverse proxies comme Apache ou Nginx en frontal qui vont s’occuper de répartir la charge et/ou filtrer une partie des requêtes pour ménager les serveurs d’application de backend.

Le principal problème rencontré dans ce type d’architecture est que, généralement, le service web de frontend va masquer l’IP source du client, réduisant la tracabilité de celui-ci sur les backends. Nous allons ici partir du principe que le service web de frontend retransmet l’IP au backend via un en-tête HTTP nommé X-Real-IP. Continuer à lire

Apache: authentification par certificats

L’authentification par certificats permet de remplacer le traditionnel couple login/password dans un environnement doté de PKI.

Le certificat doit être reconnu par le serveur web, que ce soit par le biais du fait que le CA authentifie côté serveur et qu’on peut également filtrer les utilisateurs par données présentes dans le certificat.

Entre autres, cela permet également d’utiliser des supports externes au clavier pour reconnaître les utilisateurs, comme des lecteurs de carte à puce.

Nous allons voir ici comment activer l’authentification par certificat sous Apache.

Continuer à lire

Shibboleth (IdP): installation et retour d’expérience

Shibboleth est un système de fédération d’identités. Il permet d’authentifier des utilisateurs faisant partie d’établissements/entreprises différentes sur des applications mutualisées.

Peu présent et utile dans le secteur privé, Shibboleth est une référence en terme d’authentification dans le secteur public, au sein du ministère de l’enseignement supérieur et de la recherche. Renater, fournisseur d’accès à Internet réservé aux établissement d’enseignement supérieur et de recherche, est l’un des organismes qui l’utilise le plus.

Shibboleth est composé de plusieurs briques, notamment le Service Provider (SP, fournisseur de services) et dans notre cas le fournisseur d’identité (Identity Provider, IdP)

Continuer à lire

Mettre en place un cluster Apache avec FreeBSD et DragonFlyBSD

Nous allons étudier dans cet article un type d’architecture redondée pour vos serveurs Web Apache. Dans ce type d’architecture, les bases de données sont dissociées du modèle, et ne seront pas étudiées ici. De même nous ne configurerons ni Apache ni le WordPress de test qui seront installés, d’autres articles seront référencés.

Cluster de données

Dans un premier temps nous allons installer le cluster de données. Nous nous basons sur DragonFlyBSD pour son très bon système de fichiers (HAMMER), qui offre d’excellentes performances avec NFS (limité à la version 3). Continuer à lire

Activer la maintenance sur un Vhost

Introduction

Maintenir ses services est essentiel. Si vous n'êtes pas dans une configuration de load balancing ou de haute disponibilité, il convient parfois de mettre des services en maintenance. Il faut savoir que le protocole HTTP intègre un code de retour qui définit un service temporairement indisponible ou en maintenance (Code HTTP 503).

Prérequis

Il est essentiel d'avoir le mod_rewrite activé.

Configuration

Ouvrez le fichier de configuration de votre VirtualHost et ajoutez simplement les lignes suivantes:

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/down.html [NC]
RewriteRule .* /down.html [R=503,L]

Avec ces lignes actives votre serveur est définit en maintenance. Vous pouvez créer une page web down.html afin de personnaliser l'alerte.

Il est bien entendu possible d'utiliser ces lignes pour générer d'autres codes d'erreur.

Reverse Proxy

Introduction

Depuis la version 2.2 d'Apache, une fonctionnalité très intéressante est apparue. Il s'agit du module de reverse proxy. Celui-ci permet de définir un serveur Apache comme forwardant des requêtes HTTP vers un autre serveur, par exemple local. Ceci permet notamment de cacher vos sites derrière un ou plusieurs serveurs web frontaux, répondant à une problématique de sécurité. Nous allons ici voir comment se configure le reverse proxy.

Cette manière de fonctionner permet ainsi de pouvoir changer de serveur à chaud par exemple dans le cas d'une maintenance ou d'un upgrade de site (avec deux machines différentes). Ceci permet également dans le cas d'une attaque web de protéger le transit de données en protégeant le contenu derrière plusieurs passerelles et pare-feu (seul le serveur web peut aller sur le site proxifié).

Prérequis

Vous devez au préalable activer/installer le module _modproxy, _mod_proxyhttp, _mod_proxyftp (si vous forwardez du trafic FTP), _mod_proxyconnect (pour le trafic HTTPS), _mod_proxyajp (serveurs tomcat), _mod_proxybalancer (load balacing de serveurs), _modheaders (pour modifier les en-têtes forwardés), _moddeflate (compression), _mod_proxyhtml (réécriture).

A vous de voir quoi activer. Nous nous contenterons de HTTP et HTTPS dans l'immédiat.

Configuration simple

La configuration d'un reverse proxy se fait dans la configuration d'un VirtualHost. Vous pouvez définir qu'un répertoire se situe sur un autre serveur, ou bien encore toute la base de votre site. Voici le template de base d'un VirtualHost en reverse proxy

<Virtualhost *:80>
      ServerName publicserver.domain.tld
      ServerAlias publicserver.domain.tld
      ProxyRequests off
      ProxyPass / http://localserver.local/
      ProxyPassReverse / http://localserver.local/
</Virtualhost>

Attention: n'oubliez pas le / à la fin de l'URL vers laquelle vous redirigez, sinon il est probable que vous soyez vulnérable à une faille de type proxy bypass.

Lorsqu'un client va se connecter sur l'adresse publicserver.domain.tld, il sera envoyé sur l'Apache frontal qui ira chercher les données demandées sur le serveur connu localserver.local. Le serveur localserver.local peut être une adresse DNS locale non connue du net ou une adresse IP non routable sur le net (conseillé dans une optique de sécurité).

Configuration générique

Voici une petite configuration très intéressante qui permet de rediriger l'ensemble des requêtes vers something.domain.tld vers something.local. Il faut au préalable activer le mod_rewrite d'Apache. Ceci permet de cacher facilement tous vos sites vers un ensemble de serveurs locaux (site1.domain.tld vers site1.local, site2.domain.tld vers site2.local).

<VirtualHost *:80>
  ServerName server.domain.tld
  ServerAlias *.domain.tld
  Rewriteengine On
  ProxyRequests off
  RewriteCond %{HTTP_HOST} (.*).domain.tld
  RewriteRule (.*) $1 [E=WHERETO:%1.local]
  ProxyPassReverse / <a>http://%{ENV:WHERETO}/</a>
  RewriteRule ^/(.*) <a>http://%{ENV:WHERETO}/$1</a> [P]
</VirtualHost>

Nous vous déconseillons d'utiliser cette configuration bien qu'elle permette d'administrer facilement un ensemble de serveurs proxifiés locaux.

Authentification .htaccess

Introduction

Généralement certaines parties de votre site sont sensibles, comme la partie administration. Afin de pouvoir sécuriser de façon plus stricte l'accès au fichiers de ces répertoires, il peut être judicieux de cacher derrière une autre sécurité celui-ci. Le fichier .htaccess permet de mettre des ACL d'accès sur un répertoire ou un fichier.

Prérequis

Vous devez avoir installé le service Apache2

Configuration d'Apache

Les .htaccess sont redoutablement efficaces pour permettre d'interdire l'accès à un répertoire.

Avant de commencer ce topic, vérifier que les lignes suivants du fichier /etc/apache2/apache2.conf sont bien dé-commentées, sinon créez les :

<Files ~ "^.ht">
    Order allow,deny
    Deny from all
    Satisfy all
</Files>

Ces lignes permettent de rendre invisible à quiconque les fichiers .htaccess.

Pour information, vous pouvez éviter de créer des .htaccess en utilisant les directives des VirtualHosts et en entrant les mêmes paramètres.

Configuration du .htaccess

Insérez les lignes suivantes afin de garantir la fonctionnalité du .htaccess :

AuthName "Accès Interdit"
AuthType Basic
AuthUserFile "/var/www/prive/.htpasswd"
Require valid-user

Ensuite il faudra créer le fichier de mots de passe. Dans les dernières version d'Apache ce fichier texte chiffre les mots de passe.

Pour créer le fichier .htpasswd :

.htpasswd -c .htpasswd toto
password: ****
repeat password: ****

Retirez l'option -c une fois que le fichier existe afin de rajouter des utilisateurs.

Votre répertoire est protégé.

ATTENTION : les mots de passe ont beau être chiffrés sur le serveur, ils transitent en clair sur votre réseau, sauf si vous utilisez du SSL !

mod_authnz_ldap

Introduction

Apache permet de s'authentifier via des fichiers .htaccess. Il peut s'avérer utile, notamment dans le cas d'un intranet, d'incorporer une couche d'authentification simple pour filtrer les utilisateurs ayant accès à une application Web. Nous allons voir comment mettre en oeuvre l'authentification LDAP sur un serveur Apache.

Configuration

Tout d'abord il faut activer le module déjà présent avec apache2.

a2enmod authnz_ldap
service apache2 force-reload

La configuration est réalisée au niveau du VirtualHost Apache, au niveau de la section Directory. Pour procéder, ajoutez les lignes suivantes à la configuration du répertoire concerné :

<Directory /private>
# <your VHost configuration>
AuthType basic
AuthName "Acces Restreint"
AuthBasicProvider ldap
AuthLDAPURL ldap://ldap.domain.tld/ou=people,dc=domain,dc=tld?uid
AuthLDAPRemoteUserIsDN off
require ldap-filter &(uid=*)
</Directory>

Cette configuration va permettre à tous les utilisateurs de la branche people du serveur domain.tld de s'authentifier en LDAP.

Pour terminer on recharge le service apache.

service apache2 reload

mod_evasive

Introduction

Apache est un serveur Web. Dans le cas de grosses entreprise il convient de définir une politique de répartition des charges (Load Balancing) afin de pouvoir supporter le nombre de clients et limiter les attaques de grande ampleur sur le service.

Nous allons étudier le paquet mod-evasive (anciennement appelé mod-dosevasive) qui permettra de limiter la charge de votre serveur et permettre ainsi de parer aux attaques de type Denial Of Service

Installation

Afin d'installer mod-evasive tapez la commande :

# Debian
apt-get install libapache-mod-evasive
# Redhat
yum install mod-evasive

Pour pouvoir configurer le module il est nécessaire d'ajouter le fichier de configuration /etc/apache2/conf.d/evasive.

touch /etc/apache2/conf.d/evasive
# ou
echo "" > /etc/apache2/conf.d/evasive

et ensuite éditez le fichier afin d'ajouter le contenu suivant permettant d'utiliser le module :

<ifmodule mod_evasive20.c>
</ifmodule>

Configuration

Pour configurer mod-evasive, il suffit d'ajouter les directives entre les balises ifmodule du fichier /etc/apache2/conf.d/evasive.

Voyons maintenant les diverses options du module.

  • DOSSiteCount: définit le nombre de requêtes autorisées dans un intervalle donné. (Attention n'oubliez pas que si vous utilisez une technologie AJAX il faudra augmenter en conséquence du nombre d'appels)
  • DOSSiteInterval: définit l'intervalle de temps pour DOSSiteCount, en secondes
  • DOSPageCount: définit le nombre de requêtes autorisées sur une même page dans un intervalle donné
  • DOSPageInterval: définit l'intervalle de temps pour DOSPageCount
  • DOSBlockingPeriod: définit l'intervalle de temps pendant lesquelles les IP blacklistées ne pourrons plus ce connecter au site et recevront une erreur 403
  • DOSWhiteList: définit une IP ou plage autorisée, il est judicieux d'autoriser 127.0.0.1.
  • DOSSystemCommand: lance la commande spécifiée lorsque l'IP est ajoutée en Blacklist de mod-evasive
  • DOSEmailNotify: spécifie l'adresse mail à qui envoyer l'alerte de mod-evasive lorsque quelqu'un est bloqué

Exemple de configuration

Voici maintenant quelques exemples de configuration suivant le trafic que vous devrez emmagasiner.

Pour moins de 100 connexions simultanées :

DOSPageCount 100
DOSPageInterval 1
DOSSiteInterval 1
DOSSiteCount 120
DOSBlockingPeriod 30

Pour 100 à 500 connexions simultanées ou si le moyen principal est via une passerelle natée (donc une seule IP) :

DOSPageCount 500
DOSPageInterval 1
DOSSiteCount 1000
DOSBlockingPeriod 20

Pour de plus de 1000 connexions simultanées :

DOSPageCount 2000
DOSPageInterval 1
DOSSiteCount 5000
DOSBlockingPeriod 20

Vous savez désormais gérer le trafic efficacement sur votre Apache. N'oubliez pas d'augmenter la valeur de la directive MaxKeepAliveRequests dans le fichier /etc/apache2/apache2.conf afin de pouvoir supporter le trafic.

Introduction à Apache2

Introduction

Apache est libre et gratuit. Néanmoins la liberté n'accorde pas le privilège de sécurité.

Apache souffre de lacunes au niveau sécurités élémentaires, et la variété des modules que l'on peut installer dessus ne permet pas d'obtenir la parfaite garantie de la fiabilité du système. Je vais vous exposer diverses techniques de sécurité permettant à votre Apache de devenir moins sensibles aux attaques Web.

VirtualHosts et séparation des sites

Apache étant une source très courante d'attaques, nous allons tout d'abord utiliser une méthode très simple mais néanmoins permettant de complexifier votre installation dans le cas ou un hacker aurait potentiellement compris l'architecture de votre machine.

Si vous hébergez plusieurs sites avec des domaines différents, vous connaissez sûrement la notion de VirtualHost.

Cela consiste à créer plusieurs fichiers de configuration afin de séparer la configuration de chacun de vos sites.

Afin que vos sites soient réellement séparés, je vous suggère de mettre leur racine dans des rérpetoires différents et de ne mettre aucune racine commune à plusieurs sites.

Admettons que vous ayez 5 sites (A,B,C,D,E) à héberger, la fonction la plus simple serait de répartir de cette façon :

/var/www/
- ./A
- ./B
- ./C
- ./D
- ./E

Il est déjà bien plus propre de se dire que /var/www correspond au site mère de la machine (ici A).

Séparez les virtualhosts et placez les dans le dossier /var/vhosts que vous aurez préalablement créé. Cette configuration étant moins utilisée elle permettra de gagner en sécurité.

Vous voilà déjà avec un rempart supplémentaire.

Vous pouvez gagner en sécurité en changeant le chemin /var/vhosts et en répartissant dans plusieurs dossiers de /var.

Confidentialité du serveur

Apache est très bavard, surtout lors d'erreurs 404, 403 et autres. Pour le faire taire, le fichier /etc/apache2/conf.d/security sera d'une grande aide.

Première modification, le ServerTokens. Celui-ci permettra de cacher lors des requêtes HTTP le gentil message d'accueil : Debian Jessie (Apache v 2.2.24). Configuration recommandée :

ServerTokens Prod

Seconde modification, ServerSignature. Placer l'option à Off permettra de cacher lors d'erreurs Apache (403,404, etc...) les données que j'ai citées ci-dessus.

ServerSignature Off