なぜラボにおいて匿名性が重要なのか
かつて、わずかなIP漏洩が原因で、一晩のうちにサーバーログが5,000件以上のSSHブルートフォース攻撃で埋め尽くされるのを目の当たりにしました。その一件は大きな教訓となりました。パブリックIPがほんの一瞬露出するだけで、自動化されたボットによる執執なスキャンや標的型攻撃を招く可能性があることが証明されたのです。マルウェア解析やペネトレーションテストを行っている際、実環境のアイデンティティが漏洩することは、単なるプライバシーの失態ではなく、重大なセキュリティ上のリスクとなります。
Tor Browserは基本的なウェブ調査には有効ですが、CLIツールやバックグラウンドのシステムアップデート、あるいはブラウザレベルのプロキシ設定を無視するカスタムスクリプトを保護することはできません。だからこそ、私はTor透明プロキシ（Tor Transparent Proxy）を活用しています。専用のLinuxゲートウェイを構築することで、ラボから送信されるすべてのパケットを強制的にTorネットワーク経由にすることができます。漏洩の心配がなく、アプリごとの手動設定も不要で、絶対的な安心感を得られます。
アーキテクチャ
この構成は、1GBのRAMを搭載したDebian VMやRaspberry Piなどの軽量なLinuxマシンで最適に動作します。2つのネットワークインターフェースが必要です。
- eth0 (WAN): インターネットへのアップストリーム接続。
- eth1 (LAN/内部): ラボマシン（VMまたは物理ハードウェア）用のゲートウェイ。
目的は、eth1に入るすべてのトラフィックをインターセプトし、eth0を経由してオープンなウェブに到達する前に、それらを直接Torプロセスにパイプすることです。
ステップ1：Torと依存関係のインストール
標準リポジトリの古いパッケージの使用は避けてください。最新のセキュリティパッチとパフォーマンスの向上を確実にするには、公式のTor Projectリポジトリを使用するのが唯一の方法です。
# 依存関係のインストール
sudo apt update
sudo apt install apt-transport-https curl lsb-release -y
# 公式のTor Projectリポジトリを追加
cat <<EOF | sudo tee /etc/apt/sources.list.d/tor.list
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org $(lsb_release -cs) main
EOF
# GPGキーのインポート
curl -s https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
# Tor、キーリング、監視用のNyxをインストール
sudo apt update
sudo apt install tor deb.torproject.org-keyring nyx -yステップ2：Torデーモンの設定
デフォルトでは、Torはポート9050でSOCKSプロキシとして動作します。これを透明ゲートウェイおよびDNSリゾルバとして機能するように再設定する必要があります。/etc/tor/torrcを開き、ファイルの末尾に以下の行を追加します。
# 透明プロキシポート
TransPort 9040
# ラボクライアント用のDNSポート
DNSPort 5353
# .onionアドレスを仮想IPにマッピング
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
RunAsDaemon 1サービスを再起動して新しい設定を適用します。
sudo systemctl restart torステップ3：IPTablesによるトラフィックのルーティング
ここでルーティングロジックを定義します。内部インターフェースに到着したトラフィックを捕捉し、TorのTransPortにリダイレクトするようLinuxカーネルに指示する必要があります。更新やリセットを容易にするため、シェルスクリプトを使用します。
tor-gateway.shを作成します：
#!/bin/bash
# 設定
_tor_uid=$(id -u debian-tor)
_trans_port="9040"
_dns_port="5353"
_int_if="eth1"
# 既存のルールをフラッシュして初期化
iptables -F
iptables -t nat -F
# 1. DNSトラフィックをリダイレクト
iptables -t nat -A PREROUTING -i $_int_if -p udp --dport 53 -j REDIRECT --to-ports $_dns_port
# 2. すべてのTCPトラフィックをTorにリダイレクト
iptables -t nat -A PREROUTING -i $_int_if -p tcp --syn -j REDIRECT --to-ports $_trans_port
# 3. 漏洩を防ぐため、LANからのTor以外の全トラフィックをドロップ
iptables -A FORWARD -i $_int_if -j DROP
# 4. ローカルゲートウェイの保護（ゲートウェイ自体からの漏洩を防止）
iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports $_dns_port
iptables -t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports $_trans_portルート権限でスクリプトを実行します：
chmod +x tor-gateway.sh
sudo ./tor-gateway.shシステムの再起動後もこれらのルールを維持するために、永続化パッケージをインストールします：
sudo apt install iptables-persistent -y
sudo netfilter-persistent saveステップ4：DNS漏洩の完全遮断
DNS漏洩は、セキュリティ設定において最も一般的なミスです。たとえウェブトラフィックが暗号化されていても、標準的なDNSを使用していると、ISPはリクエストされたすべてのドメインを確認できてしまいます。DNSPort 5353を設定し、ポート53をリダイレクトすることで、すべてのクエリを強制的にTorサーキット経由にします。
クライアントマシンでは、静的DNSサーバーをゲートウェイのeth1インターフェースのIPアドレスに設定してください。これにより、クライアントが8.8.8.8やISPのリゾルバに直接アクセスしようとするのを防ぎます。
ステップ5：検証と監視
プロキシが動作していることを証明するまで、決して動作していると思い込まないでください。クライアントマシンから簡単なチェックを実行します：
curl https://check.torproject.orgページでTorを使用していることが確認できれば、パイプラインは安全です。
リアルタイムの可視化には、Nyxをお勧めします。これはTorノード用の強力なCLIダッシュボードです。ゲートウェイで実行して、アクティブなサーキットを確認します：
sudo -u debian-tor nyxこのツールは、帯域幅の使用状況を視覚化し、現在の出口ノード（Exit Node）の地理的な場所を特定するのに役立ちます。
パフォーマンスに関する最終的な考察
3層の暗号化されたノードを介してすべてのトラフィックをルーティングすると、大幅なレイテンシが発生します。pingが20msから300ms以上に跳ね上がることを覚悟してください。大きなISOファイルのダウンロードなどは時間がかかりますが、リスクの高いリサーチにおいては、セキュリティとのトレードオフは不可欠です。この基盤を正しく整えることで、ツールの設定ミス一つで悪意のある攻撃者に自分の場所をうっかり露呈させてしまうといった事態を防ぐことができます。
