ここ近年、WEBサービスへのサイバー攻撃による、個人情報などの情報漏洩事件が後を絶ちません。攻撃の多くは、アプリケーションやサーバの脆弱性を利用したものです。当然セキュリティ対策が必要になるのですが、対策方法は山のようにあり、どこから手をつけたらよいか迷ってしまいますね。そこで今回は、WEBサービスでよく使われている Linuxサーバのセキュリティ対策をまとめてみました。
タックス（Pax版）のライセンス：CC 表示 - 継承 3.0 非移植
IPA 安全なウェブサイトの作り方
どのセキュリティ対策から手をつければよいのかが、一番の悩みどころかと思いますが、IPAが公開している「安全なウェブサイトの作り方」の中に「ウェブサーバに関する対策」がありますので、まずはここから始めるのがよいかと思います。
IPAが公開している資料や注意喚起の内容は、過去の裁判で「専門家として当然はたすべき責務」の基準と判断されたことからも、事実上、国のセキュリティガイドラインとも考えられます。
（参考記事）SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記
「ウェブサーバに関する対策」は以下の５つです。かなり基本的な内容になっています。
・OSやソフトウェアの脆弱性情報を継続的に入手し、脆弱性への対処を行う
・ウェブサーバをリモート操作する際の認証方法として、パスワード認証以外の方法を 検討する
・パスワード認証を利用する場合は、十分に複雑な文字列を設定する
・不要なサービスやアカウントを停止または削除する
・公開を想定していないファイルを、ウェブ公開用のディレクトリ以下に置かないIPA 安全なウェブサイトの作り方（改訂第7版）より引用
続いて、これら対策の具体的な設定や、運用方法を考えてみたいと思います。（各設定例はCentOS7のものになります）
OSやソフトウェアの脆弱性情報を継続的に入手し、脆弱性への対処を行う
具体的には、OSやミドルウェアへのセキュリティパッチの適用が主になります。基本的かつ重要なセキュリティ対策ですが、サービスの停止や、パッチの検証が必要な場合もあるため、簡単なようで実は難しいのが、この脆弱性への対処です。
対策方法は標題の通りです。脆弱性情報収集の担当者を決め、プロジェクトの利害関係者と、以下のような取り決めをしておくとよいでしょう。
□セキュリティパッチ適用の実施基準
例：IPAの重要なセキュリティ情報一覧で「緊急」の対策
□セキュリティパッチの実施タイミング
例：プロジェクトリーダーの○○さんと都度相談
決めることは他にも色々ありますが（作業費はどうするとか、パッチの検証はどうするとか）脆弱性情報を継続的に入手し、問題があればアクションを起こせる「体制」ができていればOKです。
ウェブサーバをリモート操作する際の認証方法として、パスワード認証以外の方法を検討する
パスワード認証以外の方法については、IPAから具体的な方法が示されています。
より高い安全性を確保するための方法として、暗号技術に基づく公開鍵認証等の利用を検討することをお勧めします。
IPA 安全なウェブサイトの作り方（改訂第7版）より引用
SSH公開鍵認証の設定
Linuxサーバでは、SSHの公開鍵認証を利用するのが一般的です。SSHの公開鍵認証の設定は手順が多いため、ややこしく思えますが、クライアントPCでSSH公開鍵を生成して、その鍵をサーバに登録するだけです。
以下設定手順です。
接続元のクライアントPCで、SSH鍵ペアを生成します。
（略）
Enter file in which to save the key (/Users/test-user/.ssh/id_rsa): ＜空エンター＞
Enter passphrase (empty for no passphrase): ＜パスフレーズ＞
Enter same passphrase again: ＜パスフレーズ＞
（略）
ホーム直下に「.ssh/」ディレクトリが作成され、その下にSSHの秘密鍵と公開鍵が作成されます。
id_rsa・・・・・秘密鍵
id_rsa.pub・・・公開鍵
SSHの公開鍵を、リモート操作するサーバに送信します。（送信方法はなんでもかまいません）
ここでは例としてリモート接続用のユーザは「test-admin」としています。
リモート操作するサーバにログインします。
ホーム直下に「.ssh/」ディレクトリを作成し、パーミッションを適切に設定します。
$ chmod 700 .ssh/
クライアントPCで生成した公開鍵「id_rsa.pub」を、認証済鍵ファイル「authorized_keys」に登録し、パーミッションを適切に設定します。
$ chmod 600 .ssh/authorized_keys
以上で、SSHの公開鍵認証設定完了です。
SSH公開鍵認証の接続確認
設定が終わったら、SSH公開鍵認証で接続できることを確認します。パスフレーズの入力が求められ、ログインできればOKです。
Enter passphrase for key '/Users/test-user/.ssh/id_rsa': ＜パスフレーズ＞
接続できることが確認できたら、サーバに送信した公開鍵ファイル「id_rsa.pub」は削除しておきましょう。
SSHパスワード認証の禁止設定
最後に、SSHログインでのパスワード認証を禁止にしておきます。
vim /etc/ssh/sshd_config
↓
PasswordAuthentication no
sshd を再起動
パスワード認証を利用する場合は、十分に複雑な文字列を設定する
パスワード認証を利用する場合は、十分に複雑な文字列を設定することを確実にするため、パスワードポリシーを設定しておきましょう。
パスワードポリシーの設定
以下の設定は、パスワードが「８文字以上」かつ「大文字・小文字・数字・記号」がそれぞれ１文字以上含まれていることが条件になります。
vim /etc/security/pwquality.conf
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
minlen
パスワードの最低文字数
dcredit
パスワードに必要な「数字」の数（マイナス値で指定）
ucredit
パスワードに必要な「大文字」の数（マイナス値で指定）
lcredit
パスワードに必要な「小文字」の数（マイナス値で指定）
ocredit
パスワードに必要な「記号」の数（マイナス値で指定）
pam_pwquality の注意点
pwquality.conf の各パラメータのデフォルト値は以下の通りです。（CentOS7では pam_pwquality が pam_cracklib の代わりになっています）
# dcredit = 1
# ucredit = 1
# lcredit = 1
# ocredit = 1
実にややこしい仕様なのですが「dcredit」「ucredit」「lcredit」「ocredit」が 0以上もしくは0の場合、実際の minlen の値は「minlen - dcredit - ucredit - lcredit - ocredit」になります。
例えば「minlen = 8」のみを設定した場合、実際の minlen の値は「8 - 1 - 1 - 1 -１= 4」となってしまいます。これを 0以下の値(マイナス値)で指定すると、単純に必要な文字数として指定できますので、「dcredit」「ucredit」「lcredit」「ocredit」の値は、必ず 0以下もしくは0を設定しておきましょう。詳しくは「man pam_pwquality」をご確認ください。
不要なサービスやアカウントを停止または削除する
不要なサービスをインストールしない
サーバOSのインストール時の、ソフトウェアの選択で「最小限のインストール」を選択し、OSのインストール後に、必要なソフトウェアのみを yum などでインストールするようにします。
レンタルサーバやクラウドサービスの場合は、導入時に最小構成のものを選択し「ps aux」コマンドで、稼働しているサービスを確認し、必要のないものは停止しておきましょう。
不要なアカウントを削除する
従業員の退職や、協力会社の変更により、不要なアカウントが残ってしまうことがあります。アカウントの作成と削除の手続きを定め、「誰がどのアカウントを使っているか」を一覧表などで管理しておくことが重要です。また、定期的に「/etc/passwd」を確認し、不要なアカウントがないか確認しましょう。
公開を想定していないファイルを、ウェブ公開用のディレクトリ以下に置かない
ありえない事だと思いたいのですが、ウェブ公開用のディレクトリ以下に、個人情報や機密情報を置いてしまい、情報漏洩してしまう事故がしばしば発生しています。過去には、東京証券取引所が上場企業に対して、公開用のディレクトリの運用状況を調査することもありました。
（参考記事）東証が上場企業Webサイトの運用体制を調査、未公開情報の管理徹底を求める
公開用のディレクトリの書込み制限
技術的な対策としては、公開用のディレクトリへのアップロード(書込み)は、特定の管理ユーザのみに制限することが上げられます。
アクセス権の設定例
chmod 705 /var/www/html
WordPressなどのCMSを使っている場合、上記のアクセス権ではCMSから画像のアップロードなどが出来なくなってしまいますので、CMSが書込むディレクトリのオーナーを、WEBサーバの実行ユーザ(apacheなど)に変更しておきます。
chmod -R 705 /var/www/html/wp-content/uploads
他の技術的な対策として、ホスト型IDSのTripwireなどで、ウェブ公開用のディレクトリの状態をチェックしておくのも一案かと思います。
アップロード作業の２重チェック
アップロード作業を管理ユーザのみに制限したとしても、人が作業する以上は、どうしても間違えは発生してしまいます。アップロード前のレビューや、２重チェックなどの運用面の対策も必要です。
２重チェックというと難しく感じますが、例えば隣の席の人に「今からWEBサーバにファイルをアップロードするので、間違いがないか見ててね」とお願いするだけでも、１人で作業するよりも間違いが発生する可能性をぐっと減らせます。
終わりに
基本的なセキュリティ対策５つでしたが、運用体制に依存する面も多く、確実に行うのはなかなか大変かもしれません。「当たり前のことを当たり前にやり続ける」ことは一番難しく一番大切だと言われますが、セキュリティ対策にもあてはまりますね。
コメント