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



Alors, sans détours .... je compte fermer ou geler (pour très très longtemps) mon blog
.



Pourquoi je dis ça ?


Même si mon blog n'a qu'une audience modeste, pour moi, c'est une audience fantastique, surtout ceux que j'ai connu un peu plus.

Ce dernier billet est fait par respect aux personnes, auxquelles j'ai une grande estime, qui suivaient mes articles, qui commentaient ou même lisaient sans intervenir.

A travers ma présence sur le Web (Mon blog, blogosphère algérienne et Forumdz ), j'ai eu la chance de connaitre des personnes formidables, même si dans la vrai vie on ne se connait pas.

Alors, pour toutes ces personnes, un Grand Merci ... et c'est à eux que la suite du billet est destinée.

Pourquoi j'arrête le blogging ?

Mon problème est simple. C'est la somme des éléments suivants, avec un poids décisif du dernier :

1- Le blogging pour moi n'est pas quelque chose de fondamental. Je n'ai pas d'image à promouvoir pour se connaitre ni d'offres de services à vendre.

Je le faisais pour le plaisir et comme moyen pour essayer de contribuer à ma manière à certains idéaux auxquels je crois.

2- J'ai une habitude (que je considère bonne) de me remettre en cause, au moins, une fois par an.
Un élément que j'ai considéré, est le temps passé sur chaque chose dans ma vie, en fonction de son importance et sa priorité.
Et comme la ressource "temps" n'est pas infinie, il faut faire des choix ... c'est l'histoire de la spécialisation en plus large :-)

La conjoncture a fait que depuis le début de septembre et jusqu'à ces derniers jours, j'étais vraiment occupé par mon boulot et par des engagements familiaux ... concrètement, des choses plus prioritaires que le blogging !

3- Bien que le fait de bloguer ne me prend pas un temps énorme, c'est quand même un certain temps d'occupation. Une option serait de continuer le blogging en fonction de ma disponibilité ... mais je n'aime pas faire les choses à moitié !

4- Je parlais de la remise en cause annuelle dans le 2ème point. Cette fois, c'est plus que ça.
Je me suis engagé dans une voie d'efficacité. Faire une chose à 100% et plus efficace que 10 choses à 30%.

Je me suis donné un objectif pour la vie ... je l'avais avant , mais pas aussi clair, aussi précis et aussi réfléchi que cette fois.

Le blogging n'est tout simplement pas du tout dans la lignée de mes plans pour l'avenir.
Il ne m'aidera ni dans ma communication, ni dans mes réflexions dans mes plans .... et comme tout ce qui sera inutile sera éliminé ... je le fais !

Ce dernier point peut paraitre pas clair .... c'est normal, il y a des petits détails personnels que je ne peux pas partager ici.

Et après ?

- Je continuerais de suivre, tant que possible, les blogs algériens que je suivaient avant, mais sans intervenir.

- Je répondrais au commentaires sur mon blog, mais uniquement pour ce dernier billet ... désolé.

- Ma boite au lettre salahnadir restera toujours active inchallah, et je continuerais à communiquer avec mes amis "virtuels" :-)

- Pour les mêmes raisons, je n'interviendrais plus sur forumdz ... désolé encore.


Bonne chance à tout le monde et encore Merci .... et on ne sait jamais, dans une conf, un séminaire, une association ... souriait quand on vous dira SALAM :-)


Allez .... SALAM :-)

.

J'apprends sur le blog de Karim que l'ARPT (Autorité de Régulation de la Poste et des Télécommunications), pas le MPTIC comme indiqué sur le titre de son billet, lance un Appel d'Offre National et International pour, je cite : Assistance à la mise en œuvre de « la certification électronique en Algérie».


Alors, je ne sais pas pour vous, mais moi, ça m'a fait un peu bizarre cette histoire. Pourquoi ?

Comment a-t-on déjà donné à une telle entité la lourde tâche de gérer les certifications électroniques.

Je ne suis pas juriste, mais bon, quand je lis dans le Décret exécutif n° 07-162 qui traite du "régime d'exploitation applicable à chaque type de réseaux, y compris radio-Èlectriques et aux différents services de télécommunications", je trouve que c'est l'ARPT qui délivre des autorisations pour "l'établissement et l'exploitation [...] des services de certification électronique".

Comment ?

Juste derrière, on trouve : "L'autorisation des services de certification électronique est, toutefois, assortie d'un cahier des charges fixant les droits et les obligations du prestataire du service et de
l'utilisateur"

Et ça là justement, en partie, le sujet de cet appel d'offre : construire LE cahier des charges.

Clairement, il sont responsable de "Mettre en place un modèle de confiance national avec ses composantes réglementaire, organisationnelle et technique" (c'est dans l'appel d'offre), mais ne savent pas DU TOUT comment faire, sinon, pourquoi un appel d'offre ?

Quand on a un minimum de compétence dans un domaine, et qu'on veut apprendre des expériences des autres, chose tout à fait légitime et louable d'ailleurs, on fait des missions de prospection, des réunions de consulting, des formations peut-être, mais pas un appel d'offre quand même !!! A moins que l'on veut une solution clé en main. Mais dans ce genre de choses, ça n'existe pas.

Je suis presque sûr que ça va coincer grave, et dire que les e-trucs vont se baser sur ça !!!

J'aimerais tant avoir tort !

.

Je commence une série de billets mensuels dans lesquels je donne les 7 meilleurs liens que j'ai apprécié. Ça peut être une étude, un article ou une discussion.

Pour ce mois d'août, j'ai apprécié et appris de ces liens ... peut être que ça vous servira aussi :)

1- Quand on parle de connaissance et d'apprentissage, un site vient directement à l'esprit, et c'est devenu même une référence (quoique c'est discutable) ... c'est Wikipedia ... je ne vous apprend rien là.

Par contre, qui connaît comment ça marche en interne cette e-encyclopédie ?

La fondation Wikimedia met justement en ligne et en accès libre un site fort intéressant : wikitech.

Toute information technique (configuration, guides, how-to ....) concernant le fonctionnement quotidien du site est là : systèmes, réseaux, services ... tout vraiment tout.

Allez-y : http://wikitech.wikimedia.org/view/Main_Page


2- Dans un autre registre, une discussion sur la mailing list DailyDave d'ImmunitySec (développement d'exploits et pentest) est lancée par un gros troll : "Security people are leaches" (Les gens de la sécurité sont des parasites !!! )

En gros, les développeurs (ceux de Linux dans ce thread) bossent et sont les vrais héros ... les autres ne font que cracher sur le travail des autres et ne produisent rien ... très intéressant à lire :)

Et en milieu de thread, le gars de ImmunitySec, Dave Aitel (rejoint le NSA à 18 ans apparemment), lance ceci :

" Right now, Linux kernel security is 5 years behind Windows"
En ce moment, la sécurité du noyau Linux est 5 ans derrière Windows ... c'est ça, j'ai bien compris ?! :)


A lire : http://lists.immunitysec.com/pipermail/dailydave/2009-July/005823.html


3- En parlant de Linux, la "linux foundation" justement vient de publier un rapport (pdf) dans lequel on apprend qui contribue vraiment à l'écriture du code. Ceux qui croyaient dans le mythe du développeur bizarre et isolé devront revoir leurs conclusions. A titre d'exemple et par ordre de classement :

  1. Red Hat: 12.3%
  2. IBM: 7.6%
  3. Novell: 7.6%
  4. Intel: 5.3%
  5. Independent consultant: 2.5%
  6. Oracle: 2.4%
  7. Linux Foundation: 1.6%
Le rapport : http://www.linuxfoundation.org/publications/whowriteslinux.pdf


4- Revenons à la sécurité, le monde des parasites, cette fois les vrais ... ou une espèce cousine si vous croyez au troll précédent :)

Une article de darkreading fort intéressant sur les stratégies des développeurs de malwares ... c'est de pire en pire (ou de mieux en mieux :) )... du classique code ravageur, aux attaques ciblées qui "savent" exactement quoi chercher comme information dans le PC compromis, en passant par les codes qui essayent de compromettre la station de l'analyste quand ils détectent qu'ils sont sous environnement contrôlé ... et enfin, les botnet (gros réseaux de PC infectés) qui attaquent le réseau de la firme ou l'analyste qui essayent de se connecter au serveur de commande et de contrôle (C&C) du botnet !!

C'est ici http://www.darkreading.com/security/client/showArticle.jhtml?articleID=219400756


5- Maintenant, analyser un flux généré par un malware peut se faire en utilisant des captures soumises bénévolement par des contributeurs. Ce qui nous amène ou dépôts de captures (de malware ou autres), et le plus connu est pcapr.

De plus, Mu Dynamics labs vient de mettre en place un projet regroupant et indexant une grande quantité de captures (15 G = 26,3 millions de paquets)

A vos labs, c'est ici : http://www.pcapr.net/forensics


6- Sortant de ce monde et voyant cette étude qui devra apparaître dans "Proceedings of the National Academies of Science".

On apprend que le multitsaking (faire des choses en parallèle) nous rond au contraire moins efficace en divisant inutilement notre attention. Mais bon, on savait que le multitasking n'est qu'un mythe

L'article explicatif d'arstechnica est ici :
http://arstechnica.com/science/news/2009/08/multitaskers-beware-your-divided-attention-comes-at-a-price.ars


7- Donc, il faudra fixer des priorités, et donner l'attention, l'effort et le temps nécessaires à chaque action. Et qui dit priorités, dit objectifs ... et nous y sommes avec le dernier lien que je suis entrain de résumer et traduire pour en faire un billet prochainement .

Comment définir et choisir ses objectifs d'une manière efficace avec la méthode GROW = Goal Reality Options Way

C'est ici http://blog.iqmatrix.com/mind-map/grow-your-goals-using-grow-model-mind-map


Bonne lecture ... tout est lié, n'est ce pas ? :)


.

Après le billet concernant la nécessité de choisir une spécialisation et les commentaires qui ont suivi, un autre aspect mérite l'attention à mon avis :

Quoi lire comme articles ou livres et quelle documentation étudier et garder chez soi ?!

L'idée de faire ce billet m'est venue après un échange d'émail avec zendyani (dans lequel il attirait mon attention sur ma bourde concernant le prix Nobel de math ... qui n'existe pas) me parlant de la grande quantité de doc de sécurité qu'il conserve.

C'est aussi mon cas, des répertoires "sec", "security" et "secure", d'autres "to_read", "to_test" et j'en passe. Chaque fois que je tombe sur un article, une étude, une vidéo ou quoique soit concernant la sécurité, je le prend immédiatement ... sans le lire ou le voir dans la majorité des cas ... et c'est là le problème !!

En fait, dans mon cas, ce n'est pas lié uniquement à la sécurité ou même à l'informatique en général ... c'est plus une envie forte de lire et d'apprendre tout ce qui tombe sous mes yeux, de l'histoire et la politique, jusqu'aux théories récentes sur la physique quantique, en passant par les concepts de management et d'économie.

A première vue, c'est quelque chose de bien ... mais le problème est, comme indiqué dans le billet cité au début, il faut faire des choix : la connaissance encyclopédique n'est plus possible, en plus, ça ne fait pas manger ... et en même temps, la spécialisation nécessite actuellement de consacrer un temps fou pour apprendre chaque jour et aussi pour rester à jour (veille technologique).

Comment faire alors ?

Personnellement, j'essaye d'adopter la démarche suivante (en supposant que le choix de spécialisation a été fait) :

1- Étudier (pas lire uniquement) les ouvrages de référence de la spécialité.

2- Suivre des formations de haut niveau et acquérir les certifications correspondantes (dans la mesure du possible).

3- Identifier des experts reconnus dans la spécialité, lire leurs études et suivre leurs blog / site.

4- Pratiquer, tester et évaluer les outils / solutions (on peut assimiler ça à l'étude de la doc).


Vous l'avez compris, si vous voulez se spécialiser, et le rester surtout, il faudrait se débarrasser de beaucoup de livres et de doc, qu'en fin de compte vous ne lirez jamais ... pour moi personnellement, c'est difficile, mais c'est un choix à faire .

Tout ça, ne veut pas dire bien sûr, qu'on ne lira plus rien en dehors de notre spécialité ... chacun éprouve le besoin d'élargir ses horizons par d'autres lectures .... mais ça sera plus des lectures de détente ou de survol, qu'une vraie étude !!

A la fin, pour présenter graphiquement mon idée, voici deux "schémas" que j'ai réalisé, résumant ce que je viens de dire :

L'expertise pointue est à l'autre bout de la "connaissance encyclopédique"


(clickez sur l'image pour l'agrandir)

Chaque fois qu'on investi du temps et de l'effort pour acquérir des connaissances de spécialisation, nos connaissances "générales" stagnent ou diminuent même !



Chaque fois qu'on descend en profondeur, la surface de contact se rétrécie

(clickez sur l'image pour l'agrandir)

La même idée exprimée autrement. Pour pouvoir bien "percer" (au sens propre et au sens figuré), on doit minimiser au maximum les frottements (autres lectures) ... et la tête doit être "pointue" :)

Les domaines cités ne sont que des exemples, sans aucune signification de l'ordre ou des relations entre eux.


.

Et oui, le temps passe trop vite ... le dernier Ramadan parait comme si c'était il y un mois !!

Demain, inchALLAH, ça sera le début de ce mois que j'adore tant ... pour une moi, c'est quelque chose qui règle toute l'année à venir !



Pourquoi ?

1- Avec mes dires et faits ravageurs au quotidien durant toute l'année, j'essaye de me corriger et de m' "élever" durant ce mois.

Dans ce mois, les liens les plus solides avec l'espèce animale sont rompus.
Toutes les conditions sont réunies pour savourer pleinement la partie de nous même qui nous confère cette particularité parmi les autres créatures.
Et puis, le plus important, ALLAH nous facilite à un point extrême l'accès à cette nouvelle façon de vivre.

2- La discipline ... oui, si en veut réussir dans la vie, et après la vie, si on veut réaliser nos ambitions et atteindre nos objectifs ... si on veut tous ça, ce n'est pas en se levant à 11h et "matant" la télé ou le web à longueur de journée (et de nuit) ... non, croyez moi, personne n'a réussi avec ce programme !

On doit donner de l'importance à chaque seconde dans notre vie, on doit aussi respecter nos "priorités" ... tous cela nécessite de la discipline individuelle ... certes, ce n'est pas facile, mais bon, il faut savoir ce qu'on veut !

Pour moi, ce mois est l'occasion idéale pour me remettre en cause et se créer des habitudes ... se créer une "discipline".

3- Me découvrir et découvrir les autres !

Quand on se prive de boire et manger (et en Août), je crois que notre vraie nature se dévoilera, et là, c'est la mesure exacte de nos personnalités, sans masques ni calmants.


Je mettrais ici à la fin mon programme / objectif que j'essaye de respecter chaque année, avec des hauts et des bas :

- Début journée : shour 30 min avant athan
- Salat sobh à la mosquée

- lecture de versets du Coran (30 mn)
- lecture mails / articles (1h)

- direction boulot (début 09 h)
- Salat dohr au boulot + 10 min lecture Coran
- fin boulot 16h et trajet 1h environ
- Salat asr à la mosquée en trajet (ça dépend où)

- Petite sieste tardive (30 mn)

- Petits achats éventuels

- Lecture versets Coran + Salat maghreb à la mosquée

- FTOUR
- Salat icha et tarawih à la mosquée

- retour et éventuellement voir quelques émissions ... sinon direction le lit

Le week-end, c'est la même chose partout, à part remplacer boulot par les courses / trucs à faire et sortie des enfants.


.

Les sciences et technologies contemporaines ne permettent pas une connaissance encyclopédique comme il fut le cas il y a des décennies.

Si on veut avoir une place, et surtout la garder, on doit se spécialiser.
Le problème est que le degré de spécialisation ne cesse d'augmenter.

Si je prend le domaine de la sécurité informatique, déjà c'est une spécialisation de la discipline "informatique". Notons au passage que quelqu'un qui se considère comme informaticien généraliste est un dinosaure ... au mieux, un collectionneur de termes à la mode :)

Mais, parler de "spécialiste en sécurité informatique" tout court est aussi imprécis à mon avis ... si j'emprunte la terminologie des professions médicales, je dirais plutôt "généraliste en sécurité informatique" !!

Être un spécialiste ça sous-entend une certaine maîtrise ... alors, on maîtrise quoi ?

- la sécurité des réseaux ? quelles infrastructures ? quelles technologies ? ...

- la sécurité des systèmes ? lesquelles ? ....

- celle des applications ? toutes ? dev ou déploient et config ? ....

Et l'administration et le monitoring de la sécurité (SIM, SIEM, NSM ... ) ?
Et le reverse engineering ?
Et l'audit ou le pentesting ?
Et l'organisation de la sécurité (ISO2700x, SMSI...) ?

Ça serais vraiment exceptionnel de maîtriser vraiment toutes ces "sous-spécialisation" à la fois !!!

Ceci m'amène au titre du billet : si on veut réussir dans le "domaine" de la sécurité, on doit choisir une spécialisation pointue et se concentrer sur elle, sans oublier de garder le contact avec les autres bien sûr ... parce que tout est lié !

Comment et quoi choisir ? et ben c'est propre à chacun !

Les connaissances déjà acquises, l'environnement actuel de travail, les aspirations ou ambitions de la personne, les débouchés ou la demande du marché et même l'âge .... tout ces paramètres peuvent influencer le choix final.

Pour ma part, en reprenant les concepts du "développement personnel", je dirais que 2 choses importante sont à considérer :

1- le VOULOIR : il n y a pas de réussite sans enthousiasme, sans amour de ce qu'on fait
2- le POUVOIR : il faut avoir les compétences et les prédispositions nécessaires (intellectuelles ou autres)
C'est vrai qu'avec de la persévérance et de l'effort on peut arriver à faire des miracles ... mais bon, avoir un prix Nobel en Maths quand on est de formation en sciences humaines est un peu exagéré ... visé le prix de littérature serait plus réaliste !

Enfin, pourquoi je dis tous ça ?

Une, j'ai discuté dernièrement de ça avec des amis, en ligne, ou de visu

Deux, je viens de lire le titre d'un billet sur ça, avec pleins d'autres liens très intéressants apparemment ... je vais lire ces articles et voir ce que les autres pensent :)

Et trois, je suis en plein processus de choix ... je voudrais passer du stade de "généraliste expérimenté" à celui de vrai "spécialiste" :)

EDIT : comme me l'a fait remarqué zendyani par émail, le prix Nobel en Math n'existe pas ... et dire que personne (à part lui) n'a relevé ça. Ça me fait du chagrin, parce que là c'est sûr, vous ne faites que "survoler" ce que je raconte :)
.


J'entamerais, dès ce mois, la publication d'un billet mensuel pour refaire la lumière sur les billet anciens ... avec le temps, ils perdent de la visibilité au profit des derniers ... même moi j'ai tendance les à oublier :)

Je commence maintenant, parceque pratiquement, c'est au mois d'aout 2008 que j'ai commencé à bloguer régulièrement.

1- google.dz ...... patientez, le Cerist est en vacances

Le premier billet traitait du lancement maladroit de google.dz ... l'indisponibilité du serveur DNS gérant ce domaine au niveau du Cerist, ajoutés à cela, des aléas fréquents de les configurations de ce serveur .... et le comble, le problème revient de temps en temps (pour ne pas dire persiste) jusqu'à maintenant.

2- Wissal du Cerist....entre securité et convenance

Après, j'ai parlais du cas de la messagerie Wissal du Cerist. Leur problème (parmis d'autres plus graves) est qu'ils t'envoient un message d'erreur en fonction de l'existence ou non du compte ... ce qui est vraiment inutile et dangereux en même temps .... et apparement il ont reglé le problème !

3-Etat des DNS Algériens....part I

Enfin, j'abordais la première partie d'une étude sur l'état de serveurs DNS algériens, dans ce billet, ceux des universités et de quelques ISP.

J'ai testé les numéros de version, la récursivité ainsi que la vulnérabilité aux attaques de cache poisoning (Dan Kaminsky).

.

.

Juste un petit billet annonce / pub :)

C'est le nouveau blog de mon ami tixxDZ ...et le premier billet n'est rien d'autre q'une annonce de découverte de vulnérabilité dans Mplayer et VLC !!!

Vous l'avez bien compris, on a un vrai chercheur en sécurité en Algérie.

Comme je l'ai dis à certains, je considère que dans la vie, il y a 2 catégories de personnes : les bâtisseurs et démolisseurs (équivalent en arabe moslihoune et moufssidoune) .... et là, c'est un exemple d'un bâtisseur ... un vrai.

Maintenant, je peux me vanter de te connaitre et d'avoir échangé quelques mails avec toi :)


.

Il y a quelques jours, certains médias en ligne font état de la découverte "accidentelle" d'une opération de préparation des terminaux BlackBerry détenus par les clients de l'opérateur émirati Etisalat pour pouvoir, le temps voulu espionner leur communications ... rien que ça !!

En fait, l'histoire commence quand des clients remarquent que leurs batteries se déchargent rapidement d'une façon inhabituelle, et que ceci arrive juste après réception d'un message de leur opérateur signifiant qu'il y aura installation d'un "patch" (par push WAP) en disant :
"Etisalat network upgrade for BlackBerry service. Please download to ensure continuous service quality."

Et comme il y aura toujours des casse-pieds qui veulent comprendre un peu plus que ce qu'on leur dit ... et ben ils ont posté sur un forum de support BlackBerry pour signaler leurs soucis ... en postant le "patch" ... qui est ... attachez-vous bien ... un simple fichier JAR (archive Java)...qui ne demande qu'à être analyser.

Et là, c'est inévitable, il y aura aussi toujours les "emmerdeurs" qui voient le mal partout ... et se font un plaisir pour décortiquer le tout .... et quand ce n'est ni obfusqué ni chiffré ni quoi que soit .... le plaisir est à 2 doigts :)

L'histoire fait le tour, et des pros se mettent de la partie ...et là encore on a le choix entre pleurer ou rire :

- Le serveur qui devait recevoir les petits "coucous" des terminaux qui ont installé le fameux patch ... n'a pas supporté la charge ... du coup, les terminaux essayent et réessayent pour le contacter ... ce qui tue les batteries :)

- Les chemins de l'archive ne donnent aucune indication (ironie)... parce que figurez-vous, un chemin du genre "com/ss8/interceptor" ne veut rien dire :) ... même si "SS8" est le doux nom d'une boite US qui se présente: "electronic surveillance solutions company that develops products that allow intelligence agencies to recognise, monitor, investigate and prevent criminal activity" .... en plus, elle n'est pas du tout inconnue dans la région ...mais pas du tout !

- Le code en lui même (qui est disponible ici) est très parlant :) ... on trouve même des trucs codés en dur ... du genre serveur où envoyer les trucs interceptés (http://10.116.3.99:7095/bbupgr), des émails ... et même des clés AES :) "aes_key_str = "EtisalatIsAProviderForBlackBerry"

Je vous invite à lire ces analyses ici , et encore par ici

Avant de terminer .... on doit rester objectif et noter que la "fonctionalité" est par défaut désactivée ...c'est déjà ça :) ... mais quand on décide que tel est "intéressant" ...un petit message contenant la commande "start" suffit :)


in9mv7wzxy


Ce matin, j'entends dans les infos que le Ministère de l'enseignement supérieur et de la recherche scientifique a mis à la disposition des nouveaux bacheliers un site web pour les orienter et aussi "pouvoir créer une boite au lettres électronique" .

Très bonne idée je me dis, alors je passe par le site du ministère (pas un modèle de design au passage) pour chercher ce nouveau site.

La seule chose que je trouve est ce message :
"Bacheliers 2009: Activez votre compte E-mail sur http://email.bac09.dz"

Ok, j'y vais pour voir ce service. Paf, une redirection sur un truc Google !!!

"Bienvenue sur votre service de messagerie Baccalauréat 2009, fourni par Google"

Je confirme ça avec une requête DNS :

$ nslookup email.bac09.dz
Nom : ghs.l.google.com

Address: 74.125.77.121

Aliases: email.bac09.dz, ghs.google.com


D'accord, je ne sais pas du tout c'est quoi ça, mais je présume que c'est une offre Google.
Puis, aucune indication comment accéder au compte ... mais là aussi, je présume que les nouveaux bacheliers le savent ... et surtout ne me dites pas non !!

Passé ça, je veux toujours voir le site lui même. J'essaye le www.bac09.dz

Maintenant, on revient sur le territoire national, le site est au Cerist : 193.194.77.195

Mais quand on revient à l'intérieur de nos frontières, on le fait vraiment à fond !!!!!!

Un site que je qualifierais de Web 0.00001 si pas moins !!! Un truc écrit en Word et copy/past sur une page web.

Et ne me parler surtout pas de la sécurité du site, on s'en fou !!!!

Vraiment pefffffffffff.


in9mv7wzxy

Tout le monde (ou presque) apprécie les services Google, en même temps, tout le monde s'offusque de l'hégémonie de Microsoft (qui commence à diminuer) .... mais Google, avec son approche et sa vision, n'est-il pas plus dangereux sur tout les plans : vie privée, sécurité, sécurité des nations même ?!!!

En lisant les news concernant le nouveau OS de Google, j'ai immédiatement pensé à une vielle vidéo sur Youtube : Epic 2014 ...qui reste, dans le fond, toujours d'actualité !





.

Si on fait abstraction des personnes qui font honte à notre pays ...

Si on n'oublie un petit peu (pour quelques minutes) que la "vraie" indépendance n'est pas encore gagnée (citez plus de 10 pays vraiment indépendant dans le monde !!!) .....

Si on contemple combien notre pays est beau et magnifique ...

Si on pense à la joie qu'à pu donner un ballon en cuir pour tout un peuple ....

Si on pense au gens (la plupart martyres) qui ont fortement crus dans ce pays ....

Enfin ... si on se permet un petit moment d'optimisme ....

..... on sentira MALGRÉ TOUT un amour profond pour notre pays.

Merci Karim (KT Algérie) et Freefoxtv pour le lien :)


Il y a quelques jours, mon lecteur RSS me ramène un article amusant sur le blog Zscaler : "les choses les plus importantes sur Internet ... de A à Z" :)

Celui-ci s'intéresse à ce que offre Google comme suggestions (le Google Suggest) quand on commence à taper une requête ... tout le monde connait ça.

Il nous donne la liste des suggestions pour les requêtes commençant par les lettres de l'alphabet ... et cela pour le ".com", parce que voyez-vous, Goggle vous sert en fonction de votre localisation !

Ainsi, une requête commençant par "s" donne, en première position :

"southwest airlines" pour le ".com"
"sncf" pour le ".fr"

... et je m'arrête là, parce que pour les autres ".ca", ".de" .... on ne nous propose rien !!

Bon, on me dira que c'est un truc qui fait parti de Google Labs ... expérimental ! ... OK :)

EDIT :

MARTANI Fakhrou
vient de me corriger concernant le fait que uniquement le "com" et le "fr" sont concernés par le service Google Suggest ... qui est sortie du laboratoire il y a longtemps déjà apparemment :)

En fait les autres localisations marchent aussi. Le problème venait de moi ... et de l'extension Noscript . Le javascript était activé uniquement pour le "com" et le "fr"... ce qui fait que les suggestions ne passent pas :)

Mais, même si les autres marchent ... le ".dz" reste muet :)

Thanks again Fakhro :)

.

Un thread sur forumdz avance que des problèmes ont survenus lors d'une tentative d'interconnexion de certains ISP algériens :

"L'histoire a commencé le mercredi 06 Mai 2009, le MERCREDI NOIR du NET en Algérie. Ce jour la, les principaux fournisseurs d'accès nationaux (Djaweb - AT, EEPAD, SLC, ARN - CERIST) ont tenté d'interconnecter leurs réseaux via ALGIX le premier point d'échange algérien.

Mais tout ne se déroule pas comme il a été prévu, le protocole BGP (mal maitrisé) a provoqué un effet avalanche sur tous les routeurs lors de la propagation des tables de routage. Résultats des courses : tout le réseau national s'écroule comme un château de carte et c'est le Blackout chez tous les FAIs!"

Alors comme ça, on a un GIX Algérien .... bonne nouvelle, bien que presque aucune information n'est disponible sur ce sujet.

Maintenant, y a-t-il eu vraiment un problème BGP ?

Comme le membre qui a affirmé ça (assilabox ... le membre, pas le routeur :) ) n'est pas du genre à balancer du n'importe quoi, alors il se peut qu'il y a eu vraiment problème lors de cette supposée interconnexion.

Et si ce cafouillage a généré du trafic de routage, on devra trouver des traces dans les endroits qui vont bien.

Avant de commencer, ne vous attendez pas à une analyse de spécialiste .... bien qu'ayant fait plusieurs années du réseau et suivi même quelques formations officielles Cisco, je ne me considère pas spécialiste.
Alors, s'il y a parmi les visiteurs un spécialiste ou quelqu'un qui connait un ... ça serait sympa de jeter un coup d'œil critique sur ce que j'avance.

Pour moi, être spécialiste signifie avoir de la maitrise. Et cette maitrise n'est possible qu'avec 2 éléments : les connaissances (assez de formations) et la pratique (années d'expérience réelle dans le domaine).

Commençons d'abord par trouver les "groupes" dans lesquelles "vivent" nos principaux ISP DZ. C'est ce qu'on appel des Autonomous System ou AS (système autonome).

Pour faire cela, des petites commandes whois sur des plages d'adresses connues pour chaque ISP peuvent suffire dans certains cas. Sinon, le net regorge de sites donnant ce type de données, le site robtex est un des bonnes pistes.

Après quelques manips, on a alors les résultats suivants :

Cerist = AS3208
Djaweb = AS33774
FAWRI = AS36947
TDA = AS21391
EEPAD = AS33783
SLC = AS36879

Maintenant, voyons si on trouve des traces de ce qui est arrivé.

Une des ressources les plus conseillées est le Routing Information Service (RIS) du RIPE NCC

Après essai des différents outils online, le service ASInUse me parait le plus utile dans ce cas. En fait, pour un AS donné, on peut voir les voisins (neighbors) avec les dates "first seen" et "last seen" dans les derniers 3 mois passés. Comme ça, on verra s'il y a des connexions qui sont apparues puis disparues.

Mais, il faut tenir compte que "One should note that the 'views' are from the perspective of our Route Collector in Amsterdam and its peers" ... une vue partielle en somme. En plus, je ne rapporte que ce que je considère lié à notre cas ... mais les liens sont dessus pour ceux qui veulent allez plus loin.

1- Cerist (3208)

AS33774 (Djaweb) du 2009-05-04 08:37:32 UTC au 2009-05-13 10:59:53 UTC

2- Djaweb (33774)

AS3208 (Cerist) du 2009-05-04 08:37:32 UTC au 2009-05-13 10:59:53 UTC
AS36947 (Fawri) du 2009-05-13 14:34:27 UTC au 2009-05-13 14:38:43 UTC
AS36989 (AnwarNet) du 2009-03-20 07:59:58 UTC au 2009-05-13 14:38:43 UTC

3- FAWRI (36947)

AS33783 (EEPAD ) du 2009-04-30 09:31:57 UTC au 2009-04-30 09:36:49 UTC
AS33774 (Djaweb) du 2009-05-10 08:06:11 UTC au 2009-05-20 15:59:44 UTC

4- TDA (21391)

AS36879 (SLC) du 2009-05-05 14:09:09 UTC au 2009-05-24 07:33:19 UTC

5- EEPAD (33783)

AS36947 (FAWRI) du 2009-04-30 09:31:57 UTC au 2009-04-30 09:36:49 UTC

6- SLC (36879)

AS21391 (TDA) du 2009-05-05 14:09:09 UTC au 2009-05-24 07:33:19 UTC


Il me parait qu'à partir du fin Avril 2009, et jusqu'au fin Mai, il y a eu une sorte de peering (Cerist - Djaweb, TDA - SLC, Eepad - Fawri) .... mais plus rien après.


.

Tout le monde s'est habitué à voir des "étoiles" quand il saisi son mot de passe sur un système, une application ou un site web.

Et ben, Jakob Nielsen appel tout bonnement à ne plus masquer les mots de passe et à les afficher en clair !

Attention, apparemment, ce n'est pas n'importe qui : co-fondateur du Nielsen Norman Group, ancien Ingénieur Sun Microsystems et auteur de plusieurs livres.

Il base son argumentaire sur le fait que l'apport en sécurité du masquage des mots de passe est négligeable par rapport aux problèmes qu'il induit.

Selon lui, d'une part, c'est rare qu'une personne se penche au dessus de vos épaules pour voir ce que vous tapez, mais d'autre part, masquer le mot de passe cause des erreurs répetées des utilisateurs, ce qui les fait, soit déserter le site en question (manque à gangner) ou choississent des mots de passe trop simple (dégradatoin du niveau de sécurité).

Vous voyez, ça ne manque pas de logique !

Et pour donner plus de crédibilité à cette idée, le célèbre cryptologue Bruce Schneier apporte son grain de sel on disant tout simplement "I agree with this".

Mais au-delà de cette idée et la polimique qu'elle peut génerer, cette histoire me rappel un billet que j'ai lu il y a quelques jours dans mon flux RSS. C'est une autre figure de la sécurité, Rich Mogull, qui fait une digression sur la nécessité en sécurité (et dans la vie en général) d'avoir une attitude "sceptique" envers notre environnement, et surout envers nos présumées "certitudes".

C'est en somme, être à la fois parano et d'un esprit scientifique !!

Difficile mode de vie à mener :)


.

J'apprends quelque part sur la toile qu'on a débattue de "l'expérience du e-commerce en Algérie" !!! Et je trouve un article sur Mobile Algérie qui reprend cette nouvelle.

Ha bon, on a de l'expérience dans l'e-commerce et on est même entrain de l'évaluer ?!!! Moi qui parlait de la nécessité de se préparer avant ... je suis dépassé par les évènements alors.

Ok, j'apprends alors par l'article qu'il "a été présentée, avant-hier à Alger, par le Touring club Algérie (TCA) et les promoteurs d'un site web de vente électronique, au deuxième et dernier jour d'une rencontre sur les expériences des pays du Maghreb dans le développement de la culture numérique".

Et que "Le directeur régional centre du TCA, Djamel Ramdani, a évoqué l'expérience menée par le Touring Club Algérie en matière de promotion du tourisme et de la destination Algérie à travers le site web de son organisme." ... où il soutient que "des réservations sont effectuées via le net au même titre que le paiement qui s'effectue à travers l'utilisation de l'Internet".

Intéressant tout ça. Je vais alors naturellement voir du côté du site de TCA pour comprendre comment ça se passe.

Déjà, c'est un domaine ".com" hébergé chez Amen en France ... mais bon, vu l'état du domaine ".dz", on peut comprendre.

Un site bien fait à première vue, mais ce qui m'intéresse c'est comment "faire de l'e-commerce" à partir de site.

L'onglet le plus parlant est "réservation"... réservons alors :)

On arrive à l'URL : http://touring-algerie.com/index.php/fre/shop/userregister

C'est du clair, pas de https malgré qu'on nous demande plein d'informations personnelles (nom, prénom,tél, émail...) !!! .... Après, on est devant un développeur qui manifestement ne sait pas (ou s'en fou) ce que veut dire contrôle des entrées :

Je met des chiffres pour les nom / prénom, des lettres pour le n° tél et le code postal....tout passe sans souci !!!

et la page me dit alors : "
Votre commande à été envoyée avec succès" ... (un "à").

Et après ? rien !!! et je cherche toujours le "e" du commerce.

J'ai peut-être raté quelque chose, alors si quelqu'un a compris quelque chose qu'il nous éclair .... rêvons en attendant de l'e-commerce algérien.

Mais on ne terminera pas sans dire que ce site est celui qui a remporté le Trophée MED-IT 2009 comme le meilleur site web marchand Algérien !!!

Je ne peut rien dire sur ça, bien que un peu surpris, mais côté sécurité c'est un peu léger ... même nos apprentis hackers peuvent faire quelque chose :)


.

Dans l'essai précédent de l'outil Honeysnap, j'ai eu à modifier manuellement le texte des traces pour garder l'anonymat du trafic réseau appartenant au client servant de cas d'étude.


Mais pour de larges quantités de traces, il faudrait faire ceci d'une manière plus propre, d'où l'intérêt des outils d'anonymisation de traces réseau.

Un des outils qui offre une grande flexibilité est PktAnon. Il a été developpé par Christoph P. Mayer, Thomas Gamer et Dr. Marcus Schöller de l'institut des télématiques de l'université de Karlsruhe en Allemagne.

Les options ou choix des modifications à apporter aux paquets originaux sont contenus dans un fichier profile sous formats XML, avec un riche panel de primitives à appliquer.

En plus des @IP source et destination, des ports source et destination (TCP ou UDP), on peut altérer plein de champ d'un paquet, allant des @MAC source et destination jusqu'au TTL.

Dans le manuel de l'outil, il y a le détail de toutes les options possibles.

Avant d'aborder l'installation et l'utilisation de cet outil, je noterais que j'ai récupérer la version 1.2.2-dev, qui était la plus récente à cet instant (la dernière semaine). La compilation n'a pas aboutie en raison de plusieurs erreurs.

J'ai envoyé alors un mail aux developpeurs de l'outil en citant les erreurs et mon environnement (version de gcc entre autre)... et 1h 25 mn après, ils me confirment que c'est lié à la dernière version de gcc que j'utilise et qu'ils vont publier une nouvelle version pour régler ce problème.

Le landemain, à 08:19 je reçois un mail m'informant de la disponibilité d'une nouvelle version, la 1.2.3-dev, compatible avec le package gcc 4.3.x ... alors bravo pour leur réactivité.

Installation :


- Récupération et décompression de l'outil :

$ wget http://www.tm.uka.de/software/pktanon/download/pktanon-1.2.3-dev.tar.gz
$ tar vxfz pktanon-1.2.3-dev.tar.gz

- Installation des paquets pré-requis : (dans le guide ils parlent de libxerces27-dev, or il n'existe pas dans les dépots Ubuntu, c'est libxerces-c2-dev à sa place)
$ sudo apt-get install libxerces-c2-dev libboost-dev

- Configuration, compilation et installation proprement dite :
$ ./configure
$ make
$ sudo make install

Utilisation :

J'ai donc une trace "capture.pcap" que je veux transmettre à un collègue ou poster sur un forum pour avoir l'avis et bénéficier de l'expertise des autres.
Je doit donc la rendre anonyme et transmettre en fait la trace "capture_anonyme.pcap" à sa place

Je décide de modifier l'@IP appartenant à mon réseau. Je veux en plus modifier l'@MAC source.

Pour faire tout ça, on prend le fichier profile fourni settings_identity.xml et on le modifie en conséquence :

- Dans le sous-module "Flow" on met :

<configitem name="Input">capture_test.pcap</configitem>
<configitem name="Output">capture_anon.pcap</configitem>


- Dans le sous-module "Checksumming", comme on va modifier certaines valeurs, la somme de contrôle va changer évidement, on met donc :

<configitem name="ReCalculateChecksums">1</configitem>
<configitem name="SetBadChecksumsToBad">1</configitem&gt
; (si un checksum initial est incorrect, on calcul un nouveau ... incorrectement)

- Dans le sous-module "EthernetPacket" on met :

<configitem anon="AnonBytewiseHashSha1" name="MacSource"/> (par défaut c'était "AnonIdentity" = garder la valeur initiale. Maintenant on change chaque octet par son Hash SHA1)

- Dans le sous-module "IpPacket" on met :

<configitem anon="AnonBytewiseHashSha1" name="IpSourceip"/&gt; (Hash SHA1 de chaque octet)


Tout est en place à présent. Il ne reste qu'à lancer la machine pktanon en précisant le fichier profile :

$ pktanon settings_identity.xml

Pour vérifier le résultat, on observe les modifications apportées au premier paquet par exemple.

L'original :

$ sudo tcpdump -neXv -c 1 -r capture_test.pcap
reading from file capture_test.pcap, link-type EN10MB (Ethernet)
18:38:47.484853 00:03:0d:3e:70:bb > 00:50:fc:25:01:2f, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11139, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.125.48706 > 74.125.99.32.80: F, cksum 0xd73f (correct), 1271021476:1271021476(0) ack 261401586 win 108
0x0000: 4500 0034 2b83 4000 4006 a07e c0a8 007d E..4+.@.@..~...}
0x0010: 4a7d 6320 be42 0050 4bc2 3fa4 0f94 abf2 J}c..B.PK.?.....
0x0020: 8011 006c d73f 0000 0101 080a 0002 37f5 ...l.?........7.
0x0030: a9b4 4922 ..I"


L'anonyme :)

$ sudo tcpdump -neXv -c 1 -r capture_anon.pcap
reading from file capture_anon.pcap, link-type EN10MB (Ethernet)
18:38:47.484853 da:c0:c5:5a:6e:f9 > 00:50:fc:25:01:2f, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11139, offset 0, flags [DF], proto TCP (6), length 52) 246.142.218.214.48706 > 74.125.99.32.80: F, cksum 0xc6ff (correct), 1271021476:1271021476(0) ack 261401586 win 108
0x0000: 4500 0034 2b83 4000 4006 903e f68e dad6 E..4+.@.@..>....
0x0010: 4a7d 6320 be42 0050 4bc2 3fa4 0f94 abf2 J}c..B.PK.?.....
0x0020: 8011 006c c6ff 0000 0101 080a 0002 37f5 ...l..........7.
0x0030: a9b4 4922 ..I"


Alors, ceux qui ont besoin d'aide, mais hésitent à envoyer leur traces ... anonymisez :)


.

Dans le billet précédent, j'ai terminé par remarquer que des requêtes DNS me semblaient bizarres parce qu'elles répétaient la même question au serveur en changeant la casse des lettres constituant le nom de domaine.

Dans ce genre de cas, c'est un des deux :
1- On est devant un truc vraiment intéressant et original
2- C'est quelque chose de banal et de trivial, et c'est nous qui avons raté une info basique

Inutile de dire que dans le plupart des cas, c'est plutôt le 2 :)

Revenons quand même à notre intrique. A ma connaissance, et selon même les RFC 1034 et 1035, la casse n'a pas d'importance dans un nom de domaine donné (voir section Preferred name syntax).
Par exemple : machin.truc = MaChin.TRUC

Alors, pourquoi certains clients (10 exactement) émettent des requêtes en variant la casse de certaines lettres ?!!

J'avoue que j'ai cherché à déceler la combinaison selon laquelle se font les variations, à voir de plus près qui sont ces clients bizarres pour moi ... en construisant plein d'hypothèses, des plus anodines au plus invraisemblables.

Mais après cette dose de paranoïa, une voix de lucidité est venue me souffler qu'il fallait peut-être voir du côté de l'ami Google s'il n'y avait pas quelque chose du même genre.

Après quelques minutes, je trouve l'explication qui me convient (pour le moment :) )

Toute cette histoire est liée aux techniques de lutte contre le cache poisoning des resolveurs DNS.

Les méchants essayent d'induire en erreur les clients DNS en leur fournissant de fausses-vraies réponses en se substituant au serveur DNS demandé.

Pour lutter contre ce type d'attaque, l'idée est d'avoir le plus possible de valeurs non (ou difficilement) déduisables par l'attaquant.

Deux éléments d'une transaction DNS sont largement connu et implémentés, surtout suite aux travaux de Dan Kaminsky de l'année passée. Ce sont le port UDP source et l'IDentifiant de la transaction. Il s'agit de les rendre le plus aléatoires possibles....mais ça reste jouable pour un attaquant s'il a le temps et les ressources suffisantes.

L'idée alors est de compliquer encore plus la vie de l'attaquant, en ajoutant un autre élément aléatoire ... vous avez deviné, c'est la casse des lettres constituant la question à résoudre. Le concept a été proposé par Paul Vixie et David Dagon sous forme d'un INTERNET-DRAFT de l'IETF en Mars 2008 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity".

En gros, ils proposent que le resolveur envoi une requête en variant la casse de la question. Les serveurs DNS en leur majorité, bien que les RFC ne le disent pas, copient bit à bit la question pour l'utiliser dans leur réponse.

Exemple, je demande à un serveur DNS de résoudre le nom www.SitE.Dz . Dans ses enregistrements, le serveur a l'@IP correspondante à www.site.dz, mais il va me répondre "www.SitE.dZ = 10.10.1.1" en respectant la casse comme il l'a reçu.... et là, le client en vérifiant la réponse, va savoir si c'est le vrai serveur qu'il a interrogé et c'est un autre qui veut l'induire en erreur.
Pour faire passer son coup, l'attaquant doit prédire la bonne combinaison en minuscule et en majuscule...en plus du bon port UDP...en plus du bon TXID .

Cette idée est petit à petit implémentée dans plusieurs resolveurs DNS (celui utilisé par tor par exemple) .

Enfin, ça explique (pour le moment) mes requêtes suspectées à tord .... désolé d'avoir douté de vous cher resolveurs 0x20 :)


.

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)