iptables per bloccare i siti Web https

9

Desidero bloccare alcuni siti Web che funzionano anche su https, come Facebook, Twitter e Gmail, nella mia organizzazione. Squid non dovrebbe essere usato qui secondo gli ordini della direzione superiore. Possiamo usare Untangle Lite Package e iptables.

Esiste un'opzione diversa da Squid per farlo? Anche alcune iptablesregole per bloccare questo tipo di traffico sarebbero davvero utili.

ho trovato questo

iptables -t filter -I INPUT -m string --string facebook.com -j LOG --algo bm
iptables -t filter -I INPUT -m string --string facebook.com -j REJECT --algo bm

ma https funziona ancora su macchine ad eccezione della macchina locale.

iptables filter

— Dharmit
fonte

2

dovresti spiegare alla tua azienda che evitare https per conto personale non è una buona idea in quanto potrebbe portare a furti di identità all'interno dell'azienda, distribuire un certificato su tutte le macchine e agire come un uomo in mezzo sarebbe un modo molto migliore per verificare chi è connettersi a facebook. inoltre non ne sono sicuro, ma penso che non sia più possibile connettere gmail senza https.

— Kiwy,

— Potrei

12

Invece di abbinare in base all'URL, prova ad abbinare in base al contenuto del certificato.

iptables -t nat -I INPUT --sport 443 -m string \
                 --string www.facebook.com --algo bm -j REJECT

Puoi anche abbinare l'impronta digitale ma se la destinazione cambia o aggiorna il loro certificato, invaliderà la tua regola.

— pr0f3550r
fonte

può bloccare tutto ciò che corrisponde a www.facebook.com anche nel corpo html, ma è legittimo come questo nella casella dei commenti. Può essere bloccato a livello di url, ma per quanto riguarda l'indirizzo IP?

— Nikhil Mulley,

@NikhilMulley: No, corrisponderà solo al certificato SSL fornito da Facebook. Tutto il resto è crittografato e non può essere visto.

— Bahamat,

2

Solo il primo pacchetto di una connessione entra nella nattabella (e non c'è nessuna catena INPUT nella tabella nat), penso che tu intendessi filterlì. Inoltre, c'è una possibilità (molto) remota che corrisponda ai pacchetti in cui 443 è la porta client

— Stéphane Chazelas,

Qualcuno ha usato questa soluzione? A parte la mancanza di -p tcpper la regola, questo non sembra essere qualcosa di utile ..

— Ivanleoncz,

10

Il firewall non può controllare a quali URL HTTPS il client sta tentando di accedere, poiché l'URL è crittografato. Il firewall può controllare solo a quali siti si sta connettendo il client, utilizzando gli indirizzi IP, ma ciò non aiuta se le versioni HTTP e HTTPS del sito si trovano nello stesso URL (e anche se non lo sono, avresti per mantenere un vasto elenco di indirizzi IP).

L'unico modo realistico per bloccare HTTPS è bloccarlo del tutto. Insistere sul fatto che tutte le connessioni devono essere HTTP valide (ovvero il client si avvia inviando una HTTPlinea e così via). Questo non può essere fatto solo con IPtables, è necessario un vero proxy compatibile con il protocollo come Squid. (Non so di cosa sia capace Untangle Lite.)

È possibile bloccare la maggior parte del traffico HTTPS bloccando il traffico in uscita verso la porta 443, poiché quasi tutti i server HTTPS si trovano su quella porta. Oppure, seguendo un approccio whitelist, consenti solo il traffico in uscita verso la porta 80 (la normale porta HTTP).

Un approccio diverso potrebbe essere il proxy di tutte le connessioni HTTP e HTTPS. Quindi puoi abbinare per URL. Ciò richiede di condurre un attacco man-in-the-middle ai client. È possibile farlo se si distribuisce la propria autorità di certificazione su tutte le macchine client e la si registra come radice di attendibilità. Questo può essere considerato non etico.

Indipendentemente da ciò che fai, determinati utenti configureranno un proxy al di fuori del tuo ambiente ed eseguiranno IP su HTTP o qualcosa del genere.

Sembra che tu stia provando a risolvere un problema sociale con mezzi tecnici, che quasi mai funziona, o stai facendo del tuo meglio per implementare un requisito sciocco da parte della direzione (nel qual caso, andrei con il blocco della porta 443, forse solo per determinati IP, che ti consentirebbero di segnalare che hai svolto il tuo lavoro, non importa quanto sia inutile).

— Gilles 'SO- smetti di essere malvagio'
fonte

1

firewall professionale come Checkpoint consente il filtro https senza distribuire un certificato client nell'ultima versione, non so come riescano a farlo, ma funziona.

— Kiwy,

4

Conosco un'opzione.

Se si dispone di server DNS interni da utilizzare, inserire alcuni riferimenti statici nei dati della zona TLD che risolvono i domini (che non si desidera stabilire connessioni esterne) a solo 127.0.0.1. In questo modo, tutti gli host che utilizzano il DNS centrale all'interno della tua rete risolveranno i domini (facebook.com/twitter.com in sé) in un indirizzo di loopback, che non porterà da nessuna parte.

Ciò funzionerà se si dispone del controllo autorevole totale sulla configurazione del resolver delle macchine client della rete. Se le workstation / i client dispongono delle autorizzazioni per cambiare / modificare / etc / hosts o /etc/resolv.conf, possono eludere questa opzione.

— Nikhil Mulley
fonte

+1 per quello. Questo può essere fatto inserendo questi riferimenti nel /etc/hostsfile. Ad esempio:127.0.0.1 www.facebook.com

2

Oppure, per una soluzione più civile, impostare i record DNS A (o voci hosts / hosts.txt) in modo da fare riferimento a un host intranet con un server web che spieghi esattamente perché l'utente non è stato inviato a Facebook, ecc. Si noti che questa interruzione HTTPS perché il nome host previsto (ad es. Www.facebook.com) non corrisponderà al certificato CN.

— Alexios,

@Alexios: OpenDNS è un'ottima soluzione per questo.

— Kevin M,

@KevinM: grazie, è utile saperlo. Lo terrò a mente (anche se abbiamo la nostra piccola fattoria DNS al lavoro)

— Alexios,

2

Un'opzione è di instradare blackhole verso i blocchi di rete: (elencati per FB)

ip route add blackhole 69.171.224.0/19
ip route add blackhole 74.119.76.0/22 
ip route add blackhole 204.15.20.0/22
ip route add blackhole 66.220.144.0/20
ip route add blackhole 69.63.176.0/20
ip route add blackhole 173.252.64.0/18

— se stesso
fonte

1

no non lo è, è complicato mantenere un elenco di ip per facebook twitter o persino google che non comunicano più le proprie gamme di intervalli ip.

— Kiwy,

1

Il filtro del contenuto semplice non può bloccare il sito SSL.

Utilizzare strumenti di protezione dalle intrusioni come snort / suricata.

Regola IPS di esempio : per bloccare URL ssl per un indirizzo IP specifico.

drop ip any 443 -> 192.168.3.30 any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".fbcdn.net"; msg:"Simplewall Ssl block for User30 : Urls => .fbcdn.net " ;sid:11469443;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".youtube.com"; msg:"Simplewall Ssl block for User30 : Urls => .youtube.com " ;sid:13989722;rev:1;)

Scarica Simplewall : nelle regole dei criteri simplewall condivise da Squid + Suricata IPS.

— Chetan Muneshwar
fonte

0

Dovresti metterlo sulla catena FORWARD, ad es

iptables -I FORWARD  -m string --string "facebook.com" \
                     --algo bm --from 1 --to 600 -j REJECT

Interesserà altri sistemi sulla rete, ad eccezione del firewall.

— Senthamil
fonte