web-dev-qa-db-ja.com

/etc/hosts.denyがsshログに到達する前にこれを傍受するべきではありませんか?

私はubuntu10.04.04サーバーで/etc/hosts.denyとufwの組み合わせを使用しています。ほとんどの日、.com.cnドメイン内のマシンからのssh試行の失敗が次のように報告されています。

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キーを移動したので、それらは関係しません)。

これは意図したとおりに機能していますか?

編集: James Sneeringerは私にログをもっと詳しく調べるように促しました、そしておそらくこれが起こっている理由がわかります。 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-> nameルックアップについて確信が持てない場合、注意を怠ってそのホストをブロックしないことを意味します。そうですか?

3
Michael H.

これは、libwrapに直接リンクされているため、sshdに期待されます。したがって、sshdは実際にはホストチェックを実行するものです。 sshdが呼び出される前に接続をブロックする場合は、接続の試行を処理するために、接続をsshdに渡す前にその前に何かを配置する必要があります。いくつかのオプションは次のとおりです。

  • Inetd(またはxinetd)でsshdを実行します。これにより、tcpdの引数としてsshdを呼び出すことができ、tcpdが実際のホストチェックを実行することになります。

  • /etc/hosts.allowおよび/etc/hosts.denyと同様の機能を提供するonly_fromおよびno_accessサービスオプションがあるxinetdでsshdを実行します。

ただし、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アドレスによるアクセスの制御に制限されます。これは必ずしも悪いことではありませんが、達成しようとしていることには役立ちません。

4