Filtragem de código aberto do tráfego HTTPS

5

Usamos uma configuração de filtragem / proxy que foi configurada para que cerca de 500 usuários fossem roteados por meio de um sistema baseado em Unix executando o SQUID com o SquidGuard para bloquear conteúdo questionável e registrar o que os usuários estavam fazendo. O que descobrimos foi que algumas pessoas conseguiram contornar o bloqueio indo a proxies on-line gratuitos que usam o protocolo HTTPS. Não consegui encontrar uma maneira de bloquear o tráfego HTTPS sem desativá-lo completamente, o que não funcionaria para compras e RH (ou usuários comuns com sites bancários).

Existe uma maneira de bloquear ou filtrar o tráfego HTTPS com o SQUID / Squidguard? Ou alguns outros programas de monitoramento de código aberto? Como os outros lidam com isso sem recorrer a aparelhos comerciais?

EDIT: Não estamos tentando ver o tráfego . Estamos tentando monitorar os URLs e bloqueá-los conforme necessário. Não queremos números de cartão de crédito e tal ... queríamos saber quando Johnny estava acessando o link , adicionar o domínio a um blockfile, e impedi-los de fazê-lo novamente. Veja alguns comentários adicionados abaixo ...

EDIT2: (Re: falando de RH, bancário, etc ...) Você não pode pensar assim, mas nós temos uma pessoa que faz compras, nosso distrito cobre 7 edifícios espalhados pelo município, então temos alguém encarregado de distribuir materiais e estoque, temos as mesmas pessoas trabalhando com registros bancários e de cheques, temos pessoas encarregadas de sindicatos para funcionários e outra para docentes, temos pessoas encarregadas de lidar com informações de RH como sinistros de seguros e danos e responsabilidade ... há muitas coisas envolvidas na administração de escolas nas quais não acho que o público em geral pense. Além disso, temos problemas em que foi considerado arrogante impedir que funcionários / professores fizessem serviços bancários on-line, ou até mesmo alunos acessarem determinados sites para uso on-line (como missões da web) que às vezes exigiam conexões SSL para funcionar. imediatamente no roteador não seria viável.

De qualquer forma, seguindo a sugestão de bloquear apenas algumas pessoas, não encontrei uma maneira de integrar a funcionalidade para autenticação por usuário; Se as credenciais pudessem ser repassadas pelo Windows para que os usuários não precisassem continuar se autenticando com outra senha, seria uma solução viável, mas qualquer coisa que eu encontrei foi desastrosa e não funcionou de forma confiável. Então, é uma questão de fazer com que as pessoas lembrem-se de outra senha (ou alunos / funcionários roubando / compartilhando senhas). Pessoalmente, eu gostava de ter a filtragem feita de forma justa em toda a equipe para funcionários e alunos, em vez de torná-la uma questão de os professores poderem fazer X, enquanto os alunos não são considerados o suficiente para fazer a mesma coisa.

No final, não consegui encontrar uma maneira de fazer com que o servidor autenticasse de forma confiável no Active Directory (para centralizar o gerenciamento de usuários e reduzir as senhas a serem lembradas) ou, se eu usasse um esquema de autenticação diferente, significaria outro banco de dados manter em sincronia com ... o que, última contagem, ~ 1200 usuários ou mais? com um alto churn como todos os anos temos crianças dentro e fora do distrito, graduando-se e novos chegando? ...

    
por Bart Silverstrim 29.07.2009 / 14:46

7 respostas

1

Não vou entrar em ética aqui - talvez você queira fazer isso em todos os sites em que você não "conhece" o domínio ... de qualquer forma, questões éticas à parte:

é possível, definitivamente precisa adicionar bits para o squid2, mas o AFAIK squid3 fará isso da caixa. Assim como alguns fornecedores de filtros web comerciais. O ataque ao estilo MITM é geralmente o único caminho.

    
por 29.07.2009 / 15:55
7

O ponto inteiro do tráfego HTTPS é que ele é criptografado entre o servidor e o usuário final para que ninguém mais possa espioná-lo, incluindo seus filtros. Você não poderá fazer nenhum filtro de conteúdo. O único filtro HTTPS que você poderá fazer é bloquear a porta SSL para endereços IP específicos.

Se você estiver na lista de permissões, você terá muitos falsos positivos - bancos em que você não pensou, sites úteis que exigem HTTPS para fazer login ou acesso, etc. Se você tiver uma lista negra, você terá muitos falsos negativos - novos sites de proxy aparecerão a cada segundo.

Isso é algo que precisa ser tratado em um nível de política, não técnico. Se alguém estiver brincando com sites pornográficos no trabalho e usando proxies para contornar seus filtros, o RH deve estar batendo na mão deles e ameaçando a rescisão se continuar.

    
por 29.07.2009 / 14:51
5

Aqui está uma solução muito feia implementada por um fornecedor comercial:

  • Substitua os certificados de CA dos navegadores por seus próprios internos

  • Quando uma conexão é solicitada para um endereço desconhecido, o proxy se conecta com seu próprio cliente e busca o certificado dos sites

  • Em seguida, gere um certificado falso para esse site, assinado por sua própria autoridade de certificação

  • O proxy age efetivamente como um MITM (man-in-the-middle)

Você não pode fazer isso com o Squid, mas eu levaria cerca de um dia de mod_perl hacking para implementar isso com o Apache.

    
por 29.07.2009 / 15:40
3

Qual solução pode ser para fazer o que os servidores de IRC às vezes, se eles verem uma conexão de XXX.XXX.XXX.XXX eles tentarão se conectar a esse IP e ver se é um servidor proxy aberto e se eles bloquearem esse IP.

É a coisa mais próxima que eu posso pensar que seria uma solução totalmente automática, mas exigiria o trabalho do seu lado. Isso combinado com as outras sugestões relacionadas à listagem branca ou apenas manualmente para ver logs e ver o ip remoto dos https e ver se a hospedagem de um site pode ser a única solução

    
por 29.07.2009 / 15:03
2

Você deve NÃO monitorar o conteúdo do tráfego HTTPS, mesmo que puder, usando técnicas man-in-the-middle. Isso enfraquecerá a segurança da coisa toda e apenas destruirá o ponto de usar HTTPS em primeiro lugar. Você pode, no entanto, monitorar o tráfego HTTPS externamente.

Por exemplo, você pode saber a quais sites eles estão se conectando, porque todo o tráfego HTTPS através de um proxy da Web usa o método CONNECT para iniciar, que é o bit inicial transmitido em branco. Essas informações podem ser usadas para ajudar a decidir se deve ou não permitir que uma conexão continue.

Você também pode monitorar o uso de largura de banda do tráfego HTTPS. Isso pode fornecer informações sobre se eles estão sendo usados para transmitir vídeos ou se estão usando transações on-line, como transações bancárias.

    
por 29.07.2009 / 15:40
1

Você pode precisar de um proxy HTTP ssl como DeleGate como um proxy Man-In-The-Middle

EDIT: Adicionar uma nova maneira provavelmente funcionar

Talvez você possa tentar passar todo o tráfego na porta ssl e iniciar o processo para detectar se o servidor de destino é um proxy ssl ou não (isso pode ser detectado se não for necessária autenticação) e bloqueá-lo.

A maioria dos firewalls baseados em conteúdo usa essa estratégia, primeiro a passou e depois a verifica e bloqueia.

    
por 29.07.2009 / 15:38
0

Eu sei que esta pergunta é antiga, mas acredito que você deve usar um proxy DNS. Portanto, você pode colocar na lista negra todos os domínios que não deseja (seja SSL ou não).

O dnsmasq funciona bem, por exemplo. Você pode configurá-lo como um proxy DNS transparente. Há uma distribuição Linux de código aberto chamada "Endian Firewall". Você pode usá-lo para isso e é EXTREMAMENTE fácil de configurar.

O que você certamente não conseguirá fazer sem o MITM é ter relatórios de sites HTTPS (quanto eles foram visitados, com que frequência, por quem, etc.).

    
por 04.03.2011 / 05:29