Archive for ottobre, 2009

La deposizione delle uova Un CMD prompt Da MS Word o Excel

15 OTTOBRE 2009

Questo è un vecchio trucco, ma vedo ancora un certo numero di amministratori che pensano di aver bloccato gli utenti fuori dal prompt dei comandi semplicemente rimuovendo l'icona dal menu e disabilitando la Start-> Esegui opzione. In questo post parlerò di come creare un prompt dei comandi con Visual Basic for Applications (VBA), e come per mitigare (ma mai completamente eliminare) il rischio di accesso qualcuno raggiungimento al prompt.

Creazione di un prompt dei comandi con VBA

Questa tecnica funziona con qualsiasi applicazione che supporti VBA, ma sono specificatamente intenzione di utilizzare Microsoft Word nel mio esempio. Ecco cosa dovete fare:

Lancio di Microsoft Word
Premere il tasto "ALT-F11" per avviare l'editor di VBA
Fare doppio clic su "ThisDocument" nel pannello di sinistra
Quando appare la finestra di editor, digitare il testo mostrato nella Figura # 1
Premere il tasto "F5"

Figura 1: La nostra semplice script VB

Dovreste vedere una finestra di prompt dei comandi visualizzato nella barra delle applicazioni. Ecco una copia del codice necessario al punto 4 in modo da poter copia / incolla:

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

Come prevenire la deposizione delle uova VBA da un prompt dei comandi

L'esecuzione del prompt dei comandi può essere disattivato con l' Editor Criteri di gruppo strumenti. Ecco i passaggi:

Fare clic su Start -> Esegui
Digitare "gpedit.msc" (senza le virgolette)
Fare clic su Configurazione utente -> Modelli amministrativi -> Sistema
Cerca l'elenco per "Impedire l'accesso al prompt dei comandi" e fare doppio clic su di esso

Avete due opzioni a vostra disposizione:

Abilitare / disabilitare l'accesso al prompt dei comandi
Sì / No Disabilita processo di scripting prompt dei comandi

Se si disattiva la prima opzione, l'accesso diretto al cmd.exe è impedito, ma un utente intelligente può comunque arrivare ad essa tramite un file batch. Per impedire l'accesso script, è necessario disabilitare la seconda opzione pure. Questo impedisce che TUTTI lo scripting e comunque possono essere devastanti in molti ambienti. Inoltre, entrambe queste impostazioni valgono per l'account Administrator pure. Questo può rendere admin e la risoluzione dei problemi molto più difficile.

Anche con entrambe le opzioni disabili, un utente può comunque aggirare queste impostazioni utilizzando command.com invece di cmd.exe. Per risolvere questo problema, è necessario limitare l'accesso a via command.com autorizzazioni utente. Se sono ancora in corso alcune vecchie applicazioni a 16 bit, questa correzione si rompono.

Tutti questi passaggi non risolvono completamente il problema comunque. Un utente che conosce che cosa stanno facendo con il debug può semplicemente copiare cmd.exe in un'altra posizione e modificare così un prompt si ottiene quando lo si utilizza per eseguire un comando fasullo. Quindi dobbiamo anche eliminare "debug.exe".

Anche allora, un programmatore esperto in grado di creare un eseguibile per aggirare tutti i controlli di sicurezza di cui sopra. Quindi abbiamo bisogno di rimuovere tutte le possibilità di copiare o scrivere sul disco pure. Inutile dire che avere un computer abbastanza inutile a quel punto.

Executive Summary

Se qualcuno intelligente ha accesso al vostro sistema, non è certo che sarà in grado di impedire che lui o lei da arrivare a riga di comando. L'Editor Criteri di gruppo può certamente rendere più difficile, ma lo strumento riduce semplicemente il rischio di attacchi. Non è possibile eliminare completamente il rischio, senza ostacolare gravemente il funzionamento del sistema e l'utilità.

Nessun commento »

Pubblicato in 4-preavviso , Windows Security

Tags: windows da riga di comando di sicurezza di Windows finestre suggerimenti

PDF di "protezione contro gli attacchi mirati" parlare

14 Ottobre 2009

Nel corso delle prossime settimane sarò dando questo discorso in un certo numero di posizioni. Per coloro che hanno partecipato e ha chiesto una versione PDF delle diapositive, ecco il link che ho promesso: protegge-contro-attacchi mirati-R2

3 commenti »

Pubblicato in 3-err , Sicurezza Generale

Tags: whitelist applicazioni malware

Tshark Challenge - Uber-Geek Risposta

13 Ott 2009

Nel mio ultimo post ti ho lasciato con una domanda: Dato ciò che abbiamo visto nel file di decodifica con tshark, quale impatto (se c'è) ci sarebbe se ci posto un firewall stateful inspection tra l'attaccante e il server Web? In altre parole, se l'attaccante è in esecuzione uno sniffer, avrebbero ancora vedere il server Web fuoriuscita errori 404?

E la risposta è ...

Forse.

Non tutti i firewall stateful inspection sono uguali. Alcuni pacchetti di gestire in modo leggermente diverso rispetto ad altri. Per esempio, alcuni (come Checkpoint, Netscreen e altri) lascia non pacchetti SYN per permettere regole generare nuove voci della tabella di stato. Alcuni (Cisco, Netfilter e altri) si generano solo una tabella di stato con la creazione della sessione corretta (deve vedere TCP a tre stretta di mano del pacchetto).

Il NIPS inviato un pacchetto valido per ripristinare l'attaccante su Internet. Ciascuno dei firewall sopra dovrebbe vedere il pacchetto di reset e rimuovere è voce dalla tabella di stato. Quando il server Web ha continuato a comunicare comunque, solo la prima serie di firewall avrebbe lasciato trapelare i pacchetti per l'attaccante. La seconda serie di firewall semplicemente cadere il traffico. In realtà se li istituito con negano invece di una regola di goccia, avrebbero ucciso la sessione sul server Web che risolve il problema creato dal NIPS.

Perché alcuni venditori di pacchetti di riconoscimento permettono di generare nuove voci della tabella di stato? Questo sembra un po 'controintuitivo come una sessione legittima sta andando sempre di iniziare con un pacchetto SYN. Ci sono due ragioni per questo fa buon senso funzionale:

Aggiornare le regole del firewall non uccide le sessioni attive
Active-active setup passare il traffico prima di sincronizzazione stato tavolo

Naturalmente abbiamo aumentato le funzionalità a costo della sicurezza. Purtroppo questo è il compromesso è tipico.

Spero che si sono divertiti con questa sfida. Se vi è interesse Io posto più in futuro.

2 commenti »

Pubblicato in 2-allarme , sicurezza di rete , decodifica dei pacchetti

Tags: firewall di sicurezza di rete Packet decodifica

Tshark sfida - La risposta definitiva

9 ott 2009

Nel mio ultimo post che avevamo stabilito che il file di traccia conteneva una sessione in cui una singola rete affinato sistema di prevenzione delle intrusioni aveva tentato di fermare un attacco da un client HTTP a un server web. Abbiamo concluso che la richiesta dei dati del cliente sembrava piuttosto sospetto, e si è dimostrato un sistema di terze parti (il NIPS) era responsabile per i pacchetti ripristino trasmessi durante la sessione.

In questo post abbiamo ancora bisogno di rispondere a due domande:

È stato l'attacco di successo?
Perché il server Web ignorare il pacchetto di reset TCP trasmesso dal NIPS?

È stato l'attacco di successo?

L'attaccante stava cercando di individuare se il file "startstop.html" è situato nella directory "Amministratore". Diamo uno sguardo a uno dei pacchetti inviati per l'attaccante dopo l'pacchetti di reset sono stati trasmessi:

tshark-n-r-x challenge1.cap frame.number == 11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
0000 00 50 8b 20 bis ab 00 b0 d0 20 7d e3 08 00 45 00. P.. .... E. ...}
0010 01 a7 37 47 40 00 40 06 73 8b 21 0c f7 04 94 4e .. 7G @. @. S..! ... N
0020 f7 0a 00 50 69 88 39 2a 3a cd 6a 4c 97 b9 80 19 ... Pi *:.. 0,9 j. L..
0030 19 20 8c d4 00 00 01 01 08 76 0a 3d 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 6e 75 64 0d 0a 44 61 74 65 3 20 ot Trovato .. Data:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 giugno 2002
0070 20 30 30 3 33 34 3 35 38 20 47 4d 54 0d 0a 53 00:34:58 GMT .. S
0080 65 72 76 65 72 3 20 41 70 61 63 68 65 0d 0a 43 erver: Apache .. C
0090 6f 6e 6e 65 63 74 69 3a 6f 6e 20 63 6c 6f 73 65 OLLEGAMENTO: chiudere
00A0 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3 20 .. Content-Type:
00b0 74 65 78 74 68 74 2f 6d 6c 3b 20 63 68 61 72 73 text / html; caratteri
00c0 65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0d 0a 0d et = iso-8859-1 ...
00d0 3c 0a 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 49 45 2f 54 46 2f PUBBLICO "- / / IETF /
00f0 2f 44 54 44 20 48 54 4d 4c 20 32 30 2e 2f 2f 45 / DTD HTML 2.0 / / E
0100 3e 4e 22 48 54 0a 3c 4d 4c 3c 3e 48 45 41 44 3e N ">. <HTML> <HEAD>
0110 3c 0a 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20. <TITLE> 404 Non
0120 46 75 6f 6e 64 3c 2f 54 49 54 45 3e 4c 0a 3c 2f trovato </ TITLE>. </
0130 48 45 41 44 3e 3c 42 4f 44 59 3e 3c 0a 48 31 3e HEAD> <BODY>. <H1>
0140 4e 6f 74 20 46 75 6f 6e 64 3c 2f 48 31 3e 54 0a Not Found </ H1>. T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c ha chiesto URL
0160 20 2f 63 66 69 64 65 41 64 2f 6d 69 6e 69 73 Administ 74 / CFIDE /
0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e startstop Rator /.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 75 6f html non è stata fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 ° su questo servizio
01a0 72 2e 50 3e 3c 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 <P> r.. </ BODY> </ H
01b0 54 4d 4c 3e 0a 00 03 00 07 LM> ... ..

Quindi la risposta alla domanda dell'attaccante, "si trova il file sul server, viene risolta in ogni pacchetto del server impostato sul client dopo i pacchetti di ripristino sono stati emessi?. Ora la domanda diventa, l'attaccante ha fatto vedere queste informazioni?

Quando il pacchetto è stato inviato a ripristinare l'attaccante, il reset dovuto uccidere la sessione TCP. Questo significa che quando questo dati sono arrivati, la porta di ricezione (TCP/26922) avrebbe dovuto essere in uno stato chiuso. Se questo fosse stato vero, infatti, mi sarei aspettato di vedere un reset / ACK di ritorno dal sistema dell'attaccante che ci dice che TCP/26922 è ormai chiuso. Non vediamo mai i pacchetti.

Allora perché non ha la stretta porta remota? Il pacchetto di reset è valido, quindi dovrebbe aver ucciso la sessione. Un attaccante esperto deve essere eseguito uno sniffer in background durante l'esecuzione il loro attacco. E 'possibile che l'attaccante avrebbe capito cosa stava succedendo e semplicemente creato una regola del firewall sul proprio sistema di attacco filtrando tutti i pacchetti di reset in entrata. Questo avrebbe permesso loro strumento per continuare a funzionare. Anche senza il filtro del firewall packet sniffer loro dovrebbe contenere le risposte che cercano. Quindi c'è una probabilità molto buona l'attaccante ha capito quello che siamo vulnerabili, nonostante il fatto che un NIPS è la protezione della rete.

Perché il server Web ignorare il pacchetto di reset?

La nostra domanda finale è perché il server Web di ignorare il pacchetto di ripristino inviati dal NIPS. Questo sta causando due problemi:

Le informazioni l'attaccante ha voluto continua a fuoriuscire
Se l'attaccante fa sonde di più file, avrebbero potuto riempire la tabella di sessione sul server Web

Il secondo elemento è una specie di paura, perché sarebbe in realtà il NIPS causando l'attacco DoS da solo uccidendo una parte della connessione in modo corretto. Quindi, anche se siamo stati patchati e aggiornati, cambio fornitore abbiamo pagato soldi per finirebbe per uccidere il nostro server web. Gee Odio quando spendo soldi per DoS me stesso.

Diamo un'altra occhiata a quei pacchetti di reset:

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

Si noti che tshark ci dice pacchetto 7 è un segmento perso. In altre parole, tshark ci sta dicendo che il numero di sequenza TCP non è all'interno della finestra l'host si aspetta. Uno sguardo alla sequenza di numeri e riconoscere spiega perché. I valori sono identici a quelli nel pacchetto 6. Si può ricordare l'ultimo messaggio da quel pacchetto 6 e 7, ha avuto anche lo stesso valore ID IP (45.298).

Così sembra che qui è quello che è successo:

Client ha inviato un attacco HTTP al nostro server Web
NIPS rilevato l'attacco
NIPS inviato un reset TCP valido per l'attaccante di terminare la sessione
NIPS scambiato la fonte e gli indirizzi IP di destinazione del pacchetto, ricalcolato il CRC, e quindi inviato il reset stesso al server Web
Web server ignora il reset perché non contiene un numero accettabile sequenza

Si può essere se stessi chiedendo: "Come ha fatto il venditore mancare a questo?". La mia ipotesi migliore è che il venditore correva alcuni attacchi simulati, lo strumento di attacco non li visualizzare i file vulnerabili, in modo che assume tutto funzionava OK. In altre parole, non è mai un venditore che ha creato un prodotto per proteggere le reti sul filo preso la briga di guardare a ciò che il loro prodotto è stato effettivamente facendo sul filo. Hummm ...

Bonus domanda

OK, se ci si diverte con questo, ecco una domanda bonus di risposta che definitivamente dimostrare la vostra uber-geek stato sulla cima della piramide segreto:

Supponiamo di mettere un firewall stateful inspection tra questa sottorete e l'attaccante. Sarà l'attaccante ancora in grado di vedere le risposte con un packet sniffer?

Io dopo la risposta la prossima settimana.

Nessun commento »

Pubblicato in 2-allarme , pacchetto di decodifica

Tags: pacchetti di decodifica

Sfida tshark - Suggerimenti 4

8 OTTOBRE 2009

Nel mio ultimo post abbiamo individuato che il sistema client in esecuzione era probabilmente una sorta di strumento di rilevare noti per essere i file vulnerabili. Dobbiamo ancora spiegare i pacchetti ripristino tuttavia, così come perché il server è stato li ignora.

Al momento non so nemmeno dove questo cattura dei pacchetti è stata presa in relazione ai due punti finali. Io vado a correre tshark utilizzando il "T-campi" passare alla stampa le informazioni TTL. Analizzando il TTL, dovremmo essere in grado di determinare dove siamo sniffing in relazione al client e il server. Ho anche intenzione di stampare gli ID di IP per vedere se ci sono anomalie in ordine pacchetto.

Ecco il comando e l'output:

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

148.78.247.10 è il client. Sappiamo che in quanto ha iniziato la sessione e la sua comunicazione con una porta in alto sorgente. 12.33.247.10 è il nostro server HTTP la comunicazione dalla porta 80.

Nel pacchetto 1 vediamo il cliente ha un TTL di 49. La partita più vicina TTL di partenza per un sistema operativo noto è 64, quindi questo ci dice il cliente è un Linux, UNIX, Mac o un sistema seduto 15 hop lontano. Nel pacchetto 2 vediamo il server con un valore TTL di 64 anni, quindi deve essere uno dei sistemi operativi già citato seduto sulla rete locale. Quindi, siamo sulla stesso dominio di collisione come server, ma seduto 15 hop lontano dal client.

C'è un problema però. Guardate i pacchetti 6 e 7. Qui vediamo il TTL di entrambi i sistemi di cambio a 255. Un sistema operativo non cambierà mai è TTL durante una sessione, quindi questo sembra estremamente sospetto. Inoltre, abbiamo già stabilito che il cliente è seduto 15 hop lontano da noi. 255 è il valore più grande possibile TTL come il campo TTL è solo un singolo byte (byte 8 nell'intestazione IP). Così, anche se l'indirizzo IP sorgente sostiene di essere il client remoto, non c'è modo che il pacchetto potrebbe aver avuto origine da nessuna parte, ma dalla rete locale. Se il pacchetto aveva attraversato uno o più router, il valore TTL sarebbe minore.

Le informazioni ID IP non sembra giusto neanche. Nei primi tre pacchetti dal client si veda l'IP ID valori 0x2a6b (10.859), 0x2a95 (10.901), e 0x2a96 (10.902). Questo ci dice il cliente è eventualmente utilizzando un +1 ID incrementale IP, noi non abbiamo visto 42 della pacchetti tra il primo e il secondo pacchetto trasmesso. L'ID prossima IP si vede dal client è 0xb0f2 (45.298). OK, a meno che non abbiamo perso oltre 34.000 pacchetti, questo ID IP non jive.

Nota precedente analisi sarebbe solo teorica se non fosse per i valori incoerenti TTL. Con solo tre pacchetti da guardare, non possiamo identificare con precisione l'incremento IP ID. E 'anche possibile, ma altamente improbabile, che l'incremento ID IP è completamente casuale e il sistema è capitato di assegnare due ID incrementale IP, una dopo l'altra. Ancora, unire il TTL e di dati identificativi IP insieme e indicano che questo pacchetto finale non poteva aver avuto origine dallo stesso sistema.

Abbiamo dati identificativi più IP dal server con cui lavorare, quindi diamo un'occhiata a questo. Gli ID sono:

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)

Date un'occhiata al terzo l'ID IP elencati, che viene dal pacchetto 6 nella traccia. Si noti che tutti gli ID altro IP sono incrementali +1, ma questo ID IP non gli appartiene. Infatti possiamo dimostrare che gli incrementi del server è l'IP ID di +1 e che non vi è modo questo pacchetto originato dal server.

Humm. Mi chiedo se questi pacchetti sospetti linea con il reset strano che abbiamo visto:

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

Ah ah! Quindi, se guardiamo i pacchetti con lo strano TTL e valori ID IP, questi sono stati i pacchetti di reset strano inviati durante la sessione.

Sembra a me come un terzo sistema sta saltando nella conversazione, al fine di trasmettere i pacchetti di reset. Dal momento che questi strani pacchetti hanno un TTL di 255, sappiamo che devono essere sullo stesso dominio di collisione, come dove siamo sniffing. Dal momento che è sulla stesso dominio di collisione, le informazioni di intestazione Ethernet potrebbe essere utile:

tshark-r-T challenge1.cap campi-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

Così, quando il cliente arriva da Internet, passa attraverso un sistema di HP in qualità sia un router o un firewall. Il nostro server Web è in esecuzione su hardware Dell. Nota nostro ripristina (pacchetti di 6 e 7) sono entrambi vengono generati dallo stesso sistema utilizzando una scheda di rete D-Link.

Allora perché il D-Link cercare di terminare la sessione? Ciò è avvenuto solo dopo che il cliente ha inviato la richiesta di file sospetti. Sembra a me come il D-Link è in realtà un unico affinato sistema di prevenzione delle intrusioni (IPS). Quando viene rilevato un attacco, l'IPS tentativi di prevenire l'attacco da parte la trasmissione dei pacchetti riportato a entrambe le estremità della connessione.

Ma abbiamo ancora alcune domande senza risposta. È stato l'attacco di successo e perché il server sembrano ignorare il tentativo IPS di uccidere la sessione?

A sua volta, alla prossima puntata per scoprirlo.

Nessun commento »

Pubblicato in 2-allarme , pacchetto di decodifica

Tags: pacchetti di decodifica

Sfida tshark - Suggerimenti 3

7 ottobre 2009

Questa è la terza serie di suggerimenti per la sfida decodificare tshark ho pubblicato la scorsa settimana. E 'possibile ottenere una copia del file da decodificare la pagina di sfida .

Nel mio ultimo post abbiamo individuato alcune discrepanze è il flusso TCP. Diamo uno sguardo più da vicino il carico utile per vedere se qualcosa sembra fuori posto. Il comando che verrà usato è il seguente:

tshark challenge1.cap-r-x | less

Se è in esecuzione su Windows, sostituire il comando "meno" con il comando "more".

L'opzione "-x" switch causerà tshark per stampare il payload di ogni pacchetto con il riepilogo di intestazione. Se pagina verso il basso per pacchetto 4 si dovrebbe vedere:

4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Amministratore / startstop.html HTTP/1.0
0000 00 b0 d0 20 e3 7d 00 50 8b bis 20 ab 08 00 45 00 ...} .. P.. ... E.
0010 01 11 2a 96 00 00 31 06 94 4e cf d2 f7 0a 0c 21 ..* ... 1 .... N ...!
0020 f7 04 69 00 50 6 bis, 2 bis, 3 bis, b8 97 6f 88 39 80 18 cd .. i *. Pj .. o: 0,9 ...
0030 ff ff fc 42 00 00 01 01 08 0a 00 48 4b ec 3d 76 .. B ... ... ... HK = v
0040 0e 8b 47 45 54 20 2f 63 66 69 64 65 41 64 2f 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 3 20 31 32 2e 33 33 2e .0 .. Host: 12,33.
0080 32 34 37 2e 34 0d 0a 55 73 65 72 41 67 65 2d 6e 247,4 .. User-Agen
0090 74 3 20 7 69 4d 6f 6c 6c 61 35 2e 2f 30 20 t 5b: Mozilla/5.0 [
00A0 6e 65 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 3 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 20 31 3a Forwarded-For: 1
00e0 34 38 2e 36 34 2e 31 34 37 2e 31 36 38 0d 0a 43 .. C 48.64.147.168
00f0 61 63 68 65 2d 6e 6f 43 74 72 3a 6f 6c 20 6d 61 mal-Control: ma
0100 78 2d 73 74 61 6c 65 3d 30 0d 0a 50 72 61 67 6d x-stantia = 0 .. Pragm
0110 61 3a 20 6e 6f 63 2d 61 63 68 65 0d 0a 0d 0a ce un: no-cache ... ..
0120 43 76 f8. Cv

Questa è la richiesta "GET" per il nome del file sospetto. Ci sono un paio di campi in questo payload che non guardano a destra. Il "HOST:" il campo che possono identificare i Web server del cliente stava tentando di accedere. Questo dovrebbe essere sempre un nome di dominio completo, come "www.fubar.com" o simili. Il fatto che l'indirizzo IP del server è elencato mi dice un browser Web non è stato utilizzato per generare questa sessione.

E 'possibile ospitare più siti Web sullo stesso server fisico. I dati del server quale sito specifico si desidera accedere analizzando questo campo host. Se il browser non ha seguito questa, regola co-locazione server con più siti ospitati sulla stessa macchina fisica non avrebbe funzionato. Quindi questo mi dice che il cliente sta andando dopo il processo vero e proprio server Web non, un sito web ospitato nel sistema.

Il "User-Agent:" il campo sembra strano pure. Mentre è possibile il cliente è ancora in esecuzione Windows 95, è improbabile.

Il campo referer non è corretto così. Questo dovrebbe mostrarci l'URI completo il client è stato accede quando erano dirette a questa pagina. Esso dovrebbe includere il nome di dominio completo, così come la pagina esatta sul sito che li ha riferiti a questa pagina. Infatti se il referer è un motore di ricerca, il campo comprenderà anche quello che i parametri di ricerca sono stati utilizzati quando erano rivolte al nostro sito. Lista un indirizzo IP è completamente errata.

C'è un ultimo pezzo interessante di informazioni in questo payload. "X-Forwarded-For:" il campo ci dice che l'indirizzo IP di origine nell'intestazione IP è qualità di un proxy HTTP per qualsiasi indirizzo IP è elencato in questo campo. Non è raro per gli aggressori per far rimbalzare i loro attacchi fuori di un server proxy pubblico. In questo modo se si rileva l'attacco nel log di accesso al server Web, penserete l'indirizzo IP di origine è l'entità ostile come l'X-Forwarded-For campo non saranno elencati.

Così abbiamo una richiesta di file sospetti, da un IP che sta cercando di nascondere la propria identità, usando i pacchetti che hanno valori sospetti. Non abbiamo bisogno di un IDS per dirci questo è probabilmente un pirata alla ricerca di un noto per essere un file vulnerabili.

Ora date un'occhiata a pacchetti da 8 a 17. Ognuno è il server tenta di dire al cliente: "Mi dispiace, non sono in esecuzione il file vulnerabili. Prova con un altro file vulnerabile se si vuole scendere a compromessi me ", attraverso 404 messaggi di errore.

Quindi il flusso più o meno così:

Il client invia una sonda per un file potenzialmente vulnerabile
Resetta la connessione del server
Resetta la connessione del client
Server indica continuamente il cliente non ha quel file

Allora, perché il ripristino e perché il server li ignora? Sintonizzati domani per scoprirlo ...

Nessun commento »

Pubblicato in 3-err , Packet decodifica

Tags: pacchetti di decodifica

Tshark Challenge - Hints2

6 OTTOBRE 2009

Ieri abbiamo lasciato prendere da una prima verifica del file di decodifica. In un primo tempo ci ha lasciato graffiare la nostra testa perché abbiamo visto un errore 404 seguito da ritrasmissioni multipli. In questo suggerimento faremo scavare nel tracciare un po 'più profonda.

Torniamo al nostro decodificare iniziale e seguire ciò che è accaduto pacchetto di pacchetto:

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 / Amministratore / 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 ACK segmento perso] 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 ritrasmissione] [segmento TCP di una PDU riassemblate]
9 0.031664 12.33.247.4 - Non> 148.78.247.10 HTTP HTTP/1.1 404 Found (text / html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]

I nostri primi tre pacchetti sono l'handshake TCP. Questa parte sembra piuttosto normale. Nel pacchetto 4, vediamo che il client invii una richiesta "GET" per un file. Questa richiesta di file mi sembra sospetta. Un file denominato "startstop.html" nella directory "Amministratore" non esattamente il suono come un file che vorrebbe essere al servizio al pubblico in generale. Faremo una nota di questo e di tornare più tardi.

Nel pacchetto 5 vediamo il server riconosce la richiesta dei dati. Dopo questo pacchetto, le cose si fanno un po 'strano. Nel pacchetto 6, vediamo il server di trasmettere un pacchetto ripristino di uccidere la connessione. Questa è un'indicazione che il server si sente qualcosa è andato storto con la sessione e che è irrecuperabile. Questo è un comportamento estremamente strano per TCP in quanto si sforza di essere affidabile. Normalmente trasmette più tentativi di ristabilire una connessione se si pensa che qualcosa è andato storto. Potete vedere il comportamento normale di recupero in pacchetti da 10 a 17, che più si avvicina come TCP tenterà di mantenere la connettività. Vi è una differenza di 0,5 ms in timestamp tra i pacchetti 5 e 6. Un sistema operativo normale non avrebbe mai determinare in quel breve periodo di tempo che la sessione TCP è irrecuperabile.

Nel pacchetto 7, le cose continuano a comportarsi in modo strano. Vediamo il cliente rispondere alle pacchetto ripristinare il server con un pacchetto di reset del suo. Questo non è certamente un comportamento IP normale come lo stato RFC non si dovrebbe mai rispondere ad un pacchetto di errore. Così durante una normale sessione non potreste mai vedere questo tipo di scambio di errore. Qualcosa è ovviamente molto sbagliato.

Nel pacchetto di 9, si vede il server invia un messaggio di errore 404. Ci sono un paio di problemi qui. Per iniziare, il server già inviato un reset che indica che considerata la sessione di essere irrecuperabili. Un sistema non dovrebbe mai continuare a inviare i dati dopo l'emissione di un pacchetto di reset. Infatti, il server continua a trasmettere fino al pacchetto 17. Ciò che rende questa attività ancora più strano è che il cliente ha emesso un reset pure. Quindi il server non è solo ignorando il fatto che lo ha emesso un reset, ma è anche ignorando il ripristino inviati dal client.

Quindi inutile dire che questo è molto strano il comportamento del TCP. Nel mio prossimo post farò scavare più in profondità nel payload di vedere meglio ciò che sta succedendo.

Nessun commento »

Pubblicato in 3-err , Packet decodifica

Tags: pacchetti di decodifica

Tshark Challenge - Hints1

5 Ottobre 2009

La scorsa settimana ho inviato un file libpcap e sfidato a capire quanto si potrebbe utilizzare la traccia su tshark. In questo post farò di iniziare il processo di analisi del decodificare. IO NON WIL soddisfa completamente. Il mio obiettivo qui è quello di dare una gamba fino alla gente che non sanno nemmeno da dove cominciare. Io aggiungere ulteriori dettagli come la settimana va avanti.

Per iniziare

La prima cosa da fare è dare un'occhiata al contenuto del file. Userò l'opzione-r di leggere il contenuto del file. Questa la priorità predefinita tshark di sniffing sulla prima interfaccia rilevato. Normalmente avrei pipe l'output attraverso il comando "meno" (o "più" in Windows), ma ci sono solo 17 pacchetti nel 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 / Amministratore / 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 ACK segmento perso] 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 ritrasmissione] [segmento TCP di una PDU riassemblate]
9 0.031664 12.33.247.4 - Non> 148.78.247.10 HTTP HTTP/1.1 404 Found (text / html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP ritrasmissione] [segmento TCP di una PDU riassemblate]

Alcuni dettagli che subito afferrare la mia attenzione:

Si tratta di una sessione HTTP
Il tentativo di connessione per accedere a un file che non esiste (404 errore in # 9)
Ci sono stati problemi di comunicazione con la sessione (# 10-17 sono ritrasmissioni)

Quindi subito questa traccia mi lascia qualche domanda:

Che succede con la richiesta di un file che non esiste?
Perché stiamo avendo problemi di comunicazione?

Questo è tutto per ora. Domani postare un altro suggerimento.

Nessun commento »

Pubblicato in 3-err , Packet decodifica

Tags: pacchetti di decodifica

Tshark Decodifica sfida

2 ottobre 2009

Nel mio ultimo post ho coperto tshark e discusso su come manipolare l'output nel corso di una decodifica. Non c'è modo migliore per imparare che da fare, così ho deciso di inviare una sfida. In questo post mi forniscono un file libpcap. La vostra missione Mr. Phelps, se scegliete di accettarla, è tentare di identificare ciò che sta accadendo all'interno del file di decodifica utilizzando tshark.

Installazione tshark

Per installare tshark, è necessario installare Wireshark. E 'possibile ottenere una copia aggiornata dalla pagina di download . Una volta fatto, il processo di installazione dipende dalla piattaforma che si sta utilizzando:

Linux / UNIX

Se si esegue Fedora o Red Hat, non è necessario visitare la pagina di download. È possibile installare Wireshark direttamente attraverso Yum:

su -
yum-y install wireshark.i586

Se si esegue un sapore UNIX o qualche altra distro Linux, potrebbe essere necessario per afferrare l'archivio tar dal link qui sopra e compilare Wireshark per il sistema. Fate molta attenzione alle dipendenze come ci sono un sacco di loro. Assicurarsi che ". / Configure" completato con successo prima di costruire i binari.

Finestre

Scarica il file eseguibile autoestraente
Eseguire il file eseguibile
Accettare schermo sconosciuto Editore facendo clic sul pulsante "Esegui"
Seguire le istruzioni sullo schermo accettando le impostazioni predefinite
Installare WinPcap (assicuratevi che la casella è selezionata)
Installare il servizio NPF se agli utenti non amministratori sarà l'esecuzione dello strumento
Aggiungere "C: \ Programmi \ Wireshark" alla fine del l'istruzione di percorso

OS X

Selezionare l'immagine che corrisponde al tipo di processore (Intel o PPC)
Apri con DiskimageMounter
Aprire il "Leggimi first.rtf"
Seguire le "Quick Setup" istruzioni

La sfida

Ecco il file di sfida:

challenge1.cap

E qui ci sono gli hash del file per verificare il download:

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

Buona fortuna e partire dalla prossima settimana sarò inviare informazioni un po 'più sul file ogni giorno per contribuire a spostare l'utente attraverso il processo di decodifica.

Nessun commento »

Pubblicato in 3-err , Packet decodifica

Tags: pacchetti di decodifica

Analizzando i pacchetti con tshark

1 Ottobre 2009

In un precedente post ho parlato di come regolare l'uscita del display in tshark . Il post ha generato molto interesse, così ho deciso di aggiungere alcune ulteriori informazioni sull'utilizzo tshark per decodificare i pacchetti. Questo post si assume di aver letto quella legata sopra.

Perché usare tshark invece di tcpdump / windump?

Molti decoder vecchio tempo giuro per tcpdump , ed è controparte Windows windump . Entrambi sono ottimi strumenti, ma sono diventati un po 'datato. Mentre le patch sono ancora liberati di tanto in tanto, poco è stato fatto per aggiornare o espandere la propria capacità di decodificare. Wireshark d'altra parte, così come è incluso strumenti come tshark, comprendono decodificare il supporto per centinaia di protocolli e la lista è in crescita tutto il tempo. Mentre si può certamente analizzare i pacchetti senza il decoder, rendono il processo di andare molto più veloce.

Perché usare tshark invece di Wireshark?

Wireshark è uno strumento particolarmente utile quando si sta facendo un'approfondita analisi di carico utile. Può essere un po 'noioso ma se si vuole seguire un campo specifico in pacchetti multipli. Per esempio diciamo che vogliamo vedere l'incremento di numero di sequenza TCP in pacchetti multipli. Con Wireshark, avrei dovuto prendere nota della posizione numero di sequenza nel pannello centrale e la pagina attraverso ogni pacchetto. Poiché non vi è alcun modo per allineare il valore nel più pacchetti, sono costretto a ricordare i valori precedenti quando si eseguono i miei calcoli. Con tshark però, possiamo fare qualcosa del genere:

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

Ricordate che il numero di sequenza TCP (il secondo campo) dovrebbe incrementare in base alle dimensioni del carico utile (il terzo campo). Si noti che i pacchetti di 10 e 11, se ricevuti fuori ordine. Questo potrebbe significare che ci sono più percorsi a disposizione tra la nostra posizione e l'indirizzo IP individuato. Wireshark mentre ci mostrava questa informazione come bene, in questa visione è un po 'più facile seguire il flusso.

Altro su visualizzazione campi

Come discusso nel mio post precedente, così come mostrato sopra, l'opzione "-T" switch può essere usato per manipolare l'output viene visualizzato. È possibile scegliere tra XML, PostScript o testo semplice. L'opzione più utile è "campi" in quanto consente di scegliere quali campi specifici che si desidera stampare. Come mostrato in precedenza, il "-e" switch può essere utilizzato per identificare i campi che si desidera visualizzare. La lista completa dei filtri può essere trovato qui . Un cheat sheet bella dei valori più comunemente usati può essere trovato qui .

Se si definisce un protocollo specifico, tshark mostrerà alcuni dei campi più importanti da quel colpo di testa. Per esempio a guardare solo l'intestazione Ethernet:

tshark T-campi-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)

Si noti il tipo e campi CRC non vengono visualizzati, in quanto non sono come "interessanti" come fonte e destinazione indirizzo MAC. Dovremmo definire questi campi appositamente (ip.type e ip.trailer) se vogliamo vederli.

Un effetto collaterale dei campi di stampa è che tshark verrà aggiunta una riga vuota per ogni pacchetto che non contiene il campo specificato. Questo può essere un dolore quando l'analisi dei pacchetti HTTP come non ogni pacchetto conterrà un URI. Un modo semplice per pulire questo è quello di pipe attraverso grep. Per esempio:

tshark-T http.request.uri campi-e | 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

Nel mio ultimo post ho discusso grep e dove afferrare una versione gratuita per Windows. Il comando grep sopra utilizza l'opzione "-v" passare a cercare tutte le righe che non contengono il valore specificato. "^ $" Definisce una riga vuota. Quindi il comando grep filtra sopra tutte le righe vuote.

Opzioni di visualizzazione più

Tshark ha un certo numero di altre opzioni di visualizzazione utili. Per esempio è possibile stampare intestazioni all'inizio del l'output:

tshark-n-T campi-e ip.src-e ip.dst-E intestazione = 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

Se hai intenzione di importare le informazioni in un foglio di calcolo o database, è possibile definire quale personaggio utilizzare tra i campi:

tshark T-campi-e ip.src-e ip.dst-e tcp.dstport-E intestazione = y-E = separatore;
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

Pacchetto statistiche

Tshark ha una solida capacità statistiche pure. Se avete bisogno di elaborare un sacco di file, a volte è aiutare a iniziare con guardare le statistiche prime. L'opzione "-z" interruttore viene utilizzato per specificare le statistiche che si desidera analizzare. Normalmente questi verranno stampati alla fine di decodificare le informazioni, ma se si utilizza l'opzione "-q" passare solo le statistiche verranno stampate. Ecco un esempio:

C: \ test> tshark-q-z http, stat,-z http, albero-r test.cap
================================================== =============
HTTP / Packet contatore valore percentuale tasso
-----------------------
Totale pacchetti HTTP 64915 0.048999
Richiesta di pacchetti HTTP 459 0.000346 0,71%
GET 24 0.000018 5,23%
TESTA 433 0.000327 94,34%
OPZIONI 2 0.000002 0,44%
I pacchetti di risposta HTTP 448 0.000338 0,69%
??: Rotto 0 0.000000 0.00%
1xx: Informativo 0 0,000000 0.00%
2xx: Successo 12 0,000009 2,68%
200 OK 12 0,000009 100,00%
3xx: Redirection 0 0,000000 0.00%
4xx: Errore client 436 0,000329 97,32%
404 Not Found 432 0,000326 99,08%
403 Forbidden 4 0,000003 0,92%
5xx: Errore del server 0 0,000000 0.00%
Altri pacchetti HTTP 64008 0.048314 98,60%
================================================== =============
================================================== =============
HTTP Statistiche
* I codici di stato HTTP in pacchetti di risposta
HTTP 200 OK
HTTP 403 Forbidden
HTTP 404 Not Found
* Elenco dei metodi di richiesta HTTP
GET 24
OPZIONI 2
TESTA 433
================================================== =============

Un paio di cose che sporgono in questa uscita. In primo luogo, abbiamo quattro 403 errori che indicano che qualcuno stava tentando di accedere a qualcosa di non avere il permesso di. Inoltre, su 459 richieste HTTP, 432 di loro erano inesistenti per i file. Stiamo inoltre vedendo un sacco di "HEAD" richieste che potrebbe essere un proxy, o potrebbe essere un hacker tenta di evitare di essere registrati per accedere accedere al server web. Chiaramente questo file di cattura comprende una parte del traffico sospetto che merita ulteriori indagini.

Tshark può anche produrre statistiche velocità generale, se ne avete bisogno. Questo è un ottimo modo per verificare la presenza di attacchi DoS:

tshark-q-z io, stat, 10-r test.cap
================================================== =============
IO Statistiche
Intervallo: 10.000 secs
Colonna # 0:
| Colonna # 0
Tempo | cornici | 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
================================================== =============

Tshark nota stampa il telaio e numero di byte per ogni intervallo di tempo specificato, definito in secondi. L'unico problema è che se si cattura di pacchetti fuori del filo, le statistiche non vengono visualizzati fino a quando la cattura finisce.

Executive Summary

Tshark è estremamente capace strumento di analisi dei pacchetti che ha superato sia controparti tcpdump e windump. Coniugare la capacità di decodificare vasto insieme con la visualizzazione di output flessibili e tshark è diventato lo strumento di scelta per i decoder pacchetto molti.

Nessun commento »

Pubblicato in 2-allarme , sicurezza di rete , decodifica dei pacchetti

Tags: pacchetti di decodifica