Endian Firewall

Proxy transparente x não transparente: Desvendando os mitos
Blog, Endian Firewall, Fraudes, Segurança, Servidores

Proxy transparente x não transparente: Desvendando os mitos

Por que proxy não transparente é melhor que o transparente

A explicação simples é a de que, além de ser mais seguro, o proxy não transparente usa o recurso do cache de DNS. Para a explicação detalhada, leia o post:

A explicação simples é a de que, além de ser mais seguro, o proxy não transparente usa o recurso do cache de DNS. Para a explicação detalhada, leia o post:

Proxy transparente x não transparente: Desvendando os mitos

Proxy transparente x não transparente: Desvendando os mitos

Como funciona o proxy?

A palavra proxy significa literalmente procurador. No caso de um proxy HTTP, o servidor recebe uma requisição HTTP, a interpreta e executa as ações necessárias para respondê-la. Como geralmente possui um cache, ou ele responde com o conteúdo do cache, ou requisita o recurso (arquivo) ao servidor HTTP original, desta vez como um pedido próprio.

Proxy Transparente

O proxy transparente é uma arquitetura que permite que o navegador cliente não saiba da existência do proxy. Ele acha que está solicitando o recurso diretamente ao servidor original; o proxy encarrega-se de capturar e processar a solicitação.

A principal vantagem nesta arquitetura é que não é necessária a configuração de proxy nos navegadores cliente. Outra (incorretamente) alegada vantagem é que o proxy não transparente não impede a conexão direta à Internet.

Como fica o navegador?

Uma requisição comum de um agente HTTP se dá em duas fases:
1) há a requisição DNS para resolver o endereço de destino;
2) é feita a requisição HTTP propriamente dita.

Se o navegador não conhece a existência do proxy, ele irá fazer inicialmente a requisição DNS e, após resolvido o endereço, irá lançar a requisição HTTP ao servidor original. O proxy, por sua vez, não irá usar o DNS resolvido pelo navegador, e fará sua própria requisição DNS antes da requisição HTTP.

Existe uma consideração importante: apesar de o pacote DNS ser pequeno e transmitido em UDP, o tempo de resolução costuma não ser desprezível. Às vezes, chega a mais de um minuto. E é o minuto mais importante, porque fica entre o <ENTER> e o aparecer alguma coisa no navegador.

É, portanto, interessante para a LAN ter um cache DNS interno servindo a todas as máquinas. Isto pode ser feito com a instalação de um servidor DNS ou com o uso do cache DNS do próprio Squid.

Se o navegador conhece o servidor proxy, ele não fará nenhuma resolução DNS e fará a solicitação do recurso ao servidor proxy, não ao servidor original.

DNS com Squid e BIND

O Squid possui um cache DNS interno que pode ser acessado com o CGI Cache Manager (no debian, pacote squid-cgi ou squid3-cgi), item Internal DNS Statistics. O recurso é tão bom que diz o quanto tempo falta para cada entrada DNS expirar.

Não achei recurso semelhante no BIND (servidor DNS mais usado no mundo). No máximo, estatísticas gerais. O BIND é dividido em duas partes: servidor com autoridade e servidor de encaminhamento. Segundo sua documentação, é focado na performance.

Quando fiz meu TCC, tive que analisar algumas centenas de requisições DNS. E apesar de não ter visto os dados concretos do BIND, tive a nítida impressão de que o Squid é mais confiável no quesito cache. Ele visivelmente fazia menos encaminhamentos (ou seja, dava mais respostas de cache).

Segurança

Os vírus não usam proxy. Eles assumem uma conexão direta a Internet. Quando se usa proxy transparente, você está encaminhando as mensagens de vírus para a Internet. Simples assim.

Uma segunda consideração está relacionada também à conectividade: no modelo não transparente, os navegadores não precisam estar conectados à Internet. Eles só precisam estar conectados ao proxy e este se vira pra chegar à web. Se você costuma usar apenas web, então pode usar um gateway falso nos clientes. Isso significa que os softwares que não conhecerem o proxy não poderão iniciar mensagens para a Internet, pois não sabem a rota. Às vezes, pode ser útil.

Além disso, não é válido o argumento de que não se pode controlar a conexão no proxy não transparente. No proxy transparente, captura-se o pacote e, dessa forma, assegura-se que ele irá seguir o caminho do proxy. Na arquitetura de proxy não transparente, pode-se inibir o uso de Internet sem o proxy colocando-se um filtro do netfilter (via iptables) no firewall.

Se o proxy está no gateway, deve-se permitir (ACCEPT) pacotes para a porta 80 (–dport) apenas vindos da própria máquina (OUTPUT) e deve-se bloquear (DROP) as vindas da rede (FORWARD) para fora.

Se o proxy não está no gateway, deve-se permitir pacotes na porta 80 cuja fonte (-s) seja o proxy e bloquear as outras.

A sintaxe é aproximadamente essa:

proxy na mesma máquina firewall/gateway.
# iptables -A INPUT –dport 80 -j ACCEPT //requisições da LAN para o proxy
# iptables -A FORWARD –dport 80 -j DROP //requisições da rede pra fora
# iptables -A OUTPUT –dport 80 -j ACCEPT //requisições do proxy pra fora

proxy em máquina interna da rede.
# iptables -A FORWARD -s <ip.proxy> –dport 80 -j ACCEPT //requisições do proxy pra fora
# iptables -A FORWARD –dport 80 -j DROP //requisições da rede pra fora

Conclusão

Quanto à performance, existem duas formas eficientes de se fazer a dobradinha proxy/cache e cache DNS. Usando proxy transparente e servidor DNS ou usando o Squid como proxy não transparente.

Na primeira forma, deve-se colocar o servidor DNS interno à LAN e fazer com que tanto o proxy quanto a LAN utilizem-no. É comum as LAN Houses e mesmo as pequenas empresas usarem o servidor DNS do provedor. Isso é prejudicial no proxy transparente, já que as requisições são individuais dos navegadores, gerando tráfego desnecessário.

Na segunda forma, o servidor proxy Squid encarrega-se de fazer o próprio cache DNS. Esta implementação é mais simples e mais econômica em recursos. Pela “filosofia” KISS, pode-se dizer que é melhor.

E se houver um duplo uso de cache? Proxy não transparente + servidor DNS interno? Fiz isso no meu TCC, pensando que era a melhor saída. Pelo que pude analisar (com squid 2.7 e BIND 9.5), sempre que o squid requisitava DNS, o BIND9 encaminhava a requisição. Ou seja, o squid era suficiente. Além do mais, o servidor BIND estava configurado para realizar requisições em múltiplos servidores DNS caso o simples encaminhamento falhasse. O tráfego era enorme e redundante.

Quanto à segurança, parece-me que o melhor mesmo é usar proxy não transparente, principalmente por causa dos vírus, trojans e toda a fauna de processos mal intencionados no sistema operacional. No Windows, isso é vital. Coloca-se um gateway e servidores DNS falsos e processa-se apenas o que vier através do navegador. Sugiro utilizar uma máquina válida preparada para receber os pacotes não autorizados, de modo que identifique-se, via tcpdump, a origem e intenção destes pacotes.

Uma preocupação constante é quanto à facilidade de configuração da rede. Para isto, há o método do proxy auto-config (PAC).

Pelos motivos explanados acima, é possível considerar que em ambientes simplificados o uso de proxies não transparentes ofereça mais vantagens que desvantagens em relação aos transparentes. Claro que cada caso é um caso. Às vezes, a vantagem na facilidade de implantação do proxy transparente pode suplantar todas as vantagens do outro modelo.

ReceitaNet: Como liberá-lo com Endian Firewall
Blog, Endian Firewall, Servidores

ReceitaNet: Como liberá-lo com Endian Firewall

ReceitaNet: Como liberá-lo com Endian Firewall

ReceitaNet: Como liberá-lo com Endian Firewall

Recentemente recebi um e-mail de um amigo me perguntando como liberar a transmissão do imposto de renda usando o receitanet pelo Endian Firewall. Acredito que muitas pessoas também tenham essa dúvida, então, esse será o tema do meu post.

– Descobrindo o endereço e a porta de comunicação.

Essa etapa deu um pouco de trabalho, pois o site da receita é um pouco confuso sendo necessário garimpar bastante atrás de informação. Procurando bastante, encontrei o IP da rede, máscara de sub-rede, protocolo e a porta que deveriam ser liberadas.

IP da rede: 161.148.0.0
Máscara: 255.255.0.0
Protocolo: TCP
Porta: 3456

Dica: Quando for procurar por endereços IP e portas, comece pelos materiais oficiais. Esses estão mais atualizados e são fontes mais seguras.

– Criando a regra de liberação

Clique na aba “Firewall” e depois no menu “outgoing traffic”.
Clique no link “criar nova regra”.

Edite os campos como na figura abaixo.

ReceitaNet: Como liberá-lo com Endian Firewall

Para finalizar aplique a regra.

Bloqueando o Facebook com Endian Firewall
Blog, Endian Firewall, Servidores

Bloqueando o Facebook com Endian Firewall

Bloqueando o Facebook com Endian Firewall

Bloqueando o Facebook com Endian Firewall

Desde que comecei a escrever sobre o Endian Firewall, tenho recebido e-mails e comentários de incentivos pela iniciativa. Tenho recebido também pedidos de explicações de como solucionar determinados problemas. Então, como várias pessoas me pediram dicas de como bloquear o facebook com o Endian Firewall, decidi escrever sobre o assunto. Existem outras formas de se bloquear o facebook, mas por enquanto, desse jeito está funcionando.
Quando vamos bloquear o facebook, nos deparamos com um grande problema, o protocolo HTTPS.


O tráfego de dados utilizando o protocolo HTTPS é criptografado e por esse motivo o Endian Firewall não consegue identificar que site foi digitado pelo usuário permitindo assim a sua passagem. Os usuários mais experientes habilitam o protocolo HTTPS como padrão para a conexão com o facebook burlando assim a segurança do filtro de conteúdo.
Para contornar esse problema, vamos descer um pouco na camada OSI e vamos trabalhar com endereços de rede.

– Descobrindo as redes que atendem o facebook.

Para descobrir os endereços de rede do facebook, utilizei o bom e velho nslookup do Windows e em complemento a ele, utilizei o site http://www.kloth.net/services/nslookup.php. Fiz uma pesquisa utilizando os endereços facebook.com / fb.com / facebook.com.br / facebook.com.tw.
Analisando os resultados do site e do windows, pude perceber que o facebook atende pelas redes 66.220.0.0; 66.171.0.0; 69.220.0.0; 69.171.0.0; 69.63.0.0; 204.74.0.0; 208.93.0.0. Para esses endereços de rede a mascara a ser utilizada é a 255.255.0.0 ou /16. Bloqueando o Facebook com Endian Firewall

– Implementando o bloqueio.

Acesse o Endian Firewall utilizando o endereço da interface verde no seu navegador. Assim que a tela principal abrir, acesse a aba firewall e o menu tráfego de saída.

Bloqueando o Facebook com Endian Firewall

 Bloqueando o Facebook com Endian Firewall

Assim que a tela de configuração do firewall de saída for totalmente carregado, clique no link “adicionar nova regra de firewall”.

Bloqueando o Facebook com Endian Firewall

Na opção origem tipo, selecione Zona / Interface e logo abaixo marque a opção verde.
Na opção destino tipo, selecione Rede / IP e logo abaixo preencha com os endereços de rede coletados com o comando nslookup e com o site. Lembrando de colocar o /16 no final de cada endereço. Dessa forma estamos especificando a mascara de sub-rede a ser utilizada.

Exemplo: 66.220.0.0/16

Na opção serviço, selecione “definido pelo utilizador”.
Na opção protocolo, selecione “TCP + UDP”.
Na opção porta de destino, digite 80 e 443.

80 – http
443 – https

Na opção política ação, selecione “bloquear”.
No campo observação, escreva algo que lembre a função dessa regra. Exemplo: Bloqueando o Facebook.
Na opção posição, selecione uma posição que fique antes dos protocolos http e https.

Obs.: O firewall verifica as regras em seqüência, então, se você colocar essa regra depois de uma regra que libere os protocolos http e https, o bloqueio não funcionará, pois o firewall vai parar nas regras que liberam.

Bloqueando o Facebook com Endian Firewall.

Para finalizar, clique no botão criar regra.

Você retornará para a tela da lista de regras. Clique no botão aplicar na caixa de diálogo verde que se abrirá no topo da tela.

Bloqueando o Facebook com Endian Firewall

Um grande abraço a todos e até o próximo post.