Archive pour Octobre 2009

Frai A-Prompt CMD à partir de MS Word ou Excel

15 octobre 2009

C'est un vieux truc, mais je vois encore un certain nombre d'administrateurs qui pensent qu'ils ont verrouillé les utilisateurs hors de l'invite de commande en supprimant simplement l'icône dans le menu et en désactivant l'option Démarrer-> Exécuter. Dans ce post, je vais discuter de la façon de créer une invite de commande avec Visual Basic pour Applications (VBA), ainsi que la façon d'atténuer (mais jamais complètement éliminer) le risque d'accès à quelqu'un parvenir à l'invite.

Création d'une invite de commande avec VBA

Cette technique fonctionne avec n'importe quelle application qui supporte VBA, mais je suis spécialement l'intention d'utiliser Microsoft Word dans mon exemple. Voici ce que vous devez faire:

Lancez Microsoft Word
Appuyez sur "Alt-F11" pour lancer l'éditeur VBA
Double-cliquez sur "ThisDocument" dans le volet gauche
Lorsque la fenêtre de l'éditeur apparaît, tapez le texte de la figure n ° 1
Appuyez sur la touche "F5"

Figure 1: Notre script simple VB

Vous devriez voir une fenêtre d'invite de commande apparaît dans votre barre des tâches. Voici une copie du code dont vous avez besoin à l'étape 4 de sorte que vous pouvez copier / coller:

Sous GetCMD ()
Shell "cmd.exe cmd.exe"
End Sub

Comment prévenir VBA fraie une invite de commande

Exécution de l'invite de commande peut être désactivée avec l' éditeur de stratégie de groupe de l'outil. Voici les étapes:

Cliquez sur Démarrer -> Exécuter
Tapez "gpedit.msc" (sans les guillemets)
Cliquez sur Configuration utilisateur -> Modèles d'administration -> Système
Rechercher dans la liste de "Empêcher l'accès à l'invite de commande" et double cliquez dessus

Vous avez deux options s'offrent à vous:

Activer / Désactiver l'accès à l'invite de commande
Oui / Non Désactivez processus de scripts d'invite de commande

Si vous ne désactivez la première option, accès direct à cmd.exe est empêché, mais un utilisateur intelligent peut toujours obtenir de l'aide d'un fichier batch. Pour empêcher l'accès au script, besoin de désactiver la deuxième option aussi. Cela empêche tous les scripts, cependant, et peuvent causer des ravages dans de nombreux environnements. En outre, ces deux paramètres s'appliquent au compte Administrateur ainsi. Cela peut rendre admin et dépannage beaucoup plus difficile.

Même avec les deux options désactivé, l'utilisateur peut toujours contourner ces paramètres en utilisant command.com au lieu de cmd.exe. Pour corriger cela, vous devez restreindre l'accès à command.com via permissions utilisateur. Si vous êtes encore l'exécution de certaines anciennes applications 16-bit, ce correctif va les casser.

Toutes ces étapes ne résout pas complètement le problème cependant. Un utilisateur qui sait ce qu'ils font avec debug pouvez simplement copier cmd.exe à un autre endroit et de le modifier de sorte une invite est atteint quand l'utiliser pour exécuter une commande factice. Donc nous devons aussi supprimer "debug.exe".

Même alors, un programmeur avisé peut créer un exécutable pour contourner tous les contrôles de sécurité ci-dessus. Nous avons donc besoin d'enlever toute possibilité de copier ou écrire sur le disque ainsi. Inutile de dire que nous avons un ordinateur assez inutile à ce point.

Résumé Exec

Si quelqu'un à puce a accès à votre système, il est douteux, vous serez en mesure d'empêcher lui de se rendre à la ligne de commande. L'éditeur de stratégie de groupe peut certainement rendre plus difficile, mais l'outil réduit simplement le risque d'attaque. Vous ne pouvez pas éliminer complètement le risque sans entrave sérieusement le fonctionnement du système et l'utilité.

Pas de commentaires »

Publié dans 4-préavis , de sécurité Windows

Tags: ligne de commande Windows de sécurité de Windows fenêtres astuces

PDF de «Protection contre les attaques ciblées" parler

14 octobre 2009

Au cours des prochaines semaines je vais donner cette conférence dans un certain nombre d'endroits. Pour ceux qui ont participé et ont demandé une version PDF des diapositives, voici le lien je l'ai promis: la protection-contre-attaques ciblées-R2-

3 commentaires »

Publié dans 3-err , Sécurité générale

Tags: liste blanche d'application Malware

Tshark Challenge - Uber-geek Réponse

13 octobre 2009

Dans mon dernier post, je vous laisse avec une question: Compte tenu de ce que nous avons vu dans le fichier de décoder avec tshark, quel est l'impact (le cas échéant) y aurait-il si on place un pare-feu stateful inspection entre l'attaquant et le serveur Web? En d'autres termes, si l'attaquant exécute un renifleur de paquets, seraient-ils encore voir le serveur Web fuite des erreurs 404?

Et la réponse est ...

Peut-être.

Pas tous les pare-feu stateful inspection sont égaux. Certains paquets de gérer de façon légèrement différente que les autres. Par exemple, certains (comme Checkpoint, Netscreen et autres) laissez non des paquets SYN pour permettre de générer de nouvelles règles entrées de la table de l'Etat. Certains (Cisco, Netfilter et autres) ne fera que générer une table d'état à l'établissement session proprement dite (à voir handshake TCP paquets trois).

Le NIPS a envoyé un paquet de réinitialisation valide pour l'attaquant sur Internet. Chacun des pare-feux ci-dessus voir le paquet de réinitialisation et le retirer de l'entrée de la table d'état. Lorsque le serveur Web a continué de communiquer cependant, seul le premier jeu de pare-feu aurait laissé s'échapper les paquets à l'attaquant. La deuxième série de pare-feu serait tout simplement laisser tomber le trafic. En fait, si nous les mis en place avec une règle de refus au lieu d'une règle de chute, ils tueraient la session sur le serveur Web ainsi régler le problème créé par le NIPS.

Pourquoi certains fournisseurs laisser entrer des paquets reconnaissance générer de nouvelles entrées de la table de l'État? Cela semble contre-intuitif peu comme une une session légitime va toujours commencer par un paquet SYN. Il ya deux raisons cela rend le bon sens fonctionnel:

Mise à jour des règles de pare-feu ne tuent pas les sessions actives
Active-Active Setup va passer le trafic avant de synchroniser la table d'état

Bien sûr, nous avons augmenté la fonctionnalité au détriment de la sécurité. Malheureusement, ce n'est l'arrêt du commerce typique.

Espoir vous avez eu du plaisir avec ce défi. S'il ya un intérêt, je poste plus dans l'avenir.

2 commentaires »

Publié dans 2-alerte , de sécurité réseau , Packet Décodage

Tags: pare-feu de sécurité réseau par paquets de décodage

Tshark Challenge - les réponses finales

9 octobre 2009

Dans mon dernier post nous avions déterminé que le fichier de trace contient une session où un seul réseau perfectionné système de prévention des intrusions avaient tenté d'arrêter une attaque d'un client HTTP à un serveur Web. Nous avons conclu que la demande du client les données ne semblent plutôt suspecte, et a prouvé un système tiers (NIPS) était responsable de la transmission des paquets de réinitialisation lors de la session.

Dans ce post nous avons encore besoin de répondre à deux questions:

L'attaque réussie?
Pourquoi le serveur Web ignorer le paquet TCP reset transmis par le NIPS?

L'attaque réussie?

L'attaquant était à la recherche afin d'identifier si le fichier "startstop.html" était situé dans l '«administrateur» du répertoire. Prenons un oeil à l'un des paquets envoyés à l'attaquant après la réinitialisation des paquets ont été transmises:

tshark-n-r-x challenge1.cap frame.number == 11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
0000 00 50 8b 20 ch ab 00 b0 d0 20 e3 7d 08 00 45 00. P.. .... ...} E.
0010 01 A7 37 47 40 00 40 06 73 8b 21 0C 04 94 F7 4e .. 7G @. @. S..! ... N
0020 f7 0a 00 50 69 88 39 2a 3a cd 6a 97 b9 4c 80 19 ... Pi *:.. 0.9 j. L..
0030 19 20 00 8c d4 00 01 01 08 76 0a 3d 0e d3 00 CE. ... ... ..= V ....
0040 48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e HKHTTP/1.1 404 N
0050 74 20 46 6f 6f 6e 75 64 0d 0a 44 61 74 65 20 3a ot trouvé .. Date:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 juin 2002
0070 20 30 30 33 34 3a 3a 35 38 20 47 4d 54 0D 0A 53 00:34:58 GMT .. S
0080 65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0a 43 erver: Apache .. C
0090 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 73 65 6f ONNEXION: fermer
00A0 0d 0a 43 6f 6e 74 65 6e 74 54 79 2d 70 65 3a 20 .. Content-Type:
00b0 74 65 78 74 68 74 2f 6d 6c 3b 20 63 68 61 72 73 text / html; caractères
00C0 65 74 69 73 6f 3d 2d 38 38 35 39 2d 31 0D 0A 0d et = iso-8859-1 ...
00d0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20. <! DOCTYPE HTML
00e0 50 55 42 4c 49 43 20 22 2d 2F 2F 49 45 54 46 PUBLIC 2f "- / / IETF /
00F0 2f 44 54 44 20 48 54 4d 4c 20 32 30 2E 2F 2F 45 / DTD HTML 2.0 / / E
0100 4e 3e 22 0a 48 54 3c 4d 4c 3e 3c 48 45 41 44 3E N ">. <HTML> <HEAD>
0110 0a 3c 4c 54 49 54 45 3e 34 30 34 20 4e 74 20 6f. <TITLE> 404 Not
0120 46 75 6f 6e 2f 64 3c 54 49 54 4c 45 3E 0a 3c 2f Found </ TITLE>. </
0130 48 45 41 44 3e 3c 42 4f 44 59 3E 0A 48 31 3C 3E HEAD> <BODY>. <H1>
0140 4e 6f 74 20 46 75 6f 6e 2f 64 3c 48 31 54 0a 3e Introuvable </ H1>. T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c, il a demandé URL
0160 20 63 66 69 2F 64 65 2F 41 64 6d 69 6e 69 73 74 Administ / CFIDE /
0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 StartStop 2e rateur /.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 75 6f html n'était pas fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 e sur cette servent
01a0 72 50 3c 2e 3e 0a 3c 2f 4f 42 44 59 3E 3C 2F 48 <P> r.. </ Body> </ H
01B0 54 4d 4c 3e 0a 00 03 00 07 TML> ... ..

Donc la réponse à la question de l'attaquant; "est le fichier situé sur le serveur, est répondu dans chaque paquet au serveur mis au client après la réinitialisation des paquets ont été émises?. Maintenant, la question devient, l'attaquant ne voit cette information?

Lorsque le paquet de réinitialisation a été envoyé à l'attaquant, la réinitialisation devrait avoir tué la session TCP. Cela signifie que lorsque ces données sont arrivés, le port de réception (TCP/26922) aurait dû être dans un état fermé. Si cela avait été vrai, en fait, je m'attends à voir un réarmement à venir / ACK de retour de l'attaquant le système nous dit que TCP/26922 est maintenant fermé. Nous ne voyons jamais ces paquets.

Alors pourquoi ne pas le fermer le port distant? Le paquet de réinitialisation est valide, il doit donc avoir tué la session. Un attaquant avisé va exécuter un renifleur de paquets dans le fond tout en effectuant leur attaque. Il est possible que l'attaquant aurait compris ce qui se passait et a simplement créé une règle de filtrage sur leur système d'attaque de filtrer tous les paquets entrants réinitialiser. Cela aurait permis leur outil de continuer à fonctionner. Même sans le pare-feu filtre les renifleur de paquets devrait contenir les réponses qu'ils cherchent. Donc, il ya une très bonne chance que l'attaquant a compris ce que nous sommes vulnérables à, malgré le fait NIPS est une protection du réseau.

Pourquoi le serveur Web ignorer le paquet reset?

Notre dernière question est de savoir pourquoi le serveur Web ignorer le paquet envoyé par le réarmement NIPS. Ce qui provoque deux problèmes:

Les infos de l'attaquant a voulu se poursuit à s'échapper
Si l'attaquant n'a sondes de fichiers multiples, ils pouvaient remplir le tableau de session sur le serveur Web

Le deuxième élément est un peu effrayant, car il serait en réalité l'NIPS provoquant l'attaque DoS en tuant un seul côté de la connexion correctement. Donc, même si nous avons été patché et jusqu'à ce jour aux engins de fournisseur, nous avons versé de l'argent pour se finir par tuer notre serveur Web. Gee je déteste quand je passe de l'argent pour moi DoS.

Prenons un autre regard sur ces paquets de réinitialisation:

tshark-n-r challenge1.cap frame.number == 6 ou 7 == frame.number
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP 80> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed segment perdu] 26922> 80 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

Notez que tshark nous dit paquet 7 est un segment perdu. En d'autres termes, tshark nous dit que le numéro de séquence TCP n'est pas dans la fenêtre de l'hôte est attendu. Un regard sur la séquence et de reconnaître numéros explique pourquoi. Les valeurs sont identiques à celles dans le paquet de six. Vous vous souvenez peut partir du dernier message que le paquet 6 et 7 avait aussi la valeur même ID IP (45 298).

Il semble donc que ce qui s'est passé ici est:

Client a envoyé une attaque HTTP vers notre serveur Web
NIPS détecté l'attaque
NIPS envoyé une réinitialisation TCP valide à l'attaquant de tuer la session
NIPS troqué la source et les adresses IP de destination dans le paquet, recalculé les CRC, puis envoyé la réinitialisation même le serveur Web
Web serveur ignore le reset, car il ne contient pas un numéro de séquence acceptables

Vous pouvez vous demander: «Comment avez le vendeur rater cela?». Ma meilleure supposition est que le vendeur a couru quelques attaques simulées, l'outil d'attaque n'a pas de leur montrer les fichiers vulnérables, alors ils ont supposé que tout fonctionnait OK. En d'autres termes, un vendeur qui a créé un produit pour protéger les réseaux sur le fil n'a jamais pris la peine de regarder ce que leur produit était en train de faire sur le fil. Hummm ...

Question bonus

OK, si vous vous amusez avec celui-ci, voici une question bonus à réponse qui sera définitivement prouver votre uber-geek statut lors du sommet de la pyramide secret:

Supposons que nous accordons à un pare-feu stateful inspection entre ce sous-réseau et l'attaquant. Est-ce que l'attaquant toujours être en mesure de voir les réponses avec un renifleur de paquets?

Je vais poster la réponse la semaine prochaine.

Pas de commentaires »

Publié dans 2-alerte , Packet Décodage

Tags: Décodage de paquets

Défi tshark - Conseils 4

8 octobre 2009

Dans mon dernier post, nous avons identifié que le système client a probablement été l'exécution de certaines genre d'outil pour sonder connus pour être des fichiers vulnérables. Nous avons encore à expliquer les paquets de réinitialisation cependant, ainsi que pourquoi le serveur a été de les ignorer.

En ce moment nous ne savons même pas où cette capture de paquets a été prise en relation avec les deux points d'extrémité. Je vais courir tshark en utilisant les "champs-T" passer à imprimer les informations TTL. En analysant les TTL, nous devrions être en mesure de déterminer où nous sommes renifler en relation avec le client et le serveur. Je vais aussi imprimer les identifiants IP pour voir s'il ya des anomalies dans l'ordre des paquets.

Voici la commande et la sortie:

tshark-r-T challenge1.cap champs e-frame.number-e-e ip.src tcp.srcport-e-e ip.ttl ip.id
1 148.78.247.10 26922 49 0x2a6b
2 12.33.247.4 80 64 0 × 0000
3 148.78.247.10 26922 49 0x2a95
4 148.78.247.10 26922 49 0x2a96
5 12.33.247.4 80 64 0 × 3743
6 12.33.247.4 80 255 0xb0f2
7 148.78.247.10 26922 255 0xb0f2
8 12.33.247.4 80 64 0 × 3744
9 12.33.247.4 80 64 0 × 3745
10 12.33.247.4 80 64 0 × 3746
11 12.33.247.4 80 64 0 × 3747
12 12.33.247.4 80 64 0 × 3748
13 12.33.247.4 80 64 0 × 3749
14 80 64 12.33.247.4 0x374a
15 80 64 12.33.247.4 0x374b
16 80 64 12.33.247.4 0x374c
17 80 64 12.33.247.4 0x374d

148.78.247.10 est le client. Nous le savons parce que l'ouverture de la session et sa communication en utilisant un port source supérieur. 12.33.247.10 est notre serveur HTTP de communiquer à partir du port 80.

En paquet de 1, nous voyons que le client a un TTL de 49. Le plus proche match débute TTL pour un système d'exploitation connue est de 64, donc cela nous dit que le client est un Linux, UNIX, ou le système Mac assise 15 sauts loin. En paquet de 2, nous voyons le serveur avec une valeur TTL de 64, donc il doit être l'un des systèmes d'exploitation mentionnés précédemment assis sur le réseau local. Donc, nous sommes sur le même domaine de collision que le serveur, mais assis 15 sauts loin du client.

Il ya un problème cependant. Regardez les paquets 6 et 7. Ici, nous voyons le TTL des deux systèmes de changement à 255. Un OS ne changera jamais c'est TTL lors d'une session, donc ce semble extrêmement suspect. De plus, nous avons déjà déterminé que le client est assis 15 sauts loin de nous. 255 est la plus grande valeur possible TTL comme le champ TTL est seulement un seul octet (8 octets de l'entête IP). Ainsi, même si l'adresse IP source prétend être le client distant, il n'ya aucun moyen que le paquet ait pu apparaître n'importe où, mais à partir du réseau local. Si le paquet a traversé un ou plusieurs routeurs, la valeur TTL serait plus faible.

Les informations d'identification IP ne semble pas correcte non plus. Dans les trois premiers paquets du client, nous voyons l'IP ID valeurs 0x2a6b (10859), 0x2a95 (10 901), et 0x2a96 (10902). Cela nous indique que le client est peut-être en utilisant un ID incrémentale une IP, nous n'avons tout simplement pas voir 42 des paquets entre les premier et deuxième paquets transmis. L'ID de la prochaine IP, nous voyons du client est 0xb0f2 (45298). OK, sauf si nous avons manqué plus de 34.000 paquets, cet ID IP ne jive.

Notez l'analyse ci-dessus ne serait-il pas théoriques ont été pour les valeurs TTL incompatibles. Avec seulement trois paquets à regarder, on ne peut pas identifier précisément l'incrément IP ID. Il est également possible, mais très très peu probable, que l'augmentation ID IP est complètement aléatoire et le système vient de se passer d'assigner deux incrémentale ID IP, l'un après l'autre. Pourtant, combiner les TTL et d'information IP ID ensemble et ils indiquent que ce paquet final pourrait ne pas provenir d'un même système.

Nous avons des données d'identité plusieurs adresses IP à partir du serveur de travailler avec, prenons donc un oeil à ça. Les identifiants sont:

0 (0)
0 × 3743 (14147)
0xb0f2 (45298)
0 × 3744 (14148)
0 × 3745 (14149)
0 × 3746 (14150)
0 × 3747 (14151)
0 × 3748 (14152)
0 × 3749 (14153)
0x374a (14154)
0x374b (14155)
0x374c (14156)
0x374d (14157)

Jetez un oeil à l'ID IP figurent dans la troisième, qui est de 6 paquets dans la trace. Notez que tous les ID de propriété intellectuelle d'autres sont incrémentales 1, mais cette IP ID ne lui appartient pas. En fait, nous pouvons montrer que les incréments de serveur c'est par une IP ID et qu'il n'y a aucun moyen de ce paquet provenant du serveur.

Humm. Je me demande si ces lignes suspectes paquets avec le réinitialise étranges que nous avons vu:

tshark-r-T challenge1.cap champs-e-e frame.number ip.src-e-e tcp.srcport ip.ttl-e-e ip.id tcp.flags.reset
1 148.78.247.10 26922 49 0x2a6b 0
2 12.33.247.4 80 64 0 × 0000 0
3 148.78.247.10 26922 49 0x2a95 0
4 148.78.247.10 26922 49 0x2a96 0
5 12.33.247.4 80 64 0 × 3743 0
6 12.33.247.4 80 255 0xb0f2 1
7 148.78.247.10 26922 255 1 0xb0f2
8 12.33.247.4 80 64 0 × 3744 0
9 12.33.247.4 80 64 0 × 3745 0
10 12.33.247.4 80 64 0 × 3746 0
11 12.33.247.4 80 64 0 × 3747 0
12 12.33.247.4 80 64 0 × 3748 0
13 12.33.247.4 80 64 0 × 3749 0
14 80 64 12.33.247.4 0x374a 0
15 80 64 12.33.247.4 0x374b 0
16 12.33.247.4 80 64 0 0x374c
17 12.33.247.4 80 64 0 0x374d

Ah ha! Donc, si on regarde les paquets avec l'étrange et les valeurs TTL IP ID, ce sont les paquets de réinitialisation étranges envoyés pendant la session.

Il me semble que certaines troisième système est de sauter dans la conversation afin de transmettre les paquets de réinitialisation. Depuis ces paquets étranges ont un TTL de 255, nous savons qu'il doit être sur le même domaine de collision que là où nous sommes reniflant. Depuis qu'il est sur le même domaine de collision, les informations d'en-tête Ethernet pourrait être utile:

tshark-r-T challenge1.cap champs e-frame.number e-ETH-e tcp.flags.reset
1 port Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3) 0
2 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
3 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3) 0
4 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3) 0
5 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
6 Ethernet II, Src: D-Link_8f: E0: 0C (00:50: ba: 8f: E0: 0C), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 1
7 Ethernet II, Src: D-Link_8f: E0: 0C (00:50: ba: 8f: E0: 0C), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3) 1
8 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
9 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
10 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
11 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
12 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
13 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
14 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
15 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
16 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0
17 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20:07 D: e3), Dst: HewlettP_ea: 20: ab (00:50:8 B: EA: 20: ab) 0

Ainsi, lorsque le client arrive à partir d'Internet, il passe à travers un système HP agit soit comme un routeur ou un firewall. Notre serveur Web est exécuté sur le matériel Dell. Notez notre réinitialise (paquets 6 et 7) sont les deux étant générés par le même système en utilisant une carte réseau D-Link.

Alors pourquoi le système D-Link essayer de tuer la session? Cela s'est produit juste après que le client a envoyé la demande de fichiers suspects. Il me semble que le système D-Link est en fait un système unique perfectionné de prévention des intrusions (IPS). Quand une attaque est détectée, l'IPS vise à prévenir l'attaque par la transmission de paquets de réinitialisation aux deux extrémités de la connexion.

Mais nous avons encore quelques questions sans réponse. L'attaque réussie et pourquoi le serveur semblent ignorer la tentative du IPS pour tuer la session?

Tourner dans le prochain épisode pour le savoir.

Pas de commentaires »

Publié dans 2-alerte , Packet Décodage

Tags: Décodage de paquets

Défi tshark - Conseils 3

7 octobre 2009

Il s'agit de la troisième série de conseils pour relever le défi de décoder tshark j'ai publié la semaine dernière. Vous pouvez récupérer une copie du fichier de décoder depuis la page des défis .

Dans mon dernier post, nous avons repéré quelques divergences est le flux TCP. Prenons un examen plus attentif de la charge utile de voir si quelque chose semble hors de propos. La commande que je vais utiliser est la suivante:

tshark-r-challenge1.cap x | less

Si vous êtes sous Windows, remplacez le "moins" de commande avec le "plus" de commande.

L'option "-x" switch causera tshark d'imprimer les données utiles de chaque paquet avec le résumé en-tête. Si vous la page vers le bas pour 4 paquets, vous devriez voir:

4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrateur / HTTP/1.0 startstop.html
0000 00 20 d0 b0 E3 7d 00 50 8b 20 ch ab 08 00 45 00 ...} .. p.. ... E.
0010 01 11 96 00 00 2a 31 06 94 d2 cf 4e 0a f7 0c 21 ..* ... 1 .... ... N!
0020 04 69 f7 2a 00 50 6a 97 b8 3a 6f 88 39 80 18 .. cd i *. Pj .. o: 0,9 ...
0030 ff ff 42 fc 00 00 01 01 08 0a 00 CE 48 4b 3d 76 .. B ... ... ... HK = v
0040 0e 8b 47 45 54 20 2F 63 66 69 64 65 41 64 6d 2f .. GET / CFIDE / Adm
0050 69 6e 69 73 74 72 61 74 6f 72 2f 73 74 61 72 74 inistrateur / démarrage
0060 73 74 6f 70 2e 68 74 6d 6c 20 48 54 54 50 31 2f stop.html HTTP / 1
0070 2e 30 0d 0a 48 6f 73 74 3a 20 31 32 2e 33 33 2e .0 .. hôte: 12,33.
0080 32 34 37 2e 34 0d 0a 55 73 65 72 2d 41 67 65 6e 247.4 .. User-Agen
0090 74 20 4d 3a 7a 6f 69 6c 6c 61 2f 35 30 20 2e t 5b: Mozilla/5.0 [
00A0 65 6E 5d 20 28 57 69 6e 39 35 20 55 29 3b 0d 0a fr] (Win95; U) ..
00b0 52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f 2f Referer: http://
00C0 31 32 2e 33 33 2e 32 34 37 2e 34 2f 0D 0A 58 2d 12.33.247.4/..X-
00d0 46 6f 72 77 61 72 64 65 64 2d 46 6f 72 3a 20 31 Forwarded-For: 1
00e0 34 38 2e 36 34 2e 31 34 37 2e 31 36 38 0d 0a 43 48.64.147.168 .. C
00F0 61 63 68 65 2d 43 6f 6e 74 72 6f 20 6d 6c 3a 61 maux-Control: MA
0100 78 73 74 61 2d 6c 65 30 0d 0a 3d 50 72 61 67 6d x-stale = 0 .. Pragm
0110 61 20 3a 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a CE un: no-cache ... ..
0120 43 76 f8. Cv

C'est le "GET" demande le nom du fichier suspect. Il ya un couple de champs dans cette charge qui ne semble pas correcte. Les "Host:" champ doit identifier le serveur Web le client a tenté d'accéder. Cela devrait toujours être un nom de domaine pleinement qualifié, comme "www.fubar.com" ou similaire. Le fait que l'adresse IP du serveur est cotée me dit d'un navigateur Web n'a pas été utilisé pour générer cette session.

Il est possible d'héberger plusieurs sites Web sur le même serveur physique. Les chiffres de serveur quel site spécifique que vous souhaitez accéder, en analysant ce domaine hôte. Si les navigateurs Web n'a pas suivi cette règle, co-localisation des serveurs avec plusieurs sites hébergés sur la même case physique ne marcherait jamais. Donc cela me dit que le client va après le processus de serveur Web réel, pas un site Web hébergé sur le système.

Le "User-Agent:" champ semble étrange aussi. Alors qu'il est possible que le client est encore sous Windows 95, il est peu probable.

Le champ referer est incorrect aussi bien. Cela devrait nous montrer l'URI complète du client était l'accès quand ils ont été dirigés vers cette page. Elle doit inclure le nom de domaine pleinement qualifié, ainsi que la page exacte sur le site qui les a renvoyés à cette page. En fait, si le referer est un moteur de recherche, le champ sera aussi inclure ce paramètres de recherche ont été utilisés quand ils ont été dirigés vers notre site. Listing une adresse IP est complètement incorrect.

Il ya un dernier morceau d'information intéressante dans cette charge. Le "X-Forwarded-For:« champ nous indique que l'adresse IP source dans l'en-tête IP agit comme un proxy HTTP pour n'importe quelle adresse IP est répertoriée dans ce domaine. Il n'est pas rare pour les attaquants de faire rebondir leurs attaques hors d'un serveur proxy public. De cette façon, si vous détectez l'attaque dans votre journal des accès du serveur Web, vous penserez à l'adresse IP source est l'entité hostile comme le X-Forwarded-For champ ne sera pas répertorié.

Nous avons donc une demande de fichier suspect, à partir d'une IP qui essaie de cacher leur identité, en utilisant les paquets qui ont des valeurs suspectes. Nous n'avons pas besoin un IDS pour nous dire que c'est probablement un attaquant cherche un fichier connu pour être vulnérable.

Maintenant jetez un oeil à des paquets de 8 à 17. Chacun est le serveur tente de dire au client «Je suis désolé, je n'ai pas de ce fichier vulnérable. S'il vous plaît essayez un autre fichier vulnérable si vous voulez me compromettre », via 404 messages d'erreur.

Ainsi le flux va quelque chose comme ceci:

Le client envoie une sonde pour un fichier potentiellement vulnérables
Server réinitialise la connexion
Réinitialise la connexion du client
Server indique en permanence le client, il n'a pas ce fichier

Alors pourquoi le réinitialise et pourquoi le serveur les ignorer? Accordez demain pour le découvrir ...

Pas de commentaires »

Publié dans 3-err , Packet Décodage

Tags: Décodage de paquets

Tshark Challenge - Hints2

6 octobre 2009

Hier nous nous sommes quittés en prenant un premier regard sur le fichier décoder. Un premier passage nous a laissé se gratter la tête parce que nous avons vu une erreur 404 suivie par plusieurs retransmissions. Dans cette astuce nous allons creuser dans la trace un peu plus profond.

Revenons à notre décodage initial et suivi ce qui s'est passé paquet par paquet:

tshark-r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26922> http [SYN] Seq = 0 Win = 65535 Len = 0 MSS = 1460 WS = 0 TSV = 15485003 TSER = 0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [SYN, ACK] Seq = 0 Ack = 1 Win = 5792 Len = 0 MSS = 1460 TSV = 1031147147 TSER = 15485003 WS = 0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26922> http [ACK] Seq = 1 Ack = 1 Win = 65535 Len = 0 TSV = 15485003 TSER = 1031147147
4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrateur / HTTP/1.0 startstop.html
5 0.030841 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [ACK] Seq = 1 Ack = 222 Win = 6432 Len = 0 TSV = 1031147150 TSER = 15485003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed segment perdu] 26922> http [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
9 0.031664 12.33.247.4 -> HTTP HTTP/1.1 148.78.247.10 404 Not Found (text / html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [segment TCP d'un PDU remonté]

Nos trois premiers paquets sont la connexion TCP. Cette partie semble assez normal. En paquet de 4, nous voyons le client envoie un "GET" demande d'un fichier. Cette demande de fichier qui me frappe comme étant suspect. Un fichier nommé "startstop.html» dans l '«administrateur» du répertoire n'est pas exactement le son comme un fichier que nous voulons être au service au public au sens large. Nous allons faire une note de cela et y revenir plus tard.

En paquet de 5, nous voyons le serveur reconnaît la demande de données. Après ce paquet, les choses deviennent un peu étrange. En paquet de 6, nous voyons le serveur transmettre un paquet de réinitialisation de tuer la connexion. Ceci est une indication que le serveur se sent quelque chose a mal tourné avec la session et qu'il est irrécupérable. Ce comportement est très étrange pour TCP comme il essaie très fort pour être fiable. Il transmettra normalement plusieurs tentatives pour rétablir une connexion si elle pense que quelque chose s'est mal passé. Vous pouvez voir le comportement de récupération normale dans les paquets de 10 à 17, ce qui correspond plus étroitement la manière dont TCP essayera de maintenir la connectivité. Il ya une différence 0.5 ms dans l'horodatage des paquets entre 5 et 6. Un système d'exploitation normale ne serait jamais déterminer à qui court d'une période de temps que la session TCP est irrécupérable.

En paquet de 7, les choses continuent à agir étrangement. Nous voyons le client de répondre aux paquets de réinitialiser le serveur avec un paquet de réinitialisation de ses propres. Ce n'est certainement pas le comportement normal de propriété intellectuelle que l'état RFC vous ne devriez jamais répondre à un paquet d'erreur. Ainsi lors d'une séance normale, vous ne verraient jamais ce type d'échange d'erreur. Quelque chose est évidemment très mal.

En paquet de 9, nous voyons le serveur envoie un message d'erreur 404. Il ya un couple de problèmes ici. Pour commencer, le serveur déjà envoyé une réinitialisation indiquant qu'elle considérait la session d'être irrécupérables. Un système ne doit jamais continuer à envoyer des données après l'émission d'un paquet de réinitialisation. En fait, le serveur continue à transmettre tout le chemin à de paquets 17. Ce qui rend cette activité encore plus étrange est que le client a émis un reset ainsi. So the server is not only ignoring the fact that it issued a reset, it is also ignoring the reset sent by the client.

So needless to say this is very strange TCP behavior. In my next post I'll dig deeper into the payloads to get a better look at what is going on.

Pas de commentaires »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Tshark Challenge – Hints1

October 5th, 2009

Last week I posted a Libpcap file and challenged you to figure out as much as you could about the trace using tshark. In this post I'll start you through the process of analyzing the decode. I WIL NOT cover it completely. My goal here is to give a leg up to the folks who do not even know where to start. I'll add more details as the week goes on.

Pour commencer

The first thing you should do is have a look at the contents of the file. I'll use the –r switch to read in the contents of the file. This will override tshark's default setting of sniffing on the first detected interface. Normally I would pipe the output through the “less” command (or “more” on Windows), but there are only 17 packets in the file.

tshark -r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26922 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=15485003 TSER=0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http > 26922 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1031147147 TSER=15485003 WS=0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26922 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=15485003 TSER=1031147147
4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET /cfide/Administrator/startstop.html HTTP/1.0
5 0.030841 12.33.247.4 -> 148.78.247.10 TCP http > 26922 [ACK] Seq=1 Ack=222 Win=6432 Len=0 TSV=1031147150 TSER=15485003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed lost segment] 26922 > http [RST, ACK] Seq=1 Ack=222 Win=0 Len=0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
9 0.031664 12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found (text/html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Some details that immediately grab my attention:

This is an HTTP session
The connection attempted to access a file that does not exist (404 error in #9)
There were communication issues with the session (#10-17 are retransmissions)

So right away this trace leaves me asking a few questions:

What's up with the request for a file that does not exist?
Why are we having communication problems?

That's it for now. Tomorrow I'll post another hint.

Pas de commentaires »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Tshark Decode Challenge

October 2nd, 2009

In my last post I covered tshark and discussed how to manipulate the output during a decode. There is no better way to learn than by doing, so I decided to post a challenge. In this post I'll provide a Libpcap file. Your mission Mr. Phelps, should you choose to accept it, is to attempt to identify what is going on within the decode file using tshark.

Installing tshark

In order to install tshark, you need to install Wireshark. You can grab a current copy from the download page . Once you do, the installation process is dependent on what platform you are using:

Linux/UNIX

If you are running Fedora or Red Hat, you do not need to visit the download page. You can install Wireshark directly through Yum:

su –
yum –y install wireshark.i586

If you are running a UNIX flavor or some other Linux distro, you may need to grab the tar archive from the above link and compile Wireshark for your system. Pay close attention to the dependencies as there are a lot of them. Ensure that “./configure” completes successfully before building your binaries.

Sous Windows

Download the self-extracting executable
Run the executable
Accept Unknown Publisher screen by clicking “run” button
Follow the on-screen prompts accepting the defaults
Install WinPcap (make sure box is checked)
Install NPF service if non-Administrator users will be running the tool
Add “C:\Program Files\Wireshark” to the end of your path statement

OS X

Select the image that matches your processor type (Intel or PPC)
Open with DiskimageMounter
Open the “Read me first.rtf”
Follow the “Quick Setup” instructions

The challenge

Here's the challenge file:

challenge1.cap

And here are the hashes of the file to verify your download:

MD5: ea92f08d9ba104c6cf7756564eb5aef9 challenge1.cap
SHA-1: 71041ab0f670c5b9558183a56fe1bb80e8b10506 challenge1.cap

Good luck and starting next week I'll post a little more info about the file every day to help move you through the decode process.

Pas de commentaires »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Analyzing packets with tshark

October 1st, 2009

In an earlier post I discussed how to adjust the display output in tshark . The post generated a lot of interest, so I decided to add some additional information on using tshark to decode packets. This post assumes you have read the one linked to above.

Why use tshark instead of tcpdump/windump?

Beaucoup de décodeurs vieux temps ne jurent que par tcpdump , et son homologue sous Windows WinDump . Les deux sont d'excellents outils, mais ils sont devenus un peu daté. Alors que les correctifs sont encore publié de temps en temps, peu a été fait pour mettre à jour ou développer leur capacité de décoder. Wireshark d'autre part, ainsi que c'est inclus des outils tels que tshark, notamment de décoder le soutien pour des centaines de protocoles et la liste s'allonge tout le temps. Alors que vous pouvez certainement analyser les paquets sans les décodeurs, ils rendent le processus plus rapide aller bien loin.

Pourquoi utiliser tshark lieu de Wireshark?

Wireshark est un outil formidable quand vous faites une analyse de la charge utile en profondeur. Il peut être un peu fastidieux cependant si vous souhaitez suivre un domaine spécifique sur plusieurs paquets. Par exemple, disons que nous souhaitons pour regarder l'incrément numéro de séquence TCP sur plusieurs paquets. Avec Wireshark, je dois noter l'emplacement numéro de séquence dans le panneau du milieu et à la page grâce à chaque paquet. Comme il n'existe aucun moyen d'aligner la valeur sur plusieurs paquets, je suis obligé de rappeler les valeurs précédentes lorsque l'exercice de mes calculs. Avec tshark cependant, nous pouvons faire quelque chose comme ceci:

tshark-n-T champs e-ip.src-e-e tcp.seq tcp.len
64.111.96.38 0 0
64.111.96.38 1 0
64.111.96.38 1 363
64.111.96.38 364 1448
64.111.96.38 1812 1448
64.111.96.38 3260 1448
64.111.96.38 4708 1448
64.111.96.38 6156 1448
64.111.96.38 7604 1448
64.111.96.38 10500 310
64.111.96.38 9052 1448
64.111.96.38 10810 0

Rappelez-vous que le numéro de séquence TCP (le second champ) doit incrémenter basé sur la taille de la charge utile (le troisième champ). Notez que les paquets 10 et 11 où reçus dans le désordre. Cela pourrait signifier il ya plusieurs chemins disponibles entre notre situation et l'adresse IP identifiée. Alors que Wireshark serait de nous montrer ces informations aussi bien, dans cette vue, il est un peu plus facile de suivre le flux.

Plus sur l'affichage des champs

Comme discuté dans mon post plus haut, ainsi que montré ci-dessus, l'option "-T" commutateur peut être utilisé pour manipuler la sortie affichée. Vous pouvez choisir à partir de XML, Postscript ou en texte brut. L'option la plus utile est «champs», comme il vous permet de choisir les domaines spécifiques que vous voulez imprimer. Comme indiqué ci-dessus, l'option "-e" commutateur peut alors être utilisé pour identifier les champs que vous souhaitez afficher. La liste complète des filtres peuvent être trouvés ici . Une antisèche belle des valeurs les plus couramment utilisés peuvent être trouvés ici .

Si vous définissez un protocole spécifique, tshark affiche quelques-uns des champs les plus importants de cette tête. Par exemple à regarder seulement la tête Ethernet:

tshark-T champs e-ETH
Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: fe: ef (f 00:12:03: d1: fe: EF)
Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: fe: ef (f 00:12:03: d1: fe: EF)
Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: fe: ef (f 00:12:03: d1: fe: EF)

Notez le type et les champs CRC ne sont pas affichés, car ils ne sont pas aussi «intéressant» comme la source et adresse MAC de destination. Nous aurions à définir spécifiquement ces domaines (et ip.type ip.trailer) si nous souhaitons les voir.

Un effet secondaire de champs d'impression est que tshark va ajouter une ligne vierge pour tous les paquets qui ne contient pas le champ spécifié. Ce peut être une douleur lors de l'analyse des paquets HTTP que pas tous les paquets contiennent un URI. Un moyen facile de nettoyer cette place, c'est de tuyau à travers grep. Par exemple:

tshark-T champs e-http.request.uri | grep-v "^ $"
/
/ Styles.css
/ Templates / classic / images / starsnstripes.gif
/ Templates / classic / images / unionjack.gif
/ Templates / classic / images / amazon.header.gif
/ C_images/2009/05/07/71090.2.jpg

Dans mon dernier post j'ai discuté grep ainsi que l'endroit où récupérer une version gratuite pour Windows. The above grep command uses the “-v” switch to match all lines that do not contain the specified value. “^$” defines a blank line. So the above grep command filters out all blank lines.

More display options

Tshark has a number of other useful display options. For example you can print headers at the beginning of the output:

tshark -n -T fields -e ip.src -e ip.dst -E header=y
ip.src ip.dst
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100

If you plan on importing the information into a spreadsheet or database, you can define which character to use between fields:

tshark -T fields -e ip.src -e ip.dst -e tcp.dstport -E header=y -E separator=;
ip.src;ip.dst;tcp.dstport
64.111.96.38;12.5.200.100;34831
64.111.96.38;12.5.200.100;34831
64.111.96.38;12.5.200.100;34831

Packet statistics

Tshark has solid statistical capability as well. If you need to process a lot of files, sometimes it is help to start with looking at the raw stats. The “-z” switch is used to specify the statistics you wish to analyze. Normally these will be printed at the end of the decode information, but if you use the “-q” switch only the stats will be printed. Voici un exemple:

C:\testing>tshark -q -z http,stat, -z http,tree -r test.cap
===============================================================
HTTP/Packet Counter value rate percent
——————————————————————-
Total HTTP Packets 64915 0.048999
HTTP Request Packets 459 0.000346 0.71%
GET 24 0.000018 5.23%
HEAD 433 0.000327 94.34%
OPTIONS 2 0.000002 0.44%
HTTP Response Packets 448 0.000338 0.69%
???: broken 0 0.000000 0.00%
1xx: Informational 0 0.000000 0.00%
2xx: Success 12 0.000009 2.68%
200 OK 12 0.000009 100.00%
3xx: Redirection 0 0.000000 0.00%
4xx: Client Error 436 0.000329 97.32%
404 Not Found 432 0.000326 99.08%
403 Forbidden 4 0.000003 0.92%
5xx: Server Error 0 0.000000 0.00%
Other HTTP Packets 64008 0.048314 98.60%
===============================================================
===============================================================
HTTP Statistics
* HTTP Status Codes in reply packets
HTTP 200 OK
HTTP 403 Forbidden
HTTP 404 Not Found
* List of HTTP Request methods
GET 24
OPTIONS 2
HEAD 433
===============================================================

A couple of things stick out in this output. First, we have four 403 errors indicating that someone was attempting to access something they did not have permission to. Also, out of 459 HTTP requests, 432 of them were for non-existent files. We are also seeing a lot of “HEAD” requests which could be a proxy, or could be an attacker attempting to keep from being logged to the Web server's access log. Clearly this capture file includes some suspect traffic that warrants further investigation.

Tshark can even produce general throughput statistics if you need them. This is an excellent way to check for DoS attacks:

tshark -q -z io,stat,10 -r test.cap
===============================================================
IO Statistics
Interval: 10.000 secs
Column #0:
| Column #0
Time |frames| bytes
000.000-010.000 254 145081
010.000-020.000 145 80003
020.000-030.000 125 65527
030.000-040.000 4 264
===============================================================

Note tshark will print the frame and byte count for any interval specified, defined in seconds. The only problem is that if you are capturing packets off of the wire, stats are not displayed until the capture ends.

Résumé Exec

Tshark is an extremely capable packet analysis tool that has surpassed it's counterparts tcpdump and windump. Combine the extensive decode capability along with the flexible output display, and tshark has become the tool of choice for many packet decoders.

Pas de commentaires »

Posted in 2-alert , Network Security , Packet Decoding

Tags: Packet Decoding