UNIX Cafe | 第９６回
ログ解析は自動、遮断は手動：私が辿り着いた「ハイブリッド防衛術」
お気に入りのコーヒーを淹れ、Google Adsenseやアフィリエイトサイトの成果を確認する。
サイトを運営している人にとって、それは自分が作成した記事の結果を確認するワクワクした時間です。
でもWordPressでサイトを運営していると、常に外部からの執拗な攻撃にさらされているため、不正なアクセスがないか、サイトを乗っ取られる危険性はないかをチェックする必要があります。
これらすべてを自分の目で監視し続けるのは無理がありますが、かといって検出したIPを「機械的」にすべて自動で門前払いにするのも、危険な気がしてしまいます。
「もし、楽しみに見に来てくれた読者まで、間違えて弾いてしまっていたら？」
そんな葛藤の末に、私が行き着いたのが、「ログ解析と抽出はシェルスクリプトに任せて効率化し、最後の遮断の判断だけは人間が検証して行う」というスタイルです。
最新の MacBook Air M4 や Mac mini M4 は、こうした裏方の作業を軽快にこなしてくれる頼もしい相棒。 道具の便利さを存分に借りつつも、最後は自分の手で守る。この「少し丁寧な防衛術」の具体的な進め方を、これからお話ししていきます。
Apache 2.4 におけるアクセス制御の基本（Require構文）
攻撃を遮断する具体的なテクニックに入る前に、まずは土台となる設定ファイルの書き方をおさらいしておきましょう。
現在、多くのレンタルサーバーや VPS で採用されている Apache 2.4系 では、それ以前のバージョン（2.2系）で主流だった Order allow,deny といった記述方式から、より論理的で分かりやすい Require 構文へと進化しています。
旧世代（2.2以前）との決別
かつての記述方式は、許可と拒否の「順番」を意識する必要があり、設定が複雑になると予期せぬ挙動を招くことがありました。2.4系で導入された Require 構文は、「何が必要か（Require）」を直接記述するため、可読性と安全性が飛躍的に向上しています。
<RequireAll> による論理構造
私が防衛術の基本として活用しているのが、<RequireAll> というディレクティブです。これは「囲まれた条件がすべて満たされた場合のみアクセスを許可する」という論理構造を作ります。
# Apache 2.4 基本構成
<RequireAll>
# 原則としてすべてのアクセスを許可
Require all granted
# ここに拒否したい条件（ブラックリスト）を追記
</RequireAll>メンテナンス性を高める記述の作法
.htaccess は一度書いたら終わりではありません。後の自分が、あるいはスクリプトが編集しやすいように、以下のポイントを意識して記述しています。
- コメント（#）の活用: 「なぜこの設定を入れたのか」を未来の自分に伝える。
- 構造の明示: ホワイトリストとブラックリストの境界を視覚的に分かりやすく分ける。
基本的な構造を理解したところで、次は「具体的にどのようにして攻撃者を狙い撃つか」というブラックリストの構築方法を見ていきましょう。
防衛の要：ブラックリストの構築（IP拒否の具体策）
不正アクセスを防ぐ最も確実な方法は、悪意が明らかな相手を「ブラックリスト」に登録し、サーバーの入り口で門前払いすることです。ここでは、実戦で使える具体的な記述方法を解説します。
個別IPの狙い撃ちとネットワーク単位の遮断
攻撃の形態に合わせて、2通りの指定方法を使い分けます。
- 特定IPの拒否: 執拗にアタックしてくる単一のホストをピンポイントで遮断します。
- ネットワーク単位（CIDR）の拒否: 特定のデータセンターやプロバイダ全体が攻撃拠点となっている場合、広範囲をまとめて遮断します。
実践的なコード例
Apache 2.4 の <RequireAll> ディレクティブ内に、以下のように Require not ip を追記していきます。
# ---------------------------------------------------------
# ブラックリスト：ここに検証済みのIPを追記する
# ---------------------------------------------------------
<RequireAll>
# 全アクセスを許可した上で、以下の条件に合致するものを拒否
Require all granted
# 個別IPの指定
Require not ip 4.217.220.52
Require not ip 4.223.96.43
Require not ip 18.180.174.183
# ネットワーク単位（CIDR）での指定
# 例：特定の海外ホストや、不審な挙動が目立つISPのレンジ
Require not ip 20.0.0.0/8
Require not ip 43.128.0.0/10
Require not ip 91.84.0.0/16
Require not ip 193.19.109.0/24
Require not ip 193.37.33.0/24
</RequireAll>【補足：IPアドレスの後ろにある「/24」とは？】
ここで指定している /24 という数字は、IPアドレスを「点（1つ）」ではなく「面（範囲）」で指定するための CIDR（サイダー）表記 と呼ばれるものです。
- 個別指定（/なし）: そのIPアドレス1つだけを狙い撃ちします。
- 範囲指定（/24）: 下3桁（0〜255）の計256個のIPアドレスをまとめて遮断します。
- 193.37.33.0/24 が指す範囲： 193.37.33.0〜 193.37.33.255 まで
攻撃者はしばしば、IPアドレスの末尾だけを変えながら執拗に攻撃を仕掛けてきます。一つひとつ登録していては「いたちごっこ」になりますが、/24 を使えば、その攻撃者が利用している「拠点の塊」ごと一撃で封じ込めることができるのです。
なぜ「ブラックリスト方式」なのか
すべてのアクセスを拒否して許可したものだけを通す「ホワイトリスト方式」は、一見安全ですが、不特定多数に公開するWebサイトには向きません。
- 正当なユーザーを邪魔しない: 検索エンジンのクローラーや一般の読者を確実に通す。
- 攻撃者のみを排除する: whois で「敵」であると確信した相手だけを、静かにリストへ加える。
この「ブラックリストの精度」こそが、サーバー管理者の腕の見せ所です。次の章では、このリストの「候補」を効率よく炙り出すための、シェルスクリプトによるログ解析について触れていきます。
効率化の武器：シェルスクリプトによるログ解析
日々蓄積されるアクセスログの量は膨大です。これを一つひとつ目視で確認するのは、まさに「砂漠の中から一粒の針を探す」ような作業です。
ここで活躍するのが、自作のシェルスクリプト check_all.sh です。
「check_all.sh」の役割：単純作業の徹底自動化
このスクリプトは、UNIXの伝統的なコマンド（grep, awk, sed, uniq など）を組み合わせ、以下の工程を一瞬で完了させます。
- アクセスログの走査: サーバー上の膨大なログファイルを読み込む。
- ノイズの除去: 正常なアクセスや自分自身のアクセスを除外。
- 攻撃パターンの抽出: 短時間に異常な回数のアクセスを試みているIPや、存在しないファイル（wp-login.php等）へ執拗にアクセスしているIPを特定。
- ブラックリスト候補の生成: 抽出した結果を整理し、遮断すべきIPのリストをその場で作成。
UNIX哲学：小さく鋭いツールの組み合わせ
スクリプトの中身は、決して複雑なプログラミングではありません。「ログを読む」「特定の文字列を探す」「数を数える」「並べ替える」といった、単機能で鋭いツールをパイプ（|）で繋いでいるだけです。
これにより、管理者は「誰が攻撃してきたか」をゼロから探す手間を省いて、スクリプトが吐き出した「ブラックリスト登録候補」を即座に確認できるようになります。
自動化の「境界線」
ここで重要なのは、このスクリプトの任務はあくまで「候補の提示」までという点です。
一つのサイトを深く分析し、抽出されたIPをそのまま機械的に遮断するのではなく、一度「人間の目」を通す。このステップを挟むための準備を、スクリプトが肩代わりしてくれているのです。
固定IP VPN：解析の精度と通信の安全性を両立させる
シェルスクリプトで正確なログ解析を行うための大前提は、「自分自身のアクセスを、いかに確実にログから除外できるか」にあります。
一般的な家庭用回線やモバイル回線はIPアドレスが頻繁に変わる「動的IP」のため、その都度解析設定を調整するのは現実的ではありません。そこで、常に同じIPアドレスを維持できる固定IP付きVPNの出番です。
- ホワイトリストの固定化: 自分のIPを一度スクリプトの除外リストに登録すれば、毎日の解析から自分の足跡を100%排除でき、精度の高いログが手に入ります。
- 「いつもの場所」としてアクセス: 場所を問わず常に同じIPでサーバーへ接続できるため、Apache側のアクセス設定も最小限で済みます。
🛡️さらに、VPNの導入は解析の精度向上だけでなく、外出先での通信を保護する強力なセキュリティ対策としても機能します。
サーバー管理者が知っておくべき「外出先での通信の守り方」については、こちらの記事で詳しく解説しています。
ミナちゃん外で作業するときは、この記事も読んでおくと安心ですよ！
ログの精度を極限まで高める「固定IP付きVPN」という選択
シェルスクリプトで正確なログ解析を行うための大前提は、「自分自身のアクセスを、いかに確実にログから除外できるか」にあります。
その解決策として有効なのが、固定IPアドレスを持てるVPNサービスです。 一般的な家庭用回線やモバイル回線は、接続のたびにIPアドレスが変わる「動的IP」であることが多く、その都度スクリプト側の除外設定を調整するのは現実的ではありません。
一方、VPNを経由して常に同じIPアドレスでアクセスできる環境を用意しておけば、そのIPをホワイトリストとして登録するだけで、自分のアクセスを解析対象から完全に切り離すことができます。 これは特定のサービスに限らず、「ログ解析を行う管理者」にとって共通する、ひとつの考え方です。
その具体的な選択肢のひとつが、 ロリポップ！固定IPアクセス です。
VPNを経由することで、自分のIPを「固定」できるため、このIPを一度スクリプトの除外リスト（ホワイトリスト）に登録してしまえば、毎日の解析から自分の足跡を100%排除できます。
場所を選ばず「いつもの管理者IP」としてアクセスできるため、解析のスピードと精度を一段上のレベルへと引き上げてくれます。
【新機能】セキュリティ監査・トラブル対応を強化する「ログ機能」が登場
Lolipop VPN（固定IPアクセス）に、待望のログ記録オプションが加わりました。 「いつ、誰が、どこからアクセスしたか」を正確に把握することは、現代のシステム運用における「内部統制」と「安全確保」の基本です。
エンジニア・管理者に選ばれる3つのポイント：
- 確かな証跡管理: 接続元IPやハンドシェイク履歴を最長6ヶ月間保存。セキュリティ監査にも即座に対応可能です。
- 迅速な解析: 管理画面からCSV形式で一括ダウンロード。トラブル発生時の原因究明をスピードアップさせます。
- 圧倒的な低コスト: 1ライセンスあたり月額110円（税込）。自前でログサーバーを構築・保守する手間とコストを最小化します。
VPNによるセキュアなアクセスに、「記録」という安心を。 あなたの管理環境の信頼性を、さらに一段階引き上げましょう。
管理者の流儀：whoisによるIP検証と意思決定
スクリプトが「攻撃の疑いあり」と判定したIPアドレス。それを機械的にすべて遮断してしまえば、管理者の手間はゼロになります。でも、私はあえてそこに whoisコマンドによる検証 というステップを挟んでいます。
それは、単なる「自動化」と、サーバーの安全性を担保する「管理者」としての責任の分かれ目だと考えているからです。
なぜ完全自動化しないのか
どれほど優れた解析スクリプトでも、アクセスログという断片的な情報だけでは「そのアクセスの背景」までを100%正確に読み取ることはできません。
- 誤検知のリスク: 善良な検索エンジンのクローラーや、プロキシ経由の一般ユーザーを誤って遮断してしまう可能性がある。
- 敵を知る: 攻撃が単発の悪戯なのか、特定の国やデータセンターからの組織的なものなのかを知ることで、防衛の強度（個別IPで弾くか、/24の範囲で弾くか）を判断できる。
whoisコマンドで「敵の正体」を見極める
Macのターミナルから whois コマンドを叩くことで、そのIPアドレスがどこの国の、どの組織に割り当てられているものかを瞬時に調査できます。
$ whois 4.217.220.52表示された結果から、以下の情報を読み取ります。
- descr（組織名）: 有名なクラウドサービスやISPか？
- country（国名）: 本来のターゲット層ではない国からの集中アクセスか？
- role / person / abuse-mailbox（管理主体）: 連絡先や管理主体の信頼性はどうか？
管理者としての「意思決定」
whoisの結果と、ログに刻まれたアクセスの執拗さを照らし合わせ、「これは明らかに攻撃である」と確信したとき初めて、.htaccess のブラックリストにそのIPを書き加えます。
この「検証という名の安全装置」があるからこそ、pc-fan.net をはじめとする各サイトの平穏が守られ、同時に善良な訪問者のアクセスを阻害しないという信頼性が担保されています。
確実なデプロイ：個別適用と動作確認のルーチン
検証済みのIPを .htaccess に追記したら、いよいよ各サーバーへ反映させる最終工程です。ここでは、効率化のために upload.sh を活用しつつも、あえて一括反映を避け、サイトごとに丁寧なデプロイを行っています。
1. 「upload.sh」によるサイト別のアップロード
FTPのパスワード入力を省略できる .netrc と curl を組み合わせた自作スクリプトを活用します。
- スクリプトの役割: ターゲットとなるドメインを指定し、ローカルで編集した最新の .htaccess を瞬時にサーバーへ転送する。
- セキュアなパスワード管理: .netrc を活用することで、スクリプト内に生パスワードを書かずに安全な自動ログインを実現。
2. なぜ「一括」送信ではなく「個別」対応なのか
管理しているサイト群（pc-fan.net, etc など）は、それぞれ CMS の種類やサーバー構成が微妙に異なります。
- 不測の事態を防ぐ: 万が一 .htaccess に記述ミス（タイポなど）があった場合、一括デプロイをしてしまうと全サイトが同時に 500 Error でダウンしてしまいます。
- サイトごとの個性を尊重: 共通のブラックリストを適用しつつも、各サイトの設定や挙動を個別に把握するための「間」（ま）を大切にしています。
3. デプロイ直後の「生存確認」
サーバー管理は、ファイルをアップロードして終わりではありません。自分の手でサイトが正常に稼働しているかを確認して、初めて作業完了となります。
ブラウザでの目視に加え、ターミナルから curl -I コマンドを実行して、レスポンスヘッダを直接確認するのが最も確実です。
# 正常にアクセスできる場合の確認
$ curl -I https://example.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
...もし設定を誤り、サーバーエラーを起こしてしまった場合は HTTP/2 500 が返ってきます。これに素早く気づけるかどうかが、管理者の「生存確認」の要です。
また、特定のIP（拒否設定したもの）を模したテスト環境などから確認し、意図通り拒否されていれば以下のような結果になります。
# アクセス拒否が正しく機能している場合の確認
$ curl -I https://example.com/
HTTP/2 403
...自分自身を締め出さないための注意点
「敵」を正しく弾けているかを確認する最も確実な方法は、自分自身のIPを一時的に「敵」と見立ててテストすることです。
ただし、この作業には注意が必要です。設定を反映した瞬間、自分自身もサイトへのアクセスや管理ができなくなるからです。万が一に備え、FTP接続を維持したまま作業するか、あるいは別回線（スマートフォンのテザリングなど）を予備として確保しておくことを強くお勧めします。
「正しく拒否されること」が確認できたら設定の消し忘れに注意して、作業を終了してください。
# 【検証テクニック】
# 自分の現在のIPを調べ、それを一時的にブラックリストに入れてテストする
# ※テストが終わったら必ずリストから消すこと！
# 1. 自分のIPを確認
$ curl inet-ip.info
# 2. そのIPを .htaccess の Require not ip に追記してアップロード
# 3. 再度アクセスして 403 になるか確認
$ curl -I https://exsample.com/
HTTP/2 403
# 4. 確認後、速やかに .htaccess から自分のIPを削除して再アップロード※ curl inet-ip.info：外部サービスのため、将来URLが変わる可能性があります。代替として ifconfig.me なども利用できます。
管理者に求められる「慎重さ」
このように、「実際に弾かれること」を確認したら、防衛システムは完成です。 自分では正しく設定したつもりでも、構文ミスがあれば素通りされてしまう可能性もあるからです。
管理者としての責任とUNIX哲学の融合
ファイルの転送作業はスクリプトに任せ、「サイトが生きているか」という確認は人間が行う。このバランスこそが、複数のサイトを長期間、安定して運用し続けるための条件です。
【管理者コラム】防衛拠点を支える機材選び（M4 Mac）
今回紹介した一連のワークフロー（ログ解析、whois検証、デプロイ）を支えているのが、MacBook Air M4 です。
サーバー管理は、いつどこで緊急対応が必要になるか分かりません。M4チップの圧倒的なレスポンスは、膨大なログを処理するスクリプトの実行を驚くほど快適にし、そして何より「どこへでも持ち出せる軽さとバッテリー持ちの良さ」が、VPN越しの安全で快適な作業を保証してくれます。
UNIX哲学という「知恵」を、最新の「M4チップ」で回す。この組み合わせこそが、現代の個人サーバー管理者にとっての最適解だと実感しています。
ポチップ
サーバーの「盾」を固めたら、次に「通信の道」を整えよう
.htaccess による防衛は、あくまでサーバー側の対策です。しかし、どれほどサーバーの入り口を強固にしても、そこへアクセスする「あなた自身の通信経路」が無防備では、安全な環境とは言えません。
特に最新の MacBook Air M4 のような機動力のある機材を使い、外出先からサーバー管理を行う場合は、フリーWi-Fiのリスクを知り、適切な接続手段（VPNやテザリング）を使い分けることが重要です。
管理者の「防衛拠点」を完璧なものにするために、通信環境のセキュリティについても併せてチェックしておきましょう。
まとめ：道具を使いこなし、サイトの平穏を守る
このページでは、.htaccess を用いたサイト防衛術について、技術的な設定から運用哲学までを俯瞰してきました。
効率化と確実性のバランス
私が実現しようとしているのは、単なる「完全自動化」ではありません。
- シェルスクリプト: 膨大なログから砂粒のような攻撃の兆候を見つけ出し、整理する「目」と「手」の代わり。
- whoisと人間: そのIPを本当に遮断すべきか、背景に何があるかを洞察する「脳」の役割。
- 個別デプロイ: 一括処理の脆さを理解し、一つひとつのサイトの「生きた反応」を確認する管理者の責任。
これらを組み合わせることで、pc-fan.net をはじめとする複数のサイトは、過剰な防御による誤遮断を避けつつ、強固な平穏を手にいれることができます。
UNIX哲学を現代の管理に
「一つのプログラムには一つのことを、効率よく」というUNIX哲学は、最新の M4 Mac を手にした現代の環境でも、色褪せることなく機能しています。
ツールはあくまで、人間の判断を助け、クリエイティブな時間を生み出すためのものです。ログ解析という単純作業をスクリプトに任せることで生まれた「余白」を、whois による深い検証や、より良いコンテンツ制作へと充てる。
この記事が、皆さんのサーバー管理を「単なる作業」から、より知的で愉しい「防衛術」へと変えるきっかけになれば幸いです。
