Arkiv för oktober, 2009

Lek En CMD Prompt från MS Word eller Excel

15 okt 2009

Detta är ett gammalt trick, men jag ser fortfarande ett antal administratörer som tror att de har låst användare av kommandotolken genom att helt enkelt ta bort ikonen från menyn och inaktivera Start-> Kör. I detta inlägg ska jag diskutera hur man kan skapa en kommandotolk med Visual Basic for Applications (VBA), samt hur man minska (dock aldrig helt eliminera) risken för att någon uppnå tillgång till prompten.

Skapa en kommandotolk med VBA

Denna teknik kommer att arbeta med alla program som stöder VBA, men jag specifikt kommer att använda Microsoft Word i mitt exempel. Här är vad du behöver göra:

Starta Microsoft Word
Tryck på "ALT-F11" för att starta VBA editorn
Dubbelklicka på "ThisDocument" i rutan till vänster
När redaktören öppnas, skriver i texten som visas i figur # 1
Tryck på "F5"-knappen

Figur 1: Vår enkla VB script

Du bör se en kommandotolk fönster visas i Aktivitetsfältet. Här är en kopia av den kod du behöver i steg 4 så att du kan kopiera / klistra in:

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

Hur du förhindrar VBA från leken en kommandotolk

Utförande av kommandotolken kan inaktiveras med Group Policy Editor verktyg. Här är stegen:

Klicka på Start -> Kör
Skriv in "gpedit.msc" (utan citationstecken)
Klicka Användarkonfiguration -> Administrativa mallar -> System
Sök ner på listan för "förhindra åtkomst till kommandotolken" och dubbelklicka på den

Du har två alternativ för dig:

Aktivera / inaktivera åtkomst till kommandotolken
Ja / Nej Inaktivera kommandotolken scripting process

Om du bara stänga det första alternativet, direkt åtkomst till cmd.exe förhindras, men en smart användare kan fortfarande få till det via en batch-fil. För att förhindra script tillgång, måste avaktivera det andra alternativet också. Detta förhindrar ALLA scripting dock och kan spela förödelse i många miljöer. Dessutom kommer båda dessa inställningar gäller för administratörskontot också. Detta kan göra admin och felsökning mycket svårare.

Även med båda alternativen funktionshindrade, kan användaren fortfarande komma runt dessa inställningar med hjälp command.com istället för cmd.exe. För att åtgärda detta måste du begränsa åtkomsten till command.com via behörigheter. Om du fortfarande kör några gamla 16-bitars program, kommer detta att fixa bryta dem.

Alla dessa steg inte helt lösa problemet dock. En användare som vet vad de gör med debug kan helt enkelt kopiera cmd.exe till en annan plats och ändra det så snabbt uppnås när man använder den för att köra en falsk kommando. Så vi måste också ta bort "debug.exe".

Även då kan en kunnig programmerare skapar en körbar att komma runt alla ovanstående säkerhetskontroller. Så vi måste ta bort alla möjligheten att kopiera eller skriva till enheten också. Självfallet har vi en ganska värdelös dator vid den punkten.

Exec Sammanfattning

Om någon smarta har tillgång till ditt system, är det tveksamt att du kommer att kunna hindra honom eller henne från att få till kommandoraden. Koncernen Policy Editor kan säkert göra det svårare, men verktyget bara minskar risken för angrepp. Du kan inte helt eliminera risken utan att allvarligt hindra systemets funktion och användbarhet.

Inga kommentarer »

Postat i 4-meddelande , Windows-säkerhet

Taggar: windows kommandoraden i Windows säkerhet fönster tips

PDF av "Skydd mot riktade attacker" prata

14 Oktober 2009

Under de närmaste veckorna jag kommer att ge denna diskussion på ett antal platser. För de som deltog och begärde en PDF-version av bilderna, här är länken jag lovade: skyddar-mot-riktad-attacker-R2

3 kommentarer »

Postat i 3-fela , General Security

Tags: ansökan vitlistning Malware

Tshark Challenge - Uber-nörd Svar

Oktober 13, 2009

I mitt senaste inlägg jag lämnade er med en fråga: Med tanke på vad vi har sett i avkoda filen med tshark, vilken inverkan (om någon) skulle det vara om vi placerar en brandvägg stateful inspektion mellan angriparen och webbservern? Med andra ord, om angriparen är igång ett paket sniffer, skulle de fortfarande se webbservern läcker ut 404-fel?

Och svaret är ...

Kanske.

Inte alla stateful inspection brandväggar är lika. Vissa hanterar paket lite annorlunda än andra. Till exempel vissa (såsom Checkpoint, NetScreen och andra) låt icke-SYN paket att tillåta regler generera nya poster statens bord. Några (Cisco, Netfilter och andra) kommer bara att generera en statlig bord med ordentlig session etablering (måste se TCP-tre paket handskakning).

De nationella vägledande program skickade ett giltigt återställa paket till angriparen på Internet. Var och en av ovan brandväggar skulle se återställning paketet och ta bort det inträde från staten bordet. När webbservern fortsatte att kommunicera är dock endast den första uppsättningen av brandväggar låta paketen läcker ut till angriparen. Den andra typen av brandväggar skulle bara släppa trafiken. Faktum är att om vi sätter upp dem med en förneka regel istället för en droppe regel, skulle de döda sessionen på webbservern vilket åtgärdar problemet som skapats av de nationella vägledande program.

Varför låter vissa leverantörer kvittering paket generera nya poster statens bord? Detta verkar lite bakvända som en legitim session kommer alltid att börja med ett SYN paket. Det finns två skäl gör detta bra funktionell mening:

Uppdatera brandväggsreglerna dödar inte aktiva sessioner
Active-aktiv inställning kommer att vidarebefordra trafik före statens bord synkronisera

Självklart har vi utökad funktionalitet på bekostnad av säkerheten. Tyvärr är det den typiska handel av.

Hoppas du hade kul med denna utmaning. Om det finns intresse jag kommer att publicera mer i framtiden.

2 kommentarer »

Postat i 2-varning , Network Security , Packet avkodning

Taggar: brandvägg nätverkssäkerhet Packet avkodning

Tshark Challenge - The Final svar

9 okt 2009

I mitt förra inlägg hade vi bestämt att spåra filen innehöll en session där en enda finslipat nätverk baserat Intrusion Prevention System hade försökt att stoppa en attack från en HTTP-klient till en webbserver. Vi drog slutsatsen att kundens uppgifter begäran såg ganska misstänksam, och visade en tredje part system (NIP) var ansvarig för återställning paket som sänds under sessionen.

I detta inlägg behöver vi fortfarande att besvara två frågor:

Var attacken lyckas?
Varför webbservern ignorera TCP-reset-paket som överförs av de nationella vägledande program?

Var attacken lyckas?

Angriparen var ute efter att identifiera om filen "startstop.html" var belägen i "Administratör" katalogen. Låt oss ta en titt på en av de paket som skickas till angriparen efter återställningen paket överlämnades:

tshark-n-r challenge1.cap-x frame.number == 11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras 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 8b 0C 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 EG. ... ... ..= 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 20 ot Hittade .. Datum:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 Jun 2002
0070 20 30 30 3a 33 34 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 6f 73 65 onnection: Stäng
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; tecken
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 inte
0120 46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f Hittade </ 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 3c 2f 48 31 3e 0a 54 Hittade inte </ H1>. T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c han begärda webbadressen
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 rator / startstop.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75 html var inte fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 nd om detta tjänar
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> ... ..

Så svaret på angriparens fråga, "Är filen som ligger på servern, besvaras varje paket servern ställa till klienten efter återställningen paketen utfärdades?. Nu är frågan blir, var angriparen se denna information?

När återställningen paket sändes till angriparen ska återställas ha dödat TCP-session. Detta innebär att när dessa uppgifter kom fram, ska den mottagande port (TCP/26922) har i en sluten stat. Hade detta faktiskt varit sant, skulle jag förväntar mig att se en återställning / ACK kommer tillbaka från angriparens systemet säger oss att TCP/26922 nu är stängd. Vi ser aldrig dessa paket.

Så varför inte den avlägsna hamnen nära? Återställningen paketet är giltigt, så det borde ha dödat sessionen. En kunniga angripare kommer att köra ett paket sniffer i bakgrunden när de utför sin attack. Det är möjligt att angriparen skulle ha listat ut vad som pågick och helt enkelt skapat en brandväggsregel på deras anfall systemet filtrera bort alla inkommande återställa paket. Detta skulle ha tillåtit sina verktyg för att fortsätta fungera. Även utan brandväggen filtrera sina packet sniffer skulle innehålla de svar de söker. Så det finns en mycket god chans angriparen har listat ut vad vi är utsatta för, trots en nationella vägledande programmen skyddar nätverket.

Varför webbservern ignorerar återställa paket?

Vår sista fråga är varför webbservern ignorera återställa paket som skickas av de nationella vägledande program. Detta leder till två problem:

Den info angriparen ville fortsätter att läcka ut
Om angriparen flera fil sonder kunde de fylla upp sessionen tabellen på webbservern

Den andra punkten är lite skrämmande eftersom det skulle faktiskt vara de nationella vägledande program som orsakar DoS attack genom att bara döda den ena sidan av kopplingen ordentligt. Så även om vi var lappad och aktuell, säljaren växel vi betalade pengar för i slutändan skulle döda vår webbserver. Gee Jag hatar när jag spenderar pengar för att DoS mig själv.

Låt oss ta en titt på de återställs paket:

tshark-n-r challenge1.cap frame.number == 6 eller frame.number == 7
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP 80> 26.922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed förlorade segmentet] 26.922> 80 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

Observera att tshark säger till oss paket 7 är en förlorad segment. Med andra ord är tshark berättar att TCP sekvensnummer inte i fönstret värden väntar. En titt på sekvensen och bekräfta siffrorna förklarar varför. Värdena är identiska med de i paket 6. Ni kanske minns från förra inlägget som paket 6 och 7 hade också samma IP ID-värde (45.298).

Så det verkar som om här är vad som hände:

Klient skickas en HTTP-attack till vår webbserver
Nationella vägledande programmen upptäcks attacken
Nationella vägledande programmen sänds en giltig TCP återställas till angriparen att döda sessionen
NIP bytte källa och destination IP-adresser i paketet, omräknat till CRC, och sedan skickas samma återställs till webbservern
Webbservern ignorerar återställningen eftersom den inte innehåller en acceptabel sekvensnummer

Du kanske frågar dig själv, "Hur gjorde säljaren missa detta?". Min bästa gissning är att säljaren körde några simulerade attacker, attacken verktyget inte visa dem sårbara filer, så de antog var allt fungerar OK. Med andra ord, besväras en leverantör som skapat en produkt för att skydda nätverk på tråden aldrig titta på vad deras produkt faktiskt gör på kabeln. Hummm ...

Bonus fråga

OK, om du har roligt med det här, här är en bonus fråga att svara på som definitivt kommer att visa din uber-nörd status på toppen av hemliga pyramid:

Antag att vi placerar en brandvägg stateful inspection mellan denna delnät och angriparen. Kommer angriparen fortfarande kunna se svaren med ett paket sniffer?

Jag kommer lägga upp svaret nästa vecka.

Inga kommentarer »

Postat i 2-varning , Packet avkodning

Taggar: Packet avkodning

Tshark Challenge - Tips 4

8 okt 2009

I min senaste inlägget vi identifierat att klienten systemet förmodligen sprang någon form av verktyg för att söka efter kända för att vara sårbara filer. Vi har fortfarande att förklara återställa paket dock, liksom varför servern var att ignorera dem.

Just nu har vi inte ens vet var detta paket fånga togs i förhållande till två ändpunkter. Jag ska köra tshark använda "-T-fält" Switch för att skriva ut TTL information. Genom att analysera TTLS, bör vi kunna avgöra var vi sniffa i förhållande till klienten och servern. Jag kommer också att skriva ut IP-ID: n för att se om det finns några avvikelser i paketet ordning.

Här är kommandot och utgång:

tshark-r challenge1.cap-T fält-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e 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 är kunden. Vi vet att eftersom det inledde sessionen och dess kommunikation med hjälp av en övre källport. 12.33.247.10 är vårt HTTP-servern kommunicerar från port 80.

I paket 1 ser vi kunden har en TTL på 49. Den närmaste start TTL match för ett känt operativsystem är 64, så det här berättar kunden är ett Linux, UNIX eller Mac-system sammanträde 15 humle bort. I paket 2 ser vi servern med en TTL-värde på 64, så det måste vara en av de tidigare nämnda operativsystemen sitter på det lokala nätverket. Så är vi på samma kollision domän som servern, men sammanträde 15 humle bort från kunden.

Det finns ett problem dock. Titta på paket 6 och 7. Här ser vi TTL för båda systemen förändras till 255. Ett OS kommer aldrig att ändra det är TTL under en session, så det här ser väldigt misstänkt. Vidare har vi bestämt redan att klienten sitter 15 humle ifrån oss. 255 är den största möjliga TTL-värde som TTL-fältet är bara ett enda byte (byte 8 i IP-huvudet). Så även om källan IP-adress anspråk på att vara fjärrklient, det finns inget sätt att paketet kunde ha sitt ursprung någon annanstans än från det lokala nätverket. Om paketet hade passerat en eller flera routrar, skulle TTL-värdet vara lägre.

IP ID-information ser inte rätt heller. Under de första tre paket från klienten ser vi IP-ID-värden 0x2a6b (10.859), 0x2a95 (10.901) och 0x2a96 (10.902). Detta säger oss klienten eventuellt med hjälp av en en inkrementell IP-ID, vi bara inte se 42 av paket mellan sänds första och andra paket. Nästa IP-id vi ser från klienten är 0xb0f2 (45.298). OK, om vi inte missat mer än 34 tusen paket går detta IP-ID inte jive.

Notera ovanstående analys endast skulle vara teoretiskt det inte vore för den inkonsekventa TTL-värden. Med bara tre paket att titta på, kan vi inte exakt identifiera IP-ID steg. Det är också möjligt, men mycket mycket osannolikt, att IP-ID steg är helt slumpmässig och att systemet bara råkade tilldela två inkrementella IP-ID, en direkt efter den andra. Ändå kombinerar TTL-och IP-ID-information tillsammans och de visar att detta sista paketet inte kunde ha sitt ursprung i samma system.

Vi har fler IP-ID data från servern att arbeta med, så låt oss ta en titt på det. IDS är:

0 (0)
0 × 3743 (14.147)
0xb0f2 (45.298)
0 × 3744 (14.148)
0 × 3745 (14.149)
0 × 3746 (14.150)
0 × 3747 (14.151)
0 × 3748 (14.152)
0 × 3749 (14.153)
0x374a (14.154)
0x374b (14.155)
0x374c (14.156)
0x374d (14.157)

Ta en titt på finns med på tredje IP-ID, som är från paket 6 i spår. Notera att alla andra IP-ID är inkrementella en, men denna IP-ID inte hör hemma. Faktum är att vi kan visa att servern steg är det IP-ID genom att en och att det inte finns något sätt detta paket kommer från servern.

Humm. Jag undrar om dessa misstänker paket linje med den konstiga återställer vi såg:

tshark-r challenge1.cap-T fält-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id-e 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 0xb0f2 1
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 0x374a 0
15 12.33.247.4 80 64 0x374b 0
16 12.33.247.4 80 64 0x374c 0
17 12.33.247.4 80 64 0x374d 0

Ah ha! Så om vi ser på paket med konstiga TTL-och IP-värden ID var dessa konstiga återställa paket som skickas under sessionen.

Det ser jag som någon tredje systemet är att hoppa in i samtalet för att överföra återställa paket. Eftersom dessa konstiga paket har en TTL på 255, vet vi att det måste vara på samma kollisionsdomän som där vi är sniffning. Eftersom det är på samma kollision domän, kan Ethernet header informationen vara till hjälp:

tshark-r challenge1.cap-T fält-e frame.number-e ETH-e tcp.flags.reset
1 Ethernet II, SRC: HewlettP_ea: 20: AB (0:50:08 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 (0:50:08 B: EA: 20: AB) 0
3 Ethernet II, SRC: HewlettP_ea: 20: AB (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 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 (0:50:08 B: EA: 20: AB) 0

Så när kunden kommer in från Internet, passerar den genom en HP-systemet fungerar som antingen en router eller en brandvägg. Vår webbserver körs på Dell-maskinvara. Observera våra återställs (paket 6 och 7) är båda genereras av samma system med en D-Link NIC.

Så varför gjorde D-Link systemet försöka döda sessionen? Detta inträffade strax efter det att kunden skickade den misstänkta filen begäran. Det ser jag som D-Link-systemet är egentligen en enda finslipat Intrusion Prevention System (IPS). När en attack upptäcks, försöker IPS att förhindra attacken genom att sända återställa paket till båda ändarna av anslutningen.

Men vi har fortfarande några obesvarade frågor. Var attacken lyckas och varför servern verkar ignorera IPS: s försök att döda sessionen?

Lämna in till nästa episod för att ta reda på.

Inga kommentarer »

Postat i 2-varning , Packet avkodning

Taggar: Packet avkodning

Tshark Challenge - Tips 3

7 oktober 2009

Detta är den tredje uppsättningen av tips till tshark avkoda utmaning jag utfärdades förra veckan. Du kan ta en kopia av avkoda filen från utmaningen sida .

I mitt senaste inlägg såg vi vissa skillnader är TCP-ström. Låt oss ta en närmare titt på nyttolasten för att se om någonting ser annorlunda ut på plats. Kommandot jag kommer att använda är:

tshark-r challenge1.cap-x | mindre

Om du kör på Windows, ersätta "mindre"-kommandot med "mer"-kommandot.

Den "-x" knappen kommer att orsaka tshark att skriva ut nyttolast varje paket tillsammans med rubriken sammanfattning. Om du sida ner till paket 4 ska du se:

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 CD 80 18 .. jag *. 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 2f 31 stop.html HTTP / 1
0070 2e 30 0d 0a 48 6f 73 74 3a 20 31 32 2e 33 33 2e .0 .. Värd: 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 3a 20 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 sv] (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 3a 20 6d 61 värk-Control: ma
0100 78 2d 73 74 61 6c 65 3d 30 0d 0a 50 72 61 67 6d x-unken = 0 .. Pragm
0110 61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ce en: no-cache ... ..
0120 f8 43 76. Cv

Detta är den "GET" begäran om misstänkta filnamnet. Det finns ett par områden i denna nyttolast som inte ser rätt. "Host:"-fältet ska identifiera vilka webbservern klienten försökte komma åt. Detta bör alltid vara ett fullständigt domännamn, som "www.fubar.com" eller liknande. Det faktum att serverns IP-adress är noterad berättar en webbläsare inte användes för att generera denna session.

Det är möjligt att vara värd för flera webbplatser på samma fysiska server. Den server räknar ut vilken specifik webbplats du vill ha tillgång till genom att analysera denna värd området. Om webbläsare inte följer denna regel, samlokalisering servrar med flera webbplatser finns på samma fysiska boxen aldrig skulle fungera. Så detta säger mig kunden är ute efter själva webbservern process, inte en webbplats som finns på systemet.

"User-Agent:"-fältet ser konstigt också. Även om det är möjligt att klienten fortfarande kör Windows 95, är det osannolikt.

Den referer fältet är fel också. Detta borde visa oss hela URI kunden hade tillgång till när de var riktade till denna sida. Den bör omfatta det fullständiga domännamnet, liksom den exakta sida på webbplatsen som hänvisade dem till denna sida. Faktum är att om referer är en sökmotor kommer fältet även vad sökparametrar har använts när de var riktade till vår webbplats. Notering en IP-adress är helt felaktig.

Det finns en sista intressant upplysning i denna nyttolast. "X-Forwarded-For:"-fältet berättar att källan IP-adress i IP-huvudet agerar som en HTTP-proxy för vad IP-adressen som anges i detta område. Det är inte ovanligt för angripare att studsa sina attacker bort av en allmän proxyserver. Detta sätt om du upptäcker attacken i din webbserver tillgång loggen kommer du att tänka källan IP-adress är fientlig enhet som X-Forwarded-For fält inte kommer att listas.

Så vi har en misstänkt fil begäran från en IP som försöker dölja sin identitet, med hjälp av paket som har misstänkta värden. Vi behöver inte ett IDS att berätta detta är troligen en angripare letar efter en känd för att vara sårbar fil.

Ta nu en titt på paket 8 till 17. Var och en är servern försöker berätta för kunden "Jag är ledsen, jag är inte körs som sårbara filen. Försök med en annan sårbar fil om du vill kompromissa mig ", via 404 felmeddelanden.

Så flödet går ungefär så här:

Klienten skickar en sond för en potentiellt sårbara fil
Server återställs anslutning
Klient återställs anslutning
Server berättar kontinuerligt kunden den har inte den filen

Så varför återställer och varför servern ignorera dem? Ratta in imorgon för att ta reda ...

Inga kommentarer »

Postat i 3-fela , Packet avkodning

Taggar: Packet avkodning

Tshark Challenge - Hints2

6 oktober 2009

Igår lämnade vi bort att ta en första titt på avkoda filen. En första passet lämnade oss skrapa vårt huvud eftersom vi såg ett 404-fel följt av flera vidaresändning. I denna antydan vi gräva i spåret lite djupare.

Låt oss gå tillbaka till vår ursprungliga avkoda och följa vad som hände paket med paket:

tshark-r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26.922> HTTP [SYN] Seq = 0 Win = 65.535 Len = 0 MSS = 1460 WS = 0 TSV = 15.485.003 TSER = 0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http> 26.922 [SYN, ACK] Seq = 0 Ack = 1 Win = 5792 Len = 0 MSS = 1460 TSV = 1031147147 TSER = 15.485.003 WS = 0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26.922> HTTP [ACK] Seq = 1 Ack = 1 Win = 65.535 Len = 0 TSV = 15.485.003 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> 26.922 [ACK] Seq = 1 Ack = 222 Win = 6432 Len = 0 TSV = 1031147150 TSER = 15.485.003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http> 26.922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed förlorade segmentet] 26.922> HTTP [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras 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 Vidaresändning] [TCP-segment i en återmonteras PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]

Våra första tre paket TCP handskakning. Denna del ser ganska normal. I paket 4 ser vi kunden skickar ett "GET" begäran om en fil. Denna fil begäran slår mig som misstänkt. En fil med namnet "startstop.html" i "Administratör" katalogen inte direkt låter som en fil som vi skulle vilja vara tjäna upp till den stora allmänheten. Vi gör en del av detta och återkomma till det senare.

I paket 5 ser vi servern bekräftar uppgifterna begäran. Efter detta paket, det blir lite konstigt. I paket 6 ser vi servern överför en återställning paket för att döda anslutningen. Detta är en indikation på att servern känner något har gått fel med sessionen och att det är oåterkalleligt. Detta är mycket märkligt beteende för TCP som den försöker väldigt svårt att vara tillförlitliga. Den normalt överföra flera försök att återupprätta en anslutning om den anser att något gick fel. Du kan se normal återhämtning beteende i paket 10 till 17, vilket närmare motsvarar hur TCP försöker att upprätthålla anslutning. Det är en 0,5 ms skillnad i tidsstämpeln mellan paket 5 och 6. En normal operativsystemet skulle aldrig bestämma i denna korta en tid att TCP session är oåterkalleligt.

I paket 7, saker att fortsätta att verka konstigt. Vi ser kunden svara på servern återställs paket med en återställning paket av sina egna. Detta är verkligen inte normalt IP-beteende som RFC staten bör du aldrig svara på ett fel paket. Så under en normal session du aldrig skulle få se denna typ av fel utbyte. Något är uppenbarligen väldigt fel.

I paket 9 ser vi att servern skickar ett meddelande 404 fel. Det finns ett par problem här. För att starta skickade servern redan en återställning som visar den ansåg att mötet ska återställas. Ett system ska aldrig fortsätta att skicka data efter att utfärda en återställning paket. I själva verket fortsätter servern att sända hela vägen till paket 17. Vad som gör denna verksamhet ännu märkligare är att kunden har utfärdat en reset också. Så servern inte bara ignorera det faktum att det utfärdas en återställning, är det ignorerar också den återställs skickas av klienten.

Så onödigt att säga att detta är väldigt konstigt TCP beteende. I mitt nästa inlägg ska jag gräva djupare i nyttolaster att få en bättre titt på vad som händer.

Inga kommentarer »

Postat i 3-fela , Packet avkodning

Taggar: Packet avkodning

Tshark Challenge - Hints1

5 oktober, 2009

Förra veckan jag postat en libpcap fil och utmanade dig att räkna ut hur mycket du kan om spår med tshark. I detta inlägg ska jag börja dig genom processen att analysera avkoda. Jag WIL täcker inte det helt. Mitt mål här är att ge ett ben upp till de folk som inte ens vet var jag ska börja. Jag ska lägga till mer information eftersom veckan går vidare.

Komma igång

Det första du bör göra är att ta en titt på innehållet i filen. Jag kommer att använda växeln-r att läsa innehållet i filen. Detta kommer att åsidosätta tshark standardinställning av sniffning på de upptäckta first gränssnitt. Normalt skulle jag spritsa ut genom "mindre" kommandot (eller "mer" i Windows), men det finns bara 17 paket i filen.

tshark-r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26.922> HTTP [SYN] Seq = 0 Win = 65.535 Len = 0 MSS = 1460 WS = 0 TSV = 15.485.003 TSER = 0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http> 26.922 [SYN, ACK] Seq = 0 Ack = 1 Win = 5792 Len = 0 MSS = 1460 TSV = 1031147147 TSER = 15.485.003 WS = 0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26.922> HTTP [ACK] Seq = 1 Ack = 1 Win = 65.535 Len = 0 TSV = 15.485.003 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> 26.922 [ACK] Seq = 1 Ack = 222 Win = 6432 Len = 0 TSV = 1031147150 TSER = 15.485.003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http> 26.922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed förlorade segmentet] 26.922> HTTP [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras 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 Vidaresändning] [TCP-segment i en återmonteras PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Vidaresändning] [TCP-segment i en återmonteras PDU]

Vissa detaljer som genast fånga min uppmärksamhet:

Detta är en HTTP-session
Anslutningen försökt komma åt en fil som inte finns (404 fel i # 9)
Det fanns kommunikationsfrågor med sessionen (# 10-17 är återutsändning)

Så genast detta spår lämnar mig ställa några frågor:

Vad är det med begäran om en fil som inte finns?
Varför har vi kommunikationsproblem?

Det var allt för nu. Imorgon ska jag posta ett tips.

Inga kommentarer »

Postat i 3-fela , Packet avkodning

Taggar: Packet avkodning

Tshark Decode Challenge

2 oktober, 2009

I mitt senaste inlägg jag täckte tshark och diskuterade hur man kan manipulera produktionsbortfall under en avkoda. Det finns inget bättre sätt att lära sig än genom att göra, så jag bestämde mig för att skriva en utmaning. I detta inlägg ska jag ge en libpcap fil. Ditt uppdrag Mr Phelps, om du väljer att acceptera det, är att försöka identifiera vad som händer inom avkoda filen med tshark.

Installera tshark

För att installera tshark, behöver du installera Wireshark. Du kan ta en aktuell kopia från nedladdningssidan . När du gör, är installationen beroende på vilken plattform du använder:

Linux / UNIX

Om du kör Fedora eller Red Hat, behöver du inte besöka sidan för nedladdning. Du kan installera Wireshark direkt via Yum:

su -
yum-y installera wireshark.i586

Om du kör en UNIX-variant eller någon annan Linux-distro, kan du behöva ta tag i tar-arkiv från ovanstående länk och sammanställa Wireshark för ditt system. Var uppmärksam på de beroenden som det finns en hel del av dem. Se till att ". / Configure" slutförs innan bygga din binärer.

Windows

Ladda ner den självuppackande körbara
Kör den körbara
Acceptera Okänd Förlag skärmen genom att klicka på "Kör" knappen
Följ anvisningarna på skärmen acceptera standardinställningarna
Installera WinPcap (se till att rutan är markerad)
Installera NPF service om icke-administratör användare kommer att köra verktyget
Lägg till "C: \ Program Files \ Wireshark" i slutet av din väg uttalande

OS X

Välj den bild som passar din processor typ (Intel eller PPC)
Öppna med DiskimageMounter
Öppna "Läs mig first.rtf"
Följ "Quick Setup" instruktioner

Utmaningen

Här är utmaningen filen:

challenge1.cap

Och här är hash av filen för att verifiera din nedladdning:

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

Lycka till och från och med nästa vecka ska jag posta lite mer info om filen varje dag för att hjälpa till att flytta dig genom avkoda processen.

Inga kommentarer »

Postat i 3-fela , Packet avkodning

Taggar: Packet avkodning

Analysera paket med tshark

1 oktober, 2009

I ett tidigare inlägg jag diskuterat hur man kan justera displayen produktionen i tshark . Tjänsten genererade mycket intresse, så jag bestämde mig för att lägga till ytterligare information om användning av tshark att avkoda paket. Detta inlägg förutsätter att du har läst ett länkade till ovan.

Varför använda tshark istället för tcpdump / windump?

Många gamla tiden dekodrar svär vid tcpdump , och det är Windows motsvarighet windump . Båda är bra verktyg, men de har blivit lite daterat. Medan fläckar fortfarande frigörs från tid till annan, lite har gjorts för att uppdatera eller utöka sin Avkodningskapacitet. Wireshark , å andra sidan, liksom det är inkluderat verktyg som tshark, inkluderar avkoda stöd för hundratals protokoll och listan växer hela tiden. Även om du kan säkert analysera paket utan dekodrar, de gör processen går mycket snabbare.

Varför använda tshark istället för Wireshark?

Wireshark är ett bra verktyg när du gör en fördjupad nyttolast analys. Det kan vara lite tråkig men om du vill följa ett specifikt område över flera paket. Till exempel låt oss säga att vi vill titta på TCP-ökningen sekvensnummer över flera paket. Med Wireshark skulle jag ha att notera platsen sekvensnummer i det mellersta fönstret och bläddra igenom varje paket. Eftersom det inte finns något sätt att rada upp värde över flera paket, jag är tvungen att minnas tidigare värden när de utför mina beräkningar. Med tshark Men vi kan göra något så här:

tshark-n-T fält-e ip.src-e tcp.seq-e 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

Kom ihåg att TCP sekvensnummer (det andra fältet) bör påslag baserat på storleken på nyttolasten (det tredje fältet). Observera att paket 10 och 11, där fick ur funktion. Det kan betyda det finns flera vägar som finns mellan vårt läge och de identifierade IP-adress. Medan Wireshark skulle visa oss denna information också, i den här vyn är det lite lättare att följa flödet.

Mer om visning av fält

Som diskuterats i mitt tidigare inlägg, liksom ovan, den "-T" brytare kan användas för att manipulera resultatet som visas. Du kan välja mellan XML, Postscript eller oformaterad text. Den mest användbara alternativet är "fält" som den låter dig välja vilka särskilda områden du vill skriva ut. Som framgår ovan kan "-e" switch sedan användas för att identifiera vilka fält du vill visa. Den kompletta listan av filter hittar du här . En trevlig fuska blad av de vanligaste värden som finns här .

Om du definierar ett särskilt protokoll, kommer tshark visa några av de viktiga områden från den rubriken. Till exempel att titta på bara Ethernet-huvudet:

tshark-T fält-e eth
Ethernet II, SRC: TyanComp_56: 3b: 14 (00: E0: 81:56:3 b: 14), DST: Dell_d1: fe: EF (00: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 (00: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 (00:12:03 f: D1: fe: EF)

Notera typ och CRC fält visas inte, eftersom de är inte lika "intressant" som källa och destination MAC-adress. Vi skulle ha att definiera dessa områden specifikt (ip.type och ip.trailer) om vi vill se dem.

En bieffekt av utskrift fält är att tshark kommer att lägga till en tom rad för alla paket som inte innehåller det angivna fältet. Detta kan vara en smärta när man analyserar HTTP-paket som inte varje paket kommer att innehålla en URI. Ett enkelt sätt att städa upp detta är att röret igenom grep. Till exempel:

tshark-T fält-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

I min senaste inlägget diskuterade jag grep liksom där för att ta en gratis version för Windows. Ovanstående kommandot grep använder "-v" byta för att matcha alla rader som inte innehåller det angivna värdet. "^ $" Definierar en tom rad. Så ovanstående kommandot grep filtrerar bort alla tomma rader.

Fler visningsalternativ

Tshark har ett antal andra användbara visningsalternativ. Till exempel kan du skriva rubriker i början av produktionen:

tshark-n-T fält-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

Om du planerar att importera informationen till ett kalkylblad eller en databas, kan du definiera vilka som ska användas mellan områden:

tshark-T fält-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; 34.831
64.111.96.38, 12.5.200.100; 34.831
64.111.96.38, 12.5.200.100; 34.831

Packet statistik

Tshark har gedigen statistiska kompetensen också. Om du behöver bearbeta en massa filer, ibland är det hjälp att börja med att titta på råa statistik. Den "-Z" switch används för att ange den statistik som du vill analysera. Normalt dessa kommer att skrivas ut i slutet av avkoda informationen, men om du använder "-q" switch bara statistik kommer att skrivas ut. Här är ett exempel:

C: \ test> tshark-q-z http, STAT,-z http-, träd-r test.cap
================================================== =============
HTTP / Packet Counter värde procents
-----------------------
Totalt HTTP-paket 64915 0.048999
HTTP Request paket 459 0.000346 0,71%
FÅ 24 0.000018 5,23%
HEAD 433 0.000327 94,34%
ALTERNATIV 2 0.000002 0,44%
HTTP svarspaket 448 0.000338 0,69%
??: Broken 0 0.000000 0,00%
1xx: Informationsansvarig 0 0,000 tusen 0,00%
2xx: Framgång 12 0,000009 2,68%
200 OK 12 0,000009 100,00%
3xx: Omdirigering 0 0,000 tusen 0,00%
4xx: Client Error 436 0,000329 97,32%
404 Hittade inte 432 0,000326 99,08%
403 Forbidden 4 0,000003 0,92%
5xx: Server Error 0 0,000 tusen 0,00%
Andra HTTP-paket 64008 0.048314 98,60%
================================================== =============
================================================== =============
HTTP-statistik
* HTTP-felmeddelanden till svar-paket
HTTP 200 OK
HTTP 403 Forbidden
HTTP 404 Hittades inte
* Lista över HTTP Request metoder
Få 24
Alternativ 2
HEAD 433
================================================== =============

Ett par saker sticker ut i denna utgång. Först har vi fyra 403 fel som visar att någon försöker komma åt något de inte har behörighet till. Även av 459 HTTP-förfrågningar, var 432 av dem för icke-existerande filer. Vi ser också en hel del "HEAD" framställningar som kan vara en fullmakt, eller kan en angripare försöker hålla från att vara inloggad till webbservern tillgång logg. Självklart är detta capture-filen innehåller några misstänker trafik som motiverar ytterligare utredning.

Tshark kan även framkalla allmän genomströmning statistik om du behöver dem. Detta är ett utmärkt sätt att kontrollera för DoS-attacker:

tshark-q-z io, STAT, 10-r test.cap
================================================== =============
IO Statistik
Intervall: 10,000 sek
Kolumn # 0:
| Kolumn # 0
Tid | ramar | 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
================================================== =============

Not tshark skriver ut bilden och byte räknas in i det angivna intervallet, som definieras i sekunder. Det enda problemet är att om du fånga paket bort av tråd, finns statistik visas inte förrän fånga slutar.

Exec Sammanfattning

Tshark är en mycket kapabel paket analysverktyg som har överträffat det motsvarigheter tcpdump och windump. Kombinera den omfattande Avkodningskapacitet tillsammans med den flexibla produktionen displayen och tshark har blivit det bästa sättet för många paket dekodrar.

Inga kommentarer »

Postat i 2-varning , Network Security , Packet avkodning

Taggar: Packet avkodning