Módulo 10 · 10.2
O que não deve fazer
Módulo 10: Manter a segurança · Tempo de leitura: 12 minutos
Objetivo de aprendizagem: No final desta lição, reconhece os erros que mais vezes levam a um servidor atacado ou avariado, consegue explicar porque são perigosos e sabe o que deve fazer em vez disso.
Conceitos-chave: início de sessão de root com palavra-passe, palavra-passe fraca ou predefinida, base de dados aberta, API do Docker na porta 2375, docker.sock num contentor, chmod 777, curl | bash, segredos no Git, painel de administração sem autenticação de dois fatores, firewall desligada "só um momento", sem atualizações, sem cópia de segurança
Porquê uma lição sobre erros?
A maioria dos servidores não é atacada por um atacante genial com uma vulnerabilidade desconhecida. São atacados por bots que percorrem toda a internet à procura de erros conhecidos: uma palavra-passe fácil de adivinhar, uma base de dados aberta, um programa sem atualizações há meses. Quem evitar os erros desta lição deixa de ser alvo desses bots. É a maior parte da proteção que pode obter.
Para cada erro, indica-se porque é perigoso e o que deve fazer em vez disso. Quase tudo foi aprendido em lições anteriores; esta lição reúne tudo numa lista.
1. Início de sessão de root com palavra-passe
O problema. Qualquer servidor recebe tentativas de início de sessão em root durante todo o dia (lição 5.3). Se o root puder iniciar sessão com uma palavra-passe, essa palavra-passe é a única coisa entre um bot e o controlo total. Palavras-passe reutilizadas ou demasiado curtas acabam, mais cedo ou mais tarde, por ser adivinhadas ou já constam de uma lista divulgada.
Faça isto. Início de sessão apenas com chaves: PasswordAuthentication no e KbdInteractiveAuthentication no, root no máximo com uma chave (PermitRootLogin prohibit-password) ou de todo não (no), e trabalho diário como utilizador comum com sudo (lição 2.2 e 3.2). Verifique a partir do exterior que métodos de início de sessão o seu servidor oferece (exercício Z2.2).
2. Uma base de dados, cache ou cluster de pesquisa aberto à internet
O problema. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch ou OpenSearch (9200) e MongoDB (27017) foram feitos para programas de confiança numa rede de confiança. Se estiverem em 0.0.0.0 sem firewall, os scanners encontram-nos depressa. O próprio Redis diz na sua documentação que não deve ser exposto à internet e que quem tiver acesso pode apagar todo o conjunto de dados; através do comando CONFIG, um atacante pode até escrever ficheiros no servidor. Bases de dados e clusters de pesquisa abertos são, há anos, uma causa conhecida de grandes fugas de dados e de mensagens a pedir "resgate" no lugar dos seus dados.
Faça isto. Ponha estes serviços a escutar em 127.0.0.1 (lição 5.1), mantenha-os atrás da firewall (lição 5.2) e, no Docker, não os publique ou publique-os apenas em 127.0.0.1 (lição 9.3). Para aceder a partir do seu portátil: um túnel SSH (lição 2.3). Verifique a partir do exterior (exercício Z5.1).
3. A API do Docker aberta ou docker.sock num contentor
O problema. Quem consegue controlar o daemon do Docker é, na prática, root no servidor: a documentação do Docker diz que só utilizadores de confiança devem poder controlar o daemon e considera o acesso ao daemon equivalente ao acesso de root. Há duas variantes deste erro:
- O daemon escuta numa porta TCP sem TLS (o habitual é 2375). Qualquer pessoa que chegue a essa porta pode iniciar contentores com o disco do seu servidor lá dentro.
- Um contentor recebe
/var/run/docker.sockcomo volume ("assim pode gerir contentores sozinho"). Se esse contentor for comprometido, todo o servidor fica perdido.
O grupo docker também equivale a root (lição 9.2): coloque nele apenas administradores.
Faça isto. Deixe o Docker funcionar apenas através do socket local. A gestão remota faz-se por SSH (docker context com ssh://) ou, se tiver mesmo de ser por TCP, com TLS na porta 2376 e certificados de cliente. Monte docker.sock apenas num contentor em que confie totalmente e de que precise realmente, de preferência só de leitura através de um proxy restritivo.
4. chmod 777 para fazer desaparecer uma mensagem de erro
O problema. "Permission denied" (permissão negada) num carregamento, e um fórum diz: chmod -R 777 /var/www. A partir daí, qualquer utilizador e qualquer processo no servidor pode escrever o que quiser no seu site, incluindo um plugin comprometido ou outra conta. Código que o servidor web pode escrever pode, através de uma vulnerabilidade, ser substituído por uma backdoor.
Faça isto. Descubra quem precisa de escrever e onde (lição 3.1): normalmente apenas o utilizador do servidor web, numa única pasta para carregamentos ou cache. Código pertencente a outro proprietário que não o servidor web, permissões 644/755, carregamentos 750/640 ou semelhante.
5. curl ... | bash e software de qualquer lado
O problema. Um script que executa como root sem o ler pode fazer tudo: adicionar fontes e chaves, substituir ficheiros, abrir um serviço. Mesmo com boa intenção, depois não sabe o que foi alterado, e na próxima atualização de versão algo falha (lição 4.3).
Faça isto. Descarregue e leia o script. Instale de preferência a partir do repositório de pacotes da sua distribuição ou da fonte oficial do criador, com uma chave própria (Signed-By, lição 4.1). Anote o que instala e porquê.
6. Sem atualizações, ou atualizações "mais tarde"
O problema. As vulnerabilidades são corrigidas e depois exploradas, muitas vezes em poucos dias. Um servidor que passa meses sem atualizações, ou que corre numa versão sem suporte, tem uma lista de portas de entrada conhecidas. Os contentores não são atualizados pelo apt.
Faça isto. Atualizações de segurança automáticas ativadas (lição 4.2), um momento fixo para reiniciar, a data de fim de suporte da sua versão na agenda (lição 4.3) e atualização regular dos contentores (lição 9.4).
7. Sem cópia de segurança, ou uma cópia nunca testada
O problema. Um snapshot no mesmo armazenamento não é uma cópia de segurança (lição 8.1). Uma cópia de segurança guardada no próprio servidor desaparece com ele num ataque ou com ransomware. E uma cópia de segurança que nunca foi reposta é uma esperança, não uma certeza.
Faça isto. Cópias de segurança cifradas fora do servidor (restic, lição 8.2), monitorização de que estão a ser feitas e, pelo menos uma vez por trimestre, um teste de reposição.
8. Painéis de administração abertos a todos, sem autenticação de dois fatores
O problema. Um painel de administração de uma base de dados (como o phpMyAdmin), do Docker (como o Portainer), da sua aplicação ou do seu cofre de palavras-passe é um alvo apetecível: uma única palavra-passe dá acesso a tudo. Palavras-passe predefinidas como admin/admin e registos que ficam abertos (Vaultwarden, lição 9.4) facilitam ainda mais.
Faça isto. Não abra painéis de administração à internet: aceda-lhes através de um túnel SSH ou apenas a partir de um endereço fixo. Se um painel tiver mesmo de ser público: https, uma palavra-passe forte e única do seu gestor de palavras-passe, autenticação de dois fatores e registo fechado. Altere sempre as palavras-passe predefinidas.
9. Segredos no Git ou no seu ficheiro compose
O problema. Uma palavra-passe, chave de API ou chave privada num ficheiro que acaba num repositório Git fica para sempre no histórico, mesmo que a remova mais tarde. Os repositórios públicos são vasculhados por bots à procura precisamente deste tipo de chaves.
Faça isto. Segredos num ficheiro separado com permissões 600 (EnvironmentFile, lição 6.3; .env no Docker Compose, lição 9.3), que consta do .gitignore. Se, ainda assim, um segredo tiver sido divulgado: substitua-o de imediato (uma nova palavra-passe, uma nova chave); limpar apenas o Git não chega.
10. Desligar a firewall "só um momento", tudo como root e sem notas
O problema. "Vou desligar a firewall só um momento para testar" acaba esquecido. "Faço isto rapidamente como root" torna-se um hábito. E um servidor em que ninguém sabe o que está a correr nem porquê não pode ser gerido nem recuperado.
Faça isto. Teste com uma regra temporária e restrita (uma porta, um endereço de origem) e remova-a depois. Trabalhe como utilizador comum com sudo. Mantenha um pequeno dossier do servidor: o que está a correr, que portas estão abertas, onde estão as cópias de segurança, qual é a data de fim de suporte da versão (lição 10.4).
Na prática
Todos estes erros podem ser cometidos em qualquer VPS, na WebOké tal como noutros fornecedores: o que acontece dentro do seu servidor é gerido por si. O fornecedor pode, ainda assim, desligar um servidor da rede se este enviar spam ou realizar ataques, porque isso afeta outros clientes. Prevenir é, portanto, também importante para a disponibilidade do seu próprio servidor.
Resumo
- A maioria dos ataques explora erros conhecidos, não vulnerabilidades desconhecidas.
- Início de sessão com chaves, início de sessão por palavra-passe desativado; bases de dados, caches e a API do Docker nunca abertos à internet; nada de
docker.sockem contentores em que não confie totalmente. - Nada de
chmod 777nem decurl | bash: saiba quem pode fazer o quê e o que está a instalar. - Atualizações automáticas, cópias de segurança fora do servidor e testadas, painéis de administração atrás de um túnel ou com autenticação de dois fatores.
- Segredos fora do Git e fora dos ficheiros compose; o que foi divulgado é substituído.
Questionário
Exercício
Exercício Z10.2: Que erro é este? No ficheiro de exemplo casussen-z10-2.md encontram-se oito casos curtos de servidores com algum problema. Para cada caso, escolha qual é o erro da lista desta lição (A a J) e qual é o melhor primeiro passo. O programa compara com a chave fixa e mostra depois a explicação de cada caso.
Para saber mais
- Proteger o seu VPS: os primeiros cinco minutos
- Gestor de palavras-passe e passkeys: assim organiza os seus inícios de sessão com segurança
- Documentação do Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
- Documentação do Docker, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
- Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/