SSH と VPN の受信ルール：許可リストが実際に制御しているもの

ルールを変える前に一度接続し、クライアントがハングするのか即座に拒否されるのかを記録します。その一つの違いが、どの判断がパケットを落としたかを教えてくれ、ポリシーファイルを読む一時間を節約します。残りの道のりは短いものです。パケットはフックを通過し、ルールに一致し、リスナーに届くか届かないかになります。許可リストとは、その三つの事実を囲む記帳にすぎません。

一度の SSH 試行を入力フックまでたどる

クライアントはホストのアドレスのポート 22 に SYN を送り、カーネルはそのパケットがローカルサービス向けかどうかを判断します。そうであれば入力経路が実行され、ルールセットがパケットを受け入れるか破棄します。沈黙はリスナーが見る前に SYN が消えたことを意味し、素早い拒否は何かがリセットで応答したことを意味します。これらは別のルールによる別の判定であり、どちらも正当な結果です。

次にリスナーを確認します。存在しないサービスを救えるルールはないからです。ss -ltnp を実行し、期待するポートとアドレスファミリーに何かが結び付いているかを確認し、続いてクライアントで ssh -v を読んでどこで止まるかを見ます。

転送は別の判断です

VPN サーバーではより興味深いフックは forward です。クライアントの通信はマシンに届けられるのではなく、マシンを通ってルーティングされるからです。自分の VPN クライアントだけを動かすホストは、他人のパケットを転送するホストよりはるかに小さなルールセットで済みます。二つの設計を一つのマシンで混ぜると、正しく見えて何も通さないルールが生まれます。

内部ポリシーを独立した問いとして書きます。どのクライアントアドレスがトンネルを通ってどの宛先に到達してよいか。管理経路、たとえば SSH は、独自の送信元制限を付けて入力経路に置きます。試験中に追加した緩い forward ルールは、試験より長生きする典型的な欠陥です。変更後は編集した一行ではなくルールセット全体を見直してください。トンネルのリスナーを開くことは、接続したすべてのクライアントにホストの管理を許すことではありません。

drop と reject は動作であり、ポリシーではありません

ベースチェーンのポリシーは受け入れるか破棄するかで、選択肢はそれだけだと nftables のリファレンス も述べています。reject は応答を選べるルールの動作として存在するため、これをポリシーとして書くと nftables でも iptables でも失敗します。実際には drop はクライアントに何の情報も与えず、reject は対処できるエラーを返します。

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

そのスケッチは貼り付けるファイルではなく判断の形として読んでください。アドレス範囲は例だからです。SSH ポートに明示的な reject を置くと、権限のないクライアントはタイムアウトを待たずに一秒で失敗し、自分のデバッグが短くなります。沈黙は場当たり的なスキャンを抑え、権限のある利用者には何も伝えません。サービスごとに選び、理由を書き留めてください。さもなければ次の人が元に戻します。

本当に必要な制御トラフィックを残す

ICMP をすべて遮断するのは人気のある既定値ですが、経路 MTU 探索を壊します。症状は、接続が確立したあと大きなパケットで止まることです。IPv6 の近隣探索は独自の ICMPv6 タイプに依存しており、それを落とすと TCP のルールが参照される前にリンクが壊れます。どちらも包括的な許可ではなく、名前を付けた依存関係として許可リストに入れるべきものです。探索を黙って壊すポリシーは、多少の診断トラフィックを許すポリシーより悪いものです。

自分で開始した接続には established と related の状態を許可し、応答は状態を追うエンジンに任せます。そのうえで、応答経路が外側で遮断されていないことを確認してください。上流で外向きだけを制限すると、ホストのせいにしようとしていたのと同じタイムアウトが生じます。

古い経路を廃止する前に復旧を証明する

コンソールセッションを開いたまま変更を適用し、別のターミナルからまったく新しい管理接続を開きます。既存のセッションは何も証明しません。新しいログインをすべて遮断するルールを生き延びることがあるからで、これがファイアウォール作業で最も説得力のある偽陽性になります。監視システムがホストを確認している場合は、最初の警告の後ではなく変更の前にその送信元アドレスを追加します。その後、大きなパケットと小さなパケットを一つずつ試して、探索がまだ機能することを示します。

VPN サービスの場合は、一度も接続したことのないクライアントから繰り返します。再開したセッションは、新しいセッションが交渉しなければならない状態を再利用できるからです。通った正確なルールセットをチェックサムかコピーとともに記録し、後の編集を推測ではなく比較できるようにします。ルールの順序を持つ担当者と調整してください。以前のルールは、あなたが追加したルールに黙って勝ちます。