Я использую комбинацию /etc/hosts.deny и ufw на моем сервере ubuntu 10.04.04. В большинстве случаев я вижу неудачные попытки ssh с компьютеров в домене .com.cn, о которых сообщается так:
Failed logins from:
112.114.63.139 (139.63.114.112.broad.km.yn.dynamic.163data.com.cn): 1 time
Однако в /etc/hosts.deny у меня есть такое правило:
ALL: .com.cn
Разве это не должно блокировать соединение еще до того, как оно попадет в ssh? Я протестировал его, заблокировав свой домашний компьютер, и он определенно отказывает мне в подключении сразу же, прежде чем я получаю приглашение на вход (и да, я убрал свои ключи ssh, чтобы они не участвовали).
Это работает как задумано?
Редактировать: Джеймс Снирингер побудил меня более внимательно изучить журналы, и, возможно, я понимаю, почему это происходит. Из 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
Это подразумевает, что если sshd не уверен в поиске IP-> имени, то он проявляет осторожность и не блокирует этот хост. Это правильно?
Это ожидается для sshd, поскольку он напрямую связан с libwrap, поэтому sshd фактически выполняет проверку хоста. Если вы хотите заблокировать соединение до вызова sshd, вам нужно поместить что-нибудь перед ним, чтобы обработать попытку соединения, прежде чем передавать его sshd. Вот пара вариантов:
Запустите sshd под inetd (или xinetd). Это позволит вам вызвать sshd в качестве аргумента tcpd, а tcpd - это то, что в конечном итоге выполняет фактическую проверку хоста.
Запустите sshd под xinetd, в котором only_from и no_access параметры службы, которые предоставляют функции, аналогичные /etc/hosts.allow и /etc/hosts.deny.
Однако справочная страница sshd не одобряет эти подходы:
-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.
Использование iptables или установка брандмауэра перед вашим сервером может показаться хорошей альтернативой, но большинство из них не выполняет никакого разрешения имен, поэтому вы ограничены контролем доступа по IP-адресу. Это не обязательно плохо, но это не помогает в том, чего вы пытаетесь достичь.