Je plusoie.
Mea Culpa mais quand je parlais de virtualisation j'entendais par abus de
langage toutes technos basées sur un hyperviseur et/ou implémentant
virtualisation complète ou para-virtualisation (Xen, kvm, vmware,
virtualbox+vagrant, libvirt, ...) mais également les "environnements de
confin
Bonjour,
Le point clairement prioritaire si tu t'orientes vers quelque chose à
plus grande échelle que la machine dans le garage, c'est d'isoler les
catégories de services. JP Troll a beau dire que la virtualisation,
c'est un bond en arrière jusqu'aux OS monotâches, une bonne isolation de
contexte
Bonjour
Je réponds à la liste vu que la question et la réponse peuvent
intéresser tout le monde
> Je ne comprends pas en quoi ta question diffère de la précédente.
> Si tu veux dire un serveur qui héberge plusieurs services qui n'ont rien à
> voir (ce qui est abominable sans à minima un chroot av
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 à
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 Bla
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 beso
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 versi
Le 6 avril 2012 23:07, Hugues 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) e
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 applicatif
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 :
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#Usi
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
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
On Thu, 5 Apr 2012 10:03:14 +0200, "JF Bustarret"
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
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
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
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écifiq
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 p
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 po
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 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 flor
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é
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 LA
... ç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é
Le 04/04/2012 14:40, cam.la...@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
J'utilise une appliance rweb.
Le 4 avril 2012 14:40, cam.la...@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
>
On 04/04/12 14:40, cam.la...@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-fo
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 (SS
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
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/
30 matches
Mail list logo
