![A infraestrutura automatizada pode eliminar tickets de trabalho?](https://optimuscloud.com.br/wp-content/uploads/2024/01/1706089444_A-infraestrutura-automatizada-pode-eliminar-tickets-de-trabalho-150x150.jpg)
A infraestrutura automatizada pode eliminar tickets de trabalho?
24 de janeiro de 2024![Featued image for: What Is API Management?](https://optimuscloud.com.br/wp-content/uploads/2024/01/1706091725_O-que-e-gerenciamento-de-API-150x150.jpg)
O que é gerenciamento de API?
24 de janeiro de 2024Ubuntu Server é um dos sistemas operacionais mais populares usados para implantações de contêineres. Muitos administradores e membros da equipe DevOps presumem que se concentrarem todos os seus esforços de segurança começando com a imagem do contêiner, tudo estará pronto.
No entanto, se você negligenciar o sistema operacional no qual tudo está instalado e implantado, estará negligenciando uma das etapas mais importantes (e mais fáceis) a serem executadas.
Nesse sentido, quero orientá-lo em algumas tarefas críticas que você pode realizar com o Ubuntu Server para garantir que a base de suas implantações seja a mais segura possível. Você ficará surpreso com o quão fácil isso é.
Você está pronto?
Vamos fazer isso.
Agende atualizações regulares
Não sei dizer quantos servidores encontrei onde o administrador (ou equipe de administradores) não conseguiu executar atualizações regulares. Isso deveria ser absolutamente óbvio, mas eu entendo o raciocínio por trás do fracasso em fazer isso. Em primeiro lugar, as pessoas ficam ocupadas, então as atualizações tendem a ser deixadas de lado em vez de apagar incêndios.
Segundo, quando o kernel é atualizado, o servidor deve ser reinicializado. Considerando como o tempo de inatividade é desaprovado, é compreensível que alguns administradores hesitem em executar atualizações.
Não.
As atualizações são a única maneira de garantir que seu servidor esteja protegido contra as ameaças mais recentes e, se você não atualizar, esses servidores ficarão vulneráveis.
Por causa disso, encontre um momento em que uma reinicialização não interrompa o serviço e aplique as atualizações.
Claro, você também pode adicionar o Ubuntu Livepatch ao sistema, para que os patches sejam baixados, verificados e aplicados automaticamente ao kernel em execução, sem a necessidade de reinicialização.
Não habilite root
O Ubuntu vem com a conta root desabilitada. Em seu lugar está o sudo e não posso recomendar o suficiente para que você não habilite e use a conta root. Ao habilitar a conta root, você expõe seu(s) sistema(s) a riscos de segurança. Você pode até desabilitar completamente o root, com o comando:
sudo passwd -l root
O que o comando acima faz é expirar a senha root, portanto, até que você redefina a senha root, o usuário root ficará efetivamente inacessível.
Desative o login SSH para o usuário root
A próxima etapa que você deve realizar é desabilitar o login SSH do usuário root. Por padrão, o Ubuntu Server permite o login SSH root, o que deve ser considerado um problema de segurança na espera. Felizmente, desabilitar o acesso root SSH é muito simples.
Faça login no seu servidor Ubuntu e abra o arquivo de configuração do daemon SSH com:
sudo nano /etc/ssh/sshd_config
Nesse arquivo, procure a linha:
#PermitRootLogin prohibit-password
Mude isso para:
PermitRootLogin no
Salve e feche o arquivo. Reinicie o SSH com:
sudo systemctl restart sshd
O usuário root não terá mais acesso via SSH.
Use autenticação de chave SSH
Falando em Secure Shell, você deve sempre usar autenticação de chave, pois é muito mais seguro do que logins tradicionais baseados em senha. Este processo leva algumas etapas e começa com a criação de um par de chaves SSH no(s) sistema(s) que será(ão) usado(s) para acessar o servidor. Você desejará fazer isso em qualquer máquina que use SSH para acessar remotamente seu servidor.
A primeira coisa a fazer é gerar uma chave SSH com o comando:
ssh-keygen
Siga as instruções e o SSH irá gerar um par de chaves e salvá-lo em ~/.ssh.
Em seguida, copie essa chave para o servidor com o comando:
ssh-copy-id SERVER
Onde SERVER é o endereço IP do servidor remoto.
Depois que a chave for copiada, tente fazer login SSH na máquina local para verificar se funciona.
Repita as etapas acima em qualquer máquina que precise de acesso SSH ao servidor porque não desabilitaremos a autenticação por senha SSH. Uma coisa a ter em mente é que, depois de desabilitar a autenticação por senha, você só poderá acessar o servidor a partir de uma máquina que tenha copiado sua chave SSH para o servidor. Por isso, certifique-se de ter acesso local ao servidor em questão (por precaução).
Para desabilitar a autenticação por senha SSH, abra o arquivo de configuração do daemon SSH novamente e procure as seguintes linhas:
#PubkeyAuthentication yes
e
#PasswordAuthentication yes
Remova os caracteres # de ambas as linhas e altere sim para não na segunda. Depois de fazer isso, salve e feche o arquivo. Reinicie o SSH com:
sudo systemctl restart sshd
Seu servidor agora aceitará apenas conexões SSH usando autenticação de chave.
Instale Fail2ban
Falando em logins SSH, uma das primeiras coisas que você deve fazer com o Ubuntu Server é instalar o fail2ban. Este sistema controla arquivos de log específicos para detectar logins SSH indesejados. Quando o fail2ban detecta uma tentativa de comprometer seu sistema via SSH, ele bane automaticamente o endereço IP infrator.
O aplicativo fail2ban pode ser instalado a partir dos repositórios padrão, usando o comando:
sudo apt-get install fail2ban -y
Depois de instalado, você precisará configurar uma prisão SSH. Crie o arquivo de prisão com:
sudo nano /etc/fail2ban/jail.local
No arquivo, cole o seguinte conteúdo:
(sshd) enabled = true port = 22 filter = sshd logpath = /var/log/auth.log maxretry = 3
Reinicie o fail2ban com:
sudo systemctl restart fail2ban
Agora, sempre que alguém tentar fazer login no seu servidor Ubuntu e falhar 3 vezes, o endereço IP será bloqueado permanentemente.
Memória compartilhada segura
Por padrão, a memória compartilhada é montada como leitura/gravação. Isso significa que o espaço /run/shm pode ser explorado e qualquer aplicativo ou serviço que tenha acesso a /run/shm. Para evitar isso, basta montar /run/shm com certos privilégios.
A única ressalva é que você pode executar determinados aplicativos ou serviços que exigem acesso de leitura/gravação à memória compartilhada. Felizmente, a maioria dos aplicativos que exigem esse acesso são GUIs, mas isso não é absoluto. Portanto, se você descobrir que determinados aplicativos começam a se comportar de maneira inadequada, será necessário retornar a montagem de leitura/gravação para a memória compartilhada.
Para fazer isso, abra /etc/fstab para edição com o comando:
sudo nano /etc/fstab
Na parte inferior do arquivo, adicione a seguinte linha:
tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0
Salve e feche o arquivo. Reinicie o sistema com o comando:
sudo reboot
Depois que o sistema for reinicializado, a memória compartilhada não será mais montada com acesso de leitura/gravação.
Habilite o Firewall
O Firewall Descomplicado (UFW) está desabilitado por padrão. Esta não é uma boa ideia para máquinas de produção. Felizmente, o UFW é incrivelmente fácil de usar e recomendo enfaticamente que você o habilite imediatamente.
Para habilitar o UFW, emita o comando:
sudo ufw enable
O próximo comando que você deseja executar é permitir conexões SSH. Esse comando é:
sudo ufw allow ssh
Você pode então permitir outros serviços, conforme necessário, como HTTP e HTTPS da seguinte forma:
sudo ufw allow http sudo ufw allow https
Para obter mais informações sobre o UFW, leia a página de manual com o comando:
cara, ah
Pensamentos finais
Estas são as primeiras (e muitas vezes as mais importantes) etapas para fortalecer o Ubuntu Server. Você também pode ir um pouco mais longe com políticas de senha e autenticação de dois fatores, mas as etapas acima ajudarão muito a fornecer uma base sólida para construir.
A postagem Endureça o servidor Ubuntu para proteger seu contêiner e outras implantações apareceu pela primeira vez em The New Stack.