Posted by kenppx on August 29, 2013 at 3:47pm
いつもお世話になっております。
この数日にロリポップで起きた、WordPressに対する大規模なサイト改ざん騒動を見ていて不安になったのですが、皆さんはdrupalでサイトを運営する上でどのようなセキュリティー対策を実施していますか？
今回はWordPressが狙われましたが、この騒動を見ていると決して他人ごとでは無いと思いました…。
ファイルのパーミッション設定や、インストール後に行ったほうが良い対策、
イザという時の為のバックアップの方法など皆さんと情報共有が出来ればと思います。
Comments
production環境ではstableではないcontr
とかですね。
パーミッションについては、Drupalの場合は標準の状態から変更しなければ問題はないかとは思います。
自分でコードを書く人向けのセキュリティ関係の情報はPro Drupal developmentの"Writing Secure Code"の章にわかりやすくまとまっています。
大変参考になります
blauerbergさん
大変参考になります、ご回答ありがとうございます。
ファイルのパーミッションに関してなのですが、drupal7をインストールした状態で
Security Reviewというモジュールを導入してみました。
https://drupal.org/project/security_review
このモジュールはセキュリティ上の問題点を指摘してくれるモジュールのようです。
その結果、Some files and directories in your install are writable by the server.
という項目が問題点として検出されて、大量のファイルのパーミッションが不適切だと列挙されて
しまいました。
やはり、インストール時そのままでは何か設定上問題が有るのでしょうか？
確認してみました。 Drupalのコードをそのまま展開する
確認してみました。
Drupalのコードをそのまま展開すると、多くのファイルのパーミッションは644になっています。
つまり、
という状態です。Security Reviewの実行結果を見ると、とにかくW属性がついているファイルがあれば
警告が出るようです。
ただし、前述したように書き込みがでいるのはファイルのオーナーのみですので、余程セキュリティレベルの高いサイトを運用していない限り、特に気にするレベルではないかなーと思います。
Drupalのファイルパーミッションについては、 https://drupal.org/node/244924 にまとまっているので、一度目を通すと良いと思います。
参考になります。
概要として、
"基本的にfilesディレクトリ以外へはGroupに書き込み権限を与えない"
というのが、リンク先ドキュメントの方針のようです。
マルチサイトを構築した場合、作業が煩雑になるのでシェルスクリプトで処理しようとしていています。
一度試してみたいですね。
コメント欄にも改良版がおいてあります。
https://drupal.org/node/244924#comment-7478980
MinnPost/drupal-permissions · GitHub
https://github.com/MinnPost/drupal-permissions
ロリポップ事件の詳細な調査はでていませんが、
いろいろな方の推察を読むとサーバー設定・管理の問題が大きかったようですね。
さくらインターネット社長田中さんの記事が非常にわかりやすいまとめになっています。
共用サーバにおけるSymlink Attacksによる攻撃とその対策について - さくらインターネット創業日記
http://tanaka.sakura.ad.jp/2013/09/symlink-attack.html
ところで、この騒ぎの中で「共用サーバは危ない」「AWSやさくらのVPSへ移行しよう」という意見を見受けますが、これは多くのケースにおいては間違った対応です。共用サーバを提供する多くの事業者においては、知られた脆弱性に対して迅速に対応されていますし、逆にセキュリティ対策ができない状況でAWSやVPSのような素のサーバを使うことは非常に危険です。しっかりとサーバ管理の出来るケースに限って、AWSやVPSなどを活用すべきだと思います。とありますが、改めて、自前でOSを管理する大変さを思い知ります。
blauerberg さんの提案に追加して行きますと
サイトの状態 ページで設定ファイルが保護されているかどうかのチェックは必須です。
admin/reports/status
ファイルアップロードにFTPは使わないこと。
FTPはPWや送信内容が平文でそのまま流れますので、危険です。SFTPかFTPSを使いましょう。
ブルートフォースを防ぐにはいろいろモジュールも出ていますので、利用するのも一手。
Login Security | drupal.org
https://drupal.org/project/login_security
管理できなくなったDrupalサイトを静的HTMLとしてアーカイブする
https://groups.drupal.org/node/305973
可能であればサイトをSSL化する。
WAFを利用する。
設定が少し難しいですが、サーバー側で提供されているなら利用すべき。
最近のレンタルサーバーではメニューに入っていることは多いです。
など、まだまだ有ると思いますので、みなさん追記していってください。
いつも勉強になります！
qchanさん
AWSやVPSを中途半端な知識で使うのが一番危険ですよね…。私もそう思います。
私には自信がありません…。
サイトの状態 ページで設定ファイルが保護されているかどうかのチェックは必須です。
admin/reports/status→私はコレはOKです。必ずチェックしています。
ファイルアップロードにFTPは使わないこと。
SFTPかFTPSを使いましょう。→SFTPにしています。
ブルートフォースを防ぐにはいろいろモジュールも出ていますので、利用するのも一手。
Login Security→試してみます！
Drupalサイトを静的HTMLとしてアーカイブする→これは大切ですね！今後やってみます。
可能であればサイトをSSL化する。→勉強してみます。
WAFを利用する→導入してみました。ただ、たまに誤検知をするのが悩みの種です…。
運用上、問題の無いサイトについては積極的に導入していこうと思います。
ロリポップ！から報告が出ました。
第三者によるユーザーサイトの改ざん被害に関するご報告 / 新着情報 / お知らせ - レンタルサーバーならロリポップ！
http://lolipop.jp/info/news/4149/
■原因
・改ざんの原因
簡単インストールを利用して設置された WordPress においてインストールが完了していない WordPress が狙われ、WordPress の管理者権限を第三者に取得されたことで、サーバー上にサーバー構成上の不備を悪用するスクリプトが設置されました。また、wp-config.php のパーミッションが 644 だったことを利用して、設置されたスクリプトによりデータベースの接続情報の取得がおこなわれ、データベース上のデータの書き換えが可能な状態となっておりました。
・改ざんが拡大した原因
サーバー側のディレクトリパーミッションが不適切だったことと、FollowSymLinks の設定を有効にできる状態であったため、同一サーバー上のユーザー領域を辿り、他のユーザー様の wp-config.php の内容を参照し、データベースの更新を実行することで改ざんの被害が拡大しました。
Drupal用の簡単インストールを各社に入れてもらいたいと思っているのですが、
いろいろ対策が必要なのですね。
さくらインターネットの共用サーバーで、.htaccessをカスタマイズしないとDrupalが動かないのも
このFollowSymLinks対策だったようです。
近々、解決されてそのまま動くようになるとのことなのでアップデートも楽になります。
少し前になりますが、Drupal 勉強会＠さっぽろ[1]
少し前になりますが、Drupal 勉強会＠さっぽろ[1] で、セキュア運用をテーマにした話をしました。
入門レベルを想定しているのであまり目新しい情報はないかもしれませんが、
一応、資料を貼っておきます。
http://www.slideshare.net/blauerberg/drupal-35592153