Padrões para Implementação de Proxies

Introdução

Implementar um proxy em nível de aplicação para servidores pode trazer resultados muito bons. Contudo, alguns pontos podem ser afetados, como a segurança por exemplo. (SOMMERLAND, 2003) A existência de Padrões para a configuração de proxy Reverso pode ajudar o usuário a entender em quais ocasiões tais configurações devem ser usadas e como se aplicam ao Squid de modo a atender alguns requisitos.

O objetivo deste artigo é mostrar alguns deste padrões e apresentar formas de implementá-los dentro do Squid:

Protection Reverse proxy

O problema: Um firewall com filtro de pacotes simples não é o suficiente. Ataques frequentes costumam usar parâmetros grandes na requisição e a maioria dos firewalls trabalha apenas com pacotes em nível de rede, não dá para prever vulnerabilidades futuras e mudando o software do servidor Web é necessário adaptações nas extensões do sistema.

Figura 1: Esquema de rede da configuração padrão

O Padrão: O padrão do tipo Proteção propõe uma topologia de rede onde se tem servidores com as aplicações Web sendo colocadas atrás de um proxy reverso em conjunto com regras de entrada e saída de um firewall. Basta abrir a porta de entrada do firewall para escutar as requisições vindas da internet e abrir as portas de saídas do servidor proxy para comunicação com os servidores que possuam os serviços requisitados.

Figura 2: Diagrama de rede da configuração de Protection Reverse proxy

Implementação:

1. Planeje as configurações de rede e firewall.
2. Selecione uma plataforma de proxy Reverso.
3. Configure seu web server.
4. Configure a proteção do proxy Reverso (lista negra e branca).
5. Implementação (firewall, rede, IPs) .

Benefícios: Os servidores que possuam tais serviços não ficam abertos a ataques. Conhecendo as vulnerabilidades, o proxy pode ser alterado para filtrar estes “pontos fracos”. Apenas uma máquina necessita de monitoração e se comunica diretamente com a internet, porém, os servidores também devem possuir filtros restritivos.

Limitações: O filtro de lista negra só pode ser construído a partir de vulnerabilidades conhecidas. Quando um servidor é rearranjado com a adição de outros serviços, por exemplo, o filtro de lista branca pode tornar-se frágil o que pode gerar reconfigurações na lista ou até mesmo no próprio proxy. A latência pode ser afetada já que todo o fluxo de requisições deve passar pelo proxy. Toda a estrutura deve ser conhecida fazendo com que haja falta transparência. Se o proxy parar, todo acesso aos servidores torna-se impossível. E recomendável que haja um computador para o proxy e outro para o firewall.

Integration reverse proxy

O problema: A necessidade de implementar um website com vários servidores e plataformas, escondendo sua topologia dos usuários. Os links entre estes servidores devem funcionar independente da topologia de rede, a mudança de partes do website não podem quebrar os links, o uso de redundância e balanceamento de carga, além de um único certificado SSL .

Figura 3: Diagrama de rede da configuração

O Padrão : O padrão do tipo Integração propõe que o proxy reverso integre todos os webservers em um endereço comum, ou seja, o do próprio proxy. Neste caso, o proxy irá mapear os caminhos de cada Servidor específico, o que torna fácil a modificação de uma função já que a alteração no proxy é simples. Outra coisa interessante é que basta ter apenas um certificado SSL no proxy para o domínio Web.

O que mais atrai é a combinação integration protection reverse proxy: Aplicações de intranet podem ser facilmente implementadas depois do proxy, da mesma maneira, uma aplicação web externa pode ser integrada sem que os usuários saibam de sua natureza externa. Já na parte de segurança, os servidores podem operar em uma zona de rede separada da rede interna. É possível utilizar dois proxies reversos de integração sendo um para internet e outra para intranet, possibilitando que as funcionalidades dos servidores sejam disponibilizadas para ambas as redes.

Figura 4: Diagrama de rede da configuração de Integration Reverse proxy

Implementação:

1. Projete os nomes dos websites. Vários prefixos podem ser mapeados para a mesma máquina, mas é melhor que o mapeamento seja simples. Uma alternativa é criar hosts virtuais possibilitando que os Servidores possuam seus nomes reais.
2. Configure os servidores web. Tenha em vista o interesse em criar relações entre os servidores, caso necessite, de modo que eles não se refiram aos seus endereços de host interno.
3. Implementação de redundância nos servidores. Se houver alguma falha de hardware, software ou mesmo a instalação de um novo servidor, é possível prover uma redundância para outra máquina que implementa a mesma funcionalidade.
4. Implementação do balanceamento de carga. Existem muitas estratégias, mas a mais simples é passar as requisições entre os vários servidores que implementam a mesma funcionalidade. Em outros casos é possível usar coleta de estatísticas e etc.

Benefícios: Apenas um host externo é conhecido (exceto quando se usa hosts virtuais, externamente é necessário conhecer apenas o nome e o IP do proxy). A topologia dos servidores finais é escondida o que possibilita mudanças sem invalidar sua URL externa. Mesmo quando um servidor é movido para outro host, os links continuam a funcionar. Balanceamento de carga de servidores pelo próprio proxy reverso. Logs centralizados. Apenas um host é visto na internet o que economiza IPs, nomes de hosts e certificados SSL.

Limitações: O próprio proxy é um ponto de falha, mas pode ter um risco minimizado por redundância. Número limitado de conexões concorrentes. Servidores que usam sessões pode ser um problema. Testar aplicações individualmente é difícil.

front door

O problema: Algumas aplicações web precisam de identificação de usuário para controle de sessão. Com múltiplos servidores para variados serviços que necessitem deste recurso, a autenticação em cada um deles não seria eficaz. A necessidade de apenas uma autenticação que libere acesso a todas as aplicações, implementar politicas de inatividade para requisitar uma nova autenticação, ter diferentes regras de acesso para diferentes tipos de usuários e que apenas uma solução controle essas diferenças e a necessidade de uma nova autenticação caso o usuário encerre sua sessão.

Figura 5: Diagrama de rede da configuração apenas com Integration Reverse proxy

O Padrão: O front door é uma especialização de segurança para o integration reverse proxy dando suporte a autenticação de usuários e uso de sessões passando as autenticações a todos os servidores finais mantendo um log de toda a atividade dos usuários em apenas um lugar. O pattern atua como proxy reverso de proteção para as partes públicas do website. É necessário consolidar a identidade dos usuários de todos os servidores finais e armazenar seus perfis contendo sua identidade e permissões de acesso em um diretório único além de se ter um sistema de gestão para manipular estas informações. Um diretório muito usado atualmente é o LDAP.

Figura 6: Diagrama de rede da configuração de front door

Implementação:

1. Unificação dos perfis de usuário em um banco de dados, um LDAP é suficiente para armazenar Ids, senhas e direitos de acesso.
2. Defina a mecânica de autenticação. Biometria, certificados, id e senha ou qualquer outro tipo de autenticação pode ser implementada a qualquer momento se alteração dos aplicativos.
3. Se necessário, defina os esquemas de acesso, mapeando os usuários aos seus direitos de acesso para permissão de uso de serviços específicos.
4. Projete como a representação do usuário e sua sessão para serem passados como cabeçalho aos servidores finais. Pode-se especificar um nome em um campo no cabeçalho ou utilizar uma mecânica básica de autenticação por HTTP usando a identificação do usuário.
5. Projete e implemente como o front door controla as sessões do usuário. Um método muito utilizado é a implementação por cookies.
6. Projete e implemente um contexto de sessão para o front door. Os cookies podem ser usados para armazenar as sessões, mas por limitações de tamanho e segurança, é bom que o contexto das sessões seja armazenado nos servidores. Outra boa alternativa é armazená-las em memória, mas uma falha pode causar perdas.
7. Implemente uma “jarra de cookies”. Se o servidor final usar seu próprio cookie de sessão, o front door pode guardar esses cookies em seu próprio contexto de sessão e não passa-lo para o browser do usuário garantindo um logoff único.
8. Projete e implemente a página do portal e o login. A página do portal pode ser implementada pelo front door Logo após a realização do login, o portal consistirá em todos os serviços permitidos ao usuário logado além do link de logoff.

Benefícios: Único login e logoff, perfil único de usuário para todos os serviços possibilitando que os servidores fiquem livres para implementar autenticação ou não, login centralizado para monitoramento dos usuários.

Limitações: Utilizando aplicações que possuam seu próprio esquema de autenticação pode gerar inconsistência na sincronização com os dados presentes no esquema de autenticação do front door. Conflito de time-out entre o front door e a aplicação podem confundir o usuário. É necessário um aplicativo para gerar a centralização das identidades dos usuários. As senhas podem expirar nos servidores finais, o que pode levar a um conflito com os dados no front door (Você pode auto gerar novas senhas ou pedir que o usuário altere-a atualizando-a tanto no front door quanto no servidor)

Conclusões

Utilizar configurações de forma padronizada para o proxy reverso deve “economizar muita dor de cabeça”, pois traz a organização, em nível lógico, bem definida do papel de cada elemento da rede além de demonstrar as disposições destes elementos e como eles interagem.

Os padrões requerem estudo da topologia da rede e um planejamento bem feito da organização da topologia da rede, o que não é trivial, e sua implementação pode ser um pouco complicada, por exemplo, quando se tem muitos serviços integrados. Algumas empresas desconhecem até a própria configuração básica deste tipo de proxy.

Existem configurações específicas para implementar cada uma destas configurações e elas serão apresentadas mais adiante.

Referência

SOMMERLAND, P. Reverse proxy Patterns. The Hillside Group, 2003. Disponivel em: <http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2003/2003_Sommerlad_ReverseproxyPatterns.pdf>. Acesso em: 21 fev. 2012.