Le Blog du grand loup Zeur » Système http://blog.gaetan-grigis.eu Le blog qui vous fait connaitre ce que vous savez déjà Tue, 17 Jan 2012 08:43:06 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Fake fencing sur Red Hat6 http://blog.gaetan-grigis.eu/systeme/administration/fake-fencing-sur-red-hat6/ http://blog.gaetan-grigis.eu/systeme/administration/fake-fencing-sur-red-hat6/#comments Mon, 16 Jan 2012 18:12:08 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1158 Plop …

Un petit retour sur l’article du failover mysql avec les clusters de red hat.

Lorsque l’on test son système de failover (machines virtuelles, ou …) sans matériel de fencing (switchs/routeurs/périph dédiés), les tests d’arrêts complets (coupure de courant barbare) échouent lamentablement, car pour switcher les services d’une machine à une autre, le daemon fenced envoie un signal de reboot au serveur ayant la main sur le service via le système de fencing, et si celui-ci ne répond pas, le service n’est pas redémarré (il considère qu’il a lui-même un problème), ne permettant pas de valider le test du « Si la machine crash, est-ce qu’une autre prendra le service ? ».

Il existe cependant des services permettant de faker ces systèmes lors d’utilisation de machines virtuelles, malheureusement pour moi, je n’utilise pas le système de machine virtuelle xen directement sur red hat6, ne me permettant de de jouir des agents fence RHEV-M et libvirt pour les machines virtuelles, et désactiver l’accès au groupe de fence empêche le rgmanager de se lancer (pose de lock sur dlm-control et dlm-rgmanager qui n’existe pas sans fence) donc passage obligé à la création d’un « fake fence ».

Pour simuler le système de fence de RHEV-M (un simple client http qui balance 3 requêtes pour vérifier si la machine existe et lance l’action de reboot), j’ai donc crée un serveur Web en python, qui renvoit des XMLs complétement faux, mais qui contiennent les infos que l’agent fence_rhevm cherche, lui permettant de valider le reboot et de débloquer le service!!!

Le codage est très simple (avec une belle XSS en prime ^^, mais comme l’agent fence_rhevm crée ses propres urls de requêtes … osef ;=)) :

  1.  
  2. #!/usr/bin/python
  3.  
  4. import SocketServer
  5. import re
  6.  
  7. status="down"
  8. class FenceHandler(SocketServer.BaseRequestHandler):
  9.     def handle(self):
  10.  global status
  11.         self.data = self.request.recv(4096)
  12.  re_get_name = re.compile("GET /api/vms/\?search=name%3D(.*) HTTP/1.1",re.IGNORECASE)
  13.  result_name = re_get_name.search(self.data)
  14.  
  15.  #If there is no Get, it's a posted action
  16.  if result_name == None:
  17.   self.request.send("HTTP/1.1 200 OK\r\nContent-Type: application/xml\r\n\r\n<action />\r\n")
  18.   status="up"
  19.   return
  20.  
  21.  #Else it's a normal request, answer …
  22.  name = "none"
  23.  
  24.  if result_name != None:
  25.   name = result_name.group(1)
  26.  self.request.send("HTTP/1.1 200 OK\r\nContent-Type: application/xml\r\n\r\n<vms><vm id=\"id\" href=\"osef\"><name>"+name+"</name><type>server</type><status><state>"+status+"</state></status></vm></vms>\r\n")
  27.  status = "down"
  28.  
  29. if __name__ == "__main__":
  30.     HOST, PORT = "0.0.0.0", 9999
  31.     server = SocketServer.TCPServer((HOST, PORT), FenceHandler)
  32.     server.serve_forever()

Une fois lancé sur une machine, il ne reste plus qu’à fournir les infos dans le cluster.conf (à titre d’exemple) :

  1. <clusternode name="mamachine">
  2.  <fence>
  3.   <method name="overthelolandfaraway">
  4.    <device name="rhevm" port="1337"/>
  5.   </method>
  6.  </fence>
  7. </clusternode>
  8. <fencedevices>
  9.  <fencedevice name="rhevm" agent="fence_rhevm" ipaddr="10.1.1.1" login="rhevm" passwd="rhevm" ipport="9999" />
  10. </fencedevices>

Si jamais le script est modifié par WP, il reste accessible ici : https://raw.github.com/cipher16/script/master/fence.py (à n’utiliser que pour des tests bien sûr ;) )

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/administration/fake-fencing-sur-red-hat6/feed/ 0 Android C2DM Notification push en bash avec wget http://blog.gaetan-grigis.eu/systeme/android-c2dm-notification-push-en-bash-avec-wget/ http://blog.gaetan-grigis.eu/systeme/android-c2dm-notification-push-en-bash-avec-wget/#comments Wed, 27 Jul 2011 18:00:10 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1116 plop à tous … encore un article « borderline » et completement useless …

Cette fois pour tester les notifications C2DM (cloud to device messaging), l’équivalent Android des push iphone en un peu plus complexe nécessité d’avoir un compte google devant s’authentifier pour ensuite envoyer un message par device_id (le device id pouvant expirer, tout comme l’authentification), pour les push iphone il suffisait d’avoir les tokens et basta ^^).

Mais au final le système répond plutôt rapidement, cela dit, en suivant de nombreux tuto sur le developement d’application utilisant C2DM (ici un premier tuto complet et ici un second tuto assez complet et intéressant).

Le problème c’est que pour tester le C2DM, la méthode nécessitant une authentification, et l’utilisation d’un header spé, pour tester l’envoi de notifications, certains recommendent de créer une seconde appli android pour envoyer les push, ou bien encore d’utiliser curl pour les requêtes, un outil qui n’est jamais installé de base sur une machine (la plupart des sytèmes unix intégrant wget, pourquoi utiliser curl?).

Donc pour le fun, voici ma version wgeté (j’ai découvert l’usage des headers sur wget) :

  1. #!/bin/bash
  2.  
  3. if [ $# != 3 ]
  4. then
  5.         echo "Usage : $0 'mail' 'reg_id' 'message'"
  6.         exit
  7. fi
  8. email="$1"
  9. registration_id="$2"
  10. message="$3"
  11.  
  12. post_data="registration_id=$registration_id&data.message=$message&collapse_key=0"
  13.  
  14. if [ ! -f /tmp/ClientLogin ]
  15. then
  16.         read -p "Password : " -e password
  17.         wget "https://www.google.com/accounts/ClientLogin" –post-data="Email=$email&Passwd=$password&accountType=GOOGLE&service=ac2dm" -qO- > /tmp/ClientLogin
  18. fi
  19.  
  20. auth=`cat /tmp/ClientLogin|grep "Auth"|awk '{split($0,array,"Auth="); print array[2]}'`
  21.  
  22. wget "https://android.apis.google.com/c2dm/send" –header="Authorization: GoogleLogin auth=$auth" –post-data="$post_data" –no-check-certificate -qO-

Si le script ne renvoit rien, c’est bon, si il répond par un Error=UnMessageDerreur, c’est pas bon, bon dev ;)

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/android-c2dm-notification-push-en-bash-avec-wget/feed/ 1 Ossec et stats sur munin http://blog.gaetan-grigis.eu/systeme/administration/ossec-et-stats-sur-munin/ http://blog.gaetan-grigis.eu/systeme/administration/ossec-et-stats-sur-munin/#comments Mon, 16 May 2011 19:51:42 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1069 Plop à tous …
Encore un article sur Ossec … avec cette fois-ci quelques exemples de statistiques à afficher avec munin. Les scripts sont extrêmement simple à modifier pour chercher des infos spécifique à certaines exploitations propres à une infrastructure données (web, mails, …).

Le but de l’article est de présenter rapidement comment créer des graphes sur munin en bash

Le screen pour en mettre plein la vue ^^ :

Pour installer les graphes représentés ci-dessus, il faut modifier le fichier de configuration /etc/munin/plugin-conf.d/munin-node, et ajouter à la fin :

  1. [ossec_*]
  2. user root
  3. env.logdir /chemin/vers/logs/ossec/logs

Et les graphes (les infos fournit risque de ne pas être très précise, les grep étant fait sur des periodes de ~15 minutes et munin exécutant les scripts toutes les 5 minutes mais le but ici, est juste d’avoir un rapide aperçu des risques encourant par le serveur, donc ce niveau me suffit) :
de réponse active (nb ban/deban) /etc/munin/plugins/ossec_active_resp :

  1. #!/bin/sh
  2. if [ "$1" = "autoconf" ]; then
  3.         echo "yes"
  4.         exit 0
  5. fi
  6.  
  7. if [ "$1" = "config" ]; then
  8.         echo "graph_title Ossec #Active Response"
  9.         echo "graph_args –base 1000 -l 0 "
  10.         echo "graph_vlabel Number of active response"
  11.         echo "graph_category Ossec"
  12.         echo "graph_scale no"
  13.         echo "c_add_actions.label Number of Rules added"
  14.         echo "c_add_actions.draw LINE2"
  15.         echo 'c_add_actions.min 0'
  16.         echo "c_del_actions.label Number of Rules deleted"
  17.         echo "c_del_actions.draw LINE2"
  18.         echo 'c_del_actions.min 0'
  19.         exit 0
  20. fi
  21. LANG=fr_FR.UTF-8
  22. LC_ALL=fr_FR.UTF-8
  23. LOG_DATE=`date|sed -e 's/[0-9]:[0-9]* (UTC+[0-9]*)//gi'`
  24. NB_ADD=$(cat $logdir/active-responses.log |grep "$LOG_DATE"|grep add|wc -l)
  25. NB_DEL=$(cat $logdir/active-responses.log |grep "$LOG_DATE"|grep del|wc -l)
  26.  
  27. echo "c_add_actions.value ${NB_ADD}"
  28. echo "c_del_actions.value ${NB_DEL}"
  29.  
  30. exit 0

d’attaque par service à mettre dans /etc/munin/plugins/ossec_attack_services :

  1. #!/bin/sh
  2. if [ "$1" = "autoconf" ]; then
  3.         echo "yes"
  4.         exit 0
  5. fi
  6.  
  7. if [ "$1" = "config" ]; then
  8.         echo "graph_title Ossec #Attack per services"
  9.         echo "graph_args –base 1000 -l 0 "
  10.         echo "graph_vlabel Number of attack per services"
  11.         echo "graph_category Ossec"
  12.         echo "graph_scale no"
  13.         echo "apache.label Apache"
  14.         echo "apache.draw LINE2"
  15.         echo 'apache.min 0'
  16.         echo "ssh.label SSH"
  17.         echo "ssh.draw LINE2"
  18.         echo 'ssh.min 0'
  19.         exit 0
  20. fi
  21. LANG=en_US.UTF-8
  22. LOGDATE=`date +'%Y %b %d %H:%M:%S'|sed -e 's/\(.*[0-9]*:[0-9]\)[0-9]:[0-9]*/\1/g'`
  23. APACHE=$(cat $logdir/alerts/alerts.log |grep -A 1 "$LOGDATE"|grep apache|wc -l)
  24. SSH=$(cat $logdir/alerts/alerts.log |grep -A 1 "$LOGDATE"|grep SSH|wc -l)
  25.  
  26. echo "apache.value ${APACHE}"
  27. echo "ssh.value ${SSH}"
  28.  
  29. exit 0

Ici, ça couvre rapidement les besoins d’un blogs : SSH et Apache, il suffit de rajouter autant de grep que l’on veut sur les logs d’autres softs qu’ossec et …

A noter que mon système de base est en français (très mauvaise idées car les logs d’ossec sont en FR, mais les logs récupéré sont en anglais, d’où le jeux avec les LANG et LC_ALL).

Et on oublie pas le :

  1. /etc/init.d/munin-node restart

Pour prendre en compte les scripts …

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/administration/ossec-et-stats-sur-munin/feed/ 0 Améliorer les performances d’apache avec nginx http://blog.gaetan-grigis.eu/systeme/administration/ameliorer-les-performances-dapache-avec-nginx/ http://blog.gaetan-grigis.eu/systeme/administration/ameliorer-les-performances-dapache-avec-nginx/#comments Fri, 15 Apr 2011 18:00:04 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1032 Plop à tous …

Comme vous l’aurez surement remarqué, la quasi-totalité de mes derniers articles sont tirés d’expériences (plutôt foireuses) me poussant souvent à remettre en questions certaines notions que je pensais acquises … cet article n’y couperas pas :s.

Après avoir vénéré les serveurs apache pendant 7 ans, j’ai eu récemment à m’asseoir sur mes convictions et à installer nginx pour avoir des performances convenable …

La question

Pour la petite histoire, on m’avait demandé si une dedibox premier prix (2gig de ram et 2ghz de CPU) pouvait supporter dans les 60000 visiteurs/jours, j’ai répondu d’un oui fier et franc tout en appuyant ma réponse avec un petit calcul :

60000 visiteurs/12 heures (la nuit y’a pas beaucoup de visite …) * 100 ressources / 60 / 60 = 138 connexions par secondes. (Ce qui ne devrait pas être un gros problème pour apache).
Donc au minimum la config apache devait avoir un StartServer à 150 et devait pouvoir monter à 500 en jouant sur les MinSpareServers et MaxSpareServers.

Après achat d’un serveur avec 4 gig de ram, et une rapide configuration, le serveur apache tourne, les transferts DNS sont effectués, et là 400 visiteurs arrivent … apache consomme toute la mémoire, le serveur swap, plus rien ne répond … c’est foutu, à l’arrache je passe le swapiness à 0 et je baisse le nombre de ThreadLimit à 80 (pour 4 gig de ram c’est le maximum que l’on peut avoir).

Et là, le site web ram … plus de 500 personnes tente de se connecter en simultanée …
Pragmatique et très calme, le propriétaire du serveur me sort un gentil : « C’est pas toi qui m’avait dit que ça tiendrait le choc ? ».

L’erreur

Ma grosse erreur a été de ne pas calculer la ram nécessaire pour cette configuration :
Un process apache consomme 50Meg (en moyenne avec un ThreadPerChild à 5) et 50Mo * 150 processus = 7500Mo de ram nécessaire rien que pour soutenir le nombre de connexions moyen (en soirée ça devait monter à 500!!), et plus de 20 Gig de ram pour supporter plus de 400 connexions secondes.

La solution

Au final j’ai donc du me tourner vers nginx en reverse proxy pour apache et en fournisseur de contenu statique, la config est faite en 5 minute :

Dans un fichier mis dans le dossier /etc/nginx/sites-enabled/, on créée le reverse proxy sur notre serveur apache (qui écoutera sur un autre port : 8080), et toute url qui se termine en jpg,js,png … est directement cherchée sur le disque et renvoyée au client sans passer par apache

  1. server {
  2.   listen 80;
  3.   server_name www.monsite.fr monsite.fr *.monsite.fr;
  4.  
  5.   location / {
  6.     proxy_pass http://127.0.0.1:8080/;
  7.     access_log off;
  8.   }
  9.  
  10.   location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|xml)$ {
  11.     root /var/www;
  12.     access_log /var/log/nginx/monsite.fr.access.log;
  13.     error_log /var/log/nginx/monsite.fr.errors.log;
  14.     expires 30d;
  15.   }
  16. }

Pour apache on modifie le port d’écoute général :
Dans /etc/apache2/ports.conf

  1. Listen 8080

Et on modifie tout les VirtualHost *:80 dans les fichiers contenu dans /etc/apache2/sites-enabled/ par VirtualHost *:8080

Après un redémarrage d’apache et nginx, le serveur n’utilise que 700Mo de ram pour gérer 500 connexions/secondes, apache n’utilise que 20 processus, et nginx ne consomme rien (aucun module n’a été installé sur nginx). Cela dit, utiliser un apache worker voir un event worker aurait pu « corriger » ce problème, mais n’étant pas sûr du résultat, et étant dans le feu de l’action, je n’ai pas eu le temps de trop chercher de solution (on dirait pas comme ça, mais c’est éprouvant la vie d’un sysadmin ;) ).

Cela dit, le résultat est très probant, le wordpress et le forum sont affichés de façon quasi instantannées, et le serveur ne ram plus du tout.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/administration/ameliorer-les-performances-dapache-avec-nginx/feed/ 2 Connecter un réseau de machines virtuelles sur un réseau local http://blog.gaetan-grigis.eu/systeme/administration/connecter-un-reseau-de-machines-virtuelles-sur-un-reseau-local/ http://blog.gaetan-grigis.eu/systeme/administration/connecter-un-reseau-de-machines-virtuelles-sur-un-reseau-local/#comments Wed, 13 Apr 2011 20:13:34 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1023 Plop à tous …

Les tutos concernant les interconnexions entre réseaux virtuelles et réseaux locaux sont légions sur internet, mais leur propretés pour le réseau ou leur flexibilité laissent souvent à désirer (entre les techniques foireuse à coup de nat iptables, les rejeux arp via parprouted et j’en passe).

J’ai eu récemment mis en place un réseau de test sur vm (avec xen, mais les réseaux de virtualbox, vmware et … devraient eux aussi fonctionner), directement connecté sur un réseau local et j’ai trouvé une méthode bien plus simple et plus rapide à mettre en place : il suffit simplement d’utiliser la machine hôte en routeur/proxy arp (suivant le type de connexion de réseau).

Pour un réseau inclut dans un autre réseau (genre pour les VM 10.75.75.0/28 dans le réseau physique 10.75.75.0/24 (dans ce cas, il faudra que le dhcp soit configuré pour fournir des ip à partir de 10.75.75.17)).

Il suffit de rajouter ceci dans le fichier /etc/sysctl.conf :

  1. net.ipv4.ip_forward = 1
  2. net.ipv4.conf.default.proxy_arp = 1
  3. net.ipv4.conf.all.proxy_arp = 1
  4. net.ipv4.conf.default.rp_filter = 0

Et l’hôte servira de routeur entre les « deux » réseaux, ça présence sera quasi-invisible (les paquets ARP de la première interface sont rejoués sur la seconde interface seulement si l’adresse existe sur sa seconde interface, ce qui évite les surcharges).

Sur deux réseaux « séparés » (genre pour les VM 192.168.1.0/24 et pour le réseau physique 10.8.8.0/24)

Il suffit de rajouter ceci dans le fichier /etc/sysctl.conf :

  1. net.ipv4.ip_forward = 1

Et rajouter la route menant au réseau 192.168.1.0/24 via l’ip de l’hôte (mettre l’ip du réseau physique ;) ) dans le routeur du réseau 10.8.8.0/24.

Et comme ça on ne pourrit pas son réseau avec du rejeu ARP entre les réseaux physique et virtuel (ça peut augmenter de façon importante le traffic du réseau).

Ne pas oublier un coup de sysctl -p après modification du fichier /etc/sysctl.conf

Et on n’a pas besoin d’ajouter de surcouche iptables avec des règles dans tout les sens à chaque machine que l’on ajoute dans le réseau.

Y’a peut être plus simple, mais celle-ci me semble assez propre et rapide à mettre en place, tout en permettant de garder des performances assez élevées.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/administration/connecter-un-reseau-de-machines-virtuelles-sur-un-reseau-local/feed/ 0 Pourrir des votes avec bash et wget http://blog.gaetan-grigis.eu/systeme/pourrir-des-votes-avec-bash-et-wget/ http://blog.gaetan-grigis.eu/systeme/pourrir-des-votes-avec-bash-et-wget/#comments Wed, 23 Mar 2011 19:50:29 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1010 plop à tous … encore un script super useless (comme d’hab).

L’utilité du script est de bourriner une url de vote pour plomber ou augmenter des stats (le site avait une vérification par ip, donc il fallait utiliser des proxy).
Connaissant samair.ru(mon fournisseur de proxy), mon script ne fonctionnera qu’une semaine ou deux, mais comme je fait appel à pas mal de trucs intéressant dans ce script, je le partage, donc c’est juste informationnel et non pas fonctionnel.

Je rappel que l’utilisation de mon script n’engage que vous … vous êtes seul responsable en cas d’effet de bord, ou de dégâts causé par l’utilisation de se script … (j’ai quand même mis un sleep histoire de ne pas trop surcharger le serveur …).

Le fonctionnement du script :

  • mettre à jour sa liste de proxy (chez samair.ru … malgrès leur système anti-bot ^^).
  • nettoyer la liste des proxy en « décodant » leurs ports (le système de sécurité de samair.ru contre les bots)
  • boucler sur les proxy en tapant une url fournit en parametre du script

Et sans plus attendre le script :

  1. #!/bin/bash
  2.  
  3. UA="Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15"
  4. LETTER=""
  5. NUMBER=""
  6. function updateProxy()
  7. {
  8.  
  9.         wget http://www.samair.ru/proxy/time-01.htm
  10.         getvariable
  11.         cat time-01.htm|perl -ne 'while(m/<td>([0-9]+.[0-9]+.[0-9]+.[0-9]+)[^+]+([^\)]+)/g){print "$1:$2\n";}'|tr -s $LETTER $NUMBER|sed "s/+//g" > proxy
  12. }
  13.  
  14. function getvariable()
  15. {
  16. LETTER=`cat time-01.htm|perl -ne 'while(m/([a-z])=([0-9]);/g){print "$1";}'`
  17. NUMBER=`cat time-01.htm|perl -ne 'while(m/([a-z])=([0-9]);/g){print "$2";}'`
  18. }
  19.  
  20. function plombe()
  21. {
  22.         for proxy in `cat proxy`
  23.         do
  24.                 export http_proxy=$proxy
  25.                 echo "Using proxy : $proxy"
  26.                 wget –spider –user-agent="$UA" –no-cookies -T30 -t1 "$1"
  27.                 sleep  $((RANDOM%10+10))
  28.         done
  29.         export http_proxy=""
  30. }
  31.  
  32. if [ -z "$1" ]
  33. then
  34.         echo "$0 need an url as parameter"
  35. else
  36.         updateProxy
  37.         plombe "$1"
  38.         rm time-01.htm
  39. fi

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/pourrir-des-votes-avec-bash-et-wget/feed/ 2 SSL via GNUTLS sur apache2 http://blog.gaetan-grigis.eu/systeme/administration/ssl-via-gnutls-sur-apache2/ http://blog.gaetan-grigis.eu/systeme/administration/ssl-via-gnutls-sur-apache2/#comments Sat, 12 Mar 2011 14:42:58 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=1001 Plop à tous …

Aujourd’hui j’ai joué a « qui a la plus grosse » config ssl et c’est là que j’ai remarqué que le mod_ssl d’apache ne supportait que les protocoles SSLv3 et TLSv1.0 (le TLSv1.1 est en cours de dev) ce qui donnait un score pitoyable à mon blog sur ssllabs (qui permet d’avoir une idée du niveau de sécurité de l’implémentation ssl/tls d’un serveur web).


(Au passage certaine banques françaises en sont encore au niveau F, donc c’était déjà pas trop mal pour un blog ^^).

Ma configuration pour le mod_ssl ressemblait à ça, avec un certificat gratuit de chez startssl :

  1. <VirtualHost *:443>
  2.    ServerName blog.gaetan-grigis.eu
  3.    DocumentRoot /dossier/de/mon/blog
  4.    SSLEngine on
  5.    SSLProtocol -all +TLSv1
  6.    SSLCipherSuite ALL:-kEDH:-RC2:-MD5:-RC4:-DES
  7.    SSLCertificateFile /dossier/de/cert/blog.crt
  8.    SSLCertificateKeyFile /dossier/de/cert/blog.key
  9.    SSLCertificateChainFile /dossier/de/cert/sub.class1.server.ca.crt
  10.    SSLCACertificateFile /dossier/de/cert/ca.crt
  11.    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
  12. </VirtualHost>

Mais bon, si l’on peut faire mieux gratuitement, on ne va pas s’en priver, donc on installe :

  1. apt-get install libapache2-mod-gnutls
  2. a2enmod gnutls

A noter au passage, que gnutls supporte le SNI (utilisation de plusieurs certificat SSL sur une seul et même IP), et le protocole TLSv1.1

et on rajoute la conf :

  1. <VirtualHost *:443>
  2.    ServerName blog.gaetan-grigis.eu
  3.    DocumentRoot /dossier/de/mon/blog
  4.    GnuTLSEnable  on
  5.    GnuTLSCertificateFile /dossier/certificat/gnutls/blog-gnutls.crt
  6.    GnuTLSKeyFile /dossier/certificat//gnutls/blog-gnutls.key
  7.    GnuTLSPriorities NONE:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-CBC:+DHE-RSA:+RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE
  8. </VirtualHost>

Au passage, on remarque qu’il y a des fichiers en moins entre la config du mod_ssl et celle de gnutls … WTF ?!, en fait on a pas besoin du ca.crt, par contre, il faut concaténer le certificat du site (blog.crt) avec celui de la « chaine » (sub.class1.server.ca.crt).

Ce que l’on peut faire par un simple :

  1. cat blog.crt sub.class1.server.ca.pem > blog-gnutls.crt

On peu lancer un apache2ctl configtest, pour vérifier si la conf est bonne et redémarrer si il n’y a aucun problème.
Pour ma part avec startssl, le format de mon fichier key n’était pas supporté :

  1. GnuTLS: Failed to Import Private Key '/mon/dossier/de/cert/gnutls/blog-gnutls.key': (-207) Base64 unexpected header error.

Il a fallut supprimer la protection par mot de passe de la clé (pas bien :s), que j’ai fait sur le site de startssl, ou que l’on peut faire via la commande openssl.

Et si l’on refait un test, on a un meilleur score :
.

Le but de cet article n’était pas de dénigrer le mod_ssl (le fait que TLSv1.1 et TLSv1.2 ne soit pas encore supporter est juste due à ma version d’openssl de ma debian 6.0), mais juste de présenter le module gnutls (et son utilisation avec des certificats de chez startssl) qui ne semble pas supporter la renégociation et la compression (malgré l’utilisation du mot clé COMP-DEFLATE), mais qui peut supporter l’authentification par clé pgp et plein d’autre truc …

Un peu de doc au passage sur les différents systèmes de chiffrement :

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/administration/ssl-via-gnutls-sur-apache2/feed/ 4 Protection DDos et ban de masse http://blog.gaetan-grigis.eu/systeme/protection-ddos-et-ban-de-masse/ http://blog.gaetan-grigis.eu/systeme/protection-ddos-et-ban-de-masse/#comments Sat, 05 Mar 2011 12:58:41 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=982 Plop …
J’ai eu droit à ma première intervention sur serveur DDosé, au départ 2/3 machines qui envoyaient des paquets SYN en boucle sur un serveur minecraft (écrit en java donc avec 200 SYN/sec le serveur tombe), et à la fin c’est environ 150 machines qui se sont relayés pour Dosé.

La plupart du temps lorsque l’on recherche des protections DDos on trouve des sites qui recommandent de mettre direct un limit sur un port sans tenir compte de la source … ce qui peut se révéler utile sur des petits serveurs, mais pas lorsque l’on tourne à plusieurs centaines de connexion seconde.


La sécurisation de base est très simple, il « suffit » de limiter le nombre de syn sur le port particulier du service, ici le 25565, mais dans le cas des serveurs de jeux, il peut arriver que l’on dépasse le nombre de SYN (genre lors d’une deco/timeout), donc côté firewall ça donne ce genre de règle :

  1. /sbin/iptables -N syn-flood
  2. /sbin/iptables -A INPUT -p tcp –syn –dport 25565 -m connlimit –connlimit-above 1 -j syn-flood
  3. /sbin/iptables -A syn-flood -m limit –limit 2/s –limit-burst 5 -j RETURN
  4. /sbin/iptables -A syn-flood -j LOG –log-prefix "SYN-FLOOD "
  5. /sbin/iptables -A syn-flood -j DROP

Pour les explications :
Si il y a plusieurs paquets TCP SYN sur le port 25565 provenant d’une même IP on lui applique la règle « syn-flood ».
Tant qu’il y a moins de 2 syn/seconde, avec un burst à 5 syn on laisse passer, sinon, on LOG le paquet (histoire d’avoir une trace de l’ip) et on drop.

Le problème c’est que si l’on subit une attaque soutenu, le firewall va bosser en continu à checker les règles, mais comme on a log l’ip, on peut y mettre une règle avec OSSEC et mettre un ban permanent.

La règle de base à rajouter dans rules/local_rules.xml :

  1.   <rule id="100034" level="9">
  2.     <if_sid>4100</if_sid>
  3.     <match>SYN-FLOOD</match>
  4.     <description>SYN Flood Attempt</description>
  5.   </rule>

Qui aura pour effet de bannir pour un certain temps (par défaut 6 minutes) l’ip incriminée.

Génial, mais comme c’était du flood continu, une fois les 6 minutes passé, le flood continuait, et comme le flood se faisait avec 150 machines, le serveur était inondé en continu, malgré les règles iptables.

Donc on peut reprendre, mes règles de ban définitif et les appliquer ici.

Donc on rajoute dans local_rules.xml

  1.   <rule id="100035" level="5" frequency="2" timeframe="370">
  2.     <if_matched_sid>100034</if_matched_sid>
  3.     <same_source_ip />
  4.     <description>Multiple SYN Flood Attempt</description>
  5.   </rule>

Et on modifie /etc/ossec.conf en ajoutant l’id 100035 dans « l’active response » du « deny-for-life » de mon autre article (dans mon cas j’ai réécrit la règle pour utiliser le firewall) et boum … après 4 heures avec ces règles un coup de :

  1. iptables -L FORWARD -n|wc -l

Retourne 150 ip bannit et plus de SYN sur le port 25565 … victoire !! Par contre :

  1. iptables -L -v -n

Montre que le firewall drop toujours encore des paquets sur les ip banni … l’attaque est toujours en cours, mais semble endiguée \o/.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/protection-ddos-et-ban-de-masse/feed/ 3 [OSSEC et SSH]Bannissement ip définitif de cracker http://blog.gaetan-grigis.eu/systeme/ossec-et-sshbannissement-ip-definitif-de-cracker/ http://blog.gaetan-grigis.eu/systeme/ossec-et-sshbannissement-ip-definitif-de-cracker/#comments Sat, 19 Feb 2011 12:59:53 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=959 plop,

today du ban au menu, à la base j’utilise au minimum fail2ban pour me protéger des attaques par bruteforce et ossec pour une protection plus personnalisée, mais depuis peu, j’ai remarqué que bannir un host 5/10 minutes ne servait à rien contre des machines automatisées dédiée à cette tâche, et une fois la période de ban terminée recommençaient leur manège, me polluant de mails me signalant une tentative de bruteforce.

Alors j’ai imaginé des règles plus simple pour mettre en place un ban définitif des méchants cracker pour ossec :
L’idée est simple, j’ai deux utilisateurs sur ma machine (toto et root, root ne s’authentifiant que par clé et toto par mot de passe) :

  • tout utilisateur tentant de se logguer en root via mot de passe est banni définitivement
  • tout utilisateur tentant de se logguer via un utilisateur invalide (autre que toto) est banni définitivement

Comme ça, on évite les bruteforces à répétition, et on est tranquille pour longtemps avec ces ip là.

Côté règles sur ossec, c’est assez simple à mettre en place :
Dans le fichier rules/local_rules.xml on ajoute entre les balises (group) :

  1.   <rule id="100033" level="10">
  2.     <if_sid>5716</if_sid>
  3.     <match>root</match>
  4.     <description>A noob tryed to login as root with password !!</description>
  5.     <group>authentication_failed,</group>
  6.   </rule>

La règles 5716 (if_sid) étant celle des authentifications failed par mot de passe  et match root  pour trouver l’utilisateur root (ça veux donc dire que si on à le bon mot de passe root du premier coup, on peut quand même se logger, ce qui peut être utile dans certain cas, et assez improbable pour un cracker de se logguer).

Ensuite on ajoute dans le fichier etc/ossec.conf

  1.   <command>
  2.     <name>host-deny-for-life</name>
  3.     <executable>host-deny.sh</executable>
  4.     <expect>srcip</expect>
  5.     <timeout_allowed>no</timeout_allowed>
  6.   </command>
  7.   <active-response>
  8.     <command>host-deny-for-life</command>
  9.     <location>local</location>
  10.     <rules_id>5710,100033</rules_id>
  11.   </active-response>

La règle 100033 étant celle que l’on vient de rajouter et la règle 5710, étant l’utilisation d’un mauvais login, et on applique à ces deux règles la commande host-deny-for-life qui rajoute l’ip au fichier /etc/hosts.deny sans timeout (pour autoriser l’ip, il faudra l’enlever à la main).

Et comme ça plus de bruteforce sur des utilisateurs invalide et sur root.

Cela dit, on peut rajouter se genre de système de ban pour le serveur smtp lorsque d’autres machines tente de l’utiliser comme relay, voir faire des règles de ban automatique pour des serveurs de jeux vidéo avec des logs sur des cheaters, …

Si vous voulez en savoir plus sur ossec, un bouquin de syngress (de très bon bouquin sur l’IT en général) dédié à Ossec a été en partie publié et téléchargeable en pdf sur le site officiel (ça couvre l’installation, la configuration et la création de règle maison).

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/ossec-et-sshbannissement-ip-definitif-de-cracker/feed/ 3 Configuration de processus apache au poil … http://blog.gaetan-grigis.eu/systeme/configuration-de-processus-apache-au-poil/ http://blog.gaetan-grigis.eu/systeme/configuration-de-processus-apache-au-poil/#comments Sat, 05 Feb 2011 13:45:55 +0000 Gaëtan http://blog.gaetan-grigis.eu/?p=947 salut à tous …

Aujourd’hui on va parler configuration de processus apache … J’ai eu l’occasion en 3-4 jours de connaitre des problèmes sur plusieurs serveurs différents liée à une surconsommation de mémoire due à apache et à sa gestion des processus faisant littéralement planter mon blog (ça swap mal un RPS! donc 2 crash de la machine en 24 heures … avec les nouveaux prix des serveurs dédiés de chez online.net … je risque probablement de migrer prochainement ;) ).

Néanmoins ce genre d’incident n’empêche pas de revoir sa configuration, d’autant plus que comme pas mal d’administrateur débutant, l’installation d’un serveur web consiste en un simple apt-get install apache2 (en prenant le temps quand même d’installer modsecurity et les dernières règles depuis le site officiel) et pis c’est tout.

On se retrouve donc avec une configuration qui plafonne à 150 clients max en simultanés, sachant que mon blog n’a que 200 visites par jours, cette configuration est vraiment surestimée.

1.L’estimation du nombre de visiteurs/connexions

La première chose à savoir c’est bien entendu, le nombre de visite, mais aussi le nombre de fichiers auxquels les personnes auront accès lors de leurs première visite, car lors d’une visite, on télécharge la page html, mais aussi toutes ses ressources liées (css, js, images, …), pour un site moyen, il y a entre 20 et 50 connexions quasi simultanée (avec entre 1 et 10 secondes d’écart, suivant son type de connexion).

Pour mon site, j’utilise un CDN, hébergé par google (GAE), qui stock toutes mes données statiques (js,css,images), résuisant de façon assez significative le nombre de connexion sur mon serveur, comme le prouve le pannel de ressource de chrome :

Il n’y a donc qu’une seule requête effectuée sur mon serveur lors de la connexion d’un visiteur, le reste étant directement lié au domaine cdn.gaetan-grigis.eu (hébergé sur appengine et donc ne consommant pas de ressource pour mon serveur web).

Sachant qu’en plus de n’avoir que 200 visiteurs par jours, je n’ai donc que 200 connexions http à gérer (gràce au CDN, ce qui n’est pas le cas de tout les serveurs …).

En partant de ces chiffres, je peux désormais passer à l’étape suivante :

2.Découverte de la cible

Apache ayant plusieurs type de fonctionnement, suivant qu’il soit en prefork ou en worker, nous devons donc savoir à quoi nous avons à faire pour ensuite le configurer :

sudo aptitude search apache2|grep "^i"

qui renvoit le type de serveur installé, ici un mpm prefork (surligné en jaune) :

Je peux donc passer à la suite :

3.Détection de la menace

On peut passer à la configuration!! Comme je suis en mpm_prefork, j’ai juste à trouver les lignes correspondantes, qui par défaut contiennent ceci :

<IfModule mpm_prefork_module>
StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0
</IfModule>

Ce qui signifie :

  • StartServers : nombre de serveur démarré par défaut
  • MinSpareServers : nombre de serveur de « rechange » EN PLUS du nombre de StartServers (donc par défaut 10 processus au démarrage!!!).
  • MaxSpareServers : nombre maximal de serveur de « rechange », si ces serveurs ne sont pas utilisés, leurs processus sont tués!! BOUCHERIE!!! (façon Flander’s Company ;) )
  • MaxClients : Nombre de clients simultanées … en prefork, il s’agit du nombre de process max qui peuvent être crée. Son nombre multiplié à la taille moyenne d’un processus apache ne doit pas dépasser la taille de la ram dispo (sinon le kernel devra lutter pour libérer ce qu’il peux).
  • MaxRequestsPerChild : nombre de requête qu’un processus va faire avant de mourir (0 = infinie), si vos applications web (phpmyadmin, wp, …) bouffe beaucoup de mémoire, cette mémoire sera consommée jusqu’à ce que le processus soit tué, donc plus vous avez d’application gourmande et plus ce chiffre est élevé, plus apache va consommé de mémoire (et si en plus ce chiffre est 0, la mémoire ne sera jamais libéré!!).

Il y a donc de l’optimisation à faire !!

4.Les calculs pour l’éradication de la menace

Mes petits calculs pour optimiser la bête et ne plus utiliser le swap lorsqu’apache déconne : Un RPS chez OVH (probablement un SC chez online.net d’ici peut).

J’ai donc 512Mo de ram (493636 ko pour être exact ;) ) à partager entre plusieurs services : MYSQL et Apache principalement.

En faisant quelque test, avec unMaxRequestsPerChild à 3, un process apache en fin de vie utilisera 50Mo (avec en application principal WordPress).

Avec ma machine et les contraintes de services j’ai donc : 120Mo (Mysql) + 100Mo (Système : IPS, …)  + 100Mo (libre pour des bursts ou autre) = 320Mo, il me reste donc 200Mo de libre pour apache (200Mo/50Mo) = 4 processus.

Donc par défaut, ma machine pourra avoir 3/4 processus apache qui tourne en continue avec plusieurs processus apache en burst. Sachant qu’en plus le kernel est censé un peu gérer la mémoire lorsque ça devient serré, ça devrait pouvoir tenir mon nombre de visiteurs, sans avoir à exploser ma mémoire inutilement … au pire, les visiteurs patienteront ;)

Note : Mon calcul est très sévère, mon serveur peut faire tourner facilement une dizaine de processus apache sans trop de soucie, mais lors de pic de fréquentation élevé, il va commencer à swaper et devenir très lent (sur les RPS le disque dur est en réseau à 1Mo/s ..). Mais, avec cette configuration, je peux servir 3/4 clients par seconde, ce qui est amplement suffisant au vue de mes besoins.

5.Mise en place de la configuration

J’ai donc remplacé mon ancienne configuration par celle-ci, qui correspond à mes besoins actuelle.

<IfModule mpm_prefork_module>
StartServers          2 #démarrage de 2 processus
MinSpareServers       1 #1 processus de rechange par défaut donc 3 processus au démarrage
MaxSpareServers       3 #3 processus de rechange max, le reste étant tué lorsqu'il rentre en inactivité
MaxClients           12 #12 process max (12 processus*40Mo = 480Mo Max pour apache en cas de gros coup dur), 40Mo étant la taille moyenne d'un processus apache.
MaxRequestsPerChild   3 #une fois que le process à fait 3 réponse, il se tue et un autre est crée, histoire de renouveler la mémoire
</IfModule>

Et on oublie pas de redémarrer ;) . Après plusieurs heures de fonctionnement, mon RPS a toujours 100Mo de libre (à part lorsque le nombre de visiteur augmente de façon importante), ce qui était plus ou moins le but de cette configuration.

6.Note

Si votre machine fait uniquement tourner un serveur apache (sur une machine stable), il n’y a pas besoin d’être aussi strict que je l’ai été (il n’y a pas de mal à swapper ;) ), mais visiblement chez OVH, dès qu’une machine swap (et pas seulement sur les RPS apparement), elle ne répond plus très bien et si apache est mal configuré, il faudra généralement redémarrer apache pour le forcer à libérer toute la mémoire qu’il vampirise, ce qui peut poser problème pour des serveurs de jeux ou autre …

Pour mes calculs je me suis basé sur la valeur moyenne de la mémoire consommée par MES processus apaches (cette taille peut dépendre des modules utilisés et de leurs configurations : mod_php, mod_security, …). Cette taille peut donc changer, suivant votre configuration.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> http://blog.gaetan-grigis.eu/systeme/configuration-de-processus-apache-au-poil/feed/ 4