ServerMan@VPSでのOpenSSH設定

やっぱしリモートでマシン管理の起点はSSHでFAだろ、つーことで今回はOpenSSHの設定について。(CentOSのSSHサーバがOpenSSHなのでOpenSSHの設定について書く)



SSHはリモートにあるUnix系マシンへの安全なログイン方法としてのデファクトスタンダードであるが、デファクトスタンダードなだけに、攻撃者に狙われる確率も高い。

例えば以下は /var/log/secure* を invalid で grep した結果の一部だが、oracle や test, admin, mysql など、ありがちなアカウントに対してアタックが仕掛けられていることがわかる。このサーバは 4/15 午後から運用しているのだが、1日もたたずに最初のアタックを仕掛けられているわけだ。

root@bangasa# grep invalid /var/log/secure* |head
/var/log/secure.1:Apr 16 01:38:14 bangasa sshd[19718]: input_userauth_request: invalid user oracle
/var/log/secure.1:Apr 16 01:38:14 bangasa sshd[19807]: input_userauth_request: invalid user test
/var/log/secure.1:Apr 17 06:29:04 bangasa sshd[55285]: input_userauth_request: invalid user admin
/var/log/secure.1:Apr 17 06:29:06 bangasa sshd[56731]: input_userauth_request: invalid user administrator
/var/log/secure.1:Apr 17 06:29:09 bangasa sshd[57212]: input_userauth_request: invalid user oracle
/var/log/secure.1:Apr 17 06:29:12 bangasa sshd[58426]: input_userauth_request: invalid user mysql
/var/log/secure.1:Apr 17 06:29:17 bangasa sshd[59334]: input_userauth_request: invalid user backup
/var/log/secure.1:Apr 17 06:29:19 bangasa sshd[60798]: input_userauth_request: invalid user ftpuser
/var/log/secure.1:Apr 17 06:29:22 bangasa sshd[60972]: input_userauth_request: invalid user test

調べたことはないが、おそらく「有名なアカウント名に対してアカウント名と同じ文字列をパスワードとしてログインを試みる」といった単純なアタックを数打ちゃ当たるで仕掛けているのだろう。ちなみにこのサーバには、 4/15以降、本日までに約3000回程度のアタックを受けたログが残っている。

root@bangasa# grep invalid /var/log/secure* |wc -l
3041

こういった SSH サービスへの攻撃に対する対策を幾つか挙げておく。それぞれ長所と短所があるので、運用するシステムの要件と照らし合わせて、最適な組み合わせで対策をしておくことをおすすめする。

対策A. SSHサービスの待受port番号を変える

• 長所: 変更や運用の手間に対して効果が高い
• 短所: 本質的な対策ではない。
• 解説: 大抵の攻撃ツールは22番ポートだけをスキャンしていると思われる(根拠レス)。ポート番号を変更しているようなサーバに時間をかけるよりも、他を狙った方が効果的だからだ。したがってとりあえず SSH サービスのポート番号を変えてしまうのが、手間もかからず効果が高いと思われる。ただし、これは本質的な対策ではない。ポートスキャンされれば SSH 待受ポートは簡単にバレてしまうので、万が一攻撃者があなたのサーバに狙いを定めている場合はほとんど意味がないからだ。この対策はあくまで一時しのぎと認識するべきであり、場合によっては「ユーザに不便を強いる割に意味のない対策」と評価されることも覚悟しておこう。(例えば、あなたが仕事としてアタック対策を提案する必要がある場合、このような安易な対策を提案するのはおすすめできない)
• 変更方法: OpenSSH の場合、 /etc/ssh/sshd_config の Port の値を 22 以外に変更する。

対策B. パスワード認証を禁止する

• 長所: パスワード認証を破ろうとするアタックは完全に防御できる
• 短所: ユーザがSSHの公開鍵認証について知っている必要がある
• 解説: パスワード認証自体受け付けなくなるので、パスワード認証を利用するアタックは完全に防御できる。ただし、ユーザが SSH の公開鍵認証について知っている必要がある。某 Open Source Software プロジェクト支援サービスのように SSH アクセスを公開鍵認証でのみ受け付けるサービスは現実に存在するし、もともと公開鍵認証のほうがパスワード認証よりもセキュアだと言われているので、アタック対策ととして正しい方向と言えるだろう。
• 変更方法: /etc/ssh/sshd_config で、PasswordAuthentication と ChallengeResponseAuthentication の両方を no に設定する。当然だが、実際にこの設定を行う前には、自分自身が公開鍵認証でログインできていることを確認してから設定しよう。

対策C. sshサービスを利用可能なIPアドレスを限定する

• 長所: 信頼できるマシンからのみアクセス可能とすれば、対策Bよりも安全な対策になりうる。
• 短所: 万が一許可していない場所からSSHしなければならない場合に困る。アクセス元のIPアドレスが変動する場合は、そもそも許可するIPアドレスを限定する事が難しい。
• 解説: アクセス元として固定IPアドレスを確保でき、かつそこ以外からのアクセスは行わないという運用が可能であれば、これは強力な対策となる。また、対策Bと同時に実施も可能なので、対策Bに加えて設定する事で、さらに安全性を高めることができる。許可すべきIPアドレスが変動する場合、この対策をとることは困難だが、例えば自分の契約しているISPが自分に割り当てるIPアドレス帯を調べることができるのなら、それを設定しておいて損はないだろう。ただし、急に別の場所(学校や職場)からアクセスしたい、という場合であってもログインできないことになるので、注意が必要だ。
• 変更方法: /etc/hosts.allow, /etc/hosts.deny を編集する。詳細は hosts_access(5)を参照されたい。または、iptables で同様の制限をかける。

以上、ざっと思いつく対策を挙げてみた。おすすめは対策B, 可能なら対策Cも実施するのがよい。今すぐ対策したいが、何らかの理由により対策B, C の導入が難しい or 導入したいが自信がない、といった場合にはツナギとして対策Aの実施を検討するのも良いだろう。