境界防御の幻想を捨てろ：内部ネットワークを徘徊する「ポート135/139」の脅威と対策
「社内LANだから安全」「ファイアウォールの中にいるから大丈夫」。もしあなたが今でもそう思っているなら、今すぐその甘い考えを捨てたほうがいい。ランサムウェアの被害に遭った現場に駆けつけると、必ずと言っていいほど、攻撃者が内部ネットワークを「偵察」した痕跡が残っているからだ。
特に、往年のレガシープロトコルである TCP 135 (RPC) と TCP 139 (NetBIOS Session) は、現代の攻撃者にとって「社内マップ」を自動作成するための格好のツールだ。今回は、これらがどのように悪用され、我々エンジニアがどう防御すべきか、現場の視点で切り込む。
—
なぜ攻撃者は「ポート135」と「139」を執拗に狙うのか
攻撃者がネットワークに侵入した直後に行うのは、いわゆる「ラテラルムーブメント（横展開）」のための情報収集だ。彼らは Nmap や専用の偵察ツールを使い、ドメインコントローラやファイルサーバの場所を特定しようとする。
TCP 135(RPC – Remote Procedure Call): Windowsのシステム管理やサービス制御の要だ。攻撃者はこれを通じて、遠隔地のホストで何が動いているかを列挙する。TCP 139(NetBIOS Session Service): ネットワーク共有のリソースを列挙するための古いプロトコルだ。これを叩けば、どのPCがどのフォルダを共有しているか、一発でリストアップできてしまう。
これらは認証が甘いケースが多く、内部の信頼関係を逆手に取った「認証の踏み台」として悪用される。
—
偵察通信のリアル：シーケンスの裏側
攻撃者が nmap --script smb-enum-shares のようなコマンドを打つと、裏側では次のような泥臭い通信が行われている。
1. 接続確立: 攻撃者端末が対象の 139 ポートへ SYN パケットを送り、SYN/ACK が返る。
2. ネゴシエーション: NetBIOS上で、セッション確立のための Session Request が飛ぶ。
3. 列挙要求: SMB プロトコルを介して、NetServerEnum などのAPIコールが投げられる。
4. 情報漏洩: ターゲットは「はい、私の共有フォルダはこれです」とばかりに、パスやアクセス権を応答する。
この通信フローを放置しているということは、自分の家の間取り図を泥棒に渡しているのと同じだ。
—
実践：ネットワークと端末でどう「塞ぐ」か
ゼロトラストの観点では、「内部通信は全て疑う」のが鉄則だ。以下の対策を現場で即座に実行してほしい。
1. Windows Defender ファイアウォールの設定（グループポリシー）
クライアント同士の通信（ピア・ツー・ピア）は、業務上必要ない限り完全に遮断するべきだ。PowerShellで一括制御するのが最も確実だ。
# 管理者権限で実行
# NetBIOS (139) と RPC (135) のインバウンド接続を禁止するポリシー
New-NetFirewallRule -DisplayName "Block_Legacy_SMB_RPC" `
-Direction Inbound `
-Action Block `
-Protocol TCP `
-LocalPort 135,139 `
-Description "内部偵察防止のため、RPC/NetBIOSのインバウンドを遮断"2. ネットワーク機器でのフィルタリング
コアスイッチや境界ルータで、VLAN間のACL（アクセス制御リスト）を厳格化する。以下は Cisco IOS の設定例だ。
! 内部ネットワーク間での不要なプロトコルを拒否するACL
ip access-list extended BLOCK_LEGACY_RECON
deny tcp any any eq 135
deny tcp any any eq 139
permit ip any any
! 対象のインターフェース（VLAN）に適用
interface Vlan10
ip access-group BLOCK_LEGACY_RECON in—
監視：パケットをどう検知するか
「遮断したつもり」が一番危険だ。実際にトラフィックが発生していないか、tcpdump で定期的にパトロールしよう。
# 特定のポートへのアクセスをリアルタイムで監視する（現場の鉄板コマンド）
sudo tcpdump -i eth0 port 135 or port 139 -nn -vもし、管理下の端末からこのポートへの通信が大量に発生している場合、その端末は既にランサムウェアに感染し、横展開を試みている可能性が高い。即座にネットワークから隔離（アイソレーション）する判断が必要だ。
—
エンジニアへの提言：境界防御から「信頼ゼロ」へのシフト
ポート 135 や 139 を塞ぐことは、あくまで延命措置に過ぎない。真の防御は、「どの端末も信用せず、常に認証と認可を求める」というゼロトラストアーキテクチャの導入にある。
API設計においても同様だ。社内APIだからといって認証をサボっていないか？ curl で簡単に叩ける内部エンドポイントが、そのまま攻撃の入り口になる。
# 悪意ある偵察をシミュレートするcurlの例
# 内部IPに対して、共有リソースを探るような挙動をチェックする
curl -v -I http://192.168.1.50:139このような通信がログに残るような環境を作ること自体が、セキュリティの第一歩だ。今日の業務が終わったら、まずは自環境の nmap スキャンを試してほしい。自分が管理者として把握していない「隙」が、意外なところで見つかるはずだ。
セキュリティは教義ではなく、泥臭い継続的な戦いである。共に堅牢なインフラを作り上げていこう。
コメント