e-Construction : Mon cyber-journal perso

"L'intelligence c'est d'apprendre de ses erreurs, la sagesse c'est d'apprendre de celles des autres..."


J'ai essayé ces derniers jours d'exploiter les résultats obtenus par l'outil Honeysnap dans le but d'analyser « sommairement » des captures réseau sur un ensemble de serveurs.

J'ai pris comme traces celles d'une entreprise cliente qui a, en DMZ externe, un serveur Web, un serveur DNS et un serveur Webmail (le serveur de messagerie est dans une autre zone).

Mais, c'est facilement faisable sur une petite architecture perso …. pour voir qui s'intéresse à nous :)

Et croyez moi ... on découvre des choses intéressantes :)

Concrètement, j'ai créé deux scripts : Analyse_DNS et Analyse_WEB

Analyse_DNS :

1- En premier, je lance Honeyscan sur la capture dns.pcap, en spécifiant les options suivantes :

"-H$1" : on donne ici (comme argument au script) l'@IP du serveur DNS.

"--do-dns" : pour demander l'extraction des données DNS (requêtes et réponses)

"--do-incoming" : sommaire des flux entrants vers le serveur

"--do-outgoing" : sommaire des flux sortants du serveur


Ce qui donne :

honeysnap -H$1 --do-dns --do-incoming --do-outgoing $2 (l'argument 2 est le fichier capture)

Les résultats sont par défaut dans le sous-répertoire « output » du répertoire courant, avec l'@IP comme sous-sous-répertoire.


2- On va voir les différents flux entrants (TCP et UDP), par ordre croissant des occurrences et uniquement le top 20 par exemple :

cat output/$1/conns/incoming.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")" | awk '{print $14 }' | sort | uniq -c | sort -g | tail -n 20 > $1_flux_in_top20.txt

Dans mon cas, ça donne ceci :

1 23
1 38933
1 38940
…................
1 39452
1 39465
2 22
441656 53

Les connexions telnet et ssh sont légitimes d'après ce que j'ai vu avec les admins.

Les paquets vers les ports 3**** sont des réponses DNS

Et naturellement (à première vue), le gros, c'est des requêtes DNS …. vers un serveur DNS


3- Alors, je voudrais maintenant voir le top 10 des adresses sources :

cat output/$1/conns/incoming.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")" | awk '{print $11 }' | sort | uniq -c | sort -g |tail -n 10 > $1_src_top10.txt

Çà donne quelque chose du genre (désolé … c'est des traces privées du client )

57 80.*.*.*
78 80.*.*.*
90 207.*.*.*
114 219.*.*.*
138 123.*.*.*
462 192.168.0.10 0
3207 192.168.1.169
4788 192.168.1.104
55695 192.168.0.190
72288 192.168.0.189

Les @IP internes constituent le plus gros volume de communications....normale apparemment


4- On a vu le trafic entrant, et le trafic sortant ?

Voyons le top 10 des destinations …. réseau, pas celles de voyagealgerie.com :)

cat output/$1/conns/outgoing.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")"| awk '{print $13 }' | sort | uniq -c | sort -g |tail -n 10 > $1_dst_top10.txt

ça donne (désolé encore :) )

60 80.*.*.*
90 207.*.*.*
114 219.*.*.*
138 123.*.*.*
150 80.*.*.*
546 192.168.0.10 0
3207 192.168.1.169
4794 192.168.1.104
55695 192.168.0.190
72288 192.168.0.189

Globalement, c'est cohérent avec les flux entrant …. pas de quoi nécessiter une analyse approfondie.


5- Étant dans le cas d'un serveur DNS, il serait normale de s'intéresser au données DNS proprement dites.

Commençant par le top 20 des requêtes DNS :

cat output/$1/dns/dns_served.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")"| awk '{print $10 }' | sort | uniq -c | sort -g |tail -n 20 > $1_req_top20.txt

et le résultat est (re-désolé ;) )

3 *.*/*.*.*.*.IN-ADDR.ARPA
3 ns.moi.Dz
5 ns.moi.DZ
20 *.*/*.*.*.*.IN-ADDR.ARPA
22 webmail.moi.dz
47 *.*/*.*.*.*.in-addr.arpa
69 *.*/*.*.*.*.in-addr.arpa
72 ,
109 *.*/*.*.*.*.IN-ADDR.ARPA
176 www.moi.dz
219 *.*/*.*.*.*.IN-ADDR.ARPA
470 *.*/*.*.*.*.in-addr.arpa
516 *.*/*.*.*.*.in-addr.arpa
907 *.*/*.*.*.*.in-addr.arpa
1393 moi.dz
1903 1*.*/*.*.*.*.in-addr.arpa
4078 www.test.moi.dz
85583 ns.moi.dz

Alors déjà les 72 requêtes sur « , » c'est un peu bizarre.

Mais après investigation sur le fichier trace et en comparant aux fichiers produits par honeysnap , je remarque que toutes les requêtes « ratées » sont de type « any ».

Un bug ? Mes traces qui sont coupables ? Pas le temps de faire d'autres tests avec d'autres traces.

Un truc attire mon attention : 3 requêtes pour « ns.client.Dz » et 5 pour « ns.client.DZ »

Vous avez remarqué le « z » contre le « Z » ?!!

Çà mériterait peut-être un peu plus d'analyse .... je traiterais cela dans un prochain billet :)


.

1 commentaires

  1. AmarSoft  

    bon courage j'attends le prochian :)

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)