Filosofia firewall

È comune ed è cattivo.

Ho risolto questo problema in passato. In una grande organizzazione finanziaria, ci sono voluti circa 4 ore a settimana per due anni.

• Passaggio 1: approvare e comunicare la nuova politica per bloccare le app P2P non approvate. Bloccali.
• Passaggio 2: monitora la porta in uscita 25, identifica il traffico legittimo, parla con i team che lo hanno originato, risolvilo o crea eccezioni. Imporre la nuova regola.
• Passaggio 3: installa un proxy. Ripeti il passaggio 2 per le porte 80 e 443 (eccetto il proxy)
• Passaggio 4: monitorare il segmento utente per l'altro traffico in uscita. Comunicare con i team, documentare le eccezioni.
• Passaggio 5: blocca tutto il resto in uscita nel segmento utente.
• Passaggio 6: monitorare il segmento DMZ per altro traffico in uscita. Comunicare con i team, documentare le eccezioni.
• Passaggio 7: blocca tutto il resto in uscita nel segmento DMZ.

Ogni passaggio migliora in modo incrementale la sicurezza e rende l'azienda più a suo agio con le modifiche. È necessario rispondere ai problemi mentre emergono. Quale brucia più tempo.

Cambiare tutto in una volta potrebbe funzionare ... ma sarà un inferno e alla fine, non avrai i processi e la documentazione da mostrare per questo, solo un formaggio svizzero di tarda notte da squadre che urlano che la XYZ è rotto o il rapporto Dobson non sta generando più.

Se parli di un'organizzazione molto piccola, fai tutto in una volta e lascia che la gente urli. Puoi rispondere rapidamente senza separazione dei compiti, quindi è più conveniente.

In una grande organizzazione, tutto è un record o un incidente. Spezzare le cose sarà molto più costoso del tuo tempo a trascinarti tutto.

La tua divergenza di opinioni è esattamente la differenza tra due distinte filosofie riguardanti il controllo dell'accesso alla rete. Queste filosofie dimostrano anche il classico compromesso tra sicurezza e usabilità.

Blacklisting , simile alla posizione dell'amministratore del tuo firewall, è una pratica che consente a tutti un elenco definito di schemi di traffico attraverso. Questo è il più facile da fare in termini di usabilità e amministrazione, ma è piuttosto insicuro e borderline ingenuo. Affermare che la lista nera è sicura, significa presumere che tu conosca tutte le possibili minacce alla tua rete e le abbia aggiunte tutte alla tua lista di negazione. Sapere tutte le possibili minacce è ovviamente impossibile e, anche allora, includere selettivamente tutte quelle minacce su una lista di negazione causerebbe l'elenco enorme e ingestibile.

Whitelisting , la filosofia con cui eri "cresciuto con" (per così dire), è l'esatto opposto. Presume che tutto il traffico dovrebbe essere negato, ad eccezione di ciò che è specificato nell'elenco delle autorizzazioni. Questa è l'opzione più sicura, ma può anche avere un grande impatto sul sovraccarico di usabilità e gestione. Si basa sulla regola di sicurezza "Principio del minimo ..." - permetti solo ai tuoi utenti / computer / programmi / ecc. fare ciò che ha veramente bisogno di fare. Il lato positivo di questo è che conosci esattamente che cosa è permesso alla tua rete di fare. Anche se questo da solo non ti renderà immune a tutte le minacce, ti aiuterà a proteggerti da una buona parte delle incognite. Ci saranno ancora modi per aggirare questo problema (ad esempio con il tunneling attraverso le porte permesse / i protocolli) ma sarà molto più difficile che contro un approccio orientato alla lista nera. Ovviamente, il lato negativo di questo approccio è che spesso può essere più difficile risolvere i problemi con le applicazioni di rete mantenendo comunque la regola "Principio del minimo ...".

Ogni approccio ha i suoi meriti e le sue debolezze. Alla fine, spetta a te (o ai dirigenti della tua azienda) decidere quale approccio è più ragionevole per la tua organizzazione. Un buon approccio alla difesa che include misure di protezione diverse dal solo firewall perimetrale è anche essenziale per mitigare i rischi lasciati aperti da qualsiasi configurazione di firewall o hardware che scegli.

Avere un rifiuto implicito nella parte inferiore dell'ACL del firewall è standard. È pigro nel permettere tutto il traffico in uscita. Questo è il sogno di una botnet.

Fondamentalmente se si infetta una macchina, quella macchina può ora avviare una conversazione su qualsiasi porta sul server di comando e controllo.

• Oppure, se si dispone di un proxy, le persone devono passare attraverso il filtro possono semplicemente disattivare il proxy e ignorare il filtraggio.
• Oppure ora possono bypassare direttamente il firewall e lo spam delle e-mail.
• Oppure possono bypassare la prevenzione della perdita di dati che hai impostato sul tuo firewall email.

A questo punto, le tue zone di sicurezza non hanno importanza perché ha un permesso implicito. Quindi se un utente malintenzionato ottiene una casella sulla rete che la casella può arrivare ovunque all'interno . Oh le possibilità. Puro genio.

Dal punto di vista dello stato, tutte le nuove connessioni in uscita sono comuni come impostazione predefinita. L'idea è che gli utenti stiano facendo nuove connessioni con i server al di fuori della rete. Se utilizzi un approccio di whitelisting e consenti solo le porte 80 e 443, allora blocchi le botnet dal loro punto d'appoggio nella rete dal chiamare home su porte non standard (6667), a meno che non usino la porta 80, che è quasi sempre aperto.

Potrebbe esserci una discussione valida sui rischi quantificati di consentire tutte le nuove connessioni in uscita, ma l'approccio 'più sicuro' è quello di autorizzare le connessioni in uscita, anche se non si sta proteggendo la rete molto più che consentirne tutte.

Nel mio caso, sono molto interessato a sapere quale traffico è in uscita su porte insolite e a sapere cosa viene comunicato, ma ho risorse per rendere l'analisi preziosa per me.

In primo luogo, i firewall utilizzano un modello di sicurezza positivo, il che significa che la whitelist è nota e che tutto il resto è bloccato. L'alternativa è un modello di sicurezza negativo, noto anche come blacklisting. I modelli di sicurezza positivi sono le migliori pratiche, periodo.

L'amministratore del firewall ha una cronologia come amministratore di rete? La mia storia è che molti amministratori di rete hanno fatto sì che gli amministratori di firewall la pensassero in questo modo, dal momento che gli amministratori di rete si occupano solo di consentire le comunicazioni e non sono molto attenti alla sicurezza. Un sacco di buchi di sicurezza sono dovuti al fatto che gli amministratori di rete hanno configurato l'architettura di base di molte aziende (prima che i problemi di sicurezza fossero predominanti) e questo è qualcosa che è molto difficile da invertire.

Hai una legittima preoccupazione e NON è la migliore pratica per i firewall aziendali per consentire tutto il traffico in uscita. Questo è il motivo numero 1 per cui l'estrazione dei dati ha avuto successo.

A mio parere, come professionista della sicurezza vorrei anche fare la decodifica SSL e il filtraggio del livello delle applicazioni in modo da non aprire solo la porta 443 o 80, ma anche solo applicazioni specifiche attraverso tali porte. Tuttavia, a volte questo è un duro affare per le organizzazioni non incentrate sulla sicurezza. Si verificano falsi positivi (negazione del traffico legittimo), in particolare con applicazioni personalizzate.

My 2c dello hacker standard della tua azienda. Tieni presente che non lo faccio, e non l'ho mai fatto, è solo una teoria . Il blocco delle porte è inutile perché:

• Devi consentire HTTPS. Consentire l'HTTPS mi consente di ignorare tutte le restrizioni e comunicare con il mio VPS personale sulla porta 443. Dopodiché, posso fare tutto ciò che SSH abilita, incluso ma non limitato a: scaricare file proibiti dal proxy, navigare sul web usando il mio VPS come un proxy e creazione di un tunnel SSH inverso dal server remoto che mi consenta di accedere a qualsiasi porta del mio computer tramite Internet.

Quindi, potrebbe essere che la pratica standard sia quella di "disabilitare tutte le porte e sentirsi al sicuro", ma è necessario abilitare le comunicazioni codificate, che rendono efficace tutte le regole del firewall.

Inoltre, ci sono scuse perfettamente benigne per l'utilizzo di SSH sulla porta 443 .

Ancora una volta, solo il mio 2c, non vale la pena per il culo dei tuoi utenti.