Filtro di Egress su una rete di uffici?

PRO: controllo rigoroso su tutto ciò che esce dalla rete (e per estensione, gran parte di ciò che si muove in esso).
CON: I tuoi utenti sentono il controllo. Considerando che sei un business di sviluppo, i tuoi utenti sono piuttosto tecnici e probabilmente lo risentiranno.
CON: Considerando che sei un'azienda di sviluppo, e che i tuoi utenti sono piuttosto tecnici, è probabile che installino legittimamente nuovi programmi, nel corso del loro lavoro (per quanto tempo è stato consentito fino a skype?), E sarà difficile tenere traccia e aggiornare i filtri.
PRO: i tuoi utenti sono limitati in ciò che possono installare :)
CON: Non considerarlo nemmeno per ogni macchina, anche se non del tutto inutile, è molto più facile da bypassare.
PRO: come hai detto, può bloccare alcuni usi di botnet e altri malware inconsapevoli.
PRO: può ipoteticamente assistere (come primo passo) nella prevenzione della fuga di dati.

UBER-CON: È banale aggirare la maggior parte degli scenari dannosi semplicemente scavalcando qualsiasi porta / protocollo che hai aperto (questo include molti tipi di worm adattivi), mentre nel non- casi malevoli è un vero affare da affrontare.

Bottom Line: Il filtro Egress è un ottimo strumento per darti controllo , ma non è molto utile per sicurezza .

Uno dei principali vantaggi del filtraggio in uscita è che ti costringe a comprendere il traffico in uscita legittimo richiesto dal personale e dai sistemi. Tuttavia il lato negativo è che la gestione richiederà tempo e denaro. Se valga la pena dipenderà dal fatto che tu pensi che le minacce che stai mitigando valgano il costo.

In termini di come si effettua il filtraggio in uscita, ciò che ho visto è principalmente società più grandi in cui non esiste un accesso diretto a Internet per gli utenti finali e tutto il traffico in uscita deve passare attraverso i server proxy.

Questo ha il vantaggio di imporre un choke-point nella rete in cui tutto il traffico Internet dell'utente scorrerà e dove può essere ispezionato, quindi in teoria è possibile distribuire IDS / IPS / DLP a questo punto per ottenere una vista di quale contenuto sta entrando e lasciando la tua rete.

Ovviamente per essere davvero efficaci, devi terminare e ristabilire tutte le sessioni SSL lì, in modo da poter eseguire l'ispezione del contenuto.

Come ho detto, la domanda principale è se tale livello di costo e di lavoro extra valga la pena per una determinata organizzazione.

Specialmente la comunicazione tra i server ha schemi di comunicazione predefiniti. Consentendo solo questo traffico, sei sicuro che nessuno accidentalmente comprometterà il server aggiungendo un nuovo software, aumentando così la sicurezza.

I contro sono il lavoro necessario per mantenere questi filtri. Non solo è necessario aprire una volta installato il nuovo software, ma è anche necessario assicurarsi di chiudere una volta che il sofwater non è più necessario o una volta modificato.

L'uso dei filtri di uscita ti obbliga a conoscere e conoscere i canali di comunicazione utilizzati dal tuo server e dal tuo software.

Pro:

• Maggiore sicurezza
• Maggiore visibilità del traffico di rete
• Controllo aumentato

Contro:

• Maggiore overhead ++
• Maggiore complessità

Credo che la risposta sia sì, ma dipende tutto dal tuo ambiente. Per lo meno le organizzazioni dovrebbero prendere in considerazione una rete segmentata che controlla il traffico in entrata e in uscita verso i loro server. Non sono d'accordo sul fatto che il filtraggio in uscita sia banale da bypassare. Se è implementato correttamente, il filtraggio in uscita può essere un strong strato difensivo. Implementato correttamente significa che tutto passa attraverso un proxy. Le eccezioni dovrebbero essere consentite solo a endpoint noti e affidabili.

Penso che i pro e i contro siano stati ben discussi e tutti puntano al vero problema qui è in effetti quello di proteggere contro la perdita di dati.

Sono d'accordo che i firewall dovrebbero essere usati sia per proteggerti dagli altri che allo stesso tempo da altri da te (ad esempio da un'epidemia di worm) con filtri outbound sensibili. Se ti piace è fondamentalmente una politica di buon vicinato.

Tuttavia, come discusso, sono uno strumento smussato che può essere aggirato banalmente se qualcuno sta cercando di filtrare le informazioni dall'organizzazione.

Quindi l'obiettivo dovrebbe essere quello di proteggere dalla perdita di dati e utilizzare il firewall come componente di questo approccio. Le organizzazioni dovrebbero monitorare il traffico in uscita come parte di un approccio organizzativo DLP (protezione della perdita dei dati) complessivo, che richiede il monitoraggio del traffico di rete stesso e la ricerca di trend / eccezioni / volume.

Il problema che la maggior parte delle persone incontra sta impostando modi per prevenire il flusso di traffico in uscita DNS e HTTP / TLS. Sono abbastanza sicuro che è meglio installare solo Whitetrash che persino usare un firewall (compresi quelli fantasiosi come Palo Alto Networks) o un gateway web sicuro .

Se utilizzi un gateway Web di whitelist come Whitetrash e hai impedito tutto il traffico in uscita, devi comunque preoccuparti dei canali segreti DNS. Il modo più semplice è semplicemente avere un server DNS interno senza connettività in uscita - e quindi avere il proxy Squid che esegue Whitetrash o ospitare DNS Internet o collegarsi a una rete separata che ospita server DNS Internet. I browser riceveranno il loro DNS attraverso il proxy. Sì, funziona davvero, ma gli utenti non saranno in grado di utilizzare alcun traffico di protocollo su Internet che non sia HTTP o SSL (e anche che deve passare attraverso il proxy). Suppongo che anche FTP e Gopher funzionerebbero se Squid fosse configurato per consentire loro.

Questa sarebbe una rete frustrante alla quale connettersi e sarebbe possibile solo negli ambienti più rigidi con politiche infosec opprimenti.

Non sono un fan dell'ispezione del traffico SSL, ma se lo fai - assicurati di non ispezionare le banche / etc con l'uso di una whitelist. Se stai usando Whitetrash, probabilmente hai già un ampio elenco da gestire comunque.

Sono sorpreso dalle persone che dicono che "potrebbe" essere una buona idea o "forse" questa è una buona cosa da fare. È assolutamente la cosa giusta da fare Non si fermerà qualcosa come una connessione tcp inversa come quella che metasploit e altri possono impostare sulla porta 80 o 443 in un ambiente non proxy, ma in alcune situazioni impedirà alle stazioni di lavoro casuali di inviare spam o altri malware in rete. Aggiunge complessità ma questo è il motivo per cui siamo pagati i soldi, giusto? :)