Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
Bien à vous :)
Km
En différenciant bien le méta-serveur du service. La machine qui fait http est un frontal, elle encaisse, elle est redondée et quasi-stateless. La machine sensible, qui traite les données, est derrière et cachée du monde.
Ce n'est qu'un début, mais ça change déjà beaucoup la donne. Ensuite, de pf à tarpit en passant par du caching et du waf, chacun y va de sa technique pour renforcer le frontal et lui faire absorber la merde ; la base reste bien la même.
<troll id="1">Sinon, tu peux embaucher un fournisseur de CDN.</troll> <troll id="2">Sinon, tu peux déporter ton appli sur le cloud.</troll>
kaiyou.
On Wed, 2012-04-04 at 14:40 +0200, cam.lafit@azerttyu.net wrote:
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
Bien à vous :)
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Cela me semble assez représentatif. Souvent les aspects suivants s'ajoutent aux grands principes cités par Pierre
- terminaison SSL (et quelque fois réencryptage pour le backend) - réécritures protocolaires et/ou RBAC/ACL (moteur à la varnish ou wombat par exemple) - authentification client (SSO en coupure vs appli ...) - caching - logging & traçabilité - politique de failover et reprise des session - éventuels traffic shapping/rate limiting/SLM - éventuelles vérifications protocolaires des RFC
HTH
Le 4 avril 2012 14:48, Pierre Jaury pierre@jaury.eu a écrit :
En différenciant bien le méta-serveur du service. La machine qui fait http est un frontal, elle encaisse, elle est redondée et quasi-stateless. La machine sensible, qui traite les données, est derrière et cachée du monde.
Ce n'est qu'un début, mais ça change déjà beaucoup la donne. Ensuite, de pf à tarpit en passant par du caching et du waf, chacun y va de sa technique pour renforcer le frontal et lui faire absorber la merde ; la base reste bien la même.
<troll id="1">Sinon, tu peux embaucher un fournisseur de CDN.</troll> <troll id="2">Sinon, tu peux déporter ton appli sur le cloud.</troll>
kaiyou.
On Wed, 2012-04-04 at 14:40 +0200, cam.lafit@azerttyu.net wrote:
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
Bien à vous :)
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On 04/04/12 14:40, cam.lafit@azerttyu.net wrote:
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
gopher :D
http://www.igvita.com/2012/01/18/building-a-modern-web-stack-for-the-realtim...
@+
G.
J'utilise une appliance rweb.
Le 4 avril 2012 14:40, cam.lafit@azerttyu.net cam.lafit@azerttyu.net a écrit :
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
Bien à vous :)
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 04/04/2012 14:40, cam.lafit@azerttyu.net a écrit :
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
J'ai mis une appliance firewall, peu importe la marque, que j'arrose régulièrement de poudre verte. La dose recommandée est de 20g/mois, je pousse à 25 comme ça mes CMS sont patchés automatiquement aussi.
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
Bonne journée,
... ça dépend de ce qu'on entend par "protéger". Protéger quoi (la machine ou le service/l'applicatif qui tourne dessus), protéger contre quoi (intrusion, déni de service, attaque applicative, ...) ?
Une bonne solution l'est dans le cadre d'un contexte bien précis...
Un firewall peut être la réponse dans certains cas, mais ne protège pas contre toutes les attaques (quand on remonte bien dans l'applicatif), voire pénaliser dans d'autres cas (j'ai des souvenirs où, sur un DDOS, le service protégé par un firewall avait sauté par saturation du FW, alors que le service d'à côté, qui se contentait d'un load-balancer, en niveau 4, continuait à tourner comme si de rien n'était - le firewall était pourtant une appliance haut de gamme d'une marque plus que connue).
Un load-balancer peut répondre à certaines problématiques, un firewall applicatif (appliance ou module type mod_security) répond à d'autres, l'extension suhosin (dans le cas de PHP) gère certains problèmes, et pour encore d'autres (la plupart ?) la seule solution consiste à virer le développeur.
Dans mon contexte à moi, je cible un risque plutôt applicatif, et on développe en interne, donc : framework web incluant une couche de sécurité sérieuse (dont une protection contre CSRF) + suhosin (on fait du PHP) + un reverse proxy + que des développeurs fiables (à priori). Pas de firewall, mais un load-balancer décent si les moyens le permettent.
Si c'est pour protéger une boite noire contre toutes les attaques possibles et imaginables, +1 pour la poudre verte (perso, je passerai à 30g, voir 50g les nuits de pleine lune). Et ne pas oublier de déréférencer totalement le site web de Google, de plus en plus de vers se basent sur Google pour déterminer leurs cibles.
JFB
Le 4 avr. 2012 à 16:49, Julien Escario a écrit :
Le 04/04/2012 14:40, cam.lafit@azerttyu.net a écrit :
Bonjour à tous
Je profite du grand calme sur cette liste pour poser cette bête question : Que faîtes vous pour protéger au mieux vos machines fournissant du http ?
J'ai mis une appliance firewall, peu importe la marque, que j'arrose régulièrement de poudre verte. La dose recommandée est de 20g/mois, je pousse à 25 comme ça mes CMS sont patchés automatiquement aussi.
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
Bonne journée,
Julien Escario escario@azylog.net Tél. : +33.972115242
Azylog 5 Rte de Champagnole F-39300 Les Nans
Liste de diffusion du FRsAG http://www.frsag.org/
Le 4 avr. 2012 à 16:49, Julien Escario a écrit :
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
"Ça dépend", ça dépasse (toute ma considération à ceux qui retrouveront la référence).
J'ai écrit, il y a quelques mois, un document sur le renforcement d'une architecture mutualisée LAMP sous Debian.
Bien que j'ai manqué de temps à la fin, ce qui m'a fait un peu bacler la fin du document, et trancher un peu trop net mon avis (a.k.a. j'ai trollé à fond ; ces avis n'engagent que moi), je pense qu'il pourra peut être en intéresser certains.
https://x-cli.eu/secfiles/lamp.pdf
Cheers, Florian Maury
Je ne veux pas paraître rabbat-joie, mais dans la flore moderne du Web qui clignote et qui mange un peu chaque jour des parts du traffic global, il n'y a guère plus de gros LAMP en production (tout court ?) qui serve du HTTP. LAMP (encore que, Apache/nginx avec un PHP fcgi, cluster de base de données déporté sera bientôt plus courant) est là pour servir une application, plus guère de HTTP (bien sûr qu'il sert du HTTP, mais c'est marginal et pas à destination du client final). Par serveur HTTP dans la question originale, j'imagine qu'on entend frontal, et qu'on laisse donc de côté la partie applicative ayant vocation à être sécurisée ailleurs et différemment (sur d'autres machines).
Sécuriser du HTTP, c'est donc essentiellement avaler de la requête dans un premier temps. Outre le hardening classique et très généraliste (filtrage réseau, DOS mitigation, services d'administration sur réseau privé, etc.), on ajoutera une fois que le système tient la charge un firewall couche 7 filtrant basiquement les énumérations et autres burinages pouvant effondrer le système (en veillant à ce que le waf lui même ne s'effondre pas). À vouloir détailler plus, on se retrouve à cheval côté applicatif, auquel cas je rejoins un message plus haut : ça dépend ; mais je crois que c'est hors propos.
On Wed, 2012-04-04 at 19:54 +0200, Florian Maury wrote:
Le 4 avr. 2012 à 16:49, Julien Escario a écrit :
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
"Ça dépend", ça dépasse (toute ma considération à ceux qui retrouveront la référence).
J'ai écrit, il y a quelques mois, un document sur le renforcement d'une architecture mutualisée LAMP sous Debian.
Bien que j'ai manqué de temps à la fin, ce qui m'a fait un peu bacler la fin du document, et trancher un peu trop net mon avis (a.k.a. j'ai trollé à fond ; ces avis n'engagent que moi), je pense qu'il pourra peut être en intéresser certains.
https://x-cli.eu/secfiles/lamp.pdf
Cheers, Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On a aussi oublié le paramètre économique : ça dépend de ce que tu as à perdre à une attaque et à dépenser pour t'en protéger...
Avec un peu de trafic, tous ces boitiers et autres, ça coûte !
Le 4 avr. 2012 à 20:56, Pierre Jaury a écrit :
Je ne veux pas paraître rabbat-joie, mais dans la flore moderne du Web qui clignote et qui mange un peu chaque jour des parts du traffic global, il n'y a guère plus de gros LAMP en production (tout court ?) qui serve du HTTP. LAMP (encore que, Apache/nginx avec un PHP fcgi, cluster de base de données déporté sera bientôt plus courant) est là pour servir une application, plus guère de HTTP (bien sûr qu'il sert du HTTP, mais c'est marginal et pas à destination du client final). Par serveur HTTP dans la question originale, j'imagine qu'on entend frontal, et qu'on laisse donc de côté la partie applicative ayant vocation à être sécurisée ailleurs et différemment (sur d'autres machines).
Sécuriser du HTTP, c'est donc essentiellement avaler de la requête dans un premier temps. Outre le hardening classique et très généraliste (filtrage réseau, DOS mitigation, services d'administration sur réseau privé, etc.), on ajoutera une fois que le système tient la charge un firewall couche 7 filtrant basiquement les énumérations et autres burinages pouvant effondrer le système (en veillant à ce que le waf lui même ne s'effondre pas). À vouloir détailler plus, on se retrouve à cheval côté applicatif, auquel cas je rejoins un message plus haut : ça dépend ; mais je crois que c'est hors propos.
On Wed, 2012-04-04 at 19:54 +0200, Florian Maury wrote:
Le 4 avr. 2012 à 16:49, Julien Escario a écrit :
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
"Ça dépend", ça dépasse (toute ma considération à ceux qui retrouveront la référence).
J'ai écrit, il y a quelques mois, un document sur le renforcement d'une architecture mutualisée LAMP sous Debian.
Bien que j'ai manqué de temps à la fin, ce qui m'a fait un peu bacler la fin du document, et trancher un peu trop net mon avis (a.k.a. j'ai trollé à fond ; ces avis n'engagent que moi), je pense qu'il pourra peut être en intéresser certains.
https://x-cli.eu/secfiles/lamp.pdf
Cheers, Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Certes mais si le coût est la priorité il y a des solutions open sources. Je rejoins l'avis global de la liste. Cela dépend vraiment de beaucoup de paramètre car les reverse proxy (par abus de langage) deviennent souvent stratégique avec le temps.
Le 4 avril 2012 21:59, JF Bustarret jf@bustarret.com a écrit :
On a aussi oublié le paramètre économique : ça dépend de ce que tu as à perdre à une attaque et à dépenser pour t'en protéger...
Avec un peu de trafic, tous ces boitiers et autres, ça coûte !
Le 4 avr. 2012 à 20:56, Pierre Jaury a écrit :
Je ne veux pas paraître rabbat-joie, mais dans la flore moderne du Web qui clignote et qui mange un peu chaque jour des parts du traffic global, il n'y a guère plus de gros LAMP en production (tout court ?) qui serve du HTTP. LAMP (encore que, Apache/nginx avec un PHP fcgi, cluster de base de données déporté sera bientôt plus courant) est là pour servir une application, plus guère de HTTP (bien sûr qu'il sert du HTTP, mais c'est marginal et pas à destination du client final). Par serveur HTTP dans la question originale, j'imagine qu'on entend frontal, et qu'on laisse donc de côté la partie applicative ayant vocation à être sécurisée ailleurs et différemment (sur d'autres machines).
Sécuriser du HTTP, c'est donc essentiellement avaler de la requête dans un premier temps. Outre le hardening classique et très généraliste (filtrage réseau, DOS mitigation, services d'administration sur réseau privé, etc.), on ajoutera une fois que le système tient la charge un firewall couche 7 filtrant basiquement les énumérations et autres burinages pouvant effondrer le système (en veillant à ce que le waf lui même ne s'effondre pas). À vouloir détailler plus, on se retrouve à cheval côté applicatif, auquel cas je rejoins un message plus haut : ça dépend ; mais je crois que c'est hors propos.
On Wed, 2012-04-04 at 19:54 +0200, Florian Maury wrote:
Le 4 avr. 2012 à 16:49, Julien Escario a écrit :
Plus sérieusement, que répondre à ça à part 'ça dépend' ?
"Ça dépend", ça dépasse (toute ma considération à ceux qui retrouveront
la référence).
J'ai écrit, il y a quelques mois, un document sur le renforcement d'une
architecture mutualisée LAMP sous Debian.
Bien que j'ai manqué de temps à la fin, ce qui m'a fait un peu bacler
la fin du document, et trancher un peu trop net mon avis (a.k.a. j'ai trollé à fond ; ces avis n'engagent que moi), je pense qu'il pourra peut être en intéresser certains.
https://x-cli.eu/secfiles/lamp.pdf
Cheers, Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous
Pour commencer je suis super ravi de toutes ces réponses. Je n'aurais pas cru que vous étiez tous à tant vous ennuyer :p
En effet je m'attendais bien à une réponse type : "Ça dépend, comment ça fonctionne chez toi et on verra après". La question était volontairement minimaliste pour voir des tendances et les interprétations de chacun.
Je pense que de base on a tous des recettes équivalentes, des outils communs. Avec ma question j'espérais voir un peu de ceci. Je crois que j'ai été servi :)
Merci à vous
Km
Le 4 avr. 2012 à 22:02, J. Mardas a écrit :
Certes mais si le coût est la priorité il y a des solutions open sources.
Même avec l'open-source, on en revient à des notions de coûts : on remplace un coût matériel/logiciel par un coût humain, qui peut ne pas être neutre. Maintenant, l'humain peut être vu (par une personne intelligente) comme un investissement et pas seulement comme une ligne dans la partie dépenses d'un tableau Excel.
JFB
C'est vrai mais là pour le coup ça dépend vraiment de beaucoup plus de choses ! Il y a également des coûts récurrents et/ou caché dans le propriétaire : par exemple pour le support, pour les opérations de MCO, les licenses multiples et par options, les prestations de services, les version spécifiques, la dépendance du fournisseurs ... De toutes les façons on fait souvent le même travail quand on implémente une solution propriétaire (formation, intégration, test, validation, ...) Mais c'est un grand débat et ce n'est pas le sujet (loin de moin l'idée de lancer ce vieux troll !)
Pour la partie reverse, je pensais à des truc simple et maîtrisé par la majorité des sysadmins (mod_security core rules) ou plus élaborée (varnish+nginx & co) mais je rejoins également un avis cité plus haut, de toutes les façons, il faut se faire une raison Il est impossible de bloquer 100% des attaques applicatives. Il est donc nécessaire de bien qualifier les processus en même temps que les choix technologiques (gestion des mise à jour de blacklist, faux positifs, sirt et réaction en cas d'attaque, proactif vs réactif ...). Surtout si le nombre de serveurs et de sites est grand
Le 5 avril 2012 10:03, JF Bustarret jf@bustarret.com a écrit :
Le 4 avr. 2012 à 22:02, J. Mardas a écrit :
Certes mais si le coût est la priorité il y a des solutions open sources.
Même avec l'open-source, on en revient à des notions de coûts : on remplace un coût matériel/logiciel par un coût humain, qui peut ne pas être neutre. Maintenant, l'humain peut être vu (par une personne intelligente) comme un investissement et pas seulement comme une ligne dans la partie dépenses d'un tableau Excel.
JFB
Liste de diffusion du FRsAG http://www.frsag.org/
Si on devait ajouter quelque chose à toute cette liste, c'est de mettre à jour très régulièrement les frontaux.
Le 05/04/2012 10:38, J. Mardas a écrit :
C'est vrai mais là pour le coup ça dépend vraiment de beaucoup plus de choses ! Il y a également des coûts récurrents et/ou caché dans le propriétaire : par exemple pour le support, pour les opérations de MCO, les licenses multiples et par options, les prestations de services, les version spécifiques, la dépendance du fournisseurs ... De toutes les façons on fait souvent le même travail quand on implémente une solution propriétaire (formation, intégration, test, validation, ...) Mais c'est un grand débat et ce n'est pas le sujet (loin de moin l'idée de lancer ce vieux troll !)
Pour la partie reverse, je pensais à des truc simple et maîtrisé par la majorité des sysadmins (mod_security core rules) ou plus élaborée (varnish+nginx & co) mais je rejoins également un avis cité plus haut, de toutes les façons, il faut se faire une raison Il est impossible de bloquer 100% des attaques applicatives. Il est donc nécessaire de bien qualifier les processus en même temps que les choix technologiques (gestion des mise à jour de blacklist, faux positifs, sirt et réaction en cas d'attaque, proactif vs réactif ...). Surtout si le nombre de serveurs et de sites est grand
Le 5 avril 2012 10:03, JF Bustarret <jf@bustarret.com mailto:jf@bustarret.com> a écrit :
Le 4 avr. 2012 à 22:02, J. Mardas a écrit : > Certes mais si le coût est la priorité il y a des solutions open sources. Même avec l'open-source, on en revient à des notions de coûts : on remplace un coût matériel/logiciel par un coût humain, qui peut ne pas être neutre. Maintenant, l'humain peut être vu (par une personne intelligente) comme un investissement et pas seulement comme une ligne dans la partie dépenses d'un tableau Excel. JFB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
D'accord pour le serveur en lui même mais pas forcément pour les blacklist (et autres règles du même type whitelist, greylist, scoringlist, ...). Je dirai qu'il est préférable d'auditer une blackliste pour éviter au maximum les faux positifs avant de l'appliquer en prod. Quasiment tous les reverse que je connais peuvent logger un pattern plutôt que d'appliquer un accept ou deny.
Le 5 avril 2012 11:11, Gregory Duchatelet greg-frsag@duchatelet.net a écrit :
Si on devait ajouter quelque chose à toute cette liste, c'est de mettre à jour très régulièrement les frontaux.
Le 05/04/2012 10:38, J. Mardas a écrit :
C'est vrai mais là pour le coup ça dépend vraiment de beaucoup plus de choses ! Il y a également des coûts récurrents et/ou caché dans le propriétaire : par exemple pour le support, pour les opérations de MCO, les licenses multiples et par options, les prestations de services, les version spécifiques, la dépendance du fournisseurs ... De toutes les façons on fait souvent le même travail quand on implémente une solution propriétaire (formation, intégration, test, validation, ...) Mais c'est un grand débat et ce n'est pas le sujet (loin de moin l'idée de lancer ce vieux troll !)
Pour la partie reverse, je pensais à des truc simple et maîtrisé par la majorité des sysadmins (mod_security core rules) ou plus élaborée (varnish+nginx & co) mais je rejoins également un avis cité plus haut, de toutes les façons, il faut se faire une raison Il est impossible de bloquer 100% des attaques applicatives. Il est donc nécessaire de bien qualifier les processus en même temps que les choix technologiques (gestion des mise à jour de blacklist, faux positifs, sirt et réaction en cas d'attaque, proactif vs réactif ...). Surtout si le nombre de serveurs et de sites est grand
Le 5 avril 2012 10:03, JF Bustarret jf@bustarret.com a écrit :
Le 4 avr. 2012 à 22:02, J. Mardas a écrit :
Certes mais si le coût est la priorité il y a des solutions open
sources.
Même avec l'open-source, on en revient à des notions de coûts : on remplace un coût matériel/logiciel par un coût humain, qui peut ne pas être neutre. Maintenant, l'humain peut être vu (par une personne intelligente) comme un investissement et pas seulement comme une ligne dans la partie dépenses d'un tableau Excel.
JFB
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAGhttp://www.frsag.org/
-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, 5 Apr 2012 10:03:14 +0200, "JF Bustarret" jf@bustarret.com said:
Même avec l'open-source, on en revient à des notions de coûts : on remplace un coût matériel/logiciel par un coût humain, qui peut ne pas
Rappel: les solutions proprietaire n'eliminent nullement le cout humain. Dans le meilleur cas ils le remplacent par le cout de la prestation (cout humain supporte par le prestataire, qui le reccupere en faisant aussi de la marge).
être neutre. Maintenant, l'humain peut être vu (par une personne intelligente) comme un investissement et pas seulement comme une ligne dans la partie dépenses d'un tableau Excel.
Si seulement c'etait la regle....
Bonjour à tous
Bon maintenant que le weekend de pâques arrive, je relance pour nous sauver de l'ennui qui arrive:p
Vu qu'on a abordé un certain nombre de grands principes, essayons un cas pratique :) J'espère que que ce cas est assez classique et que la plupart d'entre nous est passée par là : le SWABDELP Si si vous savez bien le serveur web avec base de données et langage de programmation qui fait aussi le ménage.
Je ne parle pas LAMP car au vu des mails cela ne semble pas représentatif et on a surement plein d'autres déclinaisons de départ.
Dans ce cas la partie http est noyée dans un ensemble d'autres services et l'idée reste toujours de protéger son serveur http. Que faîtes vous ? Éventuellement on peut parler des outils privilégiés par chacun et le plus qu'on y trouve.
Comme il reste plusieurs ponts, on pourra faire la déclinaison bdd, os, .... :)
Km qui entraine pour le moment son foie
Bonjour,
Un bon coup de Reverse-proxy/load-balancer de niveau 7, à savoir HAProxy.
Ca permet de le mettre dans une DMZ, de laisser ses serveurs sur le LAN, de protéger des synflood, des slowloris et autres apache killer. C'est simple à configurer et c'est performant...
En cherchant sur le net, y'a des produits commerciaux qui l'utilisent si on veut du support sur sa brique opensource :)
a+
Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien.
je suis en train de travailler avec Dancer http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer
détails sur : https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Le 06/04/2012 13:09, Baptiste a écrit :
Bonjour,
Un bon coup de Reverse-proxy/load-balancer de niveau 7, à savoir HAProxy.
Ca permet de le mettre dans une DMZ, de laisser ses serveurs sur le LAN, de protéger des synflood, des slowloris et autres apache killer. C'est simple à configurer et c'est performant...
En cherchant sur le net, y'a des produits commerciaux qui l'utilisent si on veut du support sur sa brique opensource :)
a+ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 06/04/2012 15:25, Hugues wrote:
Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien.
je suis en train de travailler avec Dancer http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer
détails sur : https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Bonsoir Hugues,
Non, et bien que (ex-) fan de perl (et sans connaitre tes besoins), je te conseille vraiment HAProxy. C'est la rolls pour du LB http, tu peux faire quasiment tout ce que tu veux : router vers les backends en fonction d'en-têtes HTTP (parfait pour les virtualhosts), en fonction du chemin (sympa pour renvoyer les assets statiques depuis un serveur specifique), authentification, LB avec des poids, montée en charge progressive des noeuds qui reviennent up, serveurs de backup, arrêt des noeuds depuis l'interface web, etc..., j'en découvre encore tous les jours. C'est vraiment un petit bijou. Par ailleurs, même si nous avons un trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu défaillir (malgré la version tagguée -dev, (oui c'est mal, non pas la claque)).
Si tu as besoin de faire du SSL pour ton appli, un petit nginx par dessus est bien pratique. HAProxy ne gère pas encore "vraiment" (mais c'est en vue pour la 1.5), et peut juste forwarder du TCP dur le port 443. Dans tous ls cas, ça me parait mieux de terminer le SSL sur le LB pour les soulager les backends et pour présenter un certificat valide.
A+
M
Merci pour ces infos
Toujours fan de perl... je cherchais qlq chose qui remplace les MVC en php ( je ne supporte plus de coder en php c'est trop la misère... ) - Dancer a l'air bien a première vue
je chercher un moyen de déporter le LB et le SSL sur un serveur en amont des serveurs applicatifs
Jusqu’à présent j'utilisais Openbsd avec ses fonctions de répartition de charge inclus dans PF
Deux firewall sous Openbsd + CARP ( un équivalent de cisco VRRP ) + PF + relayd et voila j'avais ma haute dispo, et mon LB- mais pas de prise en charge du SSL.
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?
Vu que, même quand il y a du traffic ils dorment..; sinon il faut que je dédie un serveur pour la gestion du SSL
bye Hugues.
Le 06/04/2012 22:44, Michel Blanc a écrit :
On 06/04/2012 15:25, Hugues wrote:
Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien.
je suis en train de travailler avec Dancer http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer
détails sur : https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Bonsoir Hugues,
Non, et bien que (ex-) fan de perl (et sans connaitre tes besoins), je te conseille vraiment HAProxy. C'est la rolls pour du LB http, tu peux faire quasiment tout ce que tu veux : router vers les backends en fonction d'en-têtes HTTP (parfait pour les virtualhosts), en fonction du chemin (sympa pour renvoyer les assets statiques depuis un serveur specifique), authentification, LB avec des poids, montée en charge progressive des noeuds qui reviennent up, serveurs de backup, arrêt des noeuds depuis l'interface web, etc..., j'en découvre encore tous les jours. C'est vraiment un petit bijou. Par ailleurs, même si nous avons un trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu défaillir (malgré la version tagguée -dev, (oui c'est mal, non pas la claque)).
Si tu as besoin de faire du SSL pour ton appli, un petit nginx par dessus est bien pratique. HAProxy ne gère pas encore "vraiment" (mais c'est en vue pour la 1.5), et peut juste forwarder du TCP dur le port 443. Dans tous ls cas, ça me parait mieux de terminer le SSL sur le LB pour les soulager les backends et pour présenter un certificat valide.
A+
M
Le 6 avril 2012 23:07, Hugues huguesmax@gmail.com a écrit :
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?
A mon sens mélanger FW et RP sur une même machine physique est non seulement un risque de sécurité mais surtout une erreur d'architecture (au sens urbanisation) et d'exploitabilité. J'ai vu de nombreux FW commerciaux (au hasard checkpoint et son module web filtering) utilisant ses fonctions en prod devenir rapidement de véritables usines à gaz inexploitables avec le temps et la multiplication des fonctions. Ceci est même risqué, car très souvent dans ce type d'appliance commercial, il n'y a pas d'HTTP en asic et c'est le CPU qui traite les règles applicatives en soft. Conséquence, les perfs s'écroulent avec la multiplication de règles applicatives.
De tels équipements, ainsi utilisés, finissent par être des spof qui se trouvent sur beaucoup de chemins critiques et deviennent avec le temps un gouffre financier. Segmenter son architecture par protocole et niveau en gardant une architecture simple et homogène me semble dans beaucoup de cas comme étant une bonne pratique pour construire des architectures durables, évolutives, maîtrisées et sécurisées.
Un FW est un équipement majoritairement réseau (1-4). Un LB qui supporte du SSL, que je considère comme un RP car il implémente nécessairement des fonctions applicatives (persistance de session, cookie, ...) est un équipement de niveau applicatif et réseau (3-7). FW et RP sur le même serveur risque de faire double emploi sur la partie réseau, ce qui peut être le cas lors d'un incident, d'un bug ou dans l'urgence. Surtout au vu de la complexité des applications et des SI et de la difficulté du debug des applications distribuées.
Cela ne veut pas dire que c'est à proscrire car encore une fois ça dépend des cas. On peut par exemple se demander si votre serveur n'est pas sur-dimensionné ou s'il n'est pas plus intéressant de le virtualiser au vu des ressources restantes et de l'overhead que cela implique.
Le 06/04/2012 22:44, Michel Blanc a écrit :
On 06/04/2012 15:25, Hugues wrote:
Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien.
je suis en train de travailler avec Dancer http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer
détails sur : https://metacpan.org/module/**Dancer::Deployment#Using-** perlbal https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Bonsoir Hugues,
Non, et bien que (ex-) fan de perl (et sans connaitre tes besoins), je te conseille vraiment HAProxy. C'est la rolls pour du LB http, tu peux faire quasiment tout ce que tu veux : router vers les backends en fonction d'en-têtes HTTP (parfait pour les virtualhosts), en fonction du chemin (sympa pour renvoyer les assets statiques depuis un serveur specifique), authentification, LB avec des poids, montée en charge progressive des noeuds qui reviennent up, serveurs de backup, arrêt des noeuds depuis l'interface web, etc..., j'en découvre encore tous les jours. C'est vraiment un petit bijou. Par ailleurs, même si nous avons un trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu défaillir (malgré la version tagguée -dev, (oui c'est mal, non pas la claque)).
Si tu as besoin de faire du SSL pour ton appli, un petit nginx par dessus est bien pratique. HAProxy ne gère pas encore "vraiment" (mais c'est en vue pour la 1.5), et peut juste forwarder du TCP dur le port 443. Dans tous ls cas, ça me parait mieux de terminer le SSL sur le LB pour les soulager les backends et pour présenter un certificat valide.
A+
M
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le plus petit serveur que je peux acheter aujourd'hui c'est un type dell 210 avec ça et un Openbsd dessus et un minimum de tuning je route 3 à 400 mb/sec
Aujourd'hui si je consomme 100 Mb/sec c'est le bout du monde si je suis ta pensée et que je reste dans l'idée du LB et donc Fail over j'ai besoin 2FW ===> 2 SSL ==> mes serveurs applicatifs ça va me faire 4 serveurs qui dorment au lieu de 2... En théorie je suis d'accord avec toi mais ça fait raller quand même. d'autre part faire des VM de BSD pour des serveurs critiques, je ne suis pas très chaud. Merci pour ces infos et bonne nuit il est 18:30 chez moi et je vais me baigner ( je suis au antilles ) bye Hugues
Le 07/04/2012 00:17, J. Mardas a écrit :
Le 6 avril 2012 23:07, Hugues <huguesmax@gmail.com mailto:huguesmax@gmail.com> a écrit :
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?A mon sens mélanger FW et RP sur une même machine physique est non seulement un risque de sécurité mais surtout une erreur d'architecture (au sens urbanisation) et d'exploitabilité. J'ai vu de nombreux FW commerciaux (au hasard checkpoint et son module web filtering) utilisant ses fonctions en prod devenir rapidement de véritables usines à gaz inexploitables avec le temps et la multiplication des fonctions. Ceci est même risqué, car très souvent dans ce type d'appliance commercial, il n'y a pas d'HTTP en asic et c'est le CPU qui traite les règles applicatives en soft. Conséquence, les perfs s'écroulent avec la multiplication de règles applicatives.
De tels équipements, ainsi utilisés, finissent par être des spof qui se trouvent sur beaucoup de chemins critiques et deviennent avec le temps un gouffre financier. Segmenter son architecture par protocole et niveau en gardant une architecture simple et homogène me semble dans beaucoup de cas comme étant une bonne pratique pour construire des architectures durables, évolutives, maîtrisées et sécurisées.
Un FW est un équipement majoritairement réseau (1-4). Un LB qui supporte du SSL, que je considère comme un RP car il implémente nécessairement des fonctions applicatives (persistance de session, cookie, ...) est un équipement de niveau applicatif et réseau (3-7). FW et RP sur le même serveur risque de faire double emploi sur la partie réseau, ce qui peut être le cas lors d'un incident, d'un bug ou dans l'urgence. Surtout au vu de la complexité des applications et des SI et de la difficulté du debug des applications distribuées.
Cela ne veut pas dire que c'est à proscrire car encore une fois ça dépend des cas. On peut par exemple se demander si votre serveur n'est pas sur-dimensionné ou s'il n'est pas plus intéressant de le virtualiser au vu des ressources restantes et de l'overhead que cela implique.
Le 06/04/2012 22:44, Michel Blanc a écrit : On 06/04/2012 15:25, Hugues wrote: Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien. je suis en train de travailler avec Dancer http://perldancer.org/ dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer détails sur : https://metacpan.org/module/Dancer::Deployment#Using-perlbal est ce que quelqu'un a déjà testé ça en prod ? Bonsoir Hugues, Non, et bien que (ex-) fan de perl (et sans connaitre tes besoins), je te conseille vraiment HAProxy. C'est la rolls pour du LB http, tu peux faire quasiment tout ce que tu veux : router vers les backends en fonction d'en-têtes HTTP (parfait pour les virtualhosts), en fonction du chemin (sympa pour renvoyer les assets statiques depuis un serveur specifique), authentification, LB avec des poids, montée en charge progressive des noeuds qui reviennent up, serveurs de backup, arrêt des noeuds depuis l'interface web, etc..., j'en découvre encore tous les jours. C'est vraiment un petit bijou. Par ailleurs, même si nous avons un trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu défaillir (malgré la version tagguée -dev, (oui c'est mal, non pas la claque)). Si tu as besoin de faire du SSL pour ton appli, un petit nginx par dessus est bien pratique. HAProxy ne gère pas encore "vraiment" (mais c'est en vue pour la 1.5), et peut juste forwarder du TCP dur le port 443. Dans tous ls cas, ça me parait mieux de terminer le SSL sur le LB pour les soulager les backends et pour présenter un certificat valide. A+ M _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est un principe c'est sûr mais ça dépend de ton archi et de tes contraintes comme on le dit depuis le début. Je ne sais pas ce que protège ton serveur mais j'ai vu du très critique tourner sur vsphere4 sans problème (y compris de la sécu). Dans ton cas ça ferai passer le nombre de serveur de 4 à 2 et vu la sécurité du OpenBSD (crypto native quasiment partout) je ne sais pas dire ce qu'on peut tirer d'un hack de la couche virtuelle dans ce cas (qui reste une attaque assez complexe) hormis un DoS qui de toutes les façons est très difficile a éviter dans tous les cas. Bonne baignade
Le 7 avril 2012 00:36, Hugues huguesmax@gmail.com a écrit :
Le plus petit serveur que je peux acheter aujourd'hui c'est un type dell 210 avec ça et un Openbsd dessus et un minimum de tuning je route 3 à 400 mb/sec
Aujourd'hui si je consomme 100 Mb/sec c'est le bout du monde si je suis ta pensée et que je reste dans l'idée du LB et donc Fail over j'ai besoin 2FW ===> 2 SSL ==> mes serveurs applicatifs ça va me faire 4 serveurs qui dorment au lieu de 2... En théorie je suis d'accord avec toi mais ça fait raller quand même. d'autre part faire des VM de BSD pour des serveurs critiques, je ne suis pas très chaud. Merci pour ces infos et bonne nuit il est 18:30 chez moi et je vais me baigner ( je suis au antilles ) bye Hugues
Le 07/04/2012 00:17, J. Mardas a écrit :
Le 6 avril 2012 23:07, Hugues huguesmax@gmail.com a écrit :
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?
A mon sens mélanger FW et RP sur une même machine physique est non seulement un risque de sécurité mais surtout une erreur d'architecture (au sens urbanisation) et d'exploitabilité. J'ai vu de nombreux FW commerciaux (au hasard checkpoint et son module web filtering) utilisant ses fonctions en prod devenir rapidement de véritables usines à gaz inexploitables avec le temps et la multiplication des fonctions. Ceci est même risqué, car très souvent dans ce type d'appliance commercial, il n'y a pas d'HTTP en asic et c'est le CPU qui traite les règles applicatives en soft. Conséquence, les perfs s'écroulent avec la multiplication de règles applicatives.
De tels équipements, ainsi utilisés, finissent par être des spof qui se trouvent sur beaucoup de chemins critiques et deviennent avec le temps un gouffre financier. Segmenter son architecture par protocole et niveau en gardant une architecture simple et homogène me semble dans beaucoup de cas comme étant une bonne pratique pour construire des architectures durables, évolutives, maîtrisées et sécurisées.
Un FW est un équipement majoritairement réseau (1-4). Un LB qui supporte du SSL, que je considère comme un RP car il implémente nécessairement des fonctions applicatives (persistance de session, cookie, ...) est un équipement de niveau applicatif et réseau (3-7). FW et RP sur le même serveur risque de faire double emploi sur la partie réseau, ce qui peut être le cas lors d'un incident, d'un bug ou dans l'urgence. Surtout au vu de la complexité des applications et des SI et de la difficulté du debug des applications distribuées.
Cela ne veut pas dire que c'est à proscrire car encore une fois ça dépend des cas. On peut par exemple se demander si votre serveur n'est pas sur-dimensionné ou s'il n'est pas plus intéressant de le virtualiser au vu des ressources restantes et de l'overhead que cela implique.
Le 06/04/2012 22:44, Michel Blanc a écrit :
On 06/04/2012 15:25, Hugues wrote:
Bonjour j'ai jamais testé HA Proxy mais j'en ai toujours entendu que du bien.
je suis en train de travailler avec Dancer http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec Perlbal comme load balancer
détails sur : https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Bonsoir Hugues,
Non, et bien que (ex-) fan de perl (et sans connaitre tes besoins), je te conseille vraiment HAProxy. C'est la rolls pour du LB http, tu peux faire quasiment tout ce que tu veux : router vers les backends en fonction d'en-têtes HTTP (parfait pour les virtualhosts), en fonction du chemin (sympa pour renvoyer les assets statiques depuis un serveur specifique), authentification, LB avec des poids, montée en charge progressive des noeuds qui reviennent up, serveurs de backup, arrêt des noeuds depuis l'interface web, etc..., j'en découvre encore tous les jours. C'est vraiment un petit bijou. Par ailleurs, même si nous avons un trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu défaillir (malgré la version tagguée -dev, (oui c'est mal, non pas la claque)).
Si tu as besoin de faire du SSL pour ton appli, un petit nginx par dessus est bien pratique. HAProxy ne gère pas encore "vraiment" (mais c'est en vue pour la 1.5), et peut juste forwarder du TCP dur le port 443. Dans tous ls cas, ça me parait mieux de terminer le SSL sur le LB pour les soulager les backends et pour présenter un certificat valide.
A+
M
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On 06/04/2012 23:07, Hugues wrote:
Toujours fan de perl... je cherchais qlq chose qui remplace les MVC en php ( je ne supporte plus de coder en php c'est trop la misère... ) - Dancer a l'air bien a première vue
Bon sinon y'a Ruby hein, ç'est dans l'esprit perl, mais avec des nouvelles versions de temps en temps :) Avec un framework pas trop lourdingue (suivez mon regard) genre Ramaze c'est vraiment le bonheur.
Deux firewall sous Openbsd + CARP ( un équivalent de cisco VRRP ) + PF + relayd et voila j'avais ma haute dispo, et mon LB- mais pas de prise en charge du SSL.
C'est à peu près l'objectif ici : deux haproxy avec ucarp et du DNS RR.
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?
Question charge ? Pas de souci chez nous. haproxy compte pour du beurre, et nginx pas vraiment gourmand non plus. Au final, c'est EEG plat chez nous. Si tu splittes sur deux LB, à mon avis, tu devrais voir venir, mais bon, à ajuster en fonction des caractéristiques serveur et trafic.
Si tu as besoin de confs pour te mettre le pied à l'étrier, fais moi signe.
Dans tous les cas, je te conseille de partir sur une conf du type frontend/backend plutot que listen (en gros, deux méthodes pour définir un service, la "méthode" listen décrivant la partie front+backends en même temps est moins souple à mon goût).
A+
M
mauvaise langue :-) , ya le perl 5.10, 5.12 y a jamais eu autant de nouvelle version depuis.....longtemps je vais tester Ha proxy + nginx et Ruby ( ça fait longtemps que je voulais tester de tous les façons) je te fait un email pour les config. Merci
bye Hugues
Le 07/04/2012 00:26, Michel Blanc a écrit :
On 06/04/2012 23:07, Hugues wrote:
Toujours fan de perl... je cherchais qlq chose qui remplace les MVC en php ( je ne supporte plus de coder en php c'est trop la misère... ) - Dancer a l'air bien a première vue
Bon sinon y'a Ruby hein, ç'est dans l'esprit perl, mais avec des nouvelles versions de temps en temps :) Avec un framework pas trop lourdingue (suivez mon regard) genre Ramaze c'est vraiment le bonheur.
Deux firewall sous Openbsd + CARP ( un équivalent de cisco VRRP ) + PF + relayd et voila j'avais ma haute dispo, et mon LB- mais pas de prise en charge du SSL.
C'est à peu près l'objectif ici : deux haproxy avec ucarp et du DNS RR.
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur les firewall ?
Question charge ? Pas de souci chez nous. haproxy compte pour du beurre, et nginx pas vraiment gourmand non plus. Au final, c'est EEG plat chez nous. Si tu splittes sur deux LB, à mon avis, tu devrais voir venir, mais bon, à ajuster en fonction des caractéristiques serveur et trafic.
Si tu as besoin de confs pour te mettre le pied à l'étrier, fais moi signe.
Dans tous les cas, je te conseille de partir sur une conf du type frontend/backend plutot que listen (en gros, deux méthodes pour définir un service, la "méthode" listen décrivant la partie front+backends en même temps est moins souple à mon goût).
A+
M
-
Baptiste -
cam.lafit＠azerttyu.net -
Florian Maury -
Gregory Duchatelet -
Guillaume -
Hugues -
J. Mardas -
JF Bustarret -
Julien Escario -
Michel Blanc -
Pierre Jaury -
Radu-Adrian Feurdean -
Sébastien Mureau