iptables para bloquear sites https

9

Desejo bloquear alguns sites que também funcionam com https, como facebook, twitter e gmail, em minha organização. O Lula não deve ser usado aqui de acordo com as ordens da alta gerência. Podemos usar o pacote Untangle Lite e iptables.

Existe outra opção além do Squid para fazer isso? Além disso, algumas iptablesregras para bloquear esse tipo de tráfego seriam realmente úteis.

Eu achei isto

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

mas https ainda funciona em máquinas, exceto na máquina local.

iptables filter

— Dharmit
fonte

2

você deve explicar à sua empresa que evitar o https para uma conta pessoal não é uma boa ideia, pois pode levar a roubos de identidade dentro da empresa, implantar um certificado em todas as máquinas e agir como um homem no meio seria uma maneira muito melhor de verificar quem está conectando ao facebook. Também não tenho certeza, mas acho que não é mais possível conectar o Gmail sem https.

— Kiwy

Posso saber como você conseguiu todos esses endereços pls IP

— Jagadeesh

12

Em vez de corresponder com base no URL, tente corresponder com base no conteúdo do certificado.

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

Você também pode corresponder à impressão digital, mas se o destino alterar ou atualizar seu certificado, invalidará sua regra.

— pr0f3550r
fonte

Isso pode bloquear qualquer coisa que corresponda a www.facebook.com, mesmo no corpo html, mas que seja legítimo assim na caixa de comentários. Ele pode ser bloqueado no nível da URL, mas e o endereço IP?

— precisa saber é o seguinte

@NikhilMulley: Não, ele corresponderá apenas ao certificado SSL fornecido pelo Facebook. Todo o resto é criptografado e não pode ser visto.

— bahamat 23/07/12

2

Somente o primeiro pacote de uma conexão entra na nattabela (e não há cadeia INPUT na tabela nat), acho que você quis dizer filterlá. Além disso, há uma chance (muito) remota de corresponder aos pacotes em que 443 é a porta do cliente

— Stéphane Chazelas 30/10/12

Alguém já usou esta solução? Além da falta de -p tcppara a regra, isso não parece ser algo útil ..

— ivanleoncz

10

O firewall não pode controlar quais URLs HTTPS o cliente está tentando acessar, porque a URL está criptografada. O firewall pode controlar apenas em quais sites o cliente está se conectando, usando endereços IP, mas isso não ajuda se as versões HTTP e HTTPS do site estiverem na mesma URL (e mesmo se não estiverem, você teria para manter uma enorme lista de endereços IP).

A única maneira realista de bloquear o HTTPS é bloqueá-lo completamente. Insista para que todas as conexões sejam HTTP válidas (ou seja, o cliente começa enviando uma HTTPlinha e assim por diante). Isso não pode ser feito apenas com IPtables, você precisa de um proxy com reconhecimento de protocolo, como o Squid. (Não sei do que o Untangle Lite é capaz.)

Você pode bloquear a maioria do tráfego HTTPS bloqueando o tráfego de saída para a porta 443, pois quase todos os servidores HTTPS estão nessa porta. Ou, seguindo uma abordagem da lista de permissões, permita apenas o tráfego de saída na porta 80 (a porta HTTP normal).

Uma abordagem diferente seria fazer proxy de todas as conexões HTTP e HTTPS. Em seguida, você pode corresponder por URLs. Isso requer a realização de um ataque man-in-the-middle aos clientes. Você pode fazer isso se implantar sua própria autoridade de certificação em todas as máquinas clientes e registrá-la como uma raiz de confiança. Isso pode ser considerado antiético.

Não importa o que você faça, determinados usuários configuram um proxy fora do seu ambiente e executam o IP sobre HTTP ou algo assim.

Parece que você está tentando corrigir um problema social com meios técnicos, o que quase nunca funciona, ou está fazendo o possível para implementar um requisito bobo do gerenciamento (nesse caso, eu iria bloquear a porta 443, talvez apenas para determinados IPs, o que permitiria que você informasse que fez seu trabalho, por mais inútil que seja).

— Gilles 'SO- parar de ser mau'
fonte

11

firewall profissional como o Checkpoint permite a filtragem https sem implantar um certificado de cliente na versão mais recente, não sei como eles conseguem fazer isso, mas funciona.

— Kiwy

4

Eu sei de uma opção.

Se você tiver servidores DNS internos para uso, coloque algumas referências estáticas nos dados da zona do seu TLD que resolvam os domínios (que você não deseja estabelecer as conexões externas) para apenas 127.0.0.1. Dessa forma, todos os hosts que usam o DNS central da sua rede resolverão domínios (facebook.com/twitter.com per se) em um endereço de loopback, o que não levará a lugar algum.

Isso funcionará se você tiver controle total de autoridade na configuração do resolvedor de máquinas clientes da sua rede. Se as estações de trabalho / clientes tiverem permissões para alterar / editar / etc / hosts ou /etc/resolv.conf, eles poderão contornar esta opção.

— Nikhil Mulley
fonte

+1 para isso. Isso pode ser feito inserindo essas referências no /etc/hostsarquivo. Por exemplo:127.0.0.1 www.facebook.com

2

Ou, para uma solução mais civilizada, defina os registros DNS A (ou entradas hosts / hosts.txt) para se referir a um host da intranet com um servidor da web que explica exatamente por que o usuário não foi enviado ao Facebook, etc. Observe que isso interrompe HTTPS porque o nome do host pretendido (por exemplo, www.facebook.com) não corresponde ao certificado CN.

— Alexios #

@ Alexios: O OpenDNS é uma ótima solução para isso.

— Kevin M

@ KevinM: obrigado, é útil saber. Eu vou manter isso em mente (embora nós temos nossa própria fazenda pequena DNS no trabalho)

— Alexios

2

Uma opção é blackhole rotas para blocos de rede: (Listados são para 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

— auto
fonte

11

não, não é, é muito complicado manter uma lista de ip para facebook twitter ou até google que não comunica mais seus próprios intervalos de alcance de ip.

— Kiwy 11/03

1

O filtro de conteúdo simples não pode bloquear o site ssl.

Use ferramentas de proteção contra intrusões, como o snort / suricata.

Regra IPS de amostra : Para bloquear URLs SSL para um endereço IP específico.

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;)

Faça o download do Simplewall : nas regras de política do simplewall compartilhadas pelo Squid + Suricata IPS.

— Chetan Muneshwar
fonte

0

Você deve colocar isso na cadeia FORWARD, por exemplo

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

Isso afetará outros sistemas na rede, exceto o firewall.

— Senthamil
fonte