Laboratorio Servidor Web

SumárioServiço de Páginas Web (Apache2)........................................................................................2

Conteúdo............................................................................................................................2Laboratório 1 - Nível básico................................................................................................2Laboratório 2 - Nível intermediário....................................................................................2

Na prática......................................................................................................................3Laboratório 3 – Extensão do nível intermediário................................................................5

Referencial Teórico - Introdução ao Apache...........................................................................6Entendendo a organização dos arquivos.......................................................................7No Debian e derivados...................................................................................................7

Ativando e desativando sites no Apache...................................................................8Ativando e desativando módulos no Apache.............................................................9Configurações de Portas do Apache..........................................................................9

No CentOS, Fedora e RHEL..........................................................................................10Adicionando e removendo sites...............................................................................10Adicionando e removendo de módulos...................................................................10Ajustes finos do Apache...........................................................................................11

Virtual Hosts.................................................................................................................11Instalando o suporte a PHP..........................................................................................15

Testando suporte ao PHP.........................................................................................16Dicas de segurança do PHP.....................................................................................17

Ativando o SSL.............................................................................................................17Usando um certificado self-signed...........................................................................18Usando um certificado reconhecido........................................................................20Usando o SSL para pastas específicas.....................................................................22

Referências.......................................................................................................................24

Laboratório de Servidor Web Apache2 | 1

Serviço de Páginas Web (Apache2)

Conteúdo

Neste laboratório serão apresentadas as seguintes competências:

1. Capacidade de instalação e configuração do servidor Web Apache;

2. Publicação de vários sites hospedados em um mesmo servidor Web;

Este laboratório será dividido em três etapas, os níveis: “básico”, “intermediário”, e “bem vindo a vida real (é por sua conta)”.

Laboratório 1 - Nível básico

Instalação e configuração de um site básico. Para isso será necessário, em resumo:

Passo 1: Instalação de Apache2 (apt-get install apache2);

Passo 2: Iniciar o serviço (service apache2 restart);

Passo 3: Verificar se o apache está funcionando corretamente, acessando o IP do servidor pelo navegador web (Uma página deverá ser apresentada informando que está tudo ok);

Passo 4: Criação do arquivo index.html para o seu site dentro do diretório /var/www (substituindo o index.html que já existe lá). Recomendo renomear o index.html que já existia ao invés de apagá-lo.

Passo 5: Acessar o site de um outro computador digitando o endereço IP do servidor. Deverá aparecer o site que foi preparado no index.html;

Com este simples resumo realizará facilmente a 1ª etapa do laboratório (LAB).

Se tudo deu certo no nível básico, podemos avançar, aumentando um pouco a complexidade do laboratório de servidor Web.

Laboratório 2 - Nível intermediário

Instalação e configuração de vários sites e acesso via endereços de domínios FQDNs. Para isso será necessário, em resumo:

Passo 1: Ter realizado o Nível básico com sucesso;

Passo 2: Instalação e configuração de do serviço de DNS (verifique os laboratórios de DNS);

Passo 3: Criação de uma zona no DNS (/etc/bind/named.conf.local) para responder pelo domínio (site), este nome encaminhará para o endereço IP do servido que hospeda o site;

Passo 4: Criar um diretório exclusivo para o site que se deseja hospedar;

Passo 5: Criar um arquivo index.html para o site no seu respectivo diretório criado no item anterior, com o texto “Laboratório de serviço de páginas Web intermediário”;

Passo 6: Criar um arquivo com a configuração do Virtual Host no diretório /etc/apache2/sites-available;

Passo 7: Habilitar acesso ao site configurado no /etc/apache2/sites-available para que o apache possa disponibilizar para os usuários com o comando a2ensite <nome do arquivo no sites-available>;


Passo 8: Recarregar o apache a cada nova publicação (service apache2 reload);

Passo 9: Testar o acesso ao site utilizando a url do site preparada para ser recebida pelo serviço de DNS e reencaminha-la para o servido do Apache.

Se tudo deu certo como resultado será apresentada a página do site com o texto: Laboratório de serviço de páginas Web intermediário”. Caso isso não aconteça refaça/revise todo o processo até encontrar o erro.

Na prática...

Vamos realizar a atividade na prática. Neste LAB vamos adotar que:

• O endereço do site: www.fuctura.net:

• O IP do servidor: 172.16.0.1

Vamos aos passos (começando do passo 3):

Passo 3: Criação de uma zona no DNS (/etc/bind/named.conf.local) para responder pelo domínio (site), este nome encaminhará para o endereço IP do servidor que hospeda o site;

Crie uma zona adicional no arquivo de zonas do DNS. Recomendamos que crie as zonas no arquivo /etc/bind/named.conf.local. Veja a definição da zona a seguir:

------------------------------ Arquivo: /etc/bind/named.conf.local ------------------------------zone “fuctura.net” IN {

type master;file “/etc/bind/db.fuctura.net”;

};--------------------------------------------------------------------------------------------------

Crie o arquivo da base de dado da zona, conforme definido na configuração acima. A seguir um exemplo do arquivo de base de zona:

------------------------------ Arquivo: /etc/bind/db.fuctura.net ------------------------------; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA fuctura.net. root.fuctura.net. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS fuctura.net. @ IN A 172.16.0.1 www IN A 172.16.0.1 --------------------------------------------------------------------------------------------------

Lembre-se de Reiniciar o serviço de DNS para que este reconheça o novo domínio.

# service bind9 restart

Neste exato momento você poderá testar no navegador web (ou no terminal com: ping, nslookup, dig...) se o DNS realmente esta resolvendo o nome www.fuctura.net convertendo para o 172.16.0.1. Como resultado teremos que ver a página que foi vista no parte anterior deste LAB (nível básico). Caso isso não aconteça refaça/revise todo o processo até encontrar o erro.


http://www.fuctura.net/


OBSERVAÇÕES:

• Muitos erros na configuração de DNS são referentes a erros de digitação, se puder sempre copiar e colar, evita muitos problemas;

• Sempre que reiniciar o serviço, mesmo que o serviço esteja [ok], verifique o log (tail /var/log/syslog) pois podem existir notificações importante para a identificação de problemas;

• Note que não será necessário criar mais de uma zona reversa, visto que a zona reversa responderá para qualquer outro domínio;

• Se você precisar hospedar mais de uma domínio, por exemplo www.empresa.net, basta criar mais uma zona que responderá por este novo domínio;

Passo 4: Criar um diretório exclusivo para o site que se deseja hospedar;

Por precaução e segurança recomenda-se hospedar os sites no diretório /var/www onde o serviço do apache2 tem permissões que são restritas aos demais diretórios do sistema.

Para que mantenha uma organização, para cada site crie um diretório. Não é necessário que o diretório tenha o mesmo nome do site, mas crie um padrão para facilitar a organização.

Neste LAB criaremos o seguinte diretório (note que o diretório é apenas fuctura):

# mkdir /var/www/fuctura

Passo 5: Criar um arquivo index.html para o site no seu respectivo diretório criado no item anterior, com o texto “Laboratório de serviço de páginas Web intermediário”;

Acesse o diretório (/var/www/fuctura.com)e crie um arquivo index.html;

# cd /var/www/fuctura# touch index.html# vi index.html

Escreva o seguinte texto:

------------------------------ Arquivo: /var/www/fuctura/index.html ------------------------------<html>

<body> <h1>Site exemplo www.fuctura.net</h1>

</body> </html> --------------------------------------------------------------------------------------------------Lembre-se de salvar o arquivo (:wq)

Passo 6: Criar um arquivo com a configuração do Virtual Host no diretório /etc/apache2/sites-available;

Faça os seguintes testes:

• Tente acessar o site com a seguinte caminho: http://172.16.0.1 (o resultado será o mesmo do inicio do LAB);

• Tente acessar o site com a seguinte caminho: http://172.16.0.1/fuctura (o resultado Apresentará o novo site criado). Neste caso acessamos um diretório especificado no servidor web;

• Agora para finalizar Tente acessar o site com a seguinte caminho: http://www.fuctura.net (o resultado será o mesmo do inicio do LAB). Precisamos configura o servidor web para entender que deverá redirecionar para as pastas diferentes dependendo das requisições;

Para que o apache possa reconhecer o site solicitado e apresentar as paginas corretas precisamos criar uma configuração de Virtual Host.

Crie um arquivo chamado fuctura em /etc/apache2/sites-available e escreva a configuração básica de virtual host;

# touch /etc/apache2/sitesavailable/fuctura;# vi /etc/apache2/sitesavailable/fuctura;


http://172.16.0.1/

http://172.16.0.1/

http://172.16.0.1/

http://www.empresa.net/

------------------------------ Arquivo: /etc/apache/sites-available/fuctura

------------------------------

<VirtualHost *:80> ServerAdmin [email protected] ServerName www.fuctura.net ServerAlias fuctura.net www.fuctura.net DocumentRoot /var/www/fuctura </VirtualHost> --------------------------------------------------------------------------------------------------

Lembre-se de salvar o arquivo (:wq)

OBSERVAÇÕES:

Note que o campo ServerAlias define como o site é esperado pelo encaminhamento do DNS. Caso o usuário digite vendas.fuctura.net, mesmo que o DNS tenha uma entrada “vendas” mapeada para o IP do servidor WEB, o apache não encaminhará para o diretório do site correto.

Passo 7: Habilitar acesso ao site configurado no /etc/apache2/sites-available para que o apache possa disponibilizar para os usuários com o comando a2ensite <nome do arquivo no sites-available>;

Concluído o passo 6, o site esta pronto para ser acessado, mas não esta habilitado para visualização. Para habilitá-lo em distribuições baseada em Debian utilize:

Para habilitar

# a2ensite <nome do arquivo no sitesavailable>

Para desativar:

# a2dissite <nome do arquivo no sitesavailable>

Passo 8: Recarregar o apache a cada nova publicação (# service apache2 reload);

Todas as vezes que fizer modificações nos arquivos de Virtual Hosts do Apache você precisa solicita que o serviço que está em execução reconheça as novas configurações. O apache possui uma opção que não para o serviço (restart) apenas recarrega (reload):

# service apache2 reload

Passo 9: Testar o acesso ao site utilizando a url do site preparada para ser recebida pelo serviço de DNS e reencaminha-la para o servido do Apache.

Se todas as configurações estiverem certas, como resultado será apresentada a página do site com o texto: Laboratório de serviço de páginas Web intermediário”. Caso isso não aconteça refaça/revise todo o processo até encontrar o erro.

Laboratório 3 – Extensão do nível intermediário1. Faça com que o mesmo site seja acessado por outros subdomínios como:

◦ www.fuctura.net

◦ vendas.fuctura.net

◦ correio.fuctura.net

2. Faça com que o mesmo site seja acessado por outros domínios como:

◦ www.cursolinux.net

◦ email.linuxserver.net

3. Crie um segundo site www.redesmistas.net e faça com que este domínio apresente uma pagina com o texto: bem vindo ao site www.redesmistas.net”


http://www.redesmistas.net/

http://www.redesmistas.net/

http://www.cursolinux.net/


Referencial Teórico - Introdução ao Apache

O Apache pode ser dividido em duas grandes famílias: o Apache 2.x e o Apache 1.3 que, apesar de muito antigo, ainda é usado em muitos servidores. O Apache 2 trouxe muitas vantagens, sobretudo do ponto de vista do desempenho, além de oferecer novos módulos e mais opções de segurança, mas sua adoção foi retardada nos primeiros anos por um detalhe muito simples: o fato de ele ser incompatível com os módulos compilados para o Apache 1.3. Como os módulos são a alma do servidor web, muitos administradores ficavam amarrados ao Apache 1.3 devido à falta de disponibilidade de alguns módulos específicos para o Apache 2 [1].

Conforme o tempo foi passando, mais e mais módulos foram portados, sem falar de novos módulos desenvolvidos diretamente para uso em conjunto com o Apache 2. Hoje em dia, o Apache 1.3 ainda sobrevive em muitas instalações devido à inércia natural que temos dentro do ramo de servidores, mas não existe nenhum bom motivo para usá-lo em uma nova instalação. O Apache 2 é simplesmente melhor em todos os quesitos.

Apesar disso, ainda existem casos de distribuições que continuam oferecendo as duas versões, de forma a satisfazer os dois públicos. No Debian Etch, por exemplo, o Apache 1.3 é instalado através do pacote "apache", enquanto o Apache 2 (a versão recomendada) é instalado através do "apache2". Entretanto, no Debian Lenny já está disponível apenas o Apache 2, assim como no CentOS, no Fedora e em outras distribuições.

Ao instalar o Apache 2, o suporte a SSL é instalado automaticamente junto com o pacote principal (mas ainda é preciso ativá-lo na configuração, como veremos a seguir). Instale também o pacote apache2-utils, que contém diversos utilitários de gerenciamento que usaremos a seguir:

# aptget install apache2 apache2utils

Se desejar ativar o suporte a páginas seguras, você vai precisar também do pacote "ssl-cert", necessário para ativar o suporte a SSL e gerar os certificados. Ele não é instalado por padrão ao fazer uma instalação enxuta do Debian ou do Ubuntu:

# aptget install sslcert

Se você estiver utilizando o CentOS ou o Fedora, instale o pacote "httpd", que contém o Apache 2 e os utilitários:

# yum install httpd

Diferente do Debian, no CentOSS o serviço não será configurado para ser ativado no boot por padrão e nem mesmo inicializado automaticamente após a instalação. Para ativá-lo, é necessário ativar o serviço e, em seguida, criar os links para início automático usando o chkconfig:

# service httpd start# chkconfig httpd on

Seguindo os nomes dos pacotes, no Debian o serviço se chama "apache2", enquanto no Fedora e no CentOS ele se chama "httpd". Para reiniciar o servidor você usa, respectivamente, os comandos "/etc/init.d/apache2 restart" e "service httpd restart".

Acessando o endereço "http://127.0.0.1", você verá uma página de boas-vindas, que indica que o servidor está funcionando. Se não houver nenhum firewall no caminho, ele já estará acessível a partir de outros micros da rede local ou da internet.

Por enquanto, temos apenas uma versão básica do Apache, que simplesmente exibe arquivos html e executa scripts CGI. Por padrão, o diretório raiz do servidor Web é " /var/www" (no Debian) ou "/var/www/html" (no Fedora). Com isso, a página "http://seu.servidor/index.html" é, na verdade, o arquivo "/var/www/index.html" ou "/var/www/html/index.html".

Como de praxe, o diretório raiz é definido através de uma opção dentro do arquivo principal de configuração (a opção "DocumentRoot") e pode ser alterado caso desejado. Ao hospedar diversos sites no mesmo servidor, você define uma pasta raiz diferente para cada um. Como pode ver, a instalação do Apache propriamente dita é bastante simples, o grande desafio é configurar e otimizar o servidor, como veremos a seguir.


Entendendo a organização dos arquivos

A principal característica do Apache é a modularidade. Ao invés de ser um aplicativo grande e complexo, que tenta desempenhar sozinho todas as funções, o Apache se limita a executar uma única tarefa: entregar páginas html e outros tipos de arquivos aos clientes. Qualquer outra coisa é invariavelmente feita por um módulo externo.

Por exemplo, quando você acessa uma página em PHP em um site que roda sobre um servidor Apache, ele (Apache) lê o arquivo no disco e repassa a requisição para o mod_php, o módulo encarregado de processar arquivos PHP. Ele, por sua vez, aciona o interpretador PHP, que processa a página e a entrega, já processada, ao Apache, que, finalmente, a entrega ao cliente. Caso seja necessário acessar um banco de dados (como no caso de um fórum ou de um gestor de conteúdo), entra em ação outro módulo, como o php5-mysql, que permite ao interpretador PHP acessar o banco de dados:

Pode parecer estranho que depois de toda essa volta o Apache ainda consiga entregar a página processada em tempo hábil, mas é justamente essa divisão de tarefas que permite ao Apache ser tão rápido e seguro. O trabalho é dividido em várias partes e cada módulo é mantido separadamente por uma equipe que entende do assunto e zela pelo desempenho e confiabilidade do código. Graças a isso, é bastante raro que sejam descobertos problemas graves de segurança no Apache ou no interpretador PHP, por exemplo. Quase sempre, os problemas de segurança não estão no servidor Web em si, mas sim no gestor de conteúdo (phpNuke, Xoops, phpBB, etc.) usado.

No Debian e derivados

Nas distribuições derivadas do Debian, a arquitetura modular do Apache é extendida também aos arquivos de configuração. Tradicionalmente, a configuração do Apache é centralizada em um único arquivo, o "httpd.conf", que pode opcionalmente incluir referências a arquivos externos (includes) que permitem segmentar e organizar a configuração. Aproveitando esta possibilidade, a equipe do Debian desenvolveu uma organização bastante prática, que é usada também no Ubuntu e em outras distribuições derivadas dele.

À primeira vista, a organização do Apache 2 nas distribuições derivadas do Debian parece muito mais complicada, mas, depois de entender, a coisa se revela bastante simples e lógica:


Figura 1: Comunicação do Apache com os módulos

Todos os arquivos de configuração estão organizados dentro do diretório "/etc/apache2". Dentro dele, temos as pastas:

• As pastas "sites-available" e "sites-enabled", que contêm a configuração dos sites hospedados;

• As pastas "mods-available" e "mods-enabled", que armazenam a configuração dos módulos;

• O arquivo "ports.conf", onde vai a configuração das portas TCP que o servidor vai escutar;

• O arquivo "apache2.conf", que armazena configurações diversas relacionadas ao funcionamento do servidor;

• A pasta "conf.d", que armazena arquivos com configurações adicionais.

Ativando e desativando sites no ApacheO Apache é capaz de hospedar simultaneamente vários sites, cada um representado por um arquivo de configuração diferente. Imagine o caso de uma empresa de hosting que mantém um servidor com 2.000 pequenos sites. Quando cada cliente registra seu site e assina o plano de hospedagem, você cria um novo arquivo dentro da pasta "sites-available" com as configurações necessárias e um link para ele na pasta "sites-enabled".

Como os nomes sugerem, a primeira pasta armazena a configuração de todos os sites (virtual hosts) hospedados no servidor, mas apenas os sites que estiverem presentes na pasta "sites-enabled" ficam disponíveis. Quando é necessário suspender temporariamente um site por falta de pagamento, por exemplo, você simplesmente remove o link na pasta "sites-enabled", sem precisar mexer na configuração.

Ao invés de criar e remover os links manualmente, você pode usar os comandos "a2ensite" e "a2dissite", que fazem isso para você. Para ativar e desativar um site configurado no arquivo "/etc/apache2/sites-available/gdhn", por exemplo, os comandos seriam:

Ativação:

# a2ensite gdhn

Desativação:

# a2dissite gdhn


Figura 2: Organização dos Arquivos no Debian e derivados

Ativando e desativando módulos no Apache

Continuando, a mesma idéia das duas pastas separadas se aplica aos módulos. A pasta "mods-available" contém a configuração e scripts de inicialização para todos os módulos disponíveis, mas apenas os módulos referenciados (através de um link) na pasta "mods-enabled" são realmente carregados.

Muita gente simplesmente cria e deleta os links manualmente, mas isso pode ser feito mais rapidamente usando os comandos "a2enmod" e "a2dismod", que ativam e desativam módulos específicos. Para desativar o suporte a PHP, por exemplo, você usaria o comando:

Ativação:

# a2enmod php5

Desativação:

# a2dismod php5

Para ativar ou desativar sites, ou ao fazer alterações simples na configuração, você não precisa reiniciar todo o serviço apenas recarregar as configurações, isso poupa paradas nos acessos já existentes aos sites publicados:

# /etc/init.d/apache2 reload

Para casos de ativação e desativação de módulos para que a alteração entre em vigor, é necessário reiniciar o serviço:

# /etc/init.d/apache2 forcereloadOu

# /etc/init.d/apache2 restart

OBSERVAÇÃO:

• Uma vez que um determinado módulo é ativado, ele fica automaticamente disponível para todos os sites hospedados no servidor.

• Usuário dos serviço apache no Debian: “www-data”

Configurações de Portas do Apache

Configuração de portas é realizada no arquivo "ports.conf". Originalmente o arquivo vem com uma única linha. Neste arquivo poderão ser adicionas novas portas, como faremos mais adiante ao ativar o SSL:

Listen 80

O Apache também permite usar portas diferentes caso precise manter mais de um servidor web ativo na mesma máquina (muitos administradores usam este truque para testar novas versões do Apache, ou para combiná-lo com um segundo servidor web, como o lighttpd, configurado para servir arquivos e páginas estáticas).

Para fazer com que seu servidor escute também na porta 443 (a porta do HTTPS) e na porta 8080, por exemplo, você adicionaria duas novas linhas, como em:

Listen 80Listen 443Listen 8080


No CentOS, Fedora e RHEL

As distribuições derivadas do Red Hat, incluindo o CentOS, o Fedora e o RHEL, utilizam por padrão uma organização mais tradicional, onde toda a configuração é concentrada no arquivo "/etc/httpd/conf/httpd.conf", em vez de ser desmembrada em diversos arquivos separados. Isso pode tornar a configuração mais simples ou mais complicada, dependendo do seu ponto de vista, já que por um lado temos um único arquivo, mas por outro ele é muito maior.

Adicionando e removendo sitesNo de distribuições baseadas em RedHat, ao adicionar um novo site na configuração, você simplesmente adiciona a seção referente a ele dentro do arquivo httpd.conf (em vez de criar um arquivo separado, como no Debian) e, para desativá-lo posteriormente, comenta ou remove a configuração.

Adicionando e removendo de módulosOs módulos são ativados através de arquivos criados dentro da pasta "/etc/httpd/conf.d/". Todos os arquivos com extensão ".conf" colocados dentro da pasta são carregados pelo servidor, de forma similar aos links dentro da pasta "/etc/apache2/mods-enabled" do Debian.

Ao ativar o suporte a PHP, por exemplo, é criado o arquivo "/etc/httpd/conf.d/php.conf". Não existe um script destinado a ativar e desativar os módulos, como no caso do a2enmod/a2dismod do Debian; para desativar um módulo, você precisa apenas remover ou renomear o arquivo referente a ele dentro da pasta, alterando a extensão de ".conf" para ".disabled", por exemplo.

Para desativar o suporte a PHP, por exemplo, você renomearia o arquivo "php.conf", e em seguida reiniciaria o Apache, como em:

# cd /etc/httpd/conf.d/# mv php.conf php.disabled# service httpd restart

Outra diferença é que, como vimos anteriormente, o script responsável por ativar e desativar o serviço se chama "httpd" em vez de "apache2", como no caso do Debian.

Para reiniciar o serviço ou apenas recarregar as configurações você pode usar os parâmetros “restart” e "reload", da mesma forma que no Debian:

# service httpd restart# service httpd reload

OBSERVAÇÃO:

• O Nome do usuário do Apache no CentOS/Fedora é "apache".

De uma forma geral, o servidor web precisa apenas de permissão de leitura para os arquivos do site, salvo em casos especiais, onde são usados scripts CGI ou páginas em PHP que salvam informações em arquivos de texto em vez de utilizarem um banco de dados.

Quando o Apache é instalado, é criado por padrão o arquivo "/etc/apache2/sites-available/default", que contém a configuração de um site "raiz", que usa (por padrão) a pasta "/var/www" como diretório de páginas. Caso queira hospedar vários sites no mesmo servidor, é necessário criar uma pasta e um arquivo de configuração para cada site adicional.

Um exemplo prático:

• Seu servidor pode, por exemplo, hospedar o "joao.com.br" e o "maria.com.br".

• O servidor DNS, mantido no servidor, é configurado para responder pelos dois domínios, em ambos os casos fornecendo o endereço IP do seu servidor web aos clientes.

• Na configuração do apache, criamos os arquivos "/etc/apache2/sites-available/joao" e


"/etc/apache2/sites-available/maria", cada um configurado para utilizar uma pasta diferente. De acordo com sua preferência, podem ser usadas pastas dentro do diretório home de cada usuário, como em "/home/joao/html" e "/home/maria/html", ou subpastas dentro do diretório "/var/www", como em "/var/www/joao" e "/var/www/maria".

• Quando um visitante digita "http://joao.com.br", o servidor do Registro.br (que responde pelos domínios .br) vai passar a requisição para seu servidor DNS, que responde com o endereço do seu servidor web. Ao acessar o servidor, o navegador solicita o site "joao.com.br" e o servidor responde enviando o arquivo "/var/www/joao/index.html" ou "index.php" ao cliente.

Esta configuração parece bem complicada à primeira vista, mas na prática é relativamente simples. Veremos mais detalhes sobre a configuração de servidores Apache com vários domínios mais adiante.

Ajustes finos do Apache

Finalmente, chegamos ao arquivo "apache2.conf", que agrupa o "resto" das configurações. É ele que você vai alterar quando, por exemplo, precisar ajustar o número de processos usados pelo Apache ou aumentar o número de conexões simultâneas permitidas pelo servidor, como veremos em detalhes mais adiante.

Virtual Hosts

O suporte a virtual hosts [2] é um daqueles recursos fundamentais, que possibilitaram o surgimento da Internet da forma como a conhecemos hoje. Ele permite hospedar diversos sites, com domínios ou subdomínios diferentes usando um único servidor e um único endereço IP. Os únicos limitantes com relação ao volume de sites que é possível hospedar são os recursos de hardware do servidor e a banda disponível.

Serviços de hospedagem compartilhada (os planos de shared hosting) utilizam este recurso de forma intensiva, de forma a espremer o maior número possível de clientes em cada servidor, sem falar nos serviços de hospedagem gratuita onde, em muitos casos, um único servidor pode hospedar dezenas de milhares de sites diferentes.

Ao usar virtual hosts, os arquivos de cada site ficam guardados em uma pasta diferente e o servidor se encarrega de direcionar cada visitante à pasta correta. Os recursos do servidor (HD, memória, processamento e link) são divididos entre os sites hospedados, assim como vários programas abertos simultaneamente disputam os recursos da máquina.

Em geral, o servidor é configurado de forma que os usuários tenham:

• Direito a uma determinada quota de espaço em disco;

• Possam acessar os arquivos do site via FTP ou SFTP;

• Tenham acesso a uma ou mais bases de dados do servidor MySQL, o que permite a instalação de gestores de conteúdo como o WordPress;

• Os clientes não podem instalar novos pacotes nem alterar a configuração do servidor;

1º Passo: Configuração do Servidor de DNS. Invariavelmente, ao hospedar vários domínios, você precisa configurar um servidor DNS para responder por todos os domínios hospedados no servidor, entregando o endereço IP do seu servidor Apache. O cliente acessa então o servidor, solicitando o site desejado, como em "joao.com.br"; o servidor web verifica a configuração e entrega os arquivos apropriados ao cliente.

Em resumo, você precisaria:

1. instalar o bind no servidor (caso já o tenha instalado passe para o próximo item);

2. Editar a configuração, adicionando uma nova configuração de zona para cada domínio hospedado. Isso é feito em duas etapas:

1. Na primeira, você edita o arquivo named.conf, adicionando uma entrada com esta, especificando o domínio e o arquivo com a configuração:


zone "joao.com.br" IN {type master;file "/etc/bind/db.joao";allowtransfer { 64.234.23.13; };

};

2. Dentro do arquivo "/etc/bind/db.joao", especificado no arquivo de configuração anterior, iria uma configuração da zona similar ao exemplo a seguir, especificando o domínio, o nome do servidor e o endereço IP usado por ele, assim como o nome e o endereço IP do servidor DNS secundário:

@ IN SOA servidor.joao.com.br. hostmaster.joao.com.br. (2008061645 3H 15M 1W 1D )

NS servidor.joao.com.br.NS ns2.joao.com.br.

IN MX 10 servidor.joao.com.br.joao.com.br. IN A 64.234.23.12www IN A 64.234.23.12ns1 IN A 64.234.23.13

Não é necessário que o DNS esteja instalado no mesmo servidor que o Apache, a função dele será unicamente responder às requisições dos clientes, fornecendo o IP correto. Vamos estudar a configuração do DNS em detalhes no próximo capítulo, dedicado unicamente ao assunto. Este foi apenas um exemplo rápido para que você tenha uma idéia geral sobre a configuração. Por enquanto, vamos nos concentrar na configuração do Apache propriamente dito.

2º Passo: Criação de pastas separadas para cada site. Para ativar o uso dos virtual hosts, o primeiro passo é criar uma pasta separada para cada site que será hospedado. Você pode usar a própria pasta "/var/www", como em:

# mkdir /var/www/joao# mkdir /var/www/maria

3º Passo: Em seguida, é necessário adicionar uma nova seção dentro da configuração do Apache para cada um, logo depois da configuração do site default.

Nas distribuições derivadas do Debian, são usados arquivos de configuração separados para cada site, armazenados na pasta "/etc/apache2/sites-available". Imagine que vamos hospedar os sites "www.joao.com.br" e "www.maria.com.br", usando as duas pastas criadas anteriormente. Criaríamos, então, um arquivo para cada site, contendo o seguinte:

Exemplo /etc/apache2/sites-available/joao:

<VirtualHost *:80>ServerAdmin [email protected] www.joao.com.brServerAlias joao.com.br www.joao.com.brDocumentRoot /var/www/joao

</VirtualHost>

Exemplo2 /etc/apache2/sites-available/maria:

<VirtualHost *:80>ServerAdmin [email protected] www.maria.com.brServerAlias maria.com.br www.maria.com.brDocumentRoot /var/www/maria

</VirtualHost>


Note que foi adicionada uma nova diretiva, a "ServerAlias", que permite que o site seja acessado tanto com, quanto sem o "www". A linha "ServerAdmin" é, na verdade, opcional, contém apenas o e-mail de contato do administrador do site.

A mesma configuração é usada se você quiser hospedar os sites usando subdomínios, como em "joao.gdhn.com.br" e "maria.gdhn.com.br". Nesse caso, não usamos o "www" e, por isso, não precisamos da linha "ServerAlias":

<VirtualHost *:80>ServerAdmin [email protected] maria.gdhn.com.brDocumentRoot /var/www/maria

</VirtualHost>

Depois de feita a configuração, ative ambos os sites usando o comando a2ensite, o que criará links para eles na pasta "/etc/apache2/sites-enabled":

# a2ensite joao# a2ensite maria

4º Passo: Edição do arquivo /etc/apache2/sites-available/default. Para que a configuração funcione, é necessário editar também o arquivo "/etc/apache2/sites-available/default", substituindo as linhas:

NameVirtualHost *<VirtualHost *>

Por:

NameVirtualHost *:80<VirtualHost *:80>

Essa configuração é necessária para que você possa ativar o suporte a SSL para os virtual hosts. Sem ela, além do SSL não funcionar, você precisaria modificar a configuração de cada um, usando sempre "<VirtualHost *>" ao invés de "<VirtualHost *:80>".

5º Passo: Recarregar as definições do Apache. Você pode adicionar quantos sites quiser usando esses mesmos passos. Sempre que alterar a configuração, é necessário atualizar a configuração do Apache. Nesse caso, o parâmetro "reload" é suficiente (o "force-reload" é necessário apenas ao ativar ou desativar módulos):

# /etc/init.d/apache2 reload

Além de configurar o servidor web, é preciso configurar também um servidor FTP ou SFTP, para que os usuários possam acessar os arquivos de suas respectivas pastas, a fim de atualizarem seus sites. A forma mais simples de fazer isso é criar um usuário para cada um e dar acesso a eles via FTP (mais adiante veremos como configurar o servidor FTP com o Proftpd). Outra opção é utilizar o SFTP, que permite acesso seguro. Veremos mais detalhes sobre ele no capítulo sobre o SSH.

Veja que as três coisas acabam se integrando: o Bind resolve os nomes de domínio, o Apache fornece as páginas e o FTP ou SFTP permite que os webmasters atualizem os sites.

Nas distribuições CentOS/Fedora e derivados

Ao utilizar o Fedora, CentOS ou outra distribuição derivada do Red Hat, a configuração de todos os virtual hosts é adicionada na seção final do arquivo "/etc/httpd/conf/httpd.conf", depois do "# Section 3: Virtual Hosts". Procure pela seção "Virtual Hosts", perto do final do arquivo, e descomente a linha:

NameVirtualHost *:80


A partir daí, você pode adicionar cada um dos sites hospedados no servidor usando a mesma configuração que vimos anteriormente, como em:

<VirtualHost *:80>ServerName www.joao.com.brServerAlias joao.com.br www.joao.com.brDocumentRoot /var/www/joao

</VirtualHost>

<VirtualHost *:80>ServerName www.maria.com.brServerAlias maria.com.br www.maria.com.brDocumentRoot /var/www/maria

</VirtualHost>

A principal diferença nesse caso é que para desativar um determinado site você precisa abrir novamente o arquivo de configuração e remover (ou comentar) a seção referente a ele, em vez de utilizar o "a2dissite", como no Debian.

Depois de fazer alterações no arquivo, é necessário recarregar a configuração para que elas entrem em vigor:

# service httpd reload

Fazendo dessa forma, os logs de acessos serão misturados no log principal do Apache, o "/var/log/apache2/access.log". Isso não é problema se você está utilizando o Google Analytics ou outra ferramenta externa para auditar os acessos dos sites (ou se simplesmente você não está preocupado em medir os acessos), mas é um grande obstáculo se você pretende usar o webalizer para gerar os relatórios de acesso.

Para que cada site tenha seus logs separados, você deve adicionar duas linhas adicionais, na configuração de cada virtual host, especificando a localização do arquivo que será usado. Você com certeza não gostaria que os logs ficassem disponíveis ao público, por isso é importante usar diretórios diferentes para os arquivos do site e para os logs, como em:

<VirtualHost *:80>ServerAdmin [email protected] www.joao.com.brServerAlias joao.com.br www.joao.com.brDocumentRoot /var/www/joao/htmlErrorLog /var/www/joao/logs/error.logCustomLog /var/www/joao/logs/access.log combined

</VirtualHost>

Você pode também salvar os logs na pasta de logs padrão do Apache, de forma a se beneficiar do rotacionamento automático de logs oferecido pelo logrotate. Nesse caso, você precisa apenas especificar um arquivo de log diferente para cada site, todos salvos dentro da pasta padrão, como em:

<VirtualHost *:80>ServerAdmin [email protected] www.joao.com.brServerAlias joao.com.br www.joao.com.brDocumentRoot /var/www/joao/htmlErrorLog /var/log/apache2/joao.error.logCustomLog /var/log/apache2/joao.access.log combined

</VirtualHost>

Note que, como todos os sites ficam hospedados no mesmo servidor, a única forma de chegar ao site


desejado é fazendo o acesso através do domínio. Se você tentar acessar diretamente o IP do servidor, vai cair no site padrão (configurado através do arquivo "/etc/apache2/sites-available/default"), que, por padrão, usa o raiz da pasta "/var/www". Esta página default pode ser usada para mostrar alguma publicidade da empresa responsável pelo servidor, ou uma lista dos sites hospedados, por exemplo.

Concluindo, caso queira ativar o suporte a SSL para algum dos virtual hosts, adicione a sessão referente ao SSL dentro da configuração de cada site, indicando corretamente a pasta do site e os arquivos de log. O SSL pode ser tanto ativado para o raiz do site, permitindo que os visitantes visualizem qualquer parte do site usando o "https://", ou utilizar uma pasta separada, onde está a parte de comércio eletrônico do site, por exemplo, como em:

<VirtualHost *:443>ServerName www.joao.com.brDocumentRoot /var/www/joao/sslSSLEngine onSSLCertificateFile /etc/apache2/ssl/apache.pem

</VirtualHost>

Neste caso, ao acessar o "http://www.joao.com.br", o visitante visualizará o conteúdo da pasta "/var/www/joao/html", enquanto ao acessar o "https://www.joao.com.br", visualizará a "/var/www/joao/ssl".

Como vimos no tópico anterior, certificados SSL são válidos apenas para um domínio específico. Se você deseja oferecer suporte a SSL para vários subdomínios hospedados no servidor, a melhor opção é adquirir um certificado wildcard, que é valido para qualquer subdomínio dentro do domínio principal da sua empresa. Isso permite que você crie diversos virtual hosts, como "loja1.minhaempresa.com" e "loja2.minhaempresa.com", utilizando o mesmo certificado.

Essa configuração manual funciona para pequenos servidores, que hospedam algumas dezenas ou centenas de páginas. Grandes serviços de hospedagem geralmente acabam desenvolvendo algum tipo de sistema para automatizar a tarefa. Nos serviços de hospedagem gratuita, por exemplo, onde o número de clientes é assustadoramente grande, as alterações são feitas de forma automática quando o visitante faz seu cadastro, geralmente através de um sistema escrito em PHP ou Java.

Conforme o número de usuários cresce e o espaço em disco no servidor começa a ficar escasso, você começará a sentir falta de um sistema de quotas, que limite o espaço que cada usuário pode usar. Para isso, consulte o tópico sobre quotas de disco, mais adiante.

Instalando o suporte a PHP

No início, existiam apenas páginas html estáticas, com links atualizados manualmente. Depois, surgiram os scripts CGI (geralmente escritos em Perl), que permitiram criar vários tipos de formulários e automatizar funções. Finalmente, surgiu o PHP, adotado rapidamente como a linguagem padrão para criação de todo tipo de página dinâmica, fórum ou gerenciador de conteúdo.

Além da linguagem ser bastante flexível, um script em PHP chega a ser mais de 100 vezes mais rápido que um script CGI equivalente, além de mais seguro. Em resumo, um script CGI é um executável, que precisa ser carregado na memória, executado e descarregado cada vez que é feita uma requisição. No caso do PHP, o interpretador fica carregado continuamente e simplesmente vai executando de forma contínua os comandos recebidos dos scripts incluídos nas páginas.

No Debian o suporte a PHP é instalado através do pacote "php5" (ou "php4", de acordo com a versão escolhida). Para instalá-lo, basta usar o gerenciador de pacotes da distribuição em uso, como em:

# aptget install php5

No caso do CentOS e do Fedora, é usado um pacote unificado, o "php", que inclui a versão mais recente do interpretador, eliminando a confusão:

# yum install php

Com o interpretador PHP instalado, falta instalar o módulo do Apache 2, que no Debian está disponível através do pacote "libapache2-mod-php5" (ou "libapache2-mod-php4", de acordo com a versão desejada):

# aptget install libapache2modphp5


No Debian o módulo "libapache2-mod-php5" é Ativado com ocomando a2enmod:

# a2enmod php5

Não esqueça de reiniciar o serviço para que o módulo seja carregado e a configuração entre em vigor:

# /etc/init.d/apache2 forcereloadou:

# service apache2 restart

No caso do CentOS/Fedora o mod_php é instalado junto com o pacote "php" e ativado automaticamente, através da criação do arquivo "/etc/httpd/conf.d/php.conf". Dentro dele, você encontra as linhas que carregam o módulo e criam a associação com os arquivos .php, como em:

LoadModule php5_module modules/libphp5.soAddHandler php5script .phpAddType text/html .phpDirectoryIndex index.php

Com o suporte a PHP ativado, o Apache continua exibindo diretamente páginas com extensão .htm ou .html, mas passa a entregar as páginas .php ou .phps ao interpretador php, que faz o processamento necessário e devolve uma página html simples ao Apache, que se encarrega de enviá-la ao cliente.

Quase sempre, os sistemas desenvolvidos em PHP utilizam também um banco de dados MySQL ou Postgre SQL. Naturalmente, é perfeitamente possível que os scripts simplesmente salvem as informações em arquivos de texto dentro do diretório do site, mas isso resultaria em um desempenho muito ruim, sem falar em eventuais brechas de segurança. Utilizar um banco de dados permite armazenar um volume muito maior de informações, acessíveis de forma mais segura.

Para que o interpretador PHP seja capaz de acessar o banco de dados, é necessário ter instalado (além do servidor MySQL propriamente dito) o módulo "php5-mysql" (ou "php4-mysql"), que faz a junção entre os dois componentes:

# aptget install php5mysql

No caso do PostgreSQL, é utilizado o módulo "php5-pgsql", que tem a mesma função:

# aptget install php5pgsql

Não se esqueça de reiniciar o Apache, para que as alterações entrem em vigor:

# /etc/init.d/apache forcereload

No caso do Fedora e do CentOS, muda apenas o nome do pacote, que passa a se chamar simplesmente "php-mysql":

# yum install phpmysql

Testando suporte ao PHPPara verificar se o suporte a PHP está realmente ativo, crie um arquivo de texto chamado "info.php" (ou outro nome qualquer, seguido da extensão .php) dentro da pasta do servidor web, contendo apenas a linha abaixo:

<? php phpinfo( ); ?>

Salve o arquivo e abra a página através do navegador. A função "phpinfo", que usamos no arquivo, faz com que o servidor exiba uma página com detalhes da configuração do PHP e dos módulos ativos:


OBS: Depois de verificar, remova o arquivo, pois não é interessante que essas informações fiquem disponíveis ao público.

Dicas de segurança do PHP

O interpretador php é configurado através do arquivo "php.ini", um longo arquivo de configuração que permite ativar ou desativar opções diversas da linguagem como, por exemplo, a possibilidade de fazer upload de arquivos através de scripts colocados nas páginas.

A localização do arquivo pode variar de acordo com a distribuição, mas você pode encontrá-lo rapidamente usando o comando "locate". No caso do CentOS, o arquivo é o "/etc/php.ini", enquanto nas distribuições derivadas do Debian é usado o arquivo "/etc/php5/apache2/php.ini".

Para melhorar a segurança, é recomendável desativar as funções "show_source", "system", "shell_exec", "passthru", "exec", "popen", "proc_open", "symlink". Este procedimento pode ser feito através da opção "disable_functions =", arquivo. Basta adicionar a lista das funções, consistem em preencher as funções a serem desativadas como em:

disable_functions = show_source, system, shell_exec, passthru, exec, popen, proc_open, symlink

Outras opções que é recomendável manter desativadas dentro do arquivo são:

• expose_php = Off

• register_globals = Off

• allow_url_fopen = Off

• allow_url_include = Off

A opção "allow_url_fopen" permite abrir ou processar uma página ou arquivo externo dentro do script php. Embora ela seja uma função útil, usada por scripts que geram uma lista de links a partir de um feed, por exemplo, ela pode ser usada para diversos tipos de abusos, o que faz com que seja desativada em diversos serviços de hospedagem.

Ao tentar executar algum script em PHP que dependa da função desativada, você receberá um erro similar a:

Warning: file_get_contents() [function.file-get-contents]: URL file-access is disabled in the server configuration in /var/ww/site/rss.php on line 59

Nesse caso, você tem duas opções. Ou volta a ativar a opção dentro do arquivo, substituindo a linha "allow_url_fopen = Off" por "allow_url_fopen = On" (é necessário reiniciar o serviço do Apache para que a alteração entre em vigor) ou reescreve o script usando a função "cURL", para que o script baixe o arquivo antes de processá-lo.

Ativando o SSL

O SSL (Secure Socket Layer) é o protocolo usado para criar páginas seguras, encriptando toda a transmissão entre o cliente e o servidor. Os dois usos mais comuns são em páginas de comércio eletrônico, onde é necessário oferecer um ambiente seguro para concluir a transação e transmitir dados confidenciais e também na criação de ambientes administrativos, como os usados pela maioria dos gestores de conteúdo, que permitem que você gerencie o conteúdo do site.

Na grande maioria das distribuições, o pacote com o mod_ssl é instalado juntamente com o pacote principal do Apache, ou é pelo menos disponibilizado como um pacote separado, instalável através do gerenciador de pacotes.

No caso das distribuições derivadas do Debian, você precisa apenas ativar o módulo usando o comando "a2enmod". Reinicie o serviço para que a alteração entre em vigor:

# a2enmod ssl# /etc/init.d/apache2 forcereload


No caso do CentOS, é necessário instalar o pacote "mod_ssl" usando o yum. O script de pós-instalação se encarrega de adicionar o script de carregamento na pasta "/etc/httpd/conf.d" automaticamente, concluindo a instalação. Não se esqueça de reiniciar o serviço para que a alteração entre em vigor:

# yum install mod_ssl# service httpd restart

Com o módulo carregado, fica faltando apenas o componente mais importante, que é o certificado SSL propriamente dito.

Se você quer ativar o SSL para testes ou para uso interno (para acessar alguma ferramenta administrativa instalada no servidor, ou para uso em uma página disponibilizada apenas para um grupo de amigos, por exemplo), você pode simplesmente gerar seu próprio certificado, o que é rápido, grátis e indolor. Se, por outro lado, você está ativando o SSL para uso em um site de comércio eletrônico, é necessário obter um certificado reconhecido através da Verisign ou outra entidade certificadora.

Os certificados caseiros são chamados de certificados self-signed (auto-assinados), já que você mesmo faz o papel de entidade certificadora, gerando e assinando o certificado. O algoritmo de encriptação usado é o mesmo, de forma que um certificado self-signed corretamente gerado oferece a mesma segurança que um certificado reconhecido. O grande problema é que os navegadores nos clientes não serão capazes de verificar a autenticidade do certificado, de forma que os visitantes receberão um aviso de "certificado não reconhecido" ao acessarem a página.

O propósito de entidades certificadoras, como a Verisign, é confirmar a titularidade dos certificados, confirmando que o certificado recebido ao acessar determinado site pertence realmente à entidade que o está fornecendo. É isso que garante que você está mesmo acessando o home banking do banco em que tem conta e não o site de um script kiddie qualquer. Certificados assinados por entidades certificadoras são automaticamente aceitos pelos navegadores (já que sua identidade já foi confirmada pela entidade certificadora), o que evita a exibição da mensagem.

Usando um certificado self-signed

No Debian e derivados você pode gerar um certificado caseiro utilizando o script "make-ssl-cert", instalado através do pacote "ssl-cert":

# aptget install sslcert

Ao usar o script, você deve especificar o arquivo com o template (/usr/share/ssl-cert/ssleay.cnf) e o arquivo onde o certificado será salvo (/etc/apache2/ssl/apache.pem, para gerar um certificado padrão para o servidor), como em:

# mkdir /etc/apache2/ssl/# cd /etc/apache2/ssl/# makesslcert /usr/share/sslcert/ssleay.cnf apache.pem days 1095

Entendendo o make-ssl-cert:

• A opção "-days" especifica a validade do certificado, que no exemplo será de 3 anos.

• O script solicitará as informações sobre a organização que serão incluídas no certificado, incluindo o código de país, estado, cidade e o nome da empresa. Estes são dados públicos, que serão exibidos aos clientes como parte das propriedades do certificado.

• O mais importante vem no final, quando o script pergunta:

Common Name (eg, your name or your server's hostname) []:

Nesse ponto, você deve sempre fornecer a URL completa do servidor onde o certificado será usado, como em "www.gdhpress.com.br" ou "ssl.gdhn.com.br". Se você especificar um domínio diferente, o cliente receberá um aviso adicional ao se conectar, avisando do problema. Isso afastará visitantes, já que muitos pensarão tratar-se de uma fraude.

Com o certificado gerado, abra agora o arquivo "/etc/apache2/ports.conf" e adicione a linha "Listen 443" (a porta usada pelo https), como em:


Port 80Listen 443

Com isso, o Apache 2 já está configurado. Falta apenas ativar o uso do SSL dentro da configuração do(s) virtual host(s) onde ele for ser utilizado. Para testar, vamos ativá-lo na página padrão que usamos para testar o servidor.

No Debian e derivados:

1º Passo: Abra o arquivo "/etc/apache2/sites-available/default". No início do arquivo, substitua a linha "NameVirtualHost *", por:

NameVirtualHost *:443NameVirtualHost *:80

Isso explica que o Apache deve escutar tanto a porta 80 padrão, quanto a porta 443, usada pelo SSL.

2º Passo: Logo em seguida, substitua a linha "<VirtualHost *>", por:

<VirtualHost *:80>

Até aqui, dividimos a configuração em duas seções, uma para a porta 80, outra para a porta 443, usada pelo SSL.

3º Passo: Agora adicionar uma nova seção referente à configuração do SSL no final do arquivo. Copie a seção <VirtualHost *:80> e edite para que fique semelhante ao exemplo abaixo:

<VirtualHost *:443>DocumentRoot /var/www/ErrorLog /var/log/apache2/error.logCustomLog /var/log/apache2/access.log combinedSSLEngine onSSLCertificateFile /etc/apache2/ssl/apache.pem

</VirtualHost>

3º Passo: Reinicie o servidor (/etc/init.d/apache2 restart) e acesse o endereço "https://127.0.0.1" para testar a configuração. Ao conectar, o navegador exibe um aviso "O certificado do servidor falhou no teste de autenticidade" ou similar, o que é normal ao usar um certificado caseiro.

No CentOS/Fedora

O CentOS não inclui o make-ssl-cert, mas inclui um outro script bastante prático, disponível dentro da pasta "/etc/pki/tls/certs":

1º Passo: Acesse o diretório /etc/pki/tls/certs;

# cd /etc/pki/tls/certs

2º Passo: Uma vez dentro da pasta, use o comando "make" seguido pelo nome do arquivo que será gerado, como em:

# make apache.pem

Por default, a validade do certificado gerado pelo script será de 365 dias. Para usar outro valor, edite o arquivo "make-dummy-cert" dentro da pasta, substituindo o "-days 365" na quinta linha de baixo para cima pelo valor desejado antes de gerar o certificado.

Como reultado o arquivo "/etc/pki/tls/certs/apache.pem" é gerado contendo o certificado.

3º Passo: Para que o certificado gerado no item anterior seja utilizado, abra o arquivo "/etc/httpd/conf.d/ssl.conf" e localize a linha abaixo e descomente-a:

#SSLCACertificateFile /etc/pki/tls/certs/cabundle.crt


4º Passo: indique a localização do arquivo de certificado gerado, como em::

SSLCACertificateFile /etc/pki/tls/certs/apache.pem

5º Passo: Reiniciar o serviço httpd e testar a configuração acessando o endereço "https://servidor".

OBSERVAÇÕES:

• Diferente do Debian, não é necessário adicionar a linha "Listen 443" na configuração do Apache, pois a linha faz parte do arquivo "/etc/httpd/conf.d/ssl.conf", que é criado automaticamente ao instalar o pacote mod_ssl.

Outras ditribuições

Em outras distribuições, você pode usar diretamente o openssl para gerar o certificado. Nesse caso, o comando é maior, já que precisamos especificar manualmente um volume maior de parâmetros. Scripts como o make-ssl-cert são desenvolvidos justamente para tornar a geração do certificado mais simples.

# openssl req new x509 days 1095 sha1 newkey rsa:1024 nodes \keyout server.key out meuservidor.csr

Este comando gera dois arquivos separados, o "server.key", que contém a chave criptográfica e o "meuservidor.csr", que contém o certificado que será fornecido aos clientes. Estes dois arquivos tem a mesma função do arquivo ".pem" que é gerado pelos scripts do Debian e do CentOS, apenas desmembrado em dois arquivos separados. Para usá-los, você precisa apenas adicionar duas linhas separadas dentro do arquivo de configuração principal do Apache ("/etc/apache2/httpd.conf" no caso do Debian ou "/etc/httpd/conf/httpd.conf", no caso do CentOS), especificando as localizações dos dois arquivos:

SSLCertificateFile /etc/apache2/ssl/meuservidor.csrSSLCertificateKeyFile /etc/apache2/ssl/server.key

OBSERVAÇÕES:

• Lembre-se de ativar o mod_ssl;

• Lembre-se de incluir a linha "Listen 443" na configuração do Apache, para que o serviço passe a escutar a porta do SSL;

• Certifique-se também de que a porta 443 está aberta na configuração do firewall.

Usando um certificado reconhecido

Finalmente, temos a configuração para um certificado reconhecido, que será assinado por uma entidade certificadora, que você utilizaria em um site de comércio eletrônico aberto ao público.

Uma das entidades certificadoras mais tradicionais é a Verisign (http://www.verisign.com/), que oferece uma série de garantias sobre os certificados emitidos. O grande problema com relação à Verisign é o preço: o certificado de validação mais simples custa nada menos de US$ 499 anuais, com opções de até US$ 1499. Com preços tão altos, não é de se estranhar que existam inúmeras outras entidades certificadoras, que oferecem preços mais competitivos.

Em termos de segurança, não existe muita diferença entre um certificado emitido pela Godaddy ou pela Verisign, as principais diferenças são o nível de validação e as garantias oferecidas por cada uma em caso de fraude ou de quebra da chave criptográfica. Assim como em outras áreas, o principal fator na decisão acaba sendo a questão da confiança.

Ao contratar os serviços de uma entidade certificadora, sua parte no trabalho é a de gerar uma chave de encriptação e uma requisição de certificado,

1º passo: Gerar a chave de encriptação que é novamente feito usando o openssl:

# openssl req new nodes keyout gdhn.key out gdhn.csr


O "gdhn.key" e o "gdhn.csr" indicam os arquivos com a chave e com a requisição do certificado que serão gerados. Você precisará responder as mesmas perguntas sobre o país, estado, cidade, nome da empresa, etc., que precisam ser respondidas corretamente, já que as informações serão examinadas não apenas pela entidade certificadora, mas também pelos clientes:

Country Name (2 letter code) [AU]: BR

State or Province Name (full name) [Some-State]: Estado

Locality Name (eg, city) []: Cidade

Organization Name (eg, company) []: Minha Empresa LTDA

Organizational Unit Name (eg, section) []: Vendas

Common Name (eg, YOUR name) []: ssl.minhaempresa.com.br

Como comentado anteriormente, o campo "Common Name" deve ser preenchido com o domínio onde o certificado será usado (incluindo o "www" ou o subdomínio usado), caso contrário os clientes receberão um aviso ao acessarem o site:

Em geral, as entidades certificadoras oferecem a opção de obter um certificado curinga (wildcard), que cobre automaticamente todos os subdomínios usados no site. Entretanto, como eles abrem a possibilidade de usar vários subdomínios usando um único certificado, as certificadoras cobram bem mais caro por eles

2º passo: No final do processo, o openssl oferece a opção de especificar uma senha (challenge password) para o certificado. É importante deixá-la em branco, caso contrário você precisará fornecê-la cada vez que o servidor web for iniciado, incluindo casos de reboots acidentais. O arquivo do certificado é armazenado em uma pasta protegida do servidor, fora do diretório disponível para a web, de forma que se um atacante chega ao ponto de obter acesso a ele, significa que o problema é mais embaixo e ele muito provavelmente já obteve acesso completo ao servidor de qualquer forma.

3º passo: Envio dos arquivos para a certificação. Depois de gerar a requisição, o próximo passo é enviar o arquivo .csr para a entidade certificadora, que o usará para gerar o certificado. O arquivo .csr é na verdade um arquivo de texto plano, cujo conteúdo pode ser copiado e colado em um formulário web. Depois de confirmada sua identidade e feito o pagamento, você receberá de volta o certificado assinado, que pode ser então usado na configuração do Apache.

4º passo: Configuração do site com os arquivo devidamente assinados A configuração consiste em adicionar as linhas "SSLCertificateFile" e "SSLCertificateKeyFile", indicando a localização dos arquivos .crt e .key recebidos. Em muitos casos, você receberá também um terceiro arquivo, com extensão "ca-bundle" ou similar, que é usado em conjunto com uma terceira opção, a "SSLCertificateChainFile". Este terceiro arquivo contém uma combinação de certificados, que permitem aos clientes chegarem até o certificado raiz da entidade certificadora, de forma a comprovarem a autenticidade do seu certificado. Devido a isso, ele é também chamado de certificado intermediário (Intermediate Certificate). Temos aqui um exemplo de configuração com as três opções:


Figura 3: erro de certificado

<VirtualHost *:443>DocumentRoot /var/www/gdhnSSLEngine onSSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crtSSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.keySSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.cabundle

</VirtualHost>

O processo de emissão do certificado inclui uma verificação de identidade, que é justamente um dos principais papéis da entidade certificadora, já que se qualquer um pudesse gerar certificados válidos no nome de qualquer outro, o sistema perderia completamente o sentido. Nos planos mais simples, como no certificado gratuito oferecido pela Comodo, é feita uma simples verificação de titularidade via e-mail, onde você deve confirmar um código enviado para uma conta administrativa, como "admin@meudominio" ou "hostmaster@meudominio". Nos planos mais caros (onde a entidade certificadora realmente oferece garantias, inclusive financeiras sobre o certificado emitido), o processo é mais burocrático, incluindo o envio de documentos.

Usando o SSL para pastas específicas

Em geral, você vai desejar usar o SSL apenas para seções específicas do site, como no caso de páginas de cadastro e de vendas, por exemplo. Na maioria dos casos, o cliente navega livremente pelo site, usando o protocolo HTTP não encriptado e acessa uma área protegida pelo SSL ao concretizar a compra ou ao acessar uma área onde precisa fornecer dados pessoais. Isso acontece por um motivo muito simples: servir páginas em HTTPS é caro em termos de processamento, de forma que encriptar o acesso a todo o site acabaria gerando um grande desperdício de recursos.

Você tem então duas opções. Usar um domínio separado para a área protegida, como "ssl.minhaempresa.com", de forma que ela fique completamente separada do restante do site, ou proteger apenas uma pasta específica do site, tornando mandatário o uso do HTTPS ao acessá-la.

Para a primeira solução, você usaria uma configuração similar a essa dentro da configuração do Apache:

<VirtualHost *:80>ServerName www.gdhn.com.brDocumentRoot /var/www/gdhn

</VirtualHost>

<VirtualHost *:443>ServerName ssl.gdhn.com.brDocumentRoot /var/www/gdhnsslSSLEngine onSSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crtSSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.keySSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.cabundle

</VirtualHost>

Veja que, nesse caso, temos essencialmente dois sites separados, um acessível apenas via HTTP e outro apenas via HTTPS. Ao acessar o "http://www.gdhn.com.br" o visitante acessaria a pasta "/var/www/gdhn", que conteria o conteúdo geral do site, enquanto ao acessar o "https://ssl.gdhn.com.br" ele acessaria as páginas da seção segura, armazenadas na pasta "/var/www/gdhn-ssl". A interligação entre as duas partes seria então feita através de links, que levariam o visitante de uma seção à outra do site.

A segunda opção, usar uma pasta para o SSL, é um pouco mais elegante, mas demanda uma configuração um pouco mais cuidadosa. Imagine que a seção segura do site será armazenada dentro da pasta "/var/www/gdhn/loja", que deverá ser acessada apenas via HTTPS.

Ao acessar o "https://www.gdhn.com.br" o visitante cairá direto na pasta segura e, ao tentar acessar o "http://www.gdhn.com.br/loja" ele será automaticamente redirecionado ao "https://www.gdhn.com.br". Nesse caso, você utilizaria uma configuração similar a essa:


<VirtualHost *:80>ServerName www.gdhn.com.brDocumentRoot /var/www/gdhn<Directory /var/www/gdhn/loja>

SSLRequireSSL</Directory>Redirect /loja https://www.gdhn.com.br

</VirtualHost>

<VirtualHost *:443>ServerName www.gdhn.com.brDocumentRoot /var/www/gdhn/lojaSSLEngine onSSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crtSSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.keySSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.cabundle

</VirtualHost>

Entendendo a segunda alternativa:

• Note que agora, usamos o domínio "www.gdhn.com.br" nas duas seções da configuração, tanto para HTTP quanto para HTTPS, entretanto, a seção com a configuração do HTTPS aponta para a pasta "/var/www/gdhn/loja";

• Como a idéia é que os arquivos da pasta possam ser acessados apenas usando o SSL, adicionamos uma diretiva para a pasta (<Directory /var/www/gdhn/loja>), dizendo que ela só pode ser acessada via HTTPS (SSLRequireSSL);

• Para que os visitantes que tentarem acessar a pasta via HTTP sejam encaminhados para a área protegida, usamos uma regra de encaminhamento (Redirect /loja https://www.gdhn.com.br). Esta regra utiliza o módulo "rewrite", que precisa estar ativo na configuração do Apache. Caso necessário, ative-o usando o comando "a2enmod rewrite e reinicie o apache".

Finalmente, caso você queira que todo o conteúdo do site fique disponível via HTTPS e que os visitantes que tentarem acessar o http://www.gdhn.com.br/ sejam encaminhados para o https://www.gdhn.com.br, a configuração seria similar a essa:

<VirtualHost *:80>ServerName www.gdhn.com.brDocumentRoot /var/www/gdhn<Directory /var/www/gdhn/>

SSLRequireSSL</Directory>Redirect / https://www.gdhn.com.br

</VirtualHost>

<VirtualHost *:443>ServerName www.gdhn.com.brDocumentRoot /var/www/gdhn/SSLEngine onSSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crtSSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.keySSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.cabundle

</VirtualHost>

Como pode ver, a configuração é quase idêntica à do exemplo anterior. As únicas diferenças são que agora a seção com a configuração do HTTPS aponta para o diretório raiz do site e a regra de redirecionamento encaminha todos os acessos feitos feitos via HTTP para o https://www.gdhn.com.br, fazendo com que o acesso a qualquer página do site seja feito via SSL.


Referências

[1] Sevidores Linux, capítulo 6. Configurando Servidores Web. Documentação online. Disponível em: http://www.hardware.com.br/livros/servidores-linux/capitulo-configurando-servidores-web.html. Acesso em: 20 dezembro de 2012

[2] Configurando servidores DNS, no muque, parte 1. DNS e Virtual Hosting. Tutorial online. Disponível em: http://www.hardware.com.br/tutoriais/servidores-dns/pagina3.html. Acesso em: 20 dezembro de 2012


Laboratorio Servidor Web

Documents

Transcript of Laboratorio Servidor Web