Paramétrages NGINX

23
mai
11
Catégorie : software
Marqué : ,

Après avoir installé NGINX il convient de le configurer, paramétrer, sécuriser, optimiser.

Pour l’instant j’utilise NGINX uniquement pour servir du contenu privé protégé par mot de passe, je n’ai donc que peu accentué mon paramétrage sur la sécurité.

 

Paramétrage du nombre de process

Dans son article Seagate DockStar : 1er mois d’exploitation Vincent Rabah indique qu’il a paramétré son Dockstar qui héberge son blog avec 3 workers process nginx et 5 cgi children process.

Par contre dans l’article nginx: configuration complète | Shtark.fr il est conseillé de ne pas dépasser 2 pour les worker process.

J’ai pour ma part choisi peu de process car de toute façon mon serveur NGINX sera peu sollicité car utilisé que par un nombre restreint d’utilisateurs :

  • 2 workers process nginx (paramétré dans /etc/nginx/nginx.conf)
  • 2 cgi children process (paramétré dans /etc/init.d/php5-fcgi)

 

Compression gzip

Sous apache il s’agit du module deflate sous NGINX il s’appelle  HTTP gzip.

La configuration se fait dans /etc/nginx/nginx.conf :

gzip            on;
# désactivation de la compression pour les navigateur ne la prenant pas en charge (IE < 6)
gzip_disable    "MSIE [1-6].(?!.*SV1)";
gzip_vary       on;
gzip_comp_level 3;
gzip_proxied    any;
gzip_buffers    16 8k;
gzip_types text/plain text/html text/css application/json  application/x-javascript text/xml application/xml application/xml+rss  text/javascript;

 

Pour le détail des différentes directive se reporter au manuel NGINX pour HttpGzipModule

 

La dernière directive (gzip_types) indique les types de fichiers servis par NGINX qui peuvent prétendre à la compression GZIP, c’est à dire tous les ficheirs de type texte pour lesquels la compression sera effective (il est inutile de compression une image jpeg qui est déjà compressée)

Cette directive est importante parce que par défaut seul le type mime text/html est paramétré (pas les css ni les js).

 

Le réglage peut se faire sur la directive gzip_comp_level qui permet de régler le taux de compression (entre 1 et 9), trop faible la compression ne sera pas très importante et trop élevé elle consommera des ressource lors de l’envoi des données

On peut connaitre le taux de compression via le site http://www.whatsmyip.org/http_compression/qui outre le fait d’indiquer si votre navigateur réclame du contenu compressé :

Indique le taux de compression pour une page donnée :

 

Mise en cache client des ressources statiques

Il s’agit d’une directive indiquant au navigateur du client de mettre en cache les ressources statique que l’on défini (fichiers images, js, etc.).

Ainsi si l’utilisateur retourne une nouvelle fois sur la page/site le navigateur affichera la ressources statique qu’il a en cache au lei de la redemander au serveur Web.

Mon installation à partir du script de Nicolargo, positionne la directive expires dans le default-site pour les ressources statiques :

location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {
	expires 	30d;
	access_log	off;
}

Le gain est très important et peu être visible avec le site http://www.webpagetest.org/ qui permet d’analyser le temps de chargement d’une page.

Le site réalise 2 chargements successifs de la même page et le gain est flagrant (test fait sur une page contenant beaucoup d’images) :

Document Complete Fully Loaded
Load Time First Byte Start Render Time Requests Bytes In Time Requests Bytes In
First View 25.426s 5.912s 6.745s 25.426s 167 1,066 KB 25.426s 167 1,066 KB
Repeat View 7.241s 5.963s 6.081s 7.241s 1 7 KB 7.241s 1 7 KB

 

Modification de la signature du serveur

Dans les en-têtes HTTP et les pages d’erreur NGINX indique son nom et la version utilisée:

Cela facilite le travail des pirates qui peuvent cibler les serveurs/versions présentant une faille de sécurité.

La signature du serveur sera donc réduite à “nginx” avec la directive server_tokens à off :

Fichiers de log

Afin de surveiller plus précisément les accès aux différents service privés que mon Dockstar héberge j’ai choisi de faire un fichier de log d’accès par service/répertoire/location.

J’ai donc une ligne access_log dans chacun de mes blocs location :

location images/ {
	...
	access_log	/var/log/nginx/images.access.log;
	...
}

Je n’ai pas personnalisé le format des logs par défaut (nommé combined) avec la directive log_format.

Ce format le voici :

log_format combined '$remote_addr - $remote_user [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Ce qui donne par exemple :

192.168.1.254 - user [11/Apr/2011:21:56:29 +0200] "GET /test/phpinfo.php HTTP/1.1" 200 9766 "http://www.monDomaine.fr/test/" "Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0"

 

Pour finir avec les logs à noter qu’il est possible de spécifier sur les logs d’erreur le niveau de détail avec la directive error_log :

error_log  /logs/nginx_error.log  warn;

 

Le niveaux sont debug | info | notice | warn | error | crit | alert | emerg | off

Par défaut le niveau est warn.

 

Divers

Favicon et 404

Lorsque l’on a pas de Favicon sur son site NGINX log régulièrement des Erreurs HTTP 404

Pour y remédier il suffit d’ajouter ceci dans sa configuration :

location = /favicon.ico {
 access_log       off;
 return   204;
 }

A voir : Boost your nginx web server performance by rewriting favicon.ico requests correctly

 

Configurations communes

Pour mutualiser divers éléments de configuration sur les différents site hébergé par mon serveur NGINX, j’ai créé un fichier /etc/nginx/common.conf contenant ces configurations.

# Sécurité : les fichiers en .ht sont interdits d'accès
 location ~ /\.ht {
 deny  all;
 }
 
# Erreur 404 sur Favicon
 location = /favicon.ico {
 access_log       off;
 return   204;
 }
 
# Mise ne cache des ressources statiques
location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {
 expires         30d;
 access_log      off;
 }

 

Il me suffit ensuite d’inclure ce fichier dans la configuration de chacun de mes sites :

include /etc/nginx/common.conf;

 

Redirection sous domaine

Pour faire une redirection d’un sous-répertoire du domaine parent vers son propre sous-domaine voici la configuration utilisée.

Par exemple pour rediriger http://www.mondomaine.fr/application vers http://application.mondomaine.fr :

location /application {
 rewrite ^/application/?(.*) $scheme://application.mondomaine.fr/$1 permanent;
 }

 

Autres paramétrages pas encore effectués

(et peut être jamais effectués sur le Dockstar)

 

 

2 commentaires

Les commentaires sont fermés.