L'impostazione di una politica DROP predefinita migliora effettivamente la sicurezza?

Impiegando una regola DROP predefinita per tutte le porte tranne quelle originariamente previste (per un sito web questi sono 80/443) si riduce la superficie di attacco delle stazioni date sulla rete. È molto più conveniente (ed economico) eliminare pacchetti invece di configurare un servizio in modo che sia sicuro rispetto a una determinata politica.

Ci sono un paio di diversi spin che possono essere messi nella tua domanda, ma ho intenzione di indirizzare È meglio DROP per le porte non consentite che REJECT?

Eliminare i pacchetti - silenziosamente, senza TCP RST o ICMP vietato - è preferibile per almeno due ragioni.

1. Rallenta gli scanner che cercano di raggiungere un numero elevato di porte, perché non ricevono feedback positivi.
2. Riduce i falsi positivi sulle scansioni: gli scanner che vedono i messaggi RST / Proibiti li aspettano e quando eseguono una scansione di grandi dimensioni a volte questi pacchetti vengono persi. Se non invii mai risposte, non mancheranno i pacchetti scartati su una scansione e li chiuderà.

Se esegui una scansione autonomamente (ad esempio per il controllo della conformità), la riduzione di tali falsi positivi è un miglioramento notevole. E se stai abbassando i falsi positivi per gli scanner malintenzionati, beh, preferirei che non si eccitino a guardare i porti che sono effettivamente chiusi; Preferirei avere una scansione accurata e, guardandola, decidere di andare a pescare altrove.

Lo metterei alla difesa in profondità. Sì, puoi configurare i tuoi servizi per ascoltare solo localhost o la tua rete interna. Anche se configurato correttamente, c'è ancora la possibilità che, a causa di un bug nel codice, accetti per errore tutto il traffico. I servizi che accettano pacchetti UDP possono anche essere vulnerabili a un attacco di spoofing IP. TCP è resistente a un tale attacco poiché l'impostazione della connessione non ha mai luogo, ma si possono finire con molte connessioni TCP aperte a metà, che possono DOS eseguire il servizio. Ciò può essere eseguito perché l'utente malintenzionato può effettuare lo spoofing di un indirizzo IP interno a cui è consentito l'accesso al servizio. Questo attacco è comunemente noto come un attacco di inondazione SYN. Maggiori informazioni: link

Alla fine della giornata, avere ulteriori precauzioni aumenta la quantità di lavoro che un utente malintenzionato deve compiere per compromettere il sistema. Safegaurds aggiuntivi riducono anche la possibilità di un singolo errore che causa una violazione.

Comprendi correttamente la situazione; c'è un vantaggio minimo nel far cadere il traffico verso le porte chiuse. Tuttavia, è ancora considerato "best practice".

Penso che la ragione per cui ShieldsUP avrebbe segnalato questo è che potrebbe indicare un errore di configurazione. Se un amministratore del firewall intende bloccare tutte le porte chiuse e ne manca uno per qualche motivo, questo è qualcosa che ShieldsUP può rilevare in una scansione. Hanno messo una valutazione del rischio sul risultato? Se è qualcosa di più alto di "basso", lo metterei seriamente in dubbio.

La tecnologia firewall di rete non è cambiata molto dalla fine degli anni '90, e molti consigli provengono da un'era di "più lockdown è buono" senza una grande comprensione di ciò che i lockdown effettivamente aiutano. La maggior parte dei progressi che si sono verificati con i firewall si sta spostando oltre il livello di rete e facendo "ispezione approfondita". Ma su una porta chiusa, non c'è assolutamente alcuna ispezione approfondita da fare.

In cima alla mia testa, una ragione ovvia è che costringe lo scanner a impiegare più tempo per determinare se un servizio è presente su una determinata porta o meno. Non sa se i pacchetti sono stati rilasciati sul percorso, o il percorso verso il server al quale accede ha solo un RTT lungo, oppure esiste un criterio firewall DROP predefinito. E tutto ciò che rallenta gli aggressori, e solo lievi inconvenienti, le persone che mappano Internet, senza intaccare gli utenti legittimi che si vogliono realmente connettere, è una buona cosa (TM).

Poi c'è il fatto che questa affermazione da parte tua "invece di prendere il tempo per configurare correttamente questi servizi, gli amministratori ti mettono semplicemente davanti un firewall". non tiene conto del fatto che questi servizi potrebbero essere come configurati correttamente possibile e contenere ancora un 0day. Potresti volere che il servizio sia in esecuzione e persino visibile a (alcuni) utenti esterni, ma nascosto dietro un porto knocking / SPA soluzione, o semplicemente filtraggio per indirizzo IP (inserendo una regola che accetta i tentativi TCP dagli indirizzi autorizzati).

Se usi SPA, non importa quanti servizi ci sono dietro il firewall, o quanti di loro hanno errori di configurazione orribili o 0days, gli unici di cui devi preoccuparti sono il firewall stesso, la soluzione SPA e i servizi esplicitamente inseriti nella whitelist nel firewall. Naturalmente, devi anche preoccuparti di chi ha le chiavi SPA, ma questa è una discussione diversa.

E se filtri per IP, è la stessa idea; eccetto che ora devi solo fidarti di quegli host, fidarti del firewall, fidarti del tuo ISP (fino a un certo punto) e fidarti che un solo pacchetto parassita, parzializzato da solo, non sarà in grado di interrompere il servizio.

Questo ha senso per lo stesso motivo per cui tutte le whitelist hanno senso; la sicurezza non viene mai danneggiata e solitamente viene aiutata, quando le funzionalità vengono erogate in base a necessità strettamente necessarie e le informazioni vengono distribuite in base a necessità di conoscenza.

Per le catene OUTPUT e FORWARDING, il ragionamento alla base di una politica DROP predefinita dovrebbe essere abbastanza ovvio; le politiche DROP predefinite su tali catene sono la parte più fondamentale di qualsiasi politica di filtraggio in uscita.