はじめに：不審なログを見て不安になったことはありますか？

サーバーのログを見ていたら、こんな経験はないでしょうか。

  • 見覚えのないIPからのアクセスが大量にある
  • 存在しないURLへのリクエストが繰り返されている
  • SSHのログに知らないユーザー名での認証失敗が並んでいる

「もしかして攻撃されている？」と不安になりますよね。

結論から言うと、それはほぼ間違いなくスキャニングです。そして、あなたのサーバーだけが狙われているわけではありません。

この記事では、スキャニングとは何か、なぜ起きるのか、そして管理者として何を見て何をすべきかを解説します。怖がる必要はありませんが、正しく理解しておくことは大切です。

第1章：なぜあなたのサーバーは毎日調べられているのか

スキャニングは「攻撃」ではなく「下見」

泥棒が家に入る前に、まず下見をするのと同じです。

  • どの窓が開いているか
  • 鍵はどんな種類か
  • 人がいる時間帯はいつか

サーバーに対するスキャニングも同じ目的で行われています。

  • どのポートが開いているか
  • どんなサービスが動いているか
  • バージョンは古くないか

これらの情報を集めて、「攻撃できそうかどうか」を判断しているのです。

全世界で自動化されている現実

重要なのは、スキャニングのほとんどは人間が手動でやっているわけではないということです。

世界中に、24時間365日、インターネット上のすべてのIPアドレスをスキャンし続けるボットが存在します。これは特定のサーバーを狙っているわけではなく、「開いているものを見つけたら記録する」という単純な作業を繰り返しているだけです。

つまり、あなたのサーバーがグローバルIPを持っている限り、スキャンされるのは当たり前なのです。

「スキャンされた＝侵入された」ではない

ここで安心してほしいのは、スキャンされることと、侵入されることは全く別だということです。

スキャンは玄関のドアを「コンコン」と叩いているだけ。ドアが開いていなければ、中には入れません。

問題になるのは：

  • ドアが開けっ放しになっている（不要なポートが公開されている）
  • 鍵が壊れている（脆弱なバージョンのソフトウェアが動いている）
  • 合鍵が推測されやすい（弱いパスワードが設定されている）

これらの状態でなければ、スキャンされても何も起きません。

第2章：スキャニングで「見られている情報」の正体

開いているポートとは何か

サーバーには「ポート」と呼ばれる通信の入り口があります。全部で65,535個あります。

ポート番号 一般的な用途
22 SSH（リモート接続）
80 HTTP（Webサイト）
443 HTTPS（暗号化されたWebサイト）
3306 MySQL（データベース）
6379 Redis（キャッシュ）

スキャンでは、これらのポートに「応答するかどうか」を確認しています。

応答があれば「このポートは開いている」と分かります。応答がなければ「閉じている」か「フィルタされている」と判断されます。

サービスとバージョン情報の意味

ポートが開いているだけでなく、何が動いているかも分かる場合があります。

多くのサービスは、接続してきた相手に「こんにちは、私は○○のバージョン△△です」と名乗ります。これをバナーと呼びます。

例えば：

  • 「Apache/2.4.41」→ Apacheのバージョン2.4.41が動いている
  • 「OpenSSH_7.6p1」→ OpenSSHのバージョン7.6が動いている

なぜこれが問題かというと、特定のバージョンには既知の脆弱性があるからです。

「このバージョンには○○という脆弱性がある」という情報は公開されています。攻撃者はバージョン情報を見て、「この脆弱性が使えるかも」と判断できるのです。

ネットワーク構成が推測される理由

複数のポートの応答パターンを組み合わせると、サーバーの役割が推測できます。

  • 80と443が開いている → Webサーバー
  • 22と3306が開いている → データベースサーバー（SSHでアクセス）
  • 多数のポートが開いている → 開発環境かもしれない

また、応答時間やTTL（Time To Live）の値から、「このサーバーはクラウドにある」「この2つのサーバーは同じネットワークにある」といった推測も可能です。

なぜログに痕跡が残るのか

スキャンは「通信」です。通信があれば、サーバー側にはその記録が残ります。

  • ファイアウォールのログ：ブロックした通信の記録
  • アクセスログ：Webサーバーへのリクエストの記録
  • 認証ログ：SSHなどへのログイン試行の記録

スキャンを隠すことは技術的に難しく、注意深く見れば必ず痕跡があるのです。

第3章：ログを見ると「人間じゃない動き」は一発で分かる

通常のアクセスとスキャンの違い

人間のアクセスとボットによるスキャンは、ログを見れば明らかに違います。

通常のアクセス（人間）

    - アクセス間隔がバラバラ
- 実在するページにアクセス
- セッションが継続する
- 認証が成功することもある

スキャン（ボット）

    - アクセス間隔が一定、または極端に速い
- 存在しないページ・ポートにアクセス
- セッションがすぐ切れる
- 認証は常に失敗する

時間集中のパターン

スキャンボットは効率を重視します。そのため、短時間に大量のリクエストを送信します。

    擬似例：スキャンの時間パターン
10:00:01 - ポート22へ接続試行
10:00:01 - ポート23へ接続試行
10:00:01 - ポート25へ接続試行
10:00:02 - ポート80へ接続試行
10:00:02 - ポート443へ接続試行
10:00:02 - ポート3389へ接続試行
（1秒間に複数のポートをスキャン）

人間が手動でこの速度でアクセスすることは不可能です。

存在しないポート・URLへのアクセス

スキャンボットは「よくある構成」を想定してアクセスしてきます。

    擬似例：存在しないURLへのアクセス
/wp-admin/          ← WordPressの管理画面
/phpmyadmin/        ← phpMyAdmin
/.env               ← 環境変数ファイル
/config.php.bak     ← バックアップファイル
/admin/             ← 管理画面

あなたのサーバーにWordPressがなくても、/wp-admin/へのアクセスはやってきます。これは「とりあえず試している」だけです。

認証失敗の連続パターン

SSHの認証ログには、こんなパターンがよく現れます。

    擬似例：認証失敗のパターン
Failed password for root from xxx.xxx.xxx.xxx
Failed password for admin from xxx.xxx.xxx.xxx
Failed password for user from xxx.xxx.xxx.xxx
Failed password for test from xxx.xxx.xxx.xxx
Failed password for guest from xxx.xxx.xxx.xxx

「root」「admin」「user」など、よくあるユーザー名で順番に試しています。これはブルートフォース攻撃（総当たり攻撃）の前段階です。

第4章：ファイアウォールは「何を守って、何を守らないか」

ファイアウォールで防げるもの

ファイアウォール（FW）は、不要な通信を遮断するための仕組みです。

防げるもの：

  • 閉じているポートへのアクセス
  • 許可していないIPからのアクセス
  • 許可していないプロトコルの通信

例えば、ポート22（SSH）を特定のIPアドレスからのみ許可していれば、それ以外のIPからのSSH接続試行はすべてブロックされます。

ファイアウォールで防げないもの

しかし、開けているポートへの正当な形式のアクセスは防げません。

防げないもの：

  • 開いているポート80/443への不正なHTTPリクエスト
  • 許可されたIPからの攻撃
  • アプリケーション層の脆弱性を突く攻撃

ファイアウォールは「入り口で身分証を確認する警備員」のようなものです。正規の入り口から正規の形式で入ってくる人は止められません。

「FWがあるから安心」が成立しない理由

よくある誤解として、「ファイアウォールを設定したから安心」というものがあります。

しかし：

状況 ファイアウォールの効果
不要なポートが開いている ブロック可能
必要なポート（80/443）への攻撃 ブロック不可
Webアプリの脆弱性 ブロック不可
内部からの情報漏洩 ブロック不可

ファイアウォールは多層防御の一つであり、それだけで完璧なセキュリティは実現できません。

第5章：ログローテーションをしないと何が起きるか

スキャン × ログ爆増の関係

スキャンは毎日、24時間、世界中から行われています。そして、そのすべてがログに記録されます。

1日あたりのスキャンログの例：

  • ファイアウォールのドロップログ：数千〜数万行
  • SSHの認証失敗ログ：数百〜数千行
  • Webサーバーの404エラーログ：数百〜数千行

これらがログローテーション（ログの定期的な切り替え・削除）なしに蓄積されると、どうなるでしょうか。

ディスク枯渇 → サービス停止の流れ

    flowchart TD
    A[スキャンが継続] --> B[ログファイルが肥大化]
    B --> C[ディスク使用率が上昇]
    C --> D{ディスク100%}
    D --> E[新しいログが書けない]
    D --> F[データベースが書き込み不可]
    D --> G[一時ファイルが作れない]
    E --> H[サービス異常動作]
    F --> H
    G --> H
    H --> I[サービス停止]

    style D fill:#f44336,stroke:#333,color:#fff
    style I fill:#d32f2f,stroke:#333,color:#fff

これはセキュリティの問題ではなく、運用の問題です。しかし、スキャンというセキュリティイベントがトリガーになって、運用障害が発生するのです。

セキュリティと運用は地続き

この例が示しているのは、セキュリティと運用は別々の問題ではないということです。

  • セキュリティ担当：「ログは全部取っておくべき」
  • 運用担当：「ログでディスクが溢れたらサービスが止まる」

両方の視点が必要です。そして、ログローテーションは両方の要求を満たす基本的な設定なのです。

第6章：管理者が本当にやるべきチェックリスト

1. ポートは必要最小限か

    確認すべきこと：
□ 現在開いているポートを把握しているか
□ 各ポートが「なぜ開いている必要があるか」説明できるか
□ 開発時に開けたポートがそのままになっていないか
□ 3306(MySQL)や6379(Redis)が外部に公開されていないか

原則：使わないポートは閉じる

開いているポートが多いほど、攻撃の入り口が増えます。「念のため開けておく」は危険な考え方です。

2. 管理画面は外に出ていないか

    確認すべきこと：
□ 管理画面（/admin, /wp-admin 等）は認証で保護されているか
□ 管理画面へのアクセスをIP制限できないか
□ phpMyAdmin、Adminer等のDB管理ツールが公開されていないか
□ .env、config.php 等の設定ファイルにアクセスできないか

管理画面やデータベース管理ツールは、本来インターネットに公開する必要がないものです。VPN経由やIP制限でアクセスを絞ることを検討してください。

3. ログは「取っているか」ではなく「扱える量か」

    確認すべきこと：
□ ログファイルのサイズを定期的に確認しているか
□ ログを確認する頻度と手順が決まっているか
□ 異常を検知する仕組み（アラート等）があるか
□ ログを検索・分析する方法があるか

「ログを取っている」と「ログを活用できている」は別の話です。取っているだけで見ていなければ、意味がありません。

4. ログローテーションは設定されているか

    確認すべきこと：
□ logrotate（または同等の仕組み）が設定されているか
□ ローテーション周期は適切か（日次、週次など）
□ 保持期間は適切か（7日、30日など）
□ 圧縮は有効になっているか

logrotateの設定例：

    /var/log/nginx/*.log {
    daily           # 毎日ローテーション
    rotate 14       # 14世代保持
    compress        # 圧縮する
    delaycompress   # 1世代目は圧縮しない
    missingok       # ログがなくてもエラーにしない
    notifempty      # 空のログはローテーションしない
}

5. ソフトウェアのバージョンは最新か

    確認すべきこと：
□ OSのセキュリティアップデートを適用しているか
□ Webサーバー（nginx, Apache）のバージョンは最新か
□ 言語ランタイム（PHP, Node.js, Python等）は最新か
□ フレームワーク・ライブラリに既知の脆弱性はないか

バージョン情報はスキャンで取得される可能性があります。古いバージョンを使い続けることは、既知の脆弱性を放置することと同じです。

第7章：まとめ：スキャニングは「防ぐもの」ではなく「前提」

正しく知れば怖くない

この記事で伝えたかったことをまとめます。

  1. スキャンは日常的に起きている

    • 特別な攻撃ではなく、世界中で自動化されている
    • あなたのサーバーだけが狙われているわけではない

  2. スキャンされること自体は問題ではない

    • 問題になるのは、不要なポートが開いている、脆弱なバージョンを使っている、弱いパスワードを設定している場合

  3. ログを見れば状況が分かる

    • スキャンと通常アクセスは明らかに違う
    • 定期的にログを確認する習慣が大切

  4. ファイアウォールは万能ではない

    • 不要なポートを閉じるには有効
    • 開いているポートへの攻撃は防げない

  5. ログローテーションは運用の基本

    • スキャンログでディスクが溢れることがある
    • セキュリティと運用は地続き

見るべきポイントを間違えない

不安になったときに見るべきなのは：

見るべきもの 見る必要がないもの
開いているポートの一覧 スキャン元のIPアドレス
使っているソフトウェアのバージョン スキャンの回数
ログローテーションの設定 攻撃者の意図
認証の強度（鍵認証、2FA等） 「なぜ自分が狙われるのか」

スキャン元のIPを追いかけても意味がありません。そのIPは来週には別のIPに変わっています。大切なのは、自分のサーバーの状態を把握することです。

不安より「観測できる状態」を作る

最後に、最も重要なことをお伝えします。

「何が起きているか分からない」状態が、最も危険です。

スキャンが来ていることを知っている状態は、知らない状態より遥かに良いのです。

  • ログを取る
  • 定期的に確認する
  • 異常を検知できる仕組みを作る

これらができていれば、スキャンを必要以上に恐れる必要はありません。

あなたのサーバーは毎日「下見」されています。それは事実です。でも、ドアと窓がちゃんと閉まっていて、鍵がかかっていれば、下見だけで終わるのです。

関連記事

🚨 この記事を読んで確認すべきこと

今すぐ以下を確認してみてください：

    # 開いているポートの確認（Linux）
ss -tlnp

# ファイアウォールのルール確認（ufw）
sudo ufw status verbose

# SSH認証失敗ログの確認
sudo grep "Failed password" /var/log/auth.log | tail -20

# ログローテーション設定の確認
cat /etc/logrotate.d/nginx

一つでも「確認したことがない」ものがあれば、この記事を読んだ機会に確認してみてください。