DevSecOps

29 jan, 2013

Top 21 melhores práticas de segurança em servidor OpenSSH – Parte 01

Publicidade

Este artigo, divido em duas partes, vai tratar das 21 melhores práticas de segurança em servidor OpenSSH. Neste, você vai conhecer as 11 primeiras.

O OpenSSH é a implementação do protocolo SSH. Ele é recomendado para login remoto, fazer backups, transferência de arquivos remotos via scp ou sftp, e muito mais. O SSH é perfeito para manter a confidencialidade e a integridade dos dados trocados entre duas redes e sistemas. No entanto, a principal vantagem é a autenticação do servidor, pelo uso de criptografia de chave pública. De tempos em tempos, aparecem rumores sobre o exploite zero day do OpenSSH. Aqui estão algumas coisas que você precisa ajustar para melhorar a segurança do servidor OpenSSH.

Arquivos de Configuração Padrão e porta SSH

  • /etc/ssh/sshd_config – arquivo de configuração do servidor OpenSSH.
  • /etc/ssh/ssh_config – arquivo de configuração do cliente OpenSSH.
  • ~/.ssh/ – diretório de configuração de usuários ssh.
  • ~/.ssh/authorized_keys ou ~/.ssh/authorized_keys – lista as chaves públicas (RSA ou DSA) que podem ser utilizadas para fazer login na conta do usuário.
  • /etc/nologin – se esse arquivo existir, o sshd só permite que o root faça login.
  • /etc/hosts.allow e /etc/hosts.deny: as listas de controle de acesso devem ser reforçadas pelo tcp-wrappers são definidas aqui.
  • SSH default port: TCP 22

imagem 1

#1: Desativar servidor OpenSSH

As estações de trabalho e os laptops podem funcionar sem o servidor OpenSSH. Se você não precisa fornecer o login remoto e recursos de transferência de arquivos do SSH, desabilite e remova o servidor SSHD. O usuário de CentOS/RHEL/Fedora Linux pode desabilitar e remover openssh-server com o comando yum:

# chkconfig sshd off
# yum erase openssh-server

O usuário de Debian/Ubuntu Linux pode desativar e remover o mesmo com o comando apt-get:

# apt-get remove openssh-server

Pode ser preciso atualizar o script iptables para remover a regra de exceção ssh. No CentOS/RHEL/Fedora, edite os arquivos /etc/sysconfig/iptables e /etc/sysconfig/ip6tables. Uma vez feito isso, reinicie o serviço iptables:

# service iptables restart
# service ip6tables restart

#2: Use apenas protocolo SSH 2

A versão 1 do protocolo SSH (SSH-1) apresenta problemas de ataques e vulnerabilidades de segurança. A versão SSH-1 é obsoleta e deve ser evitada a todo custo. Abra sshd_config e verifique se existe a seguinte linha:

Protocol 2

#3: Limite o acesso SSH do usuário

Por padrão, todos os usuários de sistemas podem fazer login via SSH utilizando sua senha ou chave pública. Às vezes, você cria uma conta de usuário UNIX/Linux para fins de ftp ou e-mail. No entanto, os usuários podem acessar o sistema utilizando ssh. Eles terão acesso total a ferramentas do sistema, incluindo compiladores e linguagens de script como Perl e Python, que podem abrir as portas de rede e fazer muitas outras coisas extravagantes. Um dos meus clientes tinha um script php muito desatualizado e um invasor foi capaz de criar uma nova conta no sistema através de um script php. No entanto, ele não conseguiu entrar na box via ssh, porque não estava em AllowUsers.

Permita somente que os usuários root, vivek e jerry utilizem o sistema via SSH; adicione o seguinte ao sshd_config:

AllowUsers root vivek jerry

Alternativamente, você pode permitir que todos os usuários façam login via SSH, porém negue apenas alguns, com a seguinte linha:

DenyUsers saroj anjali foo

Você pode também configurar o Linux PAM para que ele permita ou negue o login via servidor sshd. Você pode permitir ou negar o acesso de uma lista de nome de grupos ao ssh.

#4: Configure Idle Log Out Timeout Interval

O usuário pode se conectar ao servidor via ssh e é possível que você defina um tempo limite ocioso para evitar uma sessão ssh inativa. Abra o sshd_config e verifique se os seguintes valores estão configurados:

ClientAliveInterval 300
ClientAliveCountMax 0

Você está definindo um intervalo de tempo limite ocioso em segundos (300 segs = 5 minutos). Depois que esse intervalo passou, o usuário ocioso será automaticamente expulso (leia-se desconectado). Veja como fazer automaticamente o login BASH / tcsh / SSH do usuário depois de um período de inatividade para mais detalhes.

#5: Desativar arquivos .rhosts

Não leie os arquivos do usuário ~/.rhosts e ~/.shosts. Atualize o sshd_config com as seguintes configurações:

IgnoreRhosts yes

O SSH pode emular o comportamento do comando obsoleto rsh. Para isso, você só precisa desabilitar o acesso inseguro via RSH.

#6: Desativar o host-based authentication

Para desativar o host-based authentication, atualize o sshd_config com a seguinte opção:

HostbasedAuthentication no

#7: Desativar login root via SSH

Não existe necessidade de entrar como root via ssh em uma rede. Os usuários normais podem usar su ou sudo (recomendado) para ter acesso de nível root. Isso também garante que você tenha informações completas de auditoria sobre quem rodou comandos privilegiados no sistema via sudo. Para desativar root login via SSH, atualize sshd_config com a seguinte linha:

PermitRootLogin no

No entanto, o Bob fez uma excelente observação:

Dizer “não logar como root” é bobagem. Isso vem dos dias em que as pessoas usaram os primeiros pacotes de sessões. Assim, logar como você e su-ing diminuiu a chance de um invasor ver o root pw e diminuiu a chance de você ser falsificado quanto a seu alvo de telnet host. Você teria a sua senha falsificada mas não o pw do root. Dá um tempo. Isso é 2005 – Temos o ssh, que se usado corretamente é seguro. Se utilizado indevidamente nada disso de 1989 vai fazer nenhuma de diferença. – Bob

# 8: Ative um banner de aviso

Defina um banner de aviso, atualizando sshd_config com a seguinte linha:

Banner /etc/issue

Arquivo de exemplo /etc/issue:

----------------------------------------------------------------------------------------------
You are accessing a XYZ Government (XYZG) Information System (IS) that is provided for authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
+ The XYZG routinely intercepts and monitors communications on this IS for purposes including, but not limited to,
penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM),
law enforcement (LE), and counterintelligence (CI) investigations.
+ At any time, the XYZG may inspect and seize data stored on this IS.
+ Communications using, or data stored on, this IS are not private, are subject to routine monitoring,
interception, and search, and may be disclosed or used for any XYZG authorized purpose.
+ This IS includes security measures (e.g., authentication and access controls) to protect XYZG interests--not
for your personal benefit or privacy.
+ Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching
or monitoring of the content of privileged communications, or work product, related to personal representation
or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
----------------------------------------------------------------------------------------------

Acima está o exemplo padrão. Consulte a sua equipe jurídica para os detalhes sobre os termos de uso.

# 9: Porta 22 no ssh do firewall

Você precisa ativar a porta 22 no ssh do firewall, atualizando as configurações de firewall iptables ou pf. Normalmente, o servidor OpenSSH só deve aceitar conexões da sua LAN ou de outros sites WAN remotos.

Configuração do Netfilter (iptables)

Atualize Update  /etc/sysconfig/iptables (RedHat e friends  de arquivo específico) para aceitar conexão apenas de 192.168.1.0/24 e 202.54.1.5/29. Digite:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -s 202.54.1.5/29 -m state --state NEW -p tcp --dport 22 -j ACCEPT

Se você tiver dual stacked sshd com o IPv6, edite /etc/sysconfig/ip6tables (arquivo específico para RedHat e derivados). Digite:

 -A RH-Firewall-1-INPUT -s ipv6network::/ipv6mask -m tcp -p tcp --dport 22 -j ACCEPT

Substitua ipv6network::/ipv6maskcom intervalos de IPv6 reais.

Configuração do Firewall * BSD PF

Se você estiver usando firewall PF, atualize update /etc/pf.conf da seguinte forma:

Port 300
ListenAddress 192.168.1.5
ListenAddress 202.54.1.5

#10: Mude a porta SSH e o limite de binding de IP

Por padrão, o SSH ouve todas as interfaces disponíveis e os endereços de IP no sistema. Limite a porta ssh e o binding e altere a porta ssh (por padrão, scripts de força bruta só tentam se conectar à porta # 22). Para ligar a 192.168.1.5 e 202.54.1.5 IPs e para a porta 300, adicione ou corrija a seguinte linha:

Port 300
ListenAddress 192.168.1.5
ListenAddress 202.54.1.5

Uma abordagem melhor para usar scripts de abordagens proativas, como fail2ban ou denyhosts.

#11: Use senhas SSH fortes e passphrase

Nunca é demais falar o quão importante é a utilização de senhas de usuários fortes e passphrase para suas chaves. O ataque de força bruta funciona porque você utiliza de senhas baseadas no dicionário. Você pode forçar os usuários a não utilizarem senhas que possam ser quebradas com um “ataque de dicionário” e usar o john the ripper para descobrir passwords fracos já existentes. Aqui está um exemplo de gerador de senhas aleatórias (coloque no seu ~/.bashrc):

genpasswd() {
	local l=$1
       	[ "$l" == "" ] && l=20
      	tr -dc A-Za-z0-9_ < /dev/urandom | head -c ${l} | xargs
}

Execute:

genpasswd 16

Output:

uw8CnDVMwC6vOKgW

Na segunda parte, apresentarei as 10 práticas restantes.

***

Texto original disponível em http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html