Uso seletivo do proxy transparente por conexão

Question

TL; DR - Estou planejando usar um firewall em nível de aplicativo para encaminhar somente solicitações de conteúdo HTML para um proxy transparente. Assim, o pedido GET inicial para google.com (por exemplo) que retorna um arquivo HTML será encaminhado para o Squid (o proxy transparente), mas todas as solicitações subsequentes para ativos estáticos (CSS, JS, arquivos de imagem, etc) não serão através do proxy.

Você consegue pensar em alguma maneira de causar impacto na sessão do usuário?

Alguns antecedentes :

Temos um roteador no local, mas queremos filtrar conteúdo usando um proxy transparente + servidor ICAP hospedado na AWS. Inicialmente, planejamos encaminhar todo o tráfego da porta 80 para o proxy transparente, mas estávamos preocupados com os 50-100ms extras que receberíamos para cada solicitação, uma vez que ela era roteada por meio da instância do EC2 e, mais importante, aumentaria os custos inaceitáveis de largura de banda. Recentemente, descobrimos que o firewall do roteador pode filtrar usando inspeção profunda de pacotes (assim, poderia corresponder às solicitações de saída com um cabeçalho "Aceitar texto / html. *", Por exemplo).

À primeira vista, parece uma solução muito mais gerenciável, mas minha experiência de rede é limitada e queria mostrar quaisquer "pegadinhas" e / ou exemplos de como essa é obviamente uma ideia horrível antes de ir longe demais nesse caminho.

    

Answer 1

O proxy HTTP transparente normalmente tem pouco ou nenhum impacto nas sessões do usuário na minha experiência.

Sua estratégia e o que você realmente pretende realizar parece incerto para mim, no entanto. Eu acho que a realidade de como o HTTP funciona vai apresentar um problema para você. Talvez você possa falar mais sobre o que você realmente está tentando realizar a partir de uma perspectiva de resultado final. Não estou dizendo que é uma "ideia horrível", mas não está claro o que você espera ganhar.

De uma perspectiva de protocolo HTTP, sua estratégia tem um grande problema. Seu firewall da camada 7 não pode saber, por definição, o tipo MIME de um recurso que está sendo solicitado até que a solicitação seja feita. Você pode fazer uma correspondência no nome do arquivo (ver se termina em ".html", etc), mas qualquer URL pode retornar um tipo MIME arbitrário. Este arquivo .b0rk é text/html , mas uma regra de correspondência em seu firewall em .html ou .htm não "saberia" isso. A solicitação deve ser feita no servidor remoto e o servidor remoto deve responder antes que o tipo MIME seja conhecido.

Por que você acha que outros tipos de arquivos (CSS, Javascript, imagens, etc) são "estáticos"? Eles certamente não precisam ser. O objeto ao qual qualquer URL se refere pode ser "dinâmico".

Se você está preocupado com os custos de largura de banda, por que não apenas hospedar um proxy transparente localmente? Um proxy local não teria uma décima segunda latência para que as solicitações atingissem o proxy, e você não teria os possíveis custos de largura de banda associados ao envio de todos os seus dados de um datacenter de terceiros. Você também veria alguma melhora na sua utilização de largura de banda local quando o proxy armazena objetos em cache e você poderia deixá-los armazenar em cache tudo (que o cna).

Eu gerenciei uma rede educacional de mil lugares através de uma instância de cache do Squid em execução no hardware que, hoje, pareceria lamentável. A menos que você esteja falando sobre uma rede muito grande, uma máquina muito modesta poderia lidar com a carga para você. Se você está preocupado com um único ponto de falha, pode usar o Protocolo de Comunicação de Cache da Web (WCCP), se o seu dispositivo de borda suporta, para fazer failover entre um par de caches.

Se você está procurando fazer isso para escanear HTML em busca de código "malicioso", acho que você está olhando para trás. Eu ficaria mais preocupado com códigos maliciosos em JavaScript e application/octet-stream de objetos do que sobre text/html objects. Tenho dúvidas de que a digitalização, de qualquer forma, pode ser suficientemente ofuscada para escanear (veja o problema de Interrupção ). A menos que você esteja indo para a interceptação SSL, você também vai perder qualquer coisa entregue via HTTPS, também. A varredura pode capturar exploits conhecidos e eu a vejo como uma parte válida de uma arquitetura de segurança de TI, mas o dia 0 quase sempre vai passar.