Individuate serie vulnerabilità nello stack TCP/IP

Http, ftp, smtp ecc sono layer superiori semmai (ovviamente è relativo)

no, anche se il numero sale e' il contrario ..sono inferiori

Quando il software/Programma come il Browser Web comunica via Http Protocol col server , questo layer Application inferiorie viene poi incapsulato in un Layer di trasporto superiore = Layer/livello TCP con header..ed a sua volta il Layer Tcp sta' dentro ad un Layer superiore ancora che e' l'Ip e suo header ..che a sua volta viene trasportato nei Frames Ethernet da 1500bytes (MTU) che a sua volta viaggiano tramite skede di rete sui cavi & router/Gateway

Corretto. Infatti ho detto che è relativo, nel senso che è giusto quello che dici riguardo l'incapsulamento ma ricordo bene che quando ho studiato reti era evidenziata questa "ambiguità" quando si parlava dei protocolli "alti" (http, ftp ecc. ecc.) in presenza di magari qualche tavola che raffigurava lo stack tcp/ip.

Detto questo leggendo la new si parla di 5 tipi di attacchi di base e 30 possibili attacchi differenti in base alle varie implentazioni . E' pur vero (anche se molto discutibile) che tcp/ip è lo standard de facto e iso/osi magari è quello de iure ma qui sembra che ognuno si sia implementato il suo personal tcp/ip e l'hanno fatto pure buggato a quanto pare ...............non so voi ma io rimango sempre più perplesso.

[color=red]Visron wrote:[/color]
> no, anche se il numero sale e' il contrario ..sono inferiori

Mah... mi suona strano...
Io ho sempre saputo che in informatica, parlando di "livello" senza precisare altro, si sottintende sempre il "livello di astrazione", non quello di "incapsulamento" od altro.

facciamo cosi': livello 0 = hardware ...Livello 1 Frames...livello 2 IP datagram.. livello 3 Tcp...livello 4 Application protocol Layer

Io intendevo superiore a scendere di livello partendo dal software (es. il browser Web ) che dialoga via HTTP protocol che lo stack poi incapsula a catena sul trasporto (tcp/ip) scendendo cmqe di livello numerico ... se ho fatto confusione , pardonn

Non è vero. La pila OSI è uno standard (è di questo che si occupa l'ISO) che specifica esattamente i protocolli necessari per implementare ciascun livello. Semplicemente i protocolli non sono mai stati utilizzati nella pratica, perché non soddisfacevano le esigenze del mercato, che ha mostrato di preferire protocolli più semplici come l'IP. Però nulla ti vieterebbe di realizzare una rete completamente basata su OSI anziché IP o ATM o qualunque altro stack protocollare realmente usato.
Oggi lo standard è morto e sepolto, però per qualche motivo i programmi accademici continuano a fare riferimento al "modello di riferimento OSI", coi suoi famosi sette livelli, per illustrare il funzionamento di un sistema di telecomunicazioni.

No no, OSI specifica proprio i protocolli implementativi. Lo standard OSI è stato un concorrente a tutti gli effetti per gli altri protocolli quali IP, IPX eccetera. Solo che ha perso di brutto .



Penso che è normale che non ti sovviene, non li avrai mai sentiti nominare perché non sono usati da nessuna parte . Scherzi a parte, probabilmente se sono ancora in uso residuale da qualche parte, mi aspetto che sia nel mondo delle telecomunicazioni piuttosto che in quello delle reti di computer.

Ad esempio, il corrispondente dell'IP era il CLNP. Al posto dell'FTP c'era l'FTAM. Al posto del TCP c'era il TP4. (Grossomodo.)

Ogni tanto qualche reliquia di questi protocolli salta fuori ancora oggi (per esempio l'X.509 per quanto riguarda i certificati di chiave pubblica).

E' stupendo leggere queste cose, ma ancora più divertente leggere le reazioni catastrofiche che generano...
Parlare di "costringere il sistema bersaglio ad un riavvio forzato per poter riprendere il normale funzionamento" a me francamente fa un po' ridere considerando che tipicamente un progetto o un servizio di dimensioni/importanza tali da essere un potenziale bersaglio di un attacco di questo tipo ha generalmente una complessità tale, ed è frutto di un accrocchio di tecnologie tali, da richiedere esso stesso un riavvio totale o di qualche componente ciclicamente o con cadenza randomica...

Mi è successo proprio oggi su un servizio vitale di un grosso cliente... riavviato il servizio, aperto e chiuso il ticket in 5 min e tutto è tornato normale.
Insomma non c'è bisogno di scomodare una fantomatica vulnerabilità di un protocollo di rete vecchio di trent'anni (e che vive di collissioni ed errori tra l'altro...) per generare una casistica del genere, quando la gran parte dei servizi e dei sistemi considerati vitali:
[LIST]
[*]sono fatti tipicamente da nmila società diverse che seguono logiche diverse e non si parlano tra loro
[*]sono passati di mano a nmila persone differenti che non si sono mai parlate
[*]sono stati implementati usando nmila strumenti e servizi differenti
[*]spesso sono nati "oggi per ieri" usando strumenti di fortuna o immediatamente disponibili e poi diventati definitivi anche se inadeguati
[/LIST]

Insomma non fasciamoci la testa per una eventualità che non solo è la realtà attuale, ma che si verifica continuamente, anche ora mentre ne stiamo parlando...
...e non certo per una stupida vulnerabilità nello stack tcp

Sono ignorante ma vi seguo con questi discorsoni da studiosi pazzi...Era una battuta logico...
Mi piace seguire le vostre idee e ricorrette da altri....
Diciamo che non so di cosa parlate, ma sarei davvero contento di avere un grafico scritto da IGNORANTI su questo problema che c'e' o ci sara.
Grazie siete mitici.....

No no, standar iso/osi è uno standard a tutti gli effetti solo che nella pratica quello "de facto" come ti dicevo prima è lo standard tcp/ip. Cmq se non ho capito male il bug si sviluppa dopo il 3-way handshake ma non ho capito come, sto provando a cercare qualcosa di concreto ma non ho ancora trovato nessun riferimento concreto. Mi sa tanto di millennium bug la vendetta.