Proxy Reverso com Apache [Wiki TCE-GO]

Essa página está em modo somente de leitura. Você pode visualizar a fonte, mas não alterá-la. Informe-se com o administrador do Wiki, caso você ache que isso está incorreto.
====== Proxy Reverso com Apache ======


===== Introdução =====

A informação se tornou um ativo estratégico para o Tribunal de Contas do Estado de Goiás - TCEGO - e por isso deve ser protegida observando as melhores práticas de segurança da informação disponível no mercado. Proteger os dados de maneira adequada, zelando pela disponibilidade, integridade, confidencialidade e autenticidade faz parte das atribuições da Gerência de TI, dessa forma, uma das regras básicas é garantir o controle de acesso e o isolamento da rede externa à rede interna do TCEGO.

Esse documento se destina a documentar a construção de um servidor Bastion Host com serviço Apache para uso em uma arquitetura de firewall Screening Subnet, para protocolos de aplicação (HTTP, HTTPS, FTP). Nesse modelo, o servidor Bastion Host atuará como um proxy de aplicação, isolando os servidores de aplicação da rede interna, impedindo que pessoas na rede externa acessem diretamente a rede interna.

\\ ===== Motivação =====

==== Isolamento de serviços ====

Na época em que foi desenhada essa solução o TCEGO não possuía uma arquitetura de firewall bem consolidada e segura, o que compromete a segurança da rede interna do tribunal. Foi identificado o uso de firewall baseado em filtro de pacotes que trata o tráfego de saída de toda a rede, com a arquitetura Screening Router:

{{redes:ScreeningRouter.gif?400x351|ScreeningRouter.gif}}Essa é a forma mais simples de arquitetura de firewall, em que é colocado um firewall baseado em filtro de pacotes entre a rede interna e a rede externa. Nesse caso cada máquina da rede interna se conecta diretamente com a rede externa (vice-versa), para host conexão, um par de regras é adicionado no firewall, logo a "zona de risco" é igual ao número de hosts configurados para acessar a rede externa.

Nesse modelo é possível, por exemplo, que um hacker envie pacotes de rede diretamente ao servidor que provê o serviço na rede interna, o que permite diversos tipos de ataques. Cada máquina servidora possui uma implementação local de firewall de filtro de pacotes, o que dificulta da gestão da segurança, a realização de testes de conformidade dentre outros. Logo, o modelo em uso não pode ser considerado eficiente e tampouco seguro.

==== Padronização de interfaces e controle de erros ====

Além do problema de exposição direta da máquina servidora, ressalta-se a dificuldade de padronização de tratamento de erros nos servidores de aplicação. Atualmente predomina no TCEGO o uso de soluções web baseadas em Microsoft Windows, mas existem implementações que utilizam Ruby on Rails ou PHP. Com o ambiente web heterogêneo, torna-se mais trabalhoso a gestão de incidentes que aparecem para o usuário. Com o uso do proxy, centralizando todos os serviços web em um único ambiente de saída, toda a gestão dos serviços se torna menos trabalhosa.

A figura abaixo é um "print" de um erro que aparece para o usuário do site ggp.tce.go.gov.br, fruto de uma falha de configuração do servidor web que hospeda essa aplicação, mas que pode ser tratado de maneira geral no proxy muito facilmente. Note que nessa página foi exposto parte do código fonte da aplicação, informações sobre o ambiente da aplicação, versão de software utilizado, caminho onde estão os arquivos no servidor e sistema operacional. Essas informações podem ser utilizadas por hackers para realizar ataques à base de dados de pessoas do TCEGO, por exemplo.

{{ :redes:700px-erroggpgave.png |}}

==== Centralização de Certificados SSL para vários subdomínios ====

Outro problema que chama atenção é a falta do uso de certificados digitais nas páginas. O uso de um certificado garante o sigilo nas comunicações, pois quando bem utilizado, protege a transmissão de dados com o uso de criptografia. No TCEGO, diversos sistemas utilizam controle de acesso, onde o usuário digita um login e senha. Esse login e senha é o mesmo utilizado para acessar a rede do TCEGO e todos os sistemas. Todavia, como as páginas não são criptografadas, um usuário com um pouco de conhecimento técnico em informática pode facilmente capturar o login e senha de um Conselheiro, por exemplo, e acessar locais restritos na rede, em sistemas ou se passar pelo Conselheiro utilizando o Webmail. Abaixo segue um exemplo de captura de senha realizada na página ggp.tce.gov.br que pode ser facilmente reproduzida na rede do TCEGO:

{{ :redes:700px-capturasenhaggp.png |}}

 Com o uso do Proxy centralizando as conexões em um único domínio de rede (tce.go.gov.br), é possível utilizar um único certificado digital para criptografar todas as páginas. Nesse projeto em tela foi criado um certificado local, não assinado por entidade certificadora, mas com capacidade de criptografar as páginas do TCEGO, inviabilizando a captura de senha através de análise de tráfego de rede, garantido confidencialidade na comunicação.

===== Metodologia =====

A primeira parte do trabalho consistiu na coleta de informações sobre o atual estado da rede do tribunal para entender como está a gestão da rede. Após essa etapa, iniciou-se o estudo de um modelo de segurança que se adequasse à realidade do TCEGO, tanto no aspecto técnico levando em consideração o conhecimento da equipe de rede quanto no aspecto orçamentário.

Através da aplicação de monitoramento Zabbix, foi feita análise de tráfego de entrada nos principais servidores Web do Tribunal e constatou-se que apesar de o TCEGO ser um órgão com grande visibilidade externa, o tráfego de dados proveniente da rede externa é relativamente pequeno, com média de XXXXXXXX conexões simultâneas e tráfego total de XXXXXX por dia.

Com isso, foi desenhado o modelo de arquitetura de firewall aderente à situação do TCEGO, baseada em software livre. Um ambiente de testes foi montado, um protótipo da solução foi construído e os portais tce.go.gov.br, ggp.tce.go.gov.br, webmail.tce.gov.br foram testados. Dentre os testes feitos relata-se análise de tráfego com aplicativos Zabbix, TCPDUMP e IPTRACK e teste estresse de Apache JMetter.

====== Proposta ======

===== Arquitetura Screened Subnet =====

{{:redes:ScreenedSubnet.gif|ScreenedSubnet.gif}}\\ Dentre as arquiteturas de firewall, a Screened Subnet é considerada uma das mais seguras. Através dessa arquitetura é inserido o conceito de Zona Desmilitarizada (DMZ), que consiste em uma região de rede ou sub-rede coberta por dois Firewalls: um que analisa conexões externas e outro que analisa conexões da rede interna.

Dentro da DMZ é colocado um servidor Bastion Host com a função de garantir maior isolamento da rede interna. Esse servidor normalmente é uma máquina Linux ou hardware dedicado com a única função de proxy, não possuindo qualquer outro serviço. Todas as requisições de serviços que são originadas na rede externa são feitas diretamente no Bastion Host, que por sua vez acessa a o serviço na rede interna. Dessa forma o Bastion Host atua como um proxy e as máquinas da rede externa não podem se conectar diretamente aos servidores da rede interna que realmente fornecem os serviços.

A grande vantagem dessa arquitetura é forçar todos os serviços a passar pela análise do firewall e o isolamento entre as redes interna/externa com o uso do Bastion Host garante uma camada de segurança mais efetiva contra ataques externos. Outra vantagem é a centralização de acesso no Bastion Host, pois somente ele responde pelo domínio tce.go.gov.br, logo, regras gerais de segurança podem ser definidas nesse servidor, como por exemplo uso de certificado SSL, tratamento de erros e monitoramento centralizado.

A grande desvantagem é que a implementação dessa arquitetura é complexa, exige maior grau de conhecimento da equipe de rede. Além disso, o Firewall que compõe a DMZ e o Bastion Host se tornam nós centrais de conexão e por isso indisponibilidade desses equipamentos causará a indisponibilidade de todos os serviços do TCE.

===== Arquitetura Proposta =====

Foi projetada a criação de uma Zona Desmilitarizada - DMZ - utilizando um servidor físico com três interfaces de rede. Uma interface se comunica com a rede externa (internet), outra com a Zona Desmilitarizada, a terceira com a rede interna do TCEGO. Os detalhes da implementação da DMZ não serão tratados nesse documento, portanto, considera-se aqui o ambiente de firewall implementado.

O Bastion Host é um servidor virtual com sistema operacional Linux, rodando Apache, funcionando como um proxy de camada de aplicação, tratando protocolos HTTP, HTTPS e FTP. Nesse contexto, o Bastion Host centraliza todos os serviços web do TCEGO e toda requisição externa é feita diretamente á esse servidor.

Mecanismos de segurança devem ser implementados no Bastio Host, como um IPS de host, além de sistema de monitoração de uso de recursos. Além disso, para garantir disponibilidade do serviço, é recomendada a duplicação desse servidor, utilizando protocolo CARP num sistema de Mestre-Escravo. Assim, quando um servidor ficar indisponível, o outro assume o serviço.

{{ :redes:800px-redetce.png |}}

===== Análise de Riscos =====

A análise de riscos da solução foi realizada levando em consideração a inserção em um ambiente em que a zona desmilitarizada está bem definida e a solução de firewall desenhada.

|  **Causa**  |  **Risco**  |  **Efeito**  |  **Probabilidade**  |  **Impacto**  |  **Estratégia**  |  **Ação**  |
|Falta de recursos físicos|Hardware inadequado|Falhas de Hardware podem parar a rede|A|A|Mitigar|Utilizar servidor físico, com cobertura de garantia do fabricante.|
|Erros na configuração e/ou atualização de software e sistema operacional|Falhas de software|Comprometimento da segurança da informação, indisponibilidade ou lentidão na rede|M|A|Mitigar|Utilizar Sistema Operacional Linux estável; Realizar testes de atualização de software em ambiente de homologação; Realizar testes de configuração em ambiente de homologação; Realizar gestão de configuração sobre o servidor;|
|Falha de gestão de firewall e DMZ|Violação da segurança na Zona Desmilitarizada|Comprometimento do funcionamento da arquitetura e do proxy|M|A|Mitigar|Realizar análise crítica periódica do funcionamento da DMZ, inclusive análise estática e funcional de regras de acesso; Realizar monitoração do uso de recursos pelo firewall.|
|Falhas no controle de acesso|Acesso físico ou lógico indevido ao firewall|Sabotagem, inserção de erros, exposição de indevida de informação, comprometimento da segurança da arquitetura.|B|A|Eliminar|Restringir acesso físico à sala de servidores; Fortalecer o servidor com regras de segurança de software; Realizar auditoria mensal nos arquivos de log de controle de acesso lógico do servidor;|
|Inexistência de central de monitoramento de ativos|Violação da segurança da arquitetura por ataques de hackers não ser percebida.|Comprometimento da segurança da informação, roubo de dados, exposição indevida de informação.|M|A|Mitigar|Realizar monitoração do servidor com Zabbix e IDS de host;|
|Erro no planejamento de capacidade|Quantidade de tráfego/usuários/conexões maiores que o esperado|Indisponibilidade ou lentidão na rede|B|M|Eliminar|Realizar monitoração diária do tráfego de rede no servidor com Zabbix;|
|Falta de plano de testes|Testes de conformidade não serem realizados regularmente|Ameaças serem exploradas sem conhecimento da equipe de rede e segurança da informação.|M|M|Eliminar|Estabelecer processo de testes periódicos de conformidade;|
|Inexistência de capacitação sobre as ferramentas de segurança|Falta de conhecimento técnico em ferramentas de segurança|Erros de configuração e manutenção da solução de segurança.|B|A|Eliminar|Realizar documentação da solução; Buscar apoio junto ao IMB para capacitação em ferramentas de segurança da informação;|
|Falhas no processo de transferência de tecnologia|Baixa qualidade da documentação do produto|Erros de configuração e manutenção da solução de segurança.|B|M|Eliminar|Realizar documentação da solução na [[infraestrutura_de_ti:redes:WikiTCE]].|
|Falta de recursos humanos|Equipe pequena e inexperiente|Erros de configuração e manutenção da solução de segurança, atraso na implementação mudanças na arquitetura;|B|M|Eliminar|Realizar documentação da solução; Buscar apoio junto ao IMB para capacitação em ferramentas de segurança da informação;|
|Falta de recursos humanos|Equipe com alta rotatividade|Erros de configuração e manutenção da solução de segurança.|B|M|Mitigar|Realizar documentação da solução; Buscar apoio junto ao IMB para capacitação em ferramentas de segurança da informação;|
|Erros no planejamento do projeto|Falta de apoio da Gerência ao projeto|Projeto ser abandonado|M|M|Eliminar|Elaborar apresentação formal da solução sobre a importância da solução para o TCE.|
|Erros no planejamento do projeto|Análise de riscos incompleta|Surgimento de diversos riscos sem tratamento ao longo do ciclo de vida da solução.|B|M|Eliminar|Analisar criticamente periodicamente o documento de riscos; Documentar novos riscos a media que vão surgindo.|

===== Resultados Esperados =====

Com a implementação de toda a solução, espera-se garantir maior segurança à rede do TCEGO, dar maior transparência na gestão de segurança da informação no que se refere ao controle de acesso à rede de serviços web. Dentre os objetivos do projeto, destacam-se:

  - Padronização da gestão de firewall;
  - Padronização da gestão de servidores de aplicação;
  - Proteção contra ataques de rede;
  - Proteção contra invasão de servidores de aplicação;
  - Isolamento da comunicação direta entre usuários externos e rede interna do TCEGO;
  - Centralização da gestão de serviços web;
  - Implementação de mecanismos de monitoramento de recursos web;
  - Criptografia das páginas de sistemas web;
  - Documentação da arquitetura da rede do TCEGO;

====== Projeto ======

===== Ambiente =====

Para o protótipo e testes foi criada uma máquina virtual Linux Debian 8 chamada de [[infraestrutura_de_ti:redes:BastionHost]], sem interface gráfica e apenas com pacotes básicos do sistema, para servir como Bastion Host. Foram habilitadas 2 interfaces de rede: um para rede externa (eth1) de IP 192.168.56.23 e outra para rede interna (eth2) de IP 10.2.0.55.

O aquivo de DNS local (C:\Windows\System32\drivers\etc\hosts) foi configurado e foram criados os domínios locais para teste:

  - 192.168.56.23 tce2.go.gov.br
  - 192.168.56.23 ggp2.tce2.go.gov.br
  - 192.168.56.23 webmail2.tce2.go.gov.br
  - 192.168.56.23 tcenet2.tce2.go.gov.br

{{:redes:VisaoAmbienteBasicoProxy.png|VisaoAmbienteBasicoProxy.png}}\\ Assim, todo tráfego que sair da máquina local para o servidor no domino tce2.go.gov.br deverá entrar pelo IP 192.168.56.23 no servidor.

\\     * **OBS: PARA TESTAR, NECESSÁRIO DESABILITAR O PRÓXY LOCAL DO NAVEGADOR**.

\\ Internamente, quando o [[infraestrutura_de_ti:redes:BastionHost]] receber requisição para a página ggp2.tce2.go.gov.br, ele irá se conectar ao servidor que da rede local que responde por ggp.tce.go.gov.br, receber o conteúdo e repassar para o computador que realizou a requisição na rede externa.

===== Instalação e configuração do Apache =====

Debian

==== Instalando Apache ====

  * Pacotes necessários: apache2 libapache2-mod-proxy-html libxml2-dev openssl:

<code>
aptitude install apache2 libapache2-mod-proxy-html libxml2-dev openssl apache2-mpm-prefork apache2-prefork-dev libxml2 libxml2-dev apache2-dev
</code>

  * Desabilitar módulo worker

<code>
a2dismod mpm_worker
a2dismod mpm_event
</code>

  * Habilitar módulo prefork

<code>
a2enmod mpm_prefork
</code>

  * Habilitar demais módulos necessários:

<code>
a2enmod ssl
a2enmod proxy
a2enmod proxy_http
a2enmod proxy_ajp
a2enmod rewrite
a2enmod deflate
a2enmod headers
a2enmod proxy_balancer
a2enmod proxy_connect
a2enmod proxy_html
</code>

==== Instalação do módulo prefork ====

Instalando dependências:

<code>
mkdir ~/modbuild/ && cd ~/modbuild/
wget http://apache.webthing.com/svn/apache/filters/mod_xml2enc.c
wget http://apache.webthing.com/svn/apache/filters/mod_xml2enc.h
apxs2 -aic -I/usr/include/libxml2 ./mod_xml2enc.c
cd ~
rm -rfd ~/modbuild/
service apache2 restart
</code>

==== Verificar instalação e módulos ====

Confirme um restar no apache e carregue as variáveis do ambiente

<code>
service apache2 restart
source /etc/apache2/envvars
</code>

Verifique se o apache está com módulo prefork:

<code>
/usr/sbin/apache2 -V
</code>

Verifique se os módulos foram carregados:

<code>
/usr/sbin/apache2 -t -D DUMP_MODULES
</code>

==== Cálculo de recursos dos processos Apache ====

1 - Determinar memória máxima para o Apache. Nesse caso, pretendo utilizar até 90% da memória total do servidor para o Apache. O servidor possui 2GB de RAM.

<code>
MemTotalApache = 2GB * 0,9 = 1800MB
</code>

2 - Determinar a memória atualmente utilizada pelo Apache. Rodar o seguinte script abaixo:

<code>
pgrep apache2 | xargs -n1 -I{} cat /proc/{}/smaps | \
  awk '{if ($0 ~ /stack/) {pids+=1} else if ($0 ~/^Shared_/) 
    {shared+=$2} else if ($0 ~ /^Pss:/) {priv+=$2}} END {
      printf "%.2f MB\n",(priv+shared/(pids*pids))/1024}'
</code>

<code>
MemUtilizadaApache = 5.65 MB
</code>

3 - Determinar variável [[infraestrutura_de_ti:redes:MaxClients]], ou seja, o número máximo de clientes que o Apache poderá atender simultaneamente.

<code>
 MaxClients = MemTotalApache / MemUtilizadaApache  = 318
</code>

4 - Determinar demais variáveis:

<code>
MaxClients         318
ServerLimit  = MaxClients         = 318
StartServers    = MaxSpareServers = 159 
MaxSpareServers 50% de MaxClients = 159
MinSpareServers 25% de MaxClients = 80
MaxRequestWorkers                 = ServerLimit   
MaxRequestsPerChild               = 10000
MaxConnectionsPerChild            = 0
</code>

5 - Adicionar essas configurações no arquivo

==== Configurações de segurança ====

Editar o arquivo **/etc/apache2/conf-available/security.conf**.

Colocar servidor em modo de produção:

<code>
ServerTokens Prod
</code>

Não emitir assinatura do servidor para o usuário:

<code>
ServerSignature Off
</code>

Adicionar segurança descomentando as linhas:

<code>
Header set X-Content-Type-Options: "nosniff"
Header set X-Frame-Options: "sameorigin"
</code>

==== Instalação do SSL ====

<code>
mkdir /etc/apache2/ssl
</code>

\\ <code>
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
</code>

\\ <code>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
</code>

===== Configuração do Proxy =====

==== Virtual Host ====

Exemplo de configuração de virtual host. Importante que todos os virtual hosts tenham resolução de nomes no DNS geral ou no arquivo **/etc/hosts**. Por exemplo, para criar um proxy para o site **[[http://tce.go.gov.br|http://tce.go.gov.br]]** utilizando o endereço **[[https://tce2.tce.go.gov.br|https://tce2.tce.go.gov.br]]**, é necessário que o servidor proxy consiga resolver os dois endereços. Como não existe registro de **[[https://tce2.tce.go.gov.br|https://tce2.tce.go.gov.br]]** no DNS do TCE, criei uma entrada no arquivo **/etc/hosts** no servidor proxy apontado para ele mesmo.

<code>
127.0.0.1       localhost
127.0.1.1       kakaroto01.tce.go.gov.br        kakaroto

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

10.2.17.28 tce2.tce.go.gov.br
</code>

\\ === Criar configuração geral para proxy e SSL ===

Criar diretório **include** e dentro dele os arquivos **proxy_no_ssl.conf** e **proxy_w_ssl.conf**.

  * OBS: [[infraestrutura_de_ti:redes:CentOS]] instalar **yum install mod_ssl**

  * Arquivo **include/proxy_no_ssl.conf**

<code>
#ARQUIVO proxy_no_ssl.conf
DocumentRoot /var/www/error

##FAZ COM QUE O PROXY SOBRESCREVA ERROS DO SERVIDOR DE ORIGEM
ProxyErrorOverride On

##FAZ COM QUE O PROXY ENCONTRE DIRETORIO COM MENSAGEM DE ERROS CUSTOMIZADAS
ProxyPass /error-documents !
ErrorDocument 404 /error-documents/HTTP_NOT_FOUND.html
Alias /error-documents /var/www/error
AllowEncodedSlashes on

##nao fazer proxy para chamadas locais ou servicos especificos
NoProxy kakaroto.tce.go.gov.br 10.2.17.28 10.2.17.29
</code>

\\   * Arquivo **include/proxy_w_ssl.conf**

<code>
 #ARQUIVO proxy_w_ssl.conf
 ##inclui configuracao geral de proxy  
 include include/proxy_no_ssl.conf

 ##FORCAR SSL NA CONEXAO
 SSLEngine on
 SSLCertificateFile /etc/apache2/ssl/apache.crt
 SSLCertificateKeyFile /etc/apache2/ssl/apache.key
</code>

=== Virtual Host Default ===

  * Virtual Host que aponta para o próprio servidor quando não houver "proxiamento"

<code>
 #ARQUIVO proxy_default.conf
<VirtualHost kakaroto.tce.go.gov.br:80>
 DocumentRoot /var/www/error
</VirtualHost>
</code>

=== Virtual Host sem SSL ===

  * Para cada página "proxiada" um Virtual Host deverá ser implementado. Quando a página não exigir SSL, basta criar um virtual host sem SSL. Caso contrário, necessário criar dois: um para porta 80 e outro para porta 443.

<code>
#ARQUIVO TCEGO.CONF
#EXEMPLO DE APLICAÇÃO QUE NAO EXIGE SSL. NESSE CASO, APENAS A CONEXOES NA PORTA 80 NAO PERMITIDAS
<VirtualHost tce2.go.gov.br:80>
   
   ##NOME DO SERVICO EXTERNO "PROXIADO"
   ServerName tce2.go.gov.br
   ServerAdmin admin@tce.go.gov.br
   
   ##INCLUIR CONFIGURACAO DE PROXY SEM SSL
   include include/proxy_no_ssl.conf

   ##FAZER PROXY DO SERVICO
   ProxyPass /  http://www.tce.go.gov.br/ timeout=60
   ProxyPassReverse /  http://www.tce.go.gov.br/ timeout=60

</VirtualHost>
</code>

=== Virtual Host Com SSL ===

<code>
#ARQUIVO WEBMAIL.CONF
#EXEMPLO DE VIRTUAL HOST QUE EXIGE SSL. SAO ABERTAS DUAS CONFIGURACOES, UMA PARA PORTA 80 E OUTRA PARA PORTA 443. 
#NO CASO DE CONEXOES QUE CHEGAM SEM SSL (NA PORTA 80), O APACHE FORÇA O USO DO SSL COM A DIRETIVA "REDIRECT PERMANET"
 
 <VirtualHost webmail.tce.go.gov.br:80>

 ##NOME DO SERVICO EXTERNO "PROXIADO"
 ServerAlias webmail.tce.go.gov.br
 ServerName  webmail.tce.go.gov.br

 ##REDIRECIONAR PARA HTTPS
 #Redirect permanent / https://webmail.tce.go.gov.br/

 ##CRIAR LOGS ESPECIFICOS PARA ESSE HOST
 ErrorLog "/var/log/apache2/webmail.tce.go.gov.br_error.log"
 CustomLog "/var/log/apache2/webmail.tce.go.gov.br_access.log" common

 #INCLUIR CONFIGURACAO GERAL DE PROXY COM SSL
 include include/proxy_no_ssl.conf

 ##FAZER PROXY DO SERVICO
 ProxyPass / http://webmail.tce.local/ timeout=30
 ProxyPassReverse / http://webmail.tce.local/ timeout=30

</VirtualHost>

<VirtualHost webmail.tce.go.gov.br:443>

        ##NOME DO SERVICO EXTERNO "PROXIADO"
        ServerName webmail.tce.go.gov.br:443
        ServerAdmin admin@tce.gov.br
        ServerAlias webmail.tce.go.gov.br

        ##CRIAR LOGS ESPECIFICOS PARA ESSE HOST
        ErrorLog "/var/log/apache2/webmail.tce.go.gov.br_error.log"
        CustomLog "/var/log/apache2/webmail.tce.go.gov.br_access.log" common

        #INCLUIR CONFIGURACAO GERAL DE PROXY COM SSL
        include include/proxy_w_ssl.conf

        ##FAZER PROXY DO SERVICO
        ProxyPass / http://webmail.tce.local/ timeout=30
        ProxyPassReverse / http://webmail.tce.local/ timeout=30
</VirtualHost>
</code>

=== Habilitar virtual host ===

<code>
 a2ensite proxy_default
 a2ensite webmail
 a2ensite tce
</code>

===== Análise de Tráfego =====

Configuração das interfaces de rede:

{{ :redes:500px-bastionhostredelocalifconfig.png |}}

Tabela de rotas do sistema:

{{:redes:CapturaBastionHost_rotas.png|CapturaBastionHost rotas.png}}\\ 

Captura na interface eth1, rede externa, porta 80:

{{ :redes:1000px-capturaeth1_redeexterna_porta80.png |}}
\\ Captura na interface eth2, rede interna, porta 80:

{{ :redes:1000px-capturaeth1_redeexterna_porta443.png |}}
\\ Captura na interface eth1, rede externa, porta 443:

{{ :redes:1000px-capturaeth2_redeinterna_porta80.png |}}

===== Conclusão =====

====== Bibliografia ======

  - Marcus J. Ranum, "Thinking About Firewalls", disponível em [[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.407.1196&amp;rep=rep1&amp;type=pdf|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.407.1196&rep=rep1&type=pdf]]
  - [[http://httpd.apache.org/docs/2.4/mod/mod_proxy.html|http://httpd.apache.org/docs/2.4/mod/mod_proxy.html]]
  - [[http://httpd.apache.org/docs/current/mod/mod_rewrite.html|http://httpd.apache.org/docs/current/mod/mod_rewrite.html]]
  - [[http://www.vivaolinux.com.br/artigo/Virtual-Host-com-Apache|http://www.vivaolinux.com.br/artigo/Virtual-Host-com-Apache]]
  - [[https://httpd.apache.org/docs/2.2/vhosts/examples.html|https://httpd.apache.org/docs/2.2/vhosts/examples.html]]
  - [[http://www.vivaolinux.com.br/dica/Apache-Criando-um-Virtual-Host-com-Proxy|http://www.vivaolinux.com.br/dica/Apache-Criando-um-Virtual-Host-com-Proxy]]
  - [[https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension|https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension]]
  - [[http://www.vivaolinux.com.br/artigo/Como-montar-um-proxy-reverse-no-servidor-Apache|http://www.vivaolinux.com.br/artigo/Como-montar-um-proxy-reverse-no-servidor-Apache]]
  - [[https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-debian-7|https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-debian-7]]
  - [[http://www.miguelborges.com/personalizar-paginas-de-erro/|http://www.miguelborges.com/personalizar-paginas-de-erro/]]
  - [[http://www.vivaolinux.com.br/dica/Escondendo-a-versao-do-Apache|http://www.vivaolinux.com.br/dica/Escondendo-a-versao-do-Apache]]
  - [[https://wiki.apache.org/httpd/RedirectSSL|https://wiki.apache.org/httpd/RedirectSSL]]
  - [[https://wiki.apache.org/httpd/RewriteHTTPToHTTPS|https://wiki.apache.org/httpd/RewriteHTTPToHTTPS]]

Disponível em "[[https://wiki.tce.go.gov.br/index.php?title=Apache_Proxy&amp;oldid=605|https://wiki.tce.go.gov.br/index.php?title=Apache_Proxy&oldid=605]]"

[[:index|Categorias]]:

  * [[:index|Infraestrutura de TI]]
  * [[:index|Redes]]
  * [[:index|Servidores de Aplicação]]