La piste des applets

Suivant: Table des matières Monter: Solutions et résultats Précédent: La piste des compteurs

La piste des applets

Nous avons finalement trouvé trois façons de détecter l'applet. La première solution est de détecter la balise applet et le nom de l'applet. Grâce au mot clé 'nocase;', on rend le nom et les balises insensibles à la casse.

La deuxième consiste à rechercher les paramètres destinés à l'applet. Dans notre cas, il s'agit de targetUrl et de evade.

La troisième intercepte les requêtes sortantes contenant la chaîne ".class" à destination de certains hôtes non sûrs. Dans notre cas, l'hôte est knuth.

Limites :
La première règle est assez fragile car il suffit de changer le nom de la classe et de recompiler pour que l'applet ne soit plus détectée.

La deuxième fait intervenir des détails de l'implémentation de l'applet. Pour pouvoir changer les paramètres dans la page html, il faudrait changer le code qui récupère les paramètres ce qui est un rien moins simple que de changer le nom.

La troisième méthode est beaucoup plus générale car elle s'attaque aux .class en provenance d'un serveur bien particulier. Il est évident qu'il faudra une règle par serveur que l'on veut surveiller.

Les Règles :

Les règles sont:

alert tcp any 80 -> $HOME_NET any (msg:"Flooding Applet"; content:"<applet";

nocase; content:"zapsfloodnetpublic1.class"; nocase;)

alert tcp any 80 -> $HOME_NET any (msg:"Flooding param"; content: " targetUrl ";

nocase; content:"evade"; nocase;)

alert tcp $HOME_NET any -> 192.168.1.44/32 80 (msg:"flooding server"; uricontent: ".class"; nocase;)

Suivant: Table des matières Monter: Solutions et résultats Précédent: La piste des compteurs