Detalhes

Categoria: Como fazer segurança

Atualização: Quinta, 12 Março 2009 21:58

Autor: vovó Vicki

Acessos: 16322

Bloqueando acessos com hosts.allow e hosts.deny

Se os usuários da shell SSH não forem muito numerosos, então os arquivos /etc/hosts.allow e /etc/hosts.deny foram feitos sob medida. O hosts.allow guarda os serviços e os IPs liberados; o hosts.deny indica os serviços e os IPs bloqueados. Antes de ativar um serviço, o inetd confere as proibições no hosts.deny. Logo em seguida, ele confere as permissões no hosts.allow e, caso ele encontre algum dos IPs bloqueados na lista dos permitidos, ele os libera novamente. Isto significa que o hosts.allow tem prioridade. Daí, a solução é um abraço...

Temos o serviço in.primed (o sshd camuflado) disponível na porta 54321. Se quisermos que apenas o host 192.168.1.10 tenha acesso ao serviço, podemos usar o apenas hosts.deny ou o hosts.deny associado ao hosts.allow. Se você quiser usar apenas o hosts.deny, acrescente ao arquivo /etc/hosts.deny

...
in.primed: ALL EXCEPT 192.168.1.10

ou, caso você tenha vários usuários na mesma faixa de IP

...
in.primd: ALL EXCEPT 192.168.1.

Outra forma é negar o acesso a todos os IPs em hosts.deny e depois autorizar um ou mais IPs em hosts.allow. Neste caso, insira a linha indicada abaixo em hosts.deny:

...
in.primed: ALL

e, em hosts.allow

...
in.primed: 192.168.1.10

No meu caso, esta última solução funcionou como uma luva. Tenho poucos usuários do SSH, todos com IPs fixos, o que facilita a configuração. É lógico que, se eu estiver no Japão, tentando me conectar através de um IP nipônico, vou quebrar a cara. Vou ter que fazer uma ligação internacional para o meu gerente de webservices para que ele libere temporariamente determinado IP ou faixa de IP. Acontece que esta é uma possibilidade muito remota e, provavelmente, para você também. Neste caso, esta solução é aceitável.

Moral da história

Meu log está enxutinho, ou seja, os kiddies deram sossego. Mas isto não quer dizer que a solução que encontrei seja adequada para as suas necessidades. Nas minhas pesquisas sobre o assunto, esbarrei uma porção de vezes em sugestões para se usar iptables. São outras soluções para o mesmo problema em condições diferentes. Se este este for o seu caso, dê uma olhada em A Cure for the Common SSH Login Attack da Soloport Corporation, na pettingres.org em sshblack e no excelente artigo do Rainer Wichmann, Defending against brute force ssh attacks