Un proxy inverse devant le serveur Web améliorera-t-il la sécurité?

Un professionnel de la sécurité tiers recommande que nous exécutions un proxy inverse devant le serveur Web (tous hébergés dans la zone démilitarisée) comme mesure de sécurité optimale.

Je sais que c'est une architecture typique recommandée car elle offre un autre niveau de sécurité devant une application Web pour empêcher les pirates.

Cependant, comme un proxy inverse fait la navette allègrement HTTP entre l'utilisateur et le serveur Web interne, il ne fournira aucune mesure de prévention du piratage sur le serveur Web lui-même. En d'autres termes, si votre application Web présente une faille de sécurité, le proxy ne fournira aucune sécurité significative.

Et étant donné que le risque d'une attaque sur une application Web est beaucoup plus élevé que celui d'une attaque sur le proxy, y a-t-il vraiment beaucoup à gagner en ajoutant une case supplémentaire au milieu? Nous n'utiliserions aucune des capacités de mise en cache d'un proxy inverse - juste un outil stupide pour faire la navette entre les paquets.

Y a-t-il autre chose qui me manque ici? L'inspection des paquets HTTP par proxy inverse est-elle si bonne qu'elle peut détecter des attaques significatives sans goulots d'étranglement majeurs, ou est-ce juste un autre exemple de Security Theater?

Le proxy inverse est MS ISA fwiw.

Apache a mod_security, qui détectera les attaques de sécurité courantes. Il existe également mod_cband, qui peut restreindre la bande passante utilisée. Je ne serais pas surpris si ISA avait quelque chose de similaire. Sans quelque chose qui vérifie réellement le trafic HTTP pendant qu'il passe par le proxy, tout cela est un peu inutile du point de vue de la sécurité.

Ce qu'un proxy inverse vous donnera, c'est l'équilibrage de charge, le basculement, la mise en cache, le déchargement SSL et le filtrage, laissant vos serveurs Web faire ce qu'ils sont bons: servir du HTML.

ISA Server peut rechercher et empêcher divers exploits HTTP et les empêcher d'accéder au serveur Web. Bien que la plupart des serveurs HTTP modernes ne soient plus exploitables par cela, cela présente l'avantage supplémentaire de ne pas envoyer ce trafic au serveur Web.

De plus, ISA peut faciliter les tâches telles que l'ajout de l'accélération SSL et la pré-autorisation des utilisateurs à diverses URL. Il peut même agir comme un équilibreur de charge pour vous afin que vous puissiez facilement ajouter plus de serveurs Web sans utiliser un équilibreur de charge matériel distinct.

Assurez-vous de prendre les avantages que cette personne donne sur ISA et de les comparer aux coûts supplémentaires qu'il en coûtera pour gérer et exécuter ISA par rapport aux avantages.

Un proxy inverse devant le serveur Web améliorera-t-il la sécurité?

Un proxy inverse vous donne quelques éléments qui peuvent rendre votre serveur plus sûr.

• Un endroit pour surveiller et enregistrer ce qui se passe indépendamment du serveur Web
• Un endroit pour filtrer ou pare-feu séparé de votre serveur Web si vous savez qu'une partie de votre système est vulnérable. Selon le proxy, vous pouvez filtrer au niveau de l'application.
• Un autre endroit pour implémenter les ACL et les règles si vous ne pouvez pas être assez expressif pour une raison quelconque sur votre serveur Web.
• Une pile réseau distincte qui ne sera pas vulnérable de la même manière que votre serveur Web. Cela est particulièrement vrai si votre proxy provient d'un autre fournisseur.
  • Utiliser la configuration Apache comme proxy devant le serveur Apache n'est probablement pas aussi utile que quelque chose comme Squid devant Apache.

Un proxy inverse sans filtrage ne vous protège pas automatiquement contre tout, mais si le système que vous devez protéger est de grande valeur, l'ajout d'un proxy inverse peut valoir les coûts de support et de performance.

Cela pourrait protéger votre serveur d'applications contre les attaques basées sur de mauvaises requêtes HTTP ... Surtout s'il est possible sur le proxy inverse (et non sur le serveur d'applications) de configurer exactement à quoi ressemble une bonne requête et de ne pas autoriser les mauvaises requêtes. Si vous devez lui dire à quoi ressemblent les mauvaises demandes, cela sera presque certainement inutile. En d'autres termes, il peut protéger contre les attaques de dépassement de tampon, mais pas contre l'injection SQL.

Surtout, cela ressemble à un théâtre de sécurité. Vous avez embauché un consultant en sécurité et il doit vous dire quelque chose à faire pour améliorer votre sécurité. Il est peu probable qu'un attaquant pénètre dans le proxy inverse et s'il le contourne simplement, il peut toujours vous en vouloir; c'est donc une recommandation sûre.

Fondamentalement, les procurations inverses cacheront votre infrastructure au monde. Il s'agit donc principalement d'une sécurité par obscurité, à moins que votre serveur Web ne soit vraiment ingérable et non sécurisé.

Il peut également protéger vos serveurs Web contre une sorte de DOS (déni de service distribué), surtout si votre site Web est "lourd", agissant alors comme une couche de mise en cache.

Il a également quelques pièges avec lui: il cachera à votre application la véritable IP du client. Cela vous fera consommer plus d'énergie du serveur et ajoutera une couche d'éléments qui peuvent se casser. N'oubliez pas que votre proxy inverse devra gérer plus de connexions (généralement deux fois plus: connexions aux clients et connexions à votre serveur Web).

À la fin de la journée, un proxy inverse ne vous épargnera pas d'avoir un site Web sécurisé de toute façon.

Je pense que Zoredache a donné une très bonne réponse quant aux avantages qu'un proxy inverse peut fournir. J'ai utilisé Pound qui est un proxy inverse, un équilibreur de charge et un frontend HTTPS.

http://www.apsis.ch/pound/

Un avantage dont je ne pense pas que quelqu'un d'autre ait parlé est le fait que vous n'avez pas à ouvrir d'IP / ports externes via votre pare-feu externe. Un bon système de proxy inverse initiera la communication de l'intérieur de votre réseau vers le serveur dans la DMZ protégeant les réseaux contre les attaques directes. Ceci, cependant et comme d'autres l'ont dit, ne vous protégera pas contre une application mal écrite.