Filtro di uscita del firewall per dominio

Are there firewalls we can use that have domain based rules, instead of IP based so our API requests continue to arrive un-interrupted yet we continue to block all other outbound connections?

Sì, anche se di solito attraverso una funzionalità proxy piuttosto che una tradizionale regola del firewall.

Ad esempio, la blade software per il filtraggio degli URL del punto di controllo consente di limitare l'HTTP in uscita e le connessioni HTTPS in base al nome DNS a cui hanno richiesto l'accesso - ad esempio, un GET http://example.com/ HTTP/1.0 o un CONNECT example.com HTTP/1.1 avrebbero successo solo se esiste una regola che consente l'accesso a example.com.

L'aspetto del proxy è il risultato dello spazio del problema. Il DNS inverso non può essere considerato attendibile in alcun modo, forma o forma, quindi il firewall non può semplicemente invertire l'IP a cui il client vuole connettersi e decidere in base a ciò. Deve essere dato un nome al cliente e prendere la sua decisione basandosi su questo. I proxy in stile HTTP funzionano bene per questo perché, anche quando è per una connessione crittografata, il client passa il nome al proxy prima che la connessione possa essere effettuata.

Il problema con questo approccio è che basa efficacemente la sicurezza sul risultato di query DNS su domini remoti. Il DNS inverso può mai essere considerato attendibile perché chiunque può inserire un nome per un IP che possiede. Ma anche in avanti il DNS non ha la sicurezza richiesta - puoi tranquillamente supporre che un aggressore moderatamente motivato possa riuscire a spoofingare o avvelenare DNS se consente loro di estrarre i dati PCI dal tuo datacenter.

(Ciò non significa che non potresti ottenere questo benedetto da un QSA: è un ragionevole controllo compensativo. Non voglio che tu pensi che sia completamente sicuro!)

I hanno affrontato lo stesso problema - per lo stesso ragioni come te - più di un anno fa, e ho concluso che il metodo "sicuro" avrebbe richiesto qualcosa di più di DNS per garantire i siti remoti e che il certificato SSL era una cosa ragionevole per mettere la sicurezza su. Ho finito per implementare tale proxy e usarlo per i miei scopi; la risposta fornita da mr.spuratic promette di fare la stessa cosa (l'unica ragione per cui non l'ho ancora accettato è perché sento il bisogno di testarlo prima)

L'idea del proxy whitelist-by-certificate è davvero interessante / ordinata a cui non avevo mai pensato prima personalmente per questo scenario; Sicuramente darei un'occhiata a quello & vedi se sarebbe fattibile per la tua situazione.

Tuttavia, lasciatemi parlare un po 'della vecchia, una soluzione un po' più semplice che hai menzionato tu stesso: impostando uno script per eseguire periodicamente un controllo DNS per vedere quale indirizzo IP funzionerà al momento. In particolare: quando una domanda correlata chiesto a Unix & Linux SE alcuni anni fa ha prodotto un paio di script di esempio per iptables che funzioneranno con una regola crontab per controllare l'IP per un determinato dominio ogni cinque minuti (da DynamicDNS, in quel caso particolare) e quindi creare una regola che consenta < em> traffico in arrivo da tale IP. Non vedo alcun motivo per cui non si possa prendere uno script preesistente, impostare il tipo di regola su in uscita , apportare qualsiasi altra aggiunta o sottrazione utile a proprio piacimento, e via. Non idealmente elegante, certo, ma non definirei nemmeno questo approccio hacky o ingannevole.

Non sono sicuro che sia corretto copiare o amp; incolla il codice di esempio direttamente da che Linux SE domanda ho fatto riferimento, quindi non lo farò. Tuttavia, ci sono solo due risposte, con un esempio di script ciascuna, nella pagina delle domande. Non difficile da leggere & ordinare affatto.

Infine, dovremmo davvero affrontare ciò che puoi fare per proteggere meglio le tue ricerche DNS. In teoria, se il tuo software di pagamento sta comunicando agli istituti finanziari esclusivamente su https, con il server ricevente autenticato per il client come legittimo avendo un certificato valido. In tal caso, anche i risultati DNS modificati malevolmente ( sia con lo spoofing locale del MitM DNS, con l'avvelenamento della cache DNS eseguito per il server risolvente a cui ci si sta collegando , ecc.) che non sarebbe sufficiente per consentire a un utente malintenzionato di entrare nella / e connessione / i sicura che tu sei inviare le informazioni finanziarie oltre. (Poiché il certificato per un server fasullo impostato da un utente malintenzionato non corrisponde al nome di dominio.) Ma dal momento che dovremmo pensare alla difesa in modo approfondito e presumendo che qualcosa potrebbe andare storto con qualsiasi livello di sicurezza (come forse un La chiave privata di firma dell'autorità di certificazione viene compromessa, in modo che un utente malintenzionato possa firmare qualsiasi server desiderato con qualsiasi nome di dominio), supponiamo di volere una sorta di protezione affidabile per le query DNS. Sfortunatamente, ciò significa che (a) esegue effettivamente un server DNS - con DNSSec abilitato e configurato correttamente per prevenire gli attacchi di avvelenamento- - direttamente sulla macchina locale che sta per effettuare la connessione o (b) utilizzando DNSCrypt per creare una connessione crittografata a OpenDNS o un server DNS fidato (con DNSSec attivo) che hai configurato all'interno della tua rete locale.

Quindi hai almeno una o due opzioni.