Product SiteDocumentation Site

11.2. Servidor web (HTTP)

Os administradores da Falcot Corp decidiram usar o servidor HTTP da Apache, incluído no Debian Jessie na versão 2.4.10.

ALTERNATIVA Outros servidores web

O Apache é apenas o mais conhecido (e amplamente utilizado) servidor web, porém existem outros; eles podem oferecer um melhor desempenho sob certas cargas de trabalho, mas ao custo de terem um número menor de funcionalidades e módulos disponíveis. Contudo, quando o servidor web em perspectiva é feito para servir arquivos estáticos ou agir como um proxy, alternativas tais como nginx e lighttpd, valem a pena serem investigadas.

11.2.1. Instalação do Apache

Instalar o pacote apache2 é tudo o que é preciso. ele contém todos os môdulos, incluíndo os Multi-Processing Modules (MPMs) que afetam como o Apache lida com processamento paralelo de muitas requisições (aqueles que costumeiramente eram fornecidos em pacotes apache2-mpm-* separados). Ele irá também puxar o apache2-utils que contém os utilitários de linha de comando que nós iremos descobrir mais tarde.
O MPM em uso afeta significantemente a forma com que o Apache irá lidar com as requisições simultâneas. Com o MPM worker, ele usa threads (processos leves), enquanto que com o MPM prefork ele usa um grupo de processos criados antecipadamente. Com o MPM event ele também usa threads, porém as conexões inativas (notavelmente aquelas mantidas abertas pelo recurso HTTP keep-alive) são devolvidas a um segmento de gerenciamento dedicado.
Os administradores da Falcot também instalaram o libapache2-mod-php5 a fim de incluir suporte a PHP no Apache. Isso faz com que o evento padrão MPM seja desabilitado, e o prefork seja instalado em seu lugar, já que o PHP só funciona sob esse MPM em particular.

SEGURANÇA Execução sob o usuário www-data

Por padrão, o Apache lida com as requisições de entrada sob a identidade de usuário www-data. Isso significa que uma vulnerabilidade em um script CGI executado pelo Apache (para uma página dinâmica) não comprometa todo o sistema, mas apenas os arquivos pertencentes a esse usuário em particular.
O uso do módulo suexec permite contornar essa regra para que alguns scripts CGI sejam executados sob a identidade de outro usuário. Isso é configurado com a diretiva SuexecUserGroup usergroup na configuração do Apache.
Outra possibilidade é usar um MPM dedicado, como o fornecido pelo libapache2-mpm-itk. Esse módulo em particular tem um comportamento um pouco diferente: ele permite o “isolamento” de hosts virtuais (na verdade, conjuntos de páginas) para que cada um deles seja executado como um usuário diferente. Portanto, uma vulnerabilidade em um site web não pode comprometer arquivos pertencentes ao dono de outro site web.

OLHADA RÁPIDA Lista de módulos

Uma lista completa dos módulos padrão do Apache pode ser encontrada online.
→ http://httpd.apache.org/docs/2.4/mod/index.html
O Apache é um servidor modular, e muitos recursos são implementados através de módulos externos que o programa principal carrega durante sua inicialização. A configuração padrão apenas habilita os módulos mais comuns, porém habilitar módulos novos é uma simples questão de rodar a2enmod módulo; para desabilitar um módulo, o comando é a2dismod módulo. Esses programas na verdade apenas criam (ou apagam) ligações simbólicas em /etc/apache2/mods-enabled/, que apontam para para os arquivos reais (armazenados em /etc/apache2/mods-available/).
Com sua configuração padrão, o servidor web ouve na porta 80 (como configurado em /etc/apache2/ports.conf), e serve páginas a partir do diretório /var/www/html/ (como configurado em /etc/apache2/sites-enabled/000-default.conf).

INDO ALÉM Compatibilidade com SSL

O Apache 2.4 inclui o módulo SSL, necessário para HTTP seguro (HTTPS) "de fábrica". Ele apenas precisa ser habilitado com a2enmod ssl, e então as diretivas necesssárias têm que ser adicionadas aos arquivos de configuração. Um exemplo de configuração é fornecido em /etc/apache2/sites-available/default-ssl.conf.
→ http://httpd.apache.org/docs/2.4/mod/mod_ssl.html
Alguns cuidados extra devem ser tomados se você quer fornecer conexões SSL com Perfect Forward Secrecy (essas conexões usam chaves de sessão efêmera, que garantem que um comprometimento da chave secreta do servidor não resulte no comprometimento de tráfego criptografado antigo que poderia ter sido armazenado durante um "sniffing" na rede). Dê uma olhada nas recomendações da Mozilla, em particular:
→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

11.2.2. Configuração de servidores virtuais

Um servidor virtual é uma identidade adicional para o servidor web.
Apache considera dois tipos diferentes de hosts virtuais: aqueles que se baseiam no endereço IP (ou na porta) e aqueles que se baseiam no nome de domínio do servidor web. O primeiro método requer a alocação de um endereço IP diferente (ou porta) para cada site, enquanto o segundo pode funcionar em um único endereço IP (e porta), os sites são diferenciados pelo nome de máquina enviado pelo cliente HTTP (que só funciona na versão 1.1 do protocolo HTTP — Felizmente essa versão é antiga o bastante, e assim, é utilizada por todos os clientes).
A (crescente) escassez de endereços IPv4 geralmente favorece o segundo método; contudo, fica mais complexo se os hosts virtuais precisam fornecer HTTPS também, pois o protocolo SSL nem sempre é fornecido para hospedagem virtual baseada em nome; a extensão SNI (Server Name Indication) que permite uma combinação desse tipo não é suportada por todos os navegadores. Quando vários sites HTTPS precisam ser rodados no mesmo servidor, eles geralmente irão ser diferenciados ou por rodar em uma porta diferente ou um endereço IP diferente (IPv6 pode ajudar aqui).
A configuração padrão do Apache 2 habilita hosts virtuais baseados em nomes. Além disso, um host virtual padrão é definido no arquivo /etc/apache2/sites-enabled/000-default.conf; esse host virtual será usado se não for encontrado nenhum host que corresponda à solicitação enviada pelo cliente.

ATENÇÃO Primeiro servidor virtual

Requisições relativas a hosts virtuais desconhecidos sempre serão servidas pelo primeiro host virtual definido, é por isso que nós definimos www.falcot.com em primeiro lugar aqui.

OLHADA RÁPIDA Suporte Apache ao SNI

O servidor Apache suporta uma extensão do protocolo SSL chamada Server Name Indication (SNI). Esta extensão permite ao navegador enviar o nome do nome do host do servidor web durante o estabelecimento da conexão SSL, muito antes do que o HTTP o solicitaria, que foi usado anteriormente para identificar o host virtual solicitado entre aqueles hospedados no mesmo servidor (com o mesmo endereço IP e porta). Isso permite ao Apache selecionar o certificado SSL mais adequado para a transação a proceder.
Antes do SNI, o Apache sempre usava o certificado definido no host virtual padrão. Clientes que tentavam acessar outro host virtual iriam então exibir avisos (warnings), pois eles recebiam o certificado que não correspondia com o site que eles estavam tentando acessar. Felizmente, a maioria dos navegadores agora trabalham com SNI; Isso inclui o Microsoft Internet Explorer a partir da versão 7.0 (começando no Vista), Mozilla Firefox começando com a versão 2.0, o Safari da Apple desde a versão 3.2.1 e todas as versões do Google Chrome.
O pacote Apache fornecido pelo Debian é construído com suporte a SNI; portanto, nenhuma configuração em particular é necessária.
Devemos também ter cuidado para garantir que a configuração do primeiro host virtual (aquele usado por padrão) habilite TLSv1, pois o Apache utiliza os parâmetros deste primeiro hospedeiro virtual para estabelecer conexões seguras e eles tem a melhor permissividade para isso!
Cada host virtual extra é então descrito por um arquivo armazenado em /etc/apache2/sites-available/. Configurar um site web para o domínio falcot.org é portanto uma simples questão de criar o seguinte arquivo, e então, habilita o host virtual com a2ensite www.falcot.org.

Exemplo 11.16. o arquivo /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName www.falcot.org
ServerAlias falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>
O servidor Apache, como configurado até agora, usa os mesmos arquivos de log para todos os hosts virtuais (embora isso possa ser alterado adicionando as diretivas CustomLog na definição de hosts virtuais). É, entretanto, boa prática customizar o formato desse arquivo de log para ter incluído o nome do host virtual. Isso pode ser feito criando um arquivo /etc/apache2/conf-available/customlog.conf, que define um novo formato para todos os arquivos de log (com a diretiva LogFormat), e habilitando-o com a2enconf customlog . A linha CustomLog tem também que ser removida (ou comentada) do arquivo /etc/apache2/sites-available/000-default.conf.

Exemplo 11.17. O arquivo /etc/apache2/conf.d/customlog.conf

# New log format including (virtual) host name
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Now let's use this "vhost" format by default
CustomLog /var/log/apache2/access.log vhost

11.2.3. Diretivas comuns

Essa seção revê, brevemente, algumas das diretivas comumente usadas na configuração do Apache.
O principal arquivo de configuração inclui vários blocos Directory; eles permitem especificar diferentes comportamentos para o servidor dependendo da localização do arquivo que está sendo servido. Um bloco desse tipo comumente inclui as diretivas Options e AllowOverride.

Exemplo 11.18. Bloco Directory

<Directory /var/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>
A diretiva DirectoryIndex contém uma lista de arquivos a serem experimentados quando uma requisição do cliente coincide com um diretório. O primeiro arquivo existente da lista é usado e enviado como resposta.
A diretiva Options é seguida de uma lista de opções a serem habilitadas. O valor None desabilita todas as opções; correspondentemente, All habilita todas elas exceto MultiViews. As opções disponíveis incluem:
  • ExecCGI indica que scripts CGI podem ser executados.
  • FollowSymlinks diz ao servidor que ligações simbólicas podem ser seguidas, e que a resposta deve conter o conteúdo do alvo de uma ligação como essa.
  • SymlinksIfOwnerMatch também diz ao servidor para seguir ligações simbólicas, mas apenas quando a ligação e seu alvo são do mesmo dono.
  • Includes habilita Server Side Includes (SSI para abreviar). Essas são diretivas embutidas nas páginas HTML e executadas em tempo de execução de cada requisição.
  • Indexes diz ao servidor para listar o conteúdo de um diretório se a requisição HTTP enviada pelo cliente aponta para um diretório sem um arquivo index (ie, quando nenhum arquivo mencionado na diretiva DirectoryIndex existe nesse diretório).
  • MultiViews habilita a negociação de conteúdo; isso pode ser usado pelo servidor para retornar uma página web que coincida com a língua preferida configurada no navegador.

DE VOLTA AO BÁSICO Arquivo .htaccess

O arquivo .htaccess contém as diretivas de configuração do Apache que são aplicadas cada vez que uma requisição diz respeito a um elemento do diretório aonde ele é armazenado. O âmbito dessas diretivas também repercute para todos os subdiretórios dentro desse diretório.
A maioria das diretivas que podem ser definidas no bloco Directory também podem ser definidas no arquivo .htaccess.
A diretiva AllowOverride lista todas as opções que podem ser habilitadas ou desabilitadas pelo arquivo .htaccess. Um uso comum dessa opção é restringir ExecCGI, para que o administrador escolha quais usuários tem permissão para rodar programas sob a identidade do servidor web (o usuário www-data).

11.2.3.1. Autenticação obrigatória

Em algumas circunstâncias, o acesso a parte do site web precisa ser restrita, para que apenas usuários legítimos que fornecerem um nome de usuário e uma senha tenham acesso ao conteúdo.

Exemplo 11.19. Arquivo .htaccess para autenticação obrigatária

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

SEGURANÇA Sem segurança

O sistema de autenticação usado no exemplo acima (Basic) tem uma segurança mínima já que a senha é enviada em texto puro (ela apenas é codificada com base64, que é uma codificação simples, ao invés de um método criptografado). Também deve ser notado que os documentos “protegidos” por esse mecanismo também trafegam pela rede em texto puro. Se segurança é importante, toda a conexão HTTP deve ser criptografada com SSL.
O arquivo /etc/apache2/authfiles/htpasswd-private contém uma lista de usuários e senhas; ele é comumente manipulado com o comando htpasswd. Por exemplo, o seguinte comando é usado para adicionar um usuário ou alterar a senha: 
# htpasswd /etc/apache2/authfiles/htpasswd-private user
New password:
Re-type new password:
Adding password for user user

11.2.3.2. Restringindo Acesso

A diretiva Require controla as restrições de acesso em um diretório (e seus sub-diretórios, recursivamente).
Isso pode ser usado para restringir acesso com base em muitos critérios; nós iremos parar na descrição de restrição de acesso com base no endereço IP de um cliente, mas isso pode ser feito de maneira muito mais poderosa, especialmente quando várias diretivas Require são combinadas dentro de um bloco RequireAll.

Exemplo 11.20. Apenas permite a partir da rede local

Require ip 192.168.0.0/16

ALTERNATIVA Sintaxe antiga

A sintaxe do Require só está disponível no Apache 2.4 (a versão na Jessie). Para usuários do Wheezy, a sintaxe no Apache 2.2 é diferente, e nós a descrevemos aqui principalmente para referência, embora ela possa também ficar disponível no Apache 2.4 usando o môdulomod_access_compat.
As diretivas Allow from e Deny from controlam as restrições de acesso em um diretório (e seus sub-diretórios, recursivamente).
A diretiva Order informa ao servidor a ordem em que as diretivas Allow from e Deny from são aplicadas; A última que coincidir tem precedência. Em termos concretos, Order deny,allow permite acesso se nenhum Deny from se aplica, ou se uma diretiva Allow from aplica. Por outro lado, Order allow,deny rejeita acesso se nenhuma diretiva Allow from coincide (ou se uma diretiva Deny from se aplica).
As diretivas Allow from e Deny from podem ser seguidas de um endereço IP, uma rede (como 192.168.0.0/255.255.255.0, 192.168.0.0/24 ou mesmo 192.168.0), um nome de máquina ou nome de domínio, ou a palavra chave all, designando todos.
Por exemplo, para rejeitar conexões por padrão mas permití-las a partir da rede local, você poderia usar isso: 
Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.4. Analisadores de Log

Um analisador de log é frequentemente instalado em um servidor web; já que o primeiro fornece aos administradores uma ideia precisa do padrão de uso do último.
Os administradores da Falcot Corp selecionaram o AWStats (Advanced Web Statistics) para analisar seus arquivos de log do Apache.
O primeiro passo de configuração é a customização do arquivo /etc/awstats/awstats.conf. O administradores da Falcot o mantiveram inalterado, exceto os seguintes parâmetros: 
LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"
Todos esses parâmetros são documentados através de comentários no arquivo de exemplo. Em particular, os parâmetros LogFile e LogFormat descrevem a localização e o formato do arquivo de log e a informação que ele contém; SiteDomain e HostAliases listam os vários nomes pelos quais o site web principal é conhecido.
Para sites com alto tráfego, DNSLookup geralmente não deveria ser configurado como 1; para sites menores, como o da Falcot descrito acima, essa configuração permite ter relatórios mais legíveis, que incluem o nome completo da máquina ao invés de simplesmente endereços IP.

SEGURANÇA Acesso as estatísticas

O AWStats deixa suas estatísticas disponíveis no site web sem restrições por padrão, mas restrições podem ser configuradas para que apenas alguns endereços IP (provavelmente internos) possam ter acesso a elas; a lista de endereços IP com permissão precisa ser definida no parâmetro AllowAccessFromWebToFollowingIPAddresses
O AWStats também será habilitado para outros hosts virtuais; cada host virtual precisa de um arquivo de configuração próprio como /etc/awstats/awstats.www.falcot.org.conf.

Exemplo 11.21. Arquivo de configuração dO AWStats para um servidor virtual

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"
O AWStats usa muitos ícones que estão armazenados no diretório /usr/share/awstats/icon/. Para que esses ícones fiquem disponíveis no site web, a configuração do Apache precisa ser adaptada para incluir as seguintes diretivas: 
Alias /awstats-icon/ /usr/share/awstats/icon/
Após alguns minutos (e uma vez que o script tenha sido rodado algumas vezes), os resultados ficarão disponíveis online:
→ http://www.falcot.com/cgi-bin/awstats.pl
→ http://www.falcot.org/cgi-bin/awstats.pl

ATENÇÃO Rotação dos arquivos de registro

Para que as estatísticas levem em consideração todos os logs, o AWStats precisa ser executado antes que os arquivos de log do Apache sejam rotacionados. Olhando a diretiva prerotate do arquivo /etc/logrotate.d/apache2, isso pode ser resolvido colocando um link simbólico em /usr/share/awstats/tools/update.sh no /etc/logrotate.d/httpd-prerotate: 
$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 644 root adm
  sharedscripts
  postrotate
    if /etc/init.d/apache2 status > /dev/null ; then \
      /etc/init.d/apache2 reload > /dev/null; \
    fi;
  endscript
  prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
      run-parts /etc/logrotate.d/httpd-prerotate; \
    fi; \
  endscript
}
$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate
$ sudo ln -sf /usr/share/awstats/tools/update.sh \
  /etc/logrotate.d/httpd-prerotate/awstats
Note também que os arquivos de log criados pelo logrotate precisam ter permissão de leitura para todos, especialmente o AWStats. No exemplo acima, isso é garantido pela linha create 644 root adm (ao invés da permissão padrão 640).