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..."



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.


.

en flag Read it in english with google

En lisant un billet sur le blog de Richard Bejtlich où il fait une intéressante réflexion sur les différents stages ou états par lesquels passe une équipe de sécurité, je me suis demandé où on placerais l'équipe de la poste.dz (si équipe de la sécurité il y a).

Il défini 7 états :

1- Ignorance : c'est l'inconscience totale .... sécurité ? heu ... ça veut dire quoi ce truc ?

2- Déni : les problèmes de sécurité, c'est pour les autres ... nous on est clean

3- Incompétence : on est conscient ... mais quoi faire et par où commencer

4- Héroïsme : personne ne bouge ... on va régler les problèmes

5- Capitalisation : on est bien lotis et on a les ressources pour faire face

6- Institutionnalisation : la sécurité n'est plus le problème des seules spécialistes .... c'est notre problème nous les managers

7- Spécialisation : on sait exactement quoi faire, quand et pourquoi le faire ... on peut même assister les autres


D'après vous, vous placeriez la poste.dz où ?!!!

Moi, c'est entre le 2 et le 3


.

en flag Read it in english with google

Apparemment il y a un petit jeu entre les admins du site web de la poste et des "hackers" (des algériens probablement).

Alors pour moi, d'un coté, il y a des admins qui ont vraiment de sérieux soucis (c'est la 2ème fois) soit techniques ou organisationnels, et de l'autre, des individus en manque de gloire et avec une surprenante perception de la justice.

Je ne connait pas les admins de la poste, alors ça serait injuste et immorale de les juger en tant que personnes. Mais ce qui est sûr c'est le fait qu'au niveau de cette administration on ne sait pas quoi faire en termes de sécurisation, ou plus grave encore, on s'en fiche.

Quand je lis les propos du directeur de communication d'Algerie Poste, je suis un peu surpris !! Essayer de banaliser cet incident de cette manière, en disant que le site n'est pas vraiment opérationnel est du n'importe quoi...vaut mieux se taire.

Maintenant sur le plan technique, il parait que le démenagement du site sur un nouveau serveur n'a pas été un succés. J'ai voulu voir sous quelle plateforme est hébergé le site en utilisant le service What's that site running de netcraft :









Ok, on passe de Solaris vers Linux comme OS .... et d'Apache vers Netscape-Enterprise comme service Web !!!!

Tiens tiens....Netscape-Enterprise ! ça me rappel un constructeur Français qui propose ceci avec ses serveurs... BULL et comme par hasard c'est cette boite qui "assiste" Algérie Poste "pour la Sécurisation de ses Sites de Production Informatique"..... ça coince vraiment quelque part :)



.

Inscription à : Articles (Atom)