Il blocco del traffico in uscita è generalmente utile per limitare ciò che un utente malintenzionato può fare una volta che ha compromesso un sistema sulla tua rete.

Quindi, ad esempio, se è riuscito a inserire malware in un sistema ( tramite una e-mail o una pagina del browser infetta), il malware potrebbe tentare di "chiamare a casa" un sistema di comando e controllo su Internet per scaricare codice aggiuntivo o per accettare attività da un sistema di controllo (ad es. invio di spam)

Il blocco del traffico in uscita può aiutare a impedire che ciò accada, quindi non è tanto per impedirti di essere infettato quanto rendere meno grave quando si verifica.

Potrebbe essere eccessivo per una rete domestica anche se c'è molti programmi che effettuano connessioni in uscita e dovresti dedicare un po 'di tempo a configurare tutte le eccezioni.

Proveniente da un ruolo di sicurezza, in particolare se sei mai stato coinvolto nella risposta agli incidenti, l'idea del filtraggio in uscita sembrerebbe un corso naturale in un ambiente ad alta sicurezza. Tuttavia, è un'impresa molto grande e complessa. Indica le parole "filtro in uscita" a un firewall, rete o amministratore di sistema e probabilmente otterrai questa risposta.

Quindi, pur sapendo che gli ambienti ad alta sicurezza potrebbe aver bisogno di questo e garantirebbe il lavoro extra, a volte può essere difficile ottenere il buy-in. In particolare quando a un'unità il cui compito principale è mantenere il tempo di attività viene improvvisamente chiesto di assumersi una quantità potenzialmente significativa di manutenzione extra per realizzare qualcosa che ha un'alta probabilità di ridurre il tempo di attività.

In questo caso saremmo remis per non parlare dell'angolo di conformità. Diamo un'occhiata al PCI-DSS v2.0 per un momento. La sezione 1 dei requisiti discute i sistemi e la sicurezza della rete. Questo è rilevante qui:

1.3.5

Non consentire il traffico in uscita non autorizzato dall'ambiente dei dati dei titolari di carta a Internet.

Per quanto a tutti noi piace parlare di come "la conformità è un punto di partenza" nel mondo reale, a volte l'unica trazione che possiamo ottenere è l'obiettivo di compilare quella casella di controllo o superare l'audit. Potrebbe essere utile dare un'occhiata ai documenti di conformità rilevanti per il tuo campo o servizio. Sebbene PCI-DSS sia esclusivamente un requisito del settore, concordato dal diritto contrattuale, è un insieme di requisiti abbastanza specifico che ho visto adottato come standard da controllare in altri luoghi che hanno requisiti meno ben definiti.

A meno che non blocchi tutto il traffico in uscita diverso da una whitelist di siti Web legittimi che visiti (e / o utilizzi un proxy che esegue whitelist e scansione di sicurezza), il blocco di tutte le porte eccetto 80/443 offre poca sicurezza aggiuntiva. Bene, bloccare la porta 25 potrebbe essere utile per impedire che la tua rete venga utilizzata per inviare spam.

Molte botnet comunicano già su HTTP per connettersi alla loro rete di comando / controllo poiché sanno che altre porte potrebbero essere bloccate ( alcuni usano addirittura DNS come protocollo di comando / controllo). Quindi, se permetti alla tua rete di connettersi a qualsiasi server HTTP, non ti stai dando molta protezione aggiuntiva dall'adesione a una botnet e incontrerai continuamente problemi quando provi a eseguire cose che usano altre porte come VPN, videoconferenze, giochi online, siti Web su porte non standard, FTP e così via. E avresti davvero bisogno di controllare regolarmente i registri per cercare segni di infezione.

Probabilmente non ne vale la pena una rete domestica. Probabilmente è meglio spendere il tuo tempo cercando di prevenire l'infezione da malware in primo luogo piuttosto che mitigare i danni una volta che sei stato infettato.

Il blocco del traffico in entrata può solo impedire al traffico non richiesto di raggiungere la tua rete interna. Tuttavia, se ricevi malware su una macchina interna (tramite l'esecuzione di un eseguibile non attendibile o tramite un exploit) puoi comunque essere colpito.

Il blocco del traffico in uscita aiuta a limitare i danni, impedendo al malware di connettersi a un comando & control server o exfiltrating data. Anche se la tua macchina sarà ancora compromessa, potresti evitare che i tuoi dati personali vengano rubati da un keylogger.

Due ragioni:

1. Nel caso in cui il malware si insinui nella tua rete, il blocco del traffico in uscita a volte può contenere il danno impedendo al malware di contattare un server remoto. Se utilizzi un firewall a livello di computer, puoi anche impedire al malware di diffondersi ulteriormente attraverso la rete. Non consentire il traffico in uscita significa anche che la tua macchina diventa meno interessante come parte di una botnet.
2. Il software legittimo con funzionalità di rete potrebbe essere vulnerabile e potrebbe essere indotto a configurare connessioni in uscita che possono essere utilizzate per compromettere ulteriormente il tuo sistema. Si consideri, ad esempio, un server web che esegue un'applicazione con un difetto che consente a un utente malintenzionato di indurlo a scaricare file su Internet invece di aprire file locali (un tale difetto è facile da produrre e trascurare, ad esempio, PHP) . Se è stato disattivato correttamente il firewall, la richiesta semplicemente non andrà a buon fine e forse farà scattare un allarme da qualche parte.

Oltre al controllo dei danni dopo una compromissione, potresti anche voler:

• Controllare come (e se) gli utenti e i processi all'interno della rete utilizzano Internet

• Monitora i tuoi processi interni per rilevare malware ("scansione passiva delle vulnerabilità")

Il blocco delle query DNS in uscita in modo che il DNS possa essere instradato solo attraverso il tuo server DNS preferito (server DNS aziendale, OpenDNS, Quad9, Google Public DNS, ecc.) È abbastanza comune su una rete che è stata in qualche modo protetta.

US-CERT ha un articolo informativo su questo ed elenca gli impatti di non farlo:

A meno che non sia gestito da soluzioni tecniche perimetrali, i sistemi e le applicazioni client possono connettersi a sistemi al di fuori del controllo amministrativo dell'azienda per la risoluzione DNS. Ai sistemi aziendali interni dovrebbe essere consentito solo di avviare richieste e ricevere risposte da server dei nomi di cache DNS aziendali approvati. Consentire ai sistemi e alle applicazioni client di connettersi direttamente all'infrastruttura DNS di Internet introduce rischi e inefficienze per l'organizzazione, che includono:

• Monitoraggio aziendale e registrazione del traffico DNS ignorati; questo tipo di monitoraggio è uno strumento importante per rilevare potenziali attività di rete dannose.
• Funzionalità di filtraggio di sicurezza DNS aziendale ignorate (sinkhole / reindirizzamento o blackhole / blocco); ciò potrebbe consentire ai client di accedere a domini dannosi che altrimenti sarebbero bloccati.
• Interazione del client con server DNS compromessi o dannosi; ciò potrebbe causare risposte DNS imprecise per il dominio richiesto (ad esempio,
  il client viene inviato a un sito di phishing o viene fornito codice dannoso).
• Protezione persa contro avvelenamento della cache DNS e attacchi denial-of-service. Gli effetti attenuanti di un'architettura DNS a più livelli o gerarchica (ad es. Server DNS interni ed esterni separati, DNS diviso e così via) utilizzata per prevenire tali attacchi vengono persi.
• Velocità di navigazione in Internet ridotta poiché la memorizzazione nella cache DNS aziendale lo farebbe non essere utilizzato.

https://www.us-cert.gov/ncas/alerts/TA15-240A

"c'è poca sicurezza aggiuntiva da guadagnare bloccando tutte le porte eccetto 80/443."

a meno che tu non stia utilizzando un proxy per mascherare il tuo IP, che il codice da un sito web (o iniettato in un sito web) potrebbe bypassare telefonando a casa su una porta diversa, bypassando così il tuo proxy (che normalmente sarà configurato solo per reindirizzare il traffico in uscita sulle porte solitamente utilizzate dal tuo browser).

È così semplice che chiunque utilizzi Tor dovrebbe esserne consapevole, poiché fa un buco proprio attraverso la maschera fornita da Tor.

Soluzione: instrada TUTTE le porte attraverso il proxy (Tor non consiglia a causa della perdita di prestazioni) o blocca tutte le porte in uscita ad eccezione di quelle specificatamente instradate attraverso il proxy.

Un approccio migliore per una rete domestica è un "firewall personale" software che viene eseguito su ogni PC e chiede all'utente se desidera consentire a un programma che sta tentando di effettuare una connessione in uscita di farlo.

Questo, sebbene inizialmente fastidioso quando ti chiede tutto mentre cerca di capire cosa dovrebbe essere consentito, è più facile da mantenere in un ambiente domestico rispetto a un firewall di rete che esegue il blocco in uscita che non ha il concetto la differenza tra Google Chrome che effettua una richiesta di pagina web e LulzBot2000 (sì, l'ho inventato io) che fa una richiesta web per payload di malware.

Il mondo potrebbe essere un posto migliore se più router domestici bloccassero per impostazione predefinita le porte in uscita come STMP, IRC, ecc. E quelle sono appena fuori dalla mia testa.

Sono appena atterrato qui dopo aver girato praticamente tutto tranne ssh, http e https. È una misura preventiva, un altro livello di sicurezza, ma in questo caso impedisce ai malintenzionati di utilizzare la tua rete come punto di lancio per un attacco.

Detto questo, al momento sono nel mezzo di eseguirne il debug e mentre i client Linux (la mia macchina Debian principale, più un netbook Debian, il server interno nome / file / stampa / ora che esegue Debian, il termostato HestiaPi) funzionano tutti bene. Il telefono Android si lamenta che non c'è Internet (perché ho anche impostato il caching / il filtro DNS, quindi ho indirizzato tutti i client su di esso, ala PiHole), ma posso accedere alle cose che uso (praticamente web e SSH).

Il Roku è un'altra storia; YouTube, Vimeo e persino Netflix funzionano bene, dopo (di nuovo) piagnucolare da Roku che non c'è Internet perché non gli permetterò di contattare i suoi preziosi server pubblicitari (per la prima volta in assoluto, gli annunci sono spariti sulla schermata principale; Io ' Cercherò di mantenerlo almeno). Ma Amazon e Hoopla non funzionano entrambi e, dato che domani devo attivare una VPN sul computer di lavoro, quasi sicuramente tornerò indietro.

TL; DR - il filtraggio in uscita è un buon idea. Almeno chiudi le connessioni in uscita a tutte le cose cattive che non usi mai (telnet, comandi R, ecc.) E valuta saggiamente di chiuderne altri.

Come altri hanno già detto, il blocco delle porte in uscita ridurrà al minimo ciò che un utente malintenzionato può dopo che la tua macchina è già stata infettata. Diamo un'occhiata alla situazione di seguito:

1. Un utente malintenzionato riesce a compromettere la tua macchina con un RAT (strumento di amministrazione remota)
2. Di solito il modo in cui funziona un RAT è collegandosi tornare alla macchina dell'attaccante per comunicare con essa, normalmente il RAT sarebbe in grado di comunicare liberamente con la macchina dell'attaccante.
3. Supponiamo che tutto il traffico in uscita sia bloccato, il RAT non può più comunicare con la macchina dell'attaccante . Ciò rende praticamente inutile qualsiasi informazione rubata dal tuo PC.

Solo perché hai impedito al RAT di comunicare con il server dell'attaccante non significa che sei al sicuro.

Il RAT può ancora modificare il file system, rallentare la macchina a seconda di ciò che sta facendo, vale la pena ricordare che se il RAT avesse i privilegi potrebbe cambiare le regole del firewall e abilitare il traffico in uscita, consentendogli di comunicare con il server dell'attaccante.