proxy reverso
TRANSCRIPT
Fatec Ourinhos
Donizete Fidelis
PROXY REVERSO
OURINHOS (SP)
2013
DONIZETE FIDELIS
PROXY REVERSO
Trabalho de Graduação apresentado a
Faculdade de Tecnologia de Ourinhos para
conclusão do Curso de Segurança da
Informação.
Orientador: Prof. Alex Marino Gonçalves
de Almeida.
OURINHOS (SP)
2013
Dedico este trabalho aos meus pais, minha
namorada, cunhados e sobrinhos, pelo
incentivo, cooperação e apoio e, em
especial, à minha irmã Sônia e seu esposo;
pois, além de terem me acolhido durante
todo o curso, compartilharam comigo os
momentos de tristezas e também de
alegrias, nesta etapa, em que, com a graça
de Deus, está sendo vencida.
Primeiramente, agradeço a Deus, meu
mestre. Ao Prof. Alex Marino Gonçalves de
Almeida, pela sabedoria e atenção com
que conduziu a orientação este
trabalho.
RESUMO
Cada vez mais o mundo corporativo na área de TI caminha para os sistemas web, pela facilidade de serem sistemas híbridos, sendo executados a partir de qualquer dispositivo como: celulares, palms, notebooks, tablets e desktops, através de um navegador padrão. Com esta reviravolta do cenário de TI, uma grande demanda da estrutura de segurança é necessária. Pois os dados das empresa já não estarão mais somente para acesso interno das informações e sim de qualquer lugar do mundo onde disponha de um acesso à internet. Podendo também uma gama de tecnologias de diferentes sistemas operacionais e linguagens de programação terem que trabalhar juntas, deixando assim a administração muito complexa. Sendo assim será criado um cenário de testes para enfatizar estas informações e demostrar que com o Proxy Reverso é possível ter um ambiente eficaz e seguro, mostrando suas configurações sendo implementadas no Apache.
Palavras-Chave; Apache, Proxy Reverso, Segurança.
ABSTRACT
Increasingly, the corporate world in the area of IT walks for the web systems, due to the ease of being hybrids, running from any devices like: phones, palms, laptops, tablets and desktops, through a standard browser. With this twist on the IT scene, a great demand of the security structure is necessary. For the data of the company will no longer be available only to internal access of the information but from anywhere in the world in which you have an internet access. It may also have a range of technologies from different operating systems and programming languages have to work together, making the administration very complex. Thus a test scenario to emphasize this information will be created and demonstrate that with the reverse proxy it is possible to have a safe and effective environment, showing the settings being implemented in Apache.
Keywords; Apache, Reverse Proxy, Security.
LISTA DE FIGURAS
Figura 1: Ambiente Sem Proxy..................................................................................10
Figura 2: Ambiente Com Proxy..................................................................................11
Figura 3: Ambiente Geral com Proxy.........................................................................13
Figura 4: Proxy Convencional....................................................................................19
Figura 5: Proxy Convencional....................................................................................20
Figura 6: Ambiente Proxy Reverso siteexemplo.dyndns.info.....................................27
Figura 7: siteexemplo.dyndns.info/cadastro...............................................................30
Figura 8: siteexemplo.dyndns.info/cadastro/teste......................................................31
Figura 9: siteexemplo.dyndns.info/pedido..................................................................32
Figura 10: siteexemplo.dyndns.info/pedido/teste.......................................................33
Figura 11: Back Track 5r3..........................................................................................34
Figura 12: Armitage....................................................................................................35
Figura 13: Serviços.....................................................................................................36
Figura 14: Ataque.......................................................................................................36
LISTA DE ABREVIATURAS E SIGLAS
ASP: Active Server Pages. CRM: Customer Relationship Management. FTP: File Transfer Protocol. HTTP: HyperText Transfer Protocol. HTTPS: HyperText Transfer Protocol Secure. IDS: Intrusion Detection System IP: Internet Protocol. ISS: Internet Information Services. LAN: Local Area Network. NCSA: National Center for Supercomputing Applications. PHP: Personal Home Page. SGBD: Sistema de Gerenciamento de Banco de Dados. SO: Sistema Operacional. TI: Tecnologia da Informação. URL: Uniform Resource Locator. VM: Virtual Box.
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................................. 5
Objetivos ............................................................................................................................................. 6
Justificativa .......................................................................................................................................... 7
Metodologia ........................................................................................................................................ 8
2. APRESENTANDO O TERMO PROXY .................................................................................................. 9
2.1 Significado do Termo Proxy ........................................................................................................... 9
2.2 Demanda de Servidores Proxy .................................................................................................... 10
2.3 Cenário sem Proxy ....................................................................................................................... 11
2.4 Cenário com Proxy ...................................................................................................................... 11
3. SOLUÇÕES PROXY DISPONÍVEIS NO MERCADO. ........................................................................... 13
3.1 Squid ............................................................................................................................................ 14
3.2 Delegate ...................................................................................................................................... 15
3.3 Dansguardian .............................................................................................................................. 15
3.4 Oops ............................................................................................................................................ 16
3.5 Microsoft Forefront Threat Management Gateway 2010 .......................................................... 16
4. O PROXY REVERSO ........................................................................................................................ 18
4.1 Conceito de Proxy Reverso. ......................................................................................................... 19
4.2 Utilização de Proxy Reverso como servidores web. .................................................................... 20
4.3 Forma de Funcionamento do Proxy Reverso. ............................................................................. 21
4.4 Apache como Proxy Reverso. ...................................................................................................... 23
4.5 O que é Apache ........................................................................................................................... 23
4.6 Apache atuando como Proxy Reverso. ....................................................................................... 23
4.7 Benefícios do Proxy Reverso. ...................................................................................................... 24
5. IMPLANTAÇÃO E VULNERABILIDADE ............................................................................................ 26
5.1 O Ambiente. ................................................................................................................................ 26
5.2 Configurando o Proxy Reverso. ................................................................................................... 27
5.3 Testando o Proxy Reverso ........................................................................................................... 29
5.3.1 Testando siteexemplo.dyndns.info/cadastro ...................................................................... 29
5.3.2 Testando siteexemplo.dyndns.info/pedido ......................................................................... 31
5.4 Teste de Vulnerabilidade ............................................................................................................ 33
6. CONSIDERAÇÕES FINAIS ................................................................................................................ 38
7. REFERENCIAS ................................................................................................................................. 39
8. APÊNDICES .................................................................................................................................... 41
5
1. INTRODUÇÃO
Atualmente, os ambientes de TI apresentam cada vez mais complexidade em elaborar novos sistemas cada vez mais robustos e ao mesmo tempo uma portabilidade acessível a várias plataformas e com isso houve uma grande demanda em aplicações desenvolvidas para trabalhar em um servidor web, que com isto obtém-se uma portabilidade com sucesso acessível geralmente em todos os Sistemas Operacionais encontrados no mercado, que por sua vez disponibiliza o acesso aos clientes que suportam o protocolo HTTP.
Entre estas tecnologias, destacam-se atualmente três plataformas: JAVA, Microsoft .NET e Ruby on Rails.
E conforme estas tecnologias vem sendo mais utilizadas, uma gama de vulnerabilidades surgem e com isso o tripé da Segurança da Informação que vem a ser: a confidencialidade, integridade e disponibilidade. Vem a ser ameaçado, contudo novas tecnologias surgem para garantir que a segurança das informações estejam sempre protegidas. Como no caso os Servidores Proxy.
Em um ambiente cliente/servidor as atenções normalmente estão direcionadas para o servidor, onde residem as informações e, portanto foco de ameaças. Os clientes na Web estão fora de nossa guarda e assim fora do nosso controle. A proteção do cliente, não é o grande objetivo, a não ser quando se trata de sua privacidade. Segurança no servidor Web consiste, em geral, em um ponto crítico em relação para algumas organizações que tem a Web a sua principal fonte de renda ou como para seu trabalho, no caso em algumas corporações 24 horas por dia e sete dia por semana.
A partir de tantas tecnologias disponíveis no mercado em soluções web, fica cada vez mais difícil de realizar um padrão de segurança da informação em cima dos serviços, pois cada tecnologia trabalha de um modo diferente e com isso brechas na segurança podem ocorrer normalmente, tornando a administração destes sistemas muito difícil para os administradores de redes.
Pois este cenário causa muito trabalho, ou seja, gera um alto nível de
complexidade nas organizações que tem que manter estes sistemas atualizados e
protegidos.
6
Objetivos
Este trabalho tem como principais objetivos, apresentar os Servidores Proxy existentes e as diferença entre Servidor Proxy Cache e Servidor Proxy Reverso.
Também mostrar em um Ambiente Web, algumas análises sobre a segurança que um Servidor Proxy Reverso vem a exercer em um ambiente que utilize soluções web.
Este trabalho tem como objetivo específico, mostrar os benefícios de uma
corporação implementar um servidor Proxy Reverso para suas aplicações que utilizam
serviços web. O cenário abaixo descrito será utilizado para implantação:
Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, onde será
implantado o Proxy Reverso;
Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, ao qual será um
servidor de aplicação;
Windows 2008 Server Standard rodando o ISS com páginas ASP, ao qual
será um servidor de aplicação;
Suponhamos que este Servidor Windows esteja configurado e estão em
produção, só que com IP não roteável, ou seja, somente na rede interna.
A empresa necessita ter acesso externo a estes Servidores Windows e
CentOS que rodam suas aplicações, porem possui somente um IP público, com isso
o Apache que está rodando no Linux CentOS tem o um domínio válido e pode ter
acesso externo. Será usado o domínio de www.siteexemplo.dyndns.info como
exemplo.
A partir deste cenário será utilizado o Apache como Proxy Reverso para que
quando o Servidor de ISS ou do Apache receber alguma solicitação externa, o Proxy
Reverso, libere somente o acesso a uma porta específica. Ficando assim protegidos
quanto a ataques que poderiam interromper os serviços da mesma.
A estrutura desse trabalho se dará da seguinte forma: O presente documento encontrara-se divido em 7 (sete) capítulos: introdução, apresentando o termo Proxy, conhecendo algumas soluções, Proxy reverso, implantação do Proxy reverso, conclusão, e referências.
7
No primeiro capítulo apresenta-se a introdução fazendo um apanhado geral do tema, descrição dos objetivos, justificativa do trabalho, a metodologia que será utilizada e a explicação sobre a estrutura do trabalho.
Sobre o segundo capítulo aborda-se de um modo geral o conceito de Proxy.
No terceiro capítulo, algumas soluções de Servidores Proxy serão apresentadas.
O quarto capítulo, submete as funcionalidade de um Servidor Proxy Reverso e os benefícios que o mesmo proporciona em um ambiente web.
O quinto capítulo será apresentado um cenário com o Proxy Reverso Implementado e com algumas ferramentas de análise de vulnerabilidades do mercado, veremos como o mesmo se comporta e a qual nível se consegue analisar as informações do servidor.
No sexto capítulo, argumentam-se as considerações finais fazendo uma síntese e um apanhado geral dos pontos mais importantes dos capítulos anteriores, de maneira a reforçar a ideia da utilização de um Servidor Proxy Reverso garantindo assim maior segurança ao ambiente.
Enfim, no sétimo capítulo serão citadas as referências da pesquisa do
trabalho.
Justificativa
Este trabalho mostrara a segurança que um Servidor Proxy Reverso tende a
criar em um ambiente que necessite de acesso externo, não adianta somente
implantar um Servidor de Firewall como principal fonte de proteção, pois a maioria dos
firewalls do mercado faz a filtragem de pacotes somente em cima de alguns campos
como exemplo no cabeçalho IP de origem, IP destino, porta origem, porta destino.
Se for autorizado o acesso a alguma porta específica do servidor, o mesmo
deixa o pacote passar, sem se preocupar com as informações contidas dentro que
poderia ser um ataque de algum hacker a um determinado serviço web da empresa e
com isto poderia causar a paralisação dos serviços, roubo de informações, alteração
8
de dados e outros problemas que podem ocorrer com o acesso indevido das
informações.
Metodologia
Para conseguir atingir os objetivos apresentados, este trabalho, uma vez
embasado em publicações como livros, artigos científicos e sites específicos, serão
apresentadas algumas tecnologias sobre Proxy.
Feito isso, irá tratar da segurança que um Servidor Proxy Reverso em um Ambiente Web proporciona, que é justamente o motivo ao qual se justifica este trabalho.
O cenário todo será elaborado e criado com máquinas virtuais utilizando a
tecnologia Oracle VM Virtual Box, ao qual serão feitas as instalações dos devidos
S.Os, configurações e seus devidos testes para comprovar a segurança que o Proxy
Reverso vem a agregar.
No último capítulo, serão feitas considerações finais para reforçar e justificar
tudo aquilo já demonstrado através das ideias e pensamentos já desenvolvidos ao
longo do trabalho.
9
2. APRESENTANDO O TERMO PROXY
Proxy é um servidor que atende a requisições repassando os dados a outros
servidores. Um usuário (cliente) conecta-se a um Servidor Proxy, requisitando algum
serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro
servidor.
O Proxy surgiu da necessidade de conectar uma rede local à Internet através
de um computador da rede que compartilha sua conexão com as máquinas da rede.
Se considerarmos que a rede local é uma rede interna e a Internet é uma rede externa,
podemos dizer que o Proxy é quem permite que outras máquinas tenham acesso
externo, ou seja, a conexão com a Internet. Geralmente, máquinas da rede interna
não possuem endereços válidos na Internet, primeiro pelo fato da segurança nas
redes privadas e também devido à falta de IP’s válidos, portanto, não têm uma
conexão direta com a Internet. Assim, toda solicitação de conexão de uma máquina
da rede local para um host da Internet é direcionada ao Proxy, este, por sua vez,
realiza o contato com o host desejado, repassando a resposta da solicitação para a
máquina da rede local. É comum termos o Proxy como conexão direta com a Internet.
2.1 Significado do Termo Proxy
Na área de TI, Proxy significa um programa ou um serviço que faz o papel de intermediário entre o cliente e o servidor, para acessar um determinado serviço.
Sobre estes aspectos de Servidor Proxy podemos nos remeter a Morimoto:
Um dos usos mais comuns e mais simples para um servidor Linux de rede local é simplesmente compartilhar a conexão. A vantagem de usar um servidor dedicado ao invés de simplesmente compartilhar usando o próprio modem ADSL é que você pode incluir outros serviços, como um cache de páginas (Squid), filtro de conteúdo (SquidGuard ou DansGuardian), firewall, servidor Samba (compartilhando arquivos com a rede interna), servidor de impressão e assim por diante. (2008, p.75).
10
O Proxy pode ser utilizado para várias aplicações como HTTP, HTTPS, FTP
e outros, fazendo seu trabalho de interceptar as informações trafegadas e liberando
as informações ao cliente ou as negando.
Sob estas expectativas:
O objetivo principal de um servidor proxy é possibilitar que máquinas de uma rede privada possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação direta com esta. O servidor proxy costuma ser instalado em uma máquina que tenha acesso direto à internet, sendo que as demais efetuam as solicitações através desta. Justamente por isto este tipo é chamado de Proxy, pois é um procurador, ou seja, sistema que faz solicitações em nome de outros. (ZANONI, 2007).
2.2 Demanda de Servidores Proxy
Para melhor análise podemos nos remetemos a Nakamura:
A tecnologia da informação é um instrumento cada vez mais utilizado pelo homem, que busca incessantemente realizar seus trabalhos de modo mais fácil, mais rápido, mais eficiente e mais competitivo, produzindo, assim, os melhores resultados. A rede é uma das principais tecnologias, permitindo conexões entre todos os seus elementos, que vão desde roteadores até servidores que hospedam o website da organização e o banco de dados dos clientes, passando ainda por sistemas financeiros, de pagamentos e Customer Relationship Management (CRM). Esses recursos disponibilizados pela rede representam, na Era da informação, até mesmo o próprio negócio das organizações. Isso faz com que sua flexibilidade e facilidade de uso resultem de uso resultante em maior produtividade e na possibilidade de criação de novos serviços e produtos, e consequentemente em maiores lucros para a organização. (2010, p. 43).
A exploração de vulnerabilidades em aplicações que usam ambientes web
aumenta a cada dia. Pois o número de vulnerabilidades aumenta de segundo em
segundo com o crescimento da TI.
[...] Vulnerabilidades – foram registradas 1.432 novas vulnerabilidades, um crescimento em torno de 12% do total conferido no ano de 2002. 80 % das vulnerabilidades são exploradas remotamente, o que incrementou as ameaças de alto risco em 6%, e as de médio risco em, 24%. As vulnerabilidades em aplicações web cresceram 12% quando comparadas ao mesmo período do ano passado. Novamente, os sistemas Microsoft tiveram um grande número de vulnerabilidades exploradas, e também erros introduzidos em códigos de programas como Apache, Sendmail e OpenSSH. (PEIXOTO, 2003).
E a cada ano mais e mais estes números tem tido um alto crescimento.
Perante estas ameaças o interessante para as empresa não é somente investir em
um servidor firewall, mais sim também em um servidor Proxy.
11
2.3 Cenário sem Proxy
Na figura 1, mostra-se um exemplo clássico de uma rede, que está presente na maioria dos cenários e muitas vezes em empresas. Os clientes da rede tem total contato diretamente com a Internet, sem nenhum controle e nenhuma análise do tráfego dos pacotes que por ali trafegam.
Figura 1: Ambiente Sem Proxy.
Fonte: Autor.
2.4 Cenário com Proxy
Na figura 2, mostra-se um exemplo básico de um servidor Proxy para serviço
de controle de tráfego da Internet em uma rede, usando o Squid. Os clientes da rede
interna não tem contato diretamente com a Internet.
12
Figura 2: Ambiente Com Proxy.
Fonte: Autor.
As requisições vão todas para o Servidor Proxy que verifica todo o trafego,
assim fazendo seu papel de autorizar ou restringir o acesso à determinada página da
web.
No próximo capitulo deste trabalho será apresentado um breve resumo sobre
alguma das principais tecnologias disponíveis no mercado.
13
3. SOLUÇÕES PROXY DISPONÍVEIS NO MERCADO.
Atualmente existem vários softwares com as características de Proxy, alguns
mais especializados em somente alguns protocolos, outros com mais funcionalidades,
em especial para o sistema operacional Linux e também algumas ferramentas para o
Sistema Operacional Windows, com pelo menos suporte à HTTP, HTTPS.
Geralmente uma infraestrutura é apresentada conforme figura 3.
Figura 3: Ambiente Geral com Proxy.
Fonte: Oficina da Net.
Segue abaixo um breve resumo de variadas formas que um Proxy pode atuar
e algumas orientações segundo REIS at al:
Web Proxy: Existe, ainda, um outro tipo de Proxy, os web proxies. Eles são uma versão que esconde o seu IP real e lhe permite navegar anonimamente. Muitos deles são utilizados em redes fechadas como universidades e ambientes de trabalho para burlar uma determinação de bloqueio a alguns sites da internet. Os conteúdos campeões de bloqueio são: sites de relacionamento (Orkut, facebook e outros), programas de troca de mensagem instantânea (Msn Messenger, Yahoo! Messenger e outros), sem contar os tão proibidos sites de pornografia.
Open Proxy: As conexões abertas de Proxy (open proxy) são o tipo mais perigoso e convidativo aos crackers e usuários mal intencionados. Quando um destes usuários consegue acessar um computador, instala um servidor Proxy nele para que possa entrar quando quiser na máquina e promover diversos tipos de ilegalidade
14
como scripts que roubam senhas de bancos, fraudes envolvendo cartões de crédito e uma grande variedade de atos ilegais.
Redes Proxy: As redes Proxy são baseadas em códigos cifrados que permitem a comunicação anônima entre os usuários. Exemplo deste tipo de rede são as conexões P2P (peer to peer) em que um usuário se conecta ao outro sem saber sua identidade e trocam arquivos entre si. Estas redes se caracterizam por não permitirem o controle dos servidores, os usuários comuns é quem providenciam todo o conteúdo e os arquivos. Certamente, muitos destes computadores são usados por pessoas mal intencionadas com segundas intenções. Por isso, deve-se ter em mente que qualquer promessa de privacidade e segurança é mais do que rara. (REIS at al, 2007).
Conforme citado por Thoeny (2002, apud REIS at al, 2007) “destaca-se Squid,
Delegate, Dansguardian, Oops entre outros”.
3.1 Squid
Praticamente um dos Proxy mais utilizado no mundo.
Foi originado de um projeto denominado Harvest entre o governo americano
e a Universidade de Colorado. Atualmente é o Proxy mais popular e mais usado como
controle de conteúdo, na qual possui vários programadores como desenvolvedores
do projeto pelo mundo. É geralmente disponibilizado por padrão pela maioria dos
sistemas operacionais Linux, fornecendo todas as funcionalidades de um Proxy
comum. Permite atuar como Proxy para os protocolos HTTPS, HTTP, FTP.
Sua principal utilidade é de filtrar e definir regras para o acesso à web, sua
principal vantagem vem a função cache, a mesma guarda no cache os sites
acessados, quando o acesso a um site presente no cache é solicitado,
automaticamente é retornado ao usuário o site do cache. (VILELLA, 2010).
Tornando assim a resposta ao usuário muito mais rápida e eficiente e também uma
economia de banda.
15
3.2 Delegate
Este também é um Proxy interessante, O Delegate interliga uma comunicação
entre usuários e clientes, onde uma comunicação direta é impossível, ineficiente, ou
inconveniente.
Perante Sato:
Delegate é um multi - propósito de gateway em nível de aplicação, ou um servidor proxy que funciona em várias plataformas (Unix, Windows, MacOS X e OS / 2). Delegate mede a comunicação de vários protocolos (HTTP, FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, SOCKS, DNS, etc.), a aplicação de cache e conversão de dados, que controlam o acesso de clientes e o encaminhamento para os servidores. Ele traduz protocolos entre clientes e servidores, aplicando SSL (TLS) para protocolos arbitrários, convertendo entre IPv4 e IPv6, mesclando vários servidores em um único servidor com analise e filtragem. Nascido como um proxy pequeno para Gopher março 1994, tem crescido constantemente em um servidor de propósito geral proxy. Além de ser um proxy, delegate pode ser usado como um servidor de origem simples para alguns protocolos (HTTP, FTP e NNTP). (SATO, 2010).
3.3 Dansguardian
É uma ferramenta capaz de filtrar acessos a Internet com base em diferentes
critérios.
Segundo palavras de Reis:
A ferramenta difere da maioria disponível no mercado pelo fato de não funcionar apenas como filtro de URL, mas também como um efetivo filtro de conteúdo de páginas Web. Pois, faz uma varredura do conteúdo de cada página acessada por seus usuários e não somente uma liberação ou proibição do nome do site ou da URL acessada. Este filtro de conteúdo funciona em conjunto com qualquer Proxy, podendo ser instalado em sistemas operacionais Linux, FreeBSD, OpenBSD, NetBSD, Mac OSX e Solaris.O Dansguardian não tem características de Proxy, portanto é obrigatório o uso de um servidor Proxy para que a ferramenta seja implementada, embora ele tenha sido citado neste trabalho por ser relevante suas funções. Nas soluções comumente encontradas no mercado, o filtro de conteúdo recebe as requisições
16
do navegador do usuário, aplica as restrições estabelecidas ou as exceções configuradas e, em seguida, passa a requisição para o Proxy. Este faz o seu papel que é a intermediação entre o cliente e o servidor a ser acessado. No processamento interno de arquivos contendo proibições e exceções, existe uma ordem pré-estabelecida. Apesar do Dansguardian não ter características de Proxy o mesmo foi citado apenas para fim de conhecimento, uma vez que o objetivo deste trabalho é demonstrar os diversos tipos de aplicações para otimização do Proxy Squid, procurando a melhor solução para desempenho do mesmo tornando-o tão eficiente quanto o Dansguardian no processo de filtro de conteúdos, pois quando o Squid utiliza uma base muito extensa (Black-list), consequentemente passa a utilizar muita memória e se torna lento demais sobrecarregando consideravelmente a rede. (REIS, 2007)
3.4 Oops
É um Proxy mais simples que os anteriores. Surgiu como uma alternativa ao
uso do Squid. Oops é leve, embora, trata-se de um poderoso Proxy com cache e com
grandes características como: HTTP/1.1, FTP. Está pronto para ser usado
imediatamente após iniciado; seus armazenamentos em disco são checados em
segundo plano, enquanto servem pedidos diretamente da rede; seus arquivos de
configuração são fácies de ler e entender, controla a largura da banda de dados,
possui um vasto modulo para a geração de logs. (REIS, 2007).
Tornando se assim um Proxy muito prestativo perante o seu funcionamento.
3.5 Microsoft Forefront Threat Management Gateway 2010
Solução que a Empresa Americana mundialmente conhecida Microsoft, criou
para seus clientes corporativos uma solução de Proxy semelhante à os de licença
GNU (Software Livre).
Forefront Threat Management Gateway 2010 é um portal web seguro que
oferece proteção abrangente contra ameaças baseadas na web, integrando múltiplas
camadas de proteção em um sistema unificado, uma solução fácil de usar. Forefront
17
TMG permite que os usuários usem de forma segura e produtiva a Internet para
negócios sem se preocupar com ameaças de malware e outros.
O Forefront TMG solução inclui dois componentes:
• Forefront Threat Management Gateway 2010 Server: Fornece
filtragem de URL, inspeção antimalware, prevenção de intrusão, firewall
de aplicação e de camada de rede e HTTP / HTTPS inspeção em uma
única solução.
• Forefront Threat Management Gateway Serviço de Proteção
Web: Fornece atualizações contínuas para filtragem de malware e
acesso a tecnologias baseadas em nuvem filtragem de URL agregados
de múltiplos fornecedores de segurança da Internet para proteger contra
as mais recentes ameaças baseadas na Web.
18
4. O PROXY REVERSO
Segundo Filho:
Um Proxy reverso tem como objetivo principal prover segurança ao servidor, evitando que os clientes tenham contato direto com ele. Todo servidor deve ter um Proxy reverso à sua frente. (FILHO, 2008).
Um Proxy Reverso é um servidor de rede geralmente instalado para ficar na
frente de um servidor Web. Todas as conexões originadas externamente são
endereçadas para um dos servidores Web através de um roteamento feito pelo
servidor Proxy, que pode tratar ele mesmo a requisição ou, encaminhar a requisição
toda ou parcialmente a um servidor Web que tratará a requisição.
Podendo também bloquear por completo o pacote ao qual está sendo
recebido pelo servidor, caso este seja algum possível ataque ou acesso indevido das
informações.
Um Proxy Reverso repassa o tráfego de rede recebido para um conjunto de
servidores, tornando-o a única interface para as requisições externas. Por exemplo,
um Proxy Reverso pode ser usado para balancear a carga de um cluster de servidores
Web. O que é exatamente o oposto de um Proxy convencional que age como um
despachante para o tráfego de saída de uma rede, representando as requisições dos
clientes internos para os servidores externos a rede a qual o servidor Proxy atende.
Sob esta perspectiva Macedo alega que:
Proxy Reverso nada mais é do que um servidor “burro” que apenas
recebe requisições e delega as mesmas ou então faz algo simples,
como devolver uma página pré-processada, mas ele é “burro” não
sabe executar aquela requisição por completo, ele é um Proxy não é
o servidor de verdade. (MACEDO, 2012).
19
4.1 Conceito de Proxy Reverso.
O termo “Proxy é um termo em inglês que significa fazer algo em favor de
alguém” (NETO, 2009).
Enquanto um Proxy, no modelo convencional, intercepta requisições
originadas na rede local (LAN – Local Área Network) com destino à Internet, um Proxy
Reverso intercepta requisições originadas na Internet com destino à rede local.
O trabalho exercido tanto por um Proxy convencional quanto por um Proxy
reverso é o mesmo: acessar o conteúdo que está sendo requisitado pelas máquinas
clientes, impedindo que estas se comuniquem diretamente com o servidor que
armazena tal conteúdo, resguardando assim, a identidade das máquinas clientes. O
que diferencia os dois modelos de Proxy é onde o cliente está localizado, pois, no
modelo utilizando Proxy convencional, o cliente se encontra dentro da rede interna e
já no Proxy Reverso, o cliente está conectado à Internet.
A figura 4 mostra uma topologia de rede onde é utilizado um Proxy
convencional para fornecer acesso web para as máquinas clientes conectada na rede
local.
Figura 4: Proxy Convencional.
Fonte: Oficina da Net.
20
O funcionamento do Proxy convencional apresentado na figura 4 é descrito
no “Capítulo 2.4 - Cenário com Proxy”.
Na figura 5 é apresentada uma topologia de rede que utiliza a estrutura de
Proxy Reverso para permitir o acesso a partir da Internet a servidores web que estão
conectados dentro de uma rede local.
Figura 5: Proxy Convencional.
Fonte: Diego Macedo – Analista de TI.
Os próximos tópicos deste capítulo descrevem com maiores detalhes, o
cenário apresentado na figura 5 e quais são as vantagens em sua utilização.
4.2 Utilização de Proxy Reverso como servidores web.
O Proxy Reverso é muito bem utilizado em uma topologia de rede quando é
apresentado o cenário que Lopes comenta:
Para que o Proxy Reverso consiga interceptar as requisições originadas na Internet e repassá-las aos servidores web que estão conectados na rede interna, é necessário que ele funcione como um servidor web, ou seja, o Proxy deve se passar por um servidor web
21
para conseguir centralizar todas as requisições e esconder, para quem está acessando a partir da Internet, informações pertinentes a rede local. Da mesma maneira que o Proxy convencional oculta para os servidores web na Internet, informações sobre as estações na rede local, o Proxy Reverso oculta para as máquinas clientes que estão na Internet, informações sobre os servidores web que estão conectados na rede local. (2006, p. 31).
Tornando assim um servidor seguro.
As máquinas dos clientes, que estão na Internet, se conectam ao servidor
Proxy Reverso como se ele fosse o próprio servidor web e o encaminham para o
verdadeiro servidor web, sendo assim realizado de maneira transparente pelo Proxy,
para a máquina cliente, sem que o próprio cliente imagine. (LOPES, 2006).
4.3 Forma de Funcionamento do Proxy Reverso.
De acordo com Lopes (2006), o Proxy Reverso mantém um bom
funcionamento perante algum passos seguidos e uma boa configuração. Para que o
Proxy Reverso possa se comportar como um servidor web fiel e fazer o correto
direcionamento das requisições para os servidores web que realmente hospedam o
conteúdo requisitado, as seguintes atividades precisam ser realizadas para uma
topologia segura.
• Mapeamento da URL requisitada: a máquina cliente faz a
requisição assumindo que o Proxy Reverso é o servidor web. Antes que
o Proxy possa repassar a requisição para o servidor Web interno, a URL
da requisição precisa ser convertida (mapeada) para refletir a URL do
servidor interno;
• Adequação de campos no cabeçalho da requisição: assim como
acontece com a URL, alguns campos no cabeçalho HTTP também
precisam ser reescritos para que possam referenciar corretamente ao
servidor web interno. Um destes campos é o “host” que é responsável
22
por transportar o host name e o número da porta da máquina que
hospeda o recurso que está sendo requisitado
Lopes (2006) ainda enfatiza as seguintes características descritas logo
abaixo:
• Podem ainda ser configuradas em um servidor Proxy Reverso,
com o objetivo principal de reforçar a segurança do ambiente, garantindo
o controle e registro de todo o tráfego que está sendo recebido e
transmitido a partir do Proxy.
• Validação do conteúdo requisitado: todas as requisições
submetidas ao Proxy Reverso são inspecionadas a fim de certificar de
que nenhum conteúdo malicioso está sendo transmitido.
• Validação do conteúdo de resposta que são obtidas do servidor
web também precisam ser verificadas pelo Proxy reverso antes que ele
as repasse para as máquinas clientes. Essa funcionalidade é utilizada
para bloquear respostas que não precisam ser visualizadas. E que
podem revelar informações da topologia da rede onde se encontra os
servidores internos a um suposto intruso evitando assim um vazamento
de informações vitais para a segurança. Todos os filtros são
armazenados em um banco de dados que é consultado constantemente
pelo Proxy Reverso.
• Por último o registro em log das requisições dos clientes e
respostas do servidor: toda a comunicação que é interceptada pelo
Proxy Reverso é registrada em arquivos de log que podem ser utilizados
para analisar o conteúdo que está sendo requisitado e respondido pelo
Proxy. Estes arquivos de log são úteis para que os administradores de
rede consigam ter um controle e acompanhamento das informações que
estão sendo disponibilizadas para a Internet, além de facilitar a
identificação de possíveis incidentes.
23
4.4 Apache como Proxy Reverso.
Neste subcapitulo será apresentado o modo de funcionamento do Apache
como Proxy Reverso, ao qual será utilizado para as comparações de teste de intrusão
no Capitulo Cinco (5).
4.5 O que é Apache
Para termos uma análise mais concreta nos remetemos a Kabir 2002: O
apache é um Servidor Web altamente configurável, modular, simplesmente fácil de
configurar e mais ainda de entender seus mais variados recursos. Qualquer pessoa
com um pouco de experiência em programação C ou Perl já pode executar várias
funções com o mesmo, o mais importe é que ele é gratuito e aberto para
desenvolvimento, funcionando muito bem com Perl, PHP e outras linguagens de
scripts.
Seu funcionamento perante aos S.Os Linux e outros sistemas como FreeBSD,
Solaris, Mac OS e também o Windows.
Criado pela NCSA no início de 1995 e até os dias de hoje se encontra entre
os melhores servidores para Web.
4.6 Apache atuando como Proxy Reverso.
Entre as várias funções do Apache, ele também pode atuar como um Proxy
Reverso fazendo assim a segurança de todos os Servidores Web.
Segundo Kabir:
24
Quando esse tipo de servidor Proxy é usado, os usuários normalmente não estão cientes deles, porque imaginam que estão acessando o recurso pretendido. Todas as solicitações feitas pelos usuários são enviadas ao Proxy reverso, que serve a resposta a partir de seu cache ou solicitando informações de outro host. (2002, p. 287).
Perante informações alegadas por Teixeira:
Suponha que exista um servidor chamado www.siteexemplo.dyndns.info, e
que você tenha uma pasta neste domínio chamada Cadastro que está hospedada em
sua rede interna com o IP 192.168.1.112 onde o mesmo não terá acesso a rede
externa, somente a Intranet. O Proxy Reverso através do comando ProxyPass
/cadastro http://192.168.1.112/cadastro, o transformando em
http://www.siteexemplo.dyndns.info/cadastro.
Fazem com que o Apache ajuste a URL com as peculiaridades do pacote
HTTP como se ele fosse location, ajustando assim seus headers, sendo assim quando
há uma requisição o endereço http://www.siteexemplo.dyndns.info/cadastro vai ser
internamente convertido para uma requisição de Proxy para
http://192.168.1.112/cadastro, acontecendo a mesma coisa quando houver o inverso.
Para o usuário ele estará na máquina siteexemplo.dyndns.info, mais na realidade sem
perceber será direcionado para a máquina 192.168.1.112
Tornando assim um ambiente muito seguro para as aplicações.
4.7 Benefícios do Proxy Reverso.
Seus benefícios são inúmeros perante servidores web, tanto na segurança
como na administração, tornando os bem seguros e estáveis, protegendo suas
informações e privacidades contidas nos servidores. Conforme descrito nos capítulos
anteriores, é a única interface para as requisições externas.
Conforme Silva coloca como seus benefícios:
Roteamento de requisições externas;
Segurança: como o Proxy é a única interface externa da rede, ele "esconde" os demais servidores;
25
Criptografia: a criptografia SSL pode ser delegada ao proxy ao invés dos servidores internos;
Balanceamento de carga: o servidor pode distribuir a carga para vários servidores da rede;
Cache: assim como o web proxy, o Proxy Reverso pode manter em cache o conteúdo estático das requisições realizadas, ajudando assim a diminuir a carga dos servidores web;
Compressão: o Proxy Reverso pode tornar o acesso mais rápido através da compressão do conteúdo acessado. (SILVA, 2011).
Trazendo assim estes benefícios ao ambiente ao qual o Proxy Reverso está
atuando. No próximo capitulo será apresentado um ambiente e ao qual serão
realizados alguns testes de penetração com alguns softwares do mercado.
26
5. IMPLANTAÇÃO E VULNERABILIDADE
Conforme foram apresentadas as informações sobre o Proxy Reverso nos
capítulos anteriores, neste capitulo será abordada a configuração de um ambiente e
também de testes de vulnerabilidade.
Mostrando no final como a aplicação se comportara e o que a mesma irá
expor.
Segundo Giavaroto (2012) a identificação de vulnerabilidades, reduzem
custos, retornos de investimentos, adoção de políticas com o intuito de fortalecer a
segurança e o comprometimento da informação avaliando assim a segurança dos
dispositivos e seus respectivos dados.
5.1 O Ambiente.
O ambiente para configurações e testes do Proxy Reverso será todo feito em
maquina virtuais com o Virtual Box 4.2, sendo criado o cenário com três Servidores
abaixo descritos:
� Server 1: Servidor Proxy Reverso
Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, onde será
implantado Apache 2.2 sendo configurado como Proxy Reverso, sendo configurado o
DNS para acesso externo (siteexemplo.dyndns.info) sendo seu IP da Intranet
192.168.1.111.
� Server 2: Servidor de Aplicação de Cadastro
Apache 2.2 instalado em S.O Linux CentOS versão 6.4, ao qual será um
servidor de aplicação, rodando Apache 2.2, ao qual terá somente acesso à Intranet
sendo seu IP 192.168.1.112.
27
� Server 3: Servidor de Aplicação de Pedidos
Windows 2008 Server Standard rodando o ISS 7, ao qual será um servidor de
aplicação, tendo somente acesso à Intranet sendo seu IP 192.168.1.113.
Abaixo segue uma imagem do cenário que será usado para implantação do
Proxy Reverso.
Figura 6: Ambiente Proxy Reverso siteexemplo.dyndns.info.
Fonte: Autor.
5.2 Configurando o Proxy Reverso.
Conforme especificado o cenário, agora é chegada a hora de pôr todas estas
informações em pratica.
Depois de configurado toda a parte de Infraestrutura do servidor, é instalado
o Apache 2.2 no Servidor CentOS ao qual recebera a configuração do Proxy Reverso.
O próximo passo será configurar o Apache para atuar como Proxy Reverso.
28
As alterações são feitas todas no arquivo de configuração do Apache, que é
encontrado no diretório “ /etc/httpd/conf/httpd.conf ”.
Procurar pelo trecho abaixo, descomentar as linhas necessárias e fazer suas
devidas alterações.
� “ProxyRequests Off”
Caso esta linha fique como “ProxyRequests On” habilitara uma
vulnerabilidade de segurança pro servidor, pois habilita o servidor proxy pra fazer
solicitações a outros servidores, ou seja, alguém poderá usar seu Servidor como um
Proxy geral habilitado através do seu site.
Abaixo uma, se não a mais importante alteração a ser feita no arquivo.
� <IfModule mod_proxy.c>
� ProxyRequests Off
� #
� <Proxy *>
� Order deny,allow
� # Deny from all
� Allow from all
� </Proxy>
�
� #
� # Enable/disable the handling of HTTP/1.1 "Via:" headers.
� # ("Full" adds the server version; "Block" removes all outgoing Via:
headers)
� # Set to one of: Off | On | Full | Block
� #
� ProxyVia On
Estas linhas não comentadas acima ativam o serviço do Apache e o
transformam em um Servidor Apache Proxy Reverso. Ao qual refere-se ao tema que
estamos abordando.
29
Logo mais abaixo da configuração acima descrita é feita a configuração de
quais Servidores da rede interna o Proxy Reverso dará acesso a aplicação de um
modo para o acesso externo, no caso abaixo quando alguma requisição chegar ao
servidor com o endereço “siteexemplo.dyndns.info/cadastro” o mesmo será
redirecionado para o servidor na rede interna 192.168.1.112, e o mesmo acontece
para o endereço “siteexemplo.dyndns.info/pedido” que também será redirecionado
para o servidor na rede interna 192.168.1.113.
� #Configuracao Proxy Reverso
� ProxyPass /cadastro http://192.168.1.112
� ProxyPassReverse /cadastro http://192.168.1.112
� ProxyPass /pedido http://192.168.1.113
� ProxyPassReverse /pedido http://192.168.1.113
Feitas estas modificações o próximo passo é salva-las e reiniciar o serviço do
Apache, para o mesmo se tornar um Proxy Apache Reverso.
Para isso é informado o comando:
� service httpd restart
Após reiniciar o serviço, se as configuração estiverem corretas e os outros
servidores da rede interna estiverem corretamente configurados e respectivamente
suas aplicações inicializadas, o Proxy Reverso estará em pleno funcionamento.
5.3 Testando o Proxy Reverso
Neste momento depois de configurado o Proxy Reverso é chegada a hora de
realizar alguns testes de ver se o mesmo está em pleno funcionamento.
5.3.1 Testando siteexemplo.dyndns.info/cadastro
Primeiro será testado o Servidor de Cadastro, para isso é digitado na barra de
endereços do navegador o respectivo endereço “siteexemplo.dynnds.info/cadastro”.
30
Pode se verificar na figura 7, que a página que está localizado no Servidor
192.168.1.112 abriu como “siteexemplo.dyndns.info/cadastro”.
Figura 7: siteexemplo.dyndns.info/cadastro.
Fonte: Autor.
Para confirmar que o Proxy Reverso está em execução, será solicitada uma
página ao qual não existe no Servidor de Cadastro e este servidor terá que responder
corretamente a requisição.
31
Figura 8: siteexemplo.dyndns.info/cadastro/teste.
Fonte: Autor.
Como se pode ver ao solicitar a página
siteexemplo.dyndns.info/cadastro/teste, o mesmo retorna a página de Error 404, ao
qual refere-se a página de objeto não encontrado do Apache 2.2, que está em
execução no IP 192.168.1.112 ao qual é o Servidor de Cadastro.
5.3.2 Testando siteexemplo.dyndns.info/pedido
O mesmo processo realizado no subtítulo 5.3.1 acima será executado com o Servidor
de Pedido siteexemplo.dyndns.info/pedido
32
Figura 9: siteexemplo.dyndns.info/pedido.
Fonte: Autor.
Depois de analisar que o mesmo está em pleno funcionamento, veremos se
o mesmo reponde com a página de Erro do ISS 7 do Windows Server 2008, solicitando
uma página que não existe no respectivo servidor.
33
Figura 10: siteexemplo.dyndns.info/pedido/teste.
Fonte: Autor.
Novamente com sucesso é apresentado a página de erro do ISS 7,
concretizando assim os teste de implantação do Servidor Proxy Reverso.
5.4 Teste de Vulnerabilidade
Para concluir este capitulo, iniciara-se um teste de vulnerabilidade para
confirmar a segurança que o Proxy Reverso proporciona na proteção de Servidores
de Aplicações para Web.
A ferramenta para teste escolhida será o S.O Linux Back Track 5r3, uma
versão de Linux baseado no Ubuntu, ao qual é focado em teste de segurança e teste
de penetrações, muito bem apreciado por hackers e analistas de segurança da
informação.
34
Figura 11: Back Track 5r3.
Fonte: Autor.
E ao qual esta ferramenta é bem completa, já é incorporada o METASPLOIT,
que é uma solução incorporada com vários código maliciosos (exploits) preparados
para testar e analisar se algum host está vulnerável a ataques.
O exploits usado será o Armitage, este é um exploit ao qual vare host de
Aplicações Web e analisa suas respectivas portas, hosts internos e os serviços que
estão sendo executados.
Veremos se essa ferramenta consegue localizar os servidores internos de
cadastro e pedido.
35
Figura 12: Armitage.
Fonte: Autor
Como pode se ver na figura 12, foi adicionado o host siteexemplo.dyndns.info,
o exploit varreu toda a rede conseguindo assim o IP externo e o IP interno ao qual
está instalado o Proxy Apache Reverso, sendo visto que o mesmo não conseguiu
localizar as outras maquinas, pois elas não tem acesso externo sendo somente
através do proxy reverso ao qual libera os acessos as aplicações.
No próximo comando verifica-se os serviços e as portas que host disponibiliza
e ao qual por onde ele irá verificar as vulnerabilidades.
36
Figura 13: Serviços.
Fonte: Autor
O próximo passo é o ataque ao host, verificado assim se existe alguma
vulnerabilidade e a penetração a os servidores da rede interna.
Figura 14: Ataque.
Fonte: Autor
37
Se vê na figura 14 que o Armitage executara vários exploits e não obteve
sucesso em nenhum deles, os resultados se encontram em anexo para maiores
informações e análises de que o Proxy Reverso proporciona um ambiente seguro para
as aplicações web.
38
6. CONSIDERAÇÕES FINAIS
O estudo realizado neste trabalho demonstrou a criação de ambiente com o
Proxy Reverso, confirmando que o mesmo trouxe uma segurança aos sistemas web,
mostrando que não é possível ver os servidores internos e trazendo também uma
ótima facilidade para os usuários.
Atualmente cada vez mais os sistemas estão sendo migrados para a Web,
necessitando assim maior segurança, e o Proxy Reverso proporciona está segurança
que estava faltando.
Como confirma Gartner Group, mais da metade de todos os problemas na
internet estão relacionadas as aplicações web.
Desde ferramentas gratuitas que podem ser baixadas na internet até
ferramentas de alto valor aquisitivos disponibilizam o Proxy Reverso. E o melhor ele
pode ser implementado com vários tipos de tecnologias, como o nosso cenário ao
qual foi utilizado servidores Linux e Windows.
Conclui-se também que o Proxy Reverso é mais uma ferramenta de proteção
e ele sozinho, não substitui outros mecanismos como o firewall, IDS. Sendo assim
realizar uma ótima configuração de regras de firewall e de segurança da informação
é imprescindível.
Uma boa observação sobre o Proxy Reverso é a otimização e facilidade de
administração do mesmo, pois as configurações são todas feitas em um único
servidor, tornando a vida dos Analistas bem melhor.
Embora os exemplos tenham sido utilizado em laboratório apenas a
ferramenta Apache, os conceitos apresentados neste trabalho, valem para qualquer
ferramenta que possui a funcionalidade de Proxy Reverso, pois seu modo de conceito
é praticamente o mesmo em outras ferramentas.
39
7. REFERENCIAS
FILHO, João Eriberto Mota. Proxy reverso HTTP com Squid (versão 2.6 ou superior). Disponível em <eriberto.pro.br/wiki/index.php?title=Proxy_reverso_HTTP_com_Squid_%28vers%C3%A3o_2.6_ou_superior%29>. Acesso em: 10 agosto 2012.
GAVAROTO, Guilherme. O que è Penetration Testing. Disponível em < http://www.backtrackbrasil.com.br/site/2012/05/o-que-e-penetration-testing/> Acesso em: 22 abril 2013.
KABIR, Mohammed J. Apache Server 2 a Bíblia. Rio de Janeiro: Campus, 2002.
LOPES, Leandro de Souza. Segurança em Servidores Web Utilizando Proxy Reverso. Uberlândia:, 2006.
MACEDO, Diego. Proxy Cache e Reverso. Disponível em <www.diegomacedo.com.br/proxy-cache-e-reverso/>. Acesso em: 25 de agosto 2012.
MICROSOFT FOREFRONT THREAT MANAGEMENT GATEWAY. Forefront Threat Management Gateway 2010. Disponível em <www.microsoft.com/en-us/server-cloud/forefront/threat-management-gateway.aspx> Acesso em: 22 setembro 2012.
MORIMOTO, Carlos E. Servidores Linux, Guia Prático, São Paulo: Sulina, 2008.
NAKAMURA, Emilio Tissato. Segurança de Redes em Ambientes Corporativos, São Paulo: Novatec, 2010.
NETO, Alfredo Sabocinski. Proxy Reverso? O que danado é isso?. Disponível em <alfredosabo.blogspot.com.br/2009/05/proxy-reverso-o-que-danado-e-isso.html>. Acesso em: 23 setembro 2012.
40
PEIXOTO, Rodney de Castro. Relatório Demonstra Crescimento de Vulnerabilidades da Internet. Disponível em <www.correiadasilva.com.br/pdf/info_dig/infodig03.pdf>. Acesso em: 20 maio 2012.
REDE SEGURA. Porque se preocupar com a Segurança das Aplicações Web atualmente. Disponível em http://keysupport.com.br/doc/%281%29_Por_que_se_preocupar_com_Seguranca_de_Aplicacoes_Web.pdf. Acesso em: 10 abril 2013.
REIS, Cristiano F.; RAYMOND, Gerson; CARMO, Gilberto T. do. TCC Projeto Squid. Disponível em <g2cinformatica.blogspot.com.br/2007/07/tcc-projeto-squid_2719.html> . Acesso em: 13 agosto 2012.
SATO, Yutaka. DeleGate Home Page. Disponível em <www.delegate.org/delegate/>. Acesso em: 11 setembro 2012.
SILVA, Natália Vaz. Proxy Reverso com Apache. Disponível em < www.vivaolinux.com.br/artigo/Proxy-Reverso-com-Apache/?pagina=1>. Acesso em: 17 outubro 2012.
TEIXEIRA, Ataliba de Oliveira. Proxy Reverso com Apache. Disponivel em <
http://www.ataliba.eti.br/txts/apache-proxy.pdf>. Acesso em: 23 setembro 2012.
ZANONI, Guilherme Souza. Servidor Proxy (Squid). Disponível em <www.vivaolinux.com.br/artigo/Servidor-proxy-%28Squid%29>. Acesso em: 21 maio 2012.
VILELLA, Luis Eduardo. Linux: Squid passo a passo no Debian para iniciantes. Disponivel em < www.vivaolinux.com.br/artigo/Squid-passo-a-passo-para-iniciantes>. Acesso em: 15 agosto 2012.
41
8. APÊNDICES
Arquivo de configuração do Proxy Apache Reverso “ /etc/httpd/conf/httpd.conf ”.
# # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See <URL:http://httpd.apache.org/docs/2.2/> for detailed information. # In particular, see # <URL:http://httpd.apache.org/docs/2.2/mod/directives.html> # for a discussion of each configuration directive. # # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts, which allow Web requests to be sent to # different IP addresses or hostnames and have them handled by the # same Apache server process. # # Configuration and logfile names: If the filenames you specify for many # of the server's control files begin with "/" (or "drive:/" for Win32), the # server will use that explicit path. If the filenames do *not* begin # with "/", the value of ServerRoot is prepended -- so "logs/foo.log" # with ServerRoot set to "/etc/httpd" will be interpreted by the # server as "/etc/httpd/logs/foo.log". # ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. #
42
# # Don't give away too much information about all the subcomponents # we are running. Comment out this line if you don't mind remote sites # finding out what major optional modules you are running ServerTokens OS # # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or otherwise network) # mounted filesystem then please read the LockFile documentation # (available at <URL:http://httpd.apache.org/docs/2.2/mod/mpm_common.html#lockfile>); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # ServerRoot "/etc/httpd" # # PidFile: The file in which the server should record its process # identification number when it starts. Note the PIDFILE variable in # /etc/sysconfig/httpd must be set appropriately if this location is # changed. # PidFile run/httpd.pid # # Timeout: The number of seconds before receives and sends time out. # Timeout 60 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive Off # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection.
43
# KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM specific) ## # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule> # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule worker.c> StartServers 4 MaxClients 300 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> # # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the <VirtualHost> # directive. # # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 Listen 80
44
# # Dynamic Shared Object (DSO) Support # # To be able to use the functionality of a module which was built as a DSO you # have to place corresponding `LoadModule' lines at this location so the # directives contained in it are actually available _before_ they are used. # Statically compiled modules (those listed by `httpd -l') do not need # to be loaded here. # # Example: # LoadModule foo_module modules/mod_foo.so # LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_owner_module modules/mod_authz_owner.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule ldap_module modules/mod_ldap.so LoadModule authnz_ldap_module modules/mod_authnz_ldap.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so LoadModule logio_module modules/mod_logio.so LoadModule env_module modules/mod_env.so LoadModule ext_filter_module modules/mod_ext_filter.so LoadModule mime_magic_module modules/mod_mime_magic.so LoadModule expires_module modules/mod_expires.so LoadModule deflate_module modules/mod_deflate.so LoadModule headers_module modules/mod_headers.so LoadModule usertrack_module modules/mod_usertrack.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule mime_module modules/mod_mime.so LoadModule dav_module modules/mod_dav.so LoadModule status_module modules/mod_status.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule info_module modules/mod_info.so LoadModule dav_fs_module modules/mod_dav_fs.so LoadModule vhost_alias_module modules/mod_vhost_alias.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule dir_module modules/mod_dir.so LoadModule actions_module modules/mod_actions.so LoadModule speling_module modules/mod_speling.so LoadModule userdir_module modules/mod_userdir.so
45
LoadModule alias_module modules/mod_alias.so LoadModule substitute_module modules/mod_substitute.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule cache_module modules/mod_cache.so LoadModule suexec_module modules/mod_suexec.so LoadModule disk_cache_module modules/mod_disk_cache.so LoadModule cgi_module modules/mod_cgi.so LoadModule version_module modules/mod_version.so # # The following modules are not loaded by default: # #LoadModule asis_module modules/mod_asis.so #LoadModule authn_dbd_module modules/mod_authn_dbd.so #LoadModule cern_meta_module modules/mod_cern_meta.so #LoadModule cgid_module modules/mod_cgid.so #LoadModule dbd_module modules/mod_dbd.so #LoadModule dumpio_module modules/mod_dumpio.so #LoadModule filter_module modules/mod_filter.so #LoadModule ident_module modules/mod_ident.so #LoadModule log_forensic_module modules/mod_log_forensic.so #LoadModule unique_id_module modules/mod_unique_id.so # # # Load config files from the config directory "/etc/httpd/conf.d". # Include conf.d/*.conf # # ExtendedStatus controls whether Apache will generate "full" status # information (ExtendedStatus On) or just basic information (ExtendedStatus # Off) when the "server-status" handler is called. The default is Off. # ExtendedStatus On # # If you wish httpd to run as a different user or group, you must run # httpd as root initially and it will switch. # # User/Group: The name (or #number) of the user/group to run httpd as. # . On SCO (ODT 3) use "User nouser" and "Group nogroup". # . On HPUX you may not be able to use shared memory as nobody, and the # suggested workaround is to create a user www and use that user.
46
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET) # when the value of (unsigned)Group is above 60000; # don't use Group #-1 on these systems! # User apache Group apache ### Section 2: 'Main' server configuration # # The directives in this section set up the values used by the 'main' # server, which responds to any requests that aren't handled by a # <VirtualHost> definition. These values also provide defaults for # any <VirtualHost> containers you may define later in the file. # # All of these directives may appear inside <VirtualHost> containers, # in which case these default settings will be overridden for the # virtual host being defined. # # # ServerAdmin: Your address, where problems with the server should be # e-mailed. This address appears on some server-generated pages, such # as error documents. e.g. [email protected] # ServerAdmin root@localhost # # ServerName gives the name and port that the server uses to identify itself. # This can often be determined automatically, but we recommend you specify # it explicitly to prevent problems during startup. # # If this is not set to valid DNS name for your host, server-generated # redirections will not work. See also the UseCanonicalName directive. # # If your host doesn't have a registered DNS name, enter its IP address here. # You will have to access it by its address anyway, and this will make # redirections work in a sensible way. # ServerName localhost:80 # # UseCanonicalName: Determines how Apache constructs self-referencing # URLs and the SERVER_NAME and SERVER_PORT variables. # When set "Off", Apache will use the Hostname and Port supplied # by the client. When set "On", Apache will use the value of the # ServerName directive. # UseCanonicalName Off #
47
# DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. # DocumentRoot "/var/www" # # Each directory to which Apache has access can be configured with respect # to which services and features are allowed and/or disabled in that # directory (and its subdirectories). # # First, we configure the "default" to be a very restrictive set of # features. # <Directory /> Options FollowSymLinks AllowOverride None </Directory> # # Note that from this point forward you must specifically allow # particular features to be enabled - so if something's not working as # you might expect, make sure that you have specifically enabled it # below. # # # This should be changed to whatever you set DocumentRoot to. # <Directory "/var/www"> # # Possible values for the Options directive are "None", "All", # or any combination of: # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews # # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you. # # The Options directive is both complicated and important. Please see # http://httpd.apache.org/docs/2.2/mod/core.html#options # for more information. # Options Indexes FollowSymLinks # # AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # Options FileInfo AuthConfig Limit #
48
AllowOverride None # # Controls who can get stuff from this server. # Order allow,deny Allow from all </Directory> # # UserDir: The name of the directory that is appended onto a user's home # directory if a ~user request is received. # # The path to the end user account 'public_html' directory must be # accessible to the webserver userid. This usually means that ~userid # must have permissions of 711, ~userid/public_html must have permissions # of 755, and documents contained therein must be world-readable. # Otherwise, the client will only receive a "403 Forbidden" message. # # See also: http://httpd.apache.org/docs/misc/FAQ.html#forbidden # <IfModule mod_userdir.c> # # UserDir is disabled by default since it can confirm the presence # of a username on the system (depending on home directory # permissions). # UserDir disabled # # To enable requests to /~user/ to serve the user's public_html # directory, remove the "UserDir disabled" line above, and uncomment # the following line instead: # #UserDir public_html </IfModule> # # Control access to UserDir directories. The following is an example # for a site where these directories are restricted to read-only. # #<Directory /home/*/public_html> # AllowOverride FileInfo AuthConfig Limit # Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec # <Limit GET POST OPTIONS> # Order allow,deny # Allow from all # </Limit>
49
# <LimitExcept GET POST OPTIONS> # Order deny,allow # Deny from all # </LimitExcept> #</Directory> # # DirectoryIndex: sets the file that Apache will serve if a directory # is requested. # # The index.html.var file (a type-map) is used to deliver content- # negotiated documents. The MultiViews Option can be used for the # same purpose, but it is much slower. # DirectoryIndex index.html index.html.var # # AccessFileName: The name of the file to look for in each directory # for additional configuration directives. See also the AllowOverride # directive. # AccessFileName .htaccess # # The following lines prevent .htaccess and .htpasswd files from being # viewed by Web clients. # <Files ~ "^\.ht"> Order allow,deny Deny from all Satisfy All </Files> # # TypesConfig describes where the mime.types file (or equivalent) is # to be found. # TypesConfig /etc/mime.types # # DefaultType is the default MIME type the server will use for a document # if it cannot otherwise determine one, such as from filename extensions. # If your server contains mostly text or HTML documents, "text/plain" is # a good value. If most of your content is binary, such as applications # or images, you may want to use "application/octet-stream" instead to # keep browsers from trying to display binary files as though they are # text. # DefaultType text/plain
50
# # The mod_mime_magic module allows the server to use various hints from the # contents of the file itself to determine its type. The MIMEMagicFile # directive tells the module where the hint definitions are located. # <IfModule mod_mime_magic.c> # MIMEMagicFile /usr/share/magic.mime MIMEMagicFile conf/magic </IfModule> # # HostnameLookups: Log the names of clients or just their IP addresses # e.g., www.apache.org (on) or 204.62.129.132 (off). # The default is off because it'd be overall better for the net if people # had to knowingly turn this feature on, since enabling it means that # each client request will result in AT LEAST one lookup request to the # nameserver. # HostnameLookups Off # # EnableMMAP: Control whether memory-mapping is used to deliver # files (assuming that the underlying OS supports it). # The default is on; turn this off if you serve from NFS-mounted # filesystems. On some systems, turning it off (regardless of # filesystem) can improve performance; for details, please see # http://httpd.apache.org/docs/2.2/mod/core.html#enablemmap # #EnableMMAP off # # EnableSendfile: Control whether the sendfile kernel support is # used to deliver files (assuming that the OS supports it). # The default is on; turn this off if you serve from NFS-mounted # filesystems. Please see # http://httpd.apache.org/docs/2.2/mod/core.html#enablesendfile # #EnableSendfile off # # ErrorLog: The location of the error log file. # If you do not specify an ErrorLog directive within a <VirtualHost> # container, error messages relating to that virtual host will be # logged here. If you *do* define an error logfile for a <VirtualHost> # container, that host's errors will be logged there and not here. # ErrorLog logs/error_log # # LogLevel: Control the number of messages logged to the error_log.
51
# Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. # LogLevel warn # # The following directives define some format nicknames for use with # a CustomLog directive (see below). # LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent # "combinedio" includes actual counts of actual bytes received (%I) and sent (%O); this # requires the mod_logio module to be loaded. #LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio # # The location and format of the access logfile (Common Logfile Format). # If you do not define any access logfiles within a <VirtualHost> # container, they will be logged here. Contrariwise, if you *do* # define per-<VirtualHost> access logfiles, transactions will be # logged therein and *not* in this file. # #CustomLog logs/access_log common # # If you would like to have separate agent and referer logfiles, uncomment # the following directives. # #CustomLog logs/referer_log referer #CustomLog logs/agent_log agent # # For a single logfile with access, agent, and referer information # (Combined Logfile Format), use the following directive: # CustomLog logs/access_log combined # # Optionally add a line containing the server version and virtual host # name to server-generated pages (internal error documents, FTP directory # listings, mod_status and mod_info output etc., but not CGI generated # documents or custom error documents). # Set to "EMail" to also include a mailto: link to the ServerAdmin. # Set to one of: On | Off | EMail
52
# ServerSignature On # # Aliases: Add here as many aliases as you need (with no limit). The format is # Alias fakename realname # # Note that if you include a trailing / on fakename then the server will # require it to be present in the URL. So "/icons" isn't aliased in this # example, only "/icons/". If the fakename is slash-terminated, then the # realname must also be slash terminated, and if the fakename omits the # trailing slash, the realname must also omit it. # # We include the /icons/ alias for FancyIndexed directory listings. If you # do not use FancyIndexing, you may comment this out. # Alias /icons/ "/var/www/icons/" <Directory "/var/www/icons"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> # # WebDAV module configuration section. # <IfModule mod_dav_fs.c> # Location of the WebDAV lock database. DAVLockDB /var/lib/dav/lockdb </IfModule> # # ScriptAlias: This controls which directories contain server scripts. # ScriptAliases are essentially the same as Aliases, except that # documents in the realname directory are treated as applications and # run by the server when requested rather than as documents sent to the client. # The same rules about trailing "/" apply to ScriptAlias directives as to # Alias. # ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" # # "/var/www/cgi-bin" should be changed to whatever your ScriptAliased # CGI directory exists, if you have that configured. # #<Directory "/var/www/cgi-bin"> # AllowOverride None # Options None
53
# Order allow,deny # Allow from all #</Directory> # # Redirect allows you to tell clients about documents which used to exist in # your server's namespace, but do not anymore. This allows you to tell the # clients where to look for the relocated document. # Example: # Redirect permanent /foo http://www.example.com/bar # # Directives controlling the display of server-generated directory listings. # # # IndexOptions: Controls the appearance of server-generated directory # listings. # IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8 # # AddIcon* directives tell the server which icon to show for different # files or filename extensions. These are only displayed for # FancyIndexed directories. # AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif .bin .exe AddIcon /icons/binhex.gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core
54
AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ^^DIRECTORY^^ AddIcon /icons/blank.gif ^^BLANKICON^^ # # DefaultIcon is which icon to show for files which do not have an icon # explicitly set. # DefaultIcon /icons/unknown.gif # # AddDescription allows you to place a short description after a file in # server-generated indexes. These are only displayed for FancyIndexed # directories. # Format: AddDescription "description" filename # #AddDescription "GZIP compressed document" .gz #AddDescription "tar archive" .tar #AddDescription "GZIP compressed tar archive" .tgz # # ReadmeName is the name of the README file the server will look for by # default, and append to directory listings. # # HeaderName is the name of a file which should be prepended to # directory indexes. ReadmeName README.html HeaderName HEADER.html # # IndexIgnore is a set of filenames which directory indexing should ignore # and not include in the listing. Shell-style wildcarding is permitted. # IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t # # DefaultLanguage and AddLanguage allows you to specify the language of # a document. You can then use content negotiation to give a browser a # file in a language the user can understand. # # Specify a default language. This means that all data # going out without a specific language tag (see below) will # be marked with this one. You probably do NOT want to set # this unless you are sure it is correct for all cases. # # * It is generally better to not mark a page as # * being a certain language than marking it with the wrong # * language! #
55
# DefaultLanguage nl # # Note 1: The suffix does not have to be the same as the language # keyword --- those with documents in Polish (whose net-standard # language code is pl) may wish to use "AddLanguage pl .po" to # avoid the ambiguity with the common suffix for perl scripts. # # Note 2: The example entries below illustrate that in some cases # the two character 'Language' abbreviation is not identical to # the two character 'Country' code for its country, # E.g. 'Danmark/dk' versus 'Danish/da'. # # Note 3: In the case of 'ltz' we violate the RFC by using a three char # specifier. There is 'work in progress' to fix this and get # the reference data for rfc1766 cleaned up. # # Catalan (ca) - Croatian (hr) - Czech (cs) - Danish (da) - Dutch (nl) # English (en) - Esperanto (eo) - Estonian (et) - French (fr) - German (de) # Greek-Modern (el) - Hebrew (he) - Italian (it) - Japanese (ja) # Korean (ko) - Luxembourgeois* (ltz) - Norwegian Nynorsk (nn) # Norwegian (no) - Polish (pl) - Portugese (pt) # Brazilian Portuguese (pt-BR) - Russian (ru) - Swedish (sv) # Simplified Chinese (zh-CN) - Spanish (es) - Traditional Chinese (zh-TW) # AddLanguage ca .ca AddLanguage cs .cz .cs AddLanguage da .dk AddLanguage de .de AddLanguage el .el AddLanguage en .en AddLanguage eo .eo AddLanguage es .es AddLanguage et .et AddLanguage fr .fr AddLanguage he .he AddLanguage hr .hr AddLanguage it .it AddLanguage ja .ja AddLanguage ko .ko AddLanguage ltz .ltz AddLanguage nl .nl AddLanguage nn .nn AddLanguage no .no AddLanguage pl .po AddLanguage pt .pt AddLanguage pt-BR .pt-br AddLanguage ru .ru AddLanguage sv .sv AddLanguage zh-CN .zh-cn AddLanguage zh-TW .zh-tw
56
# # LanguagePriority allows you to give precedence to some languages # in case of a tie during content negotiation. # # Just list the languages in decreasing order of preference. We have # more or less alphabetized them here. You probably want to change this. # LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW # # ForceLanguagePriority allows you to serve a result page rather than # MULTIPLE CHOICES (Prefer) [in case of a tie] or NOT ACCEPTABLE (Fallback) # [in case no accepted languages matched the available variants] # ForceLanguagePriority Prefer Fallback # # Specify a default charset for all content served; this enables # interpretation of all content as UTF-8 by default. To use the # default browser choice (ISO-8859-1), or to allow the META tags # in HTML content to override this choice, comment out this # directive: # AddDefaultCharset UTF-8 # # AddType allows you to add to or override the MIME configuration # file mime.types for specific file types. # #AddType application/x-tar .tgz # # AddEncoding allows you to have certain browsers uncompress # information on the fly. Note: Not all browsers support this. # Despite the name similarity, the following Add* directives have nothing # to do with the FancyIndexing customization directives above. # #AddEncoding x-compress .Z #AddEncoding x-gzip .gz .tgz # If the AddEncoding directives above are commented-out, then you # probably should define those extensions to indicate media types: # AddType application/x-compress .Z AddType application/x-gzip .gz .tgz # # MIME-types for downloading Certificates and CRLs
57
# AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl # # AddHandler allows you to map certain file extensions to "handlers": # actions unrelated to filetype. These can be either built into the server # or added with the Action directive (see below) # # To use CGI scripts outside of ScriptAliased directories: # (You will also need to add "ExecCGI" to the "Options" directive.) # #AddHandler cgi-script .cgi # # For files that include their own HTTP headers: # #AddHandler send-as-is asis # # For type maps (negotiated resources): # (This is enabled by default to allow the Apache "It Worked" page # to be distributed in multiple languages.) # AddHandler type-map var # # Filters allow you to process content before it is sent to the client. # # To parse .shtml files for server-side includes (SSI): # (You will also need to add "Includes" to the "Options" directive.) # AddType text/html .shtml AddOutputFilter INCLUDES .shtml # # Action lets you define media types that will execute a script whenever # a matching file is called. This eliminates the need for repeated URL # pathnames for oft-used CGI file processors. # Format: Action media/type /cgi-script/location # Format: Action handler-name /cgi-script/location # # # Customizable error responses come in three flavors: # 1) plain text 2) local redirects 3) external redirects # # Some examples: #ErrorDocument 500 "The server made a boo." #ErrorDocument 404 /missing.html
58
#ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://www.example.com/subscription_info.html # # # Putting this all together, we can internationalize error responses. # # We use Alias to redirect any /error/HTTP_<error>.html.var response to # our collection of by-error message multi-language collections. We use # includes to substitute the appropriate text. # # You can modify the messages' appearance without changing any of the # default HTTP_<error>.html.var files by adding the line: # # Alias /error/include/ "/your/include/path/" # # which allows you to create your own set of files by starting with the # /var/www/error/include/ files and # copying them to /your/include/path/, even on a per-VirtualHost basis. # Alias /error/ "/var/www/error/" <IfModule mod_negotiation.c> <IfModule mod_include.c> <Directory "/var/www/error"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var Order allow,deny Allow from all LanguagePriority en es de fr ForceLanguagePriority Prefer Fallback </Directory> ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var ErrorDocument 410 /error/HTTP_GONE.html.var ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var
59
ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var </IfModule> </IfModule> # # The following directives modify normal HTTP response behavior to # handle known problems with browser implementations. # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 # # The following directive disables redirects on non-GET requests for # a directory that does not include the trailing slash. This fixes a # problem with Microsoft WebFolders which does not appropriately handle # redirects for folders with DAV methods. # Same deal with Apple's DAV filesystem and Gnome VFS support for DAV. # BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully BrowserMatch "MS FrontPage" redirect-carefully BrowserMatch "^WebDrive" redirect-carefully BrowserMatch "^WebDAVFS/1.[0123]" redirect-carefully BrowserMatch "^gnome-vfs/1.0" redirect-carefully BrowserMatch "^XML Spy" redirect-carefully BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the ".example.com" to match your domain to enable. # <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from all </Location> # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".example.com" to match your domain to enable. # #<Location /server-info>
60
# SetHandler server-info # Order deny,allow # Deny from all # Allow from .example.com #</Location> # # Proxy Server directives. Uncomment the following lines to # enable the proxy server: # <IfModule mod_proxy.c> ProxyRequests Off # <Proxy *> Order deny,allow # Deny from all Allow from all </Proxy> # # Enable/disable the handling of HTTP/1.1 "Via:" headers. # ("Full" adds the server version; "Block" removes all outgoing Via: headers) # Set to one of: Off | On | Full | Block # ProxyVia On # # To enable a cache of proxied content, uncomment the following lines. # See http://httpd.apache.org/docs/2.2/mod/mod_cache.html for more details. # <IfModule mod_disk_cache.c> CacheEnable disk / CacheRoot "/var/cache/mod_proxy" </IfModule> </IfModule> # End of proxy directives. #Configuracao Proxy Reverso ProxyPass /cadastro http://192.168.1.112 ProxyPassReverse /cadastro http://192.168.1.112 ProxyPass /pedido http://192.168.1.113 ProxyPassReverse /pedido http://192.168.1.113 ### Section 3: Virtual Hosts # # VirtualHost: If you want to maintain multiple domains/hostnames on your # machine you can setup VirtualHost containers for them. Most configurations # use only name-based virtual hosts so the server doesn't need to worry about
61
# IP addresses. This is indicated by the asterisks in the directives below. # # Please see the documentation at # <URL:http://httpd.apache.org/docs/2.2/vhosts/> # for further details before you try to setup virtual hosts. # # You may use the command line option '-S' to verify your virtual host # configuration. # # Use name-based virtual hosting. # #NameVirtualHost *:80 # # NOTE: NameVirtualHost cannot be used without a port specifier # (e.g. :80) if mod_ssl is being used, due to the nature of the # SSL protocol. # # # VirtualHost example: # Almost any Apache directive may go into a VirtualHost container. # The first VirtualHost section is used for requests without a known # server name. # #<VirtualHost *:80> # ServerAdmin [email protected] # DocumentRoot /www/docs/dummy-host.example.com # ServerName dummy-host.example.com # ErrorLog logs/dummy-host.example.com-error_log # CustomLog logs/dummy-host.example.com-access_log common #</VirtualHost>
62
Relátorio do teste de Vulnerabilidade.
===== Checking multi/http/activecollab_chat =====
msf > use multi/http/activecollab_chat
msf exploit(activecollab_chat) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(activecollab_chat) > check
[-] Exploit check failed: Msf::OptionValidateError The following options failed
to validate: USER, PASS.
===== Checking multi/http/apprain_upload_exec =====
msf exploit(activecollab_chat) > use multi/http/apprain_upload_exec
msf exploit(apprain_upload_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(apprain_upload_exec) > check
[*] The target is not exploitable.
===== Checking unix/http/contentkeeperweb_mimencode =====
msf exploit(apprain_upload_exec) > use
unix/http/contentkeeperweb_mimencode
63
msf exploit(contentkeeperweb_mimencode) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(contentkeeperweb_mimencode) > check
[*] The target is not exploitable.
===== Checking multi/http/cuteflow_upload_exec =====
msf exploit(contentkeeperweb_mimencode) > use
multi/http/cuteflow_upload_exec
msf exploit(cuteflow_upload_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(cuteflow_upload_exec) > check
[*] The target is not exploitable.
===== Checking linux/http/ddwrt_cgibin_exec =====
msf exploit(cuteflow_upload_exec) > use linux/http/ddwrt_cgibin_exec
msf exploit(ddwrt_cgibin_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(ddwrt_cgibin_exec) > check
[*] This exploit does not support check.
64
===== Checking linux/http/dolibarr_cmd_exec =====
msf exploit(ddwrt_cgibin_exec) > use linux/http/dolibarr_cmd_exec
msf exploit(dolibarr_cmd_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(dolibarr_cmd_exec) > check
[*] The target is not exploitable.
===== Checking multi/http/familycms_less_exec =====
msf exploit(dolibarr_cmd_exec) > use multi/http/familycms_less_exec
msf exploit(familycms_less_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(familycms_less_exec) > check
[*] The target is not exploitable.
===== Checking multi/http/freenas_exec_raw =====
msf exploit(familycms_less_exec) > use multi/http/freenas_exec_raw
65
msf exploit(freenas_exec_raw) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(freenas_exec_raw) > check
[*] This exploit does not support check.
===== Checking multi/http/gitorious_graph =====
msf exploit(freenas_exec_raw) > use multi/http/gitorious_graph
msf exploit(gitorious_graph) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(gitorious_graph) > check
[*] This exploit does not support check.
===== Checking multi/http/horde_href_backdoor =====
msf exploit(gitorious_graph) > use multi/http/horde_href_backdoor
msf exploit(horde_href_backdoor) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(horde_href_backdoor) > check
[*] This exploit does not support check.
66
===== Checking multi/http/lcms_php_exec =====
msf exploit(horde_href_backdoor) > use multi/http/lcms_php_exec
msf exploit(lcms_php_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(lcms_php_exec) > check
[-] Unable to get the page parameter, please reconfigure URI
[-] Check failed: The state could not be determined.
===== Checking unix/http/lifesize_room =====
msf exploit(lcms_php_exec) > use unix/http/lifesize_room
msf exploit(lifesize_room) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(lifesize_room) > check
[*] This exploit does not support check.
===== Checking linux/http/linksys_apply_cgi =====
msf exploit(lifesize_room) > use linux/http/linksys_apply_cgi
67
msf exploit(linksys_apply_cgi) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(linksys_apply_cgi) > check
[*] This exploit does not support check.
===== Checking multi/http/log1cms_ajax_create_folder =====
msf exploit(linksys_apply_cgi) > use multi/http/log1cms_ajax_create_folder
msf exploit(log1cms_ajax_create_folder) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(log1cms_ajax_create_folder) > check
[*] The target is not exploitable.
===== Checking multi/http/op5_license =====
msf exploit(log1cms_ajax_create_folder) > use multi/http/op5_license
msf exploit(op5_license) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(op5_license) > check
[*] Attempting to detect if the OP5 Monitor is vulnerable...
[*] Sending request to https://200.232.237.139:443/license.php
68
[*] The target is not exploitable.
===== Checking multi/http/op5_welcome =====
msf exploit(op5_license) > use multi/http/op5_welcome
msf exploit(op5_welcome) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(op5_welcome) > check
[*] Attempting to detect if the OP5 Monitor is vulnerable...
[*] Sending request to https://200.232.237.139:443/op5config/welcome
[*] The target is not exploitable.
===== Checking multi/http/php_cgi_arg_injection =====
msf exploit(op5_welcome) > use multi/http/php_cgi_arg_injection
msf exploit(php_cgi_arg_injection) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(php_cgi_arg_injection) > check
[*] Checking uri /
[-] Server responded indicating it was not vulnerable
[*] The target is not exploitable.
69
===== Checking multi/http/php_volunteer_upload_exec =====
msf exploit(php_cgi_arg_injection) > use
multi/http/php_volunteer_upload_exec
msf exploit(php_volunteer_upload_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(php_volunteer_upload_exec) > check
[*] This exploit does not support check.
===== Checking multi/http/phpldapadmin_query_engine =====
msf exploit(php_volunteer_upload_exec) > use
multi/http/phpldapadmin_query_engine
msf exploit(phpldapadmin_query_engine) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(phpldapadmin_query_engine) > check
[*] The target is not exploitable.
===== Checking multi/http/phpscheduleit_start_date =====
70
msf exploit(phpldapadmin_query_engine) > use
multi/http/phpscheduleit_start_date
msf exploit(phpscheduleit_start_date) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(phpscheduleit_start_date) > check
[*] Checking uri /phpscheduleit/reserve.php
[*] The target is not exploitable.
===== Checking linux/http/piranha_passwd_exec =====
msf exploit(phpscheduleit_start_date) > use linux/http/piranha_passwd_exec
msf exploit(piranha_passwd_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(piranha_passwd_exec) > check
[*] This exploit does not support check.
===== Checking multi/http/pmwiki_pagelist =====
msf exploit(piranha_passwd_exec) > use multi/http/pmwiki_pagelist
msf exploit(pmwiki_pagelist) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
71
msf exploit(pmwiki_pagelist) > check
[*] The target is not exploitable.
===== Checking multi/http/sit_file_upload =====
msf exploit(pmwiki_pagelist) > use multi/http/sit_file_upload
msf exploit(sit_file_upload) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(sit_file_upload) > check
[-] Exploit check failed: Msf::OptionValidateError The following options failed
to validate: USERNAME, PASSWORD.
===== Checking multi/http/snortreport_exec =====
msf exploit(sit_file_upload) > use multi/http/snortreport_exec
msf exploit(snortreport_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(snortreport_exec) > check
[*] This exploit does not support check.
72
===== Checking multi/http/spree_search_exec =====
msf exploit(snortreport_exec) > use multi/http/spree_search_exec
msf exploit(spree_search_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(spree_search_exec) > check
[*] This exploit does not support check.
===== Checking multi/http/spree_searchlogic_exec =====
msf exploit(spree_search_exec) > use multi/http/spree_searchlogic_exec
msf exploit(spree_searchlogic_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(spree_searchlogic_exec) > check
[*] This exploit does not support check.
===== Checking multi/http/sun_jsws_dav_options =====
msf exploit(spree_searchlogic_exec) > use multi/http/sun_jsws_dav_options
msf exploit(sun_jsws_dav_options) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
73
msf exploit(sun_jsws_dav_options) > check
[*] The target is not exploitable.
===== Checking linux/http/symantec_web_gateway_exec =====
msf exploit(sun_jsws_dav_options) > use
linux/http/symantec_web_gateway_exec
msf exploit(symantec_web_gateway_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(symantec_web_gateway_exec) > check
[*] The target is not exploitable.
===== Checking linux/http/symantec_web_gateway_file_upload =====
msf exploit(symantec_web_gateway_exec) > use
linux/http/symantec_web_gateway_file_upload
msf exploit(symantec_web_gateway_file_upload) > set RHOST
200.232.237.139
RHOST => 200.232.237.139
msf exploit(symantec_web_gateway_file_upload) > check
[*] The target is not exploitable.
74
===== Checking linux/http/symantec_web_gateway_lfi =====
msf exploit(symantec_web_gateway_file_upload) > use
linux/http/symantec_web_gateway_lfi
msf exploit(symantec_web_gateway_lfi) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(symantec_web_gateway_lfi) > check
[*] The target is not exploitable.
===== Checking linux/http/symantec_web_gateway_pbcontrol =====
msf exploit(symantec_web_gateway_lfi) > use
linux/http/symantec_web_gateway_pbcontrol
msf exploit(symantec_web_gateway_pbcontrol) > set RHOST
200.232.237.139
RHOST => 200.232.237.139
msf exploit(symantec_web_gateway_pbcontrol) > check
[*] The target is not exploitable.
===== Checking multi/http/tomcat_mgr_deploy =====
75
msf exploit(symantec_web_gateway_pbcontrol) > use
multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(tomcat_mgr_deploy) > check
[-] Failed: Error requesting /manager/serverinfo
[*] Cannot reliably check exploitability.
===== Checking multi/http/traq_plugin_exec =====
msf exploit(tomcat_mgr_deploy) > use multi/http/traq_plugin_exec
msf exploit(traq_plugin_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(traq_plugin_exec) > check
[*] The target is not exploitable.
===== Checking multi/http/vbseo_proc_deutf =====
msf exploit(traq_plugin_exec) > use multi/http/vbseo_proc_deutf
msf exploit(vbseo_proc_deutf) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
76
msf exploit(vbseo_proc_deutf) > check
[*] The target is not exploitable.
===== Checking linux/http/vcms_upload =====
msf exploit(vbseo_proc_deutf) > use linux/http/vcms_upload
msf exploit(vcms_upload) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(vcms_upload) > check
[*] The target is not exploitable.
===== Checking linux/http/webcalendar_settings_exec =====
msf exploit(vcms_upload) > use linux/http/webcalendar_settings_exec
msf exploit(webcalendar_settings_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(webcalendar_settings_exec) > check
[*] The target is not exploitable.
===== Checking linux/http/webid_converter =====
77
msf exploit(webcalendar_settings_exec) > use linux/http/webid_converter
msf exploit(webid_converter) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(webid_converter) > check
[*] The target is not exploitable.
===== Checking multi/http/webpagetest_upload_exec =====
msf exploit(webid_converter) > use multi/http/webpagetest_upload_exec
msf exploit(webpagetest_upload_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(webpagetest_upload_exec) > check
[*] The target is not exploitable.
===== Checking multi/http/wikka_spam_exec =====
msf exploit(webpagetest_upload_exec) > use multi/http/wikka_spam_exec
msf exploit(wikka_spam_exec) > set RHOST 200.232.237.139
RHOST => 200.232.237.139
msf exploit(wikka_spam_exec) > check
78
[-] Exploit check failed: Msf::OptionValidateError The following options failed
to validate: USERNAME, PASSWORD, PAGE.