Bom dia,
Desde o ultimo post que fiz utilizando o HAproxy da PFsense para separar ligações aplicacionais SSL de uma ligação https tipica, a partilhar a mesma porta de https, surgiu-me um pedido extremamente interessante:
Perguntaram-me como separar dois ambientes de owncloud: Um seria para serviço interno na empresa, o outro para utilização publica para Clientes.
Tendo em conta que como todos os ambientes de owncloud partilhados correm por definição em um (1) servidor web, em termos de segurança isto poderia ter implicações.
Outro pré requisito indicava que ambas as instâncias de owncloud deveriam estar por trás de uma firewall com IDS de forma a mitigar ataques, e teriam ambas que partilhar o mesmo IP de acesso.
Finalmente, as aplicações deveriam ser contidas, segregadas e com poucos recursos.
Foi avançada a possibilidade de configurar 2 vHosts num apache, um que fizesse acesso local (por exemplo para a instância publica), e outro com mod_proxy para outro servidor com a instância privada.
Isto iria introduzir um single point of failiure pois caso o primeiro webserver falhasse, a segunda instância iria ficar igualmente inacessível pelo que foi uma escolha preterida.
Existia a hipótese de duas VM’s cada uma com a sua instância mas em termos de recursos o servidor onde iria estar a plataforma montada é algo modesto e duas VM’s iria comprometer recursos desnecessários.
Optou-se portanto por duas instalações de LXC na mesma VM, cada uma com a instância em endereçamentos IP totalmente diferentes: Uma de DMZ e outra de Servidores.
A instalação do produto owncloud em sqlite (a DB usada para backend aplicacional) tem bastantes howto’s na internet e este post não é acerca disso.
O que nos interessa, é a forma de agulhar tráfego na pfsense, ao nível do HA proxy, e diferenciar que tráfego vai para que site baseado no url de destino.
Na pratica e muito simplificadamente ficamos com algo como isto:
O pedido chega a pfsense, é analisado para ameaças, define o destino baseado no url e em seguida encaminhado para o container corredator.
Em primeiro lugar, na pfsense será necessário definirem dois backends: Um publico que irá conter a instância da owncloud publica, e outro privado, que irá conter a instância privada:
No caso do b_privado temos:
E no b_publico temos:
Temos portanto dois servidores, em duas vlans separadas com endereçamento diferente.
Podemos então construir a ACL que irá encaminhar os pedidos:
E as ações a tomar conforme as ACL’s sejam validadas:
Traduzindo, caso a condição de url seja verificada, será encaminhado para a instância de owncloud que se pretenda, ou publica ou privada.
Finalmente e após configurar o snort, chegou a altura de aplicar as regras de IDS and smartdefense que nos interessa:
O snort irá inspecionar a rede WAN (onde está a instância publica) e o LXC onde está a instância privada.
Com este post tentei mostrar a elasticidade de um datacenter software defined (DaaS), onde neste caso equipamento ativo de rede (firewall, balanceadores e IDS) foram substitutos por software.
É importante sublinhar que em configurações DaaS de existe uma penalização de performance, especialmente quando toda a infraestrutura estiver sobre muita carga.
No entanto, nos ambientes cloud com datacenters totalmente virtuais, este tipo de configuração faz perfeitamente sentido especialmente se o orçamento não for grande.
É uma solução suportada pelo próprio fabricante da appliance pfSense, da mesma forma que para ambientes LXC / Dockers temos o Red Hat Atomic Server totalmente suportado e com SLA’s associados.
Sei ainda a partida que a configuração do snort deve ter despertado algum interesse, tendo em conta que muitos dos que leem são entusiastas dos seus laboratórios e que se preocupam com a segurança dos mesmos.
O próximo post será dedicado precisamente a configuração de um snort, para defesa ativa do vosso laboratório / datacenter.
Até lá, sabem onde me encontrar.
1Abraço,
Nuno