Instalou o OpenSSH? Estas configurações são “obrigatórias”…
Quem usa sistemas Linux, como o Ubuntu, CentOS, Debian, entre outros, sabe que é muito fácil aceder remotamente a outra máquina. Um dos protocolos mais conhecidos e mais usados é o SSH. Este protocolo é extremamente versátil e pode-se instalar e configurar rapidamente.
Hoje deixamos algumas dicas de configuração, por questões de segurança, do OpenSSH. Saiba o que pode fazer.
O OpenSSH é um conjunto de ferramentas que nos permite gerir remotamente máquinas, recorrendo ao protocolo SSH. Ao contrário de outras ferramentas como o Telnet, rcp, rlogin e ftp, o OpenSSH garante que as comunicações entre máquinas sejam seguras, pois, recorre à criptografia para cifrar todo o tráfego (incluindo passwords).
Como instalar e configurar o OpenSSH no Ubuntu Server?
Instalar o SSH no Ubuntu é algo relativamente simples. Para isso basta que abram o terminal e insiram o seguinte comando:
sudo apt install ssh |
Em seguida vamos iniciar e ativar o serviço no arranque. Para tal usem os seguintes comandos:
sudo systemctl start ssh sudo systemctl enable ssh |
Configurações importantes do OpenSSH (Segurança)
#1 - Desativar o acesso via utilizador root
Antes de desabilitarmos o login ao utilizador root, é importante que tenho um utilizador que possa fazer login como root. Por exemplo, permita que o utilizador pplware efetue login como root usando o comando sudo. Para tal deve fazer as seguintes configurações:
sudo adduser pplware sudo adduser pplware sudo |
Em seguida basta ir ao ficheiro de configuração do OpenSSH (/etc/ssh/sshd_config) e realizar a seguinte configuração:
PermitRootLogin no |
Depois é só gravar as configurações e reiniciar o serviço (sudo systemctl restart ssh).
#2 - Desativar acesso sem password
Outra das opções é desativar o acesso ao SSH sem password. Para tal basta colocar o PermitEmptyPasswords a no.
#3 - Mudar porto lógico de acesso
Caso pretendam mudar o porto lógico de acesso ao OpenSSH, que por omissão é o 22, podem fazê-lo na instrução Port como mostra a imagem seguinte. Com a configuração da imagem, mudamos o porto de 22 para 2222.
#4 - Número de tentativas por ligação
Através da configuração do OpenSSH é possível indicar quantas tentativas pode um utilizador ter para se autenticar por ligação. O campo MaxAuthTries especifica o número máximo de tentativas de autenticação permitidas por cada ligação. Vamos, por exemplo, indicar que o utilizador tem 3 tentativas.
#5 - Tempo de espera para autenticação
Também é possível definir a quantidade de tempo que um utilizador tem para concluir a autenticação depois de se ligar inicialmente ao seu servidor SSH. Para tal basta que mude o parâmetro LoginGraceTime (tempo em segundos).
E está feito! Como viram a configuração é simples e rápida. Para se ligarem a uma máquina com SSH podem usar ferramentas como o Putty ou WinSCP, ou então, via terminal, com o comando ssh utilizador@endereco_ip.
Este artigo tem mais de um ano
2° passo adicionar auth por key….
Pois…
Dizer para desactivar passwords sem activar chaves…
Para alem disso eu diria que o programa fail to ban é bem util
Pelo que está no artigo, foi dito para desactivar a “PermitEmptyPasswords” ou seja, logins com passwords vazias. Nada tem a haver com desactivar passwords.
Uma mudança que não tem quase qualquer efeito é a mudança de porto, basta um simples scan e detecta-se o porto que está a ser utilizado para qualquer protocolo.
Todos os outros pontos parece-me bem.
Claro que não se mete autenticação por password, isso é o básico “não”, tem de ser por chave publica/ privada ou EdDSA Ed448 (+/- 223 bit de segurança) ou RSA 8192 (+/- 192 bit de segurança) (ou superior: RSA 16384 (+/- 256 bit de segurança) )… se for chave RSA e utilizarem algo como Putty Key Generator para a criar usem as opções mais avançadas para garantir a máxima segurança: Key > “Use proven primes with even distribution (slowest)” e “Use “strong” primes as RSA key factors”. Todo o cuidado é pouco na geração destas chaves… e muitos problemas no passado aconteceram por causa de não ter existido todo o cuidado necessário.
Para a actualidade e para os próximos anos (até ao ano de 2028) 128 bit é o nível de segurança mínimo recomendado pela ECRYPT, pelo que qualquer das opções acima é mais do que suficiente, e deixam uma margem confortável de segurança.
Depois do ano 2028 o nível mínimo recomendado é de 256 bit e realmente aí só com RSA 16384 bit é que é possível atingir e ultrapassar ligeiramente os valores mínimos recomendados para atingir esse nível de segurança.
Quer dizer, teoricamente o ECDSA nistp521 também permite atingir o nível de segurança de 256 bit, mas existem dúvidas na comunidade que se dedica a esta área acerca da forma como as curvas elípticas apareceram, desconfiando-se que a NSA, que as criou, criou com alguma vulnerabilidade… logo não são tão confiáveis nesse aspecto.
Instalar ja, nem preciso do windows
2fa adiciona outra camada de protecção
2fa no ssh? Não sabia que era possível!
Aparentemente até é possível utilizar chaves de segurança físicas FIDO2, como segundo factor de autenticação (exemplo de implementação: https://www.stavros.io/posts/u2f-fido2-with-ssh/ ).
Diria que em conjunto com a chave pública/ privada de autenticação primária EdDSA Ed448, ou RSA 8192, ou RSA 16384, é o nível de segurança maior que se pode obter… maior mesmo só se conseguirem gerar a chave primária a partir de um dispositivo de hardware de segurança (HSM) dedicado só para essa função… para nenhum código maligno conseguir obter a chave privada.
Se quiser apertar a malha, ainda mais, pode até definir o IP e o utilizador, tudo o que for diferente o SSH chuta logo para canto.
O porto 22 TCP é muito utilizado por intrusos.
Quem não precisar de utilizar o protocolo SSH deverá bloquear o mesmo.
O unified firewall (ufw) presente em muitas distros e o seu “gui” muito intuitivo (gufw) permite acrescentar as mais diversas “rules” ali pré-definidas, entre as quais a “rule” para o SSH, podendo reverter em qualquer altura, assim como voltar a activar.
Bastará adiccionar esta “rule” presente no menu e fazer o “Deny” bidireccionalmente para bloquear o SSH.
Outras “rules” importantes para dificultar o trabalho dos intrusos são, por exemplo: samba, ftb, telnet, UpnP, RDP, NTP, imap, imaps, pop3, pop3s etc.
Basta o deny de cada uma bidireccionalmente.
Haverá outros protocolos também críticos, venham daí sugestões.