Reverse proxy Nginx : Load-balancing et Fail-Over
Tutoriel sur la mise en place d’une architecture de load-balacing et fail-over avec un reverse proxy Nginx
Lire cet articleTutoriel sur la mise en place d’une architecture de load-balacing et fail-over avec un reverse proxy Nginx
Lire cet articleNous allons ici voir comment envoyer les logs Access et Error d’apache sur un serveur rsyslog
Lire cet articleNous allons ici présenter le module de pare-feu applicatif mod_security, son installation et sa configuration basique.
Lire cet articleRediriger de façon permanente ou temporaire un domaine avec Redirect et les redirections 301 et 302.
Lire cet articleNous allons ici voir comment installer et configurer le module proxy_http d’Apache pour le faire agir en tant que reverse_proxy.
Lire cet articleNous allons ici voir ce qu’est la méthode HTTP TRACE et comment la désactiver sous Apache2.
Lire cet articlePartager vos documents en quelques clics grâce à Fenix.
Lire cet articleDans ce tutoriel, nous allons apprendre à mettre en place du Load-Balancing et du Fail-Over entre deux serveurs web sous Pfsense.
Lire cet articleIl est toujours utile d’avoir des métriques sur l’utilisation du processus Apache, le module status permet d’avoir ces informations.
Lire cet articleNous allons voir comment autoriser ou interdire les accès par vhost en fonction des IP
Lire cet articleNous allons ici voir ce qu’est le cache est quel est son rôle dans les protocoles et technologies dans lesquels il peut être utilisé.
Lire cet articleI. Présentation Dans les précédents billets, nous avons donc vu ce qu’était un serveur web mutualisé, de quoi il était constitué et pourquoi sa structure globale pouvait être facilement déjouée pour outre-passer les limitations standards mises en place. Dans le dernier billet de ce dossier, nous allons étudier des pistes pour sécuriser les vulnérabilités aperçues précédemment. Loin de moi l’idée de proposer une solution 100% sécurisée qui révolutionnerait le marché, je vise plutôt dans ce billet à donner des débuts d’idées et des pistes à parcourir pour arriver à résoudre certains problèmes rencontrés. II. Récapitulatif Il convient tout d’abord de poser sur la table les principaux points qui posent problèmes dans notre contexte : Un serveur web mutualisé héberge par définition plusieurs sites qui tournent donc tous sur le même utilisateur De ce fait, l’exécution d’un script menant des actions sur le serveur via cet utilisateur par les clients pose un problème de sécurité car ces derniers peuvent profiter des
Lire cet articleI. Présentation Dans nos précédents billets sur ce sujet, nous avons vu ce qu’était un serveur web mutualisé, leurs avantages et leurs limites et nous avons également vu leur architecture et fonctionnement général au niveau technique. En fin de la construction de cette architecture, nous avons été confronté à un problème de droit qui nous a forcé à élargir un peu plus les droits par défaut des répertoires web des clients. A travers ce post je vais montrer en quoi cet ajout de droit pose un problème majeur au sein des serveurs web mutualisés utilisant le couple habituel Apache/PHP, ce qui est le cas de la plupart d’entre-eux ! II. États des lieux Nous savons donc que pour fonctionner, les utilisateurs uploads leurs fichiers via un service FTP qui leur est dédié est par lequel ils accèdent à leur espace web qui est chrooté. Pour que ces fichiers soient immédiatement lisibles et traités par Apache via HTTP, nous sommes contraints
Lire cet articleI. Présentation Dans de précédents billets (concept et limites), nous avons vu en quoi un serveur web mutualisé consistait et quelles étaient leurs limités générales. Nous allons ici aborder un post un peu plus technique où nous allons, pour mieux les comprendre, monter une architecture système qui nous permettrait de faire tourner un serveur web mutualisé (aussi basique soit il). Je ne prétends pas ici révolutionner le serveur web mutualisé mais au contraire montrer de quoi il est, en théorie, composé et faire en sorte que les services que nous allons installer permettent un fonctionnement global pouvant être assimilé à celui d’un serveur web mutualisé. II. De quoi a t-on besoin ? Comme nous l’avons résumé dans le précédent billet sur le sujet, nous avons vu que le serveur web mutualisé a besoin de plusieurs services basiques pour être considéré en tant que tel : Chaque accès utilisateurs ayant alors besoin d’un accès au FTP, au minimum une base de
Lire cet articleI. Présentation Dans un précédent billet, j’ai tenté d’expliquer de façon non technique ce qu’était un serveur et un hébergement web mutualisé. Nous avons vu que ce type d’hébergement permettait d’avoir assez simplement un espace qui nous est réservé dans l’infrastructure d’un hébergeur afin d’y mettre nos sites web et nos applications web. Nous allons ici voir les différentes limites que peut présenter le choix d’un hébergement dans un serveur web mutualisé. II. Un espace dans un Datacenter avec des limites ? Eh bien oui, un hébergeur a tout intérêt, pour que la colocation de tous ses clients se passe bien au sein d’un même serveur, à instaurer des limites (voulues ou non), par le biais de droits par exemple mais aussi techniquement. Nous avons précédemment vu qu’un serveur web mutualisé consistait en l’utilisation d’une même ressource (la plus simple étant l’espace du disque dur) par plusieurs clients (comprendre sites web). Un site web (avec sa base de données) peut
Lire cet article