Sei sulla pagina 1di 84

Fatec Ourinhos

Donizete Fidelis

PROXY REVERSO

OURINHOS (SP) 2013

DONIZETE FIDELIS

PROXY REVERSO

Trabalho de Graduao apresentado a Faculdade de Tecnologia de Ourinhos para concluso do Curso de Segurana da Informao. Orientador: Prof. Alex Marino Gonalves de Almeida.

OURINHOS (SP) 2013

Dedico este trabalho aos meus pais, minha namorada, cunhados e sobrinhos, pelo incentivo, cooperao e apoio e, em especial, minha irm Snia e seu esposo; pois, alm de terem me acolhido durante todo o curso, compartilharam comigo os momentos de tristezas e tambm de alegrias, nesta etapa, em que, com a graa de Deus, est sendo vencida.

Primeiramente, agradeo a Deus, meu mestre. Ao Prof. Alex Marino Gonalves de Almeida, pela sabedoria e ateno com que conduziu a orientao este trabalho.

RESUMO Cada vez mais o mundo corporativo na rea de TI caminha para os sistemas web, pela facilidade de serem sistemas hbridos, sendo executados a partir de qualquer dispositivo como: celulares, palms, notebooks, tablets e desktops, atravs de um navegador padro. Com esta reviravolta do cenrio de TI, uma grande demanda da estrutura de segurana necessria. Pois os dados das empresa j no estaro mais somente para acesso interno das informaes e sim de qualquer lugar do mundo onde disponha de um acesso internet. Podendo tambm uma gama de tecnologias de diferentes sistemas operacionais e linguagens de programao terem que trabalhar juntas, deixando assim a administrao muito complexa. Sendo assim ser criado um cenrio de testes para enfatizar estas informaes e demostrar que com o Proxy Reverso possvel ter um ambiente eficaz e seguro, mostrando suas configuraes sendo implementadas no Apache. Palavras-Chave; Apache, Proxy Reverso, Segurana.

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: Servios.....................................................................................................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 Informao. URL: Uniform Resource Locator. VM: Virtual Box.

SUMRIO

1.

INTRODUO .................................................................................................................................. 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 Cenrio sem Proxy....................................................................................................................... 11 2.4 Cenrio com Proxy ...................................................................................................................... 11

3.

SOLUES PROXY DISPONVEIS 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 Utilizao 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 Benefcios do Proxy Reverso. ...................................................................................................... 24

5.

IMPLANTAO 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.

CONSIDERAES FINAIS ................................................................................................................ 38

7. 8.

REFERENCIAS ................................................................................................................................. 39 APNDICES .................................................................................................................................... 41

1.

INTRODUO

Atualmente, os ambientes de TI apresentam cada vez mais complexidade em elaborar novos sistemas cada vez mais robustos e ao mesmo tempo uma portabilidade acessvel a vrias plataformas e com isso houve uma grande demanda em aplicaes desenvolvidas para trabalhar em um servidor web, que com isto obtmse uma portabilidade com sucesso acessvel 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 trs 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 Segurana da Informao que vem a ser: a confidencialidade, integridade e disponibilidade. Vem a ser ameaado, contudo novas tecnologias surgem para garantir que a segurana das informaes estejam sempre protegidas. Como no caso os Servidores Proxy. Em um ambiente cliente/servidor as atenes normalmente esto direcionadas para o servidor, onde residem as informaes e, portanto foco de ameaas. Os clientes na Web esto fora de nossa guarda e assim fora do nosso controle. A proteo do cliente, no o grande objetivo, a no ser quando se trata de sua privacidade. Segurana no servidor Web consiste, em geral, em um ponto crtico em relao para algumas organizaes que tem a Web a sua principal fonte de renda ou como para seu trabalho, no caso em algumas corporaes 24 horas por dia e sete dia por semana. A partir de tantas tecnologias disponveis no mercado em solues web, fica cada vez mais difcil de realizar um padro de segurana da informao em cima dos servios, pois cada tecnologia trabalha de um modo diferente e com isso brechas na segurana podem ocorrer normalmente, tornando a administrao destes sistemas muito difcil para os administradores de redes. Pois este cenrio causa muito trabalho, ou seja, gera um alto nvel de complexidade nas organizaes que tem que manter estes sistemas atualizados e protegidos.

Objetivos Este trabalho tem como principais objetivos, apresentar os Servidores Proxy existentes e as diferena entre Servidor Proxy Cache e Servidor Proxy Reverso. Tambm mostrar em um Ambiente Web, algumas anlises sobre a segurana que um Servidor Proxy Reverso vem a exercer em um ambiente que utilize solues web. Este trabalho tem como objetivo especfico, mostrar os benefcios de uma corporao implementar um servidor Proxy Reverso para suas aplicaes que utilizam servios web. O cenrio abaixo descrito ser utilizado para implantao: Apache 2.2 instalado em um S.O Linux CentOS verso 6.4, onde ser implantado o Proxy Reverso; Apache 2.2 instalado em um S.O Linux CentOS verso 6.4, ao qual ser um servidor de aplicao; Windows 2008 Server Standard rodando o ISS com pginas ASP, ao qual ser um servidor de aplicao; Suponhamos que este Servidor Windows esteja configurado e esto em produo, s que com IP no rotevel, ou seja, somente na rede interna. A empresa necessita ter acesso externo a estes Servidores Windows e CentOS que rodam suas aplicaes, porem possui somente um IP pblico, com isso o Apache que est rodando no Linux CentOS tem o um domnio vlido e pode ter acesso externo. Ser usado o domnio de www.siteexemplo.dyndns.info como exemplo. A partir deste cenrio ser utilizado o Apache como Proxy Reverso para que quando o Servidor de ISS ou do Apache receber alguma solicitao externa, o Proxy Reverso, libere somente o acesso a uma porta especfica. Ficando assim protegidos quanto a ataques que poderiam interromper os servios da mesma. A estrutura desse trabalho se dar da seguinte forma: O presente documento encontrara-se divido em 7 (sete) captulos: introduo, apresentando o termo Proxy, conhecendo algumas solues, Proxy reverso, implantao do Proxy reverso, concluso, e referncias.

No primeiro captulo apresenta-se a introduo fazendo um apanhado geral do tema, descrio dos objetivos, justificativa do trabalho, a metodologia que ser utilizada e a explicao sobre a estrutura do trabalho. Sobre o segundo captulo aborda-se de um modo geral o conceito de Proxy. No terceiro captulo, algumas solues de Servidores Proxy sero apresentadas. O quarto captulo, submete as funcionalidade de um Servidor Proxy Reverso e os benefcios que o mesmo proporciona em um ambiente web. O quinto captulo ser apresentado um cenrio com o Proxy Reverso Implementado e com algumas ferramentas de anlise de vulnerabilidades do mercado, veremos como o mesmo se comporta e a qual nvel se consegue analisar as informaes do servidor. No sexto captulo, argumentam-se as consideraes finais fazendo uma sntese e um apanhado geral dos pontos mais importantes dos captulos anteriores, de maneira a reforar a ideia da utilizao de um Servidor Proxy Reverso garantindo assim maior segurana ao ambiente. Enfim, no stimo captulo sero citadas as referncias da pesquisa do trabalho.

Justificativa

Este trabalho mostrara a segurana que um Servidor Proxy Reverso tende a criar em um ambiente que necessite de acesso externo, no adianta somente implantar um Servidor de Firewall como principal fonte de proteo, pois a maioria dos firewalls do mercado faz a filtragem de pacotes somente em cima de alguns campos como exemplo no cabealho IP de origem, IP destino, porta origem, porta destino. Se for autorizado o acesso a alguma porta especfica do servidor, o mesmo deixa o pacote passar, sem se preocupar com as informaes contidas dentro que poderia ser um ataque de algum hacker a um determinado servio web da empresa e com isto poderia causar a paralisao dos servios, roubo de informaes, alterao

de dados e outros problemas que podem ocorrer com o acesso indevido das informaes. Metodologia Para conseguir atingir os objetivos apresentados, este trabalho, uma vez embasado em publicaes como livros, artigos cientficos e sites especficos, sero apresentadas algumas tecnologias sobre Proxy. Feito isso, ir tratar da segurana que um Servidor Proxy Reverso em um Ambiente Web proporciona, que justamente o motivo ao qual se justifica este trabalho. O cenrio todo ser elaborado e criado com mquinas virtuais utilizando a tecnologia Oracle VM Virtual Box, ao qual sero feitas as instalaes dos devidos S.Os, configuraes e seus devidos testes para comprovar a segurana que o Proxy Reverso vem a agregar. No ltimo captulo, sero feitas consideraes finais para reforar e justificar tudo aquilo j demonstrado atravs das ideias e pensamentos j desenvolvidos ao longo do trabalho.

2.

APRESENTANDO O TERMO PROXY

Proxy um servidor que atende a requisies repassando os dados a outros servidores. Um usurio (cliente) conecta-se a um Servidor Proxy, requisitando algum servio, como um arquivo, conexo, website, ou outro recurso disponvel em outro servidor. O Proxy surgiu da necessidade de conectar uma rede local Internet atravs de um computador da rede que compartilha sua conexo com as mquinas 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 mquinas tenham acesso externo, ou seja, a conexo com a Internet. Geralmente, mquinas da rede interna no possuem endereos vlidos na Internet, primeiro pelo fato da segurana nas redes privadas e tambm devido falta de IPs vlidos, portanto, no tm uma conexo direta com a Internet. Assim, toda solicitao de conexo de uma mquina 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 solicitao para a mquina da rede local. comum termos o Proxy como conexo direta com a Internet.

2.1 Significado do Termo Proxy

Na rea de TI, Proxy significa um programa ou um servio que faz o papel de intermedirio entre o cliente e o servidor, para acessar um determinado servio. 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 conexo. A vantagem de usar um servidor dedicado ao invs de simplesmente compartilhar usando o prprio modem ADSL que voc pode incluir outros servios, como um cache de pginas (Squid), filtro de contedo (SquidGuard ou DansGuardian), firewall, servidor Samba (compartilhando arquivos com a rede interna), servidor de impresso e assim por diante. (2008, p.75).

10

O Proxy pode ser utilizado para vrias aplicaes como HTTP, HTTPS, FTP e outros, fazendo seu trabalho de interceptar as informaes trafegadas e liberando as informaes ao cliente ou as negando. Sob estas expectativas:
O objetivo principal de um servidor proxy possibilitar que mquinas de uma rede privada possam acessar uma rede pblica, como a Internet, sem que para isto tenham uma ligao direta com esta. O servidor proxy costuma ser instalado em uma mquina que tenha acesso direto internet, sendo que as demais efetuam as solicitaes atravs desta. Justamente por isto este tipo chamado de Proxy, pois um procurador, ou seja, sistema que faz solicitaes em nome de outros. (ZANONI, 2007).

2.2 Demanda de Servidores Proxy

Para melhor anlise podemos nos remetemos a Nakamura:


A tecnologia da informao um instrumento cada vez mais utilizado pelo homem, que busca incessantemente realizar seus trabalhos de modo mais fcil, mais rpido, mais eficiente e mais competitivo, produzindo, assim, os melhores resultados. A rede uma das principais tecnologias, permitindo conexes entre todos os seus elementos, que vo desde roteadores at servidores que hospedam o website da organizao 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 informao, at mesmo o prprio negcio das organizaes. Isso faz com que sua flexibilidade e facilidade de uso resultem de uso resultante em maior produtividade e na possibilidade de criao de novos servios e produtos, e consequentemente em maiores lucros para a organizao. (2010, p. 43).

A explorao de vulnerabilidades em aplicaes que usam ambientes web aumenta a cada dia. Pois o nmero 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 so exploradas remotamente, o que incrementou as ameaas de alto risco em 6%, e as de mdio risco em, 24%. As vulnerabilidades em aplicaes web cresceram 12% quando comparadas ao mesmo perodo do ano passado. Novamente, os sistemas Microsoft tiveram um grande nmero de vulnerabilidades exploradas, e tambm erros introduzidos em cdigos de programas como Apache, Sendmail e OpenSSH. (PEIXOTO, 2003).

E a cada ano mais e mais estes nmeros tem tido um alto crescimento. Perante estas ameaas o interessante para as empresa no somente investir em um servidor firewall, mais sim tambm em um servidor Proxy.

11

2.3 Cenrio sem Proxy

Na figura 1, mostra-se um exemplo clssico de uma rede, que est presente na maioria dos cenrios e muitas vezes em empresas. Os clientes da rede tem total contato diretamente com a Internet, sem nenhum controle e nenhuma anlise do trfego dos pacotes que por ali trafegam.

Figura 1: Ambiente Sem Proxy. Fonte: Autor.

2.4 Cenrio com Proxy

Na figura 2, mostra-se um exemplo bsico de um servidor Proxy para servio de controle de trfego da Internet em uma rede, usando o Squid. Os clientes da rede interna no tem contato diretamente com a Internet.

12

Figura 2: Ambiente Com Proxy. Fonte: Autor.

As requisies vo todas para o Servidor Proxy que verifica todo o trafego, assim fazendo seu papel de autorizar ou restringir o acesso determinada pgina da web. No prximo capitulo deste trabalho ser apresentado um breve resumo sobre alguma das principais tecnologias disponveis no mercado.

13

3.

SOLUES PROXY DISPONVEIS NO MERCADO.

Atualmente existem vrios softwares com as caractersticas de Proxy, alguns mais especializados em somente alguns protocolos, outros com mais funcionalidades, em especial para o sistema operacional Linux e tambm 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 orientaes segundo REIS at al:
Web Proxy: Existe, ainda, um outro tipo de Proxy, os web proxies. Eles so uma verso que esconde o seu IP real e lhe permite navegar anonimamente. Muitos deles so utilizados em redes fechadas como universidades e ambientes de trabalho para burlar uma determinao de bloqueio a alguns sites da internet. Os contedos campees de bloqueio so: sites de relacionamento (Orkut, facebook e outros), programas de troca de mensagem instantnea (Msn Messenger, Yahoo! Messenger e outros), sem contar os to proibidos sites de pornografia. Open Proxy: As conexes abertas de Proxy (open proxy) so o tipo mais perigoso e convidativo aos crackers e usurios mal intencionados. Quando um destes usurios consegue acessar um computador, instala um servidor Proxy nele para que possa entrar quando quiser na mquina e promover diversos tipos de ilegalidade

14

como scripts que roubam senhas de bancos, fraudes envolvendo cartes de crdito e uma grande variedade de atos ilegais. Redes Proxy: As redes Proxy so baseadas em cdigos cifrados que permitem a comunicao annima entre os usurios. Exemplo deste tipo de rede so as conexes P2P (peer to peer) em que um usurio se conecta ao outro sem saber sua identidade e trocam arquivos entre si. Estas redes se caracterizam por no permitirem o controle dos servidores, os usurios comuns quem providenciam todo o contedo e os arquivos. Certamente, muitos destes computadores so usados por pessoas mal intencionadas com segundas intenes. Por isso, deve-se ter em mente que qualquer promessa de privacidade e segurana 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 contedo, na qual possui vrios programadores como desenvolvedores do projeto pelo mundo. geralmente disponibilizado por padro 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 funo cache, a mesma guarda no cache os sites acessados, quando o acesso a um site presente no cache solicitado, automaticamente retornado ao usurio o site do cache. (VILELLA, 2010). Tornando assim a resposta ao usurio muito mais rpida e eficiente e tambm uma economia de banda.

15

3.2 Delegate

Este tambm um Proxy interessante, O Delegate interliga uma comunicao entre usurios e clientes, onde uma comunicao direta impossvel, ineficiente, ou inconveniente. Perante Sato:
Delegate um multi - propsito de gateway em nvel de aplicao, ou um servidor proxy que funciona em vrias plataformas (Unix, Windows, MacOS X e OS / 2). Delegate mede a comunicao de vrios protocolos (HTTP, FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, SOCKS, DNS, etc.), a aplicao de cache e converso 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 arbitrrios, convertendo entre IPv4 e IPv6, mesclando vrios servidores em um nico servidor com analise e filtragem. Nascido como um proxy pequeno para Gopher maro 1994, tem crescido constantemente em um servidor de propsito geral proxy. Alm 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 critrios. Segundo palavras de Reis:
A ferramenta difere da maioria disponvel no mercado pelo fato de no funcionar apenas como filtro de URL, mas tambm como um efetivo filtro de contedo de pginas Web. Pois, faz uma varredura do contedo de cada pgina acessada por seus usurios e no somente uma liberao ou proibio do nome do site ou da URL acessada. Este filtro de contedo funciona em conjunto com qualquer Proxy, podendo ser instalado em sistemas operacionais Linux, FreeBSD, OpenBSD, NetBSD, Mac OSX e Solaris.O Dansguardian no tem caractersticas de Proxy, portanto obrigatrio o uso de um servidor Proxy para que a ferramenta seja implementada, embora ele tenha sido citado neste trabalho por ser relevante suas funes. Nas solues comumente encontradas no mercado, o filtro de contedo recebe as requisies

16

do navegador do usurio, aplica as restries estabelecidas ou as excees configuradas e, em seguida, passa a requisio para o Proxy. Este faz o seu papel que a intermediao entre o cliente e o servidor a ser acessado. No processamento interno de arquivos contendo proibies e excees, existe uma ordem pr-estabelecida. Apesar do Dansguardian no ter caractersticas de Proxy o mesmo foi citado apenas para fim de conhecimento, uma vez que o objetivo deste trabalho demonstrar os diversos tipos de aplicaes para otimizao do Proxy Squid, procurando a melhor soluo para desempenho do mesmo tornando-o to eficiente quanto o Dansguardian no processo de filtro de contedos, pois quando o Squid utiliza uma base muito extensa (Black-list), consequentemente passa a utilizar muita memria 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 caractersticas como: HTTP/1.1, FTP. Est pronto para ser usado imediatamente aps iniciado; seus armazenamentos em disco so checados em segundo plano, enquanto servem pedidos diretamente da rede; seus arquivos de configurao so fcies de ler e entender, controla a largura da banda de dados, possui um vasto modulo para a gerao de logs. (REIS, 2007). Tornando se assim um Proxy muito prestativo perante o seu funcionamento.

3.5 Microsoft Forefront Threat Management Gateway 2010

Soluo que a Empresa Americana mundialmente conhecida Microsoft, criou para seus clientes corporativos uma soluo de Proxy semelhante os de licena GNU (Software Livre). Forefront Threat Management Gateway 2010 um portal web seguro que oferece proteo abrangente contra ameaas baseadas na web, integrando mltiplas camadas de proteo em um sistema unificado, uma soluo fcil de usar. Forefront

17

TMG permite que os usurios usem de forma segura e produtiva a Internet para negcios sem se preocupar com ameaas de malware e outros. O Forefront TMG soluo inclui dois componentes: Forefront Threat Management Gateway 2010 Server: Fornece

filtragem de URL, inspeo antimalware, preveno de intruso, firewall de aplicao e de camada de rede e HTTP / HTTPS inspeo em uma nica soluo. Forefront Threat Management Gateway Servio de Proteo

Web: Fornece atualizaes contnuas para filtragem de malware e acesso a tecnologias baseadas em nuvem filtragem de URL agregados de mltiplos fornecedores de segurana da Internet para proteger contra as mais recentes ameaas baseadas na Web.

18

4.

O PROXY REVERSO

Segundo Filho: Um Proxy reverso tem como objetivo principal prover segurana 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 conexes originadas externamente so endereadas para um dos servidores Web atravs de um roteamento feito pelo servidor Proxy, que pode tratar ele mesmo a requisio ou, encaminhar a requisio toda ou parcialmente a um servidor Web que tratar a requisio. Podendo tambm bloquear por completo o pacote ao qual est sendo recebido pelo servidor, caso este seja algum possvel ataque ou acesso indevido das informaes. Um Proxy Reverso repassa o trfego de rede recebido para um conjunto de servidores, tornando-o a nica interface para as requisies 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 trfego de sada de uma rede, representando as requisies 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 requisies e delega as mesmas ou ento faz algo simples, como devolver uma pgina pr-processada, mas ele burro no sabe executar aquela requisio por completo, ele um Proxy no o servidor de verdade. (MACEDO, 2012).

19

4.1 Conceito de Proxy Reverso.

O termo Proxy um termo em ingls que significa fazer algo em favor de algum (NETO, 2009). Enquanto um Proxy, no modelo convencional, intercepta requisies originadas na rede local (LAN Local rea Network) com destino Internet, um Proxy Reverso intercepta requisies originadas na Internet com destino rede local. O trabalho exercido tanto por um Proxy convencional quanto por um Proxy reverso o mesmo: acessar o contedo que est sendo requisitado pelas mquinas clientes, impedindo que estas se comuniquem diretamente com o servidor que armazena tal contedo, resguardando assim, a identidade das mquinas 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 mquinas 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 Captulo 2.4 - Cenrio 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 esto conectados dentro de uma rede local.

Figura 5: Proxy Convencional. Fonte: Diego Macedo Analista de TI.

Os prximos tpicos deste captulo descrevem com maiores detalhes, o cenrio apresentado na figura 5 e quais so as vantagens em sua utilizao.

4.2 Utilizao de Proxy Reverso como servidores web.

O Proxy Reverso muito bem utilizado em uma topologia de rede quando apresentado o cenrio que Lopes comenta:
Para que o Proxy Reverso consiga interceptar as requisies originadas na Internet e repass-las aos servidores web que esto conectados na rede interna, necessrio que ele funcione como um servidor web, ou seja, o Proxy deve se passar por um servidor web

21

para conseguir centralizar todas as requisies e esconder, para quem est acessando a partir da Internet, informaes pertinentes a rede local. Da mesma maneira que o Proxy convencional oculta para os servidores web na Internet, informaes sobre as estaes na rede local, o Proxy Reverso oculta para as mquinas clientes que esto na Internet, informaes sobre os servidores web que esto conectados na rede local. (2006, p. 31).

Tornando assim um servidor seguro. As mquinas dos clientes, que esto na Internet, se conectam ao servidor Proxy Reverso como se ele fosse o prprio servidor web e o encaminham para o verdadeiro servidor web, sendo assim realizado de maneira transparente pelo Proxy, para a mquina cliente, sem que o prprio cliente imagine. (LOPES, 2006).

4.3 Forma de Funcionamento do Proxy Reverso.

De acordo com Lopes (2006), o Proxy Reverso mantm um bom funcionamento perante algum passos seguidos e uma boa configurao. Para que o Proxy Reverso possa se comportar como um servidor web fiel e fazer o correto direcionamento das requisies para os servidores web que realmente hospedam o contedo requisitado, as seguintes atividades precisam ser realizadas para uma topologia segura. Mapeamento da URL requisitada: a mquina cliente faz a

requisio assumindo que o Proxy Reverso o servidor web. Antes que o Proxy possa repassar a requisio para o servidor Web interno, a URL da requisio precisa ser convertida (mapeada) para refletir a URL do servidor interno; Adequao de campos no cabealho da requisio: assim como

acontece com a URL, alguns campos no cabealho HTTP tambm precisam ser reescritos para que possam referenciar corretamente ao servidor web interno. Um destes campos o host que responsvel

22

por transportar o host name e o nmero da porta da mquina que hospeda o recurso que est sendo requisitado Lopes (2006) ainda enfatiza as seguintes caractersticas descritas logo abaixo: Podem ainda ser configuradas em um servidor Proxy Reverso,

com o objetivo principal de reforar a segurana do ambiente, garantindo o controle e registro de todo o trfego que est sendo recebido e transmitido a partir do Proxy. Validao do contedo requisitado: todas as requisies

submetidas ao Proxy Reverso so inspecionadas a fim de certificar de que nenhum contedo malicioso est sendo transmitido.

Validao do contedo de resposta que so obtidas do servidor

web tambm precisam ser verificadas pelo Proxy reverso antes que ele as repasse para as mquinas clientes. Essa funcionalidade utilizada para bloquear respostas que no precisam ser visualizadas. E que podem revelar informaes da topologia da rede onde se encontra os servidores internos a um suposto intruso evitando assim um vazamento de informaes vitais para a segurana. Todos os filtros so armazenados em um banco de dados que consultado constantemente pelo Proxy Reverso. Por ltimo o registro em log das requisies dos clientes e

respostas do servidor: toda a comunicao que interceptada pelo Proxy Reverso registrada em arquivos de log que podem ser utilizados para analisar o contedo que est sendo requisitado e respondido pelo Proxy. Estes arquivos de log so teis para que os administradores de rede consigam ter um controle e acompanhamento das informaes que esto sendo disponibilizadas para a Internet, alm de facilitar a identificao de possveis 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 comparaes de teste de intruso no Capitulo Cinco (5).

4.5 O que Apache

Para termos uma anlise mais concreta nos remetemos a Kabir 2002: O apache um Servidor Web altamente configurvel, modular, simplesmente fcil de configurar e mais ainda de entender seus mais variados recursos. Qualquer pessoa com um pouco de experincia em programao C ou Perl j pode executar vrias funes 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 tambm o Windows. Criado pela NCSA no incio 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 vrias funes do Apache, ele tambm pode atuar como um Proxy Reverso fazendo assim a segurana de todos os Servidores Web. Segundo Kabir:

24

Quando esse tipo de servidor Proxy usado, os usurios normalmente no esto cientes deles, porque imaginam que esto acessando o recurso pretendido. Todas as solicitaes feitas pelos usurios so enviadas ao Proxy reverso, que serve a resposta a partir de seu cache ou solicitando informaes de outro host. (2002, p. 287).

Perante informaes alegadas por Teixeira: Suponha que exista um servidor chamado www.siteexemplo.dyndns.info, e que voc tenha uma pasta neste domnio chamada Cadastro que est hospedada em sua rede interna com o IP 192.168.1.112 onde o mesmo no ter acesso a rede externa, somente a Intranet. O Proxy Reverso atravs 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 requisio o endereo http://www.siteexemplo.dyndns.info/cadastro vai ser internamente convertido para uma requisio de Proxy para http://192.168.1.112/cadastro, acontecendo a mesma coisa quando houver o inverso. Para o usurio ele estar na mquina siteexemplo.dyndns.info, mais na realidade sem perceber ser direcionado para a mquina 192.168.1.112 Tornando assim um ambiente muito seguro para as aplicaes.

4.7 Benefcios do Proxy Reverso.

Seus benefcios so inmeros perante servidores web, tanto na segurana como na administrao, tornando os bem seguros e estveis, protegendo suas informaes e privacidades contidas nos servidores. Conforme descrito nos captulos anteriores, a nica interface para as requisies externas. Conforme Silva coloca como seus benefcios:
Roteamento de requisies externas; Segurana: 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 invs dos servidores internos; Balanceamento de carga: o servidor pode distribuir a carga para vrios servidores da rede; Cache: assim como o web proxy, o Proxy Reverso pode manter em cache o contedo esttico das requisies realizadas, ajudando assim a diminuir a carga dos servidores web; Compresso: o Proxy Reverso pode tornar o acesso mais rpido atravs da compresso do contedo acessado. (SILVA, 2011).

Trazendo assim estes benefcios ao ambiente ao qual o Proxy Reverso est atuando. No prximo capitulo ser apresentado um ambiente e ao qual sero realizados alguns testes de penetrao com alguns softwares do mercado.

26

5.

IMPLANTAO E VULNERABILIDADE

Conforme foram apresentadas as informaes sobre o Proxy Reverso nos captulos anteriores, neste capitulo ser abordada a configurao de um ambiente e tambm de testes de vulnerabilidade. Mostrando no final como a aplicao se comportara e o que a mesma ir expor. Segundo Giavaroto (2012) a identificao de vulnerabilidades, reduzem custos, retornos de investimentos, adoo de polticas com o intuito de fortalecer a segurana e o comprometimento da informao avaliando assim a segurana dos dispositivos e seus respectivos dados.

5.1 O Ambiente.

O ambiente para configuraes e testes do Proxy Reverso ser todo feito em maquina virtuais com o Virtual Box 4.2, sendo criado o cenrio com trs Servidores abaixo descritos: Server 1: Servidor Proxy Reverso Apache 2.2 instalado em um S.O Linux CentOS verso 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 Aplicao de Cadastro Apache 2.2 instalado em S.O Linux CentOS verso 6.4, ao qual ser um servidor de aplicao, rodando Apache 2.2, ao qual ter somente acesso Intranet sendo seu IP 192.168.1.112.

27

Server 3: Servidor de Aplicao de Pedidos Windows 2008 Server Standard rodando o ISS 7, ao qual ser um servidor de aplicao, tendo somente acesso Intranet sendo seu IP 192.168.1.113. Abaixo segue uma imagem do cenrio que ser usado para implantao do Proxy Reverso.

Figura 6: Ambiente Proxy Reverso siteexemplo.dyndns.info. Fonte: Autor.

5.2 Configurando o Proxy Reverso.

Conforme especificado o cenrio, agora chegada a hora de pr todas estas informaes em pratica. Depois de configurado toda a parte de Infraestrutura do servidor, instalado o Apache 2.2 no Servidor CentOS ao qual recebera a configurao do Proxy Reverso. O prximo passo ser configurar o Apache para atuar como Proxy Reverso.

28

As alteraes so feitas todas no arquivo de configurao do Apache, que encontrado no diretrio /etc/httpd/conf/httpd.conf . Procurar pelo trecho abaixo, descomentar as linhas necessrias e fazer suas devidas alteraes. ProxyRequests Off Caso esta linha fique como ProxyRequests On habilitara uma vulnerabilidade de segurana pro servidor, pois habilita o servidor proxy pra fazer solicitaes a outros servidores, ou seja, algum poder usar seu Servidor como um Proxy geral habilitado atravs do seu site. Abaixo uma, se no a mais importante alterao 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 no comentadas acima ativam o servio 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 configurao acima descrita feita a configurao de quais Servidores da rede interna o Proxy Reverso dar acesso a aplicao de um modo para o acesso externo, no caso abaixo quando alguma requisio chegar ao servidor com o endereo siteexemplo.dyndns.info/cadastro o mesmo ser redirecionado para o servidor na rede interna 192.168.1.112, e o mesmo acontece para o endereo siteexemplo.dyndns.info/pedido que tambm ser redirecionado para o servidor na rede interna 192.168.1.113. #Configuracao Proxy Reverso ProxyPass ProxyPass /cadastro /pedido http://192.168.1.112 http://192.168.1.112 http://192.168.1.113 http://192.168.1.113 ProxyPassReverse ProxyPassReverse /cadastro /pedido

Feitas estas modificaes o prximo passo salva-las e reiniciar o servio do Apache, para o mesmo se tornar um Proxy Apache Reverso. Para isso informado o comando: service httpd restart Aps reiniciar o servio, se as configurao estiverem corretas e os outros servidores da rede interna estiverem corretamente configurados e respectivamente suas aplicaes 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 endereos do navegador o respectivo endereo siteexemplo.dynnds.info/cadastro.

30

Pode se verificar na figura 7, que a pgina 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 execuo, ser solicitada uma pgina ao qual no existe no Servidor de Cadastro e este servidor ter que responder corretamente a requisio.

31

Figura 8: siteexemplo.dyndns.info/cadastro/teste. Fonte: Autor.

Como

se

pode

ver

ao

solicitar

pgina

siteexemplo.dyndns.info/cadastro/teste, o mesmo retorna a pgina de Error 404, ao qual refere-se a pgina de objeto no encontrado do Apache 2.2, que est em execuo 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 subttulo 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 pgina de Erro do ISS 7 do Windows Server 2008, solicitando uma pgina que no existe no respectivo servidor.

33

Figura 10: siteexemplo.dyndns.info/pedido/teste. Fonte: Autor.

Novamente com sucesso apresentado a pgina de erro do ISS 7, concretizando assim os teste de implantao do Servidor Proxy Reverso.

5.4 Teste de Vulnerabilidade

Para concluir este capitulo, iniciara-se um teste de vulnerabilidade para confirmar a segurana que o Proxy Reverso proporciona na proteo de Servidores de Aplicaes para Web. A ferramenta para teste escolhida ser o S.O Linux Back Track 5r3, uma verso de Linux baseado no Ubuntu, ao qual focado em teste de segurana e teste de penetraes, muito bem apreciado por hackers e analistas de segurana da informao.

34

Figura 11: Back Track 5r3. Fonte: Autor.

E ao qual esta ferramenta bem completa, j incorporada o METASPLOIT, que uma soluo incorporada com vrios cdigo maliciosos (exploits) preparados para testar e analisar se algum host est vulnervel a ataques. O exploits usado ser o Armitage, este um exploit ao qual vare host de Aplicaes Web e analisa suas respectivas portas, hosts internos e os servios que esto 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 no conseguiu localizar as outras maquinas, pois elas no tem acesso externo sendo somente atravs do proxy reverso ao qual libera os acessos as aplicaes. No prximo comando verifica-se os servios e as portas que host disponibiliza e ao qual por onde ele ir verificar as vulnerabilidades.

36

Figura 13: Servios. Fonte: Autor

O prximo passo o ataque ao host, verificado assim se existe alguma vulnerabilidade e a penetrao a os servidores da rede interna.

Figura 14: Ataque. Fonte: Autor

37

Se v na figura 14 que o Armitage executara vrios exploits e no obteve sucesso em nenhum deles, os resultados se encontram em anexo para maiores informaes e anlises de que o Proxy Reverso proporciona um ambiente seguro para as aplicaes web.

38

6.

CONSIDERAES FINAIS

O estudo realizado neste trabalho demonstrou a criao de ambiente com o Proxy Reverso, confirmando que o mesmo trouxe uma segurana aos sistemas web, mostrando que no possvel ver os servidores internos e trazendo tambm uma tima facilidade para os usurios. Atualmente cada vez mais os sistemas esto sendo migrados para a Web, necessitando assim maior segurana, e o Proxy Reverso proporciona est segurana que estava faltando. Como confirma Gartner Group, mais da metade de todos os problemas na internet esto relacionadas as aplicaes 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 vrios tipos de tecnologias, como o nosso cenrio ao qual foi utilizado servidores Linux e Windows. Conclui-se tambm que o Proxy Reverso mais uma ferramenta de proteo e ele sozinho, no substitui outros mecanismos como o firewall, IDS. Sendo assim realizar uma tima configurao de regras de firewall e de segurana da informao imprescindvel. Uma boa observao sobre o Proxy Reverso a otimizao e facilidade de administrao do mesmo, pois as configuraes so todas feitas em um nico servidor, tornando a vida dos Analistas bem melhor. Embora os exemplos tenham sido utilizado em laboratrio 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, Joo Eriberto Mota. Proxy reverso HTTP com Squid (verso 2.6 ou superior). Disponvel em <eriberto.pro.br/wiki/index.php?title=Proxy_reverso_HTTP_com_Squid_%28vers%C 3%A3o_2.6_ou_superior%29>. Acesso em: 10 agosto 2012.

GAVAROTO, Guilherme. O que Penetration Testing. Disponvel 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 Bblia. Rio de Janeiro: Campus, 2002.

LOPES, Leandro de Souza. Segurana em Servidores Web Utilizando Proxy Reverso. Uberlndia:, 2006.

MACEDO, Diego. Proxy Cache e Reverso. Disponvel 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. Disponvel em <www.microsoft.com/enus/server-cloud/forefront/threat-management-gateway.aspx> Acesso em: 22 setembro 2012.

MORIMOTO, Carlos E. Servidores Linux, Guia Prtico, So Paulo: Sulina, 2008.

NAKAMURA, Emilio Tissato. Segurana de Redes em Ambientes Corporativos, So Paulo: Novatec, 2010.

NETO, Alfredo Sabocinski. Proxy Reverso? O que danado isso?. Disponvel 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. Relatrio Demonstra Crescimento de Vulnerabilidades da Internet. Disponvel em <www.correiadasilva.com.br/pdf/info_dig/infodig03.pdf>. Acesso em: 20 maio 2012.

REDE SEGURA. Porque se preocupar com a Segurana das Aplicaes Web atualmente. Disponvel em http://keysupport.com.br/doc/%281%29_Por_que_se_preocupar_com_Seguranca_d e_Aplicacoes_Web.pdf. Acesso em: 10 abril 2013.

REIS, Cristiano F.; RAYMOND, Gerson; CARMO, Gilberto T. do. TCC Projeto Squid. Disponvel em <g2cinformatica.blogspot.com.br/2007/07/tcc-projetosquid_2719.html> . Acesso em: 13 agosto 2012.

SATO, Yutaka. DeleGate Home Page. Disponvel em <www.delegate.org/delegate/>. Acesso em: 11 setembro 2012.

SILVA, Natlia Vaz. Proxy Reverso com Apache. Disponvel 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). Disponvel 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.

APNDICES

Arquivo de configurao 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. admin@your-domain.com # 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 webmaster@dummy-host.example.com # 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

Reltorio 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 200.232.237.139 RHOST => 200.232.237.139 msf exploit(symantec_web_gateway_file_upload) > check [*] The target is not exploitable. exploit(symantec_web_gateway_file_upload) > set RHOST

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 200.232.237.139 RHOST => 200.232.237.139 msf exploit(symantec_web_gateway_pbcontrol) > check [*] The target is not exploitable. exploit(symantec_web_gateway_pbcontrol) > set RHOST

===== 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.

Potrebbero piacerti anche