<<TableOfContents: execution failed “] (ver também o log)>>
OpenSSH (ou Secure SHell) tornou-se um padrão de facto para acesso remoto substituindo o protocolo telnet. O SSH tornou protocolos como o telnet redundantes devido, em grande parte, ao fato de que a conexão é criptografada e as senhas não são mais enviadas em texto simples para que todos vejam.
No entanto, uma instalação padrão do ssh não é perfeita, e ao executar um servidor ssh há alguns passos simples que podem endurecer drasticamente uma instalação.
Use Strong Passwords/Usernames
Uma das primeiras coisas que você vai notar se você tiver o ssh rodando e exposto ao mundo exterior é que você provavelmente vai registrar tentativas de hackers para adivinhar seu nome de usuário/senha. Normalmente um hacker irá procurar pela porta 22 (a porta padrão na qual o ssh ouve) para encontrar máquinas com o ssh em execução, e depois tentar um ataque de força bruta contra ele. Com senhas fortes no lugar, espero que qualquer ataque seja registrado e notado antes que ele possa ser bem sucedido.
Espera que você já use senhas fortes, mas se você não estiver, tente escolher as senhas que contém:
- Mínimo de 8 caracteres
- Mix de letras maiúsculas e minúsculas
- Mix de letras e números
- Nem caracteres alfanuméricos (por exemplo, caracteres especiais como ! ” £ $ % ^ etc)
Os benefícios das senhas fortes não são específicos do ssh, mas têm um impacto em todos os aspectos da segurança do sistema. Mais informações sobre senhas podem ser encontradas na documentação do CentOS:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Se você não pode absolutamente impedir seus usuários de escolher senhas fracas, então considere usar nomes de usuário gerados aleatoriamente ou difíceis de adivinhar para suas contas de usuário. Se os vilões não conseguem adivinhar o nome de usuário, então eles não podem forçar a senha. No entanto, isso ainda é segurança através da obscuridade e estar ciente do vazamento de informações de nomes de usuário de coisas como e-mail enviado de contas de usuário.
Disable Root Logins
SSH server settings are stored in the /etc/ssh/sshd_config file. Para desactivar os logins de raiz, certifique-se de que tem a seguinte entrada:
# Prevent root logins:PermitRootLogin no
e reinicie o serviço sshd:
service sshd restart
Se precisar de acesso root, inicie sessão como um utilizador normal e use o comando su.
Limitar Logins de Utilizador
SH logins podem ser limitados apenas a determinados utilizadores que necessitem de acesso remoto. Se você tem muitas contas de usuário no sistema então faz sentido limitar o acesso remoto apenas àqueles que realmente precisam dele, limitando assim o impacto de um usuário casual com uma senha fraca. Adicione uma linha AllowUsers seguida por uma lista separada por espaço de nomes de usuário ao /etc/ssh/sshd_config Por exemplo:
AllowUsers alice bob
e reinicie o serviço sshd.
Protocolo Desabilitado 1
SSH tem dois protocolos que pode usar, o protocolo 1 e o protocolo 2. O protocolo mais antigo 1 é menos seguro e deve ser desativado, a menos que você saiba que você especificamente precisa dele. Procure a seguinte linha no arquivo /etc/ssh/sshd_config, descomente-o e altere conforme mostrado:
# Protocol 2,1Protocol 2
e reinicie o serviço sshd.
Use a Non-Standard Port
Por defeito, o ssh escuta as ligações de entrada na porta 22. Para um hacker determinar se o ssh está rodando em sua máquina, ele provavelmente escaneará a porta 22 para determinar isso. Um método eficaz é executar o ssh em uma porta não-padrão. Qualquer porta não utilizada serve, embora uma acima de 1024 seja preferível. Muitas pessoas escolhem a 2222 como porta alternativa (como é fácil de lembrar), assim como a 8080 é muitas vezes conhecida como porta HTTP alternativa. Por esta mesma razão, provavelmente não é a melhor escolha, já que qualquer hacker escaneando a porta 22 provavelmente também escaneará a porta 2222 apenas para uma boa medida. É melhor escolher alguma porta alta aleatória que não seja usada para nenhum serviço conhecido. Para fazer a mudança, adicione uma linha como esta ao seu arquivo /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
e reinicie o serviço sshd. Não se esqueça de fazer quaisquer alterações necessárias ao reencaminhamento de portas no seu router e quaisquer regras de firewall aplicáveis. Por exemplo no CentOS 7 (e superior) você pode mudar o serviço ssh do firewalld fazendo uma duplicata do seu arquivo de serviço em /etc/firewalld/ e mudando sua linha de porta:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Então altere a linha de porta em /etc/firewalld/services/ssh-custom.xml para que a porta seja a mesma que no arquivo de configuração ssh:
<port protocol="tcp" port="2345"/>
Após, remova o serviço ssh, adicione o serviço ssh-custom, e recarregue o firewalld para que a alteração tenha efeito:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Or no CentOS 6, adicione uma regra iptable para abrir a nova porta ssh:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Não se esqueça de fechar a porta antiga também.
No CentOS 6 e acima você também deve atualizar o selinux, etiquetando corretamente a porta escolhida, caso contrário o sshd será impedido de acessá-la. Por exemplo:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Porque o ssh não está mais escutando conexões na porta padrão, você precisará dizer ao seu cliente em que porta conectar. Usando o cliente ssh a partir da linha de comando, podemos especificar a porta usando o switch -p:
$ ssh -p 2345 myserver
ou se você estiver usando o protocolo fish no konqueror, por exemplo:
fish://myserver:2345/remote/dir
Se você está pensando que isso soa como uma dor ter que especificar a porta cada vez que você conectar, simplesmente adicione uma entrada especificando a porta no seu arquivo local ~/.ssh/config:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
E o ficheiro: ~/.ssh/config deve ter as seguintes permissões:
$ chmod 600 ~/.ssh/config
Filtro SSH no Firewall
Se você só precisa de acesso remoto de um endereço IP (digamos do trabalho para o seu servidor doméstico), então considere filtrar as conexões no seu firewall adicionando uma regra de firewall no seu roteador ou no iptables para limitar o acesso na porta 22 apenas para aquele endereço IP específico. Por exemplo, no iptables isso pode ser conseguido com o seguinte tipo de regra para iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
ou usando firwalld (CentOS 7) use regras rich-rules para permitir ssh somente em uma porta específica. O endereço de origem pode ser um único endereço ou um endereço base com uma máscara de bits:
SSH também suporta nativamente TCP wrappers e o acesso ao serviço ssh pode ser controlado de forma similar usando hosts.allow e hosts.deny.
Se você não consegue limitar os endereços IP de origem, e precisa abrir a porta ssh globalmente, então o iptables ainda pode ajudar a prevenir ataques de força bruta, registrando e bloqueando tentativas repetidas de login a partir do mesmo endereço IP. Por exemplo, com iptables
A primeira regra registra o endereço IP de cada nova tentativa de acesso à porta 22 usando o módulo recente. A segunda regra verifica se esse endereço IP tentou se conectar 4 ou mais vezes nos últimos 60 segundos, e se não, então o pacote é aceito. Note que esta regra requereria uma política padrão de DROP na cadeia de entrada.
Não se esqueça de mudar a porta como apropriado se você estiver rodando ssh em uma porta não-padrão. Quando possível, a filtragem no firewall é um método extremamente eficaz de proteger o acesso a um servidor ssh.
Para sistemas usando o serviço FirewallD (CentOS 7 ou superior), use o firewall-cmd:
O primeiro comando remove a regra de serviço mais permissiva, o segundo instata uma regra para aceitar apenas 4 conexões em um minuto e registrar todas as conexões.
Utilizar chaves públicas/privadas para autenticação
Utilizar chaves criptografadas para autenticação oferece dois benefícios principais. Em primeiro lugar, é conveniente já que já não precisa de introduzir uma palavra-passe (a menos que encripte as suas chaves com protecção por palavra-passe) se utilizar chaves públicas/privadas. Em segundo lugar, uma vez que a autenticação do par de chaves públicas/privadas tenha sido configurada no servidor, você pode desativar a autenticação da senha completamente, o que significa que sem uma chave autorizada você não pode obter acesso – então não há mais tentativas de cracking da senha.
É um processo relativamente simples criar um par de chaves públicas/privadas e instalá-las para uso no seu servidor ssh.
Primeiro, crie um par de chaves públicas/privadas no cliente que irá utilizar para se ligar ao servidor (terá de o fazer a partir de cada máquina cliente a partir da qual se liga):
$ ssh-keygen -t rsa
Se ainda não quiser que lhe seja pedida uma senha (que é basicamente uma senha para desbloquear uma determinada chave pública) cada vez que se conectar, basta pressionar enter quando lhe for pedida uma senha ao criar o par de chaves. Cabe a você decidir se deve ou não adicionar a criptografia de proteção de senha à sua chave quando você a criar. Se você não proteger sua chave por senha, então qualquer pessoa que tenha acesso à sua máquina local terá automaticamente acesso ssh ao servidor remoto. Além disso, root na máquina local tem acesso às suas chaves, embora se suponha que se você não puder confiar em root (ou root estiver comprometido), então você está com problemas reais. Criptografar a chave adiciona segurança adicional às custas de eliminar a necessidade de inserir uma senha para que o servidor ssh seja substituído apenas por inserir uma frase-chave para o uso da chave. Isto pode ser ainda mais simplificado com o uso do programa ssh_agent
Agora defina as permissões na sua chave privada:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Copie a chave pública (id_rsa.pub) para o servidor e instale-a na lista de chaves_autorizadas:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Nota: depois de importar a chave pública, você pode apagá-la do servidor.
e finalmente definir as permissões dos ficheiros no servidor:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
As permissões acima são necessárias se StrictModes estiver definido para sim em /etc/ssh/sshd_config (o padrão).
Certifique-se de que os contextos SELinux correctos estão definidos:
$ restorecon -Rv ~/.ssh
Agora, quando iniciar sessão no servidor não lhe será pedida uma palavra-passe (a menos que tenha introduzido uma palavra-passe quando criou o seu par de chaves). Por padrão, o ssh tentará primeiro se autenticar usando chaves. Se nenhuma chave for encontrada ou a autenticação falhar, então o ssh voltará à autenticação de senha convencional.
Após ter verificado que pode iniciar sessão com sucesso no servidor usando o seu par de chaves públicas/privadas, pode desactivar completamente a autenticação da palavra-passe adicionando a seguinte configuração ao seu ficheiro /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Pergunta Frequentemente Feita (FAQ)
Q: CentOS usa a versão X do OpenSSH e a última versão é a versão Y. A versão X continha uma grave falha de segurança, devo atualizar?
A: Não. O Upstream Vendor tem uma política de backporte de patches de segurança das últimas versões para a versão de distribuição atual. Desde que você tenha as últimas atualizações aplicadas para sua distribuição CentOS, você está totalmente corrigido. Veja aqui para mais detalhes sobre backporting de patches de segurança:
http://www.redhat.com/advice/speaks_backport.html
Q: Como obter ssh para permitir autenticação sem senha baseada em chaves entre máquinas que compartilham os diretórios domésticos dos usuários por NFS?
A: O SElinux bloqueia o acesso root aos diretórios e arquivos compartilhados do NFS que não são legíveis mundialmente por padrão e por isso o sshd não consegue ler os arquivos chave dos usuários em ~/.ssh. Para ativar o acesso, altere a configuração de use_nfs_home_dirs executando o seguinte comando como superusuário:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html