Réseaux et (in)sécurité http://blog.packetfault.org \x42\x45\x45\x52 in the DataCenter! Sun, 30 Aug 2009 18:45:58 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 Ma personnalité IDISC: Chercheur – Researcher http://blog.packetfault.org/2009/08/ma-personnalite-idisc-chercheur-researcher/ http://blog.packetfault.org/2009/08/ma-personnalite-idisc-chercheur-researcher/#comments Sun, 30 Aug 2009 18:45:58 +0000 admin http://blog.packetfault.org/?p=64 L’an passé j’ai lu The Personality Code the Travis Bradberry et réalisé le test de personnalité.

IDISC a été crée par un psychologue d’Harvard, Monsieur William Marston. Aussi inventeur de Wonder Woman.

Le résultat est que parmi les 14 personnalités, j’entre dans la case chercheur (Researcher). Voici les explications en anglais de ce type de personnalité :

As a Researcher, most of what you do is characterized by an utter reliance on logic and reason to solve problems, and a steadfast willingness to complete a project to the end without loose ends. You possess an unusual amount of determination and are highly task focused. You don’t mind working alone to accomplish goals, and are steadfast in your beliefs about what works and what doesn’t work. Just 4% of the population share this profile, including famous data hounds Warren Buffet and Jonas Salk.

Strengths:

  • Completing tasks to the end without loose ends
  • Using logic and reason
  • Being confident
 Challenges:

  • Displaying emotion
  • Trusting your gut
  • Accepting change

How to make the most of your Researcher profile:

  • Due to your low-key and steady nature, others may interpret your style as cold or uncaring. You can avoid this by explaining your passion for facts and objective information.
  • Logic and reason appeal to you more than emotion and feelings, so you should pursue tasks that require focus on data and analytical reasoning to interpret problems and devise solutions.
  • People see you as rational and thorough so don’t be surprised when they come to you to test their, or someone else’s, thinking. Be careful not to deliver your feedback too harshly, or it will deter people from seeking you out.

Suggestions for connecting with a Researcher:

  • When presenting an idea or opinion to a Researcher, be sure to support your position with solid data.
  • Researchers require clearly stated goals and an organized plan to work effectively on a project.
  • You will have far better luck wining over a Researcher with logical reasoning than you will with displays of emotion.

D’après le test IDISC, chaque personnalité contient un anti-type. Ce dernier correspondant à un type de personnes avec lesquelles il risque d’avoir des étincelles… La bête noire du chercheur est le stratège.

What do you get when you bring two people together who are steadfast in their beliefs and always have a clear plan for the future? Unless their plans are matching, you’re bound to get fireworks. Since the Researcher and Strategist are motivated by different things – yet always have a plan for the future – their opinions of where to head are often at odds. The Researcher is characterized by his outright reliance on logic and reason when solving problems. He’s far more focused on tasks than people, and understandably unresponsive to persuasive displays of emotion. If you want to convince the Researcher of something, you better come with data. The Strategist, on the other hand, is primarily interested in people, and she uses her charisma to win people over to her way of thinking. Nobody likes talking to a brick wall, which is precisely what it feels like for a Strategist to talk to a Researcher – her most persuasive arguments go unnoticed. On the other side of the coin, the Researcher doesn’t understand why the Strategist can’t bring the facts forward, and is quick to assume that she’s hiding something to focus so fervently on, “anything other than the truth.”

Task-focused profiles often clash with people-focused profiles, and the source of resolution is generally fueled by the people-focused profile’s desire for harmony. This doesn’t work here. The Strategist may be focused on people, but she is quick to disdain those that don’t share enthusiasm for her ideas – and if anyone isn’t going to, it’s usually a Researcher wondering when she’s going to get the facts. Since both profiles are steadfast in their beliefs about how to get things done, the butting of heads that ensues can be fierce.

Is there anything the Researcher and Strategist can do to reconcile? Absolutely. It’s all about pace. You see, the Strategist is so willing to trust her gut that she grows impatient when others don’t do the same. But a Researcher isn’t going to budge here. Researchers just don’t offer quick decisions, and the Strategist has to understand that the Researcher needs time to collect the facts before he is comfortable offering an opinion. Whenever two people have trouble staying in sync, they need to check in with each other. Since the Strategist is usually going to be the one pushing to move things forward, she needs to stop and check-in with the Researcher every time that surge of impatience balloons in her belly. Make sure the two of you are talking about the same thing. The Researcher won’t hesitate to tell you the crux of what he’s thinking – so take what he says seriously.

If you think emotions can’t be measured, watch how quickly people are swayed by the Strategists ideas. She’s no pied piper – she’s convincing because she speaks directly to what people feel is important. The Strategist is also very good at planning ahead. She’s so good at it that people place great trust in what she thinks. So, you’re better off paying attention to what’s on her mind. If you’re hesitant to consider her suggestions, make sure it’s truly a logical fallacy and not your own resistance to change. The Strategist embraces change like a warm hug, and a Researcher can learn a lot from that. Finally, realize that the Strategist’s use of emotion to sway people’s opinion distracts from an important quality that she shares with the Researcher – perhaps more than any other profiles, the Strategist and the Researcher like to dot the i’s and cross the t’s. When things are going to hell in a hand basket, the Strategist is not only going to care about doing things right, she can convince the group to listen to a Researcher’s reason. Like the Researcher, the Strategist is a smart, logical thinker; when they find common ground in support of a plan, they make a formidable team.

Et vous quel est votre DISC ? :-)

]]> http://blog.packetfault.org/2009/08/ma-personnalite-idisc-chercheur-researcher/feed/ 0 Retour sur l’incident “Watch your Internet routers!” du SANS http://blog.packetfault.org/2009/08/retour-incident-watch-your-internet-routers-isc-sans/ http://blog.packetfault.org/2009/08/retour-incident-watch-your-internet-routers-isc-sans/#comments Tue, 18 Aug 2009 06:01:51 +0000 admin http://blog.packetfault.org/?p=50 Le SANS est un organisme élitiste de barbichus se servant régulièrement d’étudiants pour pondre de beaux documents de sécurité.

Fin mars 2009, un lecteur du diary de l’ISC (journal de recensement des incidents sécurité du SANS) nous fait part d’une attaque sur l’un de ses routeurs Cisco ayant les services de management joignables depuis l’Internet.

Malheureusement pour eux, un compte “test” a été utilisé par un délinquant du (telnet|ssh). Mais cette expérience leur a été bénéfique, ils ont compris que collecter des logs est toujours utile.

Lles commandes entrées par le délinquant ont été enregistrées et les voici :

3/28/2009 8:34:02 Authen OK test
3/28/2009 8:34:04 test Default Group where <cr>
3/28/2009 8:34:05 test Default Group who <cr>
3/28/2009 8:34:13 test Default Group who <cr>
3/28/2009 8:34:19 test Default Group show version <cr>
3/28/2009 8:34:23 test Default Group who <cr>
3/28/2009 8:38:38 test Default Group show configuration <cr>
3/28/2009 8:38:59 test Default Group show interfaces <cr>
3/28/2009 8:39:48 test Default Group configure terminal <cr>
3/28/2009 8:39:50 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:39:57 test Default Group show interfaces <cr>
3/28/2009 8:41:48 test Default Group configure terminal <cr>
3/28/2009 8:41:49 test Default Group access-list 20 permit 192.168.2.2 <cr>
3/28/2009 8:41:50 test Default Group ip nat pool new [removed] netmask 255.255.255.252 <cr>
3/28/2009 8:41:51 test Default Group ip nat inside source list 20 pool new overload <cr>
3/28/2009 8:41:52 test Default Group ip nat inside source static tcp 192.168.2.2 113 [removed] 113 extendable
3/28/2009 8:41:52 test Default Group interface Serial 1/0 <cr>
3/28/2009 8:41:53 test Default Group ip nat outside <cr>
3/28/2009 8:41:53 test Default Group interface Tunnel 128 <cr>
3/28/2009 8:41:53 test Default Group ip nat inside <cr>
3/28/2009 8:41:54 test Default Group ip address 192.168.2.1 255.255.255.0 <cr>
3/28/2009 8:41:54 test Default Group ip tcp adjust-mss 1400 <cr>
3/28/2009 8:41:55 test Default Group tunnel source Serial 1/0 <cr>
3/28/2009 8:41:55 test Default Group tunnel destination [removed] <cr>
3/28/2009 8:47:23 test Default Group configure terminal <cr>
3/28/2009 8:47:26 test Default Group line console 0 <cr>
3/28/2009 8:47:32 test Default Group password *****
3/28/2009 8:47:45 test Default Group who <cr>
3/28/2009 8:47:55 test Default Group configure terminal <cr>
3/28/2009 8:48:01 test Default Group line vty 0 1052 <cr>
3/28/2009 8:48:06 test Default Group password *****
3/28/2009 8:49:12 test Default Group no transport input <cr>
3/28/2009 8:49:26 test Default Group transport input ssh <cr>

3/28/2009 8:34:02 Authen OK test

3/28/2009 8:34:04 test Default Group where <cr>

3/28/2009 8:34:05 test Default Group who <cr>

3/28/2009 8:34:13 test Default Group who <cr>

3/28/2009 8:34:19 test Default Group show version <cr>

3/28/2009 8:34:23 test Default Group who <cr>

3/28/2009 8:38:38 test Default Group show configuration <cr>

3/28/2009 8:38:59 test Default Group show interfaces <cr>

3/28/2009 8:39:48 test Default Group configure terminal <cr>

3/28/2009 8:39:50 test Default Group interface Tunnel 128 <cr>

3/28/2009 8:39:57 test Default Group show interfaces <cr>

3/28/2009 8:41:48 test Default Group configure terminal <cr>

3/28/2009 8:41:49 test Default Group access-list 20 permit 192.168.2.2 <cr>

3/28/2009 8:41:50 test Default Group ip nat pool new [removed] netmask 255.255.255.252 <cr>

3/28/2009 8:41:51 test Default Group ip nat inside source list 20 pool new overload <cr>

3/28/2009 8:41:52 test Default Group ip nat inside source static tcp 192.168.2.2 113 [removed] 113 extendable

3/28/2009 8:41:52 test Default Group interface Serial 1/0 <cr>

3/28/2009 8:41:53 test Default Group ip nat outside <cr>

3/28/2009 8:41:53 test Default Group interface Tunnel 128 <cr>

3/28/2009 8:41:53 test Default Group ip nat inside <cr>

3/28/2009 8:41:54 test Default Group ip address 192.168.2.1 255.255.255.0 <cr>

3/28/2009 8:41:54 test Default Group ip tcp adjust-mss 1400 <cr>

3/28/2009 8:41:55 test Default Group tunnel source Serial 1/0 <cr>

3/28/2009 8:41:55 test Default Group tunnel destination [removed] <cr>

3/28/2009 8:47:23 test Default Group configure terminal <cr>

3/28/2009 8:47:26 test Default Group line console 0 <cr>

3/28/2009 8:47:32 test Default Group password *****

3/28/2009 8:47:45 test Default Group who <cr>

3/28/2009 8:47:55 test Default Group configure terminal <cr>

3/28/2009 8:48:01 test Default Group line vty 0 1052 <cr>

3/28/2009 8:48:06 test Default Group password *****

3/28/2009 8:49:12 test Default Group no transport input <cr>

3/28/2009 8:49:26 test Default Group transport input ssh <cr>

L’attaquant arrive à 8h34. Il vérifie si quelqu’un d’autre est connecté au routeur. Un petit show version, show conf (à l’ancienne!) histoire de savoir où l’attaquant a mis ses pieds.

A 8h41, l’attaquant monte un tunnel entre le routeur victime (If tunnel: 192.168.2.1 sourcé par l’interface S1/0) et son propre routeur (If tunnel: 192.168.2.2 à destination de l’adresse IP du routeur de l’attaquant). En l’état, ce tunnel n’a pas été utilisé pour mirrorer du traffic via GRE et donc pas de leaking d’informations. L’authentification sur le routeur a pu être déjouée mais l’attaquant n’a, au final, rien fait d’intéressant (à priori puisque l’on ne sait pas quel traffic a pu être émis). Ce genre de configuration est utile pour faire passer sa connexion par un routeur victime histoire de se cacher “ou comment les délinquants transforment ton routeur Cisco en proxy full open-ports!”. Une petite règle NAT pour pouvoir répondre aux requêtes identd (44 – What is an Ident server? Why am I unidentified and why does it matter?) des serveurs le demandant et voilà ton routeur prêt pour être utilisé comme router-in-the-middle (c) pour relayer des paquets. En voyant autant de bétises, on se dirait presque que les admins réseaux du routeur victime l’ont fait exprès ou font parti du projet honeynet mais, à priori, il n’en n’est rien ;)

Après 8h52, les commandes sont totalement “blarg!” puisque les modifications sont appliquées immédiatement (changement du mot de passe ssh) mais la logique de l’IOS utilisera la configuration AAA à base de RADIUS/TACACS en premier. Le fallback vers la configuration locale prenant place uniquement si le serveur RADIUS/TACACS devient inaccessible.

Au vu de la session, l’attaquant  ne donne pas l’impression de maîtriser complètement le système d’exploitation sur lequel il est tombé. D’ailleurs ça lui aura été vite fatale puisque

quelques minutes plus tard, les victimes ont été prévenu grâce à RANCID qui a enregistré un changement de configuration et envoyé un e-mail à l’administrateur réseau qui a quoi faire. Moralité .. désactiver vos comptes de tests et rédiger des documents de réponse à incident pertinents assure une excellente réactivité et efficacité de la part des opérationnels.

]]> http://blog.packetfault.org/2009/08/retour-incident-watch-your-internet-routers-isc-sans/feed/ 0 Sémaphores et Cisco IOS EEM http://blog.packetfault.org/2009/08/semaphores-et-cisco-ios-eem/ http://blog.packetfault.org/2009/08/semaphores-et-cisco-ios-eem/#comments Sat, 15 Aug 2009 11:53:48 +0000 admin http://blog.packetfault.org/?p=37 Inventé par Monsieur Dijkstra, personnage incontournable dans le monde du routage OSPF ou IS-IS. Les sémaphores sont bien connus des étudiants en cycle ingénieur et autres geeks aimant creuser les entrailles des systèmes d’exploitation. Grossièrement, le rôle d’un sémaphore est de réserver l’accès exclusif à une ressource. Pratique pour résoudre une race condition inter-processus ou pas :

Mais les sémaphores ne sont pas parfait. En voici un exemple lorsqu’un un grand nombre d’interfaces contient des ACL configurés.
Une opération rapide de création/suppression d’ACE entraîne ces message sur les plateform c10k http://www.cisco.com/en/US/products/hw/routers/ps133/:
Dec 27 12:46:09.884: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already
locked by itself
-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594
Dec 27 12:46:09.888: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already
locked by itself
-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594
Dec 27 12:46:09.888: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already
locked by itself
-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594
Dec 27 12:46:15.076: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already
locked by itself
-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594
Dec 27 12:46:15.088: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already
locked by itself
-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Les sémaphores ne sont pas parfait. En voici un exemple lorsqu’un un grand nombre d’interfaces contient des ACL configurés.

Une opération rapide de création/suppression d’ACE entraîne ces message sur les plateformes c10k :

Dec 27 12:46:09.884: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already locked by itself

-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Dec 27 12:46:09.888: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already locked by itself

-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Dec 27 12:46:09.888: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already locked by itself

-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Dec 27 12:46:15.076: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already locked by itself

-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Dec 27 12:46:15.088: %SCHED-3-SEMLOCKED: TurboACL attempted to lock a semaphore, already locked by itself

-Traceback= 60530010 6061B3C4 61030AFC 603E658C 603E946C 603E9594

Côté opérationnel, un sémaphore s’implémente grâce à EEM (lorsqu’il est absent, une parade existe). Ce dernier permet d’ajouter une logique (humaine, oups! on est pas dans la merde!) à la logique de fonctionnement parfois inadapté de l’IOS. Lorsque la raison n’est pas technique (dans notre cas ici, ça l’est), les couches 8 et 9 du modèle OSI ont toujours raison!

En particulier en environnement datacenter, dans lequel idéalement, les domaines spanning-tree de niveau 2 en accès doivent être isolés du coeur du réseau afin de prévenir la propagation d’une boucle de commutation non pas sur un site de datacenter mais sur la totalité des datacenter. L’isolation de spanning-tree est donc obligatoire. Si votre consultant favori ne vous a pas parlé de ça, alors fuyez! .. ça me rappelle le mythe de l’expert sécurité généraliste.

Afin de garantir une topologie loop-free de bout en bout, un sémaphore (merci EEM) est configuré pour garantir qu’aucune boucle ne soit généré par les liens WAN reliant les différents datacenter. Considérons la topologie suivante :

Les N-PE primary et backup sont interconnectés au coeur de réseau MPLS (généralement administré par Orange pour les clients Français). L’on va positionner les sémaphores entre chaque N-PE primary et backup (matérialisés par les flèches rouges et vertes entre chaque primary et backup sur le schéma précédent).  Le primary forward les flux pendant que le backup est en attente. Aucune boucle n’est alors possible car les pseudowires sont actif uniquement sur le lien primary.

Régulièrement un signal (sémaphore – flèche rouge) est envoyé au N-PE backup indiquant que le N-PE primary est toujours connecté alors le N-PE backup indique au primary que son lien est bien down. Si le primary passe down, le backup passe UP. Le sémaphore – flèche verte s’active évitant ainsi une transition “active/active”. Lorsque le lien WAN du primary repasse en UP. Le sémaphore rouge est envoyé. Mais le vert aussi. Un timer est alors déclenché afin de s’assurer que le lien WAN du primary est stable et n’est pas en train de flapper ou repassera down dans les prochaines secondes. Le backup assure son rôle, alors pourquoi vouloir se presser ! Lorsque le timer est passé, le sémaphore du backup passe en down et le primary gère de nouveaux les flux inter-datacenter.

Voici la configuration anti boucle de commutation réalisé grâce aux sémaphores. Sur les primaires :

interface loopback80

ip address 10.80.74.4 255.255.255.255

track timer timer ip route 1

track 10 ip route 10.80.76.5/32 reachability

Sur les backup :

interface loopback80

ip address 10.80.76.5 255.255.255.255

shutdown

track timer ip route 1

track 10 ip route 10.80.76.4/32 reachability

delay up 100

Les événements EEM déclenchés seront des shut/no shut des interfaces loopback permettant d’activer/désactiver les sémaphores.

]]> http://blog.packetfault.org/2009/08/semaphores-et-cisco-ios-eem/feed/ 1 Remplacer Cisco EEM par un script python (la loose c’est même pas en ruby) http://blog.packetfault.org/2009/08/remplacer-cisco-eem-par-un-script-python-la-loose-cest-meme-pas-en-ruby/ http://blog.packetfault.org/2009/08/remplacer-cisco-eem-par-un-script-python-la-loose-cest-meme-pas-en-ruby/#comments Thu, 13 Aug 2009 18:43:33 +0000 admin http://blog.packetfault.org/?p=31 EEM (IOS Embedded Event Manager) permet principalement de déclencher des actions automatiques en fonction d’événements sur les Cisco.

Les anciens codes IOS (routeurs ou switches) ne supportent pas toujours ce système que ça soit dans sa dernière ou première version.

Hélas, je suis tombé sur un système qui ne supportait pas l’EEM … mais après tout, il y a pire : Il paraît que certains ont vu se déployer RSH en 2009 au grand damn de JPGaulier.

Le python et pspad utilisés comme outils afin d’écrire un petit bout de code dont le but est de remplacer une des fonctionnalités d’EEM.

Paramétrer la ligne logging 1.2.3.4 (où 1.2.3.4 est la machine sur laquelle le script est lancé) sur le switch. Vous pouvez avoir plusieurs lignes “logging” dans la configuration, les logs seront envoyés aux adresses IP spécifiés pour chacune des lignes de configuration.

Ensuite, le fichier motcle.txt contient un mot-clé recherché dans les logs réceptionnés et déclenchera les commandes indiqués dans le fichier commandes.txt. Après avoir spécifié l’adresse IP du switch ainsi que ses paramètres de connexions (username, mot de passe, mot de passe et enable) dans le fichier password.txt, lancer le script.

Pour mon besoin, il y a une boucle qui tourne 10 fois. Ici, le but recherché était de surveiller les compteurs d’interfaces afin de détecter des micro-spikes et comparer le retour des commandes à une baseline de traffic. Du coup, lorsque le script a lancé les commandes, un fichier cisco-date-heure-.log est crée dans le répertoire courant.

Télécharger le script.

]]> http://blog.packetfault.org/2009/08/remplacer-cisco-eem-par-un-script-python-la-loose-cest-meme-pas-en-ruby/feed/ 0 MISC 44 – Attaque des numéros de séquences cryptographiques sur OSPF http://blog.packetfault.org/2009/08/misc-44-attaque-des-numeros-de-sequences-cryptographiques-sur-ospf/ http://blog.packetfault.org/2009/08/misc-44-attaque-des-numeros-de-sequences-cryptographiques-sur-ospf/#comments Sun, 09 Aug 2009 10:24:20 +0000 admin http://blog.packetfault.org/?p=17 Mon article et preuve de concept sur l’attaque des numéros de séquences cryptographiques sur OSPFv2 est disponible dans le dernier MISC de Juillet/Août 2009.

En résumé pour être safe … faites passer vos flux OSPF uniquement dans des liens point à point ou alors passez à OSPFv3 et donc IPv6 !

]]> http://blog.packetfault.org/2009/08/misc-44-attaque-des-numeros-de-sequences-cryptographiques-sur-ospf/feed/ 0 Reconstruire des fichiers qui passent dans un flux TFTP grâce à Ruby (pour être hype) http://blog.packetfault.org/2009/07/reconstruire-des-fichiers-qui-passent-dans-un-flux-tftp-grace-a-ruby-pour-etre-hype/ http://blog.packetfault.org/2009/07/reconstruire-des-fichiers-qui-passent-dans-un-flux-tftp-grace-a-ruby-pour-etre-hype/#comments Thu, 30 Jul 2009 10:35:07 +0000 admin http://blog.packetfault.org/?p=22 Parfois les collègues de la VoIP reçoivent des données à troubleshooter au format PCAP et dedans il y a des requêtes TFTP de transferts de fichiers.

- “François, tu aurais une idée pour voir les fichiers avec wireshark ?”

- “Wireshark ne sait pas faire ça. Allez on va coder notre mini tool!”

Newsoft me disant au cours de la semaine que le Ruby c’était “à la mode” … alors j’ai crée un mini-tool en ruby qui reconstruit les fichiers en lisant un fichier PCAP.

Et voilà ton .Jar et tes paramètres de boot des IP phones reconstitués!

Le script est téléchargeable ici.

]]> http://blog.packetfault.org/2009/07/reconstruire-des-fichiers-qui-passent-dans-un-flux-tftp-grace-a-ruby-pour-etre-hype/feed/ 0 MISC40 Sécurité des réseaux, les nouveaux enjeux http://blog.packetfault.org/2008/10/misc40-securite-des-reseaux-les-nouveaux-enjeux/ http://blog.packetfault.org/2008/10/misc40-securite-des-reseaux-les-nouveaux-enjeux/#comments Fri, 31 Oct 2008 10:01:04 +0000 admin http://blog.packetfault.org/?p=7 Oyé oyé! Le MISC numéro 40 avec un dossier sécurité des réseaux est disponible dans votre kiosque préféré depuis aujourd’hui. D’habitude je ne fais pas les sorties de nouveaux numéros mais là c’est différent car j’ai pu écrire un article dedans (Le très haut débit – un challenge pour la sécurité). Voici le sommaire complet:
http://blog.packetfault.org/misc40.jpg
Infowar [04 - 13]
Conflit russo-géorgien et guerre de l’information
Cryptographie [14 - 16]
MOC ou la biométrie dans une carte à puce
DOSSIER [18 - 59]
[Sécurité des réseaux : les nouveaux enjeux]
Sécurité pour l’introduction de l’IPv6 dans les coeurs de réseau / 19 – 28
Le très haut débit – Un challenge pour la sécurité / 29 – 37
Les nouvelles sondes de sécurité dans les réseaux multiservices / 38 – 44
Une nouvelle approche dans l’analyse des configurations / 47 – 52
Émulation d’architectures réseau / 53 – 59
Système [60 - 69]
Comprendre les rôles de Solaris™ et d’OpenSolaris
Science [70 - 82]
La biométrie : solution ou illusion ?
Bonne lecture!
http://www.miscmag.com/index.php/2008/10/31/misc-40-securite-des-reseaux-les-nouveaux-enjeux-novembredecembre-2008-chez-votre-marchand-de-journaux
http://www.ed-diamond.com/produit.php?produit=601

Le MISC numéro 40 (Novembre/Décembre) avec un dossier sécurité des réseaux est disponible dans votre kiosque préféré depuis aujourd’hui.

J’ai pu écrire un article dedans (Le très haut débit – un challenge pour la sécurité). Voici le sommaire complet :

Infowar [04 - 13]

Conflit russo-géorgien et guerre de l’information

Cryptographie [14 - 16]

MOC ou la biométrie dans une carte à puce

DOSSIER [18 - 59]

[Sécurité des réseaux : les nouveaux enjeux]

Sécurité pour l’introduction de l’IPv6 dans les coeurs de réseau
Le très haut débit – Un challenge pour la sécurité
Les nouvelles sondes de sécurité dans les réseaux multiservices
Une nouvelle approche dans l’analyse des configurations
Émulation d’architectures réseau

Système [60 - 69]

Comprendre les rôles de Solaris™ et d’OpenSolaris

Science [70 - 82]

La biométrie : solution ou illusion ?

Bonne lecture!

http://www.miscmag.com/index.php/2008/10/31/misc-40-securite-des-reseaux-les-nouveaux-enjeux-novembredecembre-2008-chez-votre-marchand-de-journaux

http://www.ed-diamond.com/produit.php?produit=601

]]> http://blog.packetfault.org/2008/10/misc40-securite-des-reseaux-les-nouveaux-enjeux/feed/ 0 Mapper une adresse IP à un numéro d’AS BGP grâce à Python http://blog.packetfault.org/2008/10/mapper-une-adresse-ip-a-un-numero-das-bgp-grace-a-python/ http://blog.packetfault.org/2008/10/mapper-une-adresse-ip-a-un-numero-das-bgp-grace-a-python/#comments Fri, 24 Oct 2008 10:06:49 +0000 admin http://blog.packetfault.org/?p=11 This morning I felt on http://nmap.org/book/nse-scripts-list.html then wrote a tiny tool in python to map IP with an AS number, country, AS peers and subnet.
Output example: python ip2asn.py 194.140.247.6
AS Numbers:
BGP: 194.140.247.0/24 | Country: GB
Origin AS: 41156 SUPINFO-AS SUPINFO – International Institute of Information Technology
Peer AS: 8928 12600
Peer AS are Interoute and Telecity Paris. SUPINFO is the school where I got my diploma.
Script is downloadable here.
Here is the python’s code:
#!/usr/bin/env python
“”"
Francois ROPERT
http://blog.packetfault.org
“”"
import sys
import dns.resolver
from dns.exception import DNSException
def usage():
print “Usage: “+sys.argv[0]+” [remote IP dnssrv.py] [woot]“
sys.exit(0)
if ( len(sys.argv) – 1 < 1 ):
usage()
resolver = dns.resolver.Resolver()
reversed_ip=sys.argv[1].split(’.')
reversed_ip.reverse()
reversed_ip = “.”.join(reversed_ip)
bgp_answers=[]
try:
answer_origin = resolver.query(reversed_ip+”.origin.asn.cymru.com”, “TXT”)
answer_peer = resolver.query(reversed_ip+”.peer.asn.cymru.com”, “TXT”)
print “AS Numbers:”
for rdata in answer_origin:
origin=str(rdata)
origin=origin.replace(’\”‘,”)
origin=origin.split(’ | ‘)
asnumber = “AS”+origin[0]
bgp_answers.append([origin[1],origin[0],origin[2]])
answer_asn = resolver.query(asnumber+”.asn.cymru.com”, “TXT”)
for rdata in answer_asn:
asn=str(rdata)
asn=asn.replace(’\”‘,”)
asn=asn.split(’ | ‘)
for i in range (0, len(bgp_answers)):
bgp_answers[i].append(asn[4])
count=0
for rdata in answer_peer:
peer=str(rdata)
peer=peer.replace(’\”‘,”)
peer=peer.split(’ | ‘)
bgp_answers[count].append(peer[0])
count=count+1
for i in range(0,len(bgp_answers)):
print “BGP: “+ bgp_answers[i][0] + ” | Country: ” + bgp_answers[i][2]
print ”  Origin AS: ” + bgp_answers[i][1] + ” ” + bgp_answers[i][3]
print ”    Peer AS: ” + bgp_answers[i][4]
except DNSException, e:
print “FAIL cuz u sux!”
Enjoy

Ce matin je suis tombé sur http://nmap.org/book/nse-scripts-list.html alors j’ai écris un mini outil en python permettant de mapper une IP à un numéro d’AS, à un pays mais aussi d’afficher quels AS ont peerés avec l’AS d’origine.  Vous pouvez télécharger le script ici.

Example : python ip2asn.py 194.140.247.6

AS Numbers:

BGP: 194.140.247.0/24 | Country: GB

Origin AS: 41156 SUPINFO-AS SUPINFO – International Institute of Information Technology

Peer AS: 8928 12600

Peer AS are Interoute and Telecity Paris. SUPINFO is the school where I got my diploma.

Vive le python!

]]> http://blog.packetfault.org/2008/10/mapper-une-adresse-ip-a-un-numero-das-bgp-grace-a-python/feed/ 0