Reverse proxy avec NGINX (restauré)

CoolRaoul · le 31 mars 2016

Depuis peu, DSM intègre nativement nginx (Merci à Piwi pour l'info)

Voila qui nous offre donc une 3eme manière d'implémenter un reverse proxy (en alternative à la modif de conf Apache ou l'utilisation de haproxy).

Merci de consulter l'historique des modifications à la fin du post

Principe de base
Pour ne rien risquer de "casser" dans la configuration du serveur nginx système DSM nous allons utiliser une deuxième instance dédiée, réservée à la fonction de reverse proxy. Les deux instance n'auront aucun fichiers en commun et tourneront de façon entièrement indépendante.

Ce dernier va être à l'écoute sur deux ports TCP, un pour le http et l'autre pour https. Comme pour haproxy il conviendra de rediriger sur sa box ou son routeur les connexions entrantes sur les ports http et https standard (80 et 443) vers chacun des ports choisi.

Dans la suite du tuto utilisera les ports 6080 et 6043 mais bien entendu chacun peut choisir.

Important: Il est requis que ces deux ports internes soient ouverts dans le firewall du Syno (si celui-ci est activé)
Préalable:
Mettre en oeuvre la redirection de ports dans la box, exemple dans le cas d'une freebox:

Configuration nginx

Il est préférable de définir un répertoire dédié à la config nginx sur le NAS, je préconise "/usr/local/etc/nginx" (à créer)

On va décomposer la configuration dans 3 fichiers pour éviter les répétitions (tous seront à créer dans ce répertoire):

fichier principal: "nginx.conf"
options proxy: "proxy_defaults.conf"
options SSL: "ssl_defaults.conf"
nginx.conf
Sa structure est la suivante:
```
user http;
#+
#   chemin du log à remplacer à votre convenance
#   attention: dans l'état il ne fait que grossir
#   mettre la ligne en commentaire ou prévoir un mécanisme de rotation
#-   
error_log /var/log/nginx-site-error.log;

events {
    worker_connections  1024;
}

http {
    access_log off;
    proxy_temp_path /var/lib/nginx-local/proxy;
    #
    # Default servers
    #
    server {
        listen       *:6080 default_server;
        listen       *:6443 default_server ssl;
        server_name  _;
        include ssl_defaults.conf;
        location / {
            proxy_pass  http://localhost:80/;
            include proxy_defaults.conf;
        }
    }
    
    <déclaration vhost 1>
    <déclaration vhost 2>
    ...
    <déclaration vhost n>

}
```
La déclaration "server" initiale sert à rediriger par défaut sur le serveur webstation les requêtes ne correspondant pas à un vhost spécifique.
Les VirtualHosts suivants sont à ajouter suivant vos besoins vers les différents services du NAS

Exemple de contenu de vhost pour l'interface DSM gérant HTTP et HTTPS:
```
server {
    listen       *:6080;
    listen       *:6443 ssl;
    server_name  ~^dsm..*$;
    underscores_in_headers on; #uniquement necessaire pour le vhost DSM

    include ssl_defaults.conf;
    location / {
        proxy_pass  http://localhost:5000/;
        include proxy_defaults.conf;
    }
}
```
La syntaxe un peu étrange pour "server_name" est une expression régulière permettant de rediriger toutes les requêtes dont la partie "host" commence par "dsm." (telles que "http://dsm.votre_domaine") vers le port 5000 local.
On notera l'utilisation d'un backend http (l'url assiciée à proxy_pass) pouvant être accédé par un front-end https (listen). Dans ce cas le protocole SSL est entièrement géré par nginx, coté interne, en local on est en full http, suivant le schema:

<navigateur> <-- HTTPS --> NGINX <--- HTTP --> <service>.

Pour les autres services, Il suffit d'ajouter autant de blocs "server" que nécessaire, voici un exemple pour filestation:
```
server {
    listen       *:6080;
    listen       *:6443 ssl;
    server_name  ~^filestation..*$;

    include ssl_defaults.conf;
    location / {
        proxy_pass  http://localhost:7000/;
        include proxy_defaults.conf;
    }
}
```
la définition ci dessus va permettre de rediriger les requêtes de "filestation.votre-domaine" vers le service filestation (quel que soit "votre-domaine")
On remarquera que, grâce au support d'expressions régulières dans la clause "server_name", il n'est pas nécessaire de mettre en dur le nom de domaine dans la config.

Il peut-être plus lisible et pratique de créer des fichiers séparés pour chaque vhost et de remplacer les blocs par des lignes:
```
include <fichier>
```
ou, mieux, mettre tous les fichiers de déclaration de vhosts dans un unique dossier dédié et utiliser une seule ligne include, exemple:
```
include services.d/*.conf
```
Attention: quand on utilise dans les "include" des chemins relatifs comme ci-dessus (c.a.d sans "/" initial), le répertoire par défaut est celui où se trouve le fichier "nginx.conf", le dossier "services.d" doit donc être situé au même endroit.
Filtrage IP
dans les blocs "location" on peut ajouter des clauses "allow" et/ou "deny" pour filtrer l'acces au bloc en fonction de l'ip du client, de façon similaire au clauses apache équivalente.

La syntaxe est simplement une série de clauses:
```
Allow <IP ou IP Range>;
```
et
```
Deny <IP ou IP Range>;
```
IP ou IP Range utilise la même syntaxe que dans les .htaccess (y compris la pseudo addresse "All").
C'est la première (de haut en bas) action (allow ou deny) qui "matche" l'IP du client qui sera appliquée.

Webdav

Webdav peut necessiter d'ajouter la clause "client_max_body_size 20M;" dans les blocs "server" des vhosts correspondants pour éviter une erreur de type "413 Request Entity Too Large" dans le cas d'upload de fichiers volumineux (20M pour 20 MegaBytes, à régler suivant votre besoin).

Ce qui donne:

server {
    listen       *:6080;
    listen       *:6443 ssl;
    server_name  ~^webdav..*$;
    client_max_body_size 20M;
    include ssl_defaults.conf;
    location / {
        proxy_pass  http://localhost:5005/;
        include proxy_defaults.conf;
    }
}

proxy_defaults.conf

proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;

# CF: http://serverfault.com/questions/372886/prevent-nginx-from-redirecting-traffic-from-https-to-http-when-used-as-a-reverse
proxy_redirect http:// $scheme://;

# CF: https://gist.github.com/micho/1712812
proxy_set_header    X-Client-Verify  SUCCESS;
proxy_set_header    X-Client-DN      $ssl_client_s_dn;
proxy_set_header    X-SSL-Subject    $ssl_client_s_dn;
proxy_set_header    X-SSL-Issuer     $ssl_client_i_dn;

ssl_defaults.conf

# NOTE: décommenter un (et un seul) des deux blocks suivants 

# (pour une compatibilité à partir de windows vista et openssl 1.0.1) 
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2; 
ssl_ciphers         ECDHE+AESGCM:ECDHE+AES; 

# Pour une compatibilité à partir de Windows XP et openssl 0.9.8 
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2; 
ssl_ciphers         ECDHE+AESGCM:ECDHE+AES:DES-CBC3-SHA; 

ssl_prefer_server_ciphers on;

# DSM5: décommenter les deux lignes suivantes
#ssl_certificate     /usr/syno/etc/ssl/ssl.crt/server.crt;
#ssl_certificate_key /usr/syno/etc/ssl/ssl.key/server.key;

# DSM6: utiliser les deux lignes suivantes (commenter sinon)
ssl_certificate           /usr/syno/etc/certificate/system/default/fullchain.pem;
ssl_certificate_key       /usr/syno/etc/certificate/system/default/privkey.pem;

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

Lancement de nginx

Pour que nginx soit démarré automatiquement au boot du NAS, il est nécessaire de le faire via un script shell, situé dans "/usr/local/etc/rc.d/".

On va le nommer "nginx.sh" (le .sh est requis). Attention de le rendre exécutable (chmod +x)

Voici son contenu:

#! /bin/ash
#
#   nginx local startup for DSM
#  
PATH="/bin:/usr/bin"

BASE="/usr/local"                      

#   contourner la restriction AppArmor (DSM6)
SYSNGINX=/bin/nginx
NGINX=$BASE/bin/nginx
cp --update --archive $SYSNGINX $NGINX

PREFIX="$BASE/etc/nginx"
CONF="$PREFIX/nginx.conf"
PIDFILE="/var/run/nginx-local.pid"
PROXY_TEMP_PATH="/var/lib/nginx-local/proxy"
[ -f $CONF ] || exit 0

if [ ! -d $PROXY_TEMP_PATH ] ; then
    mkdir -p $PROXY_TEMP_PATH
    chown http:http $PROXY_TEMP_PATH
    chmod u=rwx,g=rwx,o= $PROXY_TEMP_PATH
fi

action=$1
#   build nginx arglist
set -- -p $PREFIX -c $CONF -g "pid $PIDFILE;"
case $action in
    start)
        [ -t 0 ] || exec >/tmp/nginx-startup.log 2>&1
        $NGINX "$@" && echo >&2  "nginx: $action"
        ;;
    stop|reload|quit)
        $NGINX "$@" -s $action && echo >&2  "nginx: $action"
        ;;
    restart)
        for action in stop start
        do
            $0   "$action"
        done
        ;;
    status)
        if [ -r $PIDFILE ] ; then
            ps -www -fp $(<$PIDFILE) # <ligne à utiliser en DSM6, suivante pour DSM5
            ### /bin/ps -w | awk -vpid="$(cat $PIDFILE)" '($1 == pid)'
        fi
        ;;
    *)
        echo "$0: unknown param \"$action\""
        ;;
esac

Ce script sert aussi pour forcer le serveur à prendre en compte modification de config. Il faut utiliser pour cela le paramétre "reload": cela à l'avantage de ne pas tuer le process serveur si une erreur de syntaxe est détectée (utile pour les modifs de conf à distance!)

"restart" sert a faire un redémarrage complet (si on soupçonne une fuite mémoire ou pour être sur de bien repartir complètement à l'état initial)

Utilisation
C'est a peu prés tout

Pour lancer manuellement le serveur:
```
/usr/local/etc/rc.d/nginx.sh start
```
pour lui faire prendre en compte une modification de config
```
/usr/local/etc/rc.d/nginx.sh reload # ou restart, plus radical
```
Notes
Il est fort possible que certaines options puissent être inutiles, ou que d'autres soient à ajouter pour optimiser ou régler tel ou tel détail. Ne pas hésiter à commenter et/ou proposer des modifications.

L'approche que j'ai suivie modifie aucun fichier système DSM et l'intégralité de la config est située sous de /usr/local.

Cela permet de garder le fonctionnement intact même en cas d'upgrade DSM.

J'attends toutes remarques et signalement de bugs
Rotation des logs
Merci à loli71 qui à soumis dans le fil des instructions pour mettre en place une rotation du log logs.

Ses instructions sont ici (et la solution s'intègre directement et proprement au composant de rotation des logs DSM)

Historiques des modifications

15/06/2014:
- déplacé error_log en global
- proxy_http_version dans proxy_defaults.conf
16/06/2014:
- "backends" en simple http
19/06/2014
- Spécificités WebDav
- interface admin DSM (5000/5001): retour au backend https pour frontend https suite à remarque.
20/06/2014
- mutualisation des blocs "server" HTTPS en HTTPS.
- solution au problème de la redirection auto en https en ajoutant la clause "proxy_redirect" appropriée (et retour à la mutualisation en un seul backend http de ce fait)
- le cas "restart" du script de démarrage avait été oublié.
24/06/2014
- ajouté "underscores_in_headers on" pour les liens partagés FileStation sur les dossiers
28/06/2014
- on peut considérer la solution comme stable, supprimé "work in progress"
- clauses "Allow" et Deny"
02/07/2014
- précisions sur les chemins relatifs pour les "includes"
15/09/2014
- supprimé la remarque "work in progress", depuis le temps je pense qu'on peut considérer cette méthode comme stable et pérenne!
- ajouté l'ouverture des deux ports d'écoute de nginx dans le firewall.
12/11/2014
- Ajouté référence à la rotation des logs proposée dans un commentaire
16/04/2016
- utilisation du site http://hilite.me/ pour la colorisation des extraits de conf et de code
20/11/2016
- mise à jour de la configuration SSL suivant les préconisation de @gaetan.cambier

Modifié le 20 novembre 2016 par CoolRaoul

CMDC · le 1 avril 2016

Salut mon ami ,

J'ai profité d'une chouette grippe de la mort qui tue qui me retient à la maison pour mettre à jour mon DS 213J en 6.0.

Du coup, vu que j'ai du temps, j'ai "migré" mes reverse proxy de apache vers nginx, grâce à ce super tuto.

Du coup j'ai un peu simplifié et j'ai simplement créé un fichier nommé "/etc/nginx/sites-enabled/vhosts.conf" que j'ai rempli de la manière suivante:

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_redirect http:// $scheme://;
proxy_set_header    X-Client-Verify  SUCCESS;
proxy_set_header    X-Client-DN      $ssl_client_s_dn;
proxy_set_header    X-SSL-Subject    $ssl_client_s_dn;
proxy_set_header    X-SSL-Issuer     $ssl_client_i_dn;
server {
        listen      80;
        server_name  ~^dsm..*$;
    return 301 https://$server_name$request_uri;
}
server {
        listen *:443 ssl;
        server_name  ~^dsm..*$;
    underscores_in_headers on; #uniquement necessaire pour le vhost DSM

    location / {
                        proxy_pass  http://localhost:5000/;
    }
}

Tout ça parce-que sur internet je préfère toujours utiliser https et donc rediriger http vers https

Voili voilou, si tu souhaites compléter ton super tuto et effacer ma réponse, pas de problème

Modifié le 1 avril 2016 par CMDC

CoolRaoul · le 1 avril 2016

il y a 53 minutes, CMDC a dit :

si tu souhaites compléter ton super tuto et effacer ma réponse, pas de problème

Impec

Je teste ça et l'intègre dans le tuto des que la situation est rétablie (original effacé par moi même comme un gland, donc on reste sur ce fil de backup ou on repart sur l'original)

vm006 · le 3 avril 2016

Hello

Je n'avais pas compris que dans le topic restauré il y avait les corrections pour le DSM 6 (Lu trop vite)

En appliquant la mise à jour sur le script de lancement ... ca marche

Merci :)

yeric79 · le 8 avril 2016

snif !

le seul tuto ou j'avais participé, et y'a plus rien...

mon orgueil en prends un coup :redface:

:biggrin:

PiwiLAbruti · le 8 avril 2016

Il faudrait peut-être retirer les algorithmes passoires/osbolètes dans ssl_defaults.conf (comme SSLv3 ou DES). Je ne sais pas si ça aura un impact négatif sur le fonctionnement en HTTPS, à tester donc.

gaetan.cambier · le 8 avril 2016

il y a une heure, PiwiLAbruti a dit :

Il faudrait peut-être retirer les algorithmes passoires/osbolètes dans ssl_defaults.conf (comme SSLv3 ou DES). Je ne sais pas si ça aura un impact négatif sur le fonctionnement en HTTPS, à tester donc.

ca aura juste un impact négatif pour les hackers

CoolRaoul · le 8 avril 2016

Il y a 2 heures, PiwiLAbruti a dit :

Il faudrait peut-être retirer les algorithmes passoires/osbolètes dans ssl_defaults.conf (comme SSLv3 ou DES). Je ne sais pas si ça aura un impact négatif sur le fonctionnement en HTTPS, à tester donc.

Je le note, mais, pour le moment sans réponse sur l'éventualité de restoration du fil original perdu, je préfère ne pas toucher au tuto dans l'état.

En plus je viens de découvrir que l'option "source du message" avait disparu en mode édition sur le forum alors que c'est celle-la même qui avait sauvé la vie du fil effacé et que j'ai utilisé dans la nouvelle version pour insérer le code colorisé (puisque on n'a plus droit à la colortsation auto des blocs de code non plus) copié/collé à partir de pastebin.

Modifié le 8 avril 2016 par CoolRaoul

mafiaman42 · le 8 avril 2016

Pour ma part j'ai désactiver l'algorithme SSLv3 depuis belle lurette et aucun soucis à déclarer sur aucun de mes navigateurs.

Seul mon IE9 (plus supporté) du boulot tire la gueule

kanjusei · le 11 avril 2016

moi j'ai mis ca dans le fichier ssl_defaults.conf de nginx pour les algorithmes:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:!AESGCM:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK;

Pour les cyphers, j'ai regardé dans les fichiers ssl du webstation.

Modifié le 11 avril 2016 par kanjusei

gaetan.cambier · le 11 avril 2016

il y a 19 minutes, kanjusei a dit :
moi j'ai mis ca dans le fichier ssl_defaults.conf de nginx pour les algorithmes:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:!AESGCM:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK;

interdire aesgcm ? c nouveau ca ? tout comme les courbe elliptique ....

pffff

kanjusei · le 11 avril 2016

AddType application/x-x509-ca-cert  .crt
AddType application/x-pkcs7-crl     .crl

SSLCipherSuite HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!CAMELLIA:!AESGCM:+AES128:+AES256:+3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3

SSLCertificateFile      "/usr/local/etc/certificate/WebDAVServer/webdav/cert.pem"
SSLCertificateKeyFile   "/usr/local/etc/certificate/WebDAVServer/webdav/privkey.pem"

SSLCertificateChainFile /usr/local/etc/certificate/WebDAVServer/webdav/fullchain.pem

#SSLCACertificatePath "/etc/httpd/conf/ssl.crt"
#SSLCACertificateFile "/etc/httpd/conf/ssl.crt/ca-bundle.crt"

#SSLCARevocationPath "/etc/httpd/conf/ssl.crl"
#SSLCARevocationFile "/etc/httpd/conf/ssl.crl/ca-bundle.crl"

Voici les lignes du fichier cipher du webstation. je ne suis pas assez instruit sur le sujet, mais le aesgcm correspond a quoi?

Modifié le 11 avril 2016 par kanjusei

gaetan.cambier · le 11 avril 2016

https://fr.wikipedia.org/wiki/Galois/Counter_Mode

c'est le + sur en aes

tout comme *EDCH* qui sont toutes les courbes eliptique https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques

Gawain · le 13 avril 2016

Bonjour et merci pour ce très bon tuto! J'ai néanmoins une petite remarque et une question.

Si on suit le tuto à la lettre le script ne permet pas de lancer nginx, il faut décommenter #BASE="/usr/local" et commenter BASE="/site"

~~Concernant la question, j'arrive à tout faire marcher à part Photo Station qui fonctionne en version web mais pas en version mobile, voici ma config :~~

server {
listen *:5443 ssl;
server_name ~^photo..*$;

       include ssl_defaults.conf;
       location / {
           proxy_pass https://localhost;
           include proxy_defaults.conf;
       }
   }

Ca marche donc depuis un navigateur mais l'appli DS Photo (sous android, appli à jour) plante purement et simplement. Est-ce que vous pensez que le problème peut venir du reverse proxy nginx? Avez-vous une idée de ce que je peux tester?

~~D'avance merci pour votre aide!~~

EDIT : avec la dernière version de l'appli DS Photo sur android ça marche à nouveau

Modifié le 25 avril 2016 par Gawain

CoolRaoul · le 13 avril 2016

@Gawain en ce qui concerne la variable "BASE", j'avais fait la modif avant l'effacement accidentel de la version la plus récente du tuto

Pour le moment, je ne touche à rien en attendant la réponse à ma requête de récupération à partir des la sauvegarde et le retour de l'option "édition en texte brut" qui à subitement disparu du forum.

Pur Photo Station, vu qu'il a toujours su passer par le port 80, je n'ai jamais eu le besoin d'utiliser le reverse proxy dans ce cas, donc je n'ai pas trop d'idée.

Gawain · le 14 avril 2016

Ok, je comprend mieux! Le tuto reste très utilisable en l'état, ça pousse juste à réfléchir un minimum (ce n'est pas un mal...)

Pour Photo Station ça marchait complètement en DSM5.2 avec Haproxy, je ne voulais pas rediriger d'autres ports vers mon NAS par soucis de sécurité mais j'y viendrai surement si ça ne s'arrange pas. Promis, j'arrête le HS maintenant!

Modifié le 14 avril 2016 par Gawain

CoolRaoul · le 16 avril 2016

Le 14/4/2016 at 12:17, Gawain a dit :

je ne voulais pas rediriger d'autres ports vers mon NAS par soucis de sécurité

J'avoue que ne comprend pas ton problème ici: Photo Station n'utilise pas de port spécifique, il est directement accessible en http/80 et/ou https/443.

jfc3744 · le 2 mai 2016

Passage de haproxy ( probleme haproxy et DSM6) à NGINX :

CoolRaoul, dans ta config le serveur "principal" demandé partout est bien apache et non nginx ( on a le choix) ???

INFOS : Installation de plusieurs syno, plusieurs domaines, 2 owncloud, sites + reste .....

et Moodle ou j'ai encore quelques problèmes d'accessibilité en extranet.

CoolRaoul · le 2 mai 2016

il y a 11 minutes, jfc3744 a dit :

CoolRaoul, dans ta config le serveur "principal" demandé partout est bien apache et non nginx ( on a le choix) ???

Le reverse proxy Nginx est entièrement indépendant du type de serveur choisit dans DSM vu qu'il s'agit d'un front-end: il utilise notament son propre process et ses propres ports TCP.

jfc3744 · le 3 mai 2016

Le 02/05/2016 at 12:46, jfc3744 a dit :

Passage de haproxy ( probleme haproxy et DSM6) à NGINX :

CoolRaoul, dans ta config le serveur "principal" demandé partout est bien apache et non nginx ( on a le choix) ???

INFOS : Installation de plusieurs syno, plusieurs domaines, 2 owncloud, sites + reste .....

et Moodle ou j'ai encore quelques problèmes d'accessibilité en extranet.

D'abord merci à CoolRaoul pour son tutoriel et la réponse à ma question.

Tout marche (j'ai donc abandonné haproxy pour nginx.. et oui on peut mettre sur le forum les 'choses' qui marchent) SAUF MOODLE, je cherche sur internet, mais si quelqu'un a une solution, n'hésitez pas.

NAS1 (nginx) qui redistribue temporairement à NAS1, NAS2, NAS3 et NAS4 (noms de domaine avec owncloud, sites et autres) et Moodle ( sur un des NAS différents).

c'est la connexion de l'extérieur Moodle qui marche pas, ça marche en interne (d'un nas à l'autre, même en passant vers l'exterieur).

Modifié le 3 mai 2016 par jfc3744

Fenrir · le 29 octobre 2016

Bon tuto, comme je passais par là, je me permets juste quelques petites remarques :

on aussi se servir de nginx pour accéder à d'autres interfaces que celles présentent sur le Syno (routeur, switch, caméra ip, autre nas, ... en pratique n'importe quel serveur http/https et pas uniquement ceux présents dans le lan).
je recommande de ne pas mettre les backend directement dans proxy_pass, mais d'utiliser la directive upstream, c'est plus propre et ça ouvre un éventail de possibilités (failover, LB, ...)
et pourquoi pas un peu de auth_basic, histoire de mettre une couche d'authentification devant les applis sensibles

Pour le chiffrement, voici ce que j'utilise sur la plupart de mes serveurs (pas testé sur un syno par contre, mais à par peut être l'ocsp, tout devrait marcher) :

        resolver                   <un DNS fiable et rapide> valid=300s;
        resolver_timeout           1s;

        keepalive_timeout 70;
        ssl_session_cache shared:ssl_session_cache:10m;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        ssl_prefer_server_ciphers on;
        ssl_dhparam <clef d'échange DH à générer avec : openssl dhparam -out dh-4096.pem 4096>;

        ssl_protocols TLSv1.2;

        ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:!DSS:!MD5:+HIGH;

        ssl_stapling               on;
        ssl_stapling_verify        on;
        ssl_trusted_certificate    <chaine de certification>;

        ssl_certificate         <certificat TLS, de préférence en ECDSA>;
        ssl_certificate_key     <clef du certificat>;

        #entête HSTS à n'utiliser que sur les sites qui devront TOUJOURS être en HTTPS)
        add_header Strict-Transport-Security "max-age=31536000";

C'est à mon avis un assez bon compromis compatibilité/sécurité/performances (sous réserve d'utiliser un certificat correct).

ps : c'est un peu du déterrage, mais sur un tuto ça ne compte pas :razz:

Modifié le 29 octobre 2016 par Fenrir

CoolRaoul · le 30 octobre 2016

Il y a 14 heures, Fenrir a dit :

comme je passais par là, je me permets juste quelques petites remarques :

on aussi se servir de nginx pour accéder à d'autres interfaces que celles présentent sur le Syno (routeur, switch, caméra ip, autre nas, ... en pratique n'importe quel serveur http/https et pas uniquement ceux présents dans le lan).

Absolument, je l'utilise d'ailleurs pour accéder de l'extérieur a l’interface d'admin de ma Freebox sans avoir besoin d'ouvrir directement les ports d'icelle.

Citation

je recommande de ne pas mettre les backend directement dans proxy_pass, mais d'utiliser la directive upstream, c'est plus propre et ça ouvre un éventail de possibilités (failover, LB, ...)

Ca je connais pas. A ma décharge faut comprendre que lorsque je me suis initialement attelé à la rédaction de ce tuto, je n'avais strictement aucune expérience Nginx. C'est suite à une suggestion de @PiwiLAbruti dans un autre fil que je me suis attaqué au sujet.

Citation

et pourquoi pas un peu de auth_basic, histoire de mettre une couche d'authentification devant les applis sensibles

+1000, à utiliser par exemple pour accéder plus discrètement aux appareils connectés à domicile ne disposant pas de contrôle d’accès.

Modifié le 30 octobre 2016 par CoolRaoul

Fenrir · le 30 octobre 2016

Il y a 1 heure, CoolRaoul a dit :

Ca je connais pas

En gros tu définis des cibles pour le reverse proxy et tu t'en sers dans proxy_pass, exemple :

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Avec ça tu peux faire de la tolérance de panne, de l'équilibrage de charge, automatiser les maintenances et factoriser la conf

Victorien · le 10 novembre 2016

Bonsoir,

J'ai un problème avec votre script de lancement nginx.sh voici l'erreur

/usr/local/etc/rc.d/nginx.sh: /bin/ash^M: bad interpreter: No such file or directory

une idée d'ou cel apourrait-il venir ? Merci

Fenrir · le 10 novembre 2016

Tu as copié collé depuis windows avec un mauvais éditeur (ou mal réglé)

Comme tu sembles être sous Windows, utilises notepad++ et choisi le format UTF-8 (sans bom), sinon avec sed/awk/tr/dos2unix/... tu devrais pouvoir corriger le fichier.

Connexion

Reverse proxy avec NGINX (restauré)

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

CoolRaoul

Fenrir

Rejoindre la conversation

Qui est en ligne 6 membres, 0 anonyme, 299 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante