ポートスキャンの方法にsynスキャンという方法がありますが

towfiqu-barbhuiya-em5w9_xj3uU-unsplash.jpg

質問

ポートスキャンの方法にsynスキャンという方法がありますが、ステルス性を考えるとこの手法のみ使われるべきと思うのですが、これでは何か取得できる足りない情報が足りないとかあるのですか?


インターネット文明 (岩波新書 新赤版 2031) [ 村井 純 ]

価格:1056円
(2026/5/4 11:03時点)
感想(0件)


解答

結論から言うと、その直感は半分当たっていて半分外れています。
SYNスキャンは「目立ちにくく、速く広く当たる」点では優秀ですが、情報量と確度に限界があるため、実務では他の手法と組み合わせます。


SYNスキャンの位置づけ(おさらい)

  • 3-wayハンドシェイクを完了させずに判定(SYN→SYN/ACKでopen、RSTでclosed)

  • 利点:高速・比較的ログに残りにくい(アプリ層のログには出にくい)

  • 前提:生パケット送信権限が必要(環境によっては使えない)


なぜ「これだけ」では足りないのか

1) アプリ層の情報が取れない

SYNで分かるのは基本的に

  • open / closed / filtered
    だけ。
    サービスの種類・バージョン・設定ミスなどは分かりません。

例:

  • 同じ 443/tcp が open でも、中身が

    • HTTPSなのか

    • プロキシなのか

    • 独自プロトコルなのか
      は判別不可。

バナー取得やプロトコル対話(フル接続 or アプリ層スキャン)が必要


2) フィルタ環境での誤判定が増える

現実のネットワークでは

  • ファイアウォール

  • IDS/IPS

  • レート制限

により応答が変形されます。

結果:

  • openなのに応答が返らない → filtered扱い

  • RSTを偽装される → closedと誤認

ACKスキャンやトレーサ的手法でフィルタの存在を推定する必要が出てきます。


3) UDPや一部プロトコルはカバーできない

SYNはTCP専用。
重要なサービス(DNS, NTP, SNMPなど)はUDP

UDPスキャンは別物として必要(しかもこちらはさらに難しい)


4) 「本当に接続できるか」は保証しない

SYNでopenでも:

  • TCP接続は張れるがアプリが落ちている

  • 接続後すぐ切られる

  • 認証必須で実質使えない

といったケースがあります。

→ **実際に接続して確かめる(connectスキャン等)**ことで確度を上げる


5) OS/スタック特性の情報が取りにくい

OSフィンガープリントは:

  • TTL

  • ウィンドウサイズ

  • オプションの癖

など複数パケットの振る舞いを見ることで精度が上がります。
SYN単体では材料が不足しがち。


6) ステルス性も万能ではない

「SYNは見つからない」は過信です。

  • IDSは未完了ハンドシェイクのパターンを検知する

  • 高速スキャンはレートで検知される

  • そもそもネットワーク機器レベルでは見える

→ 現代では完全ステルスなスキャンはほぼ存在しないと考えた方が現実的


ではどう使い分けるか

実務的には段階的にやります。

  1. 広く浅く(SYN)

  • 開いている可能性のあるポートを高速に列挙

  1. 確度を上げる(connect / 再試行)

  • 本当に接続可能か確認

  1. 中身を見る(バナー / プロトコル)

  • サービス特定・バージョン取得

  1. 必要に応じて補助スキャン

  • UDP、ACK、OSフィンガープリントなど


まとめ

  • SYNスキャンは入口として最適

  • ただし得られるのは**「ポート状態の粗い分類」だけ**

  • 実用的な情報(サービス内容・脆弱性)には届かない

  • ステルス性も絶対ではない

なので結論は:

SYNは主役ではあるが、単独では不十分。偵察の第一段階として使うのが正しい。





マイクロソフト Excel 2024

価格:22370円
(2026/5/3 21:09時点)
感想(7件)


 



この記事へのコメント