Archivio per la categoria '2-alert '

«Vecchi

TCP Opzioni Challenge - indizi

18 Novembre 2009

In precedenza ho postato una sfida a dare una tcpdump / windump filtro che cattura i pacchetti che hanno l'opzione "Finestra Scala" TCP set. Alcune persone sono vicini, ma volevo inviare alcuni suggerimenti. Inoltre, non ho alcun problema con me via e-mail direttamente, ma per vincere la sfida è necessario inviare la risposta alla sezione dei commenti. In questo modo non ci sono dubbi su chi trova la prima risposta.

Tutte le opzioni TCP sono specificati da un "Registro di tipo" value (simile al ICMP campo "Type"). Nel caso della Scala finestra, quel valore è 3. Inoltre, tutte le opzioni TCP tranne NOP contenere un campo secondario denominato "Lunghezza". Questo definisce il numero di byte le opzioni sta usando, tra cui il "Registro di tipo" byte. Nel caso della Scala finestra il valore della lunghezza è sempre 3. Quindi abbiamo:

  • 1 byte per Tipo Registro
  • 1 byte di lunghezza
  • 1 byte per il valore effettivo WScale

Suggerimento 2: Se non avete mai forato nel campo TCP Opzioni, tshark ha un'opzione cool:

tshark-n-r capture-file.cap T-campi-e tcp.options

Questo produrrà l'intero campo delle opzioni TCP in esadecimale in modo da poter almeno vedere come appare.

Indizio finale, ho inviato un pacchetto SYN Linux che definisce WScale al 5 per voi da utilizzare per controllare il filtro.

linux-syn

Buona fortuna!

Chris

Nessun commento »

Pubblicato in 2-allarme , pacchetto di decodifica

Tags:

TCP Opzioni di Sfida

18 Novembre 2009

Ho avuto un po 'in corso compreso il rilascio di un nuovo strumento di riferimento per l'Apple iPhone e iPod. Lo strumento è chiamata decodifica dei pacchetti di configurazione e ho un sito alternativo per aiutare a mantenere esso.

Mi sento male a trascurare questo sito negli ultime settimane, quindi ho deciso di buttare via un'altra sfida. Il vincitore riceverà una copia gratuita dello strumento di decodifica dei pacchetti di cui sopra. OK, quindi non sarà in grado di andare in pensione sui proventi, ma si spera che lo strumento renderà la vostra vita un po 'più facile. ;)

Quindi ecco la sfida:

Scrivi una tcpdump o windump filtro che solo catturare i pacchetti che hanno il TCP "Scala finestre" set opzione. Tutte le altre impostazioni delle opzioni TCP può essere ignorato.

Abbastanza semplice, eh? Persona prima di inviare la risposta nella sezione commenti ottiene il premio.

2 commenti »

Pubblicato in 2-allarme , pacchetto di decodifica

Tags:

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:

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:

  1. È stato l'attacco di successo?
  2. 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:

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:

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:

Passivamente Fingerprinting VMware Virtual Systems

15 settembre 2009

Ci sono stati alcuni giornali eccellente scritto su come rilevare se un sistema operativo è in esecuzione come immagine guest Vmware. strumenti automatici sono ancora stati rilasciati per contribuire ad accelerare il processo. Tutti presuppongono tuttavia che l'accesso terminale o prompt dei comandi è necessario per eseguire il rilevamento. Pochi si rendono conto che è possibile rilevare passivamente un ospite Vmware senza alcun livello di accesso al sistema. Infatti, se si sa cosa cercare, si può anche identificare la versione di VMware ospita il sistema virtuale.

Fingerprinting passivo

Fingerprinting passivo è una tecnica in cui da un sistema operativo remoto può essere identificato con le sfumature i pacchetti IP che produce. Per esempio il payload di pacchetti echo-request sono abbastanza uniche da sistema operativo a sistema operativo. In un post precedente ho discusso di come diversi sistemi operativi utilizzano orario diverso per vivere i valori. Analizzando queste variazioni in pacchetti IP, è possibile fare un lavoro abbastanza preciso di individuare il sistema operativo di origine. In realtà molte volte si può anche identificare il livello di ritorno di patch del sistema.

Virtuale VMware sistemi

VMware supporta due modalità per il collegamento di un sistema operativo guest a una rete. Si può NAT dietro l'host, o collegarlo in modalità di bridging. Molte persone pensano che la modalità di bridging dà l'accesso diretto al sistema operativo guest la scheda di rete, ma si dimentica che VMware è ancora seduto tra il sistema operativo guest ei driver del sistema host per eseguire il NIC. Non è raro per questo livello di apportare modifiche in pacchetti IP prima di passarli sul filo. Quindi, se si sa cosa cambia per cercare, si può rilevare quando il software VMware è seduto tra un sistema operativo e la rete locale.

VMware rende più modifiche al flusso di dati IP. In questo post ci guarderà solo a due di questi cambiamenti (dimensione della finestra e ridimensionamento), e lascio al lettore per cercare di trovare gli altri. Inoltre, diverse versioni di VMware modificherà il flusso di dati IP in modi diversi. Se si conosce quali cambiamenti sono unici per ogni versione, è possibile identificare il livello di rilascio di VMware seduto tra il sistema operativo guest e la rete.

La dimensione della finestra e window scaling

Dimensione della finestra TCP utilizza per identificare la quantità di dati possono essere trasmessi prima che un sistema remoto deve mettere in pausa e attendere una conferma. Per esempio se "Sistema A" racconta "Sistema B", "dimensione della finestra = 1400", "System B" il permesso di inviare poco meno di un pacchetto full size Ethernet prima si deve aspettare. Dopo il 1400 byte vengono trasmessi, "System B" non è consentito inviare i dati più fino a che non riceve un riconoscimento di tali dati da "Sistema A". Dimensione della finestra viene regolata al volo, in modo da "Sistema A" possono eventualmente pubblicizzare "la dimensione della finestra = 1600". Questo significa "sistema B" possono ora inviare un pacchetto full size seguito da un pacchetto piccolo prima di dover mettere in pausa per un riconoscimento. Dimensione della finestra è un metodo di controllo di flusso per contribuire a garantire che il sistema ricevente non vede più dati di quelli che i buffer in grado di gestire.

Dimensione della finestra risale alla implementazione originale di TCP. Al momento sono stati riservati 16 bit (byte 14 e 15 nell'intestazione TCP) per specificare quanti byte possono essere trasferiti prima della pausa per un riconoscimento. Questo significa che potremmo specificare una dimensione massima della finestra di 65.535 byte. Questo è più che abbastanza grande entro il 1980 gli standard, ma non così grande quando si parla di circa 1 Gb di reti e più veloce. Nei primi anni '90, il window scaling è stato aggiunto come opzione TCP. Window scaling è solo pubblicizzato il primo pacchetto TCP inviato da un sistema (SYN o SYN / ACK) ed è un moltiplicatore per le dimensioni della finestra pubblicizzato. Per esempio, assumere una dimensione della finestra di 1400 byte. Se la scala finestra è 3, la matematica sarebbe:

(2 * 2 * 2) * 1.400 = 11.200

Se la scala finestra è 4, la matematica diventa:

(2 * 2 * 2 * 2) * 1.400 = 22.400

Così window scaling ci permette di pubblicizzare ora dimensioni della finestra molto più grande. Questa spiegazione è piuttosto semplicistico, ma dovrebbe dare al lettore un'idea di come dimensione della finestra e le opere di scala. Per maggiori informazioni si veda RFC 1323 o il Wiki TCP .

Backtrack 3 finale come host autonomo

Ecco una risposta SYN / ACK ad una richiesta di connessione restituito da un sistema a 3 Backtrack (Linux kernel 2.6.21.5) in esecuzione su un host dedicato:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), lunghezza 60) 192.168.100.4.80> 192.168.100.50.44943: S, cksum 0 × 9552 (corretto ), 2760872392:2760872392 (0) ack 4071399005 win 5792 <mss 1460,sackOK,timestamp 5362662 198395,nop, wscale 5>

Nota la scala finestra iniziale è di 5, il che significa che la dimensione della finestra reale è 32 * 5.792 = 185.344. Questo è abbastanza comune per i sistemi Linux con un post 2.6.17 del kernel.

Ora diamo uno sguardo a come la dimensione della finestra di Backtrack 3 viene incrementato:

[Root @ fubar ~] # tshark-n-T campi-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst ospitare 192.168.100.50

Catturare su eth0

192.168.100.4 5792 5

192.168.100.4 245

192.168.100.4 336

192.168.100.4 426

192.168.100.4 517

192.168.100.4 607

192.168.100.4 698

192.168.100.4 788

192.168.100.4 879

192.168.100.4 969

192.168.100.4 1060

Ho usato tshark per ripulire l'uscita in modo da poter concentrarsi sui campi che effettivamente interessano. La traccia di cui sopra è un trasferimento di dati di grandi dimensioni a 192.168.100.4 (BT3 stand alone) via TCP/80, come mostrato nella traccia sopra tcpdump. Si noti che si può tranquillamente identificare chiaramente come la dimensione della finestra è stato incrementato nel corso degli sessione dati.

Backtrack 3 definitivo, ospite su Windows XP Workstation

Allora diamo uno sguardo a come dimensione della finestra e il ridimensionamento ottenere colpite quando il sistema operativo è seduto dietro VMware. In questo test mi sono imbattuto BT 3 come sistema operativo guest su un host workstation Windows XP. Ho usato VMware Player 2.5.3 e ha scritto un file personalizzato VMX per eseguire il BT 3 iso.

Ecco un primo pacchetto SYN / ACK:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), lunghezza 60) 192.168.100.7.80> 192.168.100.50.35245: S, cksum 0x670d (corretto), 3795217952:3795217952 (0) ack 4108648760 win 5792 <mss 1460,sackOK,timestamp 5210512 208486,nop, wscale 4>

Si noti che mentre la dimensione della finestra iniziale corrisponde autonomo BT sistema a 3, VMware ha lasciato cadere la window scaling da 5 (32x) a 4 (16x).

Ecco il flusso di pacchetti che vengono restituiti dal sistema guest:

[Root @ fubar ~] # tshark-n-T campi-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst ospitare 192.168.100.50

Catturare su eth0

192.168.100.7 5792 4

192.168.100.7 490

192.168.100.7 671

192.168.100.7 852

192.168.100.7 1033

192.168.100.7 1214

192.168.100.7 1395

192.168.100.7 1576

192.168.100.7 1757

192.168.100.7 1938

192.168.100.7 2119

Si noti che dopo il primo pacchetto la dimensione della finestra negoziato appare più grande, ma quando si fattore moltiplicatore di scala finestra la dimensione della finestra complessivo finisce per essere leggermente più piccolo di BT 3 quando viene eseguito su un sistema dedicato. Non è così sorprendente come i sistemi virtuali funzionano normalmente più lenti rispetto ai sistemi dedicati, ma abbiamo appena taggati due differenze che possiamo cercare di determinare se l'host è stand-alone o una immagine virtuale guest.

Backtrack 3 definitivo, ospite su Fedora 11

Naturalmente la grande domanda è: "è stato il cambiamento dimensioni della finestra a causa di Windows XP host o VMware?". VMware aggira lo stack IP di Windows durante la trasmissione sul filo, in modo che il sistema operativo host dovrebbe avere alcun effetto sul flusso di pacchetti. Per verificare questo, proviamo lo stesso test utilizzando la stessa versione di VMware Player, solo che questa volta useremo Linux come sistema operativo ospitante. Ecco il SYN / ACK:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), lunghezza 60) 192.168.100.13.80> 192.168.100.50.43363: S, cksum 0x6ef7 (corretto), 3423175369:3423175369 (0) ack 483782889 win 5792 <mss 1460,sackOK,timestamp 579990 366817,nop, wscale 4>

Ecco il flusso di pacchetti che vengono restituiti dal TCP/80 sul guest BT 3 Sistema:

[Root @ fubar ~] # tshark-n-T campi-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst ospitare 192.168.100.50

Catturare su eth0

192.168.100.13 5792 4

192.168.100.13 490

192.168.100.13 671

192.168.100.13 852

192.168.100.13 1033

192.168.100.13 1214

192.168.100.13 1395

192.168.100.13 1576

192.168.100.13 1757

192.168.100.13 1938

192.168.100.13 2119

Si noti i risultati sono identici a quando BT3 è stato il sistema operativo guest su Windows XP. Così, mentre questa metodologia non identificare il sistema operativo host in uso, si può sempre determinare se BT3 è in esecuzione su un sistema dedicato o come ospite tramite VMware. Mentre è del tutto possibile modificare un sistema dedicato di apparire di essere un ospite virtuale, l'opposto non sembra essere fattibile.

Executive Summary

Avendo una profonda comprensione di IP e le sfumature generate da sistemi operativi differenti, è possibile determinare se un sistema operativo è in esecuzione su un sistema dedicato o come ospite tramite VMware. Modifiche apportate dal wrapper VMware lasciarsi alle spalle raccontare indizi racconto. Un weenie pacchetto intelligente in grado di sfruttare questi indizi per determinare lo stato di virtualizzazione del sistema operativo di origine.

Nessun commento »

Pubblicato in 2-allarme , pacchetto di decodifica

Tags:

Come nascondere una backdoor Dietro una porta attiva di Windows Ascolto

3 settembre 2009

La sua una tecnica comune. Si sospetta che uno dei vostri sistemi è stata compromessa, in modo da eseguire un port scanner contro il sistema. La speranza è che se il sistema è backdoored si identifica una porta senza documenti ascolto. Ma cosa succede se un attaccante intelligente nasconde la backdoor nel sito normale? Che cosa succede se si nascondono dietro la backdoor una porta esistente che effettivamente si aspettano di vedere in ascolto sul sistema? Purtroppo questo è fin troppo facile da realizzare se l'host è in esecuzione Windows.

Il modo in UNIX

Su un sistema UNIX o Linux, le porte di ascolto sono sempre aperti in modo esclusivo. In altre parole, se un processo si apre TCP/25 posta per accettare le connessioni posta in entrata, qualsiasi altra applicazione che tenta di ascolto su TCP/25 riceverà un errore di legare e di essere negato l'accesso. L'unico modo per la seconda applicazione può legare TCP/25, è quello di uccidere in primo luogo fuori del processo di posta elettronica utilizzando la porta. Quindi una sola applicazione alla volta è sempre consentito l'accesso ad una presa di ascolto.

Il modo di Windows

In Windows, l'accesso esclusivo a una porta di ascolto è opzionale. Il suo perfettamente legale per avere più applicazioni in ascolto sulla stessa porta TCP o UDP. Questo naturalmente può semplificare il processo di creazione di una backdoor dietro un'applicazione esistente.

Con Windows, esclusività di accesso presa è in realtà un processo che si è evoluto nel corso degli anni. Windows 95, 98 e ME in realtà non aveva modo di aprire una porta in modo esclusivo. Non c'era niente di un'applicazione potrebbe fare per prevenire un altro di attaccarsi alla stessa porta di ascolto. Per le versioni di Windows tra NT e XP, è possibile richiedere un accesso esclusivo porta tramite l'opzione SO_EXCLUSIVEADDRUSE. Se l'accesso esclusivo non è espressamente richiesto tuttavia, il valore predefinito è di ripiegare a fornire l'accesso condiviso.

Con Windows 2003 e versioni successive, il valore predefinito è porta di accesso esclusivo a meno che entrambe le applicazioni specificamente richiesta di accesso condiviso attraverso l'opzione SO_REUSEADDR. L'eccezione è che se lo stesso account viene utilizzato per lanciare entrambe le applicazioni, l'accesso condiviso è ancora possibile l'accesso esclusivo a meno che non sia espressamente richiesto. Ciò significa che se un attaccante esperto può lanciare i loro backdoor attraverso l'account di sistema, questa maggiore sicurezza di solito è sconfitto.

Provate voi stessi

Per verificare come funziona, avrete bisogno di una copia della versione per Windows di Netcat . Copia nc.exe in una delle directory nell'istruzione di percorso. Una volta fatto, aprire un prompt dei comandi e provare il seguente comando:

C: \> nc-l-p 135

Non è possibile afferrare 0.0.0.0:135 con legano

Abbiamo appena detto Netcat di ascoltare (-l) sulla porta TCP (-p) 135. All'avvio di Windows prima in su, Microsoft RPC TCP/135 si apre con l'opzione SO_EXCLUSIVEADDRUSE. Così, se tutte le applicazioni (come Netcat) cerca di ascolto su TCP/135, riceve l'errore di legare sopra indicato. Questo è il tipo di comportamento ci piacerebbe vedere tutto il tempo.

Ora provate ad aprire una porta che non sia già in uso:

C: \> nc-l-p 1234

Dovrebbe apparire come se il comando è appesa (prompt dei comandi non ritorna). Questo ti dice che Netcat è ora in ascolto sulla porta TCP/1234. Per verificare questo, aprire un secondo prompt dei comandi e digitare il comando:

C: \> netstat-an | find "1234"

TCP 0.0.0.0:1234 0.0.0.0:0 ASCOLTO

Questo ci mostra che Netcat è ora in ascolto su TCP/1234 su tutte le interfacce di rete.

Netcat quando apre una porta di ascolto che non richiede l'accesso esclusivo al porto. Ciò significa che è possibile associare Netcat a una porta esistente ascolto che non sia già stato aperto in modo esclusivo. Per verificare ciò, aprire un comando di terza e quarta prompt. Immettere il comando stesso Netcat in ogni che si esegue all'interno del primo comando prompt. Ogni comando deve eseguire senza errori.

Questo significa Netcat è l'ascolto più volte? Tornare alla finestra di comando secondo prompt e provare il seguente comando:

C: \> netstat-aon | find "1234"

TCP 0.0.0.0:1234 0.0.0.0:0 ASCOLTO 448

TCP 0.0.0.0:1234 0.0.0.0:0 ASCOLTO 3044

TCP 0.0.0.0:1234 0.0.0.0:0 ASCOLTO 3016

Abbiamo aggiunto l'interruttore "o" il quale visualizza l'ID del processo per l'applicazione tiene aperto la porta di ascolto. Si noti che una diversa istanza di Netcat è responsabile per ognuna delle porte aperte in ascolto. Netcat perché non richiede l'accesso esclusivo al porto, si può ascoltare sulla porta più volte.

Che cosa succede quando qualcuno tenta di connettersi alla porta? Provalo e scoprire usando il comando seguente:

C: \> nc 127.0.0.1 1234

Questa è una prova

Si dovrebbe vedere il testo "Questo è un test" appaiono in una sola istanza degli ascoltatori Netcat. Se si lascia questa sessione attiva e aperta (l'ennesima) prompt dei comandi e digitare:

C: \> nc 127.0.0.1 1234

Si tratta di test 2

Dovreste vedere questo testo appaiono in una diversa istanza di chi ascolta Netcat.

Che cosa abbiamo imparato

Dal momento che Windows non ha bisogno di applicazioni di avere accesso esclusivo a una porta di ascolto, la sua possibile avere una backdoor maligno seduto dietro una richiesta legittima, sulla porta di ascolto stesso. Questo rende la backdoor non rilevabile quando si esegue una scansione delle porte. Per connettersi alla backdoor è necessario prima occupato la legittima applicazione con una sessione attiva, ma questo è facile da raggiungere.

Nessun commento »

Pubblicato in 2-allarme , sicurezza PC Windows

Tags:

Il tuo indirizzo IP Spoofing Durante una scansione delle porte - Parte 2

31 Agosto 2009

Nel mio ultimo post ho discusso una scansione di inattività e come si può consentire a un utente malintenzionato di mascherare il proprio indirizzo IP durante una scansione delle porte. In questa puntata vedremo alcune tracce, oltre a discutere su come stabilire quando una scansione di inattività è stata utilizzata contro la rete.

L'incremento di monitoraggio IP ID

Iniziamo guardando i pacchetti che stavano monitorando il campo IP ID sul sistema Windows. Ecco ciò che il nostro pacchetto sonda assomiglia a questo:

07:22:15.367140 IP (tos 0 × 0, ttl 64, id 63897, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.1.2203> 192.168.100.2.0:., Cksum 0xeca2 (corretto), vinci 512

Alcuni di questi campi sono abbastanza interessante. Il valore TTL è impostato su "64", che suggerisce un sistema Linux o UNIX. Dal momento che stiamo scrivendo prima il pacchetto direttamente al filo di questo valore è in realtà controllato da hping. 64 appena capita di essere il programma predefinito, ma possiamo cambiare il valore a tutto ciò che vogliamo con il "-t" interruttore.

L'indirizzo di destinazione viene stampato come "192.168.100.2.0", il che significa che il pacchetto è stato inviato alla porta TCP 0 a indirizzo IP 192.168.100.2. Windows non offre servizi sulla porta TCP 0, ma va bene così. Non stiamo in realtà cercando di connettersi al sistema di Windows. Abbiamo solo bisogno di inviare un pacchetto IP in modo da poter verificare il valore IP ID. Se volessimo colpire una porta diversa, potremmo usare hping il "-p" interruttore.

L '"." Dopo la specifica destinazione significa che non sono stati flag TCP trova all'interno del pacchetto. Questo viene definito come un pacchetto nullo e non avrebbe mai verificarsi durante le normali comunicazioni IP. Per questo motivo, NIDS può, NIPS e firewall lo bandiera. Abbiamo creato un pacchetto nullo perché non dire hping inviati a uno qualsiasi dei flag TCP. Per esempio aggiungendo lo switch "-S" avrebbe acceso il flag SYN, "-A" si trasformerebbe sulla bandiera riconoscimento, e così via.

Tutti i nostri pacchetti di prova per i sistemi di Windows è simile a questo. Gli unici valori che cambierebbe è il timestamp (ovviamente), la porta TCP di origine e il valore di checksum CRC.

Ecco cosa le risposte sembrano tornare dal sistema di Windows:

07:22:15.367296 IP (tos 0 × 0, ttl 128, id 108, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (corretto), 0:0 (0) ack 918250228 win 0



07:22:16.367453 IP (tos 0 × 0, ttl 128, id 109, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.0> 192.168.100.1.2204: R, cksum 0xfa78 (corretto), 0:0 (0) ack 2127488152 win 0



07:22:17.367763 IP (tos 0 × 0, ttl 128, id 110, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (corretto), 0:0 (0) ack 1611256374 win 0

Il valore importante è l'ID IP, identificato come "id". Nel primo pacchetto è impostato a 108, e poi gli incrementi di valore di +1 per ogni pacchetto successivo (109 poi 110). Finché continuiamo a vedere una sequenza ininterrotta l'ID IP, sappiamo che il sistema Windows non trasmette tutti i pacchetti eccetto quelli che fanno parte di questa sessione.

Sondando una porta chiusa

Ricorda che come parte del nostro scansione, saremo spoofing l'indirizzo IP sorgente del sistema Windows quando porte di destinazione su un sistema remoto. Un cambiamento l'incremento ID IP è quello che ci dice che abbiamo trovato una porta aperta.

Diamo uno sguardo a uno di questi pacchetti in grado di:

10:30:28.852602 IP (tos 0 × 0, ttl 64, id 41256, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.1266> 192.168.100.3.79: S, cksum 0x97a6 (corretto), 1704542340:1704542340 (0) vince 512

Nota l'indirizzo IP di origine è quella del sistema Windows (192.168.100.2). Sappiamo che questo non poteva venire dal sistema Windows ma perché il TTL è impostato a 64. Quindi questo è un pacchetto che abbiamo generato da 192.168.100.1 con una seconda istanza di hping.

Si noti anche che hanno preso di mira la porta TCP 79 e hanno acceso il flag SYN. Ecco la risposta che abbiamo ricevuto dal target remoto:

10:30:28.852839 IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), lunghezza 40) 192.168.100.3.79> 192.168.100.2.1266: R, cksum 0xbb1a (corretto), 0:0 (0) ack 1704542341 win 0

Notare il valore "R" che ci dice la bandiera ripristino è stato acceso nell'intestazione TCP. Vediamo anche "ack" che ci racconta la bandiera riconoscimento è stato acceso pure. Si tratta di un pacchetto di errore informa la fonte che la porta TCP è in uno stato chiuso. Si noti inoltre che il pacchetto viene trasmesso al sistema Windows dal momento che era l'indirizzo IP sorgente del pacchetto della sonda.

Così come sarà il sistema Windows rispondere? Si può ricordare dal mio ultimo post che la RFC stato non si dovrebbe mai rispondere ad un pacchetto di errore. Anche se il sistema Windows non ha idea di cosa il target sta parlando, verrà tranquillamente scartare questo pacchetto di errore. In altre parole, il sistema Windows non inviare una risposta. Questo significa che dovremmo vedere alcun cambiamento nella incremento IP ID.

Sondando una porta aperta

Ora diamo un'occhiata a cosa succede quando ci bersaglio di una porta che in realtà è in uno stato aperto. Ecco il pacchetto della sonda. Nota è abbastanza simile a quello ultimo, solo che adesso stiamo verificando la porta TCP 80.

10:29:46.947964 IP (tos 0 × 0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (corretto), 947341260:947341260 (0) vince 512

Ecco la risposta da parte del target. Si noti che vediamo una "S" invece di una "R", il che significa che SYN flag è acceso e non la bandiera reset. Questo è il modo obiettivi di informare la fonte che la porta TCP 80 è aperta e se ha un'applicazione seduto dietro di esso le connessioni di manutenzione.

10:29:46.953333 IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), lunghezza 44) 192.168.100.3.80> 192.168.100.2.1984: S, cksum 0x0de6 (corretto), 262246932:262246932 (0) ack 947341261 win 5840 <mss 1460>

Così questa volta il sistema Windows riceve un pacchetto dicendo: "Certo, è possibile collegare alla porta TCP 80". Questo è un problema per il sistema di Windows perché non ha voce di connessione dicendo che in realtà tentato di connettersi alla porta 80 sul bersaglio. Senza la voce di connessione, Windows non ha modo di sapere quale applicazione richiesta la sessione. Con questo in mente, lo fa l'unica cosa che può fare: trasmettere un pacchetto ripristinare l'obiettivo di chiudere la sessione. Ecco cosa il pacchetto sembrava:

10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (corretto), 947341261:947341261 (0) win 0

Si noti che Windows timbrato il successivo ID IP disponibili nell'header IP (176). Quindi, se fossimo stati l'incremento di monitoraggio IP ID sul sistema Windows in una sessione diversa, avremmo visto: 173, 174, 175, 177, 178, 179. In altre parole, avremmo visto che mancava 176 (+2 dal pacchetto precedente). Questa sarebbe la nostra indicazione che il TCP/80 sonda inviata verso il bersaglio ha colpito una porta aperta.

Identificare una scansione inattiva

Quindi una scansione inattiva fa un ottimo lavoro di mascherare il vero indirizzo IP sorgente di un port scan. Ciò significa che senza l'accesso per registrare le informazioni sul host di Windows (cosa che non esisterà se l'attacco ha fatto i compiti a casa), non saremo mai in grado di scoprire il vero indirizzo IP di origine dell'attacco.

C'è un modo per raccontare una scansione di inattività è stata eseguita piuttosto che una scansione rettilineo porta avanti in modo da sapere se vale la pena indagare l'indirizzo IP sorgente? Ci sono infatti un paio di indizi possiamo cercare.

Sonda tentativi

Se il sistema mirato è seduto dietro un firewall, si noterà una differenza nel numero di tentativi sonda rispetto a un port scanner normale. Quando qualcuno esegue un normale scanner porta, lo scanner in genere colpire le porte aperte, ma solo una volta le porte firewall più volte. Questo perché le porte firewall di ritorno alcuna risposta. Lo scanner farà diversi tentativi di assicurarsi che i pacchetti non sono solo perdersi. Dato che la porta aperta effettivamente rispondere, solo un pacchetto sonda è necessaria.

Quando una scansione inattiva viene eseguita, è vero il contrario. Se una porta firewall viene sondato non ci sarà alcun incremento IP cambiare ID sul sistema Windows. Quindi, solo un controllo è necessario per confermare questa non è una porta di ascolto attivo. Quando una porta aperta è sondato comunque, faremo rilevare un cambiamento di ID incremento IP del sistema Windows. Anche se pensiamo che questo sia dovuto a noi trovare una porta aperta, potrebbe altrettanto probabilmente perché il sistema Windows ha inviato una trasmissione. Così si desidera eseguire più sonde contro la porta aperta per garantire che i dati IP ID di Windows rimane costante.

Così:

  • Sonda firewall le porte il più delle volte le porte aperte = port scanner normale
  • Porte sonda aprire più spesso che le porte firewalled = scansione inattiva

Tempismo

Scansioni delle porte normali essere estremamente veloce. Non è raro vedere centinaia di pacchetti di prova al secondo. Con una scansione di inattività però, dobbiamo prendere le cose un po 'più lento. Questo perché dobbiamo controllare l'ID IP spoofing dell'indirizzo, inviare il pacchetto sonda, consentono tempo sufficiente per la sonda di ottenere una risposta, dare al sistema contraffatto tempo sufficiente per rispondere con un reset, se necessario (e quindi utilizzando un ID alto IP ), e quindi controllare l'ID IP per vedere se l'incremento è cambiato.

Tenta di eseguire tutti questi passaggi troppo in fretta, e si pagherà il prezzo in precisione. Per esempio nmap supporta la scansione di inattività con l'opzione "-SI" interruttore. La velocità di scansione estremamente veloce di default funziona bene se tutti i sistemi sono sulla stessa rete commutata. Se i padroni di casa sono 15 hop lontano gli uni dagli altri su Internet però, la mia esperienza è stata la valutazione accuratezza cade notevolmente a meno che non rallentare la velocità di scansione.

Così:

  • Centinaia di pacchetti al secondo port scanner = normale
  • Una dozzina o meno pacchetti al secondo scan = possibile inattivo, potrebbe essere solo una scansione lenta

TTL campo

Guardiamo di nuovo il pacchetto sonda contraffatti nonché il ripristino risposta legittima inviata dal sistema di Windows:

10:29:46.947964 IP (tos 0 × 0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (corretto), 947341260:947341260 (0) vince 512



10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), lunghezza 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (corretto), 947341261:947341261 (0) win 0

Avrete notato il TTL sono lontano gli uni dagli altri. Se entrambi di questi pacchetti ha infatti origine da 192.168.200.2 allora avrebbero entrambi hanno lo stesso valore di partenza TTL. Il fatto che essi sono diversi ci dice che uno di loro è falso.

Se si sta monitorando il perimetro del sistema di destinazione e notare che il SYN e pacchetti di reset hanno differenti valori di TTL, questo è un indizio che potrebbe trattarsi di una scansione inattiva. Ora, come detto prima, è del tutto possibile impostare il TTL a che cosa mai vogliamo nel nostro pacchetto camuffato. Quindi, un attaccante intelligente è semplicemente andando a fissare i loro partenza TTL a 128 per imitare meglio il sistema Windows. Se fanno questo, la vostra unica speranza è che l'attaccante e il sistema Windows sono un diverso numero di salti di distanza. In altre parole, se si vede costantemente i pacchetti SYN con un TTL di 115, ma il ripristino sempre hanno un TTL di 113, si sta probabilmente guardando una scansione di inattività.

Se il TTL coincidono, non possiamo del tutto escludere una scansione inattivo. L'attaccante potrebbe essere solo quella buona.

Così:

  • TTL di SYN e RSTS sono coerenti ma che non corrispondono scansione minimo =
  • TTLS di SYN e RSTS corrispondere port scanner normale = o smart scanner stand-by

ID valore IP

Il miglior modo per contrassegnare una scansione minimo è sfruttare la stessa cosa l'attaccante usa, cioè il valore di ID IP. Prendere un altro sguardo a queste ultime due pacchetti decodificati. Si noti che l'ID IP nel primo è 15249, ma nel secondo è 176. Se state vedendo una scansione inattiva, noterete i pacchetti resto sempre un ID di IP +2 (stessa cosa l'attaccante vede), ma i pacchetti SYN avrà un valore del tutto indipendenti. L'incremento ID IP nei pacchetti SYN possono essere prevedibili o potrebbe essere casuale. Onestamente non importa. Ciò che conta è che si possono individuare alcuni pattern in ID IP dei pacchetti riposo che non jive con gli ID di IP nei pacchetti SYN.

Così:

  • ID IP dei pacchetti SYN e RST sembrano essere legati port scanner = normale
  • Incremento ID IP di RST non corrisponde SYN = scansione inattiva

Executive Summary

Spero che ora hanno una migliore comprensione di ciò che sta accadendo sul filo quando un pirata informatico effettua la scansione di inattività. Se ci sono mirati con una scansione di inattività, non siamo in grado di determinare il vero indirizzo IP di origine dell'attaccante. Il meglio che possiamo sperare di ottenere è quello di determinare che la scansione è una scansione inattiva contro una scansione delle porte normali. Ci sono una serie di indizi dicono racconto in pacchetti, il migliore dei quali è il valore ID IP.

Nessun commento »

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

Tags:

Mappatura della rete attraverso un firewall - Parte 3

26 Agosto 2009

Nei miei ultimi due post ho parlato di due metodi differenti che possono essere utilizzate per mappare una rete attraverso un firewall. Il primo tempo leveraged ICMP superato in errori di transito, mentre il secondo usato l'IP di rilevazione d'instradamento. In both posts I also gave possible solutions for preventing an attacker from using these techniques against your network.

In both cases however, supported features available in commercial grade firewalls limited our security options. In this third and final part of the series, I will cover how to properly prevent these attacks if you are using an open source firewall. I will specifically be using Netfilter , but many of the techniques are applicable to pf as well.

What is Netfilter?

Netfilter is the stateful inspection firewall that is included in every modern distribution of Linux. If you have a copy of Linux, you also have a copy of Netfilter. Netfilter is sometimes referred to as iptables , but this is because iptables is the name of the binary you use to manipulate the Netfilter rulebase. Netfilter is an extremely capable firewall with too many features to cover in this post. I highly recommend you check out some of the FAQs and tutorials as they do an excellent job of describing many of the features.

Controlling tcptraceroute

In the first post I described how tools like tcptraceroute could punch through an open firewall rule to map the network sitting behind it. With commercial firewalls, we were limited to controlling the flow of outbound ICMP time exceeded in transit errors.

With Netfilter, we have the ability to control traffic based on the TTL value. We can look for a specific value, or a value above or below a certain threshold. The supported switches are:

  • -m ttl –ttl-eq = Match packets with a TTL of a specified value
  • -m ttl –ttl-gt = Math packets with a TTL higher than a specified value
  • -m ttl –ttl-lt = Match packets with a TTL below a specified value

Here is a possible Netfilter rule we can use:

iptables -A FORWARD -m ttl –ttl-lt 5 -j DROP

This rule would be processed prior to any permit rules in the rulebase. The rule simply checks the TTL value to see if it is less than 5. If so, the packet is dropped. Since the lowest TTL used by a modern OS is 64, and most systems are about 15 hops away from each other on the Internet, we should never inadvertently filter out legitimate traffic.

Here's tcptraceroute running though a regular firewall:

[root@fubar ~]# tcptraceroute -n -f 1 -m 5 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 39142 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 5 hops max
1 10.1.2.2 0.353 ms
2 10.1.4.1 0.450 ms
3 10.1.4.10 [open] 0.586 ms

And here is what tcptraceroute sees once we implement the above Netfilter rule:

[root@fubar ~]# tcptraceroute -n -f 1 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 54531 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 30 hops max
1 10.1.2.2 10.175 ms
2 10.1.4.1 0.464 ms
3 *
4 *
5 *
6 *
7 10.1.4.10 [open] 1.007 ms

Si noti che, una volta cominciare a filtrare il valore della TTL, l'aspetto delle nostre variazioni di perimetro. Senza la regola di un utente malintenzionato potrebbe enumerare o schema di indirizzamento IP. Anche se filtrati i pacchetti in uscita Timex, avrebbero ancora conoscere il conteggio corretto hop. La regola Netfilter rende molto più difficile identificare con precisione il nostro layout di rete.

Aggiunta in alcuni inganno

Una delle caratteristiche più potenti di Netfilter è la possibilità di personalizzare rifiutare i messaggi. Mentre la maggior parte dei firewall respingono i pacchetti restituendo un messaggio di errore negato, Netfilter consente di scegliere tra una serie di diversi codici di errore irraggiungibile. Questo rende per alcune interessanti possibilità. Per esempio, si consideri la seguente regola:

iptables-A FORWARD-m ttl-ttl-lt 5-j REJECT-reject-with icmp-host-unreachable

Questa regola dice a Netfilter che ogni volta che vede un pacchetto con un meno di 5 TTL, dovrebbe restituire un pacchetto ICMP host non raggiungibile destinazione. In altre parole, Netfilter sarà impersonare un router e dire al sistema di trasmissione che l'host di destinazione è off-line. Ecco un esempio di output tcptraceroute una volta che questa regola è stato realizzato:

[Root @ fubar ~] # tcptraceroute-n-f 1-q 1-S 80 10.1.4.10
Selezionato dispositivo eth0, indirizzo 10.1.1.10, porta 47555 per i pacchetti in uscita
Tracciare il percorso 10.1.4.10 sulla porta TCP 80 (http), 30 punti di passaggio max
1 10.1.2.2 0,299 ms
2 10.1.4.1 0,450 ms
3 10.1.4.1 0,403 ms! H

Confronta questa uscita per l'uscita tcptraceroute prima mostrato sopra. Si noti che la linea 3 è ora differente. Con un firewall normale, luppolo tre era una risposta da l'host di destinazione. In questa uscita però, sembra che il router a monte sta tornando un ICMP irraggiungibile ospitante (designati come "! H") a significare l'host è off-line. Dal tcptraceroute pensa l'host è off-line, offre a cercare e non raggiunge mai effettivamente l'host di destinazione.

Così, mentre questa tecnica è un po 'di sicurezza attraverso l'oscurità, è efficace a disabilitare uno strumento che normalmente pugno destro attraverso un firewall. Poiché il traffico regolare non avrebbe un valore anormalmente basso TTL, che non corrisponde a questa regola e non è influenzato.

Controllo percorso di registrazione

Nel mio secondo post di questa serie ho parlato di percorso di registrazione e come può essere sfruttato per mappare attraverso un firewall. Ho discusso che la gamma dello strumento è limitato (max 8 luppolo, 3 se si desidera informazioni hop in entrambe le direzioni), ma che ci sono modi per un utente malintenzionato per aggirare questa limitazione. Ho anche detto che i firewall commerciali in genere non vi darà la possibilità di controllare il routing del traffico record.

Con Netfilter, c'è il supporto per il controllo delle opzioni IP tramite il modulo ipv4options (http://netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html). Gli switch supportati sono:

  • -M-ipv4options ssrr = Incontro con i pacchetti sorgente rigoroso percorso di
  • -M-ipv4options lsrr = Incontro con i pacchetti source routing esteso set
  • -M ipv4options-rr = pacchetti Incontro con record del percorso
  • -M ipv4options-ts = pacchetti Incontro con set timestamp
  • -M ipv4options-ra = pacchetti Incontro con router-alert set
  • -M ipv4options-qualsiasi-opt = Individua i pacchetti con almeno un set opzione IP

Ecco un esempio di una regola che potrebbe bloccare i pacchetti con l'opzione fonte percorso:

iptables-A FORWARD-m ipv4options-rr-j REJECT-reject-with icmp-host-unreachable

Nota stiamo inviando indietro un ICMP irraggiungibile host in risposta. Questo è per spegnere il nostro strumento di mappatura di rete.

Executive Summary

Mentre commerciale firewall eccellere in gestione centralizzata e di colori piacevoli selezionando per la loro interfaccia grafica, di solito impallidiscono di fronte ad aprire firewall source per quanto riguarda il controllo del traffico sul filo. Al fine di proteggere le loro reti, gli amministratori di firewall bisogno di un maggiore controllo del header IP che semplicemente scrutando la fonte e l'indirizzo IP di destinazione.

Nessun commento »

Pubblicato in 2-allarme , sicurezza di rete

Tags: