Porte filtrate: cosa le filtra esattamente?

Generalmente ci sono più dispositivi tra te e il tuo obiettivo. Lungo la strada firewall, router, switch e altri dispositivi di rete possono limitare i tuoi pacchetti a raggiungere il tuo obiettivo. Anche i firewall basati su host oi controlli di accesso alle applicazioni possono causare una risposta filtrata.

A volte si ottiene una risposta dal dispositivo di filtraggio nella risposta di un messaggio di errore ICMP ma nella maggior parte dei casi da qualche parte lungo il percorso i pacchetti vengono semplicemente rilasciati.

Le tue ipotesi:

• Nessun. Iptables può essere configurato per non rispondere affatto a meno che tu non sia su un elenco approvato. O iptables può essere configurato con un elenco di host / reti per non rispondere affatto.
• Dipende da come si definisce il dispositivo di sicurezza. Un termine migliore sarebbe il dispositivo di controllo dell'accesso in quanto potrebbe essere qualcosa come ACL su un router.
• A seconda dell'applicazione e del suo stack di rete è possibile. Un'applicazione con uno stack di rete terrestre utente può scegliere cosa fare con le richieste anziché con il sistema operativo.

Nella maggior parte dei sistemi operativi, la gestione dell'handshake a tre vie TCP è responsabilità del codice di rete del sistema operativo. Le applicazioni possono solo dichiarare interesse a ricevere connessioni su una determinata porta tramite la chiamata di sistema listen (). Il sistema operativo risponderà a un SYN con un SYN / ACK se c'è un'applicazione in ascolto sulla porta e con un RST in caso contrario. Nessuna applicazione ha voce in capitolo.

Questo è il comportamento predefinito. Può essere modificato da molte cose, incluso ma non limitato ai meccanismi di filtraggio dei pacchetti sull'host. Inoltre, l'implementazione specializzata di TCP / IP può comportarsi in modo diverso di proposito.

Quando NMAP non riceve né un SYN / ACK né un RST in risposta a un pacchetto SYN segnala tale porta come "filtrata". Non ha modo di determinare il motivo per cui non ha ricevuto una risposta. Viceversa, se un firewall interposto blocca la porta rispondendo con RST, NMAP segnalerà la porta come chiusa anche se il pacchetto sonda non ha mai effettivamente raggiunto la sua destinazione.

In breve, la tua citazione è almeno inesatta. NMAP segnala anche le porte filtrate se non possono essere determinate come aperte o chiuse per motivi altri oltre al filtraggio dei pacchetti. Il filtraggio dei pacchetti è solo la causa più comune ed è quindi diventato l'eponimo di questo risultato. Inoltre, NMAP può anche segnalare una porta come chiusa quando non può determinarla come aperta o chiusa a causa di un filtro di pacchetti che interviene.

Nel tentativo di inserire la forma più semplice della rete target :

Internet   ---  firewall  ---   target

attraverserai almeno 3 livelli di filtraggio:

1. firewall
2. a livello di sistema operativo del target
3. a livello di applicazione del target

A ogni di questi livelli un 1 ° pacchetto IP (e qualsiasi altro pacchetto di protocollo) come pacchetto ESP o AH) potrebbe ricevere 4 tipi di trattamento:

1. il pacchetto viene semplicemente rilasciato (non una forma di risposta)
2. il pacchetto viene rilasciato e viene restituito un ICMP di tipo 3, codice 9 o 10,
3. riceve un pacchetto RST TCP
4. riceve un pacchetto TCP ACK

Le reti reali sono costituite da questo mattone di base.

Ci sono diverse domande qui, fammi provare e riformattarle, quindi puoi dare una risposta adeguata.

Domanda 1. I sistemi rispondono con SYN / ACK o RST se il traffico raggiunge un host?

Risposta breve - non necessariamente, è possibile ottenere una destinazione ICMP irraggiungibile (porta non raggiungibile), che è considerata una risposta accettabile quando non vi è alcun processo di ascolto su quella porta ( RFC 1122 , pagina 40 e RFC 792 , pagina 5). Potresti anche non avere alcuna risposta - sfortunatamente non tutti sono conformi alle specifiche RFC. Sfortunatamente, ho visto implementazioni che rispondono a SYN con una FIN! Sì, può essere così male.

Domanda 2. ogni sonda che riuscirà a raggiungere la porta riceverà una risposta adeguata?

Risposta breve - non necessariamente, le implementazioni dello stack TCP tra sistemi operativi variano, ad esempio, ho visto sistemi incorporati con risorse limitate che hanno sostituito il processo listener e quando il processo è stato ripristinato in memoria , la finestra di opportunità per una risposta è chiusa. È un'eccezione piuttosto che una regola, ma dovresti tenere presente che non tutti dovrebbero rispettare lo standard - alcuni potrebbero avere meccanismi di protezione dalle inondazioni SYN incorporati che potrebbero vedere troppi segmenti SYN dallo stesso host di un tentativo di DoS.

Domanda 3. Un'applicazione può ignorare le sonde?

In genere non è responsabilità dell'applicazione, è lo stack del sistema operativo che si occupa di queste cose. Non è per dire che non è possibile implementare il proprio gestore di protocollo, ma raramente è il caso. Ma direi che poche applicazioni hanno voce nella parte di handshake TCP delle loro comunicazioni.

Spero che troverai utili queste risposte: -)