翻訳・改善にご協力ください

ドキュメンテーションを現在英語版から翻訳中です。どなたでもご協力いただけます。

誤字や間違った情報にお気づきの方は、各記事の下にあるフィードバックセクションからお知らせください。

WordPress の安全性を高める

トピック

WordPress ではセキュリティを非常に重要なものと考えています。しかし、他のどんなシステムでも同様ですが、基本的なセキュリティ対策がなされていない場合には問題が発生する可能性はあります。このページでは、よくある脆弱性について、そして WordPress を安全に保つためにできることを紹介します。

このページはセキュリティに対する心配を一掃するその場限りの応急措置とは違います。特定のセキュリティ問題や不明な点を抱えている場合は、コンピューターセキュリティの知識を十分に持っている信頼のおける人ときちんと話し合うべきです。

セキュリティとは

基本的には、セキュリティとは「完璧に安全なシステム」のことではありません。そのようなものは実用的ではないか、見つけたり運用したりするのは不可能といえるでしょう。セキュアなサーバーは、サーバー管理者のコントロールのもとに、リソースのプライバシー・整合性・可用性を保護するものです。

信頼できる Web ホスティングには、以下が含まれます。

  1. セキュリティに関してあなたが気になっている点や、ホスティングにどのようなセキュリティ機能やプロセスがあるのかをためらいなく話し合ってくれる。
  2. 最新安定版のサーバーソフトウェアを使っている。
  3. 確実なバックアップとリカバリ方法を提供している。

保護すべきソフトウェアとデータを確定することで、どのようなセキュリティが必要なのかを決定しましょう。以下のガイドがその助けになるはずです。

トップ ↑

セキュリティの考え方

システムの各方面のセキュリティを考える時に、いくつかの一般的な考え方を頭に置いておきましょう。

  1. アクセスの制限: 悪意ある人物が利用可能な潜在的な入り口を効果的に減らすための賢い選択をする。
  2. 抑制: インストールの弱点を悪意ある人物が発見した場合に備え、システム内部で実行できる損害を最小化するようにシステムを設定する。
  3. 知識: バックアップを取り、定期的に WordPress インストールの状態を知り、WordPress インストールを理解しやすいよう、行った変更をドキュメント化しておく。
  4. 信頼できるソース: テーマやプラグインを信頼できないソースから入手するのはやめて、WordPress.org 公式レポジトリまたはよく知られた信頼のおける企業などからのダウンロードに制限する。それ以外から入手することで問題が発生することがある。

トップ ↑

ローカルコンピュータの脆弱性

WordPress に投稿するコンピュータが、スパイウェア、マルウェア、ウイルスに感染していないことを確かめましょう。またアプリケーションが安全で安定したバージョンであることを確かめましょう。例えばキーロガーが仕込まれていた場合、WordPress や Web サーバーのセキュリティ対策は全く意味をなさなくなってしまいます。

OS とソフトウェアは常に最新版にしておきましょう。特に、セキュリティ脆弱性からパソコンを保護するために Web ブラウザを最新版に更新しておくことが大事です。信頼できないサイトを閲覧しているなら、NoScript などのツールを使うかブラウザの JavaScript/Flash/Java を無効にすることをおすすめします。

トップ ↑

WordPress パッケージの脆弱性

多くの現代的なソフトウェアパッケージと同様、WordPress は新しいセキュリティ関連の問題が発生すると定期的に更新されています。ソフトウェアのセキュリティを改善していくのは常に進行形の懸案事項であり、このため、最新バージョンの WordPress に常に更新すべきです。WordPress の旧バージョンはセキュリティアップデートに対してメンテナンスされていません。

トップ ↑

WordPress の更新

メイン記事: WordPress のアップグレード

最新版の WordPress は、WordPress 公式サイト (https://wordpress.org/) または日本語版公式サイト (https://ja.wordpress.org/) から入手できます。公式リリースはこれ以外のサイトからはリリースされません。wordpress.org ドメイン以外からは絶対に WordPress をインストール・アップグレードしないでください。

バージョン3.7で WordPress は自動アップデート機能を導入しました。最新の状態に維持するためにこの機能を利用してください。また、WordPress のダッシュボードには更新に関する情報が表示されます。更新を行いセキュリティを保つため、ダッシュボード内の情報または WordPress 開発者ブログを読むようにしてください。

脆弱性が発見された問題に対処する新しい WordPress のバージョンがリリースされるほとんどの場合には、この脆弱性を悪用するための情報が公開されています。これにより古いバージョンではより攻撃を受けやすくなるため、WordPress を常に最新の状態にする主な理由の一つといえます。

複数の WordPress をインストールする管理者は、管理を容易にするために Subversion などのバージョン管理ソフトを使用することを検討してください。

トップ ↑

セキュリティ上の問題の報告

WordPress 上にセキュリティ関連の問題を見つけたと思ったら、これを報告することで協力できます。セキュリティ上の問題を報告する方法については、セキュリティ FAQ をごらんください。

バグだと思うものを見つけた場合は、報告してください。詳しくはバグの報告をごらんください。脆弱性、または脆弱性に繋がるバグを見つけたという場合もあります。

トップ ↑

サーバーの脆弱性

WordPress を実行しているウェブサーバー、WordPress データのあるデータベース、プラグインで使用される PHP およびその他のスクリプト・プログラム言語、またはヘルパーアプリケーションに脆弱性があるかもしれません。ウェブサーバー、データベース、スクリプトインタプリタが安全で安定したバージョンであることを確かめるか、これらの作業を行う信頼できるホスティング業者を使用しているか確かめてください。

共有サーバー (同じサーバー上に他の人のサイトがホスティングされている環境) で誰かのサイトが感染すると、たとえこのガイドに従っていた場合でもあなたのサイトも感染してしまう可能性があります。使用している[用語集 #Hosting_provider Web ホスト] がどのようなセキュリティ対策を行っているか確かめておいてください。

トップ ↑

ネットワークの脆弱性

ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。無線であれ有線であれ、インターネットカフェの暗号化されていない接続でパスワードを送信するのは「信頼できるネットワーク」上の作業とは言えません。

ホスティング業者は自身のネットワークがハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊 (中間者攻撃など) の発生を許してしまうかもしれません。

トップ ↑

パスワード

セキュリティ向上のための習慣を守れば、脆弱性の多くは回避可能です。ここで重要な点のひとつに、パスワードがあります。

パスワードの目的は、ブルートフォース攻撃/Brute_Force_Attacks (総当たり攻撃) の成功を難しくすることです。インターネット上には多くのパスワード自動生成ツールが公開されており、安全なパスワードを作成するために利用できます。

さらに、WordPress にはパスワードの強度メーターが含まれています。パスワードを変更する際にはこれを活用し、強度が十分かどうか確認しましょう。

パスワードを選ぶ際には、以下のことは避けましょう。

  • 自分の本名、ユーザー名、会社名、サイト名などの羅列。
  • (あらゆる言語で) 辞書にある単語。
  • 短いパスワード。
  • 数字のみ、またはアルファベットのみのパスワード。両方を混ぜるのが効果的です。

強力なパスワードは、ブログのコンテンツを守るためだけに必要なのではありません。あなたの管理アカウントにアクセスできるようになったハッカーは、サーバー全体を危険にさらす可能性がある悪意のあるスクリプトをインストールできてしまいます。

強力なパスワードの使用に加えて、追加のセキュリティ対策として2段階認証 /two-step authentication を有効にすることは良いアイデアです。

トップ ↑

FTP

お使いのサーバーに接続するときは、(ホスティングが対応していれば) 暗号化された SFTP を使用すべきです。ホスティングが対応しているか不明な場合は、ホスティングのサポートにお問い合わせください。

SFTP の使い方は FTP と同じですが、手元の端末とサーバーとの間で送受信するパスワードやその他のデータが暗号化される点が異なります。パスワードが平文で送られることは無いため、攻撃者に不正使用されることはありません。

トップ ↑

ファイルパーミッション

WordPress の便利な機能のいくつかは、ウェブサーバーがファイルに書き込みできることに基づいています。しかし、アプリケーションがファイルに書き込み権限を持つことは危険です。公開環境では特に危険です。

セキュリティの観点からベストなのは、ファイルパーミッション (書き込み権限) を可能な限り制限して、書き込み権限が必要な時のみ制限を緩くする、あるいは画像アップロード等の目的のために制限の緩い特別のフォルダを作成することです。

考えられるパーミッションスキーマの1つを示します。

すべてのファイルの所有者はあなたのユーザーアカウントで、あなたのみ書き込み可能。WordPress が書き込み権限を必要とするファイルは、ウェブサーバーで使用するユーザーアカウントのグループ所有。/ ルート WordPress ディレクトリ。すべてのファイルを自分のユーザーアカウントのみから書き込み可能にするべきです。例外は .htaccess: で、自動的にリライトルールを生成させたいときはこれを WordPress によって書き込み可能にします。/wp-admin/ WordPress 管理領域: すべてのファイルを自分のユーザーアカウントのみから書き込み可能にする。/wp-includes/ WordPress アプリケーションロジックの大部分。すべてのファイルを自分のユーザーアカウントのみから書き込み可能にする。/wp-images/ WordPress が使用する画像ファイル。すべてのファイルを自分のユーザーアカウントと Web サーバーのプロセスのみから書き込み可能にする。

/wp-content/ 内には以下が含まれる。/wp-content/ ユーザー提供の様々なコンテンツ。開発者 /en により、すべて (所有者、グループ、全体) 書き込み可能に意図されている。/wp-content/themes/ テーマファイル。ビルトインテーマエディタを使用する場合は、Web サーバーのプロセスに書き込み権限を与える。ビルトインテーマエディタを使用しない場合は、自分のユーザーアカウントのみから書き込み可能にする。/wp-content/plugins/ プラグインファイル。すべてのファイルを自分のユーザーアカウントのみから書き込み可能にする。

/wp-content/ の他のディレクトリは、プラグイン/テーマの要求次第で異なり、パーミッションは様々である。

トップ ↑

ファイルパーミッションの変更

サーバーへのシェルアクセスが可能な場合は、以下のコマンドでファイルパーミッションを再帰的に変更できます。

ディレクトリ: 

find [your path here] -type d -exec chmod 755 {} \;

ファイル: 

find [your path here] -type f -exec chmod 644 {} \;

/wp-includes/ にはこのコマンドを使用してはいけません。

トップ ↑

自動アップグレードに関して

WordPress に自動アップグレードを適用する際、すべてのファイル操作は Web サーバーユーザーではなくファイル所有者であるユーザーとして行われます。すべてのファイルは 0644 に、すべてのディレクトリは 0755 に設定され、ユーザーのみ書き込み可能で、(Web サーバーを含む) 誰にでも閲覧可能な状態になります。

トップ ↑

データベースのセキュリティ

同一サーバー上で複数のブログを実行している場合は、別々のデータベースに格納し、異なるユーザーが管理するのが賢明でしょう。最初の WordPress のインストールで実行するのがもっとも達成しやすいでしょう。これは、抑制戦略です。もし侵略者が WordPress インストールのいずれかのクラッキングに成功した場合、他のブログを改変するのが難しくなるでしょう。

MySQL をあなたが管理している場合は、MySQL 設定を理解しているか確認し、(外部 TCP 接続を受け入れるなどの)不要な機能が無効になっていることを確認してください。MySQL の優れた入門については、Secure MySQL Database Design をごらんください。

トップ ↑

データベースユーザーの権限を制限する

ブログやコメントの投稿・メディアファイルのアップロード・新規 WordPress ユーザーの作成・プラグインのインストールといった通常の WordPress 運用においては、MySQL データベースユーザーはデータの読み書き (SELECT / INSERT / UPDATE / DELETE) が可能な権限のみが必要となります。

つまり、DROP / ALTER / GRANT といったデータベース構造の変更や管理のための他の権限は必要ないということです。こういった権限を取り消すことによって抑制 (封じ込め) 対策を改善することができます。注: 一部のプラグイン、テーマ、WordPress コアのメジャーバージョン更新においてはテーブルの追加やスキーマの変更などといったデータベース構造の変更が必要になる場合があります。こういった場合にはプラグインのインストールやソフトウェア更新の際に、一時的にデータベースユーザーへの権限許可を行う必要があります。警告: WordPress のバージョンアップでデータベーススキーマが変わる場合、これらの権限なしに更新しようとすれば、問題を起こす虞があります。よって、これらの権限を外すことはお奨めできません。セキュリティのために是非ともこれらの権限を外す必要があると思われる場合は、信頼性の高いバックアップ計画を策定し実施することが必要不可欠です。バックアップ計画には、定期的にデータベース全体のバックアップをとること、バックアップした内容を検証すること、そして、容易にバックアップから復元できるようにすることが必要です。データベースのアップグレードに失敗しても、バックアップからデータベースを復元し、必要な権限を付与し、そして WordPress にデータベース更新をやり直させることで、たいてい解決します。データベースは、バックアップから復元することで旧バージョンに戻るので、WordPress の管理画面で旧バージョンが検出され、必要な SQL コマンドをまた実行させることができます。WordPress のバージョンアップのたびにスキーマが変更されるわけではありません。スキーマが変わるのはたいていメジャーバージョンアップ (例えば 3.7 から 3.8 へ) のときであり、マイナーバージョンアップ (例えば 3.8 から 3.8.1 へ) では変わらないことが一般的です。いずれにしても、定期的にバックアップをとり続けることです。

トップ ↑

wp-admin を安全にする

サーバーサイドで /wp-admin/ にパスワードを追加する (Basic 認証など) と、ブログ管理領域、ログイン画面、ファイルに二層の保護を追加できます。これにより攻撃者またはボットは、実際の管理ファイルではなく二層目の保護レイヤーを攻撃する必要が発生します。ほとんどの場合、WordPress への攻撃は、悪意あるソフトウェアボットが自動実行しています。しかし、wp-admin/ ディレクトリを保護することで WordPress の機能の一部が使えなくなってしまう場合があります。例えば wp-admin/admin-ajax.php に含まれる Ajax ハンドラなどです。適切な wp-admin/ ディレクトリのパスワード保護方法については、リソースセクションをご覧ください。

WordPress ブログへのよくある攻撃は、以下の2つのカテゴリに分類されます。

  1. 特定の脆弱性を食い物にする特別な細工をした HTTP 要求をサーバーに送信する。古い/更新されていないプラグインやソフトウェアへの攻撃も含む。
  2. 「ブルートフォース」パスワード推測により、ブログへアクセスを試みる。

重要なファイルに第二層の保護レイヤーを追加することで、攻撃者は、/wp-admin/ に攻撃を仕掛ける前に、これを突破する必要があります。この保護は、Basic HTTP 認証を使用し、パスワードは平文で、暗号化されずにネットワークに流れます。この保護の主な利点は、サーバーファイルへのアクセスを拒否し、あなたのブログへの攻撃が /wp-admin/ の入り口に達する前に警告が発生することです。

“二層式”パスワード保護の完全な実装をするには、/wp-admin/ ディレクトリに HTTPS SSL 暗号化接続し、すべての通信と重要なデータを暗号化することが必要です。管理画面での SSL 通信 をご覧ください。

トップ ↑

wp-includes を安全にする

通常スクリプトがユーザーによってアクセスされることを想定されていない部分で次のレイヤーの保護を追加することができます。ひとつの方法は、.htaccess で mod_rewrite を使っているスクリプトをブロックするというやり方です。注: 下記のコードが WordPress によって上書きされないようにするためには、.htaccess ファイルの # BEGIN WordPress と # END WordPress タグの外側に書き込んでください。この2つのタグの間に何かを書き込むと WordPress が上書きしてしまうことがあります。 

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
# BEGIN WordPress

RewriteRule ^wp-includes/[^/]+\.php$ – [F,L] によって ms-files.php ファイルが画像を生成するのを防ぐため、この設定はマルチサイトでは使えません。このコードを消すことで動作はしますが、セキュリティ強度は弱まります。

トップ ↑

wp-config.php を安全にする

wp-config.php ファイルを、WordPress をインストールした階層の一つ上に移動することができます。つまり、ウェブスペースのルートに WordPress をインストールしている場合、wp-config.php をウェブルートの外側に格納できるということです。注意:wp-config.php の移動は最低限の利点しかなく、しかも注意深く実行しなければ深刻な脆弱性を引き起こすと主張する人もいます。この意見に反対する人もいます。

wp-config.php は、WordPress (wp-includes のある場所) インストールの一つ上のディレクトリに格納できることに注意してください。また、wp-config.phpの読み込み権限があるのはあなた (とウェブサーバー) のみであることを確認してください。(大抵の場合、ファイルパーミッションは400、もしくは440です)

.htaccess を使えるサーバーであれば、下記設定を追加した .htaccess ファイルをサーバーのトップに設置することにより、アクセスを拒否することができます。 

<files wp-config.php>
order allow,deny
deny from all
</files>

トップ ↑

ファイル編集の無効化

WordPressダッシュボードでは、デフォルトで管理者がPHPファイル (例えばプラグインとテーマファイル) を編集することが可能です。攻撃者がログインできると、多くの場合まずこの機能を利用してコードを実行します。WordPressダッシュボードには、編集を無効にする定数があります。wp-config.phpに次の行を追加することで、すべてのユーザの「edit_themes」、「edit_plugins」および「edit_files」を無効にします。 

define('DISALLOW_FILE_EDIT', true);

これにより、アップロードされる悪意があるファイルからあなたのサイトまで攻撃者を防ぎませんが、いくつかの攻撃を止めるかもしれません。

トップ ↑

プラグイン

まず、利用しているプラグインが常に最新に更新されていることを確かめてください。また、使用していないプラグインはシステムから削除するようにしてください。

トップ ↑

ファイアウォール

サイトのファイアウォールとして動作するプラグインやサービスがたくさんあります。その一部では .htaccess ファイルを修正し、WordPress に処理が渡る前に Apache のレベルでアクセスを制限することによって機能するものもあります。良い例は iThemes Security や All in One WP Security です。WordFence のように WordPress レベルで動作するファイアウォールプラグインもあり、WordPress がロードされる際、完全に機能する前に攻撃をフィルタリングします。

プラグインのほかには Web サーバーに WAF (Web ファイアウォール) をインストールして WordPress で処理される前にコンテンツをフィルタリングできます。もっとも人気のあるオープンソース WAF は ModSecurity です。

またファイアウォールは、ホスティングの提供会社とインターネットの間にも追加できます(中間でのセキュリティ)。ファイアウォールを通過する DNS レコードを変更します。すべてのトラフィックがサイト到達前にファイアウォールによりフィルタリングされます。CloudFlare、Sucuri、Incapsula など、いくつかの会社がこのようなサービスを提供しています。

トップ ↑

書き込み権限を必要とするプラグイン

プラグインが WordPress ファイルとディレクトリに書き込み権限を要求する場合は、コードを読んで合法であることを確認するか、信頼できる人にチェックしてもらうようにしてください。チェックする場所は、サポートフォーラムと IRC チャンネルです。

トップ ↑

コードを実行するプラグイン

上述のとおり、WordPress を強固にする目的には、攻撃が成功した場合の被害を抑えることが含まれます。データベースのエントリから任意の PHP やコード実行を許可するプラグインは、攻撃が成功した場合の被害が非常に大きくなります。

これらのプラグインを避ける方法の一つは、関数を呼び出すカスタムページテンプレートを使用することです。このセキュリティの一部は、WordPress でファイル編集を無効にする場合にのみ有効です。

トップ ↑

隠蔽によるセキュリティ

Security through obscurity (隠蔽によるセキュリティ向上) は、典型的には、基本戦略として健全でない、と考えられています。しかし、WordPress のある領域では、情報を隠蔽することがセキュリティの助けになることがあるかもしれません。

  1. 管理者アカウント名の変更: 管理者アカウントを作るとき、簡単に推測されるような言葉 (admin とか webmaster) をユーザー名に使うのは避けましょう。真っ先に攻撃対象にされてしまいます。既存の WordPress インストールでは、MySQL コマンドラインクライアントで UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin'; のようなコマンドを入力するか、phpMyAdmin のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
  2. table_prefix の変更: 多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの wp_ であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができるかもしれません。

トップ ↑

データバックアップ

データを定期的にバックアップしましょう。MySQL データベース (詳しくはデータベースのバックアップを参照) もです。データ保全は、信頼できるバックアップに大切です。バックアップを暗号化し、各バックアップファイルに独立した MD5 ハッシュをつけ、バックアップを読み込み専用メディアに保存すると、データが改変されていないという信頼性が高まります。

健全なバックアップ戦略は、WordPress インストール全体も含む (WordPress コアファイルとデータベースを含む) 定期的なバックアップを信頼できる場所に保管することです。毎週バックアップするサイトを考えてみましょう。5月1日に感染し、5月12日まで発見されなかった場合、サイトオーナーは、サイトを再構築する助けとなる感染前のバックアップを持っており、感染後のバックアップはサイトが感染した方法を決定する助けとなるでしょう。

トップ ↑

ログの取得

調査のためにログを使えば、サイトについて理解するために非常に役に立ちます。ログから、誰がいつ何をしたのかが分かります。残念なことにログからはどのユーザーがログインしたのかという情報は知ることができませんが、IP や時刻などを特定できます。さらに、アタックをすべてチェックできます。クロスサイトスクリプティング (XSS)、リモートファイルインクルージョン (RFI)、ローカルファイルインクルージョン (LFI)、そしてディレクトリトラバーサルの試行といったことです。ブルートフォース攻撃があればその履歴も見られるでしょう。

ログを見るのに抵抗がなくなったら、いつテーマ・プラグインエディタが使われたのか、いつウィジェットが更新されたのか、いつ投稿や固定ページが追加されたのかといったことも見えるようになってきます。ログには、Web サーバー上での犯人調査のために必要なキー要素が全て含まれています。

セキュリティの観点から見た場合に、Web サーバーで使っておきたい大事なオープンソースソリューションが2つあります。これはセキュリティへのレイヤー的アプローチです。

OSSEC はあらゆる -NIX ディストリビューションと Windows 上で利用でき、正しい設定を行えば非常にパワフルです。すべてのログを関連付け、凝集させるというのがその考え方です。すべての access_logs と error_logs を収集するように必ず設定し、サーバーアカウント上に複数のサイトがある場合はそれらも忘れないようにしましょう。また、効果的なログを取るにはデフォルトで含まれるノイズをきちんとフィルタリングするのも忘れないようにしてください。

トップ ↑

モニタリング

ときには、予防策が十分でなく、攻撃されることがあります。このため、侵入の検知や監視が非常に重要です。すぐに対策を取ることができ、何が起きたかを把握し、サイトを元に回復することができるでしょう。

トップ ↑

ログの監視

root アクセス権限のある専用サーバーや VPS では、何が起こっているかを監視するために簡単に設定を変更できる権限があります。OSSEC を使えばこの設定がやりやすくなるでしょう。詳しくは OSSEC for Website Security – Part I を参照してください。

トップ ↑

ファイル変更の監視

攻撃が発生すると、必ず痕跡が残ります。ログまたはファイルシステム (新規ファイル、変更されたファイル等) です。上で推奨している OSSEC を使用している場合、ファイルを監視し、変更があると通知します。ファイル変更の通知には、オープンソース Tripwire を使用することもできます。

トップ ↑

目標

ファイルシステムトラッキングの目標は次のとおりです。

  • 変更、追加されたファイルのモニタリング
  • 変更、追加のログ取得
  • 詳細な変更お取得機能
  • 自動警告

トップ ↑

一般的なアプローチ

管理者は次のような一般的な技術を使用してファイルシステムをモニタリングできます。

  • システムユーティリティ
  • バージョン制御
  • OSやカーネルレベルのモニタリング

トップ ↑

特定のツール

ファイルシステムモニタリングのオプションは次のとおりです。

  • diff – サイトのクリーンなテストコピーをビルドし、本番環境と比較する
  • Git – ソースコード管理
  • inotify と incron – OS カーネルレベルのファイルモニタリングサービス。ファイルシステムイベントに対してコマンドを実行
  • Watcher – Python inotify ライブラリ
  • OSSEC – Open Source Host-based Intrusion Detection System。ログ解析、ファイルの一貫性検証、ポリシーのモニタリング、rootkit 検知、リアルタイム警告と動的対応

トップ ↑

注意点

ファイルベースモニタリング戦略を採用する場合、以下を含む多くの注意点があります。

モニタリング用スクリプトやサービスを root で実行する

攻撃者によるファイルシステムモニタリングソリューションの無効化や変更が困難になります。

計画したメンテナンスやアップグレード時にモニタリングを無効化する

サイトの定期的なメンテナンスを実行する際に、不要な警告を回避できます。

実行可能なファイルタイプのみモニタリングする

.php ファイルなど実行可能なファイルタイプのみをモニタリングすれば十分安全です。非実行可能ファイルをフィルタリングから除外すれば、不要なログ出力や警告を削減できます。

厳格なファイルシステムパーミッションを使用する

ファイルパーミッションと所有権について参照してください。一般に、可能な限り execute 権限と write 権限は避けてください。

トップ ↑

悪意ある変更に備えて外部からウェブサーバーを監視する

攻撃者がサイトを書き換えたり、マルウェアを追加しようとするとき、ウェブベースの改善検知ソリューションを使用して、これらの変更を検知することができます。今日ではさまざまな形式のサービスがあります。検索エンジンで「Web Malware Detection Remediation」または「マルウエア 検知 修正」を検索してください。多くのサービス提供会社がリストされます。

トップ ↑

リソース

トップ ↑

日本語

トップ ↑

英語

トップ ↑

参考

この記事は役に立ちましたか ? どうすればさらに改善できますか ?