Re: [ml] Abbattere il TCP via ICMP

Ancora qualche giorno di pazienza, poi vedo di installare un filtro piu'
intelligente di quello che c'e' ora ...

http://www.expita.com/nomime.html
Configuring Mail Clients to Send Plain ASCII Text

thnx
Koba (moderatore)

----- Forwarded message from Dario Lombardo <dario.lombardo(at)libero.it> -----
From: Dario Lombardo <dario.lombardo(at)libero.it>
Subject: Re: [ml] Abbattere il TCP via ICMP

Le cose che dici sono corrette, ma la domanda era un'altra.

Se provi la poc che hanno rilasciato e sniffi un pacchetto in rete 
vedrai questo:

Frame 1 (72 bytes on wire, 72 bytes captured)
   Arrival Time: Apr 21, 2005 17:58:14.795697000
   Time delta from previous packet: 0.000000000 seconds
   Time since reference or first frame: 0.000000000 seconds
   Frame Number: 1
   Packet Length: 72 bytes
   Capture Length: 72 bytes
   Protocols in frame: sll:ip:icmp:ip:tcp
Linux cooked capture
   Packet type: Sent by us (4)
   Link-layer address type: 1
   Link-layer address length: 6
   Source: EE:HH:EE:HH:EE:HH (IL:MI:OB:EL:MA:CC)
   Protocol: IP (0x0800)
Internet Protocol, Src Addr: 1.1.1.1 (1.1.1.1), Dst Addr: 2.2.2.2 (2.2.2.2)
   Version: 4
   Header length: 20 bytes
   Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
       0000 00.. = Differentiated Services Codepoint: Default (0x00)
       .... ..0. = ECN-Capable Transport (ECT): 0
       .... ...0 = ECN-CE: 0
   Total Length: 56
   Identification: 0xa5d3 (42451)
   Flags: 0x00
       0... = Reserved bit: Not set
       .0.. = Don't fragment: Not set
       ..0. = More fragments: Not set
   Fragment offset: 0
   Time to live: 255
   Protocol: ICMP (0x01)
   Header checksum: 0x0fec (correct)
   Source: 1.1.1.1 (1.1.1.1)
   Destination: 2.2.2.2 (2.2.2.2)
Internet Control Message Protocol
   Type: 3 (Destination unreachable)
   Code: 2 (Protocol unreachable)
   Checksum: 0x8a5a (correct)
   Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1 
(1.1.1.1)
       Version: 4
       Header length: 20 bytes
       Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
           0000 00.. = Differentiated Services Codepoint: Default (0x00)
           .... ..0. = ECN-Capable Transport (ECT): 0
           .... ...0 = ECN-CE: 0
       Total Length: 40
       Identification: 0x61ec (25068)
       Flags: 0x00
           0... = Reserved bit: Not set
           .0.. = Don't fragment: Not set
           ..0. = More fragments: Not set
       Fragment offset: 0
       Time to live: 255
       Protocol: TCP (0x06)
       Header checksum: 0x53de (correct)
       Source: 2.2.2.2 (2.2.2.2)
       Destination: 1.1.1.1 (1.1.1.1)
*  *  Transmission Control Protocol, Src Port: 23 (23), Dst Port: 0 (0)
       Source port: 23 (23)
       Destination port: 1000 (1000)


Come vedi nella parte finale (payload icmp) si riporta il pacchetto che 
avrebbe scatenato l'icmp. Anche tu dici che la faccenda riguarda il 
fatto che l'implementazione ignora il seqnum presente in questo payload, 
rendendo facile l'attacco in quanto ci si basa solo sulla porta. Ora la 
domanda e': dov'e' questo benedetto seqnum? E' l'implementazione della 
poc che non e' corretta? O tutti i pacchetti di proto unreachable 
riferiti al TCP hanno questa conformazione? La domanda e' questa.
Il dissector di ethereal visualizza correttamente il pacchetto, quindi 
questo farebbe pensare ad un payload giusto. Ma se e' cosi' dov'e' il 
seqnum di cui abbiamo parlato?
Spero di aver chiarito meglio la domanda. Peraltro hai detto tutte cose 
giuste e condivido in particolare il discorso sul non chiudere l'icmp. 
Ma questa e' un'altra storia... :)

----- End forwarded message -----