Securing OpenSSH

<TableOfContents: execution failed “]] を参照してください。 (ログも参照)>>

OpenSSH (または Secure SHell) は telnet プロトコルに代わるリモートアクセスのデファクトスタンダードとなりました。 SSH は telnet のようなプロトコルを冗長にしてしまいましたが、 その理由の大部分は接続が暗号化され、パスワードが平文で送られなくなり、 すべての人に見えるようになったという事実によるものです。

しかし、ssh のデフォルトのインストールは完璧ではなく、ssh サーバーを実行するときに、インストールを劇的に強化できるいくつかの簡単な手順があります。

Use Strong Passwords/Usernames

ssh を実行して外部に公開している場合、最初に気づくことの 1 つは、ユーザー名/パスワードを推測しようとするハッカーによるログを取得することでしょう。 通常、ハッカーはポート22（sshがリッスンするデフォルトのポート）をスキャンして、sshが動作しているマシンを見つけ、それに対してブルートフォース攻撃を試みます。 強力なパスワードがあれば、うまくいけば、どんな攻撃でもログに記録され、成功する前に気づくことができる。

うまくいけば、すでに強力なパスワードを使用していますが、そうでない場合は、強力なパスワードを選択するようにしてください。

• 最低 8 文字
• 大文字と小文字の混合
• 文字と数字の混合
• 英数字以外の文字 (! ” £ $ % ^ などの特殊文字)

強いパスワードは ssh 固有ではなく、システムセキュリティのあらゆる側面に影響を与えるのである。 パスワードに関する詳細な情報は、CentOSのドキュメントに記載されています。

http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html

ユーザーが弱いパスワードを選択するのを絶対に防ぐことができない場合、ユーザー アカウントにランダムに生成されたユーザー名または推測が困難なユーザー名を使用することを検討してください。 悪者がユーザー名を推測できなければ、パスワードをブルート フォースで入力することはできません。 ただし、これはあくまでも曖昧さによるセキュリティであり、ユーザーアカウントから送信されるメールなどからユーザー名の情報が漏れることに注意しましょう。

Disable Root Logins

SSH サーバーの設定は /etc/ssh/sshd_config ファイルに格納されています。 ルートログインを無効にするには、次のエントリがあることを確認します。

# Prevent root logins:PermitRootLogin no

そして sshd サービスを再起動します。

service sshd restart 

root アクセスが必要な場合は、通常のユーザとしてログインし、su コマンドを使用します。

Limit User Logins

SSH ログインは、リモートアクセスを必要とする特定のユーザーのみに制限することができます。 システム上に多くのユーザアカウントがある場合、リモートアクセスを本当に必要なユーザのみに制限することは理にかなっており、弱いパスワードを持つカジュアルなユーザの影響を制限することができます。 AllowUsers 行を追加し、その後にスペースで区切ったユーザ名のリストを /etc/ssh/sshd_config に追加します。

AllowUsers alice bob

そして sshd サービスを再起動します。

Disable Protocol 1

SSH には、プロトコル 1 とプロトコル 2 の 2 種類のプロトコルが使用されます。 古い方のプロトコル 1 は安全性に欠けるので、特に必要であるとわかっている場合を除き、無効にすべきです。 etc/ssh/sshd_config ファイルで次の行を探し、コメントを解除して、図のように修正します。

# Protocol 2,1Protocol 2 

そして sshd サービスを再起動します。

Use a Non-Standard Port

デフォルトでは、ssh はポート 22 で着信接続をリッスンします。 ハッカーがあなたのマシンで ssh が実行されていると判断するためには、おそらく 22 番ポートをスキャンしてこれを判断することになるでしょう。 効果的な方法は、標準以外のポートで ssh を実行することです。 未使用のポートであれば何でも構いませんが、1024以上のポートが望ましいです。 8080がHTTPの代替ポートとしてよく知られているように、多くの人が2222を代替ポートとして選んでいます(覚えやすいので)。 なぜなら、22番ポートをスキャンするハッカーは、念のため2222番ポートもスキャンしている可能性が高いからだ。 既知のサービスに使用されていない、ランダムな高いポートを選択する方が良いだろう。 この変更を行うには、以下のような行を /etc/ssh/sshd_config ファイルに追加します。

# Run ssh on a non-standard port:Port 2345 #Change me

そして sshd サービスを再起動します。 その後、ルータのポートフォワーディングとファイアウォールのルールに必要な変更を加えるのを忘れないでください。 例えば、CentOS 7 (およびそれ以降) では、firewalld の ssh サービスを変更するには、/etc/firewalld/ にそのサービスファイルの複製を作成し、そのポート行を変更することができます。

$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml

それから /etc/firewalld/services/ssh-custom.xml のポート行を変更して、ポートが ssh 設定ファイル内のものと同じになるようにします。

<port protocol="tcp" port="2345"/>

最後に、ssh サービスを削除して ssh-custom サービスを追加し、Firewalld をリロードして変更を反映させます。

$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload

または、CentOS 6 では、新しい ssh ポートを開くために iptable ルールを追加してください。

$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT

古いポートも同様に閉じることを忘れないでください。

Centos 6 以上では、selinux も更新し、選択したポートを正しくラベル付けする必要があります。 例えば

$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me 

ssh はもはや標準ポートで接続をリッスンしないので、クライアントにどのポートで接続するかを指示する必要があります。 コマンドラインから ssh クライアントを使用する場合、-p スイッチを使用してポートを指定することができます。

$ ssh -p 2345 myserver

または、konqueror で fish プロトコルを使用している場合は、たとえば次のように指定します。

fish://myserver:2345/remote/dir

接続するたびにポートを指定するのは面倒だと思う方は、ローカルの ~/.ssh/config ファイルにポートを指定するエントリを追加するだけです。

 # Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345 

そして、そのファイルです。 ~/.ssh/config には、以下のパーミッションが必要です。

$ chmod 600 ~/.ssh/config 

Filter SSH at the Firewall

ある IP アドレスからのリモートアクセスのみが必要な場合 (たとえば仕事場から自宅サーバへ)、ルータまたは iptables でファイアウォールルールを追加し、ポート 22 へのアクセスをその特定の IP アドレスのみに制限して、ファイアウォールで接続をフィルタすることを考えてみてください。 例えば、iptablesでは以下のようなルールで実現できます（CentOS 6）。

$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT

または firwalld (CentOS 7) の rich-rules を使用して、特定のポートのみを許可する ssh を使用することができます。 送信元アドレスは、単一のアドレスまたはビットマスクを持つベースアドレスです。

SSH は TCP ラッパーもネイティブにサポートしており、ssh サービスへのアクセスは hosts.allow と hosts.deny を使って同様に制御することができます。

送信元 IP アドレスを制限できず、ssh ポートをグローバルに開く必要がある場合でも、iptables は同じ IP アドレスから繰り返しログインしようとする試みを記録しブロックすることにより、ブルートフォース攻撃の防止に役立ちます。 例えば、iptables

の場合、最初のルールは、recentモジュールを使用してポート22にアクセスしようとする新しい試行のIPアドレスを記録します。 2番目のルールは、そのIPアドレスが過去60秒以内に4回以上接続を試みていないかどうかをチェックし、そうでなければパケットを受け付けます。 このルールは、入力チェーンにDROPというデフォルトのポリシーが必要であることに注意してください。

ssh を非標準のポートで実行している場合、適切なポートに変更することを忘れないでください。 可能であれば、ファイアウォールでのフィルタリングは、sshサーバへのアクセスを確保するための非常に効果的な方法です。

FirewallDサービスを使用しているシステム（CentOS 7以上）では、firewall-cmdを使用してください。

最初のコマンドは、より寛容なサービスのルールを削除し、2番目のコマンドは、1分間に4つの接続のみを受け入れ、すべての接続を記録するルールをインストールします。

認証にパブリック/プライベート キーを使用する

認証に暗号化キーを使用すると、主に 2 つの利点があります。 まず、公開鍵/秘密鍵を使用すると、（パスワード保護で鍵を暗号化しない限り）パスワードを入力する必要がなくなるので便利です。 第二に、公開鍵/秘密鍵のペア認証がサーバー上で設定されると、パスワード認証を完全に無効にできます。つまり、認証された鍵がなければアクセスできないので、パスワードクラッキングの試みはもう必要ありません。

公開鍵/秘密鍵ペアを作成し、ssh サーバーで使用するためにそれらをインストールするのは比較的簡単なプロセスです。

まず、サーバーへの接続に使用するクライアントで公開/秘密鍵ペアを作成します (接続する各クライアント マシンでこの作業を行う必要があります)。

$ ssh-keygen -t rsa

接続するたびにパスフレーズ (基本的に、指定した公開鍵を解除するためのパスワード) を要求されたくない場合は、鍵ペアの作成時にパスフレーズを要求されたら Enter キーを押すだけです。 鍵の作成時にパスフレーズ保護暗号を付加するかどうかは、お客様の判断にお任せします。 鍵のパスフレーズ保護を行わない場合、ローカルマシンにアクセスできる人は、自動的にリモートサーバーにsshでアクセスできるようになります。 また、ローカルマシンの root は鍵にアクセスすることができますが、root を信用できない (または root が危険にさらされる) 場合は、本当に困ったことになると思われます。 鍵を暗号化すると、ssh サーバにパスワードを入力する必要がなくなる代わりに、 鍵を使用するためのパスフレーズを入力する必要がなくなるという犠牲を払って、さらにセキュリティを 強化することができます。 これは、ssh_agent プログラムを使用することにより、さらに簡素化されます。

$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa 

公開鍵 (id_rsa.pub) をサーバーにコピーし、authorized_keys list にインストールします。

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

注意: 公開鍵をインポートしたら、サーバーから削除することができます。

そして最後にサーバーにファイルのパーミッションを設定します。

$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys 

上記のパーミッションは、/etc/ssh/sshd_config で StrictModes が yes に設定されている場合 (デフォルト) に必要とされます。

正しい SELinux コンテキストが設定されていることを確認します。

$ restorecon -Rv ~/.ssh 

これで、サーバーにログインする際に、パスワードの入力を要求されなくなりました (鍵ペアを作成した際にパスフレーズを入力した場合を除く)。 デフォルトでは、ssh は最初に鍵を使った認証を試みます。 鍵が見つからない場合、または認証に失敗した場合、ssh は従来のパスワード認証に戻 ります。

公開/秘密鍵ペアを使用してサーバーに正常にログインできることを確認したら、次の設定を /etc/ssh/sshd_config ファイルに追加して、パスワード認証を完全に無効にすることができます。

# Disable password authentication forcing use of keysPasswordAuthentication no

Frequently Asked Question (FAQ)

Q: CentOS は OpenSSH のバージョン X を使用しており、最新バージョンはバージョン Y となっています。 バージョン X には、重大なセキュリティ欠陥が含まれていますが、アップグレードすべきでしょうか?

A: いいえ。上流ベンダーは、最新のリリースから現在の配布バージョンにセキュリティパッチをバックポートするポリシーを持っています。 お使いのCentOSディストリビューションに最新のアップデートが適用されている限り、完全にパッチが適用されています。 バックポートセキュリティパッチの詳細については、こちらをご覧ください。

http://www.redhat.com/advice/speaks_backport.html

Q: NFS でユーザーのホームディレクトリを共有しているマシン間で、パスワードなしの鍵ベースの認証を行うにはどうしたらよいですか?

A: SElinux は NFS で共有されているディレクトリやファイルへの root アクセスをデフォルトでブロックしており、そのため sshd は ~/.ssh にあるユーザの鍵ファイルを読み込むことができません。 スーパーユーザで以下のコマンドを実行し、use_nfs_home_dirsの設定を変更することで、アクセスを可能にすることができます。

setsebool -P use_nfs_home_dirs 1 

https://www.centos.org/forums/viewtopic.php?t=49194

Links

http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html

http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html