não deveria /etc/hosts.deny estar interceptando isso antes que ele atinja os logs ssh?

Question

Estou usando uma combinação de /etc/hosts.deny e ufw no meu servidor Ubuntu 10.04.04. Na maioria dos dias, vejo tentativas ssh com falha de máquinas no domínio .com.cn, relatadas da seguinte forma:

Failed logins from:
112.114.63.139 (139.63.114.112.broad.km.yn.dynamic.163data.com.cn): 1 time

No entanto, em /etc/hosts.deny, tenho esta regra:

ALL: .com.cn

Isso não deveria estar bloqueando a conexão antes mesmo de atingir o ssh? Eu testei isso via bloqueio de minha máquina doméstica, e certamente me nega uma conexão imediatamente antes de eu obter um prompt de login (e sim, eu mudei minhas chaves ssh para que eles não estejam envolvidos).

Isso está funcionando conforme o esperado?

Edit: James Sneeringer me levou a olhar mais de perto os logs, e talvez eu entenda por que isso está acontecendo. De auth.log:

Nov  5 09:38:40 mymachine sshd[22864]: warning: /etc/hosts.deny, line 21: can't verify hostname: getaddrinfo(139.63.114.112.broad.km.yn.dynamic.163data.com.cn, AF_INET) failed
Nov  5 09:38:44 mymachine sshd[22864]: reverse mapping checking getaddrinfo for 139.63.114.112.broad.km.yn.dynamic.163data.com.cn [112.114.63.139] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov  5 09:38:45 mymachine sshd[22864]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.114.63.139  user=root
Nov  5 09:38:47 mymachine sshd[22864]: Failed password for root from 112.114.63.139 port 37245 ssh2
Nov  5 09:38:47 mymachine sshd[22866]: Connection closed by 112.114.63.139

Isso implica para mim que, se o sshd não tiver certeza sobre a pesquisa de nome IP- >, ele erra ao lado do cuidado e não bloqueia esse host. Está certo?

    

Answer 1

Isso é esperado para o sshd porque está vinculado diretamente à libwrap, portanto, o sshd é, na verdade, o que realiza a verificação do host. Se você quiser bloquear a conexão antes que o sshd seja invocado, você precisará colocar algo na frente dele para lidar com a tentativa de conexão antes de passá-la para o sshd. Algumas opções seriam:

• Execute sshd em inetd (ou xinetd). Isso permitirá que você invoque o sshd como um argumento para o tcpd, e o tcpd é o que acaba executando a verificação real do host.

• Execute sshd sob xinetd, que possui only_from e no_access opções de serviço que fornecem funcionalidade semelhante a /etc/hosts.allow e /etc/hosts.deny.

A página de manual do sshd desencoraja essas abordagens, embora:

 -i      Specifies that sshd is being run from inetd(8).  sshd is normally
         not run from inetd because it needs to generate the server key
         before it can respond to the client, and this may take tens of
         seconds.  Clients would have to wait too long if the key was
         regenerated every time.  However, with small key sizes (e.g. 512)
         using sshd from inetd may be feasible.

Usar o iptables ou colocar um firewall na frente do seu servidor pode parecer uma boa alternativa, mas a maioria não executa nenhuma resolução de nome, então você está limitado a controlar o acesso por endereço IP. Isso não é necessariamente uma coisa ruim, mas não ajuda com o que você está tentando realizar.