OpenBSD 7.7 を堅牢なファイアウォール基盤に：背中を預けられる pf.conf と sysctl.conf

OpenBSD は長年にわたり、妥協のないセキュリティ哲学で知られてきました。健全なデフォルト、クリーンなコード、そして「secure by default（デフォルトで安全）」をスローガンではなく作業指針として扱う姿勢です。日々の運用で信頼でき、挙動が説明できるファイアウォールを求めるなら、OpenBSD は強固な土台になります。同時に、強いデフォルトは素晴らしいものの、いくつかの狙いを定めた調整を加えるだけで、システムを脆い実験室に変えることなく、セキュリティ水準と予測可能性をはっきり引き上げられます。
本記事は、実運用に耐えるベースラインを提示します。小規模ネットワーク、ホームラボ、多くの中小規模のセットアップを確実に守りつつ、読みやすさと保守性を両立します。

ここでは、終わりのないチェックリストや恣意的な「チューニングのコツ」ではなく、根拠のある判断と明快な理由を示します。なぜそのオプションを有効にするのか、どんなリスクに対処するのか、どんな副作用を念頭に置くべきか。目標は、あらゆる理論上の攻撃を網羅することではありません。信頼できる出発点を提供することです――スリムな規則、少ない例外、明確なふるまい。

本ガイドの方針は一貫しています。明示的に許可したものだけ通し、それ以外は遮断。外から内へは、ルーター自身に必要なものだけを許可。内から外へは、あなたが本当に望むものだけを通す。DNS は可視かつコントロール可能に保ちます。DoH、DoT、DoQ、QUIC に抜け道は与えません――「見えない」チャネルを残さないためです。ステートは意図的にインターフェースへ結び付け、接続が発生した場所に留まるようにします。これによりシステムは予測可能になり、トラブルシューティングは耐えうるものになります。そして、10 個の小技より透明性を重んじます。クリティカルな経路にはすべてラベルを付け、運用中に「何が通っているか・何が落ちているか・どこを締めるべきか」を即座に把握できます。

実際に使いやすくするため、2 つの pf プロファイルを用意します。古典的な LAN→インターネットのためのルーター専用（router‑only）と、サービスを分離したいときのルーター＋DMZ（router+DMZ）です。クライアントの DNS は 1.1.1.1（任意で 1.0.0.1 をフォールバック）のみに強制します。これはこだわりではなく、可視性と制御を取り戻すための意図的な設計です。アプリが別経路を望めば、必ず目立ちます。そのうえで、どこに例外を置くかをあなたが判断できます。

sysctl.conf は、この姿勢をカーネルレベルで補強します。OpenBSD は初期状態でも十分に強力ですが、いくつかのスイッチで堅牢性の向上が測定可能になります。たとえば、典型的なメモリバグを早く、そして大きく失敗させる強い malloc 設定、サイドチャネルの恩恵がないなら SMT/ハイパースレッディングを無効化、危ういグレーゾーンで動かすよりW^X でプロセスをきっぱり落とす、リダイレクトや不要なトンネルをオフ、モダンな TCP 機能と穏当なレート制限でネットワークの「ノイズ」を抑制――いずれも派手な「裏ワザ」ではなく衛生管理です。攻撃面の縮小、サプライズの回避、負荷時の安定性につながります。

本記事のスコープ外：高度に特化した標的型攻撃、フルスタックの IDS/IPS。多層監視、プロトコルのディープインスペクション、脅威インテリジェンスを導入したい場合も、この設定は邪魔になりません。むしろ、基礎として上に積み上げやすくしてあります。また、複雑なマルチ WAN 政策、大量のポートフォワード、奇抜なオーバーレイネットワークといった話題もあえて扱いません。実現可能ですが、ベースラインの明快さを損なうためです。

読みやすさを重視するとは、仕組みで語り、魔法に頼らないということでもあります。リアルタイム系には静的 NAT（ポート固定）、それ以外は高いエフェメラルレンジ。QUIC は遮断し、DNS が TLS ストリームに紛れ込まないようにします。IPv6 はまず遮断し、「ハーフオープン IPv6」（クライアントは v6 を優先するのに、ファイアウォールが v6 を制御していない）を避けます――必要なら、後段で正しく有効化する手順を示します。また、運用で役立つ箇所はラベルでマークします。ログを派手にするためではなく、答えを得るためです。「誰が DoT を試みた？」「どのホストが anti‑rebind に引っかかった？」「どの通信が egress ブロックを叩いた？」

対象読者：管理を職人仕事と捉え、清潔な基盤に 1 時間を投じるほうが、奇妙な副作用を 3 週間追うより賢いと思う人。デフォルト許可に驚かされるのではなく、自分のネットワークを理解したい人。SOC/ブルーチームを回すほど大規模ではないが、「量販ルーター」では満足できない人。ここで提示するベースラインは魔法ではありません。筋の通った標準です――小さく保てて、長く保てる。

脅威モデル：何に備え、何は備えないか

このベースラインは、専任のブルーチームがいない一方で、信頼できる標準を求める環境を想定しています。日々あなたの境界にぶつかってくる典型的な事象――大規模スキャン、機会主義的なエクスプロイト、（「DNS over 何でも」のような）プロトコルの濫用、誤設定、データ流出を招く緩い egress ポリシー――を抑えます。任意のサーバは DMZ に封じ、LAN への横移動を防ぎます。フォーカスしないのは、高度に特化した標的型攻撃や完全な IDS/IPS スタックです。これらは後から基盤の上に積み上げられます。

設計原則：小さな攻撃面、明確な責務

将来の拡張でも役立つ、いくつかの指針に従います。

Fail‑closed（明示以外は閉じる）。明示的に許可されないものは、すべて閉じる――インバウンドもアウトバウンドも。テストの初期段階で、アプリが本当に必要としているものが見え、主導権を握れます。

決定論的ステート。if-bound によって、接続は発生インターフェースに縛られます。シングル WAN ルーターでは、魔法のような「フローティングステート」を追い回す必要がなくなり、トラブルシューティングが容易になります。

Egress の最小化。内から外へは必要最低限のみ：クラシックな Web、メールのサブミッション、VoIP/WebRTC 用の明示した UDP レンジ――そして DNS はあなたが決めた行き先だけ。

透明性＞当て推量。QUIC をブロックし、DoH/DoT/DoQ もブロックします。ある種のアプリに不便かもしれませんが、代わりにクリアな見通しを得ます。DNS は DNS、TLS は TLS。影の DNS が必要なら、すぐに目につきます。

頑健なデフォルト。スクラビング、MSS 上限、ランダム化された IP‑ID、ボーゴンフィルタ、アンチスプーフィング、TCP フラグの衛生、ICMP と RST の妥当なレート制限――どれも派手ではありませんが、組み合わされば強い衛生です。

IPv6 は意図して。IPv6 はデフォルトで無効。必要なら本文で手順を示します。**「半開きの IPv6」**は一貫して避けます。

sysctl.conf — カーネルで効く安全レバー

OpenBSD のデフォルトは優秀ですが、少数の設定で安全性と予測可能性をはっきり底上げできます。終わりなき一覧ではなく、明快な理由を添えて要点のみ。

メモリのハードニング（vm.malloc_conf=CFGJRS）。ガードページ、ジャンクパターン、レッドゾーン、カナリアにより、古典的なメモリバグの悪用を難しくし、プロセスを「大きな音を立てて」失敗させます。ルーター用途では、このオーバーヘッドはほぼ常に見合います。

CPU/ハードウェア：SMT を切り、aperture を閉じる。hw.smt=0 は（ハイパースレッディングの）サイドチャネルリスクを下げ、ルーターではスループット低下は小さいことが多い。machdep.allowaperture=0 は /dev/mem 的な近道を塞ぎます。ヘッドレス機には最適。X11/KMS が必要なら自明ですし、そうでなければ閉じたままで。

ルーティングとプロトコル：IPv4 は有効、IPv6 は意図的に無効。net.inet.ip.forwarding=1 で IPv4 ルーターに。net.inet6.ip6.forwarding=0 で「偶発的な」IPv6 ルーティングを防止。加えて、IP‑in‑IP、GRE、ESP/AH、EtherIP など不要なトンネルを無効化。暗号化・カプセル化の機械を減らすほど、攻撃面と意外な挙動は減ります。

レガシーな落とし穴の無効化。ディレクテッドブロードキャストはオフ、リダイレクトは（IPv4/IPv6 ともに）無視。ICMP リダイレクトは古典的な地雷です。経路を変えたいなら、ルーティングや PF で明示的に行うべきです。

節度ある ICMP。ブロードキャスト echo には応答せず、timestamp/netmask にも応答しない。エラーパケットには妥当なレート制限を。DDoS ノイズを抑えつつ、正当な機能は壊さない。ICMP は敵ではありません。ただしガードレールは必要です。

魔法に頼らない UDP/TCP の強化。UDP のチェックサムは必須。ソケットバッファは現実的な値に。TCP は window scaling、timestamps、SACK を有効に保ち、安定性を高める。ECN は有効。現代のネットワークでは問題になりにくく、混雑時に効きます。SYN キャッシュ/バケットの上限や RST のレート制限で、典型的なスキャンの波を吸収します。

キュー、BPF、W^X。長めの if‑queue は突発時のドロップを減らします。大きめの BPF バッファは、将来のあなた（デバッグ時）への贈り物。kern.wxabort=1 は W^X を厳格に適用します。コードは書けるか実行できるかのどちらかで、両方は不可。違反すればプロセスは終了――まさに fail‑closed。スワップ暗号化はオンのまま。機微な残骸が平文でストレージに落ちることを防ぎます。

この sysctl セットは意図的に地味です。「たいてい動く」から「ストレス下でも一貫したふるまいへ」。sysctl -f でクリーンに読み込み、sysctl -n net.inet6.icmp6.errppslimit、netstat -m、pfctl -s memory などのカウンタを確認。mbuf/cluster の予算をいじるなら、PF の set limit frags など連動する上限の再調整を忘れずに。

pf.conf：説明できるルール

pf の可能性は無限大です。ここでのベースラインは、堅牢な標準を成立させるのに必要な分だけを取ります――多すぎず、少なすぎず。

マクロ、テーブル、ラベル――構造が半分。まずはインターフェースとネットワークを明確に定義：WAN、LAN、（必要なら）DMZ。bogons / abusers / scanners 用のテーブル、そして疑わしい DoH エンドポイントのウォッチリストも用意。これは飾りではありません。persist によりリロードをまたいで生存し、overload で騒がしい送信元を自動収容します。規則に一貫したラベルを付けておけば、重い pcap を使わずとも運用の可視性は一級品。pfctl -vvsr や systat pf を見れば、「どこに脈があるか」が分かります。

グローバルオプション――予測可能性。set block-policy drop と最適化「aggressive」は妥当な保守的デフォルト。set state-policy if-bound は接続を入り口インターフェースへ係留します。state / frags / src‑nodes の上限、アダプティブなタイムアウト、そしてsyncookies の適応的有効化を設定。増水時に効いてきます。loginterface は WAN の統計を出し、set skip on lo0 は「自傷」を避けます。
pf は標準で IPv6 をブロックします。sysctl の方針に沿い、「半開き IPv6」を避けるためです。IPv6 を実運用で使いたいなら、意図的に、見える形で開けます。

WAN の ICMP（インバウンド）：健康維持のために十分な開放。WAN では echo と「unreachable」だけを state 付き・レート制限付きで許可します。MTU/パス問題の診断を容易にしつつ、ping フラッドから守ります。その他――特にリダイレクト――はオフのまま。

スクラビング：フラグメントを減らし、苛立ちを減らす。進出両方向でスクラブ：ランダムな IP‑ID、控えめな最小 TTL、MSS を 1440 に（実地で「ちょうどよい」値）、TCP 再組立て。怪しいフラグメントで state が詰まるのを防ぎ、PMTU 関連のつまずきを抑えます。これがあるので、sysctl で MSS を触る必要はほぼなくなります。

NAT：リアルタイムは静的、その他は動的。UDP は静的ポートを使います――VoIP/WebRTC、ゲームなどリアルタイム系に効きます。その他は高いエフェメラルレンジで、トレースしやすく、衝突もしにくい。NAT は明示した管理行き以外のすべてに適用――想定外の抜け道をなくします。

アンチスプーフィング、ボーゴン、ゼロポート。antispoof を全インターフェースで。壊れたソースルートで WAN に来たパケットは即時ドロップ。bogons はインもアウトもブロック。たとえば 10/8 や 127/8 からインターネットへ出ようとするのは、たいてい別の問題の表れです。ポート 0 や不自然な TCP フラグ も掃除。ロケット科学ではありませんが、「クリエイティブ」なスキャナ相手に余計な苦労をせずに済みます。

デフォルト拒否：大掃除の一撃。衛生処理が済んだら、block all で鋭く切り分け。ここから先は意図的な例外だけが通ります。

WAN インバウンド：ルーター自身に必要なものだけ。上流が必要とする場合に限って、インバウンド DHCP を許可。それ以外は遮断。インターネットから到達可能な公開 DMZ は、このベースラインの目的ではありません。その場合はごく少数のポートフォワードを意図的に定義してください。

QUIC：HTTP/3 は外に。WAN の UDP 80/443 をブロックし、QUIC への酸素を断ちます。なぜ厳しく？ QUIC は快適なトンネルだからです――DoH 亜種や「全部ひと流し」のトリックにも都合がいい。後に明確な理由で特定宛先への HTTP/3 を許可したいなら、外科的に例外を開けましょう。ベースラインはまず透明性を重視し、速度はその次です。

DoH/DoT/DoQ の可視化――境界は明確に。DoT（853/TCP） と DoQ（784/UDP） はアウトバウンドで遮断、インバウンドはログ。LAN/DMZ 内では、既知の DoH 宛の TLS をラベルでマーキングします（方針は変えません。厳格モードを選ぶなら別）。要点は：クライアントの隠れ DNS の試みが見えること。

ファイアウォール管理アクセス：狭く、緩やかなレート制限付きで。LAN→ファイアウォールの SSH は、state とフラグ衛生、控えめのレート制限付きで許可。上流の管理（例：モデム/ルーターの GUI）にはピンポイントの pass を。小さな接続レート制限で誤操作のスプレーを抑えます。ラベルで常時可視化します。

ローカルリゾルバなしの DNS 方針：願うのではなく、強制する。要点：LAN（と必要なら DMZ）のクライアントは 1.1.1.1（任意で 1.0.0.1） の 53/TCP+UDP にのみ到達可能。他の 53 宛は遮断して記録。これは「便利オプション」ではなく可視性の核心です。他のリゾルバや DoH/DoT/DoQ の試みはすぐ分かります（後者は別途ブロック）。外部リゾルバはいつでも置き換え可能。仕組みは同じです。

DMZ：裏口も近道も作らない。DMZ 変種では、DMZ 内部の横通信なし、LAN への戻りなし。そこにいるサービスのためのピンポイント egress（クラシック Web、メールサブミッション、VoIP/WebRTC 用 UDP レンジ）のみ許可。DMZ から上流 GUI への経路は禁止。侵害されたサーバが管理ネットに触れるのを防ぎます。その他は遮断してログ。足りないボルトを素早く見つけるためです。

アウトバウンドリスクの抑制：古典をまず閉じる。外向きは、定番の危険どころ――SMB/NetBIOS、RPC/NFS、TFTP、SNMP、RDP/VNC/WinRM、野良 SMTP――をブロック。これらは内部や明示経路では役立ちますが、インターネットへは原則不要。例外が要るなら、意識的に開け、ラベルを付けましょう。

ファイアウォール自身：出てよい、ただし見える形で。アップデート、パッケージ、診断のため、ファイアウォール自身の外向きは許可（state/上限/ラベル付き）。ただしやり過ぎは禁物。この箱はルーターであり番犬であって、ブラウザ端末ではありません。

Anti‑rebind、LAN→DMZ、最後の掃除。LAN と DMZ の間は、明示した経路のみ（例：クライアント→DMZ サービス）。逆方向は閉じたまま。Anti‑rebind は、ファイアウォール越しの DNS トリックで内側の保護対象に到達するのを防ぎます。その他の場面では、PF ははっきり NO と言います――適切な箇所では return で、失敗を速やかに見せ、調査を楽にします。

ルーター専用 vs ルーター＋DMZ：どちらを選ぶ？

単に LAN をインターネットに接続したいだけなら、ルーター専用が最適です。コンパクトで分かりやすく、しかし硬い。アンチスプーフィング、ボーゴンフィルタ、厳格な egress、1.1.1.1/1.0.0.1 への DNS 強制、DoH/DoT/DoQ/QUIC のコントロール、LAN→ファイアウォールの管理 SSH、そしてスクラブ/ステート/上限の整ったデフォルトが得られます。

サービスをホストする（たとえ内部向けだけでも）なら、ルーター＋DMZ が有効です。DMZ は事故を閉じ込め、侵害されたサービスが LAN への踏み台になる確率を下げます。DMZ 内部通信は閉じ、egress はホワイトリストで LAN より狭く。DNS は同じく厳格。NTP は本当に必要になるまで開けません。

IPv6 を正しく有効化する

ベースラインはIPv6 を遮断し、「半開き」を避けます。必要なら、意図的かつ一貫性をもって有効化します。sysctl でルーティング、pf に inet6 の対応規則、クリーンな egress 設計（そう、v6 でも DNS 強制）、RA/DHCPv6 の方針を明確に。v4 の良い考えを鏡写しにしてください：アンチスプーフィング、デフォルト拒否、QUIC/DoH/DoQ の扱い、見える例外――それ以上でも以下でもない。要点：こっそり v6 を入れない。やるならきちんと、そうでないならまだやらない。

運用・診断・フォレンジック：測る、当てずっぽうにしない

厳格な方針が良いのは、日々読めるときだけ。pf は 3 つの経路で助けます。

ラベル。重要なルールにはすべてわかりやすいラベル。pfctl -vvsr で、どの経路が使われ、どれがブロックされ、どこで衝突しているかが見えます。多くの場合、これだけで原因が絞れます。

テーブル。pfctl -t <table> -T show で abusers/scanners の中身を確認。overload は、クライアントが過剰に接続を張ると自動でテーブルに収納します。罰ではなくシートベルトです。

最小限の pcap。tcpdump は友人ですが、目的を持って使いましょう。DNS/DoH の可視化なら、次のような短い一瞥で足りることが多い：
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
これは計画のあるフォレンジックであって、「目に涙が出るまで Wireshark」ではありません。

健全なテスト作法。ルールを変えたら、まず 読み込みなしでコンパイル：pfctl -nf /etc/pf.conf。その後 pfctl -f。もし問題が起きたら、ラベルとテーブルが修正の手がかりに。DNS 強制の検証：drill @1.1.1.1 openbsd.org は成功し、drill @9.9.9.9 openbsd.org はブロックされるべき。QUIC の検証：curl -I --http3 https://example.com がUDP で行かず、HTTP/2 にフォールバックすること。DoT/DoQ は、1.1.1.1:853 と UDP 784 への試行が失敗し、ラベル付きルールのカウンタが増えるのが見えること。

egress 変更のコツ。何かを開けたら、そのルールに一時的に非常に明確なラベルを付け、1 週間後に実際に使われているか確認。使われていなければ削除。ベースラインを軽量に保てます。

パフォーマンス――伝承ではなく事実で

このセットアップは「攻めのチューニング」ではなく、安定性へ寄せています。いくつかの帰結を理解しておきましょう。

QUIC のブロックで、一部サイトはわずかに遅くなるかもしれません。これは意図的なトレード：可視性を速度より優先。HTTP/3 を許可する妥当な理由があるなら、外科的に（対象をテーブル化し、ラベルを付ける）開けます。

ECN 有効は現代のネットワークではほぼ無害。エキゾチックなミドルボックスが嫌うなら、すぐ気づけます。その場合は個別に無効化してください。ベースラインが邪魔をすることはありません。

UDP の静的 NAT ポートはリアルタイム系に効く切り札。WebRTC のトラブルを追ったことがある人なら、金の価値が分かるはず。コストはほぼありません。UDP ポートのランダム化は安全機能ではないと理解するだけです。

if‑queue と BPF バッファは実用的な大きさに。ピークに耐え、デバッグセッションが 4KB バッファで窒息しない程度の余裕。もし本当にスループットの限界を狙うなら、計測してから調整を――逆ではありません。

よくある落とし穴――上品に切り抜ける

「うちのアプリは DoH でしか動かない！」 → ならば例外が要るか、より良いのは正直な評価です。DoH 自体は悪ではありませんが、家庭/企業ネットのコントロールには不利です。特定ホストを許可テーブルに入れ、意識的な例外に留めましょう。全面開放はしない。

「ビデオ通話が途切れる」 → まずはプロバイダ（Zoom/Teams/WebRTC）の UDP レンジをカバーしているか確認。静的 UDP ポートは助けになりますが、適切な egress コリドーがなければ効果はありません。狙い撃ちで調整しましょう。

「メールクライアントが直接送信できない」 → 正しい挙動です。25/tcp（outbound） は閉じています。メールは submission（465/587） で自分のプロバイダ/サーバへ。インターネットへ直投は不可。必要なら submission ポートをラベル付きで許可します。

「IPv6 が突然おかしい」 → このベースラインでは v6 は遮断。クライアントが v6 を優先し、ファイアウォールが v6 をルーティングしないとタイムアウトが発生します。正しく v6 を有効化（規則も用意）するか、RA/ND で「ここは v6 まだなし」と明示しましょう。

「ルール変更後に変な挙動」 → ステートを思い出してください。古いステートは生き残るのがデフォルト。基本方針（例：外向きポートの開放）を変えたなら、該当ステートを選択的に消す（pfctl -k ...）、あるいは必要なら全消し（pfctl -F state）。その後、世界は再整合します。

このベースラインが「安全」な理由――ここでの安全の意味

安全は絶対ではありません。しかし、目標を明確にし、道筋を正直に検証すれば、測定可能です。このベースラインは攻撃面を縮めます。なぜなら――

あらゆるインバウンド露出を最小化する

アウトバウンドを例外へと位置づける

DNS を強制し、可視に保つ

QUIC/DoH/DoT/DoQ といった秘匿経路を塞ぐ

リダイレクトやブロードキャストのような擬似機能を無効化する

堅牢な TCP/ICMP デフォルトを適用する

ステート処理を決定論的にする

そして、日々の観測に使える道具を与える

一方で、構成はメンテしやすいままです。3,000 行あるから安全なのではなく、すべての行を説明できるから安全なのです。

マイグレーション：進め方

既存の pf 構成があるなら、段階的に。

1. まず sysctl。 サービスを落とさないハードニングをロード。ICMP/RST の異常なノイズがないかログを確認。
2. pf ポリシーを並走テスト。 pfctl -nf で構文確認し、ラボやメンテナンス窓で試験。初回有効化時は、LAN→ファイアウォールの SSH を確保――自縄自縛はつらい。
3. egress を締める。 DNS 強制を有効化して観察。その後、古典的な高リスクサービスを段階的に閉じる。1〜2 週間のモニタが盲点発見に効きます。
4. DMZ を導入（必要なら）。 サービスを移し、intra‑DMZ と DMZ→LAN は閉じたまま。本当に必要な egress だけ開ける。観察し、磨く。
5. IPv6 は意図して決める。 きちんと有効化するか、閉じたままクライアントに明示するか。

各段階で、安全性は上がりますが、危険なビッグバンにはなりません。

後から簡単に拡張できること

このベースラインは基礎であって檻ではありません。典型的な拡張：

• 妥当性の検証された理由がある場合の、QUIC/DoH への外科的例外（常にテーブル＋ラベルで管理）
• サイト間 VPN（Site‑to‑Site） を最小攻撃面で――デフォルトの sysctl は邪魔しません。プロトコルを明示許可すればよい
• 監視／アラート。pf カウンタや systat pf は基本メトリクスに十分。必要に応じて pf ログを集中管理へ
• IPv6 を v4 のロジックで完全に鏡映（付け足しにしない）

アップグレードと保守

OpenBSD は約束を守ります――が、毎回のアップグレードでリリースノートを読みましょう。特に pf の構文やカーネルデフォルトの変更点。ラベル・テーブル・明快なマクロは、バージョン間の検証を素早くしてくれます。すべての例外にコメントを付けるという規律を守りましょう。「なぜ存在するのか、誰が必要としているのか、最終レビューはいつか」。例外それ自体は悪ではありませんが、無注記の例外は技術的負債です。

まとめ：明快さこそ最良のハードニング

このベースラインの狙いは単純です。複雑さより、明快さ。日々の運用で予測可能に動く OpenBSD ファイアウォールを手に入れ、攻撃面を小さく保ち、ラベル／テーブル／妥当なデフォルトで「実際に何が起きているか」をいつでも可視化できます。暗黙の副作用ではなく、明示的な意思決定を優先：厳格な egress、定義済みリゾルバへの DNS 強制、QUIC/DoH/DoT/DoQ による静かな抜け道は不許可、決定論的なステート、堅牢なカーネル設定。これは学術デモではありません。安心して積み増せる出発点です。

重要な点として、このベースラインはあえて、ローカルリゾルバやローカル NTP サービスを前提にしません。追加インフラなしで素早く安定運用に乗せたいセットアップを想定しています。後からオンプレのコントロールを厚くしたくなったら、摩擦なく追加可能――基盤の姿勢を崩さずに拡張できます。

探し回らなくて済むように：本文の下に完全な構成案を用意しました。pf.conf は 2 つのプロファイル（DMZ なしのルーター専用と、強い隔離のあるルーター＋DMZ）、そしてハードニング済みの sysctl.conf。ここまでの記事は判断の理由を説明しています。下のファイルは、それを一字一句実装しています。**「検証 → ロード → 計測」**の順を守れば、すぐに再現性のある結果に到達できるでしょう。

最後に、スコープについての正直さも大切です。ここでは、高度な標的型攻撃や完全な IDS/IPSは対象外です。放棄せよという意味ではありません。むしろ、秩序立てて追加しやすい基盤ができました。実運用では、3 つの拡張ルートが有用であることが分かっています。

もし、特定のルールをさらに鋭くできるアイデアがある、特殊要件がある、もしくは運用上の観察結果を共有したい――という場合は、ぜひ連絡ください。現場のフィードバックこそ、意味のある改善の最良の触媒です。次回以降の拡張にも反映していきます。セキュリティはプロセスであり、短距離走ではありません。明快なベースラインと経験を共有するコミュニティがあれば、「良い」はすぐに「とても良い」に変わります。

sysctl.conf をダウンロード：https://www.protectstar.com/download/blog/sysctl.txt
pf.conf（DMZ あり）をダウンロード：https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
pf.conf（DMZ なし）をダウンロード：https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt