Guia: configurações iniciais para segurança de uma VPS para WordPress (passo a passo)

Deixe um comentário / Uncategorized / Por

Quando iniciei no desenvolvimento WEB, fui logo para full-stack. Chegando no momento de colocar a aplicação no ar, senti na pele a responsabilidade de fazer um deploy e garantir um mínimo de segurança ao servidor. Senti muita falta de um passo a passo, me guiando a cada etapa do processo e explicando o motivo de cada coisa.

Pois bem, após quase 10 anos de experiência, este é o guia que eu gostaria de ter encontrado naquela época. Lembrando que essas são medidas básicas de segurança e configuração, algumas coisas foram retiradas para não deixar o artigo muito longo. Caso tenham algum feedback, deixem aí abaixo nos comentários. Boa leitura!

Índice

  1. Instalando o sistema
  2. O que é e como configurar o SSH
  3. Bloqueando acessos como firewall (UFW)
  4. Usando fail2ban para proteção de ataques força bruta
  5. Detectando ações maliciosas com auditd
  6. Os próximos passos

1. Instalando o Sistema Operacional

Dependendo do seu provedor de hospedagem, há diversas opções disponíveis. Normalmente, escolho a versão do Ubuntu LTS (Suporte de Longo Prazo) mais recente. No momento da edição desse aquivo é a versão 20.04.

2. O que é e como configurar o SSH

Como acessar?

Para acessar o servidor, instalar pacotes e realizar configurações, utilizaremos o SSH, um protocolo que nos permite enviar comandos via terminal para o VPS. Se você não tem muita experiência, com a linha de comandos, não se preocupe, é mais simples do que parece.

Antes de tudo, você precisará de um programa que suporte esse protocolo para prosseguir. Caso esteja no Windows, instale o Cmder (baixe a versão que inclui as ferramentas que precisamos). Se está no Linux ou MacOS, essas aplicações já vêm instaladas no seu sistema por padrão.

Acessando o servidor via SSH

Para evitar ficar digitando do usuário root (uma espécie de administrador) toda vez, você pode configurar uma chave SSH para acesso ao servidor. Ela funcionará como uma espécie de documento de identificação que será utilizada para login ao invés da senha.

Em um primeiro momento, essa opção não costuma estar disponível, então vamos logar via senha dessa primeira vez. Tenha em mãos o endereço de IP da sua VPS e a senha de acesso root também. Abra um terminal e vamos colocar a “mão na massa”, digo, nos comandos.

# Substitua os 123 pelo seu endereço de IP
ssh root@123.123.123.123

Dê um enter e digite sua senha. Você deverá ver um shell com algo como: root@nomeMaquina:~$

O que são chaves SSH?

No SSH existem duas chaves: a pública e privada. A chave privada fica na sua máquina e a pública, como próprio nome indica é compartilhada publicamente é usada em conjunto com a sua chave privada para validar sua identidade.

Em uma simplificação bem fácil de entender, é como se sua chave pública fosse o número do seu CPF e o documento físico (em papel mesmo), fosse sua chave privada. Mesmo tendo o número no sistema, você ainda vai precisar mostrar o documento físico para que o responsável veja sua foto, verifique a autenticidade do documento para enfim autorizar sua entrada. Se você quer entender realmente como esse processo funciona, confira esse artigo.

Gerando a chave pública e privada usando ssh-keygen

Abra um novo terminal na sua máquina local e digite os seguintes comandos:

# Gerar chaves ssh
ssh-keygen -t rsa -C seuEmail@exemplo.com

Será aberto um passo a passo que solicitará duas coisas:

  • Onde salvar: recomendo que mantenha na pasta “~/.ssh/nomedachave” para fins de organização. Caso tenha dúvidas, mantenha o padrão.
  • Senha: nessa etapa, é de extrema importância que você escolha uma senha forte. Lembre-se essa chave é como um “documento oficial”, caso alguém tenha acesso a esse arquivo, poderá acessar o servidor como se fosse você.

Chave gerada, vamos para voltar para o terminal do servidor para permitir o acesso através dela. Não feche esse ainda, vamos precisar dele mais adiante.

Como adicionar chaves SSH ao servidor?

Para continuar, vamos voltar ao terminal logado no servidor via SSH para configurar o acesso via chave pública.

# 1. Crie a pasta .ssh
mkdir -p ~/.ssh

# 2. Crie o arquivo com as chaves autorizadas a acessar essa conta
touch ~/.ssh/authorized_keys

Após realizar esses passos, só precisamos adicionar a sua chave pública ao arquivo authorized_keys. Mas antes, vamos precisar do conteúdo da sua chave pública.

Voltando para o terminal que geramos o par de chaves, vamos ler o conteúdo da sua chave pública.

# Se você deixou com a localização padrão, o nome será id_rsa.pub
cat ~/.ssh/nome_da_sua_chave.pub

Apareceu uma sequência de maluca de letras e números? Perfeito! Copie isso tudo para sua área de transferência e vamos alternar para o terminal do servidor.

# Substitua o conteúdo entre aspas simples pela chave pública copiada no passo anterior
echo 'conteudo_da_sua_chave_aqui' >> ~/.ssh/authorized_keys

Pronto! Agora só precisamos testar se está tudo funcionando corretamente. Volte para o terminal da sua máquina e tentar realizar uma conexão usando esse novo método.

# Substitua pelo seu endereço de IP
ssh root@123.123.123.123 -i ~/.ssh/nome_da_sua_chave

Digite sua senha e boom! Você estará logado no servidor usando a chave SSH. Incrível, não?

Medidas de segurança ao configurar um servidor público de SSH

Por padrão, os servidores SSH utilizam a porta 22 e qualquer um pode se tentar se conectar a sua VPS recém-configurada. Isso é uma característica desejada, imagine que você precisa dar uma manutenção enquanto está viajando? Ou acessar rapidamente pelo celular para reiniciar o servidor?

O problema começa quando você considera que existem inúmeros robôs automatizados que constantemente verificam a internet em busca de servidores com a porta 22 aberta o tempo todo. Quando esses “bots” encontram tal porta, imediatamente lançam um ataque de força bruta, tentando dezenas de milhares de senhas de uma vez só.

Essa ação faz com que preciosos ciclos de processamento sejam gastos e, em alguns casos, podem até derrubar o seu servidor. Mas como podemos nos proteger de tais ataques? Existem diversas medidas de segurança, mas vamos nos focar em três:

  1. Alterar a porta padrão
  2. Limitar o número de tentativas de login
  3. Permitir apenas o acesso via chaves SSH

Alterando a porta padrão do SSH

Considerando um robô que esteja verificando portas vulneráveis, seria muito custoso escanear todas as portas em todos os endereços da internet. Por isso, esses ataques focam em portas padrão em serviços conhecidos como FTP, SSH, TELNET e assim por diante. Alterando a porta de entrada, poderemos mitigar essas ações maliciosas de forma significativa.

O primeiro passo é acessar o servidor e procurar pelo arquivo de configuração do SSH.

# Nano é um editor de texto via terminal
sudo nano /etc/ssh/sshd_config
  1. Procure pela linha que contenha “# Port 22”
  2. Remova o # do início da linha e coloque o número da porta (recomendo um número entre 10000 e 65535)
  3. Anote esse número, pois será muito importante para acessarmos o servidor
  4. Tecle <CTRL>+<O> para salvar o aquivo no nano
  5. Tecle <CTRL>+<X> para sair do arquivo

A partir daqui, precisaremos informar ao deamon ssh que a porta foi alterada. A forma de realizar esse procedimento é reiniciando esse serviço. Note que ele é responsável pela conexão com o servidor em que você está, portanto, a sessão atual será finalizada.

# Reiniciando o ssh
sudo service sshd restart

Para iniciar uma conexão, será preciso especificar a nova porta que acabamos de configurar. Mas lembrar da porta e especificar a chave privada toda vez é bem chato, não? Vamos configurar “atalho” para facilitar nossa vida!

Acessando o servidor com apenas um comando

O primeiro passo é acessar um terminal na sua máquina local e abrir o seguinte arquivo em um editor de texto: 

# Abrindo o arquivo de configuração usando nano
nano ~/.ssh/config

# Copie o texto abaixo e substitua as informações
# -------------------------------------------------
Host nomeDoAtalho
    HostName 123.456.789.012      # Endereço de IP do VPS
    User root                     # Seu usuário
    Port 1234                     # Porta do passo anterior
    IdentityFile ~/.ssh/suaChave  # Caminho para a chave privada
    IdentitiesOnly yes            # Acesso via chave

# Salve e feche o arquivo

Sensacional! Você acabou de configurar um atalho para acesso à sua VPS. Com isso, toda vez que precisar iniciar uma sessão, basta digitar o comando abaixo. Rápido e fácil.

ssh nomeDoAtalho
# Obs.: Caso apareça uma mensagem de erro informando
#       que a identificação do servidor foi alterada,
#       basta remover a identificação anterior
#       utilizando o comando:
ssh-keygen -f "~/.ssh/known_hosts" -R "[ip_do_servidor]:porta"

Limitar o número de tentativas e proibindo o login via senhas

O procedimento aqui é bem similar, vamos acessar o aquivo /etc/ssh/sshd_conf e realizar as alterações que precisamos:

# 1. Abra o com o nano
nano /etc/ssh/sshd_conf

# 2. Procure pela linha e remova o # do início
#---------------------------------------------
#MaxAuthTries 6


# 3. Busque a linha abaixo
#--------------------------
#PasswordAuthentication yes


# 4. Substitua por:
#-------------------
PasswordAuthentication no

Alterações finalizadas. Salve o arquivo e reinicie o servidor.

# Reiniciando o ssh
sudo service sshd restart

3. Bloqueando acessos não autorizados como firewall (UFW)

O que é o UFW?

O nome UFW é uma sigla para (Uncomplicated FireWall | Firewall Descomplicado). Em suma, consiste em uma interface mais amigável para outra barreira de segurança muito presente no mundo Linux: o iptables. Ele permite configurar regras específicas para conexões de entrada e saída, sejam estas via tcp ou udp.

Partindo para um exemplo prático, digamos que eu tenha configurado um serviço de banco de dados no meu servidor e a aplicação que precisa acessar esse banco também está na mesma VPS. Teria sentido deixar esse serviço disponível para qualquer um, na internet? Definitivamente NÃO!

Nesse cenário, o ideal seria restringir somente ao localhost. Mesmo que a aplicação estivesse em outro servidor, o correto seria permitir conexões ao banco somente quando vindas do IP dessa aplicação, não de qualquer local. O UFW nos ajuda justamente na definição desse tipo de regras.

Quais regras serão configuradas

Para garantir que não “esqueçamos” nenhuma porta aberta, vamos configurar as regras dessa forma:

  1. Bloquear todas as conexões de entrada
  2. Permitir todas as conexões de saída
  3. Permitir a entrada e saída para conexões SSH
  4. Permitir as portas para HTTP e HTTPS

Definindo regras no UFW

# 1. Bloqueando todas as conexões de entrada
sudo ufw default deny incoming

# 2. Permitindo todas as conexões de saída
sudo ufw default allow outgoing

# 3. Permitindo conexões SSH 
#    > Caso tenha alterado a porta padrão, substitua o 22
#    > Se a porta estiver incorreta, não conseguirá acessar
#    > o servidor via SSH
sudo ufw allow 22/tcp
sudo ufw allow 22/udp

# 4. Permitindo conexões HTTP e HTTPS (servidor Web)

# HTTP
sudo ufw allow 80/tcp
sudo ufw allow 80/udp

# HTTPS
sudo ufw allow 443/tcp
sudo ufw allow 443/udp

# 5. Ativando os logs dos bloqueios (serão salvos em /var/log/ufw.log)
sudo ufw logging on 

# 6. Verificando o status
sudo ufw status

# 6. Ativando
sudo ufw enable

# 7. Reiniciando
sudo ufw reload

Principais comandos para gerenciamento UFW

ufw resetRemove todas as regras e desabilita o firewall
ufw status numberedMostra o status e as regras ativas de forma numerada
ufw delete <numero>Remove determinada regra
ufw allow from <IP/Subnet>Permite conexões de determinado IP para qualquer porta
ufw allow from <IP> to any port <porta>Permite conexões de determinado IP para uma porta
ufw insert 1 from <IP>Bloqueia determinado IP
ufw delete deny from <IP>Desbloqueia determinado IP

4. Usando fail2ban para proteção de ataques força bruta

Além das medidas que já tomamos em relação à limitação de logins via SSH, podemos adicionar uma ferramenta que gerencia tentativas de login e permite um controle muito mais preciso.

Além disso, o fail2ban também utiliza o iptables por baixo dos panos. Isso significa que é possível colocá-lo para trabalhar em conjunto com o ufw.

Instalando e habilitando o fail2ban

# Instalação usando apt (debian/ubuntu/derivados)
sudo apt install fail2ban

# Habilitando o serviço para inicializar junto do sistema
sudo systemctl enable fail2ban

Em primeira instância, vamos (1) ignorar as definições de bloqueio para o loopback (localhost) e logo em seguida, (2) uma regra personalizada para o SSH.

# 1. Ignora as regras de bloquio para IPs locais
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# 2. Abra com seu editor de texto favorito
sudo nano /etc/fail2ban/jail.local

# 3. Procure pela linha e remova o comentário (#)
--------------------------------------------------

# ignoreip = 127.0.0.1/8 ::1

# 4. Salve o arquivo e saia

Definindo regras personalizadas no fail2ban

O próximo passo é configurar serão os serviços monitorados por ele e as quais parâmetros vão ser utilizados.

O fail2ban analisa os logs e a partir deles, cria as regras de bloqueio de acordo com o que for definido. Essas definições ficam em arquivos chamados “jails”, localizados em /etc/fail2ban/jail.d/

# 1. Cria um arquivo para regras do SSH
sudo nano /etc/fail2ban/jail.d/sshd.local

# 2. Adicione o seguinte conteúdo ao arquivo

[sshd]
enabled = true
port = <numeroPorta>         # Porta
action = iptables-multiport
logpath = /var/log/secure    # Logs analisados
maxretry = 6                 # Max. tentativas
bantime = 1200               # Tempo em seg

Como “desbanir” um IP usando fail2ban

No momento que um endereço é banido, todas as requisições do IP em questão no serviço especificado são recusadas e só serão aceitas novamente após o tempo definido no parâmetro “bantime”. Caso seja necessário permitir esse acesso novamente, utilize o comando abaixo:

# Substitua "servico" pelo correspondente. Ex: sshd
sudo fail2ban-client set <servico> unbanip <IP>

5. Detectando e auditando ações maliciosas com auditd

Nosso principal objetivo como sysadmins é que o servidor seja o mais seguro possível, nunca seja invadido, mas imagine por um momento que algo ruim aconteceu, ou, ainda pior: um comportamento estanho foi detectado.

Essa é a parte mais desafiadora do nosso trabalho, quando aparece uma variação abrupta no uso de memória, CPU e por aí vai. E então? Como saber, de verdade se foi uma invasão, ataque ou só uma falha no código? Uma palavra: observabilidade.

É aí que entra o audid. Ele é uma ferramenta que permite monitorar todos os comportamentos da sua VPS. Dessa forma, você pode verificar nos logs exatamente quais arquivos foram modificados, executados, quem executou e até mesmo os parâmetros utilizados.

Instalando o audid no Debian/Ubuntu e derivados

# Instalação via APT
sudo apt install auditd audispd-plugins

# Habilitando o auditd na inicialização
sudo service auditd start

Em conjunto com o auditd, também serão instaladas outras que ferramentas que nos ajudam a gerenciar e visualizar os logs gerados por ele. São elas:

  1. auditctl: controla o status e as configurações do auditd
  2. aureport: gera relatórios a partir dos logs
  3. ausearch: usada para pesquisar eventos ou logs específicos
  4. aulast: mostra as atividades mais recentes armazenadas
  5. aulastlog: exibe as últimas informações de login
  6. ausyscall: informações sobre system calls

Se isso parece “grego” para você, não se preocupe. Não é trivial para ninguém, exige conhecimentos prévios sobre sistema operacional e uma boa lida na documentação.

Mas mesmo sem entender muito, INSTALE. Você nunca sabe quando vai precisar dessas informações. Nada como uma boa dose de desespero para despertar seu interesse a estimular o aprendizado.

Caso queira se aprofundar, recomendo esses links:

  1. https://www.redhat.com/sysadmin/configure-linux-auditing-auditd
  2. https://docs.oracle.com/en/learn/ol-auditd/#install-the-audit-package
  3. https://people.redhat.com/sgrubb/audit/

Como funcionam os arquivos de configuração do auditd

Quando falamos sobre monitoramento, guardar tudo que acontece na máquina seria extremamente custoso em processamento e espaço em disco. Entretanto, há também o risco de deixar de monitorar alguma ação maliciosa.

Para resolver esse impasse, o auditd utiliza um método de definição de regras, definidas em arquivos na pasta /etc/audit/rules.d. Existem milhares de regras a serem implementadas, mas é fora do escopo desse artigo a explicação e fundamento de cada uma.

Configurando as principais regras de segurança no auditd

De modo a facilitar nossa vida, vamos utilizar um conjunto de regras disponível no github e amplamente adotada para essa ferramenta. Segundo o README do projeto, é baseado nas definições do governo do Reino Unido e monitora os principais eventos que podem indicar comprometimento de segurança.

# Acesse a pasta auditd
cd /etc/audit/rules.d

# Remova o arquivo padrão
rm audit.rules

# Baixe o arquivo de configuração
 wget https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules

# Habilite o audid na inicialização
sudo systemctl enable auditd

# Renicie o serviço
sudo systemctl restart auditd.service 

# Verifique se as regas foram adicionadas
sudo auditctl -l

Mantendo logs do auditd por 90 dias

A rotação de logs é um processo que separa automaticamente os logs de acordo com critérios definidos pelo usuário. Por exemplo, diariamente, às 00h00, um novo arquivo de log é criado e o do dia anterior é guardado em um arquivo compactado para otimização de espaço.

Esse processo, no Linux é gerenciado pelo lograte. As configurações são definidas por aplicação, isso significa que é possível definir uma política diferente para o nginx e outra completamente diferente para o apache, ou qualquer outro programa.

Os arquivos de configuração ficam armazenados na pasta /etc/logrotate/logrotate.d. No nosso caso, vamos configurar o auditd para:

  1. Armazenar os arquivos de log por 90 dias
  2. Limitar o tamanho máximo de 10M por arquivo
  3. Compactar os logs dos dias anteriores

Para realizar essas definições, abra um terminal e digite:

# 1. Criar um arquivo no logrotate para o auditd
nano /etc/logrotate.d/audit

# 2. Adicionar o seguinte conteúdo ao arquivo
# ---------

/var/log/audit/*.log {
        daily
        compress
        dateext
        copytruncate
        rotate 90
        maxsize 100M
}

# 3. Salvar e sair

6. Os próximos passos

Gerenciar um servidor não é tarefa fácil, sempre aparecem novas vulnerabilidades, ataques e por aí vai. O importante é que você, como sysadmin fique sempre atento, atualize os pacotes com frequência.

No próximo artigo da série, será abordado o passo a passo de como instalar o Nginx, MySQL e phpMyAdmin, não se esqueça de conferir.

Além disso, se você deseja se aprofundar um pouco mais, confira a lista de canais e sites abaixo. Caso tenha gostado do conteúdo, compartilhe esse artigo e se inscreva na nossa newsletter, sempre mando coisas bacanas por lá.

Canais no Youtube

  • Hussein Nasser: vídeos explorando o backend das principais aplicações e quais as stacks por trás.
  • IppSec: explicações aprofundadas sobre hacking e segurança da informação.
  • STÖK: atualizações semanais sobre ferramentas e hacking e bugbounty no geral.

Blogs

  • Server Fault: sim, do StackOverflow. Caso tenha alguma dúvida, não hesite em participar da comunidade (lembrando de pesquisar um pouco antes).
  • Sucuri Blog: dos mesmos criadores do WAF Sucuri, atualizações sobre as últimas ameaças e ataques no cenário WordPress.
  • 4sysops: um blog voltado para sysadmins e devops.

Podcasts

  • Security Weekly: um podcast notícias semanais sobre o mundo da Segurança da informação.