Reverse Proxy (Apache et Nginx)

Support Debian
#21

Bien entendu qu’il le peut, c’est d’ailleurs ce que font une grande majorité des hébergeurs fournissant de l’espace d’hébergement à pas cher packagé …

Apache et Nginx peuvent assurer ces rôles tous les deux l’un comme l’autre.
Maintenant l’intérêt est limité certes mais c’est possible.

Je pense malgré tout qu’il vaut mieux apprendre à mettre en place un serveur web bien configuré et utiliser un applicatif sérieux au niveau des standards de sécurité du web, que de sortir une infra mal sécurisé qui finalement fera plus de mal que de bien.

C’est pas ce que j’appelle des backoffices.
Et en quoi Nginx et Apache (et ce ne sont de plus pas les seuls) à jour et configuré correctement sont des passoires ?

Se tenir informé des CVE c’est une partie du métier de sysadmin :see_no_evil: :hear_no_evil: :speak_no_evil:

1 J'aime
#22

Quand je parle du serveur, je parle du processus serveur. Un même processus apache ne peux pas faire à la fois le reverse proxy et le service web.
mais un processus pour le serveur web et un processus pour le reverse proxy, ça oui.

sauf qu’aujourd’hui il n’y a pas une seule application correctement développée à ce niveau à cause des framework qui eux même ont des failles parfois importantes.
depuis 1991 que je regarde des sites web, moins de 1% sont ne serait ce que conforme aux normes HTTP (via les DTD des documents). Donc autant s’assurer avec un reverse proxy; c’est d’ailleurs à cause de ça qu’ils existe aussi (mais pas seulement).

en plus, certains modules (apache ou nginx ou autres), utilisés dans les applications, sont eux même avec des failles qui ne peuvent être corrigées par le code lui même.

Ils ne le sont pas forcement. Mais certains modules sont eux même avec des trous, le développement de l’application aura des trous à 99,99% de chance aujourd’hui. et enfin, par essence, le service en lui-même va mettre en avant des fonctionnements qu’aujourd’hui on peut contourner, devoyer, etc…

Tu n’as aucune chance d’avoir le même niveau de sécurité sans reverse proxy qu’avec.

Sauf que ça ne l’est pas des équipe de développement web :smiley: et que le sysadmin n’est pas un développeur :slight_smile: et qu’aucun des deux n’est en général un expert sécurité (quand par miracle ils en ont une formation :wink: )

#23

Ça tombe bien Apache est multi-processus et si besoin multi-thread. On peut donc parfaitement avoir un site servi avec un unique service Apache2 en reverse proxy.

L’utilisation d’un mandataire inverse en frontal ne te prémunira pas contre les failles de sécurité des applications web. Tu l’as toi-même reconnu plus haut !

Quels sont ces modules ? Merci de ne pas me sortir des trucs exotiques non fournis par la distribution.

Bine sûr que si. Et dans l’absolu tu as même une meilleure sécurité en éliminant une surcouche inutile.

1 J'aime
#24

Tu avais quel FAI en 1991 ?
Même en labo universitaire (à quelques très rares exceptions près) on avait pas accès au Web en 1991.

#25

Ben non Renater y avait accès depuis quelques années déjà. je n’ai pas dit que j’y avait forcement accès chez moi.

Non désolé, et la pratique actuelle dans toutes les architectures sécurisées dans les entreprises est plutôt dans mon sens. Ce qui vaut mieux vu que c’est, entre autre, mon boulot.
Je peux te citer des exemple:
MAAF, MMA, harmonie Mutuelles pour les mutuelles/assurances
BNP, Crédit Agricole, Société générale pour les banques
renault, Fiat, PSA, Mercedex Benz pour l’automobile
EDF pour l’electricité et le nucleaire
GEFCO pour la logistique
Orange, SFR, Bouygues telecom pour les telecom
KLM, ADP pour le transport aerien
CNES pour l’aerospatial
Alsthom, cegelec, Daher pour l’industrie.
France 3 pour l’audio-visuel
Tikehau pour la finance.

Et ça ce n’est que pour ceux que je connais.

suexec, userdir, webdav par exemple?

Pour un certain nombre de cas si. par exemple, il y a moyen avec ALOHA (basé sur HAproxy et debian) de bloquer un certain nombre d’injection SQL, les attaques de SYN flood aussi.
Mais effectivement pas toutes. Mais mieux vaut avoir le RP qui tombe que le site lui même, mettant ainsi à découvert d’autres élement sensible. Si le RP tombe on ne peut pas aller plus loin (excepté si tout est sur la même machine et que tu as accès à la machine bien sur.

processus racine, pour être plus précis. d’où l’utilité de faire le RP avec un outil le site web avec un autre.

#26

Ben voyons, Renater a été créé en 1993. Il va falloir un moment arrêter de raconter n’importe quoi. Cela va finir pas se voir.
Et je parlais du Web, pas de l’Internet. Si tu confonds les deux c’est grave.

#27

Les premières pages web ont été mise en service en 1991/1992 il me semble, avant il y avait le wais et le gopher.

Oui c’est la création du GIE, ca ne veut pas dire qu’il n’y avait aucun backbone juste avant.
Pour moi ca remonte assez loin, 'autant plus que des accès j’en utilisé près d’une dizaine différents.
A deux ans près? le Web c’est internet, si tu as accès à Internet tu as accès au web à partir du moment où des serveurs répondent. Tu devrais savoir ça toi qui a la science infuse.
Et si tu parle de 1993 voir 94, à cette époque j’avais accès à Internet via RTC chez moi, pas souvent car cher. C’est d’ailleurs pour ça qu’à cette époque j’ai essayé de créer une fourniture d’accès en boucle locale pour réduire les couts d’accès de la ville où j’habitais. Fourniture d’accès qui a été créé à l’époque au final par un pote à moi. sa société existe toujours par ailleurs.
Et je ne parle même pas des passerelles BBS/Internet fréquente à cette période et avant.

#28

C’est pas un concours de Ki Ka La Plus Grosse :wink:

Et j’entends bien que pour le meileur des mondes où l’utilisation d’un proxy inverse est nécessaire il est bien de pouvoir séparer les services et redonder les rôles etc …
Mais de la à poursuivre dans le deni … il est largement possible de faire propre avec un Serveur web, il n’est pas obligatoire de séparer les applicatifs avec Apache et/ou Nginx et encore moins obligatoire de séparer les applicatifs sur des serveurs différents.

Toutes les boîtes que tu cite ne sont pas sur un unique serveur et possèdent une galaxie de serveur hébergeant une multitude de rôles.

ON n’est très loin du besoin qui a été exposé précédement.

#29

Propre ne veut pas dire sécurisé, surtout en utilisant des frameworks comme node.js par exemple. Quelque soit la propreté du code, dans le cas d’utilisation de SSL, le/les certificat(s) vont être manipulés par diverses parties du code, ou des modules, avec le RP, les applications ne manipulent plus les certificats.
Et un point que j’avais oublié, un RP permet d’éviter le scan direct de l’application, et les fingerprintings propres à l’application.
Le service RP doit être séparé du service web. S’ils ont le même processus racine, la séparation qui est de base le principe du reverse proxy n’existe alors plus. Autant dans ce cas là ne pas en mettre effectivement.

#30

Je te renverrai à la même réponse que Bruno, node.js, ou typo3, Symphony etc … tant qu’il y a des failles il y a des failles.

:thinking: JE cherche, mais là je vois plus quoi dire …

Le principe de base … gérer le code statique est aussi une belle idée à faire avec du reverse proxy … la séparation n’est qu’une de ces fonctions, pas LA fonction d’un proxy inverse.

C’est sans doute pourquoi tu ne comprends pas ce que je t’explique et pourquoi je ne peux prendre pour argent comptant tes certitudes.