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 :)


.


Un petit billet annonce / promo / pub :)

C'est pour signaler un nouveau portail " qui visera tous ce qui tourne autours du voyages, des métiers liés à ce dernier, du tourisme et surtout de la destination Algérie" .... c'est www.voyageralgerie.com

Il a l'ambition de devenir un espace fédérateur des activités liées au tourisme et au voyage .... souhaitons bonne continuation et pleine réussite à cette initiative :)

En plus du portail Web, on a droit aussi à un blog : http://voyages-algerie.blogspot.com

Enfin, l'initiateur du projet est Karim Khelouiati ... alias ktalgerie :)


.


On ces temps de prolifération de malwares et d'attaques de tous type, de l'attaquant pro déterminé au newbie oisif, on n'a pas le temps de scruter toutes les traces réseaux ou l'ensemble des logs ... on a plutôt besoin d'avoir une vue plus large sur le trafic pour déterminer après s'il y a lieu d'aller plus en détail dans un flux précis.

Il y a plein d'outils pour faire ça, et chacun apporte son petit plus.
Je vais commencer l'essai et le test de plusieurs outils (analyse flux et autres) et je vais en faire des billets sur le blog comme aide mémoire pour moi ... mais ça peut intéresser d'autres peut-être.

Le premier outil (application python) que je suis entrain de tester est Honeysnap

Alors comme fonctionnalités, on trouve par exemple (selon leur site) :

  • Packet and connection overview.
  • Flow extraction of ASCII based communications.
  • Protocol decode of the more common Internet communication protocols.
  • Binary file transfer extraction.
  • Flow summary of inbound and outbound connections.
  • Keystroke extraction of ver2 and ver 3 Sebek data.
  • Identification and analysis of IRC traffic, including keyword matching.
Assez intéressant ...

Installation :

- Récupération des paquets pré-requis (s'ils ne sont pas encore là) :
python2.(votre_version)-dev (apt-get)
libpcap0.8 libpcap0.8-dev (apt-get)
pypcap (lien sur la page de l'outil ... mais )

Pour pycap, le package proposé et cité dans le fichier INSTALL me sort des erreurs lors de l'installation...probablement en raison de ma version python 2.6

Je fait alors un petit "apt-cache serach" pour voir s'il n'y a pas un dans les dépôts. Effectivement, il y a le packet "python-pypcap" et ça s'installe sans soucis.

- Récupération et décompression de l'outil pour *nix honeysnap-1.0.6.14.tar.gz,

- Dans le répertoire "honeysnap-1.0.6.14" on lance l'installation :

$ sudo python setup.py install

Encore des erreurs !! ben, c'est ça la compilation à partir des sources ... ça permet de faire travailler les neurones, nettement mieux que les clic suivant-suivant :)

Voyons où est le problème :

Ha oui, toujours le problème de la version de python. Dans le fichier "ez_setup.py" il parle de la version "0.6c7" pour les "setuptools", et comme ma version est 2.6, il ne va pas le trouver, à la place il y a le "0.6a7"... changeant le fichier en conséquence.

Ok, ça passe .... MAIS encore des erreurs .... j'aime ça :)

Cette fois l'erreur est la suivante :

"File "/tmp/easy_install-LisPo7/dpkt-1.6/dpkt/bgp.py", line 678
self.failUnless(c.as == 65215)
^
SyntaxError: invalid syntax"
Invalide syntaxe ?!! si c'était moi qui a codé ça je comprendrais :)

Là, c'est carrément le "au secours google" .... et après quelques minutes je trouve ce lien , où on explique que depuis la version 2.6, "as" est un mot réservé du langage python et qu'il faut le changer en "asn" dans le fichier "bgp.py" qui est dans le package "dpkt-1.6.tar.gz"

OK, comme le package est toujours avec la "mauvaise" syntaxe, je récupère le package en local et je fait le search / replace qui va bien dans le fichier bgp.py et je sauvegarde les modifs
(pour mémoire, les lignes à modifier sont 143, 404, 431, 678 et 715)

Mais, il ne faut pas oublier de modifier le fichier "setup.py" et de mettre au lieu de "http://dpkt.googlecode.com/files/dpkt-1.6.tar.gz" le chemin local "file://dpkt-1.6.tar.gz" (mettre le package dans le répertoire de l'outil honeysnap)

Ouf .... enfin ça s'installe et ça s'exécute :

$ honeysnap --version
honeysnap 1.0.6.14

Utilisation :

En suivant le fichier "USAGE", on peut tester les fonctionnalités qui nous intéressent (j'utilise une capture de test récupérée ici)

On peut voir par exemple les flux entrant ou sortant d'un certain host, les requêtes DNS qu'il a initié, l'extraction de data (ftp, telnet, http...)

C'est un outil à utiliser dans d'autres scripts pour l'analyse des flux et de l'activité réseau.

Bonne analyse ... les flux sont si passionnant :)


.

J'apprends à travers le billet de freefoxtv que le site d"Algérie Telecom est inaccessible, mais des commentaires disent qu'ils peuvent y accéder sans souci

Alors j'ouvre un onglet en mettant www.algerietelecom.dz .... ça marche !
Mais comme il n y a pas de fumée sans feu, et que BoF ne fume pas de joins (à ma connaissance :) ) , je me dit qu'il y a peut-être un truc lié à la résolution DNS.

Faisant alors les choses selon les règles de l'art.

Interrogeons directement un serveur root, avec l'option "trace" activée de dig, comme ça on va voir tout le chemin de la résolution DNS :

$ dig +trace @B.ROOT-SERVERS.NET www.algerietelecom.dz

; <<>> DiG 9.5.1-P2 <<>> +trace @B.ROOT-SERVERS.NET www.algerietelecom.dz
; (1 server found)
;; global options: printcmd
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
;; Received 492 bytes from 192.228.79.201#53(192.228.79.201) in 246 ms

dz. 172800 IN NS NS3.NIC.FR.
dz. 172800 IN NS DECST.CERIST.dz.
dz. 172800 IN NS CASBAH.ELDJAZAIR.NET.dz.
dz. 172800 IN NS NS-DZ.RIPE.NET.
;; Received 245 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 186 ms

algerietelecom.dz. 86400 IN NS dns-1.djaweb.dz.
algerietelecom.dz. 86400 IN NS dns-2.djaweb.dz.
;; Received 118 bytes from 193.0.12.4#53(NS-DZ.RIPE.NET) in 57 ms

www.algerietelecom.dz. 86400 IN A 213.140.56.5
algerietelecom.dz. 86400 IN NS localhost.algerietelecom.dz.
;; Received 112 bytes from 193.251.169.166#53(dns-2.djaweb.dz) in 99 ms
Alors on a l'adresse IP du site : 213.140.56.5
On a aussi les serveurs DNS répondant pour le domaine algerietelecom.dz : les DNS 1 et 2 de djaweb.

Mais, un truc bizarre est là (ce qui est en rouge) : on nous dit aussi que le serveur DNS autoritaire d'algerietelecom est localhost.algerietelecom.dz

J'espère que localhost ne veut pas dire pour les gens d'AT ce qu'il veut dire pour tout le monde : un serveur local à la machine, inutile d'aller sur le réseau, tout est en local.

Vérifions :

$ host localhost.algerietelecom.dz
localhost.algerietelecom.dz has address 127.0.0.1

Ok. Si un résolveur DNS client veut connaître l'@IP d'un site dans le domaine algerietelecom.dz, il devra voir du coté des serveurs DNS de djaweb ou de ce localhost ... ce dernier va tout simplement renvoyer la balle au client en lui disant cherche dans ton serveur local (127.0.0.1) !!!!

J'ai l'habitude de voir des configurations bizarre, mais là vraiment chapeau !

Conclusion, si vous avez de la chance, les serveurs de djaweb vous répondent, sinon le serveur d'AT vous dit que la réponse est chez toi :)

Je ne sais pas comment la mise à jour des enregistrements et les transferts de zones sont fait entre les serveurs de djaweb et celui d'AT, mais ils risquent gros en termes d'accessibilité avec ce type de config.

Et quand je vois le reste des informations dans la configuration de ce serveur autoritaire localhost, je me dit que les administrateurs devront relire les guides de déploiement d'un serveur DNS !


.

en flag Read it in english with google

Bien que la plupart de mes lectures et mes flux RSS sont sans relation avec l'actualité algérienne des TIC, quelques fois je fait le parallèle. C'est le cas avec le billet concernant les différents états par lesquels passe une équipe de sécurité.

Ça concernait la poste.dz .

Et c'est toujours leur cas, ainsi que celui du quotidien d'oran encore down, qui me vient à l'esprit en lisant ce billet "8 reasons why website vulnerabilities are not fixed"

Je fait ici une compile / traduction des raisons citées dans le billet et même dans les commentaires (c'est pourquoi j'ai attendu 2 semaines depuis la 1ère lecture du billet), et l'ordre n'est pas important :

1- personne dans l'organisation ne comprend ni est responsable de la maintenance du code;
2- les fonctionnalités sont plus prioritaires que les correctifs de sécurité;
3- le code affecté est la propriété d'une boite externe non joignable;
4- le site web devra être remplacé incessamment;
5- le risque d'exploitation est accepté;
6- les solutions correctrices rentrent en conflit avec l'utilisation métier;
7- les exigences de conformité ne requièrent pas la correction;
8- personne dans l'organisation n'est au courant, comprend ou donne de l'importance au problème;
9- manque de prioritisation du problème (sévère, critique, mineur...)
10- les solutions de scan de vulnérabilités sont trop chères
11- l'organisation ignore les bonnes pratiques de sécurité applicative et essaye de corriger à sa manière;
12- ils ne savaient pas qu'il existe des applications dedans :) ;
13- manque de budget pour apporter toutes les corrections;
14- le risque est réduit par l'utilisation de firewall applicatifs;
15- c'est une fonctionnalité, pas une vulnérabilité !!! ;
16- l'application est en php :) ;
17- nos utilisateurs sont assez bête pour pouvoir exploiter ça :)

Belle liste et plein d'excuses. Dans certains cas, il y en a qui accumulent plus d'une :)


.

en flag Read it in english with google

Beaucoup de monde sont maintenant au courant que le site du Quotidien d'Oran est inaccessible, avec un beau message "Forbidden". C'est suite à un défacement que le site est "en panne". On apprend (au moins moi) de la même source (le blog de Amar) que le site de la société iAlgerie "fournisseur de services Internet" a été défacé (actuellement nettoyé et en marche).

En visitant les deux sites (quotidien d'oran et ialgerie) et grâce aux add-on FireFox je remarque déjà qu'ils sont hébergé chez le même prestataire suisse NexLink. Et avec un autre add-on, je vois que c'est pratiquement la même adresse IP (80.86.200.143)... de l'hébergement mutualisé sûrement.

Confirmant ça encore plus avec l'option de recherche par @IP de live.com :

search.live.com/results.aspx?q=ip:80.86.200.143
(on pourrais faire la même chose en ligne de commande si l'outil est publié par son proprio ;))

Beaucoup de sites Algériens, le Quotidien en premier.
Je parie que le choix de l'hébergeur émane de la boite ialgerie....le whois sur quelques domaines le confirme (lequotidien-oran.com par exemple) :

Administrative Contact:
Sarl iAlgerie
Sarl IAlgerie
108, Cite Hosn El djiwar -USTO-
Oran, 31000
DZ
+213.41530727
(fax: +213.41530729)
ialgerie@gmail.com


Alors, incompétence de l'hébergeur ? de la boite algérienne (qui offre de la sécurité aussi) ?
Sans éléments concrets inutile de me prononcer ... mais quelques indices me laissent penser que ceux qui se rencontrent se ressemblent !


.

en flag Read it in english with google

Apparemment, on est devant une vague de défacement des sites Algériens. C'est une situation à la fois pathétique et normale :)

Normale dans le sens où l'expérience des administrations et des entreprises algériennes dans le domaine de la sécurité est au mieux au stade de la découverte, sinon de l'ignorance totale .

Mais ce qui est pathétique c'est l'image que donne nos sites dz. De simples "défaceurs" arrivent à ridiculiser un site comme poste.dz

Enfin, ce qui m'interpelle et me dérange réellement c'est un sentiment que ces "script-kiddies" sont manipulés par d'autres groupes non algériens. Ceux-là sont surement plus expérimentés et probablement plus compétents.

En lisant leurs commentaires sur certains forums et blogs (surtout celui d'Amar), il m'a semblé qu'il sont assistés dans leur attaques par des "copains" (chat, forum ou même implication directe).

Jusqu'à là ça ne parait pas assez grave, mais quand les services sur Internet seront introduits dans notre pays (les e-trucs)....et ça ne va pas tarder ... à ce moment là, ces groupes "pros" engageront des actions de cybercriminalité ... et nos "super-hackers" made in Algeria seront les bouc-émissaires malheureux.


.

Inscription à : Articles (Atom)