【実務・中級編】 ポート135番・139番(RPC/NetBIOS):Windowsネットワークサービスを標的とした内部探索とエクスプロイト手法 – サイバーセキュリティとプライバシー保護実践ガイド

「レガシーな遺物」が招く悪夢:ポート135/139がネットワークの牙城を崩す瞬間

ネットワークエンジニアとして現場を渡り歩いていると、いまだに「なぜ、このポートが空いているのか?」と頭を抱えたくなるような構成に出くわすことがあります。特に、Windowsネットワークの根幹を支えてきた TCP/135 (RPC) や TCP/139 (NetBIOS) といったレガシーなプロトコルたちは、現代のゼロトラスト環境において、攻撃者にとっての「黄金の鍵」となり得ます。

今日は、これらのポートがなぜ危険視されるのか、そして私たちがインフラ設計の現場でどうやってこのリスクを封じ込めるべきか、泥臭い知見を交えて解説しましょう。

—

1. なぜ「ポート135/139」が標的になるのか

まず前提として、これらのポートはMicrosoftのネットワーク共有や管理機能のために存在します。

  • TCP/135 (RPC – Remote Procedure Call): Windowsの管理用インターフェースです。攻撃者はこれを利用して、リモートマシンの機能を列挙し、特定のサービス(例えば WMI や DCOM)を叩いてコード実行を試みます。
  • TCP/139 (NetBIOS Session Service): ネットワーク上のホスト名解決やファイル共有を担います。認証が甘い環境では、ここから共有フォルダへアクセスし、パスワードハッシュを抜き取るという古典的かつ強力な手法が使われます。

攻撃者は、ネットワークセグメントに潜入した瞬間、これらのポートに向けてパケットを投げ、ネットワーク全体の「地図」を描き始めます。これを防ぐのが、私たちの役割です。

—

2. 攻撃者の視点:ツールで見るホスト列挙

攻撃者がネットワーク内で行う「偵察」は、実は非常にシンプルです。例えば nmap を使ったスキャンは、管理者の目から見れば、ネットワークの死角を突く最も標準的な行為です。

# ネットワーク内のRPC/NetBIOSが空いているホストを探すスキャン
# -p135,139: ターゲットのポートを指定
# -sV: バージョン情報を取得し、脆弱なサービスかを確認
nmap -p135,139 --script smb-enum-shares,rpcinfo 192.168.1.0/24

もし、あなたの管理するサブネットからこのようなパケットが大量に発生しているなら、既に内部でランサムウェアが横行しているか、侵入者が足場を固めている最中だと疑うべきです。

—

3. 実務で活かす防御策:ACLとルーティングの制御

ゼロトラストの基本は「境界を信じない」ことですが、ネットワークレベルでの防御(セグメント間ルーティング制御)は、多層防御の要です。

3.1. Windows Firewallでの厳格な遮断

サーバーのOSレベルで、これらのポートを「許可しない」設定がデフォルトであるべきです。PowerShellを使って、全インターフェースで該当ポートをクローズするスクリプトを書いておきましょう。

# NetBIOSおよびRPC関連ポートをWindows Firewallで遮断するコマンド
$ports = "135,137,138,139,445"
New-NetFirewallRule -DisplayName "Block_Legacy_SMB_RPC" `
                    -Direction Inbound `
                    -Action Block `
                    -Protocol TCP `
                    -LocalPort $ports `
                    -Description "内部探索を防ぐため、RPC/NetBIOSポートを閉鎖"

3.2. ルーター/L3スイッチでのセグメント間制御

VLAN間ルーティングを行っているコアスイッチでは、クライアントセグメントからサーバーセグメントへの通信に対し、ACL (Access Control List) を適用します。

! Cisco IOSでのACL設定例
ip access-list extended SECURE_SEGMENT_ACL
 ! NetBIOS/RPCを遮断し、ログを記録する
 deny tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 135
 deny tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 139
 ! 必要な通信(HTTPS等)のみ許可
 permit tcp any any eq 443
 deny ip any any

—

4. 現代的なインフラへの教訓

Web APIやクラウドネイティブなサービスを設計する際、私たちは「サーバー間通信はHTTPS(443)やgRPCなどの現代的なプロトコルに限定する」というルールを徹底すべきです。

どうしてもレガシーなWindows管理が必要な場合でも、VPNや Bastion Host (踏み台サーバー) を経由させ、直接クライアントからサーバーの 135 や 139 に到達できない構造を作ってください。

最後に:エンジニアとしての嗅覚

トラブルシューティングをしていると、パケットキャプチャ上に奇妙な SMB トラフィックや RPC の呼び出しが見えることがあります。多くの初心者はこれを「単なる通信エラー」と片付けますが、凄腕のエンジニアは「誰が、何の目的でこのレガシープロトコルを叩いているのか?」を疑います。

ネットワークは嘘をつきません。ポートの開放は、そのまま「扉の鍵を開けっ放しにしている」のと同じです。あなたの設計するインフラが、攻撃者にとって「攻略しがいのある迷路」ではなく、「侵入不可能な鉄壁」であることを願っています。

—
著者プロフィール:
長年、金融機関のネットワーク設計からCSIRTのインシデントレスポンスまでを経験。現在は技術コンサルタントとして、セキュアなインフラ構築の啓蒙に注力中。「パケットが読めれば、セキュリティは半分終わったようなもの」が口癖。

コメント

タイトルとURLをコピーしました