Reverse Proxy (Apache et Nginx)

Support Debian
#1

Bonjour,

J’aimerai un petit coups de main pour mettre en place un Reverse proxy. J’aimerai inclure Nginx sur le chemin de mon serveur.

Actuellement : Routeur > Apache2 (Pas top sécurité)
Demande : Routeur > Nginx > Apache2

Domaine :

Routeur DNS:

echo « address=/test.com/www.test.com/192.168.1.101 » > /jffs/configs/dnsmasq.conf.add ; service restart_dnsmasq ;

Machine 1: 192.168.1.100 (Apache)

<VirtualHost *:80>
ServerName test.com
ServerAlias test.com
DocumentRoot /var/www/html/

<VirtualHost *:80>
ServerName wordpress.test.com
DocumentRoot /var/www/html/wordpress

Machine 2: 192.168.1.101 (Nginx)

#2

Bonjour,
Ton site web est uniquement utilisé en interne?
Quelle est la configuration de ton NGINX?

#3

Il faut sur ton serveur nginx un hôte virtuel avec une configuration du type :

server {
	listen 80;
	server_name test.com;
	location / {
		proxy_pass http://192.168.1.101;
		}
}
#4

Bonjour,

Pour la mise en place du https sur le nginx, se serai possible que tu m’expliques car je suis un peu perdu

#5

Expliquer quoi ?
Qu’est-ce que tu as fait ? Qu’est-ce qui ne fonctionne pas ?

#6

Bonjour,

C’est que la configuration actuelle ne prend pas le certificat SSL

#7

Bonjour,

voici une config type:

# redirection http -> https (facultatif)
server {
    listen    80;
    server_name    test.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name    test.com;
    ssl_certificate /chemin/vers/le/certificat;
    ssl_certificate_key /chemin/vers/la/clef/du/certificat;

    location / {
	proxy_set_header X-Forwarded-Proto http;
        proxy_pass http://192.168.1.101;
    }

}

Tu peux bien sûr avoir d’autres directives à ajouter (logs, etc).

Par contre, quel est l’avantage, du point de vue sécurité, d’employer un RP Nginx plutôt qu’Apache ? (c’est une vraie question, je suis assez profane là-dessus)
Si tu ne comptes pas avoir d’autres serveurs web, et si le seul but de la manoeuvre est de protéger ton site avec HTTPS, tu peux très bien faire ça directement sur le serveur Apache, sans avoir besoin d’une tierce machine dédiée au Reverse Proxy HTTPS.

1 J'aime
#8

S’il y a des certificat alors la redirection s’impose pour ne pas contourner les dit certificats.

l’intérêt du RP, c’est que c’est lui qui porte les certificats de tous les sites qui sont derrière. Et de fait aucun besoin d’adapter le site pour le HTTPS car parfois certains développement de site en HTTP laissent des failles HTTP en HTTPS. avec un reverse proxy il y a nécessairement une coupure et si le site web renvoie du HTTP alors que du HTTPS est demandé, le reverse proxy est facile à configurer pour ré-écrire les retour de HTTP vers HTTPS.

Certes il est préférable de bien programmer son site, mais ce n’est pas toujours (souvent?) le cas.

#9

Oui, je voulais dire: « quel est l’intérêt de mettre en place une autre machine avec un RP HTTPS Nginx, alors qu’on peut aussi mettre en place le RP HTTPS localement sur Apache ? »

#10

en terme d’architecture tu n’utilises pas le même process apache pour servir de reverse proxy que le process apache qui s’occupe du site web. Car dans ce cas là ton reverse proxy ne sert plus à rien :slight_smile:

Un reverse proxy c’est pour ne pas exposer directement ton apache. Le RP c’est un frontal au serveur web proprement dit, ils doivent être des process différents sinon la sécurité apportée par le reverse proxy (et éventuellement aussi les fontions de répartition de charge) n’est plus pertinente.

#11

Bonjour,

Merci pour votre aide.

L’objectif est de faire de l’hébergement de site avec plusieurs domaines avec une IP WAN. Le reverse Proxy permet d’avoir l’architecture Frontal / Back-Office.

Le serveur frontal :

Centralisation des certificats (Facilité de gestion)
Rediriger la demande vers le serveur.
Protéger les serveurs en back office
Répartiteur de charge.

Le serveur Back-office

Propose le service demandé (Web, SQL, FTP etc)
Plusieurs serveurs

Exemple:

Site1.com:80 > Frontal > Machine_1:80
Site1.com:443 > Frontal > Machine_1:81
…
Site2.com:80 > Frontal > Machine_2:80
Site2.com:443 > Frontal > Machine_2:81

En termes de sécurité, le serveur back-office sera protéger car le serveur frontal sera attaquer.
Et pour la gestion, j’ai juste à modifier le frontal.

#12

Apache et Nginx sont capables de faire sans reverse proxy avec de simple vhost :wink:

Le reverse proxy en générale est là pour porter du ssl, effectuer une coupure avec l’extérieur, effectuer des opérations de filtrage/restrictions diverses, de la réécriture d’url …

1 J'aime
#13

Bonjour clochette,

J’étais en train de réécrire mon message .

#14

Protégé de quoi ?
Si tu héberges une application web qui présente une faille de sécurité, ce n’est pas la présence d’un mandataire inverse en frontal qui empêchera de l’exploiter.
Plus une architecture est complexe, plus sa sécurisation demandera du temps et de l’attention.

#15

Tu parle d’hébergement , un serveur web ne peut à la fois être serveur du site et reverse proxy du même site.

Le reverse proxy permet d’avoir des règles de sécurité d’utilisation et de vérifier que les requêtes y sont conformes.
Qui plus est, ce n’est pas le cas ici mais encore, tu peux ainsi faire en sorte de ne pas exposer ton site web y compris de ne pas le mettre dans une zone à risque. Ton frontal est dans la DMZ exposée, ton serveur web dans une DMZ non exposée.

Il ne s’agit pas ici de protéger des failles de sécurité du développement du site, il n’en a jamais été question.

Dans une architecture multi-site, il est habituel, voir même conseillé d’utiliser des reverse-proxy en frontal pour éviter d’avoir à exposer directement sur le web les processus d’hébergement. C’est un classique de l’hébergement web depuis pas mal d’année.

Qui plus est, le RP anonymise le serveur web réel vis à vis du client extérieur. Ils intègrent maintenant assez facilement des anti-virus et autres type de scanners. Et au passage, peuvent intervenir sur l’encodage, le cache, la compression etc… Le tout sur un seul serveur et donc plus facile à configurer car centralisé.

#16

Conformes à quoi ?
C’est à l’application web elle même de filtrer les requêtes.

Je ne comprends rien à ces histoire de DMZ exposée et non exposée. Une DMZ est par définition « exposée »…

Et donc c’est censé protéger de quoi ?

Les pratiques à la mode ne sont pas toujours les meilleures. Loin de là. Et la question initiale reste entière.

Cela n’anonymise rien du tout.
Et cela fait deux serveurs à configurer et à maintenir au lieu d’un seul. Ce qui constitue un gaspillage de ressources matérielles, énergétiques et humaines.

1 J'aime
#17

conforme à des règles que tu établies justement dans la configuration du RP.

Une DMZ n’est pas forcement exposée directement à Internet. C’est ce qu’on appelle une DMZ Low Risk. Une DMZ exposée directement à internet est une DMZ High Risk.
Ceci en considérant les expositions entrante et/ou sortante.
Une DMZ peut être exclusivement sortante (par exemple pour un relai de messagerie de l’interne vers l’externe, et entrante pour les email venant de l’extérieur ou les sites web.
Le fait qu’une DMZ soit entrante ou sortante n’expose pas celle-ci aux mêmes risques.

On ne parle pas de mode mais de savoir faire architectural pratiqué par la quasi totalité des entreprises spécialisées et de leurs clients à travers le monde depuis près de 15 à 20 ans.

Bien sur que si, le client « pense » être directement en connexion avec le serveur Web alors qu’il ne l’est pas, et de plus il ne peut savoir où se trouve le serveur web lui-même. c’est anonymisation par offuscation si tu veux.

Ça fait un serveur à configurer pour la partie sécurité au lieu d’avoir à gérer la sécurité de chaque site web 1 par 1. Tu n’as juste qu’un serveur de plus à configurer en plus des différents serveurs web.

Un serveur web n’est pas capable par exemple de vérifier les flags des requetes (ack, syn, etc…), d’ailleurs certaines attaques sont basé dessus. Un RP est capable de le faire. Il peut ainsi verifier la conformité des requete au niveau de toutes les couches, ce qu’un serveur web ne sait pas faire.
Il fait du cache .
Il fait de l’anti-virus.
Il peut faire de la compression de flux (mieux qu’un serveur web) .
Il peut intervenir sur l’encodage.
Il peut faire de la ré-écriture à la volée, y compris sur des couches autres que la couche applicative (couche 7)
et bien sur la répartition de charge avec des critères ou des règles qui peuvent être assez complexes.

C’est ton point de vue, qui visiblement n’a pas été confronté à la réalité des entreprises.
Avec un seul site c’est compréhensible.
Dès que tu commence à avoir 3, 4 10 ou plus sites accessibles, le reverse proxy est une nécessite.

Le reverse prxy est aussi nécessaire si tu ne peux pas exposer directement ton site web sur internet et que tu es obligé de passer par une DMZ. Il y a un grand nombre de site web qui ne peuvent pas être directement exposés sur internet (pour des raisons de sécurité, de service, …).

Par ailleurs, quand tu dois avoir une garantie de service, avec un volume d’accès important, la répartition de charge devient une nécessité, ce qui est aussi une des fonction du RP.

Quand enfin sur tes sites web, tu dois gérer une quantité importante de certificats, la centralisation de cette gestion est très utile pour économiser des ressources humaines par exemple.

Un autre avantage des RP c’est aussi de pouvoir s’assurer qu’une requête en HTTPS est bien servie en HTTPS et qu’il n’y a pas de risque de voir une requêtes HTTP passer à travers, ce qui est bien plus fréquent qu’on ne le croit.

#18

Tu as raison sur certains points dans le cas d’une grosse infrastructure. Pour de la répartition de charge, de la centralisation, etc. oui mais uniquement si c’est justifié par de réels besoins. Pour la sécurité, attention de na pas se croire protégé et de négliger la sécurité des machines qui sont derrière le proxy.
Ceci dit on peut parfaitement avoir 10 sites web ou plus sur le même serveur, sans reverse proxy, de manière tout à fait sécurisée.

Je me place dans le contexte de la question initiale où il s’agit visiblement d’une utilisation a des fins personnelles et avec les deux IP dans un un petit LAN.

1 J'aime
#19

Tout à fait exact, l’un n’exclue pas l’autre. Ils s’additionnent.

dans le même contexte j’ai deux accès WEB et un accès SSH que je fais passer tous les trois à travers un reverse proxy HAproxy.
je n’expose jamais directement un site web sur le net. Même avec une seule machine.

Et l’objectif de départ de la demande inclue un reverse proxy.

#20

Bonjour,

Merci à tous pour vos réponses et point de vu .

La demande initial était de pouvoir mettre un reverse proxy en https pour plusieurs site qui seront hébergés sur plusieurs machines virtuelles différentes. (Services Web et SQL)

D’autre part le reverse proxy à l’avantage de pouvoir centralisé les certificats SSL et de protéger les serveurs web en arrière plan (back-office) qui sont souvent de grosse passoire.

Je comprends qu’en terme de sécurité, le serveur frontal ne protège pas de certaines type d’attaque mais permet un minimum de protection (scanner de port et cie)

L’objectif est d’avoir un minimum de protection, gestion simplifiés et de transmettre pour l’extérieur seulement les services nécessaires à exposer.