Just Another Geek

WormRadar [archive], développé par Roger Thompson, est un projet qui a pour but d'écouter le trafic passant par une machine et de faire des statistiques sur les connexions entrantes en fonction des ports ciblés. Le résultat final est un graphique [archive] disponible sur le site du projet mis à jour toutes les trente minutes.

L'objectif principal est de détecter les nouveaux Worms, bots, ou tentative de piratage. WormRadar est un outil "distribué" dans le sens où tous les clients participant au projet envoient leurs résultat à un serveur principal qui traitera les données.

En effet, les paquets reçus par le client sont analysés pour détecter les patterns déjà connus. On peut alors distinguer deux catégories de "connexion" :

• Les données non reconnus par le moteur, représentée par l'item rouge dans le graphique. Les noms sur le graphique sont déterminés à partir du protocole (TCP ou UDP principalement), du numéro de port et de la chaîne "unk".
  Exemple : t1433unk pour le port 1433 en TCP
• Les paquets reconnus par l'analyseur, en vert. Cette catégorie comptablilise également les paquets vides.

Ce qui nous intéresse le plus sont les données inconnues car si on reçoit sur un même port un nombre important de connexions, on peut découvrir un nouveau Worm ou une nouvelle faille.

A l'heure actuelle, un peu plus de 1500 nodes participent au projet. Les données sont uploadées au serveur par mail et par UDP (avec exactement le même contenu que le mail sans l'enveloppe).

Les projets similaires ne manquent pas (Dshield [archive], ISC [archive]) et semblent beaucoup plus ouvert que WormRadar qui n'est disponible que sous forme binaire pour les systèmes Microsoft Windows (mais son auteur compterait porter l'application sous GNU/Linux).

Plus je lis les sources du noyau, plus je me dit que c'est pas si mal l'instruction goto. Ca clarifie vraiment le code dans certains cas.

Par contre, je n'ai toujours pas compris pourquoi ils utilisaient :

for (;;) {
  ...
}

Plutôt que

while (1) {
  ...
}

D'accord, y a moins de touches pour la boucle for(), mais je trouve ça tellement moins lisible !

C'est amusant de voir toutes les personnes qui croient avoir le scoop en or à chaque faille de sécurité. Par exemple, regardez tous les marketeux qui parlent au sujet de la Faille TCP/IP ! Ils sont tellement content qu'ils diffusent l'information sur toutes les mailing lists, ou forums. On leur dit que la technique est connue depuis 1996 ?

Ah si si si si, l'Internet va couler par les méchants n'hackers...

M'enfin...

Google propose depuis deux ans d'accéder aux fonctionnalités du moteur de recherche à travers un protocole méconnue : SOAP. Ce protocole permet aux programmes d'avoir un accès rapide aux résultat d'une recherche sans avoir besoin de faire des requêtes HTTP/HTML classiques puis de parser le résultat.

L'article détaille le protocole utilisé, et offre une implémentation Python de ce service. De plus, une (courte) réflexion sur l'utilisation de ces données est émise.

Le tout disponible sur http://mouarf.org/papers/google-soap/ [archive]

C'est Wanadoo qui respecte sa tradition d'excellent FAI ou bien Google [archive] est vraiment lent depuis ce week-end ?

Voici un lien trouvé sur le blog de Kenneth Hunt au sujet de l' architecture de Google [archive].

On peut voir que Google a un système assez atypique (Traduction: qui n'est pas Décideur compliant), on sent que les choix ont été fait par des vrais techniciens/architectes, et pas par un marketeux, résultat : pas de SAN, ni de RAID, etc. Ils préfèrent utiliser beaucoup (Plusieurs milliers) de machines de type PC pour avoir une infrastructure puissante, et pas chère.

C'est original et puis ca doit etre tellement beau de voir ces centaines de machines par salle tournant sous Linux