Passos recomendados para proteger o HTTP Apache no FreeBSD 12.0

O autor selecionou o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

Introdução

Embora a instalação padrão de um servidor HTTP Apache já seja segura para usar, sua configuração pode ser melhorada substancialmente com algumas modificações. É possível complementar os mecanismos de segurança atuais como, por exemplo, definindo proteções em torno de cookies e cabeçalhos, de modo que as conexões não possam ser alteradas no nível cliente do usuário. Ao fazer isso, é possível reduzir drasticamente as possibilidades de vários métodos de ataque, como ataques de Cross-Site Scripting (também conhecidos por XSS). Também é possível evitar outros tipos de ataques, como a solicitação intersite forjada (XSRF), ou sequestro de sessão, bem como ataques de negação de serviço.

Neste tutorial, você implementará alguns passos recomendados para reduzir o nível de exposição das informações em seu servidor. Você verificará as listas de diretórios e desativará a indexação para verificar o acesso aos recursos. Você também vai alterar o valor padrão da diretiva timeout, para ajudar a mitigar os ataques do tipo negação de serviço. Além disso, você desativará o método TRACE, de modo que as sessões não possam ser invertidas e sequestradas. Por fim, protegerá cabeçalhos e cookies.

A maioria das definições de configuração serão aplicadas ao arquivo de configuração principal do HTTP Apache encontrado em /usr/local/etc/apache24/httpd.conf.

Pré-requisitos

Antes de iniciar este guia, você precisará do seguinte:

• Um servidor FreeBSD 12 configurado, seguindo o tutorial sobre Como começar a usar o FreeBSD.

• Um firewall configurado de acordo com a seção Configurando um firewall, no artigo Passos recomendados para novos servidores FreeBSD 12.0.

• Uma pilha FAMP completa instalada, de acordo com o tutorial Como instalar uma pilha Apache, MySQL e PHP (FAMP) no FreeBSD 12.0.

• Um certificado Let’s Encrypt instalado,de acordo com o tutorial Como proteger o Apache com o Let’s Encrypt no FreeBSD.

Com os pré-requisitos instalados, você terá um sistema FreeBSD com uma pilha sobre ele, capaz de atender o conteúdo Web usando qualquer coisa escrita em PHP, tais como softwares de CMS importantes. Além disso, você criptografou conexões seguras através do Let’s Encrypt.

Reduzindo as informações do servidor

A faixa do sistema operacional é um método usado por computadores, servidores e dispositivos de todos os tipos para se apresentarem nas redes. Atores mal-intencionados podem usar essa informação para conseguir acesso às vulnerabilidades de sistemas relevantes. Nesta seção, você reduzirá a quantidade de informações publicadas por essa faixa.

Conjuntos de diretivas controlam como essa informação é exibida. Para essa finalidade, a diretiva ServerTokens é importante; por padrão, ela mostra todos os detalhes sobre o sistema operacional e os módulos compilados para o cliente que está se conectando a ele.

Você usará uma ferramenta de verificação de rede para conferir quais informações são atualmente reveladas, antes de aplicar qualquer alteração. Para instalar o nmap, execute o seguinte comando:

sudo pkg install nmap

Para obter o endereço IP do seu servidor, execute o seguinte comando:

ifconfig vtnet0 | awk '/inet / {print $2}'

Verifique a resposta do servidor Web, usando o seguinte comando:

nmap -sV -p 80 your-server-ip

Você invoca o nmap para fazer uma verificação (por conseguinte, o sinalizador -s), para exibir a versão (o sinalizador -V) na porta 80 (o sinalizador -p) de um determinado IP ou domínio.

Você receberá informações sobre seu servidor Web, semelhantes às seguintes:

Output
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET
Nmap scan report for 206.189.123.232
Host is up (0.054s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Esse resultado mostra que informações como o sistema operacional, a versão HTTP Apache e o OpenSSL estão visíveis. Isso pode ser útil para que invasores consigam informações sobre o servidor e escolham as ferramentas certas para acessar, por exemplo, uma vulnerabilidade no software que está em execução no servidor.

Você colocará a diretiva ServerTokens no arquivo de configuração principal, já que ela não vem configurada por padrão. A falta dessa configuração faz com que o HTTP Apache mostre toda a informação sobre o servidor, da maneira como está na documentação. Para limitar as informações que são reveladas sobre seu servidor e configuração, você colocará a diretiva ServerTokens dentro do arquivo de configuração principal.

Coloque essa diretiva após a entrada ServerName, no arquivo de configuração. Execute o seguinte comando para encontrar a diretiva:

grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

Você encontrará o número da linha que você poderá pesquisar com o vi:

Output
226    #ServerName www.example.com:80

Execute o seguinte comando:

sudo vi +226 /usr/local/etc/apache24/httpd.conf

Adicione a linha destacada a seguir:

. . .
#ServerName www.example.com:80
ServerTokens Prod

Salve e saia do arquivo com :wq e ENTER.

Definir a diretiva ServerTokens para Prod fará com que ela exiba apenas que este é um servidor Web Apache.

Para que isso entre em vigor, reinicie o servidor HTTP Apache:

sudo apachectl restart

Para testar as alterações, execute o seguinte comando:

nmap -sV -p 80 your-server-ip

Você verá um resultado semelhante ao seguinte, com informações reduzidas sobre seu servidor Web Apache:

Output
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET
Nmap scan report for WPressBSD (206.189.123.232)
Host is up (0.056s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Você viu quais informações o servidor estava anunciando antes da mudança e agora reduziu isso a um mínimo. Com isso, estará fornecendo menos pistas sobre seu servidor a um agente externo. No próximo passo, você irá gerenciar as listagens de diretórios para seu servidor Web.

Gerenciando listagens de diretórios

Neste passo, você irá assegurar que a listagem de diretórios esteja devidamente configurada, de modo que as partes certas do sistema fiquem publicamente disponíveis, conforme pretendido, ao passo que as demais partes fiquem protegidas.

Adicionar a instrução Options -Indexes definirá o conteúdo dentro do caminho de dados /usr/local/www/apache24/data para não indexar (leia listado) automaticamente se não existir um arquivo .html e para não exibir se um URL mapear esse diretório. Isso também se aplicará quando usar configurações de host virtual, como a que foi usada no tutorial com os pré-requisitos para o certificado Let’s Encrypt.

Você definirá a diretiva Options com o argumento -Indexes e com a diretiva +FollowSymLinks, o que permitirá que links simbólicos sejam seguidos. Você usará o símbolo + para cumprir com as convenções do HTTP do Apache.

Execute o seguinte comando para encontrar a linha a ser editada no arquivo de configuração:

grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

Você verá um resultado similar ao seguinte:

Output
263 :    Options Indexes FollowSymLinks

Execute este comando para acessar diretamente a linha para edição:

sudo vi +263 /usr/local/etc/apache24/httpd.conf

Agora, edite a linha de acordo com a configuração:

. . .
#
Options -Indexes +FollowSymLinks

#
. . .

Salve e saia do arquivo com :wq e ENTER.

Reinicie o HTTP Apache para implementar estas alterações:

sudo apachectl restart

No seu domínio, no navegador, você verá uma mensagem de acesso proibido, também conhecida como erro 403. Isso se deve às alterações que você aplicou. Colocar -Indexes na diretiva Options desabilitou a capacidade de auto-indexação do HTTP Apache e, portanto, não haverá nenhum arquivo index.html no caminho dos dados.

Você pode resolver isso, colocando um arquivo index.html dentro do VirtualHost que você habilitou no tutorial com os pré-requisitos para o certificado Let’s Encrypt. Você usará o bloco padrão dentro do HTTP Apache e o colocará na mesma pasta que o DocumentRoot que tiver declarado no host virtual.

<VirtualHost *:80>
    ServerAdmin your_email@your_domain.com
    DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
    ServerName your_domain.com
    ServerAlias www.your_domain.com
    ErrorLog "/var/log/your_domain.com-error_log"
    CustomLog "/var/log/your_domain.com-access_log" common
</VirtualHost>

Use o comando a seguir para fazer isso:

sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

Agora você verá uma mensagem It works! (Funciona!) ao visitar o seu domínio.

Nesta seção, você definiu restrições na diretiva dos Indexes, de modo a não listar nem exibir automaticamente o conteúdo, exceto o que você quiser que seja listado e exibido. Agora, caso não haja um arquivo index.html dentro do caminho de dados, o HTTP Apache não criará automaticamente um índice dos conteúdos. No próximo passo, você irá além do ocultamento de informações e personalizará diferentes diretivas.

Reduzindo o valor da diretiva de Tempo Limite

A diretiva Timeout (tempo limite) define o limite de tempo que o HTTP Apache vai aguardar por novas entradas/saídas, antes de falhar o pedido de conexão. Esta falha pode ocorrer devido a diversas circunstâncias, como pacotes que não chegam no servidor ou dados que não estão sendo confirmados como recebidos pelo cliente.

Por padrão, o tempo limite é definido em 60 segundos. Em ambientes onde o serviço de internet é lento, esse valor padrão pode fazer sentido. No entanto, um minuto é um tempo consideravelmente longo, especialmente se o servidor estiver cobrindo usuários alvo com um serviço de internet mais rápido. Além disso, durante o tempo em que o servidor não está fechando, a conexão pode ser explorada para a realização de ataques de negação de serviço (do inglês, DoS). Caso uma enorme quantidade dessas conexões mal-intencionadas ocorra, o servidor irá fraquejar e possivelmente ficará saturado e deixará de responder.

Para alterar o valor, encontre as entradas de Timeout no arquivo httpd-default.conf:

grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

Você verá um resultado parecido com este:

Output
 8  # Timeout: The number of seconds before receives and sends time out.
10  Timeout 60
26  # KeepAliveTimeout: Number of seconds to wait for the next request from the
29  KeepAliveTimeout 5
89  RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

No resultado, a linha 10 define o valor da diretiva Timeout. Para acessar diretamente essa linha, execute o seguinte comando:

sudo vi +10  /usr/local/etc/apache24/extra/httpd-default.conf

Você irá alterar o valor para 30 segundos, assim como no exemplo a seguir:

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

Salve e saia do arquivo com :wq e ENTER.

O valor da diretiva Timeout precisa equilibrar um intervalo longo o bastante, para que tais eventos permitam que uma conexão legítima e bem-sucedida ocorra, mas suficientemente curto para evitar tentativas de conexão indesejadas.

Para que essa alteração entre em vigor, reinicie o servidor HTTP Apache:

sudo apachectl restart

Você alterou o valor padrão da diretiva Timeout para mitigar parcialmente os ataques de DoS.

Desabilitando o método TRACE

O HTTP (Hypertext Transport Protocol [Protocolo de Transporte de Hipertexto]) foi desenvolvido de acordo com um modelo cliente-servidor e, como tal, o protocolo tem métodos de solicitação para recuperar ou posicionar informações vindas do servidor ou enviadas para ele. O servidor precisa entender esses conjuntos de métodos e como eles interagem entre si. Neste passo, você irá configurar os métodos mínimos necessários.

O método TRACE - antes considerado inofensivo - foi potencializado para a realizar ataques de rastreamento intersites. Esses tipos de ataques permitem que atores mal-intencionados roubem as sessões do usuário através desse método. O método foi projetado para a finalidade de depuração pelo servidor, retornando o mesmo pedido enviado originalmente pelo cliente. Como o cookie da sessão do navegador é enviado para o servidor, ele será enviado de volta novamente. No entanto, possivelmente isso poderia ser interceptado por um ator mal-intencionado que poderia, então, redirecionar a conexão de um navegador para um site controlado por ele e não para o servidor original.

Devido à possibilidade do uso indevido do método TRACE, é recomendável usá-lo apenas para depuração e não na produção. Nesta seção, você desativará esse método.

Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

sudo vi /usr/local/etc/apache24/httpd.conf

Adicione o seguinte caminho de entrada ao final do arquivo:

. . .
TraceEnable off

Uma prática recomendável é especificar apenas os métodos que você usará no seu servidor Web HTTP Apache. Isso ajudará a limitar possíveis pontos de entrada para atores mal-intencionados.

O LimitExcept pode ser útil para este propósito, uma vez que ele não permite nenhum outro método senão os que estão declarados nele. Por exemplo, uma configuração pode ser estabelecida desta forma:

DocumentRoot "/usr/local/www/apache24/data"
<Directory "/usr/local/www/apache24/data">
    Options -Indexes +FollowSymLinks -Includes
    AllowOverride none
     <LimitExcept GET POST HEAD>
       deny from all
    </LimitExcept>
    Require all granted
</Directory>

Como declarado dentro da diretiva LimitExcept, apenas os métodos GET, POST e HEAD foram permitidos na configuração.

• O método GET faz parte do protocolo HTTP e é usado para recuperar dados.
• O método POST também faz parte do protocolo HTTP e é usado para enviar dados ao servidor.
• O método HEAD é semelhante ao GET, porém, ele não possui nenhum corpo de resposta.

Você usará o comando a seguir e colocará o bloco LimitExcept dentro do arquivo:

sudo vi +272 /usr/local/etc/apache24/httpd.conf

Para definir essa configuração, você colocará o seguinte bloco na entrada da diretiva DocumentRoot, a partir do qual o seu conteúdo será lido, mais especificamente dentro da entrada Directory:

. . .
<LimitExcept GET POST HEAD>
   deny from all
</LimitExcept>
. . .

Para aplicar as alterações, reinicie o HTTP Apache:

sudo apachectl restart

A diretiva mais recente AllowedMethods oferece funcionalidades semelhantes, embora ainda esteja com status experimental.

Você viu o que são os métodos HTTP, seus usos e a proteção que oferecem contra atividades mal-intencionadas, que potencializam o método TRACE, além de como declarar quais métodos usar. A seguir, você trabalhará com proteções adicionais, dedicadas aos cabeçalhos e cookies HTTP.

Protegendo cabeçalhos e cookies

Neste passo, você irá configurar diretivas específicas para proteger as sessões que as máquinas clientes abrirão ao visitar seu servidor Web HTTP Apache. Dessa forma, seu servidor não irá carregar conteúdo indesejado, a criptografia não será reduzida e você evitará a detecção de conteúdo.

Os cabeçalhos são componentes dos métodos de solicitação. Existem cabeçalhos para ajustar a autenticação, a comunicação entre servidor e cliente, o cache, a negociação de conteúdo etc.

Os cookies são partes de informações enviadas pelo servidor para o navegador. Essas partes permitem que o servidor reconheça o navegador do cliente de um computador para outro. Elas também permitem que os servidores reconheçam as sessões dos usuários. Por exemplo, elas podem rastrear um carrinho de compras de um usuário conectado, informações de pagamento, histórico e assim por diante. Os cookies são usados e mantidos no navegador Web do cliente, uma vez que o HTTP é um protocolo sem estado, ou seja, assim que a conexão se fecha, o servidor não se lembra do pedido enviado por um cliente, ou outro.

É importante proteger os cabeçalhos, bem como os cookies, pois eles proporcionam comunicação entre o cliente do navegador Web e o servidor Web.

O módulo headers (cabeçalhos) vem ativado por padrão. Para verificar se ele está carregado, use o seguinte comando:

sudo apachectl -M | grep 'headers'

Você verá o seguinte resultado:

Output
headers_module (shared)

Se não ver nenhum resultado, verifique se o módulo está ativado dentro do arquivo do Apache httpd.conf:

grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

Como resultado, você verá uma linha não comentada, referindo-se ao módulo específico para os cabeçalhos:

. . .
122  LoadModule headers_module libexec/apache24/mod_headers.so
. . .

Remova a hashtag no início da linha mod_headers.so, se houver, para ativar a diretiva.

Ao utilizar as diretivas do HTTP Apache a seguir, você protegerá os cabeçalhos e cookies de atividade mal-intencionada, reduzindo o risco para clientes e servidores.

Agora, você irá configurar a proteção do cabeçalho. Você colocará todos esses valores de cabeçalho em um bloco. Você pode escolher aplicar esses valores como desejar, mas todos são recomendados.

Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

sudo vi /usr/local/etc/apache24/httpd.conf

Posicione o seguinte bloco ao final do arquivo:

. . .
<IfModule mod_headers.c>
  # Add security and privacy related headers
  Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
  Header set X-Content-Type-Options "nosniff"
  Header set X-XSS-Protection "1; mode=block"
  Header set Referrer-Policy "strict-origin"
  Header set X-Frame-Options: "deny"
  SetEnv modHeadersAvailable true
</IfModule>

• Header set Strict-Transport-Security "max-age=31536000; includeSubDomains": o HTTP Strict Transport Security (HTSTS) [Segurança de Transporte Estrito HTTP] é um mecanismo para servidores e clientes Web (principalmente navegadores) para estabelecer comunicações usando apenas HTTPS. Ao implementar isso, você está evitando ataques de intermediários (do inglês, man-in-the-middle ou MITM), nos quais um terceiro, no meio da comunicação, possivelmente poderia acessar partes dos dados, bem como adulterá-las.

• Header always edit Set-Cookie (. *) "$1; HttpOnly; Secure": os sinalizadores HttpOnly e Secure nos cabeçalhos ajudam a evitar ataques de script intersites, também conhecidos como XSS. Invasores podem usar os cookies indevidamente, passando-se por visitantes legítimos, ou seja, apresentando-se como outras pessoas (roubo ou falsificação de identidade).

• Header set Referrer-Policy "strict-origin": o cabeçalho Referrer-Policy define quais informações são incluídas como informações de referenciador no campo do cabeçalho.

• Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": o cabeçalho Content-Security-Policy (CSP) evitará completamente o carregamento de conteúdo não especificado nos parâmetros, o que é útil para prevenir ataques de scripts intersites (XSS). Existem muitos parâmetros possíveis para configurar a política para este cabeçalho. A linha final está configurando-o para carregar conteúdo a partir do mesmo site e atualizar qualquer conteúdo com origem de HTTP.

• Header set X-XSS-Protection "1; mode=block": este cabeçalho é compatível com navegadores mais antigos que não estão à altura dos cabeçalhos Content-Security-Policy. O cabeçalho ‘X-XSS-Protection’ fornece proteção contra os ataques de script intersites. Você não precisa definir esse cabeçalho, a menos que precise dar suporte às versões antigas de navegadores, o que é raro.

• Header set X-Frame-Options: "deny": isso impede os ataques de clickjacking [ataques à interface do usuário]. O cabeçalho ‘X-Frame-Options’ diz a um navegador se uma página pode ser renderizada em um <frame>, <iframe>, <embed> ou <object>. Dessa forma, o conteúdo de outros sites não pode ser inserido em outros, impedindo os ataques de clickjacking. Aqui, você está negando toda renderização de quadros, para que a página Web não possa ser inserida em nenhum outro lugar, nem mesmo dentro do mesmo site. Você pode adaptar isso às suas necessidades, caso, por exemplo, precise autorizar a renderização de algumas páginas por se tratarem de anúncios ou colaborações com sites específicos.

• Header set X-Content-Type-Options "nosniff": o cabeçalho ‘X-Content-Type-Options’ controla os tipos MIME, de modo que não sejam alterados nem seguidos. Os tipos MIME são padrões de formatos de arquivos; eles funcionam para texto, áudio, vídeo, imagem etc. Esse cabeçalho impede que atores mal-intencionados detectem tais arquivos e tentem alterar os tipos de arquivos.

Agora, reinicie o Apache para que as alterações entrem em vigor:

sudo apachectl restart

Para verificar os níveis de segurança das suas configurações, visite o site de cabeçalhos de segurança. Após seguir os passos neste tutorial, seu domínio irá obter uma nota A.

Neste passo, você trabalhou com até sete configurações para melhorar a segurança dos seus cabeçalhos e cookies. Esses recursos ajudarão a evitar ataques do tipo script intersites, clickjacking, entre outros.

Conclusão

Neste tutorial, você lidou com vários aspectos de segurança, desde a divulgação de informações, até a proteção de sessões, definindo ajustes alternativos na configuração de funcionalidades importantes.

Para obter mais recursos para proteger o Apache, aqui estão algumas outras referências:

• Dicas de segurança HTTP do Apache
• Diretrizes de segurança do Mozilla
• Recomendações de auditoria do Center of Internet Security para o HTTP Apache

Para obter outras ferramentas para proteger o HTTP Apache:

• mod_evasive é uma ferramenta útil para ajudar a mitigar os ataques de DoS. Encontre mais detalhes no tutorial Como se proteger contra o DoS e DDoS com o mod_evasive para o Apache.

• fail2ban é um software útil de prevenção contra invasões, para bloquear tentativas repetidas de login de usuários não autorizados. Leia mais no tutorial sobre Como proteger um servidor Apache com o Fail2Ban.

• ModSecurity é um Firewall do aplicativo Web (do inglês, WAF) e, como tal, oferece uma ampla gama de possibilidades baseadas em regras pré-definidas, escritas pelo SpyderLabs e por membros da comunidade. Você pode ler mais sobre esse assunto no artigo sobre Como configurar o ModSecurity com o Apache.