No post anterior, vimos sobre o protocolo SSH, se o ssh cliente e servidor estão instalados e preparamos um terreno para esse post.
Segue nossa estrutura
Esses passo a passos serão feitos apenas no servidor, ou seja, na máquina empresa100, com ip 192.168.0.40.
Após Instalado o SSH server, Quais os Primeiros passos para Garantir um mínimo de Segurança em minha Rede?
Após instalado o servidor SSH já traz boas configurações por padrão, mas não podemos aceitá-las às cegas.
Podemos controlar o comportamento do nosso servidor de 3 maneiras:
- configurações globais: que afetarão todo o sistema do servidor SSH.
- Configurações Por Usuário: São praticadas por usuários finais. Afetam apenas o Servidor SSH na conta do usuário que está realizando essas modificações. As configurações SSH nas outras contas de usuários não são alteradas.
Um usuário, por exemplo, pode querer negar acesso ssh à sua conta. - Configurações durante a instalação/compilação: do nossos servidor SSH. Podemos escolher quais recursos incluir ou não no SSH durante sua configuração.
As configurações globais podem depender das configurações durante a instalação/compilação. Por exemplo, se optamos por não instalar uma determinada função durante a compilação do servidor ssh então essa função não ficará disponível para configurarmos mais tarde através das configurações globais.
Aqui iremos alterar algumas Configurações Globais do servidor SSH que nos dará seguranças minímas.
Configurações Globais do SSH
Podemos alterar as configurações globais do servidor ssh de duas maneiras,
1) através do arquivo de configuração
2) por linha de comando.
iremos alterar o arquivo, ou seja, usando o método 01.
No CentOS, o arquivo de configuração do servidor ssh é o “/etc/ssh/sshd_config”. Acesse ele usando seu editor favorito. Usarei o vim.
[elder@centos65 ~]$ sudo vim /etc/ssh/sshd_config
Protocol: Versão do Protocolo SSH
Podemos escolher entre os protocolos SSH-1 e SSH-2. Por questão de segurança é bom evitarmos usar “Protocol 1(SSH-1).
Esse opção já vem como “Protocol 2” por padrão e assim não há o que alterar, mas citei aqui para conhecimento dos marinheiros de primeira viagem.
Port: Alterar Porta SSH no Servidor SSH
Após alterada a porta de 22 para 2222, você irá acessar o servidor ssh utilizando a opção “-p”
Exemplo,
elder@ubuntu:~$ ssh 192.168.0.40 -p 2222
A porta padrão de acesso para o servidor SSH é a 22. Uma boa prática é alterá-la para um valor igual ou acima de 1024. portas abaixo de 1024 são reservadas pelo Sistema Operacional.
Alterar a porta pode evitar que “Robôs”, que ficam tentando encontrar IPs aleatórios na internet, encontre seu ip público e faça milhares de tentativas a fim de descobrir a senha SSH por força bruta. Vai por mim 🙂 Se deixar na porta padrão 22 e seu ip público acessível dentro de poucas horas irá ver muitas tentativas de acesso.
PermitRootLogin: Desativar Acesso do Usuário Root no Servidor SSH
Defina para “no” a opção PermitRootLogin.
Além da porta 22, o usuário root, além de todo poderoso, é um usuário que existe em todas as distros Linux. Se deixar acesso via ssh ao root e ainda a porta 22 definida estará dando quase que a faca e o queijo aos hackers: “Já tenho o ip, a porta e o usuário root. ÊÊÊÊbba! Falta apenas a senha!” 🙂
Altere porta, defina “PermitRootLogin no”
MaxAuthTries: Limitar Tentativas Máximas de Login
limite as tentativas com falhas de login. Isso irá frustrar tentativas de “adivinhação de senha”.
Acima, deixei 2. Assim, tenho duas tentativas. Após isso, é bom definir um tempo de espera para novas tentativas.
LoginGraceTime: Tempo de Espera para Próximas tentativas
Após tentar logar 2 vezes e falhar, terei que esperar 2 minutos. Poderíamos aumentar esse tempo para 5 minutos(5m) ou 10(10m) 🙂
MaxStartups: Quantidade Máximas de Conexões Simultâneas
O valor de MaxStartups é definido da seguinte forma
onde, com 10 conexões a probabilidade de rejeição das próximas será de 50%; com 20 conexões a rejeição será 100%, não aceitando mais nenhum nova.
Limitar essas conexões limitará ataques de DOS(Denial of Service) ou DDOS(Distributed Denial of Service). Também evitará que muito mais pessoas em um ambiente de trabalho acessem de forma a esgotar a memória ram ou outro recurso do seu servidor.
PubkeyAuthentication: Autenticação usando um par de chaves
Essa configuração é muiiiito recomendada!!!
Quando PubkeyAuthentication é definida como yes a função de login(modo de acesso) por meio de chaves é habilitada.
Iremos criar um post sobre esse assunto, visto a sua importância! mas para entendermos seu funcionamento básico insiro abaixo algumas linhas:
- No computador cliente, que você usa para acessar o servidor ssh, usamos o comando ssh-keygen para gerar um par de chaves: uma chave privada e outra pública.
- Enviamos a chave pública para o servidor ssh e a inserimos ao final do arquivo “/home/elder/.ssh/authorized_keys”
- Opcional, mas Recomendado: No arquivo “/etc/ssh/sshd_config” definimos “PasswordAuthentication no”
Bom, esse último método , PubkeyAuthentication yes, é fortemente recomendado. Mas temos que ter a garantia que o acesso via chaves está funcionando antes de colocar PasswordAuthentication no.
O próximo post será sobre a geração e uso do par de chaves.
Conclusão
As medidas acima são básicas mas primordiais após instalação dos serviços de ssh.
Reforçando, “PasswordAuthentication no” deve ser usado apenas quando estamos certos do funcionamento das chaves. Se chegarmos a enviar a chave pública para o servidor ssh e, por exemplo, inserirmos por engano outra pública chave no arquivo authorized_keys ou apagar, sem querer querendo, todo o conteúdo dentro de authorized_keys ficaremos sem acesso e para consertar teríamos que ir até o local de instalação do servidor para realizar as devidas correções. Isso se o servidor ssh não ficar situado em outra cidade.