Sei sulla pagina 1di 84
Fatec Ourinhos Donizete Fidelis PROXY REVERSO OURINHOS (SP) 2013

Fatec Ourinhos

Donizete Fidelis

PROXY REVERSO

OURINHOS (SP)

2013

DONIZETE FIDELIS

PROXY REVERSO

Trabalho de Graduação apresentado a Faculdade de Tecnologia de Ourinhos para conclusão do Curso de Segurança da Informação. Orientador: Prof. Alex Marino Gonçalves de Almeida.

OURINHOS (SP)

2013

Dedico este trabalho aos meus pais, minha namorada, cunhados e sobrinhos, pelo incentivo, cooperação e apoio e, em especial, à minha irmã Sônia e seu esposo; pois, além de terem me acolhido durante todo o curso, compartilharam comigo os momentos de tristezas e também de alegrias, nesta etapa, em que, com a graça de Deus, está sendo vencida.

Primeiramente, agradeço a Deus, meu mestre. Ao Prof. Alex Marino Gonçalves de Almeida, pela sabedoria e atenção com que conduziu a orientação este trabalho.

RESUMO

Cada vez mais o mundo corporativo na área de TI caminha para os sistemas web, pela facilidade de serem sistemas híbridos, sendo executados a partir de qualquer dispositivo como: celulares, palms, notebooks, tablets e desktops, através de um navegador padrão. Com esta reviravolta do cenário de TI, uma grande demanda da estrutura de segurança é necessária. Pois os dados das empresa já não estarão mais somente para acesso interno das informações e sim de qualquer lugar do mundo onde disponha de um acesso à internet. Podendo também uma gama de tecnologias de diferentes sistemas operacionais e linguagens de programação terem que trabalhar juntas, deixando assim a administração muito complexa. Sendo assim será criado um cenário de testes para enfatizar estas informações e demostrar que com o Proxy Reverso é possível ter um ambiente eficaz e seguro, mostrando suas configurações sendo implementadas no Apache.

Palavras-Chave; Apache, Proxy Reverso, Segurança.

ABSTRACT

Increasingly, the corporate world in the area of IT walks for the web systems, due to the ease of being hybrids, running from any devices like: phones, palms, laptops, tablets and desktops, through a standard browser. With this twist on the IT scene, a great demand of the security structure is necessary. For the data of the company will no longer be available only to internal access of the information but from anywhere in the world in which you have an internet access. It may also have a range of technologies from different operating systems and programming languages have to work together, making the administration very complex. Thus a test scenario to emphasize this information will be created and demonstrate that with the reverse proxy it is possible to have a safe and effective environment, showing the settings being implemented in Apache.

Keywords; Apache, Reverse Proxy, Security.

LISTA DE FIGURAS

Figura 1: Ambiente Sem Proxy

10

Figura 2: Ambiente Com Proxy

11

Figura 3: Ambiente Geral com Proxy

13

Figura 4: Proxy Convencional

19

Figura 5: Proxy Convencional

20

Figura 6: Ambiente Proxy Reverso siteexemplo.dyndns.info

27

Figura 7: siteexemplo.dyndns.info/cadastro

30

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

31

Figura 9: siteexemplo.dyndns.info/pedido

32

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

33

Figura 11: Back Track 5r3

34

Figura 12: Armitage

35

Figura 13: Serviços

36

Figura 14: Ataque

36

LISTA DE ABREVIATURAS E SIGLAS

ASP: Active Server Pages.

CRM: Customer Relationship Management.

FTP: File Transfer Protocol.

HTTP: HyperText Transfer Protocol.

HTTPS: HyperText Transfer Protocol Secure.

IDS: Intrusion Detection System

IP: Internet Protocol.

ISS: Internet Information Services.

LAN: Local Area Network.

NCSA: National Center for Supercomputing Applications.

PHP: Personal Home Page.

SGBD: Sistema de Gerenciamento de Banco de Dados.

SO: Sistema Operacional.

TI: Tecnologia da Informação.

URL: Uniform Resource Locator.

VM: Virtual Box.

SUMÁRIO

1. INTRODUÇÃO

5

 

Objetivos

6

Justificativa

7

Metodologia

8

2. APRESENTANDO O TERMO PROXY

9

2.1 Significado do Termo Proxy

9

2.2 Demanda de Servidores Proxy

10

2.3 Cenário sem Proxy

11

2.4 Cenário com Proxy

11

3. SOLUÇÕES PROXY DISPONÍVEIS NO

13

 

3.1 Squid

14

3.2 Delegate

15

3.3 Dansguardian

15

 

3.4 Oops

16

3.5 Microsoft Forefront Threat Management Gateway 2010

16

4. O PROXY REVERSO

18

4.1 Conceito de Proxy Reverso

19

4.2 Utilização de Proxy Reverso como servidores web

20

4.3 Forma de Funcionamento do Proxy

21

4.4 Apache como Proxy Reverso

23

4.5 O que é Apache

23

4.6 Apache atuando como Proxy

23

4.7 Benefícios do Proxy

24

5. IMPLANTAÇÃO E VULNERABILIDADE

26

5.1 O

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

7.

REFERENCIAS

39

8.

APÊNDICES

41

5

1.

INTRODUÇÃO

Atualmente, os ambientes de TI apresentam cada vez mais complexidade em elaborar novos sistemas cada vez mais robustos e ao mesmo tempo uma portabilidade acessível a várias plataformas e com isso houve uma grande demanda em aplicações desenvolvidas para trabalhar em um servidor web, que com isto obtém- se uma portabilidade com sucesso acessível geralmente em todos os Sistemas Operacionais encontrados no mercado, que por sua vez disponibiliza o acesso aos clientes que suportam o protocolo HTTP.

Entre estas tecnologias, destacam-se atualmente três plataformas: JAVA, Microsoft .NET e Ruby on Rails.

E conforme estas tecnologias vem sendo mais utilizadas, uma gama de vulnerabilidades surgem e com isso o tripé da Segurança da Informação que vem a ser: a confidencialidade, integridade e disponibilidade. Vem a ser ameaçado, contudo novas tecnologias surgem para garantir que a segurança das informações estejam sempre protegidas. Como no caso os Servidores Proxy.

Em um ambiente cliente/servidor as atenções normalmente estão direcionadas para o servidor, onde residem as informações e, portanto foco de ameaças. Os clientes na Web estão fora de nossa guarda e assim fora do nosso controle. A proteção do cliente, não é o grande objetivo, a não ser quando se trata de sua privacidade. Segurança no servidor Web consiste, em geral, em um ponto crítico em relação para algumas organizações que tem a Web a sua principal fonte de renda ou como para seu trabalho, no caso em algumas corporações 24 horas por dia e sete dia por semana.

A partir de tantas tecnologias disponíveis no mercado em soluções web, fica cada vez mais difícil de realizar um padrão de segurança da informação em cima dos serviços, pois cada tecnologia trabalha de um modo diferente e com isso brechas na segurança podem ocorrer normalmente, tornando a administração destes sistemas muito difícil para os administradores de redes.

Pois este cenário causa muito trabalho, ou seja, gera um alto nível de

complexidade nas organizações que tem que manter estes sistemas atualizados e

protegidos.

6

Objetivos

Este trabalho tem como principais objetivos, apresentar os Servidores Proxy existentes e as diferença entre Servidor Proxy Cache e Servidor Proxy Reverso. Também mostrar em um Ambiente Web, algumas análises sobre a segurança que um Servidor Proxy Reverso vem a exercer em um ambiente que utilize soluções web.

Este trabalho tem como objetivo específico, mostrar os benefícios de uma

corporação implementar um servidor Proxy Reverso para suas aplicações que utilizam

serviços web. O cenário abaixo descrito será utilizado para implantação:

Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, onde será

implantado o Proxy Reverso;

Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, ao qual será um

servidor de aplicação;

Windows 2008 Server Standard rodando o ISS com páginas ASP, ao qual

será um servidor de aplicação;

Suponhamos que este Servidor Windows esteja configurado e estão em

produção, só que com IP não roteável, ou seja, somente na rede interna.

A empresa necessita ter acesso externo a estes Servidores Windows e

CentOS que rodam suas aplicações, porem possui somente um IP público, com isso

o Apache que está rodando no Linux CentOS tem o um domínio válido e pode ter

acesso externo. Será usado o domínio de www.siteexemplo.dyndns.info como

exemplo.

A partir deste cenário será utilizado o Apache como Proxy Reverso para que

quando o Servidor de ISS ou do Apache receber alguma solicitação externa, o Proxy

Reverso, libere somente o acesso a uma porta específica. Ficando assim protegidos

quanto a ataques que poderiam interromper os serviços da mesma.

A estrutura desse trabalho se dará da seguinte forma: O presente documento encontrara-se divido em 7 (sete) capítulos: introdução, apresentando o termo Proxy, conhecendo algumas soluções, Proxy reverso, implantação do Proxy reverso, conclusão, e referências.

7

No primeiro capítulo apresenta-se a introdução fazendo um apanhado geral do tema, descrição dos objetivos, justificativa do trabalho, a metodologia que será utilizada e a explicação sobre a estrutura do trabalho.

Sobre o segundo capítulo aborda-se de um modo geral o conceito de Proxy.

No

terceiro

apresentadas.

capítulo,

algumas

soluções

de

Servidores

Proxy

serão

O quarto capítulo, submete as funcionalidade de um Servidor Proxy Reverso e os benefícios que o mesmo proporciona em um ambiente web.

O quinto capítulo será apresentado um cenário com o Proxy Reverso Implementado e com algumas ferramentas de análise de vulnerabilidades do mercado, veremos como o mesmo se comporta e a qual nível se consegue analisar as informações do servidor.

No sexto capítulo, argumentam-se as considerações finais fazendo uma síntese e um apanhado geral dos pontos mais importantes dos capítulos anteriores, de maneira a reforçar a ideia da utilização de um Servidor Proxy Reverso garantindo assim maior segurança ao ambiente.

Enfim, no sétimo capítulo serão citadas as referências da pesquisa do

trabalho.

Justificativa

Este trabalho mostrara a segurança que um Servidor Proxy Reverso tende a

criar em um ambiente que necessite de acesso externo, não adianta somente

implantar um Servidor de Firewall como principal fonte de proteção, pois a maioria dos

firewalls do mercado faz a filtragem de pacotes somente em cima de alguns campos

como exemplo no cabeçalho IP de origem, IP destino, porta origem, porta destino.

Se for autorizado o acesso a alguma porta específica do servidor, o mesmo

deixa o pacote passar, sem se preocupar com as informações contidas dentro que

poderia ser um ataque de algum hacker a um determinado serviço web da empresa e

com isto poderia causar a paralisação dos serviços, roubo de informações, alteração

8

de dados e outros problemas que podem ocorrer com o acesso indevido das

informações.

Metodologia

Para conseguir atingir os objetivos apresentados, este trabalho, uma vez

embasado em publicações como livros, artigos científicos e sites específicos, serão

apresentadas algumas tecnologias sobre Proxy.

Feito isso, irá tratar da segurança que um Servidor Proxy Reverso em um Ambiente Web proporciona, que é justamente o motivo ao qual se justifica este trabalho.

O cenário todo será elaborado e criado com máquinas virtuais utilizando a

tecnologia Oracle VM Virtual Box, ao qual serão feitas as instalações dos devidos

S.Os, configurações e seus devidos testes para comprovar a segurança que o Proxy

Reverso vem a agregar.

No último capítulo, serão feitas considerações finais para reforçar e justificar

tudo aquilo já demonstrado através das ideias e pensamentos já desenvolvidos ao

longo do trabalho.

9

2. APRESENTANDO O TERMO PROXY

Proxy é um servidor que atende a requisições repassando os dados a outros

servidores. Um usuário (cliente) conecta-se a um Servidor Proxy, requisitando algum

serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro

servidor.

O Proxy surgiu da necessidade de conectar uma rede local à Internet através

de um computador da rede que compartilha sua conexão com as máquinas da rede.

Se considerarmos que a rede local é uma rede interna e a Internet é uma rede externa,

podemos dizer que o Proxy é quem permite que outras máquinas tenham acesso

externo, ou seja, a conexão com a Internet. Geralmente, máquinas da rede interna

não possuem endereços válidos na Internet, primeiro pelo fato da segurança nas

redes privadas e também devido à falta de IP’s válidos, portanto, não têm uma

conexão direta com a Internet. Assim, toda solicitação de conexão de uma máquina

da rede local para um host da Internet é direcionada ao Proxy, este, por sua vez,

realiza o contato com o host desejado, repassando a resposta da solicitação para a

máquina da rede local. É comum termos o Proxy como conexão direta com a Internet.

2.1 Significado do Termo Proxy

Na área de TI, Proxy significa um programa ou um serviço que faz o papel de intermediário entre o cliente e o servidor, para acessar um determinado serviço.

Sobre estes aspectos de Servidor Proxy podemos nos remeter a Morimoto:

Um dos usos mais comuns e mais simples para um servidor Linux de rede local é simplesmente compartilhar a conexão. A vantagem de usar um servidor dedicado ao invés de simplesmente compartilhar usando o próprio modem ADSL é que você pode incluir outros serviços, como um cache de páginas (Squid), filtro de conteúdo (SquidGuard ou DansGuardian), firewall, servidor Samba (compartilhando arquivos com a rede interna), servidor de impressão e assim por diante. (2008, p.75).

10

O Proxy pode ser utilizado para várias aplicações como HTTP, HTTPS, FTP e outros, fazendo seu trabalho de interceptar as informações trafegadas e liberando as informações ao cliente ou as negando.

Sob estas expectativas:

O objetivo principal de um servidor proxy é possibilitar que máquinas de uma

rede privada possam acessar uma rede pública, como a Internet, sem que para isto tenham uma ligação direta com esta. O servidor proxy costuma ser instalado em uma máquina que tenha acesso direto à internet, sendo que as

demais efetuam as solicitações através desta. Justamente por isto este tipo

é chamado de Proxy, pois é um procurador, ou seja, sistema que faz solicitações em nome de outros. (ZANONI, 2007).

2.2 Demanda de Servidores Proxy

Para melhor análise podemos nos remetemos a Nakamura:

A tecnologia da informação é um instrumento cada vez mais utilizado pelo

homem, que busca incessantemente realizar seus trabalhos de modo mais fácil, mais rápido, mais eficiente e mais competitivo, produzindo, assim, os melhores resultados. A rede é uma das principais tecnologias, permitindo conexões entre todos os seus elementos, que vão desde roteadores até servidores que hospedam o website da organização e o banco de dados dos clientes, passando ainda por sistemas financeiros, de pagamentos e Customer Relationship Management (CRM). Esses recursos disponibilizados pela rede representam, na Era da informação, até mesmo o próprio negócio das organizações. Isso faz com que sua flexibilidade e facilidade de uso resultem de uso resultante em maior produtividade e na possibilidade de criação de novos serviços e produtos, e consequentemente em maiores

lucros para a organização. (2010, p. 43).

A exploração de vulnerabilidades em aplicações que usam ambientes web

aumenta a cada dia. Pois o número de vulnerabilidades aumenta de segundo em segundo com o crescimento da TI.

Vulnerabilidades – foram registradas 1.432 novas vulnerabilidades, um

crescimento em torno de 12% do total conferido no ano de 2002. 80 % das vulnerabilidades são exploradas remotamente, o que incrementou as ameaças de alto risco em 6%, e as de médio risco em, 24%. As vulnerabilidades em aplicações web cresceram 12% quando comparadas ao mesmo período do ano passado. Novamente, os sistemas Microsoft tiveram um grande número de vulnerabilidades exploradas, e também erros introduzidos em códigos de programas como Apache, Sendmail e OpenSSH.

(PEIXOTO, 2003).

E a cada ano mais e mais estes números tem tido um alto crescimento.

Perante estas ameaças o interessante para as empresa não é somente investir em

um servidor firewall, mais sim também em um servidor Proxy.

] [

11

2.3 Cenário sem Proxy

Na figura 1, mostra-se um exemplo clássico de uma rede, que está presente na maioria dos cenários e muitas vezes em empresas. Os clientes da rede tem total contato diretamente com a Internet, sem nenhum controle e nenhuma análise do tráfego dos pacotes que por ali trafegam.

análise do tráfego dos pacotes que por ali trafegam. Figura 1: Ambiente Sem Proxy. Fonte: Autor.

Figura 1: Ambiente Sem Proxy. Fonte: Autor.análise do tráfego dos pacotes que por ali trafegam. 2.4 Cenário com Proxy Na figura 2,

2.4 Cenário com Proxy

Na figura 2, mostra-se um exemplo básico de um servidor Proxy para serviço

de controle de tráfego da Internet em uma rede, usando o Squid. Os clientes da rede

interna não tem contato diretamente com a Internet.

12

12 Figura 2: Ambiente Com Proxy. Fonte: Autor. As requisições vão todas para o Servidor Proxy

Figura 2: Ambiente Com Proxy. Fonte: Autor.

As requisições vão todas para o Servidor Proxy que verifica todo o trafego, assim fazendo seu papel de autorizar ou restringir o acesso à determinada página da web.

No próximo capitulo deste trabalho será apresentado um breve resumo sobre alguma das principais tecnologias disponíveis no mercado.

13

3. SOLUÇÕES PROXY DISPONÍVEIS NO MERCADO.

Atualmente existem vários softwares com as características de Proxy, alguns mais especializados em somente alguns protocolos, outros com mais funcionalidades, em especial para o sistema operacional Linux e também algumas ferramentas para o Sistema Operacional Windows, com pelo menos suporte à HTTP, HTTPS.

Geralmente uma infraestrutura é apresentada conforme figura 3.

uma infraestrutura é apresentada conforme figura 3. Figura 3: Ambiente Geral com Proxy. Fonte: Oficina da

Figura 3: Ambiente Geral com Proxy.

Fonte: Oficina da Net.

Segue abaixo um breve resumo de variadas formas que um Proxy pode atuar e algumas orientações segundo REIS at al:

Web Proxy: Existe, ainda, um outro tipo de Proxy, os web proxies. Eles são uma versão que esconde o seu IP real e lhe permite navegar anonimamente. Muitos deles são utilizados em redes fechadas como universidades e ambientes de trabalho para burlar uma determinação de bloqueio a alguns sites da internet. Os conteúdos campeões de bloqueio são: sites de relacionamento (Orkut, facebook e outros), programas de troca de mensagem instantânea (Msn Messenger, Yahoo! Messenger e outros), sem contar os tão proibidos sites de pornografia.

Open Proxy: As conexões abertas de Proxy (open proxy) são o tipo mais perigoso e convidativo aos crackers e usuários mal intencionados. Quando um destes usuários consegue acessar um computador, instala um servidor Proxy nele para que possa entrar quando quiser na máquina e promover diversos tipos de ilegalidade

14

como scripts que roubam senhas de bancos, fraudes envolvendo cartões de crédito e uma grande variedade de atos ilegais.

Redes Proxy: As redes Proxy são baseadas em códigos cifrados que permitem a comunicação anônima entre os usuários. Exemplo deste tipo de rede são as conexões P2P (peer to peer) em que um usuário se conecta ao outro sem saber sua identidade e trocam arquivos entre si. Estas redes se caracterizam por não permitirem o controle dos servidores, os usuários comuns é quem providenciam todo o conteúdo e os arquivos. Certamente, muitos destes computadores são usados por pessoas mal intencionadas com segundas intenções. Por isso, deve-se ter em mente que qualquer promessa de privacidade e segurança é mais do que rara. (REIS at al, 2007).

Conforme citado por Thoeny (2002, apud REIS at al, 2007) “destaca-se Squid, Delegate, Dansguardian, Oops entre outros”.

3.1 Squid

Praticamente um dos Proxy mais utilizado no mundo.

Foi originado de um projeto denominado Harvest entre o governo americano e a Universidade de Colorado. Atualmente é o Proxy mais popular e mais usado como controle de conteúdo, na qual possui vários programadores como desenvolvedores do projeto pelo mundo. É geralmente disponibilizado por padrão pela maioria dos sistemas operacionais Linux, fornecendo todas as funcionalidades de um Proxy comum. Permite atuar como Proxy para os protocolos HTTPS, HTTP, FTP.

Sua principal utilidade é de filtrar e definir regras para o acesso à web, sua principal vantagem vem a função cache, a mesma guarda no cache os sites acessados, quando o acesso a um site presente no cache é solicitado, automaticamente é retornado ao usuário o site do cache. (VILELLA, 2010).

Tornando assim a resposta ao usuário muito mais rápida e eficiente e também uma economia de banda.

15

3.2 Delegate

Este também é um Proxy interessante, O Delegate interliga uma comunicação entre usuários e clientes, onde uma comunicação direta é impossível, ineficiente, ou inconveniente.

Perante Sato:

Delegate é um multi - propósito de gateway em nível de aplicação, ou um servidor proxy que funciona em várias plataformas (Unix, Windows, MacOS X e OS / 2). Delegate mede a comunicação de vários protocolos (HTTP, FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, SOCKS, DNS, etc.), a aplicação de cache e conversão de dados, que controlam o acesso de clientes e o encaminhamento para os servidores. Ele traduz protocolos entre clientes e servidores, aplicando SSL (TLS) para protocolos arbitrários, convertendo entre IPv4 e IPv6, mesclando vários servidores em um único servidor com analise e filtragem. Nascido como um proxy pequeno para Gopher março 1994, tem crescido constantemente em um servidor de propósito geral proxy. Além de ser um proxy, delegate pode ser usado como um servidor de origem simples para alguns protocolos (HTTP, FTP e NNTP). (SATO, 2010).

3.3 Dansguardian

É uma ferramenta capaz de filtrar acessos a Internet com base em diferentes critérios.

Segundo palavras de Reis:

A ferramenta difere da maioria disponível no mercado pelo fato de não

funcionar apenas como filtro de URL, mas também como um efetivo filtro de conteúdo de páginas Web. Pois, faz uma varredura do conteúdo de cada página acessada por seus usuários e não somente uma liberação ou proibição do nome do site ou da URL acessada. Este filtro de conteúdo funciona em conjunto com qualquer Proxy, podendo

ser instalado em sistemas operacionais Linux, FreeBSD, OpenBSD, NetBSD, Mac OSX e Solaris.O Dansguardian não tem características de Proxy, portanto é obrigatório o uso de um servidor Proxy para que

a ferramenta seja implementada, embora ele tenha sido citado neste

trabalho por ser relevante suas funções. Nas soluções comumente encontradas no mercado, o filtro de conteúdo recebe as requisições

16

do navegador do usuário, aplica as restrições estabelecidas ou as exceções configuradas e, em seguida, passa a requisição para o Proxy. Este faz o seu papel que é a intermediação entre o cliente e o servidor a ser acessado. No processamento interno de arquivos contendo proibições e exceções, existe uma ordem pré-estabelecida. Apesar do Dansguardian não ter características de Proxy o mesmo foi citado apenas para fim de conhecimento, uma vez que o objetivo deste trabalho é demonstrar os diversos tipos de aplicações para otimização do Proxy Squid, procurando a melhor solução para desempenho do mesmo tornando-o tão eficiente quanto o Dansguardian no processo de filtro de conteúdos, pois quando o Squid utiliza uma base muito extensa (Black-list), consequentemente passa a utilizar muita memória e se torna lento demais sobrecarregando consideravelmente a rede.

(REIS, 2007)

3.4 Oops

É um Proxy mais simples que os anteriores. Surgiu como uma alternativa ao uso do Squid. Oops é leve, embora, trata-se de um poderoso Proxy com cache e com grandes características como: HTTP/1.1, FTP. Está pronto para ser usado imediatamente após iniciado; seus armazenamentos em disco são checados em segundo plano, enquanto servem pedidos diretamente da rede; seus arquivos de configuração são fácies de ler e entender, controla a largura da banda de dados, possui um vasto modulo para a geração de logs. (REIS, 2007).

Tornando se assim um Proxy muito prestativo perante o seu funcionamento.

3.5 Microsoft Forefront Threat Management Gateway 2010

Solução que a Empresa Americana mundialmente conhecida Microsoft, criou para seus clientes corporativos uma solução de Proxy semelhante à os de licença GNU (Software Livre).

Forefront Threat Management Gateway 2010 é um portal web seguro que oferece proteção abrangente contra ameaças baseadas na web, integrando múltiplas camadas de proteção em um sistema unificado, uma solução fácil de usar. Forefront

17

TMG permite que os usuários usem de forma segura e produtiva a Internet para negócios sem se preocupar com ameaças de malware e outros.

O Forefront TMG solução inclui dois componentes:

Forefront Threat Management Gateway 2010 Server: Fornece

filtragem de URL, inspeção antimalware, prevenção de intrusão, firewall

de aplicação e de camada de rede e HTTP / HTTPS inspeção em uma única solução.

Forefront Threat Management Gateway Serviço de Proteção

Web: Fornece atualizações contínuas para filtragem de malware e acesso a tecnologias baseadas em nuvem filtragem de URL agregados de múltiplos fornecedores de segurança da Internet para proteger contra as mais recentes ameaças baseadas na Web.

18

4. O PROXY REVERSO

Segundo Filho:

Um Proxy reverso tem como objetivo principal prover segurança ao servidor, evitando que os clientes tenham contato direto com ele. Todo servidor deve ter um Proxy reverso à sua frente. (FILHO, 2008).

Um Proxy Reverso é um servidor de rede geralmente instalado para ficar na

frente de um servidor Web. Todas as conexões originadas externamente são

endereçadas para um dos servidores Web através de um roteamento feito pelo

servidor Proxy, que pode tratar ele mesmo a requisição ou, encaminhar a requisição

toda ou parcialmente a um servidor Web que tratará a requisição.

Podendo também bloquear por completo o pacote ao qual está sendo

recebido pelo servidor, caso este seja algum possível ataque ou acesso indevido das

informações.

Um Proxy Reverso repassa o tráfego de rede recebido para um conjunto de

servidores, tornando-o a única interface para as requisições externas. Por exemplo,

um Proxy Reverso pode ser usado para balancear a carga de um cluster de servidores

Web. O que é exatamente o oposto de um Proxy convencional que age como um

despachante para o tráfego de saída de uma rede, representando as requisições dos

clientes internos para os servidores externos a rede a qual o servidor Proxy atende.

Sob esta perspectiva Macedo alega que:

Proxy Reverso nada mais é do que um servidor “burro” que apenas recebe requisições e delega as mesmas ou então faz algo simples, como devolver uma página pré-processada, mas ele é “burro” não sabe executar aquela requisição por completo, ele é um Proxy não é o servidor de verdade. (MACEDO, 2012).

19

4.1 Conceito de Proxy Reverso.

O termo “Proxy é um termo em inglês que significa fazer algo em favor de

alguém” (NETO, 2009).

Enquanto um Proxy, no modelo convencional, intercepta requisições originadas na rede local (LAN – Local Área Network) com destino à Internet, um Proxy Reverso intercepta requisições originadas na Internet com destino à rede local.

O trabalho exercido tanto por um Proxy convencional quanto por um Proxy

reverso é o mesmo: acessar o conteúdo que está sendo requisitado pelas máquinas clientes, impedindo que estas se comuniquem diretamente com o servidor que armazena tal conteúdo, resguardando assim, a identidade das máquinas clientes. O que diferencia os dois modelos de Proxy é onde o cliente está localizado, pois, no modelo utilizando Proxy convencional, o cliente se encontra dentro da rede interna e já no Proxy Reverso, o cliente está conectado à Internet.

A figura 4 mostra uma topologia de rede onde é utilizado um Proxy

convencional para fornecer acesso web para as máquinas clientes conectada na rede local.

acesso web para as máquinas clientes conectada na rede local. Figura 4: Proxy Convencional. Fonte: Oficina

Figura 4: Proxy Convencional. Fonte: Oficina da Net.

20

O funcionamento do Proxy convencional apresentado na figura 4 é descrito no “Capítulo 2.4 - Cenário com Proxy”.

Na figura 5 é apresentada uma topologia de rede que utiliza a estrutura de Proxy Reverso para permitir o acesso a partir da Internet a servidores web que estão conectados dentro de uma rede local.

web que estão conectados dentro de uma rede local. Figura 5: Proxy Convencional. Fonte: Diego Macedo

Figura 5: Proxy Convencional.

Fonte: Diego Macedo – Analista de TI.

Os próximos tópicos deste capítulo descrevem com maiores detalhes, o cenário apresentado na figura 5 e quais são as vantagens em sua utilização.

4.2 Utilização de Proxy Reverso como servidores web.

O Proxy Reverso é muito bem utilizado em uma topologia de rede quando é apresentado o cenário que Lopes comenta:

Para que o Proxy Reverso consiga interceptar as requisições originadas na Internet e repassá-las aos servidores web que estão conectados na rede interna, é necessário que ele funcione como um servidor web, ou seja, o Proxy deve se passar por um servidor web

21

para conseguir centralizar todas as requisições e esconder, para quem está acessando a partir da Internet, informações pertinentes a rede local. Da mesma maneira que o Proxy convencional oculta para os servidores web na Internet, informações sobre as estações na rede local, o Proxy Reverso oculta para as máquinas clientes que estão na Internet, informações sobre os servidores web que estão conectados na rede local. (2006, p. 31).

Tornando assim um servidor seguro.

As máquinas dos clientes, que estão na Internet, se conectam ao servidor Proxy Reverso como se ele fosse o próprio servidor web e o encaminham para o verdadeiro servidor web, sendo assim realizado de maneira transparente pelo Proxy, para a máquina cliente, sem que o próprio cliente imagine. (LOPES, 2006).

4.3 Forma de Funcionamento do Proxy Reverso.

De acordo com Lopes (2006), o Proxy Reverso mantém um bom funcionamento perante algum passos seguidos e uma boa configuração. Para que o Proxy Reverso possa se comportar como um servidor web fiel e fazer o correto direcionamento das requisições para os servidores web que realmente hospedam o conteúdo requisitado, as seguintes atividades precisam ser realizadas para uma topologia segura.

Mapeamento da URL requisitada: a máquina cliente faz a

requisição assumindo que o Proxy Reverso é o servidor web. Antes que o Proxy possa repassar a requisição para o servidor Web interno, a URL da requisição precisa ser convertida (mapeada) para refletir a URL do servidor interno;

Adequação de campos no cabeçalho da requisição: assim como

acontece com a URL, alguns campos no cabeçalho HTTP também precisam ser reescritos para que possam referenciar corretamente ao servidor web interno. Um destes campos é o “host” que é responsável

22

por transportar o host name e o número da porta da máquina que hospeda o recurso que está sendo requisitado

Lopes (2006) ainda enfatiza as seguintes características descritas logo

abaixo:

Podem ainda ser configuradas em um servidor Proxy Reverso,

com o objetivo principal de reforçar a segurança do ambiente, garantindo o controle e registro de todo o tráfego que está sendo recebido e

transmitido a partir do Proxy.

Validação do conteúdo requisitado: todas as requisições

submetidas ao Proxy Reverso são inspecionadas a fim de certificar de

que nenhum conteúdo malicioso está sendo transmitido.

Validação do conteúdo de resposta que são obtidas do servidor

web também precisam ser verificadas pelo Proxy reverso antes que ele as repasse para as máquinas clientes. Essa funcionalidade é utilizada

para bloquear respostas que não precisam ser visualizadas. E que podem revelar informações da topologia da rede onde se encontra os servidores internos a um suposto intruso evitando assim um vazamento de informações vitais para a segurança. Todos os filtros são armazenados em um banco de dados que é consultado constantemente pelo Proxy Reverso.

Por último o registro em log das requisições dos clientes e

respostas do servidor: toda a comunicação que é interceptada pelo Proxy Reverso é registrada em arquivos de log que podem ser utilizados para analisar o conteúdo que está sendo requisitado e respondido pelo Proxy. Estes arquivos de log são úteis para que os administradores de rede consigam ter um controle e acompanhamento das informações que estão sendo disponibilizadas para a Internet, além de facilitar a identificação de possíveis incidentes.

23

4.4 Apache como Proxy Reverso.

Neste subcapitulo será apresentado o modo de funcionamento do Apache como Proxy Reverso, ao qual será utilizado para as comparações de teste de intrusão no Capitulo Cinco (5).

4.5 O que é Apache

Para termos uma análise mais concreta nos remetemos a Kabir 2002: O

apache é um Servidor Web altamente configurável, modular, simplesmente fácil de

configurar e mais ainda de entender seus mais variados recursos. Qualquer pessoa

com um pouco de experiência em programação C ou Perl já pode executar várias

funções

com

o

mesmo, o

mais

importe é que

ele

é

gratuito e aberto para

desenvolvimento, funcionando muito bem com Perl, PHP e outras linguagens de

scripts.

Seu funcionamento perante aos S.Os Linux e outros sistemas como FreeBSD,

Solaris, Mac OS e também o Windows.

Criado pela NCSA no início de 1995 e até os dias de hoje se encontra entre

os melhores servidores para Web.

4.6 Apache atuando como Proxy Reverso.

Entre as várias funções do Apache, ele também pode atuar como um Proxy Reverso fazendo assim a segurança de todos os Servidores Web. Segundo Kabir:

24

Quando esse tipo de servidor Proxy é usado, os usuários normalmente não estão cientes deles, porque imaginam que estão acessando o recurso pretendido. Todas as solicitações feitas pelos usuários são enviadas ao Proxy reverso, que serve a resposta a partir de seu cache ou solicitando informações de outro host. (2002, p. 287).

Perante informações alegadas por Teixeira:

Suponha que exista um servidor chamado www.siteexemplo.dyndns.info, e que você tenha uma pasta neste domínio chamada Cadastro que está hospedada em sua rede interna com o IP 192.168.1.112 onde o mesmo não terá acesso a rede externa, somente a Intranet. O Proxy Reverso através do comando ProxyPass /cadastro http://192.168.1.112/cadastro, o transformando em http://www.siteexemplo.dyndns.info/cadastro.

Fazem com que o Apache ajuste a URL com as peculiaridades do pacote HTTP como se ele fosse location, ajustando assim seus headers, sendo assim quando há uma requisição o endereço http://www.siteexemplo.dyndns.info/cadastro vai ser internamente convertido para uma requisição de Proxy para http://192.168.1.112/cadastro, acontecendo a mesma coisa quando houver o inverso. Para o usuário ele estará na máquina siteexemplo.dyndns.info, mais na realidade sem perceber será direcionado para a máquina 192.168.1.112 Tornando assim um ambiente muito seguro para as aplicações.

4.7 Benefícios do Proxy Reverso.

Seus benefícios são inúmeros perante servidores web, tanto na segurança como na administração, tornando os bem seguros e estáveis, protegendo suas informações e privacidades contidas nos servidores. Conforme descrito nos capítulos anteriores, é a única interface para as requisições externas.

Conforme Silva coloca como seus benefícios:

Roteamento de requisições externas;

Segurança: como o Proxy é a única interface externa da rede, ele "esconde" os demais servidores;

25

Criptografia: a criptografia SSL pode ser delegada ao proxy ao invés dos servidores internos;

Balanceamento de carga: o servidor pode distribuir a carga para vários servidores da rede;

Cache: assim como o web proxy, o Proxy Reverso pode manter em cache o conteúdo estático das requisições realizadas, ajudando assim a diminuir a carga dos servidores web;

Compressão: o Proxy Reverso pode tornar o acesso mais rápido através da compressão do conteúdo acessado. (SILVA, 2011).

Trazendo assim estes benefícios ao ambiente ao qual o Proxy Reverso está atuando. No próximo capitulo será apresentado um ambiente e ao qual serão realizados alguns testes de penetração com alguns softwares do mercado.

26

5. IMPLANTAÇÃO E VULNERABILIDADE

Conforme foram apresentadas as informações sobre o Proxy Reverso nos capítulos anteriores, neste capitulo será abordada a configuração de um ambiente e também de testes de vulnerabilidade.

Mostrando no final como a aplicação se comportara e o que a mesma irá

expor.

Segundo Giavaroto (2012) a identificação de vulnerabilidades, reduzem custos, retornos de investimentos, adoção de políticas com o intuito de fortalecer a segurança e o comprometimento da informação avaliando assim a segurança dos dispositivos e seus respectivos dados.

5.1 O Ambiente.

O ambiente para configurações e testes do Proxy Reverso será todo feito em maquina virtuais com o Virtual Box 4.2, sendo criado o cenário com três Servidores abaixo descritos:

Server 1: Servidor Proxy Reverso

Apache 2.2 instalado em um S.O Linux CentOS versão 6.4, onde será

implantado Apache 2.2 sendo configurado como Proxy Reverso, sendo configurado o DNS para acesso externo (siteexemplo.dyndns.info) sendo seu IP da Intranet

192.168.1.111.

Server 2: Servidor de Aplicação de Cadastro

Apache 2.2 instalado em S.O Linux CentOS versão 6.4, ao qual será um servidor de aplicação, rodando Apache 2.2, ao qual terá somente acesso à Intranet sendo seu IP 192.168.1.112.

27

Server 3: Servidor de Aplicação de Pedidos

Windows 2008 Server Standard rodando o ISS 7, ao qual será um servidor de aplicação, tendo somente acesso à Intranet sendo seu IP 192.168.1.113.

Abaixo segue uma imagem do cenário que será usado para implantação do Proxy Reverso.

que será usado para implantação do Proxy Reverso. Figura 6: Ambiente Proxy Reverso siteexemplo.dyndns.info.

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

5.2 Configurando o Proxy Reverso.

Conforme especificado o cenário, agora é chegada a hora de pôr todas estas informações em pratica. Depois de configurado toda a parte de Infraestrutura do servidor, é instalado o Apache 2.2 no Servidor CentOS ao qual recebera a configuração do Proxy Reverso. O próximo passo será configurar o Apache para atuar como Proxy Reverso.

28

As alterações são feitas todas no arquivo de configuração do Apache, que é encontrado no diretório “ /etc/httpd/conf/httpd.conf ”. Procurar pelo trecho abaixo, descomentar as linhas necessárias e fazer suas devidas alterações.

“ProxyRequests Off” Caso esta linha fique como “ProxyRequests On” habilitara uma vulnerabilidade de segurança pro servidor, pois habilita o servidor proxy pra fazer solicitações a outros servidores, ou seja, alguém poderá usar seu Servidor como um Proxy geral habilitado através do seu site.

Abaixo uma, se não a mais importante alteração a ser feita no arquivo.

<IfModule mod_proxy.c> ProxyRequests Off # <Proxy *> Order deny,allow # Deny from all Allow from all </Proxy> # # Enable/disable the handling of HTTP/1.1 "Via:" headers. # ("Full" adds the server version; "Block" removes all outgoing Via:

headers) # Set to one of: Off | On | Full | Block # ProxyVia On

Estas linhas não comentadas acima ativam o serviço do Apache e o transformam em um Servidor Apache Proxy Reverso. Ao qual refere-se ao tema que estamos abordando.

29

Logo mais abaixo da configuração acima descrita é feita a configuração de quais Servidores da rede interna o Proxy Reverso dará acesso a aplicação de um modo para o acesso externo, no caso abaixo quando alguma requisição chegar ao servidor com o endereço “siteexemplo.dyndns.info/cadastro” o mesmo será redirecionado para o servidor na rede interna 192.168.1.112, e o mesmo acontece para o endereço “siteexemplo.dyndns.info/pedido” que também será redirecionado para o servidor na rede interna 192.168.1.113.

#Configuracao Proxy Reverso ProxyPass /cadastro http://192.168.1.112 ProxyPassReverse /cadastro http://192.168.1.112 ProxyPass /pedido http://192.168.1.113 ProxyPassReverse /pedido http://192.168.1.113

Feitas estas modificações o próximo passo é salva-las e reiniciar o serviço do Apache, para o mesmo se tornar um Proxy Apache Reverso. Para isso é informado o comando:

service httpd restart Após reiniciar o serviço, se as configuração estiverem corretas e os outros servidores da rede interna estiverem corretamente configurados e respectivamente suas aplicações inicializadas, o Proxy Reverso estará em pleno funcionamento.

5.3 Testando o Proxy Reverso

Neste momento depois de configurado o Proxy Reverso é chegada a hora de realizar alguns testes de ver se o mesmo está em pleno funcionamento.

5.3.1 Testando siteexemplo.dyndns.info/cadastro

Primeiro será testado o Servidor de Cadastro, para isso é digitado na barra de endereços do navegador o respectivo endereço “siteexemplo.dynnds.info/cadastro”.

30

Pode se verificar na figura 7, que a página que está localizado no Servidor 192.168.1.112 abriu como “siteexemplo.dyndns.info/cadastro”.

abriu como “siteexemplo.dyndns.info/cadastro”. Figura 7: siteexemplo.dyndns.info/cadastro. Fonte: Autor.

Figura 7: siteexemplo.dyndns.info/cadastro. Fonte: Autor.

Para confirmar que o Proxy Reverso está em execução, será solicitada uma página ao qual não existe no Servidor de Cadastro e este servidor terá que responder corretamente a requisição.

31

31 Figura 8: siteexemplo.dyndns.info/cadastro/teste. Fonte: Autor. página siteexemplo.dyndns.info/cadastro/teste, o mesmo

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

página

siteexemplo.dyndns.info/cadastro/teste, o mesmo retorna a página de Error 404, ao qual refere-se a página de objeto não encontrado do Apache 2.2, que está em

execução no IP 192.168.1.112 ao qual é o Servidor de Cadastro.

Como

se

pode

ver

ao

solicitar

a

5.3.2 Testando siteexemplo.dyndns.info/pedido

O mesmo processo realizado no subtítulo 5.3.1 acima será executado com o Servidor de Pedido siteexemplo.dyndns.info/pedido

32

32 Figura 9: siteexemplo.dyndns.info/pedido. Fonte: Autor. Depois de analisar que o mesmo está em pleno funcionamento,

Figura 9: siteexemplo.dyndns.info/pedido. Fonte: Autor.

Depois de analisar que o mesmo está em pleno funcionamento, veremos se o mesmo reponde com a página de Erro do ISS 7 do Windows Server 2008, solicitando uma página que não existe no respectivo servidor.

33

33 Figura 10: siteexemplo.dyndns.info/pedido/teste. Fonte: Autor. Novamente com sucesso é apresentado a página de erro

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

Novamente com sucesso é apresentado a página de erro do ISS 7, concretizando assim os teste de implantação do Servidor Proxy Reverso.

5.4 Teste de Vulnerabilidade

Para concluir este capitulo, iniciara-se um teste de vulnerabilidade para confirmar a segurança que o Proxy Reverso proporciona na proteção de Servidores de Aplicações para Web.

A ferramenta para teste escolhida será o S.O Linux Back Track 5r3, uma versão de Linux baseado no Ubuntu, ao qual é focado em teste de segurança e teste de penetrações, muito bem apreciado por hackers e analistas de segurança da informação.

34

34 Figura 11: Back Track 5r3. Fonte: Autor. E ao qual esta ferramenta é bem completa,

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

E ao qual esta ferramenta é bem completa, já é incorporada o METASPLOIT, que é uma solução incorporada com vários código maliciosos (exploits) preparados para testar e analisar se algum host está vulnerável a ataques.

O exploits usado será o Armitage, este é um exploit ao qual vare host de Aplicações Web e analisa suas respectivas portas, hosts internos e os serviços que estão sendo executados.

Veremos se essa ferramenta consegue localizar os servidores internos de cadastro e pedido.

35

35 Figura 12: Armitage. Fonte: Autor Como pode se ver na figura 12, foi adicionado o

Figura 12: Armitage. Fonte: Autor

Como pode se ver na figura 12, foi adicionado o host siteexemplo.dyndns.info,

o exploit varreu toda a rede conseguindo assim o IP externo e o IP interno ao qual está instalado o Proxy Apache Reverso, sendo visto que o mesmo não conseguiu localizar as outras maquinas, pois elas não tem acesso externo sendo somente através do proxy reverso ao qual libera os acessos as aplicações.

No próximo comando verifica-se os serviços e as portas que host disponibiliza

e ao qual por onde ele irá verificar as vulnerabilidades.

36

36 Figura 13: Serviços. Fonte: Autor O próximo passo é o ataque ao host, verificado assim

Figura 13: Serviços. Fonte: Autor

O próximo passo é o ataque ao host, verificado assim se existe alguma vulnerabilidade e a penetração a os servidores da rede interna.

assim se existe alguma vulnerabilidade e a penetração a os servidores da rede interna. Figura 14:

Figura 14: Ataque. Fonte: Autor

37

Se vê na figura 14 que o Armitage executara vários exploits e não obteve sucesso em nenhum deles, os resultados se encontram em anexo para maiores informações e análises de que o Proxy Reverso proporciona um ambiente seguro para as aplicações web.

38

6. CONSIDERAÇÕES FINAIS

O estudo realizado neste trabalho demonstrou a criação de ambiente com o Proxy Reverso, confirmando que o mesmo trouxe uma segurança aos sistemas web, mostrando que não é possível ver os servidores internos e trazendo também uma ótima facilidade para os usuários.

Atualmente cada vez mais os sistemas estão sendo migrados para a Web, necessitando assim maior segurança, e o Proxy Reverso proporciona está segurança que estava faltando.

Como confirma Gartner Group, mais da metade de todos os problemas na internet estão relacionadas as aplicações web.

Desde ferramentas gratuitas que podem ser baixadas na internet até ferramentas de alto valor aquisitivos disponibilizam o Proxy Reverso. E o melhor ele pode ser implementado com vários tipos de tecnologias, como o nosso cenário ao qual foi utilizado servidores Linux e Windows.

Conclui-se também que o Proxy Reverso é mais uma ferramenta de proteção

e ele sozinho, não substitui outros mecanismos como o firewall, IDS. Sendo assim

realizar uma ótima configuração de regras de firewall e de segurança da informação

é imprescindível.

Uma boa observação sobre o Proxy Reverso é a otimização e facilidade de administração do mesmo, pois as configurações são todas feitas em um único servidor, tornando a vida dos Analistas bem melhor.

Embora os exemplos tenham sido utilizado em laboratório apenas a ferramenta Apache, os conceitos apresentados neste trabalho, valem para qualquer

ferramenta que possui a funcionalidade de Proxy Reverso, pois seu modo de conceito

é praticamente o mesmo em outras ferramentas.

39

7.

REFERENCIAS

FILHO, João Eriberto Mota. Proxy reverso HTTP com Squid (versão 2.6 ou superior). Disponível em

<eriberto.pro.br/wiki/index.php?title=Proxy_reverso_HTTP_com_Squid_%28vers%C

3%A3o_2.6_ou_superior%29>. Acesso em: 10 agosto 2012.

GAVAROTO, Guilherme. O que è Penetration Testing. Disponível em < http://www.backtrackbrasil.com.br/site/2012/05/o-que-e-penetration-testing/> Acesso em: 22 abril 2013.

KABIR, Mohammed J. Apache Server 2 a Bíblia. Rio de Janeiro: Campus, 2002.

LOPES, Leandro de Souza. Segurança em Servidores Web Utilizando Proxy Reverso. Uberlândia:, 2006.

MACEDO, Diego. Proxy Cache e Reverso. Disponível em <www.diegomacedo.com.br/proxy-cache-e-reverso/>. Acesso em: 25 de agosto

2012.

MICROSOFT FOREFRONT THREAT MANAGEMENT GATEWAY. Forefront Threat Management Gateway 2010. Disponível em <www.microsoft.com/en- us/server-cloud/forefront/threat-management-gateway.aspx> Acesso em: 22 setembro 2012.

MORIMOTO, Carlos E. Servidores Linux, Guia Prático, São Paulo: Sulina, 2008.

NAKAMURA, Emilio Tissato. Segurança de Redes em Ambientes Corporativos, São Paulo: Novatec, 2010.

NETO, Alfredo Sabocinski. Proxy Reverso? O que danado é isso?. Disponível em

<alfredosabo.blogspot.com.br/2009/05/proxy-reverso-o-que-danado-e-isso.html>.

Acesso em: 23 setembro 2012.

40

PEIXOTO, Rodney de Castro. Relatório Demonstra Crescimento de Vulnerabilidades da Internet. Disponível em <www.correiadasilva.com.br/pdf/info_dig/infodig03.pdf>. Acesso em: 20 maio 2012.

REDE SEGURA. Porque se preocupar com a Segurança das Aplicações Web atualmente. Disponível em

http://keysupport.com.br/doc/%281%29_Por_que_se_preocupar_com_Seguranca_d

e_Aplicacoes_Web.pdf. Acesso em: 10 abril 2013.

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

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

SILVA, Natália Vaz. Proxy Reverso com Apache. Disponível em < www.vivaolinux.com.br/artigo/Proxy-Reverso-com-Apache/?pagina=1>. Acesso em:

17 outubro 2012.

TEIXEIRA, Ataliba de Oliveira. Proxy Reverso com Apache. Disponivel em < http://www.ataliba.eti.br/txts/apache-proxy.pdf>. Acesso em: 23 setembro 2012.

ZANONI, Guilherme Souza. Servidor Proxy (Squid). Disponível em <www.vivaolinux.com.br/artigo/Servidor-proxy-%28Squid%29>. Acesso em: 21 maio

2012.

VILELLA, Luis Eduardo. Linux: Squid passo a passo no Debian para iniciantes. Disponivel em < www.vivaolinux.com.br/artigo/Squid-passo-a-passo-para-iniciantes>. Acesso em: 15 agosto 2012.

41

8.

APÊNDICES

Arquivo de configuração do Proxy Apache Reverso “ /etc/httpd/conf/httpd.conf ”.

#

#

This is the main Apache server configuration file. It contains the

#

configuration directives that give the server its instructions.

#

See <URL:http://httpd.apache.org/docs/2.2/> for detailed information.

#

In particular, see

#

<URL:http://httpd.apache.org/docs/2.2/mod/directives.html>

#

for a discussion of each configuration directive.

#

#

#

Do NOT simply read the instructions in here without understanding

#

what they do. They're here only as hints or reminders. If you are unsure

#

consult the online docs. You have been warned.

#

#

The configuration directives are grouped into three basic sections:

#

1. Directives that control the operation of the Apache server process as a

#

whole (the 'global environment').

#

2. Directives that define the parameters of the 'main' or 'default' server,

#

which responds to requests that aren't handled by a virtual host.

#

These directives also provide default values for the settings

#

of all virtual hosts.

#

3. Settings for virtual hosts, which allow Web requests to be sent to

#

different IP addresses or hostnames and have them handled by the

#

same Apache server process.

#

#

Configuration and logfile names: If the filenames you specify for many

#

of the server's control files begin with "/" (or "drive:/" for Win32), the

#

server will use that explicit path. If the filenames do *not* begin

#

with "/", the value of ServerRoot is prepended -- so "logs/foo.log"

#

with ServerRoot set to "/etc/httpd" will be interpreted by the

#

server as "/etc/httpd/logs/foo.log".

#

### Section 1: Global Environment

#

#

The directives in this section affect the overall operation of Apache,

#

such as the number of concurrent requests it can handle or where it

#

can find its configuration files.

#

42

#

#

Don't give away too much information about all the subcomponents

#

we are running. Comment out this line if you don't mind remote sites

# finding out what major optional modules you are running ServerTokens OS

#

#

ServerRoot: The top of the directory tree under which the server's

#

configuration, error, and log files are kept.

#

#

NOTE! If you intend to place this on an NFS (or otherwise network)

#

mounted filesystem then please read the LockFile documentation

#

(available at

<URL:http://httpd.apache.org/docs/2.2/mod/mpm_common.html#lockfile>);

#

you will save yourself a lot of trouble.

#

#

Do NOT add a slash at the end of the directory path.

#

ServerRoot "/etc/httpd"

#

#

PidFile: The file in which the server should record its process

#

identification number when it starts. Note the PIDFILE variable in

#

/etc/sysconfig/httpd must be set appropriately if this location is

#

changed.

#

PidFile run/httpd.pid

#

#

Timeout: The number of seconds before receives and sends time out.

#

Timeout 60

#

#

KeepAlive: Whether or not to allow persistent connections (more than

#

one request per connection). Set to "Off" to deactivate.

#

KeepAlive Off

#

#

MaxKeepAliveRequests: The maximum number of requests to allow

#

during a persistent connection. Set to 0 to allow an unlimited amount.

#

We recommend you leave this number high, for maximum performance.

#

MaxKeepAliveRequests 100

#

#

KeepAliveTimeout: Number of seconds to wait for the next request from the

#

same client on the same connection.

43

#

KeepAliveTimeout 15

## ## Server-Pool Size Regulation (MPM specific) ##

# prefork MPM

# StartServers: number of server processes to start

# MinSpareServers: minimum number of server processes which are kept spare

# MaxSpareServers: maximum number of server processes which are kept spare

# ServerLimit: maximum value for MaxClients for the lifetime of the server

# MaxClients: maximum number of server processes allowed to start

# MaxRequestsPerChild: maximum number of requests a server process serves <IfModule prefork.c>

StartServers

8

MinSpareServers

5

MaxSpareServers

20

ServerLimit

256

MaxClients

256

MaxRequestsPerChild 4000 </IfModule>

# worker MPM

# StartServers: initial number of server processes to start

# MaxClients: maximum number of simultaneous client connections

# MinSpareThreads: minimum number of worker threads which are kept spare

# MaxSpareThreads: maximum number of worker threads which are kept spare

# ThreadsPerChild: constant number of worker threads in each server process

# MaxRequestsPerChild: maximum number of requests a server process serves <IfModule worker.c>

StartServers

4

MaxClients

300

MinSpareThreads

25

MaxSpareThreads

75

ThreadsPerChild

MaxRequestsPerChild 0 </IfModule>

25

#

#

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

ProxyPassReverse

/pedido

http://192.168.1.113

/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

Relátorio do teste de Vulnerabilidade.

===== Checking multi/http/activecollab_chat =====

msf > use multi/http/activecollab_chat

msf exploit(activecollab_chat) > set RHOST 200.232.237.139

RHOST => 200.232.237.139

msf exploit(activecollab_chat) > check

[-] Exploit check failed: Msf::OptionValidateError The following options failed to validate: USER, PASS.

===== Checking multi/http/apprain_upload_exec =====

msf exploit(activecollab_chat) > use multi/http/apprain_upload_exec

msf exploit(apprain_upload_exec) > set RHOST 200.232.237.139

RHOST => 200.232.237.139

msf exploit(apprain_upload_exec) > check

[*] The target is not exploitable.

===== Checking unix/http/contentkeeperweb_mimencode =====

msf

exploit(apprain_upload_exec)

unix/http/contentkeeperweb_mimencode

>

use

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)

multi/http/cuteflow_upload_exec

>

use

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)

multi/http/phpscheduleit_start_date

>

use

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_optio