【テクニカル・上級編】ポート135(RPC)およびポート139(NetBIOS Session)による内部偵察 – サイバーセキュリティとプライバシー保護実践ガイド

内部ネットワークの静寂を破る「死のノック」：RPC/NetBIOS偵察を封じ込める深層防衛術

ネットワークの境界が「境界」として機能しなくなった現代において、真の防衛ラインは常に内部ネットワークのダークサイドにあります。ランサムウェアが初期侵入を果たした後、彼らが最初に行うのは派手な暗号化ではありません。まずは静かに、しかし執拗に、ネットワークの地図を描くことです。

その地図作成の道具として、今なお愛用されているのが 135/tcp (RPC) と 139/tcp (NetBIOS Session) です。これらは現代のネットワークから見れば「遺物」に近いですが、Active Directory（AD）環境下では依然として血液のように流れています。今回は、この古くて新しい偵察手法をパケットレベルで解剖し、どう防ぎ、どう検知すべきか、現場の視点から掘り下げます。

—

パケットが語る「偵察」のリアル

攻撃者が 135 や 139 を狙う理由はシンプルです。これらは「ネットワークの構成情報」を無防備に晒す性質があるからです。

135 (Microsoft RPC Endpoint Mapper) へのクエリは、まさに宝の地図です。どのホストでどのサービスが動いているか、どのUUIDが登録されているかを epm_Map パケット一つで引き出せます。また、139 (NetBIOS) を通じた NetServerEnum は、ドメイン内のサーバーリストをいとも簡単に列挙します。

パケットキャプチャを眺めていると、巧妙な攻撃者はスキャン速度を調整し、IPSの閾値を回避しようとします。しかし、TCP のハンドシェイクにおける SYN パケットの連続や、SMB の匿名パイプ接続の試行といった「不自然なシーケンス」は、カーネルレベルのフィルタリングで明確に浮き彫りにすることが可能です。

—

内部防衛の最適化：パフォーマンスを犠牲にしない制約

「すべてブロックすればいい」というのは理想論ですが、現実のAD環境では RPC を完全に遮断すると認証基盤が崩壊します。ここで重要になるのが、TCP バッファのチューニングと、マイクロセグメンテーションによる「必要な通信の極小化」です。

1. カーネルレベルでの偵察パケットの抑制

iptables や nftables を使い、特定のホスト間以外からの 135/139 へのアクセスを「断固拒否」します。特に、エンドポイント同士の通信（Lateral Movement）を許可すべき理由は皆無です。

# nftablesによる内部偵察防止ルール
# クライアント同士のRPC/NetBIOS通信を破棄しつつ、ログを記録する
table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
        # 内部セグメントからの135/139をドロップ
        ip saddr 10.0.0.0/8 tcp dport { 135, 139 } log prefix "RPC_SCAN_ATTEMPT: " drop
    }
}

2. トランスポート層の最適化とTLSの役割

もしあなたが RPC over HTTP/HTTPS を利用しているなら、TLS ハンドシェイクの最適化がボトルネックになります。TLS 1.3 への移行は、RTT（Round Trip Time）の削減だけでなく、ハンドシェイク時の情報漏洩リスクを低減させます。

sysctl でTCPスタックを調整する際は、バッファサイズの最適化を忘れないでください。偵察トラフィックによるセッション飽和を防ぐため、tcp_max_syn_backlog を適切に設定し、SYNクッキーを有効にします。

# /etc/sysctl.conf の最適化例
# SYN flood攻撃対策とセッション管理の強化
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_tw_reuse = 1 # TIME_WAIT状態のソケットを再利用

—

次世代の監視：パケットヘッダーから「兆候」を読む

単なるポート監視を超えて、我々は SMB パケットのヘッダー圧縮や、異常な RPC リクエストのUUIDパターンに注目すべきです。例えば、RpcSs サービスに対する過度な QueryInterface リクエストは、偵察の明白な兆候です。

これらを効率的に検知するには、eBPF (Extended Berkeley Packet Filter) を活用したパケット追跡が最も泥臭く、そして確実です。カーネル空間でパケットをフィルタリングすることで、オーバーヘッドを最小限に抑えつつ、アプリケーション層のシグネチャを監視できます。

# eBPFを利用した簡易的な監視の考え方 (BCCフレームワーク)
from bcc import BPF

# 135ポートへのアクセスをカーネル内部でフックするコードの断片
bpf_text = """
int kprobe__tcp_v4_connect(struct pt_regs *ctx, struct sock *sk) {
    u16 dport = sk->__sk_common.skc_dport;
    if (ntohs(dport) == 135) {
        bpf_trace_printk("偵察パケット検知: RPCポートへの接続試行あり\\n");
    }
    return 0;
}
"""
# 運用環境ではこれをコンパイルしてロードする

—

結びに代えて：ゼロトラストの先にあるもの

135 や 139 を巡る攻防は、サイバーセキュリティの「終わりのないチェス」です。プロトコルを完全に排除できない以上、我々にできるのは「通信の正当性」をいかに厳格に検証し、異常をいかに早く検知するかという一点に集約されます。

ネットワークスペシャリストにとって、パケットは嘘をつきません。TCP のフラグ、TTL の揺らぎ、そしてヘッダーの僅かな違和感。それらを愛し、観察し、制御し続けることこそが、エンタープライズのインフラを守るための唯一の道です。

次にネットワーク機器のログを見る時、あるいは tcpdump を走らせる時、思い出してください。その1パケットの中に、防衛のヒントが隠されていることを。