サーバをセキュアにするために最低限やっておくべきOpenSSHの設定

SSHのブルートフォース攻撃(ユーザー名・パスワード総当り攻撃)が一般化してから
もう5年以上経つ気がしますが、
いまだに「アタックされて侵入された」という話を良く聞く気がします。
むしろ、サーバの知識もセキュリティの知識もないまま
Linuxサーバを管理することになった人が増えたためか、
被害者の数は増えてる気さえします。

本当はOS(ディストリビューション)の出荷時に
一番セキュアな設定になっていてくれるのが一番良いのですが、
利便性との兼ね合いのせいか、OSによっては必ずしもそうなっていない場合があります。
特に CentOS とか、CentOS とか、、、

ということで、今 Webサーバで一番良く使われているであろうCentOSを対象に、
最低限の設定を解説します。
対象とするCentOSのバージョンは最新の6.3ですが、5.xでも基本は同じです。

## 基本戦略

ブルートフォース攻撃にやられないために大切なことは
「簡単に推測出来るパスワードを使わない」なのですが、
ユーザがそんなこと聞いてくれるわけないですよね?w

ということで、

– そもそもパスワード認証は使わせない
– 代わりに公開鍵認証のみを許可する

というのが基本戦略になります。

## 変更すべき設定
具体的には、/etc/ssh/sshd_configの以下の部分を変更します。

### 公開鍵認証以外の認証の無効化
まずはパスワード認証を無効にします。
PasswordAuthentication, ChallengeResponseAuthentication の両方を
no にして下さい。
CentOS 6.3のデフォルトでは ChallengeResponseAuthentication は
no になっているはずですが、念の為チェックしましょう。

PasswordAuthentication no
ChallengeResponseAuthentication no

GSSAPI認証も、使っていないのであれば無効化します。
使っているかどうかわからない場合は無効化して構わないはずです。

GSSAPIAuthentication no

**[2014/6/14追記]** ChallengeResponseAuthenticationについての記事を書きました。

* [OpenSSH の ChallengeResponseAuthentication と PasswordAuthentication](http://lovepeers.org/2014/06/14/openssh-challengeresponseauthentication/)

### rootログインの無効化
本当はまずこれを真っ先に変えないといけないのですが…
CentOSのデフォルトでは、リモートから root でログインすることが可能です。
rootのパスワードが弱いとroot権限を取られてしまうので、すぐに

PermitRootLogin no

としましょう。

他のサーバから rootでログインしてバッチを走らせる場合など、
どうしても root でのログインを許可しなければならない場合は
PermitRootLogin の設定を without-password にします。
この場合、rootでログインするためにパスワード認証が使えなくなります。

PermitRootLogin without-password

### Port番号を22番以外にする
実はブルートフォース攻撃に一番効くのはこれだったりするのですが…

sshd が待ち受けるポートをデフォルトの22番以外にすると、
まずブルートフォース攻撃に狙われなくなります。

Port 9822

待ち受けポートが22番の時は /var/log/secure に

Sep 9 15:12:53 www10102ue sshd[514]: Invalid user cron from xxx.xxx.xxx.xxx

というログが大量に残っていると思いますが、
ポート番号を変えるだけでこれが面白いくらいピタッと止まります。

## 変更した設定の反映
設定を変更したら、忘れずに

# /sbin/service sshd restart

を実行して、変更を反映させておきましょう。

コンソールにアクセス出来ないサーバを管理している場合、
万が一設定に間違いがあって sshd の起動に失敗したらサーバにログイン出来なくなるので、
/sbin/service sshd restart を実行したターミナルからはログアウトせずに、
別のターミナルからログイン出来ることを確認しましょう
(万が一sshdが落ちても、ログインしているセッションは維持される)。

## 設定が変更されたことを確認する
念の為、設定の変更が効いていることを確認しておきます。

コマンドラインの ssh プログラムを使っている場合は、
-v オプションをつけてサーバにログインしてみます。

% ssh -p 9822 -v somehost.examples.com
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/koma2/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
……

というメッセージがダラダラと出るはずですが、

debug1: Authentications that can continue: publickey

という行の最後に “publickey” とだけ出れば設定は変更されています。
password や gssapi-keyex などが出る場合、
何か変更漏れがあるはずなので、再度設定を確認しましょう。