「そのアクセス、信頼していいのか？」SWGとDGAの攻防戦を制する現場の技術
ネットワークエンジニアの諸君、今日も元気にパケットを追いかけているか？
境界防御が崩壊し、「信頼するな、常に検証せよ」というゼロトラストの原則が叫ばれるようになって久しい。だが、どれほど強固な認証基盤を築こうとも、「人間がブラウザから悪意あるURLを踏む」という、もっともプリミティブで防ぎにくい攻撃経路は常に脅威として居座り続けている。
今日は、Webゲートウェイ（SWG: Secure Web Gateway）の心臓部である「URLフィルタリング」と「レピュテーション評価」、そしてサイバー攻撃の急先鋒である「DGA（Domain Generation Algorithm）」をどう捌くか、現場の泥臭い実体験を交えて深掘りしていくぞ。
—
1. なぜ「静的リスト」だけでは防げないのか
昔ながらのプロキシサーバーやファイアウォールのブラックリスト運用、まだ信じているやつはいないよな？
攻撃者は「ドメインを使い捨てる」。DGA（Domain Generation Algorithm）という技術を使えば、数千、数万ものドメインを動的に生成し、マルウェアのC2（指令）サーバーとして一瞬だけ稼働させ、すぐに消すことができる。攻撃者にとって、ドメインの取得コストはタダ同然だ。
そこで重要になるのが、「新規開設ドメイン（Newly Registered Domains: NRD）」の動的な遮断だ。
通信フローの裏側：SWGの判定ロジック
クライアントが GET / HTTP/1.1 を投げた瞬間、SWG内部では超高速な連鎖判定が走っている。
1. キャッシュ確認: 直近でアクセスしたURLの評価結果があるか？
2. カテゴリ・レピュテーション照会: 外部脅威インテリジェンス（TalosやBrightCloudなど）への問い合わせ。
3. DGA検知: ドメイン名の「怪しさ」をエントロピー計算や辞書チェックで解析。
4. ポリシー適用: 許可、ブロック、あるいはSSL復号（インスペクション）の判断。
この処理がミリ秒単位で行われなければ、ユーザーは「ネットが重い」とクレームを入れてくる。SWGの性能は、この「判定の効率化」に凝縮されているんだ。
—
2. 実践：DGAを意識したWeb APIのリクエスト検証
開発現場でAPIを叩く際、接続先が信頼できるかを確認するのはもはやエンジニアの嗜みだ。Pythonの requests ライブラリで、簡易的なレピュテーションチェックを模したコードを書いてみた。
import requests
# 信頼できないドメインの可能性が高いか確認する擬似ロジック
def check_domain_reputation(domain):
# 本来はここで Threat Intel API (例: VirusTotal) を叩く
api_url = f"https://api.threat-intel.example.com/v1/reputation?domain={domain}"
try:
response = requests.get(api_url, timeout=2.0)
data = response.json()
# 評価スコアが閾値（例: 70以下）なら警告、80以下なら遮断
if data.get("reputation_score", 100) < 50:
print(f"[ALERT] 危険なドメインです: {domain}")
return False
return True
except requests.exceptions.RequestException as e:
print(f"[ERROR] 照会失敗: {e}")
return False
# 実行例
target = "x8z9-malware-c2.com"
if check_domain_reputation(target):
print("通信を許可します")
else:
print("通信を遮断します")現場では、このようにAPIのレスポンスに対して、Content-Type や X-Reputation-Score といったヘッダーを監視し、異常があれば即座にサーキットブレーカーを起動させる設計が不可欠だ。
—
3. インフラ運用での設定Tips：SWGの「守り」を固める
次に、SWG（例えばクラウドベースのSWGや、オンプレのWebプロキシ）での設定例だ。よくあるのが「新規ドメインをすべて許可してしまう」という設定ミス。
設定ファイルの概念例 (Squid風)
# NRD (新規開設ドメイン) を検知してブロックするACL
# ※実際には外部のDynamic Category Listと連動させるのが定石
acl newly_registered_domains rep_category "newly_registered_24h"
acl malicious_sites rep_category "malware_c2_servers"
# セキュリティポリシー：危険なカテゴリは即時ブロック
http_access deny newly_registered_domains
http_access deny malicious_sites
# ログ設定：異常な接続を特定するために詳細ログを吐かせる
logformat custom_log %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log /var/log/squid/access.log custom_logここで重要なのは、%Ss:%Sh（TCP_MISS/DIRECTなど）のログだ。「どのドメインが、どのカテゴリとして判定され、どの結果（ブロック/許可）になったか」を追跡できないインフラは、トラブル発生時にただのブラックボックスと化す。障害対応の際、このログを grep する手が止まるようなことがあってはならない。
—
4. 現場のシニアからのアドバイス
最後に、若手エンジニアにこれだけは伝えておきたい。
- 「ホワイトリスト至上主義」を捨てろ: すべてを許可して危険なものを弾くより、必要な通信以外をすべて遮断（Default Deny）する姿勢が、結局は運用を楽にする。
- SSL復号は必須: 今やWebトラフィックの9割以上がHTTPSだ。中身を見ないSWGは、目隠しをして防犯カメラを監視しているのと同じ。適切な証明書配布と、プライバシーに配慮した復号ルールを策定せよ。
- 「誤検知」は勲章だ: 厳しく設定すれば、社内の正当な業務が止まることもある。その時、真っ先に「なぜ遮断されたのか」を即座にロギングから特定し、ホワイトリストへ追記するフローを自動化できれば、君はもう一人前のセキュリティエンジニアだ。
ネットワークは生き物だ。攻撃者は日々進化する。だが、パケットが通る仕組みや、通信の裏側にある「意図」を理解していれば、恐れることはない。
さあ、今日のログをチェックして、潜んでいる脅威をあぶり出そうじゃないか。何かあればまた聞きに来てくれ。
コメント