La scansione delle vulnerabilità con credenziali eseguite sui server linux / Unix di Nessus e migliaia di vulnerabilità è uscita dalla porta tcp / 0 . Come può una porta riservata IANA (tcp / 0) gestire il traffico? Queste vulnerabilità sono veramente numerabili o quelle risultate false? Come dovremmo procedere per il processo di riparazione delle vulnerabilità mostrate sotto port tcp / 0?
How could a IANA reserved port(tcp/0) handle traffic?
È possibile . Generalmente, la porta TCP (o UDP) 0 in uno stato riservato non significa che non possa essere utilizzata nella pratica. Anche se il modo in cui sono progettati i socket Berkeley non è così facile collegarsi alla porta zero, è comunque possibile per usarlo.
Tuttavia , è altamente improbabile che questo sia effettivamente accadendo nel tuo caso. Stai solo utilizzando lo scanner Nessus che elenca attività non strettamente correlate a una porta specifica sotto la porta 0 / TCP o 0 / UDP (vedi: " Vulnerabilità per host " ). Questa è semplicemente una convenzione (scomoda?) Per visualizzare gli avvertimenti senza port sotto la porta 0 - ironicamente, per evitare confusione.
Si noti che quelli a) non sono necessariamente vulnerabilità, solo avvertimenti o suggerimenti (ad esempio non aderenti a le migliori pratiche Microsoft durante l'esecuzione di uno scanner); b) non sono necessariamente falsi positivi. Prova a ignorare la porta zero stessa, leggi attentamente il rapporto e agisci di conseguenza.
How could a IANA reserved port(tcp/0) handle traffic?
Mentre la risposta accettata spiega come la porta 0 è ancora una porta reale, può essere utile capire come funzionano le porte in TCP. Di seguito è riportato un diagramma a 32 bit del pacchetto TCP in scala. UDP è simile, anche se molto più semplice (dopo le porte, ha solo un campo lunghezza e un campo checksum prima dei dati).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | Source Port | Destination Port | +-------------------------------+-------------------------------+ | Sequence Number | +---------------------------------------------------------------+ | Acknowledgment Number | +-------+-----------+-+-+-+-+-+-+-------------------------------+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-------+-----------+-+-+-+-+-+-+-------------------------------+ | Checksum | Urgent Pointer | +-------------------------------+-------------------------------+ | Options | Padding | +-----------------------------------------------+---------------+ | | / ... Data (optional) ... / | | +---------------------------------------------------------------+
Come puoi vedere, i campi della porta di origine e della porta di destinazione hanno entrambi una larghezza di 16 bit. Ciò significa che può rappresentare 65536 diversi stati possibili, da 0 a 65535. Questo è incidentalmente il motivo per cui non vi sono porte negative, poiché il valore è considerato come non firmato. L'unica cosa che impedisce a tutte le porte di essere tutti null byte (che rappresentano la porta 0) è uno standard IANA che dice di non farlo. È perfettamente possibile che un pacchetto venga inviato con una qualsiasi delle porte impostate su 0. Lo scopo di mantenere la porta 0 riservata è quello di consentire a "just give me any port" di essere rappresentato da un numero intero a 16 bit. Quando viene effettuato un tentativo di collegarsi a TCP / 0, piuttosto che ascoltare i pacchetti con la porta di destinazione impostata su tutti gli zeri, il sistema dovrebbe collegarsi a qualsiasi porta disponibile.
Leggi altre domande sui tag vulnerability-assessment ports vulnerability-scanners nessus