Sur centos / RHEL :
le cron weekly lance ceci :
run-parts /etc/cron.weekly
ce qui produit de temps en temps l’erreur suivante :
/etc/cron.weekly/99-raid-check: WARNING: mismatch_cnt is not 0 on /dev/md2
Cela provient du fait qu’il y a des blocs non synchronisés.
Pour le réparer il faut lancer en root :
echo repair >/sys/block/mdX/md/sync_action
attendre que sync_action revienne à idle puis
echo check >/sys/block/mdX/md/sync_action
Le prochain cron ne généra plus d’erreurs.
Les services FTP ont toujours été difficile à filter.
Tout ceci à cause des modes ftp (actif / passif) qui change la donne.
Voici quelques explications :
Mode actif :
C’est le mode par défaut des clients FTP. Le client établi dans un premier temps une session TCP sur le port 21 (FTP) du serveur (« control channel »).
Une fois la session établie et l’authentification FTP acceptée, c’est le serveur qui établi une session TCP (avec le port source 20, FTP-DATA) vers un port dynamique du client (« data channel »).
Mode passif :
Le mode passif est conseillé à partir du moment où l’on est derrière un pare-feu.
Comme pour le FTP actif, le client établi une première session TCP sur le port 21 (FTP) du serveur (« control channel »). Une fois la session établie et l’authentification FTP acceptée,
On demande au serveur de se mettre en attente de session TCP grâce à la commande PASV. Alors le client peut établir une seconde session TCP sur un port dynamique vers le serveur (« data channel »).
il faut d’abord charger le module ip_conntrack_ftp ( pour suivre les connexions ftp).
modprobe ip_conntrack_ftp
Ensuite la commande suivantes pour que la connexion puisse s’établir :
iptables -A INPUT -i eth0 -p tcp \--sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp \--sport 21 -m state --state ESTABLISHED -j ACCEPT
Ensuite, c’est la que l’on a besoin de ip_conntrack_ftp, pour que le serveur puisse établir la connexion pour les données ( en mode actif).
iptables -A INPUT -i eth0 -p tcp \--sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp \--sport 20 -m state --state ESTABLISHED -j ACCEPT
Pour que le serveur puisse établir la connexion pour les données (en mode passif) ici le mode ip_conntrack_ftp est nécessaire.
iptables -A INPUT -i eth0 -p tcp \--sport 1024:65535 --dport 1024:65535 -m state ESTABLISHED -j ACCEPT iptables -A OUTOUT -o eth0 -p tcp \--sport 1024:65535 --dport 1024:65535 -m state ESTABLISHED,RELATED -j ACCEPT
Voilà !
Par défaut, Nginx affiche sa version dans les headers http. On peut pour des raisons de veilles versions ou de vulnérabilités vouloir cacher cette version.
Par défaut nous avons ceci :
$ curl -I https://www.cloud-devops.fr/ HTTP/1.1 200 OK Server: nginx/1.9.10 Date: Fri, 05 Feb 2016 20:57:50 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding
Si l’on veut ne plus afficher la version 1.9.10, il faut ajouter dans le bloc « http » l’option :
server_tokens off;
Après un restart de Nginx, nous obtenons ceci :
$ curl -I https://www.cloud-devops.fr/ HTTP/1.1 200 OK Server: nginx Date: Fri, 05 Feb 2016 21:04:09 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding
Voilà ça fonctionne ! Notre version de Nginx est maintenant masquée aux utlisateurs.
C’est toujours dans une approche d’optimization de notre serveur ainsi que de l’expérience utilisateur que nous allons aborder la mise en place de la compression Gzip des requêtes http sur Nginx. Nous avons déjà vu comment mettre en cache nos fichiers statiques pour rendre notre site plus rapide. Ici nous allons voir comment compresser nos requêtes.
Vous devez avoir le module ngx_http_gzip_module de compiler sur votre nginx. C’est généralement le cas par défaut.
Les paramètres gzip sont à mettre dans le bloc « http » généralement ce bloc se trouve dans le fichier nginx.conf.
On y ajoute les paramètres suivants :
gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 4 32k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/javascript font/eot font/opentype image/svg+xml image/x-icon text/plain;
Et l’on redémarre nginx.
Les lignes les plus importantes sont gzip on; et gzip_types.
Quelques explications :
On peut surcharger nos paramètres en le mettant dans le bloc « server ».
Par exemple si l’on met gzip off dans un bloc « server » cela désactivera la compression gzip sur notre domaine.
Nous allons tester à l’aide de curl si nos paramètres sont bien pris en compte.
$ curl -I --header "Accept-Encoding: gzip" https://www.cloud-devops.fr/ HTTP/1.1 200 OK Server: nginx Date: Fri, 05 Feb 2016 14:32:20 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Content-Encoding: gzip
Si vous voyez « Vary: Accept-Encoding » et « Content-Encoding: gzip » c’est que votre serveur est bien paramétré.
Pour plus d’infos sur le module gzip voici le documentation nginx officiel gzip
Il est très important de bien configurer votre serveur nginx pour servir correctement les fichiers statiques (images, javascript, css, texte …).
Cela vous permet d’économiser la bande passante de votre serveur et également d’améliorer l’expérience utilisateur. L’utilisateur aura l’impression que votre site se charge plus vite.
L’utilisateur n’aura pas besoin de télécharger de nouveau ce fichier js ou l’image car son navigateur l’aura déjà dans son propre cache.
La mise en cache des fichiers statiques, coté du navigateur, se fait à l’aide des headers renvoyés par le serveur.
Il faut être sur d’avoir le module ngx_http_headers_module compilé avec nginx. C’est le cas par défaut.
Il y a plusieurs paramètres à mettre en place pour configurer correctement nos headers.
Prenons l’exemple suivant :
location ~* \.(png|jpg|jpeg|gif|ico|woff|otf|ttf)$ {
root /var/www/static/;
access_log off;
log_not_found off;
}
Ce paramètre permet de contrôler la durée de mise en cache. Il est par défaut à off. La directive expires permet d’agir sur les headers http Expires et Cache-Control
Ce paramètre peut prendre différents paramètres epoch,max,une durée, off ou une heure.
Dans la plupart des cas un expires max; ou expires 1y; sera bien efficace. Dans notre exemple cela donne :
location ~* \.(png|jpg|jpeg|gif|ico|woff|otf|ttf)$ {
root /var/www/static/;
access_log off;
log_not_found off;
expires 1y;
}
Cette directive prend des options libres c’est à nous de renseigner ce que l’on veut. Nos paramètres doivent correspondre aux standard du protocol http pour être interprété par l’ensemble des navigateurs et proxies.
Nous allons intervenir sur le header Cache-Control. Avec le paramètre expires nous sommes déjà intervenu sur le cache-control pour mettre max-age=31536000. Il faut maintenant décrire la façon dont cela doit être conserver. Plusieurs options sont à notre disposition :
Nous allons donc de notre coté mettre le paramètre add_header Cache-Control « public »; qui va permettre de mettre nos fichiers en cache pour tout le monde et de les stocker. Dans notre exemple cela donne :
location ~* \.(png|jpg|jpeg|gif|ico|woff|otf|ttf)$ {
root /var/www/static/;
access_log off;
log_not_found off;
expires 1y;
add_header Cache-Control "public";
}
A l’aide d’un curl nous allons tester que cela fonctionne.
$ curl -I https://www.cloud-devops.fr/wp-content/uploads/2016/02/log_nginx.jpg HTTP/1.1 200 OK Server: nginx Date: Fri, 05 Feb 2016 12:07:27 GMT Content-Type: image/jpeg Content-Length: 181406 Last-Modified: Thu, 04 Feb 2016 21:31:59 GMT Connection: keep-alive ETag: "56b3c34f-2c49e" Expires: Sat, 04 Feb 2017 12:07:27 GMT Cache-Control: max-age=31536000 Pragma: public Cache-Control: public Vary: Accept-Encoding Accept-Ranges: bytes
Nous avons le header Cache-Control à public, le Cache-control max-age à 365 jours et un Expires à la date du Sat, 04 Feb 2017 12:07:27 GMT. Tout fonctionne parfaitement !
Nous avons vu précédemment que nous pouvions exclure des logs nginx une url spécifique et même une adresse ip.
Nous allons voir ici, comment exclure de nos logs un user agent spécifique. Par exemple nous ne voulons pas avoir dans nos logs le user agent de notre monitoring « mymonitoringBot » ou encore celui de « Googlebot ».
Nous allons créer un bloc « map » pour y mettre nos règles :
map $http_user_agent $log_useragent {
~Googlebot 0;
~mymonitoringBot 0;
default 1;
}
On assigne la valeur 0 aux user agent Googlebot et mymonitoringBot. Toutes les autres user agent auront la valeur 1.
Il suffit ensuite de mettre cette condition dans notre bloc « server« .
server {
...
access_log /var/log/nginx/access.log main if=$log_ua;
}
N’entrerons dans les logs que la valeur 1 qui correspond à la valeur par défaut. Notre fichier access.log ne contiendra pas les user agent Googlebot et mymonitoringBot.
Pour des raisons pratiques, on peut vouloir exclure de nos logs nginx une ou plusieurs adresses ip.
Nginx déconseille d’utiliser le « if » dans la configuration de nginx et le considère comme le mal !
Nous allons créer un bloc « map » pour y mettre la liste des adresses ips. Ce bloc « map » doit être créer en dehors du bloc « server« .
Vous pouvez avoir envie d’exclure le localhost ou encore l’ip de votre monitoring.
map $remote_addr $log_ip {
"127.0.0.1" 0;
"1.2.3.4" 0;
default 1;
}
On assigne la valeur 0 aux adresses ip 127.0.0.1 et 1.2.3.4. Toutes les autres adresses ip auront la valeur 1.
Il suffit ensuite de mettre dans le bloc « server » notre condition sur nos logs.
server {
...
access_log /var/log/nginx/access.log main if=$log_ip;
}
Les adresses ip 127.0.0.1 et 1.2.3.4 n’apparaitront plus dans le log access.log.
On peut vouloir exclure des urls spécifiques dans nos logs. Cela facilitera les futurs recherches par exemple.
Dans la config de nginx, on utilise très souvent le bloc « location » pour définir les paramètres d’un type d’url, par exemple pour servir les fichiers statiques.
Vous avez sans doute ce type de configuration :
location ~* \.(png|jpg|jpeg|gif|ico|js|css)$ {
root /var/www/static/;
expires max;
}
Pour que les urls de nos images, js ou css n’apparaissent pas dans nos logs, il suffit d’ajouter l’option « access_log off; »
Comme ceci :
location ~* \.(png|jpg|jpeg|gif|ico|js|css)$ {
root /var/www/static/;
expires max;
access_log off;
log_not_found off;
}
Vous pouvez noter que j’ai également ajouter l’option « log_not_found off; » qui permet de ne pas écrire dans le fichier « error_log » les fichiers manquants.
Il existe un utilitaire en ligne de commande qui permet d’agir sur fail2ban.
Il s’agit de fail2ban-client. Il s’utilise de cette façon :
fail2ban-client set JAILNAME unbanip IPADDRESS
Pour connaitre le vrai « JAILNAME », on peut utiliser cette commande :
# iptables -L -n target prot opt source destination fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22
Chez moi, « JAILNAME » correspond à fail2ban-ssh
Ce qui donne la commande suivante :
# fail2ban-client set ssh unbanip 1.2.3.4
Depuis sa version 1.9.5, nginx apporte le support du protocole http version 2. Si vous utilisiez déjà le module SPDY, il est remplacé par le module HTTP/2.
Pour savoir si vous supportez ce protocole :
# nginx -V
Vous devez avoir une version supérieur à 1.9.5 et avoir dans les options de compilations –with-http_v2_module. Si vous n’avez pas cette option, il faudra mettre à jour votre version de nginx.
Il faut savoir que l’implémentation de HTTP/2 requière du HTTPS.
Pour ajouter la prise en charge de HTTP/2 dans la configuration de nginx, il suffit de remplacer dans le bloc server { }
listen 443 ssl;
par :
listen 443 ssl http2;
On recharge ensuite la config :
# service nginx restart
Pour vérifier que cela fonctionne correctement je vous invite à faire le test sur :