独立サイトのセキュリティ強化:ファイアウォール、ログイン制限、ファイル権限、マルウェアスキャン

独立サイトのハッキング被害の80%は5つのよくある入口から発生します。未更新のプラグイン、弱いパスワード、公開されたデータベースバックアップ、ファイルアップロードの回避、SSHパスワード総当たり攻撃です。強化に高価なセキュリティ製品は不要で、4つの手順で十分です。クラウドのセキュリティグループは...

独立站安全加固:四层防御与一条红线Site hardening: four layers of defense and one red line 被黑的站 80% 是弱口令和未更新插件,不是0day —— 加固先堵常见入口80% of breaches come from weak passwords and outdated plugins, not zero-days 层Layer 关键动作Key action 量化门槛Quantitative bar 1 防火墙1. Firewall 云安全组 + WAF · 只开80/443/SSHSG + WAF, open only 80/443/SSH SSH 限固定IP,禁密码登录SSH whitelist, key-only login 2 登录限制2. Login lock 失败5次锁30分钟 · 改默认路径Lock after 5 fails, rename admin path 2FA必须开,密码≥16位2FA on, 16-char min password 3 文件权限3. File perms 目录755 文件644 · wp-config只读dirs 755, files 644, wp-config 400 uploads 禁PHP执行No PHP execution in uploads 4 恶意扫描4. Malware scan 每周扫核心文件 · 比对哈希Weekly core-file hash check 插件主题7天内必须更新Patch plugins within 7 days 红线:被黑后第一动作不是查后门,是断开数据库写入并从最近干净备份恢复Red line: after a breach, restore from clean backup before hunting backdoors 在线清理会漏掉藏在cron和数据库里的webshell,恢复比清理更彻底Live cleanup misses DB/cron webshells; restore beats cleaning 常见被黑入口排名Top breach vectors 1. 未更新插件/主题漏洞 2. wp-admin弱口令 3. 数据库备份文件暴露在web目录1. Outdated plugins 2. Weak wp-admin passwords 3. Exposed DB backups 4. 文件上传绕过 5. SSH端口暴露+密码爆破 —— 前五类占独立站被黑事件的80%以上4. Upload bypass 5. SSH brute force — top 5 cover 80%+ of breaches
独立サイトのセキュリティ強化4層:ファイアウォール、ログイン制限、ファイル権限、マルウェアスキャン

独立サイトのセキュリティ強化:ファイアウォール、ログイン制限、ファイル権限、マルウェアスキャン

結論から言うと:独立サイトのハッキング被害の80%は5つのよくある入口から発生します。未更新のプラグイン、弱いパスワード、公開されたデータベースバックアップ、ファイルアップロードの回避、SSHパスワード総当たり攻撃です。強化に高価なセキュリティ製品は不要で、4つの手順で十分です。クラウドのセキュリティグループは80/443とIP制限した22番ポートのみ開放、wp-adminは5回失敗で30分ロックし2FAを必須化、ディレクトリは755でファイルは644、uploadsはPHP実行を禁止、週に一度コアファイルのハッシュ照合を実行します。ハッキング後の最初の行動はオンラインでの駆除ではなく、直近のクリーンなバックアップからの復元です。

1. ファイアウォール:クラウドのセキュリティグループとWAFで、不要なポートをまず閉じる

ファイアウォールはサーバー内にインストールするソフトウェアだと思われがちですが、クラウドホストの独立サイトでは、第一の防御線はクラウド事業者のセキュリティグループです。セキュリティグループで3306、6379、9000などのポートがデフォルトで全開放されているのが最大のリスクです。データベースやRedisが直接インターネットに露出し、スキャナーは数分で突破できます。正しい方法は、セキュリティグループで80と443のみ許可し、22番ポートは自社の固定出口IPに制限することです。

第二の防御線はWAF(Webアプリケーションファイアウォール)です。Cloudflareの無料版で十分で、SQLインジェクション、XSS、一般的なスキャナーを自動的にブロックします。WAFのルールは厳しすぎると正常な訪問者を締め出してしまうので、まず記録のみのモードで3日間運用し、誤検知率が1%未満であることを確認してからブロックモードに切り替えます。

ポート/サービス 初期状態 強化後の状態 原因
80/443 0.0.0.0/0で開放 0.0.0.0/0で開放 インターネットからのアクセスが必須
22 SSH 0.0.0.0/0で開放 自社固定IPに制限、鍵認証に変更 パスワード総当たり攻撃の多発地帯
3306 MySQL 誤って開放されがち ローカル127.0.0.1のみ許可 絶対にインターネットに露出させない
6379 Redis 誤って開放されがち ローカルのみ許可、パスワード設定 未認証アクセスで公開鍵を書き込まれる
9000 PHP-FPM ローカルsocket ローカルsocketを維持し、TCPを開放しない インターネットからのアクセスは不要
8888/宝塔パネル 露出しがち IP制限+デフォルトポート変更 パネルは攻撃頻度の高い標的

事例:宝塔パネルを使ったWordPressサイトで、公開直後はセキュリティグループが全開放されており、3日後にサーバーのCPUが100%に達しました。ログインして確認すると3306番ポートが海外IPから総当たり攻撃を受け、MySQLログは接続失敗の記録で埋め尽くされていました。セキュリティグループを80/443と自社IPに制限した22番のみに変更すると、CPUは即座に5%まで低下しました。この事故は10分で防げますが、多くの人は公開時にセキュリティグループを確認しません。

WAFルールの設定方法は、問い合わせフォームのスパム対策と同じロジックです。まず記録して観察し、その後ブロックします。最初から疑わしいリクエストをすべて遮断してはいけません。

2. ログイン制限:ブルートフォースの入口を狭める

WordPressのwp-adminは、独立系サイトが最初に狙われる入口です。ユーザー名がadminのまま、パスワードが単純、ログイン画面が誰でもアクセスできる状態なら、スキャナーは数時間で辞書を回り切ります。逆説的ですが、ログイン制限のプラグインを1つ入れるほうが、どんなセキュリティスキャン製品を買うより効きます。ブルートフォースのほとんどは脆弱性の悪用まで届かず、ログイン画面で止まるからです。

ログイン制限の三点セット:5回失敗で30分ロック、デフォルトのログインURLを変更(/wp-adminをランダムな文字列に)、2FAを必須化。パスワードは16文字以上、パスワードマネージャーで生成し、単語+数字は使わない。SSHも同じで、パスワードログインを禁止し鍵のみ許可します。

設定項目 初期値 強化値 ツール/実装
ログイン失敗ロック 無制限 5回失敗で30分ロック Wordfenceまたは自作fail2ban
ログインURL /wp-admin /login-7f3kのようなランダム文字列 WPS Hide Loginプラグイン
二要素認証 なし TOTP 2FAを必須化 WordfenceまたはTwo Factor
パスワード長 6文字 16文字以上のランダム パスワードマネージャーで生成
SSH認証 パスワードログイン 鍵のみ許可、パスワード禁止 sshd_configでPasswordAuthentication noに変更
データベースユーザー rootでリモート接続 専用ユーザー、ローカル接続のみ MySQLで専用アカウントを作成

事例:海外向けSaaSサイトで、管理画面のログインURLを/secret-adminにし、2FAを有効化、5回失敗で30分ロック。ログ監視では毎週約2000回の海外IPからのログイン試行があり、すべてロックされて1件も成功していません。こうした試行に制限がなければ、平均的なパスワード強度で計算すると3か月以内に突破される確率は30%を超えます。

プラグイン選定と技術スタックの全体的な考え方はこちら环形山技術スタックの自社開発プラグイン4つ。

3. ファイル権限:アップロードされた悪意あるファイルを動かさない

ファイル権限は多くの人が見落とす層です。WordPressが侵害されると、攻撃者は通常wp-content/uploadsディレクトリにPHPウェブシェルを置きます。uploadsディレクトリでPHPの実行が許可されていれば、このウェブシェルは即座にサイト全体を掌握します。実行が禁止されていれば、アップロードされても動かず、攻撃者は手も足も出ません。

標準の権限は、ディレクトリ755、ファイル644、wp-config.phpは400(所有者のみ読み取り可)です。手間を惜しんで全部777にするのは、鍵をドアに掛けておくのと同じです。uploadsディレクトリにはnginxの設定でルールを追加し、.php、.phtml、.php5などの実行を禁止します。

道筋 権限 所有者 説明
サイトルート 755 www-data:www-data 777にしない
wp-config.php 400 root Webプロセスから読めない
wp-content/themes 755 www-data 自動更新に書き込み権限が必要
wp-content/uploads 755 www-data PHP実行を禁止
wp-content/plugins 755 www-data プラグイン更新に書き込みが必要
.gitディレクトリ Webに公開しない — 公開するとソースが漏れる

もう一つのよくある侵入経路は、データベースのバックアップファイルをwebディレクトリ直下に置いてしまうことです。多くのバックアッププラグインは.sql.gzをwp-content/backup/に保存するのがデフォルトで、攻撃者にスキャンされてそのままダウンロードされ、サイト全体のデータを奪われます。正しい運用は、バックアップファイルをwebルートの外に置くか、バックアップ完了後に自動でオブジェクトストレージへアップロードしてローカルコピーを削除することです。バックアップ戦略はこちらサイトのバックアップと復元演習。

4. 悪意あるスキャンとパッチ:週1回、7日以内に適用

悪意あるスキャンは、攻撃されてからやるものではありません。週に1回、コアファイルのハッシュを照合し、WordPressコアファイルが既知バージョンのハッシュと一致しなければ改ざんされた証拠です。プラグインとテーマの更新は7日以内に完了させてください。公開された脆弱性が自動スキャナに悪用されるまでの平均期間は14日なので、7日以内にパッチを当てれば大半の攻撃を回避できます。

スキャンツールは3種類あります。Wordfenceのようなプラグインスキャンは既知のwebshellシグネチャを検出できます。ClamAVはサーバー全体のウイルススキャンを実行します。サーバーログ分析は異常なアクセスパターンを発見できます。3つを組み合わせて使い、単一のツールですべてをカバーできるとは考えないでください。AIクローラーのログ分析の考え方はこちらAIクローラーログ分析。同じログ分析の手法で悪意あるスキャナも発見できます。

チェック項目 頻度 ツール 異常対応
コアファイルのハッシュ照合 毎週 Wordfence コア整合性 差分を検出したらクリーンな版から復元
プラグイン・テーマの更新 毎週月曜 WP管理画面+ログ 7日以内に更新を完了
webshellスキャン 毎週 ClamAVまたはWordfence 悪意あるファイルを隔離して削除
不審なログイン記録 毎日 fail2banログ 攻撃IPを自動ブロック
webディレクトリの最近更新ファイル 毎週 find -mtime -7 想定外の変更はすぐ調査
データベースの異常書き込み 毎週 wp_posts内のbase64コンテンツ 隠されたevalコードを除去

直感に反する注意点:攻撃された後、オンラインで駆除しようとしないでください。オンライン駆除の最大の問題は、データベースに隠れたwebshellやcronタスクを完全に除去できず、2週間後に再発することです。正しい手順は、サイトの外部サービスを停止し、直近のクリーンなバックアップから復元し、すべてのパスワードとキーを変更し、cronとデータベース内の残留物を調査してから再公開する、という流れです。攻撃後の完全な手順はこちらサイトがハッキングされた後のクリーンアップと再インデックス。

日次点検チェックリストはこちら公式サイト保守で毎月やる6つのこと。セキュリティ強化を組み込みましょう。アラートしきい値の設定方法はこちらサイト監視とアラート。

FAQ よくある質問

独立サイトが攻撃されたら、まず何をすべき?
オンラインで駆除しないでください。たいていは完全に除去できません。正しい順序は次のとおりです。第一に、すぐにサイトをメンテナンスモードに切り替えるかロードバランサから切り離し、悪用を止めます。第二に、直近のクリーンなバックアップからサイト全体のファイルとデータベースを復元します。第三に、すべてのパスワードを変更します。wp-admin、SSH、データベース、FTP、ホストパネル、すべてです。第四に、cronタスクとデータベースのwp_optionsテーブルに隠されたバックドアがないか確認します。第五に、クリーンであることを確認してから再公開し、Google Search Consoleで再審査を申請します。オンライン駆除は応急処置にしかならず、最終的な解決策にはなりません。
有料WAFを買うべき?Cloudflareの無料版で十分?
ほとんどのB2B自社サイトにとって、Cloudflareの無料版で十分です。基本的なSQLインジェクション、XSS、一般的なスキャナーからの攻撃の遮断、および全体のレート制限がすでに含まれています。有料のPro版で月20ドル払って追加されるマネージドWAFルールとBot管理は、明確な攻撃の証拠がない限り購入する必要はありません。そのお金はログイン制限とファイル権限に使ったほうがROIは高くなります。DDoSでサイトが落ちた経験がある、またはフォームのスパムが正常な問い合わせ数の10倍以上になった場合にのみ、有料WAFを検討してください。
WordPressプラグインはどのくらいの頻度で更新すべき?自動更新は安全?
セキュリティパッチは公開後7日以内に適用する必要があります。公開された脆弱性が自動スキャナーに悪用されるまでの平均期間は14日だからです。コアとセキュリティ系プラグインは自動更新を有効にしても問題ありませんが、機能系プラグインは慎重に。自動更新がテーマと競合して画面が真っ白になることがあります。推奨は、コア、セキュリティ、キャッシュ系プラグインは自動更新をオンにし、カスタム機能プラグインはまずステージング環境でテストしてから本番に反映する方法です。毎月第1月曜日に一括更新を実行し、更新前に自動バックアップを取ります。
wp-config.phpとuploadsディレクトリの権限はどう設定する?
wp-config.phpは400、所有者はrootに設定し、Webプロセスから読めないようにします。これでWebが侵害されてもデータベースのパスワードは盗まれません。ディレクトリは一律755、ファイルは一律644にし、手抜きで777にしないでください。uploadsディレクトリにはnginxまたはApacheの設定で.php、.phtml、.php5ファイルの実行を禁止するルールを追加します。これで攻撃者がwebshellをアップロードしても実行できません。権限設定後はWordPress管理画面を一通り操作し、画像アップロード、プラグイン更新、自動更新が正常に動くことを確認してください。権限が厳しすぎて業務に支障が出るのを防ぎます。
SSHポートはデフォルトの22から変更すべき?パスワードログインは残していい?
パスワードログインは必ず無効にし、鍵認証のみ許可してください。デフォルトポートの変更はスキャンの半分を防げますが、鍵認証の代わりにはなりません。正しい方法は、sshd_configでPasswordAuthentication no、PermitRootLogin no、PubkeyAuthentication yesを設定し、22番ポートを52022のような高位ポートに変更し、最後にクラウドのセキュリティグループでSSHポートを会社の固定出口IPに限定することです。鍵にはパスフレーズを設定し、パスワードマネージャーに保管してください。パスフレーズなしの秘密鍵をサーバーに置かないでください。
サイトが改ざんされたことにどう気づく?前兆はある?
よくある前兆は5つあります。Google Search Consoleのマルウェア警告、サーチコンソールに中国語のギャンブルやアダルトキーワードが大量に登録される、サーバーのCPUとトラフィックが突然上昇する、wp-adminに見知らぬIPからのログインがある、ページのソースコードに不審なiframeやevalコードが追加されている、です。週に一度Wordfenceのコアファイル整合性チェックを実行し、公式ハッシュと一致しない場合はすぐに対処してください。同時にfail2banでログイン失敗を監視し、1日の失敗が50回を超えたIPを自動的に24時間ブロックします。監視アラートの設定方法はサイト監視とアラートの記事をご覧ください。

最後に

セキュリティ強化で一番高くつくのはツール代ではなく、「大丈夫だろう」という油断です。独立系サイトは銀行ではありませんが、問い合わせの入口です。改ざんや停止が起きれば、失うのは本当の売上につながるリードです。4層の防御は一度に全部やる必要はありませんが、順番は守ってください。まずポートを閉じ、次にログインを制限し、ファイル権限を調整し、最後にスキャンを導入します。最初の3ステップは半日で終わり、投資対効果が最も高い部分です。

実行は3ステップです。第一に、クラウドのセキュリティグループで3306、6379、8888など公開すべきでないポートを閉じ、SSHは会社のIPだけに制限します。第二に、wp-adminのパスを変更し、2FAを有効にし、5回失敗でロック、SSHは鍵認証に切り替えます。第三に、毎週決まった時間にコアファイルのハッシュ確認とプラグイン更新を実行します。ここまでで、よくある攻撃の8割は防げています。

覚えておきたい一言。独立系サイトが攻撃されるのは、高度なハッカーが原因ではなく、弱いパスワード、未更新のプラグイン、公開されたデータベースのバックアップが原因です。この3つの入口を塞ぐことが、どんなセキュリティ製品を買うより効きます。

环形山
环形山 クレーター専門家

公式アカウント · 環形山 Crater

環形山(Crater)は、WordPress独立サイト開発+Google SEO+GEO全域成長に特化した海外展開支援会社で、スマートハードウェア、産業機器、SaaS、新エネルギーなどの分野を手がけています。

プロダクト能力方法論ホワイトペーパー業界レポート
965件のシェア
78件のナレッジベース