Mai 04

This is the sound of beat

Mon précèdent billet a reçu un accueil plutôt chaleureux et je vous en remercie 😀

J’ai reçu énormément de mails (félicitations, insultes, invitation à faire grossir mon sexe, toussa quoi) et des questions les plus pertinentes les unes que les autres.

Je n’ai pas répondu à tout le monde et je m’en excuse, mais certaines de ses questions étaient « plutôt limite » vis à vis de la législation en vigueur…
Je rappelle que ce n’était qu’une démonstration didactique et que je n’ai pas vocation à former des cambrioleurs en herbe… A bon entendeur…

Parmi celles ci, l’une d’entre elles m’a particulièrement amusée :

« Peut-on savoir quelle technologie domotique est employée depuis l’extérieur du domicile ? »

La question est intelligente et sans dévoiler toutes les facettes, j’ai trouvé intéressant de vous faire une autre petite démonstration à ce sujet.

Car oui, notre environnement domotique est « bruyant ». Oh bien sûr vous n’entendez rien (comme vous subissez les ondes de vos équipements divers et variés qui transforme petit à petit votre cerveau en gélatine flasque et malodorante au fil des années, faisant approcher votre QI du chiffre de la température anale (nan j’déconne… quoi que 😉 ), mais en calant un récepteur audio sur la fréquence de vos équipements domotique, vous pouvez rapidement vous rendre compte qu’ils ne sont pas très discret 🙂

En écoutant donc le son que produit régulièrement vos équipements (sortie de veille ou communication de l’état de la batterie), on peu rapidement en déduire la technologie utilisée dans le domicile.

Un capteur 433Mhz CHACON en action :


Son produit par un module 433Mhz par Guiguiabloc

Un capteur ZWave 868Mhz en action :


Son produit par un module Z-Wave 868Mhz par Guiguiabloc

Petit bonus, ça fait du bruit un brouilleur ?…


Son produit par un brouilleur CDMA par Guiguiabloc

Ah oui, ça sature un peu les fréquences 😀

Amusant, non ?

Classé dans domotique, geekerie | Taggé , , | 4 Commentaires
Avr 27

Neutralisation des alarmes domotiques Z-Wave

La domotique fait une percée de plus en plus grande et c’est un bonne chose.
Toutefois, nombreux sont ceux qui au regard des modules disponibles de détection périmétriques et volumétriques, se font fort d’en faire leur système d’alarme principal et d’ajouter le terme « sécurité » à la domotique.

Loin de moi le fait de dire que je suis un expert en sécurité des biens mais j’ai quand même un peu d’expérience dans ce domaine, être parmi les premiers à souligner à chaque fois qu’il ne faut pas mélanger « torchons et serviettes » et que la domotique et l’alarme sont deux domaines bien différents.
Je ne suis pas le seul à m’alarmer (humour) et à alimenter le débat sur ce genre de discussion que je vois de plus en plus fleurir sur les forums dédiés.
Le tweet de mon confrère Spyou aka @Turblog me rassure sur le fait de ne pas être seul à m’inquiéter de ce mélange des genres.

Alors je vous avoue avoir longuement hésité à publier ce billet.

La même hésitation que j’avais eu en publiant la démonstration d’un crochetage de serrure ou celle que l’on peut avoir en dévoilant une faille de sécurité qui pourrait être « maladroitement » utilisé (ou utilisé à mauvais escient).

Si le cas de la serrure était plus facile à montrer car il faut les outils et l’expérience, la neutralisation d’un système d’alarme domotique est plus délicate.

Il existe plusieurs techniques et j’ai décidé de vous montrer la plus rapide et la plus efficace visuellement tout en ne montrant qu’une partie de la neutralisation et en obligeant toujours le fait qu’il faille un équipement spécifique que tout le monde ne détient pas forcément dans l’instant.
Même si c’est une fausse excuse (après tout si moi je détiens ce genre d’équipement, tout le monde peut l’avoir aussi (ou presque 😉 ), elle s’oblige à s’engager dans une démarche hors-la-loi pour laquelle vous êtes prévenue.

j’ai voulu cette démonstration surtout pour mettre un coup d’électrochoc aux idées préconçues sur la fiabilité des « alarmes » domotique ou de l’utilisation de ses équipements en tant que tel.

Bien entendu, c’est à but didactique, et cela peut vous couter cher si vous décidez de « jouer » a cela chez votre voisin détesté…

IMPORTANT : Ce genre d’utilisation est une infraction aux articles L 33-3 2 et 3, L 39-1 3, L 39-1 4 du code des postes et des communications.

Matériel mis en oeuvre pour la démonstration

Pour cette petite démo, j’ai utilisé les éléments suivants :

– 1 capteur d’ouverture Z-wave AEON LABS

– 1 contrôleur Z-wave Aeon Labs Z-stick S2

– 1 brouilleur radio (jammer) incluant le CDMA

Brouilleur Tri-bandes 2,7W

Petit rappel, le Z-Wave (que l’on retrouve dans les box de type Vera ou BlyssBox)  fonctionne sur la fréquence 868,42 Mhz et le CDMA couvre la bande 850-894MHz, donc pile dedans.

Les images valant tout les commentaires, voici donc la démonstration en vidéo :


Brouillage radio de module Z-Wave par Guiguiabloc

Inquiétant, non ?

Rassurez-vous (ou pas), le brouillage existe aussi sur les fréquences Wifi, caméra sans-fil (2,4 Ghz et plus) et sur les fréquences plus basses, comme le 433Mhz par exemple (Chacon, Dio, Blyboss (pour la partie 433Mhz) etc….

(ah oui, vous avez aussi sûrement remarqué que le GSM est brouillé également, adieu donc les transmissions téléphoniques par SIM…)

Oui mais une alarme « normale » (comprendre une vraie certifiée toussa), cela fait pareil !

Et ben non…

J’ai une alarme sans-fil professionnelle bi-bande. C’est à dire qu’elle fonctionne sur 2 fréquences éloignées l’une de l’autre (il me faudrait donc 2 brouilleurs si les fréquences étaient par exemple 433 et 868 Mhz), mais elle est surtout équipée d’une technologie « autoprotection radio » (la majorité des alarmes sans fils en sont équipées).
En langage des mortels, cela veut dire qu’elle détecte une tentative de brouillage radio et… se déclenche (j’en ai fait la douloureuse expérience sonore 😀 ).

Je n’ai pas écrit ce billet pour descendre en flammes les équipements domotiques incluant des modules de sécurité, je l’ai écrit pour bien montrer que ce n’est ABSOLUMENT PAS un système de sécurité fiable et certifiée ! (D’ailleurs je ne connais aucune solution domotique grand public certifiée A2P…).

Les détecteurs périmétriques et volumétriques de ses solutions ont un but « domotique » (allumer la lumière quand il détecte votre présence, couper le chauffage quand une fenêtre est ouverte etc..) et pas dans un but de protection de l’habitation.

En espérant que vous y réfléchirez à deux fois avant de confier l’intégralité de votre système de sécurité à votre équipement domotique…

Classé dans domotique, sécurité | Taggé , , , | 50 Commentaires
Avr 17

Naxsi, du WAF pour votre Nginx

Quand je dis WAF, je parle bien sûr de Web Application Firewall , pas de Wife Acceptance Factor , (quoi que parfois cela peut être étrangement lié 😀 )

Je tiens toute suite à éviter toute polémique sur l’image illustrant l’article, c’est juste que cela m’a fait bien rire d’imaginer Ivan Drago en Nginx russe prêt a affronter les scripts kiddies capitalistes 🙂 (mais cela ne fait rire que moi, je sais :p)

Mais revenons au sujet de ce billet.

Si vous êtes un peu proche de la sécurité des « serveurs web », vous avez vite compris que le simple firewalling tel qu’on le connaît devient de moins en moins adapté aux formes d’attaques présentes sur le Nain Ternet.

Au bout d’un moment, il va falloir ajouter quelques filtrages de niveau 7 pour regarder et analyser ce qu’il se trame (humour), dans nos requêtes http.

Pour les sites « web », il s’agit principalement d’insérer un firewall applicatif dédié au requêtes http, on appelle cela un WAF.

Si votre serveur http est Apache, vous utilisez sûrement le module mod_security (un must have sur tout serveur de ce nom), ou encore Ironbee (je vous en reparlerais peut être un autre jour, étant grand fan d’ Ivan Ristic, l’auteur justement de modsecurity).

Vous utilisez IIS ? Je ne comprends même pas ce que vous faites sur ce blog… 🙁

Donc, avec Apache, je jouais avec mod_security ou Ironbee mais j’utilise aussi Nginx depuis des années, le serveur http venu du froid qui pourrait bien vous faire revoir votre vision des serveurs http.

Bref, ce n’est pas un débat Apache VS Nginx (chacun a ses avantages/inconvénients et cela dépend vraiment de la façon dont vous utilisez votre serveur http (même si Nginx ça roxx sa maman en slip).

Donc, même si Nginx supporte plutôt très bien certains types d’attaque (qui a dit Slowloris ? :p), votre site web, lui, a peut être quelques failles de type injection SQL, Cross-Site scripting ou Cross-Site Request Forgery.

Et ModSecurity ne fonctionne pas sous Nginx.

Heureusement, il existe un WAF dédié pour Nginx, et pas des moindres.

Ce WAF s’apple NAXSI, et il est issu d’une société qui n’est pas dans le genre « plaisantin » quand il s’agit de sécurité informatique : NBS-SYSTEM

Pour preuve, vous trouverez chez eux des gens plutôt velus qui entre autres fondent des groupuscules intégristes que l’on vénère ou l’on détéste 🙂

(même GuiguiAbloc en parle, c’est pour dire :p)

Vous me direz, « mouais, c’est sympa ton truc, mais dans la vrai vie, ça a fait ses preuves ? »

Et bien, disons qu’il y en a qui ont plutôt bien apprécié son efficacité...

Tout de suite, on se dit, « ok, ca a quand même subit un bon test IRS (In Real Situation) »

Si je vous parle avec autant de passion de Naxsi, c’est que ce WAF a une approche plutôt originale du firewall.

Alors que ses confrères se basent surtout sur des signatures (comme un antivirus), Naxsi, lui, fonctionne comme un filtre bayésien (et oui, comme les anti-spams).

Il détecte les chaînes de caractères suspectes et donne un « score » qui, quand il devient trop élevé, renvoi le « visiteur » vers une page de votre choix (403, ou pire, vers votre NIDS pour analyse ultérieure 😉 )

Je vous invite bien entendu à vous goinfrer du Wiki du projet.

Suffit la causette, comment on met cela en place ?

Je suppose que vous avez télécharger les sources de Nginx ainsi que la dernière version stable de Naxsi (0.43-1 a ce jour).

On détargézède tout cela et on compile Nginx avec Naxsi en tant que module.

Attention : Spécifier bien le add-module Nasxi en premier ! Nginx est sensible à l’ordre de chargement de ses modules.

Exemple :

./configure --prefix=/opt/nginx -add-module=../naxsi-0.43-1/naxsi_src/ --with-http_ssl_module --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --without-http_uwsgi_module --without-http_scgi_module

.Bien sûr je vous laisse adapter à votre configuration 🙂

Copier le fichier naxsi-0.43-1/naxsi_config/naxsi_core.rules dans votre répertoire conf de Nginx (par exemple), et on prépare la configuration de Nginx.

...
 
http {
include        /opt/nginx/conf/naxsi_core.rules;
 
...
 
server {
proxy_set_header Proxy-Connection "";
listen       *:80;
access_log  /opt/nginx/logs/nginx_access.log;
error_log  /opt/nginx/logs/nginx_error.log debug;
 
location /RequestDenied {
proxy_pass http://127.0.0.1:4242;
}
 
location / {
include    /opt/nginx/conf/monsite.rules;
...

Petite explication dans le texte.

Au niveau du block http de Nginx on charge les filtres de Naxsi (/opt/nginx/conf/naxsi_core.rules)

Puis au niveau du virtualhost, on définie une destination « RequestDenied » où seront envoyées toutes les requètes interceptées par Naxsi.

On se fait un petit fichier incluant les règles nouvellement apprises :

include    /opt/nginx/conf/monsite.rules

Fichier qui contient :

LearningMode;
SecRulesEnabled;
DeniedUrl "/RequestDenied";
 
include "/tmp/naxsi_rules.tmp";
 
## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

La ligne « proxy_pass http://127.0.0.1:4242 » est un petit plus de Naxsi : l’apprentissage.

Et oui, comme tout filtre bayésien, Naxsi est capable d’apprendre des requètesiqui sont légitimes pour votre site web, ce la s’appelle une liste blanche (white list).

Pour cet apprentissage (learning mode), il vous faut un petit serveur http local qui écoutera sur le port 4242 et alimentera la base de Naxsi (dans mon exemple, le fichier /tmp/naxsi_rules.tmp  qui deviendra ensuite le /opt/nginx/conf/monsite.rules.

Vous pouvez donc télécharger le script http_config.py ici :

http://code.google.com/p/naxsi/source/browse/trunk/contrib/rules_generator/http_config.py

C’est fait ?

Lancons le http_config :

/opt/nginx/sbin# python http_config.py --rules /opt/nginx/conf/naxsi_core.rules
Starting server, use <Ctrl-C> to stop

Puis Nginx.

Maintenant vous pouvez surfer sur votre site, afin d’alimenter la liste blanche qui se créera en fonction des spécificités de votre site web.

Une petite visite sur http://localhost:4242 vous indiquera les règles apprises et en attente de validation :

You currently have 4 rules generated by naxsi
You have a total of 1584 exceptions hit.You should reload nginx's
config.Write rules and reload for ALL sites. [write&reload eos|0
pending rules|
filename:/tmp/naxsi_rules.tmp.21db4a5fea0f4dedb0aa90007de5c3c3]
[write&reload wafing.me|4 pending rules|

Il vous suffit alors de valider le « Write&reload » pour enregistrer les règles dans votre fichier.

Tout cela bien sûr est clairement expliqué ici :

http://code.google.com/p/naxsi/wiki/Howto#Installing_nginx_+_naxsi

Une fois votre fichier bien rempli, vous pouvez modifier votre VirtualHost pour renvoyer les visiteurs indélicats sur un 403 :

location /RequestDenied {
#proxy_pass http://127.0.0.1:4242;
return 403;
}

Et de commenter le « learning mode » dans votre fichier de règles.

Si bien sur, vous voulez continuez à alimenter votre filtre avec une restriction d’accès, un excellent exemple est disponible ici :

http://blog.memze.ro/?p=81

Une fois en place, vous pouvez tester a loisir la puissance de votre Naxsi :

GuiguiAbloc:~# wget "http://wafing.me?a=<>"
--2012-04-17 22:40:55--  http://wafing.me/?a=%3C%3E
Résolution de wafing.me... 8.20.110.175
Connexion vers wafing.me|8.20.110.175|:80...connecté.
requête HTTP transmise, en attente de la réponse...403 Forbidden
2012-04-17 22:40:55 ERREUR 403: Forbidden.

Je ne peux que vous inviter chaudement (tss tss), à lire la documenation de Naxsi et surtout remonter les éventuels problèmes à l’équipe pour ce projet jeune mais terriblement efficace et innovant dans le monde merveilleux des WAF.

Amusez-vous bien 😀

Classé dans linux, sécurité | Taggé , , | 8 Commentaires
Mar 31

Géolocalisation par DNS avec Bind

Un petit billet rapide suite à la réception en Alpha test d’un serveur OVH au Canada 🙂

Alors voilà, vous avez votre serveur en Europe et un autre aux USA (je simplifie, hein, ca peut être votre ferme de serveurs dans le Larzac et l’autre dans le Wisconsin).

Si vous avez décidé d’offrir le même service au monde entier, il serait peut-être intéressant de rediriger vos visiteurs américains sur votre serveur aux US et vos visiteurs européens sur celui en Europe, question de latence.

Cette technique, employée depuis très longtemps par les « accélérateurs de contenus » comme Akamaï , a été reprise par les sites à gros trafic comme Google, Yahoo et consorts.

Comment on met cela en place ?

D’abord je considère que vous avez 1 serveur DNS qui tourne sur chacun de vos serveurs (1 aux US, 1 en Europe).

Bien évidemment, on définira ses deux serveurs en NS du domaine que l’on veut géolocaliser.

Pour réussir ce tour de force de géolocalisation, il vous faut une base des adresses IPs mondiales et les pays dans lesquels elles sont attribuées.

L’un des site spécialisé dans ce domaine est Maxmind

Et bonus, ce site offre en téléchargement une base de ses IPs :

http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip

C’est un fichier CSV au contenu plutôt impressionnant qu’il va falloir rendre compréhensible par votre serveur DNS.

Heureusement, Mark, sur son site Phix.me, vous propose un script Bash pour faire cela rapidement.

.

#!/bin/bash
 
[ -f GeoIPCountryCSV.zip ] || wget -T 5 -t 1 http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
 
echo -n "Creating CBE (Country,Begin,End) CSV file..."
unzip -p GeoIPCountryCSV.zip GeoIPCountryWhois.csv | awk -F \" '{print $10","$6","$8}' &gt; cbe.csv
echo -ne "DONE\nGenerating BIND GeoIP.acl file..."
 
(for c in $(awk -F , '{print $1}' cbe.csv | sort -u)
do
  echo "acl \"$c\" {"
  grep "^$c," cbe.csv | awk -F , 'function s(b,e,l,m,n) {l = int(log(e-b+1)/log(2)); m = 2^32-2^l; n = and(m,e); if (n == and(m,b)) printf "\t%u.%u.%u.%u/%u;\n",b/2^24%256,b/2^16%256,b/2^8%256,b%256,32-l; else {s(b,n-1); s(n,e)}} s($2,$3)'
  echo -e "};\n"
done) &gt; GeoIP.acl
rm -f cbe.csv
echo "DONE"
exit 0

Vous avez maintenant un fichier geo.acl compréhensible par BIND.

On se modifie BIND pour servir un fichier d’enregistrement différent suivant le pays d’origine du visiteur :

named.conf :
include "/opt/bind/GeoIP.acl";

Et pour traiter les visiteurs, nous allons utiliser le système « View » de BIND qui nous permet de servir des réponses différentes suivant l’ip du demandeur.

view "north_america" {
  match-clients { US; CA; MX; };
  zone "guiguiabloc.fr" {
       type master;
       file "/etc/bind/guiguiabloc.us";
       allow-transfer { ipdnsslave; };
       allow-query { any; };
};
};
 
view "south_america" {
  match-clients { AR; CL; BR; PY; PE; EC; CO; VE; BO; UY; };
  recursion no;
zone "guiguiabloc.fr" {
       type master;
       file "/etc/bind/guiguiabloc.us";
       allow-transfer { ipdnsslave; };
       allow-query { any; };
 
};
};
 
view "other" {
  match-clients { any; };
zone "guiguiabloc.fr" {
       type master;
       file "/etc/bind/guiguiabloc.fr";
       allow-transfer { ipdnsslave; };
       allow-query { any; };
};

Et voila, on relance BIND et vous devriez désormais avoir une réponse différente suivant le pays depuis lequel vous êtes (ou pas :p)

En espérant que cela vous soit utile 😀

Tout cela bien expliqué dans la langue de Shakespeare (ou de John Holmes, suivant vos centres d’intérêts… ) :

http://phix.me/geodns/

Classé dans linux, réseau | 12 Commentaires