Tag: wordpress

Observando, analisando e cuidando do servidor.

Observabilidade é a palavra chave quando pensamos em manter um servidor wordpress sempre saudável e estável. É observando e analisando logs e dados em realtime que podemos entender e descobrir o que pode ser mudado, ou até mesmo o que está causando lentidões e gargalos.

O que podemos monitorar e analisar ?

Existe uma centena de ferramentas pagas e opensource no mercado com foco em monitoramento de infraestrutura e serviços e não vou julgar qual é a melhor, pois cada uma pode atender um projeto em um determinado momento da empresa.

Para monitoramento do Nginx, PHP, MySQL e Hardware, podemos utilizar ferramentas como:

• Nginx Amplify
• Zabbix
• Prometheus e Grafana
• Site24x7
• NewRelic
• Dynatrace
• Datadog
• Etc

Nesse capítulo vamos utilizar o Nginx Amplify para o LEMP , mas seria interessante você também utilizar o Site24x7 por exemplo, para monitoramento de Rede,Disco,RAM,CPU e Validade do SSL.

Se você possui um e-commerce, ou qualquer projeto que realmente precise de cuidados 24×7, recomendo pesquisar mais sobre NewRelic, Prometheus com Grafana e Datadog. Por possuírem mais recursos e opções para nossa observabilidade de infraestrutura.

Monitoramento com Nginx Amplify

O Nginx Amplify é uma ferramenta totalmente gratuita e bem intuitiva na verdade. Para começarmos a configura-lo precisamos realizar o cadastro no site oficial pois é por lá que vamos acompanhar nossos dashboards.

Primeiro passo: Cadastro

Acessem o site oficial e realizem o cadastro através do link: https://amplify.nginx.com/login

Segundo passo: Instalação do Agente

Assim que você realiza o cadastro, você vai cair em uma tela onde será solicitado que você instale o agente do Nginx Amplify no servidor. É através desse agente que o Enginx Amplify consegue coletar dados e estatísticas dos nossos serviços.

Você vai acessar o servidor via SSH e executar as etapas 2, 3 e após concluir a etapa 3, clicar em Continue no navegador.

Em seguida o Ngin Amplify vai aguardar pelos dados recebidos do agente, sugiro aguardar os minutos que é apresentado na tela.

Após alguns minutos, você vai ser redirecionado para uma segunda página, e é apresentado o passo a passo do que fazer para configurar o Nginx para enviar os dados para o Amplify. E é isso que faremos agora!

Integrando o Amplify no Nginx

Siga os passos indicados na imagem, exatamente na mesma ordem e clica em continuar após executar as etapas. Nesse momento o Nginx Amplify irá aguardar os dados enviados pelo agente a respeito do serviço Nginx no servidor.

Após alguns minutos, conforme o seu site vá recebendo requisições, você notará que os dados começarão aparecer na tela. O básico do que aparecerá são:

• Requests no nginx
• Conexões correntes
• Erros 400
• Erros 500
• Memória consumida pelo Nginx
• CPU consumido pelo Nginx

E se clicar no menu em Overview verá também um resumo bem legal sobre as estatísticas de uptime, requests, erros 5xx,

Integrando o Amplify no PHP-FPM

Agora vamos configurar o Nginx Amplify para coletar dados e estatísticas de consumo do PHP-FPM. No painel não temos o passo a passo facilitado, mas felizmente vou comentar todos os passos aqui para você.

Acesse o servidor via SSH, e abra o arquivo do pool fpm default, com o comando abaixo:

nano /etc/php/8.0/fpm/pool.d/www.conf

Procure a linha pm.status_path e descomente-a.

Salve o arquivo e reinicie o PHP.

/etc/init.d/php8.0-fpm restart

No Nginx Amplify, clique em Graph e em seguida php-fpm, depois de um tempo começará ver os dados chegando, como: conexões queue, conexões, processos, requests lentas, etc.

Integrando o Amplify no MySQL

O agente do Nginx Amplify também consegue coletar métricas e processos de bancos de dados MySQL, mas para isso precisamos realizar alguns passos para que possamos deixar isso funcionando.

1. Acesse o MySQL pelo terminal de comando com o usuário root

mysql -uroot -p

2. Crie um usuário para o agente

# defina uma senha em xxxxxx
CREATE USER 'amplify-agent'@'localhost' IDENTIFIED BY 'xxxxxx';
exit;

3. Logue agora com o usuário amplify-agent e veja se está tudo ok

mysql -u amplify-agent -p

show global status;

exit;

4. Agora precisamos adicionar um conteúdo ao arquivo de configuração para que o agente consiga se conectar ao banco e coletar as métricas. Abra o arquivo de configurações do agente com o comando abaixo:

nano /etc/amplify-agent/agent.conf

Agora adicione o conteúdo na última linha, e lembre de colocar a senha do usuário do agente que criamos nos passos anteriores em password.

[extensions]
..
mysql = True

[mysql]
#host =
#port =
unix_socket = /run/mysqld/mysqld.sock
user = amplify-agent
password = xxxxxx

5. Por fim, restarte o serviço do Nginx Amplify

service amplify-agent restart

Agora o Nginx Amplify começará a enviar dados e estatísticas do banco de dados para o painel, uma nova aba irá abrir no dashboard ao lado de PHP-FPM.

Dependendo do tipo de banco de dados, pode ser que os dados não serão enviados, recomendo a leitura do blog post abaixo:

Conclusão

É importante entendermos o que está acontecendo dentro do nosso servidor, principalmente visualizar as métricas a respeito dos serviços que estão sendo executados. Nesse capítulo utilizamos uma ferramenta gratuita, possui suas limitações, mas que pode ser de grande serventia.

No entanto, para uma observabilidade mais refinada e profissional, softwares como Dynatrace, Prometheus com Grafana, Site24x7 e outros, podem ser uma ótima solução para seus negócios.

Se você está acompanhando desde o primeiro capítulo o nosso projeto de implantação de um servidor ubuntu para hospedagem wordpress, já viu que temos o nosso ambiente pronto.

Nesse capítulo vamos implementar algumas mudanças no nginx com foco em segurança, no entanto, isso não quer dizer que você está livre de toda e qualquer ameaça de ataques, mas as configurações aqui apresentadas podem minimizar os impactos.

SSL

Proteção no SSL

Nosso site wordpress nesse momento já possui o certificado SSL instalado, isso foi feito no segundo capítulo. No entanto, alguns usuários podem ainda tentar se conectar no nosso site pelo protocolo HTTP, quando nós adicionamos a diretiva Strict-Transport-Security aos cabeçalhos de resposta do servidor, garantirá que todas as futuras conexões sejam feitas sempre com o protocolo HTTPS.

Para realizar o procedimento, edite o nginx.conf com o comando abaixo:

sudo nano /etc/nginx/nginx.conf

E adicione o conteúdo abaixo dentro do bloco http assim como a imagem abaixo

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

Salve o arquivo e de um reload nas configurações do Nginx com o comando:

service nginx reload

Agora acesse o site do Qualys SSL Test e realize um teste de qualidade do nosso SSL.

Performance do SSL

Normalmente uma conexão HTTPS consome e demanda bastante recurso do servidor em comparação a uma conexão simples HTTP. Isso ocorre por conta do procedimento de handshake adicional necessário ao estabelecer uma conexão.

Mas podemos adicionar em cache os parâmetros da sessão SSL, o que evitará um handshake para cada conexão HTTPS do usuário. Logo, podemos melhorar levemente um pouco mais a performance do servidor.

Abra o arquivo de configuração do nginx novamente

sudo nano /etc/nginx/nginx.conf

Na diretiva abaixo de SSL Settings, adicione o conteúdo abaixo:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Agora faça um reload do Nginx para que as configurações entrem em vigor:

sudo service nginx reload

Tipos de Ataques e Segurança com Nginx

Cross-Site Scripting (XSS)

Uma das formas que você desenvolvedor pode lidar com o XSS é garantir a validação e limpeza correta de todas as entradas do usuário no seu código, principalmente as áreas de administração do WordPress. Mas sabemos que tudo vira um caos quando existem vários plugins e templates de terceiros, é complicado você manter isso seguro.

Uma das formas que temos para poder diminuir os riscos de ataques XSS é configurando o Nginx para fornecer cabeçalhos de resposta adicionais. Mas como assim?

Imagine que um atacante conseguiu incorporar um arquivo JS malicioso no código-fonte do seu blog/site, seja por meio de um form de comentários ou algo do gênero. Por padrão, o navegador acaba permitindo que esse arquivo externo seja executado no momento do acesso, e poderá infectar o visitante ou até mesmo minerar criptomoedas torrando a CPU do seu usuário.

Quando inserimos uma política de segurança de conteúdo, o que permite definirmos uma lista de permissões de fontes totalmente aprovadas por nós para carregar ativos (JS,CSS,HTML,etc), a coisa muda de cenário. Se o script não estiver na lista de aprovados, ele não poderá ser carregado no browser do seu usuário. Legal, não?

Criar uma política de segurança é bem complicado para falar a verdade, hora ou outra acabamos bloqueando algum recurso de um template ou plugin e desconfigurando nosso site, então fica em um cenário de tentativa e erro.

Clickjacking

Clickjacking é um tipo de ataque que engana o seu usuário para que ele realize uma ação sem que ele perceba (induz o usuário a clicar), e é realizado através de iframes em uma página.
Não sou especialista em segurança, mas você pode ler um artigo que explica como funciona detalhadamente esse tipo de ataque do Clickjacking.

No Nginx podemos mitigar um pouco esse tipo de ataque, desabilitando completamente a incorporação de iframes de terceiros adicionando o cabeçalho X-Xss-Protection no nginx.conf.

Fortalecendo a segurança do WordPress com Nginx

Abra o seu nginx.conf e adicione os cabeçalhos para que os tipos de ataques acima sejam mitigados. Também inclui alguns outros cabeçalhos, que vão nos ajudar a evitar uma série de outros ataques web.

add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval';" always;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "origin-when-cross-origin" always;
add_header Permissions-Policy interest-cohort=();

A medida que atualizarmos esse capítulo com novos tipos de ataques iremos atualizar também as configurações do Nginx.

Conclusão

Antes de configurarmos as diretivas de segurança no Nginx com foco no nosso site WordPress, o resultado de um teste e análise dos cabeçalhos resultava a seguinte nota de segurança:

Após configurarmos os cabeçalhos, os resultados obtidos são maravilhosos:

Desse modo constatamos que configuramos os cabeçalhos e que ao menos alguns ataques vão ser bem difíceis de serem feitos no nosso servidor wordpress. Se você quer analisar o seu site, acesse o site: https://securityheaders.com/

A importância dos Backups

Ao longo do tempo vivenciei diversos projetos e vi na prática a importância que um backup tem para solucionar um problema. Já vi de perto vários projetos terem de recomeçar do zero pelo falta de backups.

Problemas técnicos acontecem, hora ou outra uma invasão ou infestação de malwares podem ocorrer, principalmente em projetos WordPress que são muito visados por atacantes e nessas horas se você não tem um backup limpo, irá chorar.

Nesse capítulo vamos configurar rotinas de backups no nosso servidor WordPress para termos cópias de segurança do nosso site.

Configurando Backup WordPress

A nossa configuração de backups será executada 1x por dia durante 7 dias, e após os 7 dias o último backup mais antigo será removido, desse modo você sempre terá salvo no seu servidor wordpress os últimos 7 dias de backups.

Se seu WordPress é muito pesado e o armazenamento do servidor ficar lotado, diminua a retenção dos backups de modo que o seu servidor consiga armazenar os backups sem travamentos.

Exemplo: Seu servidor possui 100GB de armazenamento e você possui um WordPress com 12GB de arquivos. Se você configurar o backup com retenção de 7 dias, será consumido 7 dias * 12GB de backups + 12GB do site principal, que dará um total de 96GB consumidos. Então analise bem!

No nosso servidor, vamos criar um diretório personalizado para que os backups sejam armazenados dentro dele.

mkdir -p /var/www/backups

Agora vamos criar um script shell básico para que o backup seja executado de modo que os arquivos do nosso WordPress e o banco de dados sejam salvos.

nano /var/www/backup.sh

Insira todo o conteúdo abaixo dentro do script e salve-o.

#!/bin/bash

DIA=$(date +%Y%m%d%H%M%S)
DB_BACKUP=${DIA}_database.sql
ARQUI_BACKUP=${DIA}_wp.tar.gz

DB_NAME=$(sed -n "s/define( *'DB_NAME', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_USER=$(sed -n "s/define( *'DB_USER', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_PASSWORD=$(sed -n "s/define( *'DB_PASSWORD', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_HOST=$(sed -n "s/define( *'DB_HOST', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)

# Backup do banco de dados
mysqldump --add-drop-table -u$DB_USERNAME -p$DB_PASSWORD -h$DB_HOST $DB_NAME > /var/www/backups/$DB_BACKUP 2>&1

# Comprimindo backup da DB
gzip /var/www/backups/$DB_BACKUP

# Backup do diretorio do WordPress
tar -zcf /var/www/backups/$ARQUI_BACKUP /var/www/html

Para que você não fique “boiando” sobre como esse script trabalha, ele tem as seguintes particularidades:

• É executado como um script bash
• Configura uma variável DIA com a data atual para os backups
• Recupera automaticamente as credenciais do banco de dados, para que automação consiga se conectar no banco
• Utiliza o gzip para comprimir o backup da database e com isso ocupar menos espaço

Agora dê permissão de execução

chmod u+x /var/www/backup.sh

Agora vamos colocar esse script no crontab para que ele seja executado todos os dias de madrugada, para que ele seja executado exatamente no horário que queremos temos que ajustar o horário do nosso servidor.

No entanto, configuramos o horário do servidor no primeiro capítulo desde guia. Mas verifique se a hora está correta:

date

Se tudo estiver correto, abra o crontab com o comando abaixo

crontab -e

Agora adicione o conteúdo abaixo

0 5 * * * cd /var/www/; /var/www/backup.sh  >/dev/null 2>&1

Esse cronjob irá acessar o diretório onde o script está armazenado e será executado as 05h da manhã todos os dias da semana.

Sempre que desejar verificar os backups salvos, basta executar o comando abaixo

ls -l /var/www/backups

Configurando Limpeza Automática

Até aqui já configuramos nosso script e colocamos ele na crontab para que seja executado todos os dias. Mas ainda não configuramos uma maneira de limpar os backups antigos, caso contrário em pouco tempo nosso servidor irá travar por falta de espaço.

Para isso vamos adicionar uma linha no nosso script bash, logo no final do arquivo

nano /var/www/backups.sh

Em seguida insira o conteúdo na última linha, feche e salve o arquivo

rm -f /var/www/backups/$(date +%Y%m%d* --date='1 week ago')

Agora nosso script sempre deixará salvo os últimos 7 dias de backups salvos no nosso servidor WordPress.

Conclusão

Backup de hospedagem WordPress é fundamental para a segurança e retenção dos dados, em um desastre você terá uma cópia dos arquivos e poderá utilizar sempre que precisar.