Archief voor oktober, 2009

Paaien Een CMD Prompt Van MS Word of Excel

15 oktober 2009

Dit is een oude truc, maar ik zie nog steeds een aantal beheerders die denken dat ze gebruikers geblokkeerd uit de command prompt door simpelweg verwijderen van de icoon in het menu en het uitschakelen van de Start-> Uitvoeren optie. In deze post bespreek ik hoe je een command prompt met Visual Basic for Applications (VBA), en hoe te verzachten (hoewel nooit volledig uit te schakelen) het risico van iemand die het bereiken van de toegang tot de prompt te creëren.

Het creëren van een command prompt met VBA

Deze techniek werkt met elke toepassing die VBA ondersteunt, maar ik ben speciaal naar Microsoft Word te gebruiken in mijn voorbeeld. Hier is wat je moet doen:

Lancering van Microsoft Word
Druk op "ALT-F11" om de VBA-editor te starten
Dubbelklik op "ThisDocument" in het linkerpaneel
Wanneer het editor venster verschijnt, typt u de tekst weergegeven in figuur # 1
Druk op de "F5" toets

Figuur 1: Onze eenvoudige VB script

U ziet nu een command prompt venster in de taakbalk. Hier is een kopie van de code die je nodig hebt in stap 4, zodat u kunt kopiëren / plakken:

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

Hoe kan ik VBA te voorkomen dat paaien een opdrachtprompt

Uitvoering van de command prompt kan worden uitgeschakeld met de Group Policy Editor tool. Hier zijn de stappen:

Klik op Start -> Uitvoeren
Type in "gpedit.msc" (zonder de aanhalingstekens)
Klik op Gebruikersconfiguratie -> Beheersjablonen -> Systeem
Zoek in de lijst voor "Voorkom toegang tot de opdrachtprompt" en dubbelklik erop

Je hebt twee opties voor u beschikbaar:

Inschakelen / uitschakelen toegang tot de opdrachtprompt
Ja / Nee Disable command prompt scripting-proces

Als je alleen uitschakelen van de eerste optie, directe toegang tot cmd.exe wordt voorkomen, maar een slimme gebruiker kan nog steeds om het te krijgen via een batch-bestand. Om te voorkomen dat script toegang, moet u de tweede optie uit te schakelen ook. Dit voorkomt dat ALLE scripting echter en kan voor chaos spelen in tal van omgevingen. Ook zullen beide van deze instellingen van toepassing zijn op de Administrator-account ook. Dit kan admin en het oplossen van problemen veel moeilijker.

Zelfs met beide opties uitgeschakeld, kan een gebruiker nog steeds rond deze instellingen door gebruik te maken command.com in plaats van cmd.exe. Om dit te verhelpen, moet u toegang hebben tot command.com via gebruikersrechten te beperken. Als u nog steeds een aantal oude 16-bit apps, zal deze oplossing breken.

Al deze stappen niet volledig maar het probleem oplossen. Een gebruiker die weet wat ze doen met debug kan eenvoudig kopiëren cmd.exe naar een andere locatie en pas het zo een prompt wordt bereikt wanneer u deze gebruikt om een nep commando uit te voeren. Dus we moeten ook "Debug.exe" te verwijderen.

Zelfs dan kan een savvy programmeur een uitvoerbaar om rond al het bovenstaande veiligheidscontroles. Dus we moeten alle mogelijkheden te kopiëren of te schrijven naar het station ook te verwijderen. Onnodig te zeggen dat we een behoorlijk nutteloos computer op dat punt.

Exec Samenvatting

Als iemand slim toegang heeft tot uw systeem, is het twijfelachtig bent u in staat om hem of haar te beletten om naar de opdrachtregel. De Group Policy Editor kan zeker het moeilijker maken, maar de tool gewoon vermindert het risico van een aanval. Je kunt niet volledig elimineren het risico zonder een ernstige rem op het systeem werking en bruikbaarheid.

Geen reacties »

Posted in 4-notice , Windows Security

Tags: windows opdrachtregel Windows-beveiliging Windows tips

PDF van "Bescherming tegen gerichte aanvallen" praten

14 oktober 2009

In de komende weken zal ik het geven van deze lezing op een aantal locaties. Voor degenen die bezocht en verzocht om een PDF-versie van de dia's, hier is de link die ik beloofd: het beschermen-tegen-gerichte-aanvallen-R2

3 reacties »

Geplaatst in drie-err , Algemene Beveiliging

Tags: applicatie whitelisting Malware

Tshark Challenge - Uber-geek Antwoord

13 oktober 2009

In mijn laatste bericht ik je met een vraag: Gegeven wat we gezien hebben in het decoderen bestand met tshark, welke impact (indien aanwezig) zou er zijn als we plaatsen een stateful inspection firewall tussen de aanvaller en de webserver? Met andere woorden, als de aanvaller is een packet sniffer lopen, zouden ze nog steeds de webserver uitlekken 404 fouten?

En het antwoord is ...

Misschien.

Niet alle stateful inspectie firewalls zijn gelijk. Sommige pakketten handvat iets anders dan anderen. Bijvoorbeeld sommige (zoals Checkpoint, Netscreen en anderen) laat niet-SYN-pakketten toe te staan de regels het genereren van nieuwe state tabel vermeldingen. Sommige (Cisco, Netfilter en anderen) zal alleen het genereren van een staat tafel met de juiste sessie vestiging (moet TCP drie packet handshake zien).

De NIPS stuurde een geldige reset pakket om de aanvaller op het internet. Elk van de bovenstaande firewalls zou zien op de reset-pakket en verwijder het de toetreding van de staat tafel. Als de webserver bleef echter te communiceren, dan zou alleen de eerste set van firewalls laten de pakketten lekken naar de aanvaller. De tweede set van firewalls zou gewoon vallen het verkeer. Sterker nog als we ze met een regel ontkennen in plaats van een druppel regel, zouden ze de sessie te doden op de webserver zodat de vaststelling van het probleem gecreëerd door de NIPS.

Waarom hebben sommige leveranciers laten erkenning pakketten te genereren nieuwe staat tabel entries? Dit lijkt een beetje contra-intuïtief als een legitieme sessie zal altijd beginnen met een SYN-pakket. Er zijn twee redenen dit maakt goede functionele zin:

Het bijwerken van de firewall-regels doodt geen actieve sessies
Active-active setup zal voorafgaand doorgeven verkeer naar state table synchroniseren

Natuurlijk hebben we meer functionaliteit ten koste van de veiligheid. Helaas is dat is de typische afweging.

Hoop dat je had plezier met deze uitdaging. Als er interesse is zal ik posten in de toekomst meer.

2 reacties »

Posted in 2-alert , Network Security , Packet Decoding

Tags: firewall netwerkbeveiliging Packet Decoding

Tshark Challenge - The Final antwoorden

09 oktober 2009

In mijn laatste bericht hadden we vastgesteld dat de trace-bestand een sessie waar een enkele geslepen netwerk op basis van intrusion prevention-systeem had geprobeerd om een aanval van een HTTP-client stoppen om een webserver bevatte. We concludeerden dat de klant gegevens op te vragen zag er nogal verdacht, en bleek een derde systeem (de NIP's) verantwoordelijk was voor de reset-pakketten die tijdens de sessie.

In dit bericht moeten we nog twee vragen te beantwoorden:

Was de aanval succesvol?
Waarom heeft de webserver voorbij aan het TCP-reset pakket verzonden door de NIPS?

Was de aanval succesvol?

De aanvaller was op zoek te identificeren wanneer het bestand "startstop.html" was gelegen in het "Administrator" directory. Laten we eens een kijkje nemen bij een van de pakketjes verstuurd naar de aanvaller na de reset-pakketten zijn verzonden:

tshark-n-r challenge1.cap-x frame.number == 11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
0000 00 50 8b ea 20 ab 00 b0 d0 20 7d e3 08 00 45 00. P.. .... } ... E.
0010 01 a7 37 47 40 00 40 06 73 0c 8b 21 f7 04 94 4e .. 7G @. @. S..! ... N
0020 f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19 ... Pi *:.. 0,9 j. L..
0030 19 20 8c d4 00 00 01 01 08 0a 3d 76 0E d3 00 ec. ... ... ..= V ....
0040 48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e HKHTTP/1.1 404 N
0050 6f 74 20 46 6f 75 6e 64 0d 0a 44 61 74 65 3a Gevonden 20 ot .. Datum:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 dinsd. De 25 juni 2002
0070 20 30 30 3a 33 34 3a 35 38 20 47 54 4d 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 6f 73 65 onnection: close
00a0 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 .. Content-Type:
00b0 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 text / html; chars
00c0 65 74 3d 69 73 6f 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 2f PUBLIC "- / / IETF /
00f0 2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45 / DTD HTML 2.0 / / E
0100 4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e N ">. <HTML> <HEAD>
0110 0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20. <TITLE> 404 Niet
0120 46 75 6f 6e 64 2f 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 3c 48 31 3e HEAD> <BODY>. <H1>
0140 4e 6f 74 20 46 6f 75 6e 64 2f 3c 48 31 3e 0a 54 niet gevonden </ H1>. T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c hij verzocht URL
0160 20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74 / CFIDE / administ
0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e configurator / StartStop.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75 html was niet fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 e op dit dienen
01a0 72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 r. <P>. </ BODY> </ H
01b0 54 4d 4c 3e 0a 00 03 00 07 TML> ... ..

Dus het antwoord op de vraag van de aanvaller: "Is het bestand op de server, wordt beantwoord in elk pakket de server in te stellen aan de klant na de reset packets werden uitgegeven?. Nu wordt de vraag, heeft de aanvaller zien deze informatie?

Toen de reset pakket is verzonden naar de aanvaller, moet de reset hebben gedood de TCP-sessie. Dit betekent dat wanneer deze gegevens aankwam, de ontvangende poort (TCP/26922) moeten zijn in een gesloten toestand. Had dit in feite waar was, zou ik verwachten te zien een reset / ACK terug te komen van de aanvaller het systeem ons te vertellen dat TCP/26922 nu gesloten is. We hebben nooit zien die pakketjes.

Dus waarom niet de externe poort sluiten? De reset pakket is geldig, dus het zou gedood hebben de sessie. Een savvy aanvaller gaat een packet sniffer op de achtergrond tijdens het uitvoeren van hun aanval. Het is mogelijk dat de aanvaller zou hebben bedacht wat er gaande was en eenvoudig creëerde een firewall beslist over de aanval systeem filteren van alle inkomende pakketten opnieuw in te stellen. Dit zou hebben toegestaan hun instrument te blijven functioneren. Zelfs zonder de firewall filter hun packet sniffer zouden de antwoorden die ze zoeken bevatten. Dus er is een zeer goede kans van de aanvaller heeft bedacht wat we zijn kwetsbaar voor, ondanks het feit een NIPS is het netwerk te beschermen.

Waarom heeft de webserver te negeren de reset-pakket?

Onze laatste vraag is waarom heeft de webserver te negeren op de reset-pakket verzonden door de NIPS. Dit veroorzaakt twee problemen:

De info van de aanvaller wilde blijft lekken
Als de aanvaller niet meerdere bestanden sondes, konden ze vullen de sessie tabel op de webserver

Het tweede item is een soort van eng, want het zou eigenlijk de NIPS waardoor de DoS-aanval worden slechts door het doden van een kant van de verbinding naar behoren. Dus zelfs als we gepatcht en up-to-date, vendor gear betaalden we geld voor zou uiteindelijk het doden van onze webserver. Gee Ik haat het als ik geld uitgeven voor DoS mezelf.

Laten we nog eens kijken naar die reset packets:

tshark-n-r challenge1.cap frame.number == 6 of 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 verloren segment] 26922> 80 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

Merk op dat tshark vertelt ons pakket 7 is een verloren segment. Met andere woorden, is tshark vertelt ons dat de TCP sequence nummer niet binnen het venster van de gastheer wordt verwacht. Een blik op de volgorde en erkennen nummers legt uit waarom. De waarden zijn identiek aan die in pakket 6. Misschien herinner je je van de laatste post die packet 6 en 7 ook dezelfde IP ID waarde (45.298) had.

Dus het lijkt erop dat hier is wat er gebeurde:

Client stuurde een HTTP-aanval op onze web-server
NIPS ontdekt de aanval
NIPS stuurde een geldige TCP teruggezet naar de aanvaller om de sessie te doden
NIPS ruilde de bron en doel-IP-adressen in het pakket, herberekend de CRC's, en vervolgens verzonden op dezelfde resetten naar de webserver
Webserver negeert de reset, want het bevat geen aanvaardbare volgnummer

Je vraagt je misschien af, "Hoe is de leverancier miss this?". Mijn beste gok is dat de verkoper een aantal gesimuleerde aanvallen liepen, de aanval gereedschap niet laten zien kwetsbare bestanden, zodat ze nam alles was OK werken. Met andere woorden, een leverancier die een product gecreëerd om netwerken te beschermen op de draad nooit de moeite genomen om te kijken naar wat hun product was eigenlijk aan het doen op de draad. Hummm ...

Bonusvraag

OK, als je plezier hebt met deze, hier is een bonus vraag om te beantwoorden die definitief zal je uber-nerd-status te tonen op de top van de geheime piramide:

Veronderstel dat we plaatsen een stateful inspection firewall tussen deze subnet en de aanvaller. Zal de aanvaller nog steeds in staat zijn om de antwoorden met een packet sniffer zien?

Ik kom na het antwoord volgende week.

Geen reacties »

Posted in 2-alert , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Tips 4

8 oktober 2009

In mijn laatste bericht hebben we vastgesteld dat het client-systeem was waarschijnlijk een soort van hulpmiddel om sonde voor het bekend is dat kwetsbare bestanden draaien. We moeten nog wel uit te leggen op de reset-pakketten, evenals de reden waarom de server was ze te negeren.

Op dit moment hebben we weten niet eens waar dit packet capture werd genomen in verband met de twee eindpunten. Ik ga tshark uitgevoerd met de "-T-gebieden"-schakelaar af te drukken van de TTL informatie. Door het analyseren van de TTLS, moeten we in staat om te bepalen waar we snuffelen in relatie tot de client en de server. Ik ben ook ter perse gaan van de IP-id's om te zien of er sprake is van afwijkingen in het pakket te bestellen.

Hier is de opdracht en de output:

tshark-r challenge1.cap-T-gebieden-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 12.33.247.4 80 64 0x374a
15 12.33.247.4 80 64 0x374b
16 12.33.247.4 80 64 0x374c
17 12.33.247.4 80 64 0x374d

148.78.247.10 is de opdrachtgever. We weten dat omdat het initiatief van de sessie en de communicatie met behulp van een hogere bron poort. 12.33.247.10 is onze HTTP-server communicatie van de haven 80.

In pakket 1 zien we de klant heeft een TTL van 49. De dichtstbijzijnde start TTL match voor een bekende besturingssysteem is 64, dus dit geeft ons de klant is een Linux-, UNIX-of Mac-systeem vergadering 15 hops weg. In pakket 2 zien we de server met een TTL-waarde van 64, dus het moet een van de eerder genoemde besturingssystemen zitten op het lokale netwerk. Dus, we zijn op dezelfde botsing domein als de server, maar zat 15 hop uit de buurt van de klant.

Er is echter een probleem. Kijk naar packets 6 en 7. Hier zien we de TTL van beide systemen te veranderen naar 255. Een besturingssysteem zal nooit het TTL veranderen tijdens een sessie, dus dit ziet er zeer verdacht. Verder hebben we al vastgesteld dat de klant is 15 hop zit bij ons vandaan. 255 is de grootst mogelijke TTL-waarde als de TTL veld slechts een enkele byte (byte 8 in de IP-header). Dus zelfs als de bron IP-adres beweert de remote client, is er geen manier dat pakket kan overal, maar vanaf het lokale netwerk zijn ontstaan. Als het pakket waren overgestoken een of meer routers, zou de TTL-waarde lager zijn.

Het IP-ID informatie ziet er niet goed zijn. In de eerste drie pakketten van de client zien we de IP ID waarden 0x2a6b (10.859), 0x2a95 (10.901), en 0x2a96 (10.902). Dit vertelt ons de klant is mogelijk met behulp van een +1 incrementele IP ID, we gewoon niet zien 42 van de pakketten tussen de verzonden eerste en tweede pakket. De volgende IP ID zien we vanuit de klant is 0xb0f2 (45.298). OK, tenzij wij misten meer dan 34.000 pakketten, dit IP-ID niet jive.

Let op de bovenstaande analyse zou slechts theoretisch, ware het niet voor de inconsistente TTL waarden. Met slechts drie pakketten om naar te kijken, kunnen we niet precies identificeren van de IP ID te verhogen. Het is ook mogelijk, maar zeer zeer onwaarschijnlijk, dat het IP ID toename is volledig willekeurig en het systeem toevallig twee incrementele IP-id's, een direct na de ander toe te wijzen. Nog steeds, combineren de TTL-en IP-ID-informatie bij elkaar en zij geven aan dat dit laatste pakket niet kon zijn ontstaan uit hetzelfde systeem.

We hebben meer IP ID gegevens van de server om mee te werken, dus laten we eens kijken naar dat. De id's zijn:

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

Neem een kijkje op de derde lijst IP ID, dat is van packet 6 in het trace. Merk op dat alle andere IP-id's zijn incrementeel +1, maar dit IP ID hoort niet. In feite kunnen we laten zien dat de server stappen is het IP ID met +1 en dat er geen manier is dit pakket afkomstig van de server.

Humm. Ik vraag me af of deze verdachte pakketjes line-up met de vreemde zet zagen we:

tshark-r challenge1.cap-T-gebieden-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 een
7 148.78.247.10 26922 255 0xb0f2 een
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 12.33.247.4 80 64 0 0x374a
15 12.33.247.4 80 64 0 0x374b
16 12.33.247.4 80 64 0 0x374c
17 12.33.247.4 80 64 0 0x374d

Ah ha! Dus als we kijken naar de pakketjes met de vreemde TTL en IP ID waarden, dit waren de vreemde reset pakketten die worden verzonden tijdens de sessie.

Het lijkt mij zoals sommige derde systeem is springen in het gesprek om de reset-pakketten te verzenden. Aangezien deze vreemde pakketjes hebben een TTL van 255, we weten dat het moet zich op dezelfde botsing domein als waar we zijn snuiven. Aangezien het zich op dezelfde botsing domein, kan de Ethernet-header informatie nuttig zijn:

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

Dus als de klant komt van het internet, het door een HP-systeem als ofwel een router of een firewall. Onze webserver wordt uitgevoerd op Dell-hardware. Let op onze reset (pakketten 6 en 7) zijn beide wordt gegenereerd door hetzelfde systeem met behulp van een D-Link NIC.

Dus waarom heeft de D-Link systeem te proberen om de sessie te doden? Dit gebeurde net nadat de opdrachtgever stuurde het verdachte bestand te vragen. Het lijkt mij als de D-Link systeem is eigenlijk een geslepen intrusion prevention system (IPS). Wanneer een aanval wordt gedetecteerd, de IPS pogingen om de aanval te voorkomen door het verzenden van reset-pakketten naar beide uiteinden van de verbinding.

Maar we hebben nog een aantal onbeantwoorde vragen. Was de aanval succesvol en waarom heeft de server verschijnen om de IPS's poging om de sessie te doden negeren?

Draai in de volgende episode uit te vinden.

Geen reacties »

Posted in 2-alert , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hints 3

7 oktober 2009

Dit is de derde reeks van tips om de tshark decoderen uitdaging die ik vorige week uitgegeven. U kunt grijpen een kopie van het decoderen bestand van de uitdaging pagina .

In mijn laatste bericht hebben we gespot enkele discrepanties is de TCP-stroom. Laten we eens een kijkje op de payload om te zien of er iets kijkt uit op zijn plaats. De opdracht zal ik gebruikt, is:

tshark-r challenge1.cap-x | less

Als u werkt op Windows, vervangt u de "minder" commando met de "meer" commando.

De "-x"-schakelaar zorgt ervoor dat tshark om de lading van elk pakket af te drukken samen met de header samenvatting. Als u pagina naar pakket 4 je moet zien:

4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrator / startstop.html HTTP/1.0
0000 00 b0 d0 20 7d e3 00 50 8b ea 20 ab 08 00 45 00 ...} .. P.. ... E.
0010 01 11 2a 96 00 00 31 06 cf d2 94 4e f7 0a 0c 21 ..* ... 1 .... N ...!
0020 f7 04 69 2a 00 50 6a 97 b8 6f 3a 88 39 80 18 cd .. i *. Pj .. o: 0,9 ...
0030 ff ff 42 fc 00 00 01 01 08 0a 00 ec 48 4b 3d 76 .. B ... ... ... HK = v
0040 0E 8b 47 45 54 20 2f 63 66 69 64 65 2f 41 64 6d .. GET / CFIDE / Adm
0050 69 6e 69 73 74 72 61 74 6f 72 2f 73 74 61 72 74 inistrator / start
0060 73 74 6f 70 2e 68 74 6d 6c 20 48 54 54 50 31 2f stop.html HTTP / 1
0070 2e 0d 0a 30 48 6f 73 74 3a 20 31 32 2e 33 33 2e 0,0 .. Host: 12,33.
0080 32 34 37 34 0d 0a 2e 55 73 65 72 2d 41 67 65 6e 247.4 .. User-Agen
0090 74 20 3a 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 5b t: Mozilla/5.0 [
00a0 65 6e 5d 20 28 57 69 6e 39 35 3b 20 55 29 0d 0a en] (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 6c 3 bis, 20 6d 61 pijn-Control: ma
0100 78 2d 73 74 61 6c 65 30 0d 0a 3d 50 72 61 67 6d x-muffe = 0 .. Pragm
0110 61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ce een: no-cache ... ..
0120 f8 43 76. Cv

Dit is de "GET" verzoek om het verdachte bestand naam. Er zijn een paar van de velden in deze payload die niet goed kijken. De "HOST:" veld moet bepalen welke webserver van de klant was een poging om toegang te krijgen. Dit moet altijd een volledig gekwalificeerde domeinnaam, zoals "www.fubar.com" of iets dergelijks. Het feit dat de server het IP-adres is vermeld vertelt me een webbrowser is niet gewend aan deze sessie te genereren.

Het is mogelijk om meerdere websites hosten op dezelfde fysieke server. De server cijfers welke specifieke site die u wilt toegang door het analyseren van deze host veld. Als Web browsers niet deze regel, co-locatie servers volgen met meerdere vestigingen gehost op dezelfde fysieke doos zou nooit werken. Dus dit zegt me dat de klant gaat na het eigenlijke webserver proces, niet een website gehost wordt op het systeem.

De "User-Agent:" veld ziet er vreemd uit ook. Hoewel het mogelijk is de client is nog steeds Windows 95 draaien, is het onwaarschijnlijk.

De referer veld is onjuist ook. Dit moet tonen ons de volledige URI van de klant was de toegang tot toen ze werden doorverwezen naar deze pagina. Het moet de volledig gekwalificeerde domeinnaam, evenals de exacte pagina op de site die ze verwezen naar deze pagina. In feite als de referer is een zoekmachine, zal het veld ook wat zoeken parameters werden gebruikt toen ze werden doorverwezen naar onze site. Listing een IP-adres is volledig onjuist.

Er is nog een laatste interessant stukje informatie in deze payload. De "X-Forwarded-For:" veld vertelt ons dat de source IP-adres in de IP-header is als een HTTP-proxy voor wat het IP-adres is opgenomen in dit gebied. Het is niet ongewoon voor aanvallers om hun aanvallen te stuiteren van een publieke proxy server. Op deze manier als je de aanval te detecteren in uw web server log, zult u denken dat de bron IP-adres is het vijandige entiteit als de X-Forwarded-For veld wordt niet vermeld.

Dus we hebben een verdachte bestand verzoek van een IP dat is proberen om hun identiteit te verbergen, met behulp van pakketten die verdachte waarden hebben. We hebben geen behoefte aan een IDS om ons te vertellen is dit waarschijnlijk een aanvaller op zoek naar een bekende te kwetsbaar bestand.

Neem nu een kijkje op packets 8 tot en met 17. Ieder is van de server probeert de klant "Het spijt me, ik ben niet lopen dat kwetsbare bestand te vertellen. Probeer een verschillende kwetsbare bestand als je me wilt compromis ", via 404 foutmeldingen.

Dus de stroom gaat ongeveer als volgt:

Client stuurt een sonde voor een potentieel kwetsbaar bestand
Server reset van de verbinding
Client reset van de verbinding
Server geeft voortdurend de klant het niet hebben dat bestand

Dus waarom de reset en waarom negeren de server hen? Stem af morgen om uit te vinden ...

Geen reacties »

Geplaatst in drie-err , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hints2

06 oktober 2009

Gisteren zijn we vertrokken uit het nemen van een eerste blik op het decoderen bestand. Een first-pass liet ons krassen op ons hoofd omdat we zagen een 404-fout, gevolgd door meerdere doorgifte. In deze tip gaan we graven in het spoor een beetje dieper.

Laten we terug gaan naar onze eerste decoderen en te volgen wat er gebeurd is packet wordt door pakket:

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 verloren 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 doorgifte] [TCP-segment van een opnieuw gemonteerd 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 doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]

Onze eerste drie pakketten zijn de TCP-handshake. Dit gedeelte ziet er vrij normaal. In pakket 4 zien we de klant te sturen een "GET" verzoek voor een bestand. Dit bestand verzoek lijkt mij verdacht. Een bestand met de naam "startstop.html" in de "Administrator" directory niet exact klinken als een bestand dat we zouden willen worden dienen tot aan het grote publiek. We maken een notitie van deze en keer terug naar het later.

In pakket 5 zien we de server erkennen de gegevens op te vragen. Na dit pakket, dingen een beetje vreemd. In pakket 6, zien we de server zendt een reset pakket om de verbinding te doden. Dit is een aanwijzing dat de server voelt er iets mis gegaan met de sessie en dat het onherstelbaar. Dit is uiterst vreemd gedrag voor TCP als het probeert heel moeilijk om betrouwbaar te zijn. Het normaal gesproken zendt meerdere pogingen om een verbinding te herstellen als hij denkt dat er iets fout is gegaan. U kunt zien dat het herstel normaal gedrag in pakketten 10 tot en met 17, die beter overeenkomt met hoe de TCP zal proberen om de connectiviteit te behouden. Er is een 0.5 ms verschil in de timestamp tussen de pakketten 5 en 6. Een normale besturingssysteem zou nooit vast te stellen in die korte tijd dat de TCP-sessie onherstelbaar is.

In pakket 7, dingen blijven vreemd handelen. Wij zien de klant te resetten van de server pakket reageren met een reset pakket van zijn eigen. Dit is zeker niet normaal IP-gedrag als de RFC's staat moet je nooit te reageren op een fout pakket. Dus tijdens een normale sessie zou je nooit dit soort fouten te wisselen. Iets is natuurlijk heel erg verkeerd.

In pakket 9, zien we de server stuurt een 404 foutmelding. Er zijn een paar van de problemen hier. Om te beginnen, de server al verstuurd een reset wat aangeeft dat hij beschouwd als de sessie te zijn hersteld. Een systeem mag nooit doorgaan met het verzenden van gegevens na de afgifte van een reset pakket. In feite is de server blijft te zenden de hele weg naar pakket 17. Wat maakt deze activiteit nog vreemder is dat de cliënt heeft een reset uitgegeven ook. Dus de server is niet alleen het negeren van het feit dat het een reset uitgegeven, is het ook het negeren van de reset die door de klant.

Dus onnodig om te zeggen dit is heel vreemd TCP gedrag. In mijn volgende post zal ik dieper ingaan op de payloads om een beter kijken naar wat er aan de hand te krijgen.

Geen reacties »

Geplaatst in drie-err , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hints1

05 oktober 2009

Vorige week postte ik een libpcap bestand en uitgedaagd om erachter te komen zoveel als je zou kunnen over het spoor met behulp van tshark. In deze post zal ik beginnen met u door het proces van het analyseren van de decoderen. Ik WIL NIET volledig bedekken. Mijn doel hier is om een poot te geven aan de mensen die niet eens weet waar te beginnen. Ik zal meer details toevoegen als de week vordert.

Aan de slag

Het eerste wat je moet doen is een blik op de inhoud van het bestand. Ik zal gebruik maken van de-r switch te lezen in de inhoud van het bestand. Dit zal override tshark de standaardinstelling van snuiven op de eerste gedetecteerde interface. Normaal gesproken zou ik pijp de uitvoer door middel van de "minder" commando (of "meer" op Windows), maar er zijn slechts 17 pakketten in het bestand.

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 verloren 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 doorgifte] [TCP-segment van een opnieuw gemonteerd 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 doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP doorgifte] [TCP-segment van een opnieuw gemonteerd PDU]

Enkele details die direct grijpen mijn aandacht:

Dit is een HTTP-sessie
De verbinding geprobeerd een bestand dat niet bestaat (404 fout in # 9) toegang
Er waren problemen met de communicatie van de sessie (# 10-17 zijn uitzending)

Dus meteen dit trace laat me enkele vragen:

Wat is er met het verzoek voor een bestand dat niet bestaat?
Waarom zijn we met communicatie problemen?

Dat is het voor nu. Morgen ga ik na een tip voor je.

Geen reacties »

Geplaatst in drie-err , Packet Decoding

Tags: Packet Decoding

Tshark Decode Challenge

02 oktober 2009

In mijn laatste bericht ik gedekt tshark en besproken hoe de output tijdens een decoderen manipuleren. Er is geen betere manier om te leren dan door te doen, dus besloot ik om een uitdaging post. In deze post zal ik zorgen voor een libpcap bestand. Jouw missie heer Phelps, moet u kiezen om het te accepteren, is om te proberen te bepalen wat er gaande is binnen het decoderen bestand met behulp van tshark.

Het installeren van tshark

Met het oog op tshark te installeren, moet je Wireshark te installeren. U kunt pak een actuele kopie van de download pagina . Zodra je dat doet, de installatie is afhankelijk van welk platform je gebruikt:

Linux / UNIX

Als u werkt met Fedora of Red Hat, hoeft u niet naar de download pagina te bezoeken. U kunt direct installeren via Yum Wireshark:

su -
yum-y installeren wireshark.i586

Als u werkt met een UNIX-smaak of een andere Linux-distro, moet u de tar-archief te pakken uit de bovenstaande link en Wireshark samenstellen voor uw systeem. Let goed op de afhankelijkheden want er zijn veel van hen. Zorg ervoor dat ". / Configure" met succes voltooid voordat het bouwen van uw binaries.

Windows

Download de zelfuitpakkende uitvoerbare
Voer de executable
Accepteer Onbekende Uitgever scherm door te klikken op "run"-knop
Volg de aanwijzingen op het scherm het accepteren van de standaard
Installeer WinPcap (zorg ervoor dat vakje is aangevinkt)
Installeer NPF dienst als niet-beheerder gebruikers zullen het uitvoeren van het gereedschap
Voeg "C: \ Program Files \ Wireshark" aan het einde van uw padinstructie

OS X

Selecteer de afbeelding die je type processor past (Intel of PPC)
Openen met DiskimageMounter
Open de "Lees mij first.rtf"
Volg de "Quick Setup" instructies

De uitdaging

Hier is de uitdaging bestand:

challenge1.cap

En hier zijn de hashes van het bestand om uw download te controleren:

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

Veel succes en vanaf volgende week zal ik een beetje meer info over het bestand te versturen elke dag om u te helpen om door het decoderen proces.

Geen reacties »

Geplaatst in drie-err , Packet Decoding

Tags: Packet Decoding

Het analyseren van pakketten met tshark

01 oktober 2009

In een eerdere post ik besproken hoe de uitvoer in te stellen tshark . De post gegenereerde veel interesse, dus ik besloot om wat extra informatie over het gebruik tshark om pakketten te decoderen toe te voegen. Dit bericht wordt ervan uitgegaan dat de een in verband met bovenstaande te lezen.

Waarom tshark gebruiken in plaats van tcpdump / WinDUMP?

Veel oude tijd decoders zweren bij tcpdump , en het is Windows tegenhanger WinDUMP . Beide zijn grote hulpmiddelen, maar ze hebben een beetje gedateerd. Terwijl de patches zijn nog vrij van tijd tot tijd, weinig is gedaan om te updaten of uit te breiden hun decoderen vermogen. Wireshark aan de andere kant, evenals het gereedschap, zoals tshark opgenomen, omvatten decoderen ondersteuning voor honderden van protocollen en de lijst groeit alle van de tijd. Terwijl u kunt zeker pakketjes analyseren zonder de decoders, ze maken het proces gaat veel sneller.

Waarom gebruik maken van tshark in plaats van Wireshark?

Wireshark is een geweldig hulpmiddel als je aan het doen zijn een diepgaande analyse payload. Het kan echter wel een beetje vervelend als u een specifiek gebied te volgen over meerdere pakketten. Bijvoorbeeld laten we zeggen dat we willen het TCP sequence nummer verhogen waken over meerdere pakketten. Met Wireshark, zou ik het volgnummer locatie in het middelste deelvenster en de pagina opmerking door elk pakket. Omdat er geen manier is om line-up van de waarde over meerdere pakketten, ben ik gedwongen naar de vorige waarden onthouden bij het uitvoeren van mijn berekeningen. Met tshark echter, kunnen we zoiets als dit:

tshark-n-T-gebieden-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

Vergeet niet dat de TCP-volgnummer (het tweede veld) moet verhogen op basis van de grootte van de lading (het derde veld). Merk op dat pakketten 10 en 11, waar ontvangen in de juiste volgorde. Dit zou kunnen betekenen dat er meerdere paden beschikbaar tussen onze locatie en de geïdentificeerde IP-adres. Terwijl de Wireshark zou tonen ons deze informatie en, in deze visie is het een beetje makkelijker te volgen de stroom.

Meer over het weergeven van velden

Zoals besproken in mijn eerdere post, en zoals hierboven aangegeven, de "-T" schakelaar kan gebruikt worden om de uitgang worden weergegeven manipuleren. U kunt kiezen uit XML, Postscript of platte tekst. De meest nuttige optie is "velden", zoals het laat je kiezen welke specifieke velden die u wilt afgedrukt. Zoals hierboven vermeld, kan de "-e" switch vervolgens worden gebruikt om de velden die u wilt weergeven te identificeren. De volledige lijst van filters kan worden gevonden hier . Een leuke cheat sheet van de meest gebruikte waarden kan worden gevonden hier .

Als u definiëren van een specifiek protocol, zal tshark tonen enkele van de belangrijkste velden uit die header. Bijvoorbeeld om te kijken naar alleen de Ethernet-header:

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

Let op het type en de CRC velden worden niet weergegeven, omdat ze niet als "interessant" als bron en de bestemming MAC-adres. We zouden moeten specifiek te definiëren deze velden (ip.type en ip.trailer) als we willen om ze te zien.

Een neveneffect van het drukken velden is dat tshark voegt een lege regel voor een pakket dat niet bevat het opgegeven veld. Dit kan een pijn zijn bij de analyse van HTTP-pakketten omdat niet ieder pakket zal een URI bevatten. Een gemakkelijke manier om dit op te ruimen is om leiding het door grep. Bijvoorbeeld:

tshark-T-gebieden-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

In mijn laatste bericht besprak ik grep en waar je een gratis versie voor Windows te grijpen. Het bovenstaande grep commando gebruikt de "-v" naar alle lijnen die geen van de opgegeven waarde overeenkomt. "^ $" Definieert een lege regel. Zodat de bovenstaande grep commando filtert alle lege regels.

Meer weergave-opties

Tshark heeft een aantal andere nuttige opties weer te geven. U kunt bijvoorbeeld afdrukken headers aan het begin van de output:

tshark-n-T-gebieden-e-e ip.src 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

Als u van plan op het importeren van de informatie in een spreadsheet of database, kunt u bepalen welk teken te gebruiken tussen de velden:

tshark-T-gebieden-e ip.src-e-e ip.dst 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 statistieken

Tshark heeft solide statistische mogelijkheid ook. Als u een groot aantal bestanden verwerken, soms is het helpen om te beginnen met kijken naar de rauwe stats. De "-z"-schakelaar wordt gebruikt om de statistieken die u wilt analyseren op te geven. Normaal gesproken zullen deze worden afgedrukt aan het einde van het decoderen van informatie, maar als u de optie "-q" switch alleen de statistieken zal worden afgedrukt. Hier is een voorbeeld:

C: \ test> tshark-q-z http, stat,-z http, boom-r test.cap
================================================== =============
HTTP / Packet Tellerwaarde tarief procent
-----------------------
Totaal 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%
OPTIES 2 0.000002 0,44%
HTTP Response Packets 448 0.000338 0,69%
??: Gebroken 0 0.000000 0,00%
1xx: Informatief 0 0,000000 0,00%
2xx: Succes 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%
Andere HTTP-Packets 64008 0.048314 98,60%
================================================== =============
================================================== =============
HTTP Statistieken
* HTTP Status Codes in het antwoord van pakketjes
HTTP 200 OK
HTTP 403 Forbidden
HTTP 404 Not Found
* Lijst van HTTP-verzoek methoden
GET 24
OPTIES 2
HEAD 433
================================================== =============

Een paar dingen uit te steken in deze uitgang. Ten eerste, hebben we vier 403 fouten aangeeft dat er iemand was een poging om iets wat ze had geen toestemming om toegang te krijgen. Ook uit van 459 HTTP-verzoeken, 432 van hen waren voor niet-bestaande bestanden. We zien ook veel "HEAD" vraagt wat een proxy worden, of kan een aanvaller proberen te houden wordt aangemeld voor toegang tot de webserver het logboek worden. Het is duidelijk dat dit capture-bestand bevat een aantal vermoeden verkeer dat nader onderzoek warrants.

Tshark kan zelfs produceren algemene throughput statistieken als je ze nodig hebt. Dit is een uitstekende manier om te controleren of DoS-aanvallen:

tshark-q-z io, stat, 10-r test.cap
================================================== =============
IO Statistics
Interval: 10,000 sec
Column # 0:
| Column # 0
Tijd | lijsten | 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
================================================== =============

Opmerking tshark drukt het frame en aantal bytes voor bepaalde elke interval, gedefinieerd in seconden. Het enige probleem is dat als je het capturen van pakketten af van de draad, stats niet worden weergegeven totdat de vangst eindigt.

Exec Samenvatting

Tshark is een zeer capabele pakket analyse-instrument dat heeft overtroffen het tegenhangers tcpdump en WinDUMP. Combineer de uitgebreide decoderen mogelijkheden samen met de flexibele uitgang weer te geven, en tshark is uitgegroeid tot het middel bij uitstek voor veel packet decoders.

Geen reacties »

Posted in 2-alert , Network Security , Packet Decoding

Tags: Packet Decoding