Richieste ARP unificate: considerate dannose?

Dopo alcuni avanti e indietro sulla mailing list Snort (e non riuscendo a contattare l'autore per questo regola), ho deciso di prendere

It's not the defined behaviour, and although ARP Polling may be a thing on some specific systems, the rule still needs to be there because we do not know a priori whether it's justified by some context-specific mechanism. And even if we do not see how they could be dangerous, there is no reason for a legitimate host to send unicast requests, and so it should trigger an alert like any unorthodox behaviour.

per una risposta. Voi ragazzi sollevate punti interessanti, ma sono più come ipotesi plausibili e meno come la risposta "definitiva" che ho cercato, che immagino solo Jeff Nathan possa fornire.

Grazie però per le tue risposte, ho imparato da loro.

NB: prima della mia modifica questa risposta azzardava forse questo perché un host aggiunge un accoppiamento MAC < - > IP alla sua tabella indipendentemente dal fatto che il pacchetto ARP in arrivo sia una richiesta o una risposta (e quindi si poteva inondare il tavolo di un host inviando richieste), ma poi ho capito che l'algoritmo di ricezione in RFC 826 fa aggiornare un host alla sua tabella finché il campo Destinazione protocollo corrisponde al suo IP, quindi la richiesta non dovrebbe essere unicast per questo attacco a lavorare - torna al punto di partenza.

NB2: ho avuto una chiacchierata divertente con un collega che ha molta più esperienza di me sull'argomento. Gli ho chiesto della regola e quando gli ho parlato di ARP Polling, la sua prima reazione è stata lanciare completamente e tornare alla sua macchina per assicurarsi che non inviasse questo tipo di richieste. Perché non c'è motivo per cui il suo computer debba parlare alla rete quando lui non intende :) (anche perché sostiene che per un host che non si contatta frequentemente, questa funzione di polling risulta inutile traffico).

L'utilizzo normale di ARP avviene attraverso i frame di trasmissione, perché ARP è pensato per consentire macchine per scoprire gli indirizzi MAC di altri host: questo ha senso solo se l'indirizzo MAC è, in effetti, non noto in anticipo. Normalmente, una macchina è responsabile per rispondere alle richieste su se stessa: se qualcuno chiede l'indirizzo MAC della macchina che attualmente possiede l'indirizzo IP 10.0.17.42, allora la macchina dovrebbe rispondere; e, cosa più importante, altri host sulla rete si asterranno dal rispondere, anche se conoscono l'indirizzo MAC del proprietario attuale dell'indirizzo 10.0.17.42.

Che solo il proprietario dell'indirizzo risponde effettivamente evita di annegare la rete. Se una macchina risponde a tutte le richieste che vede, una richiesta ARP broadcast su una rete occupata potrebbe innescare centinaia di risposte.

Affinché una richiesta ARP unicast abbia senso, deve essere inviata a un host per il quale è noto l'indirizzo MAC, quindi non il proprietario dell'indirizzo IP stesso (altrimenti, quale sarebbe il punto della richiesta?); ma quell'host non risponderà per impostazione predefinita. Pertanto, le richieste ARP unicast legittime si verificano solo in contesti in cui è presente un risponditore ARP che è stato configurato per rispondere alle richieste ARP per gli indirizzi IP assegnati ad altre macchine. Questa è una configurazione piuttosto insolita.

Un sistema Linux può essere configurato per rispondere alle richieste ARP per gli indirizzi di altre macchine; questo è chiamato Proxy ARP . Il caso d'uso principale, tuttavia, è per alcuni firewall trasparenti: la LAN è suddivisa in diverse LAN distinte, senza che le macchine locali siano a conoscenza della divisione. La macchina che collega le sotto-LAN insieme esegue proxy ARP per mantenere l'illusione di una singola LAN, mentre continua a filtrare le comunicazioni. Ma in quel caso, le macchine sono inconsapevoli del setup; una richiesta ARP unicast si sarebbe verificata solo da una delle macchine che avrebbe in qualche modo saputo che era stata eseguita una divisione LAN.

Quindi in pratica , le richieste unicast ARP sono di solito il segno del gioco scorretto. Le macchine normali non lo faranno.

Probabilmente a causa di attacco di flooding MAC - una specie di attacco di unicast flood in cui un utente malintenzionato scarica spazio nella tabella di allocazione MAC di uno switch, quindi non è in grado di trova l'indirizzo giusto nella cache degli indirizzi (tutti sono stati forniti dall'attaccante), invierebbe il pacchetto a tutte le porte (se uno switch ha ricevuto un pacchetto unicast con un indirizzo di destinazione sconosciuto, il pacchetto viene trattato come un pacchetto broadcast e viene inviato a tutti gli host della rete). Dopo che la maggior parte / tutti / i MAC legittimi target sono stati forzati fuori dal tavolo, è un buon momento per avviare uno sniffer di pacchetti poiché i pacchetti precedentemente non disponibili che sono stati sputati dallo switch sono presumibilmente disponibili per l'acquisizione. Anche se la cattura di pacchetti non ha inteso questo è già un tipo di attacco DoS, esp. nelle reti di grandi dimensioni (a causa del numero di client che parlano all'interruttore), il che certamente degrada le prestazioni della rete.

BTW, le richieste unicast ARP sono legittime secondo RFC1122 che afferma a pagina 23:

(2) Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.

Non conosco alcun uso legittimo per una richiesta ARP unicast. Lei dice che questa è una caratteristica di alcune implementazioni; hai ulteriori dettagli su questo?

Sospetto che l'uso dannoso di una richiesta ARP unicast sia di aggirare le funzionalità anti-spoofing. Ad esempio, il kernel di Linux non ascolterà una risposta ARP non richiesta, ma è possibile utilizzare una richiesta ARP falsificata per indurla a pensare che venga richiesta una risposta. E una richiesta unicast ha meno probabilità di influenzare altri dispositivi o di essere notata rispetto a una richiesta di trasmissione.

Dato che ci sono così tante regole in snort, ti suggerisco di concentrarti sull'acquisizione di esperienza con una serie di problemi, piuttosto che concentrarti su questo problema in modo molto dettagliato.