新しいUFWルールと古い接続：確立済み状態が優先される

拒否ルールを追加したのに開いているダウンロードが続くのは、UFWのバグではありません。追加したルールはすでにそのフローを許可したルールの後ろにあり、以前に確立した接続はそれらに一致し続けます。修正するには正しい位置に挿入し、先行ルールが何を約束しているかを理解する必要があります。その変更を狭く行う方法を以下に示します。

決めるのは順序であり、ルールの存在ではない

UFWはnetfilterのルールを段階的に書き込むフロントエンドです。ユーザールールの前に走るフレームワーク部分、次にユーザールール自体、その後に走る部分という順序です。標準の先行ルールは確立済みおよび関連する接続の通信を許可し、それらのルールは通常のallowやdenyで追加したものより先に評価されます。UFWのコマンドリファレンスには、挿入の構文と、この変更が依存する番号付きの状態表示が記載されています。

その順序が驚きを説明します。新しいルールは実在し、正しいテーブルにありますが、パケットが出会う最初の判断ではありません。すでに確立済みとして追跡されている接続はそこに到達しません。

この作業にはrouteルールを使います。パケットはゲートウェイ自身のサービス宛てではなく、ゲートウェイを通って転送されるからです。inputルールでは誤った通信を絞り込むことになり、何もしていないように見えます。

広い許可の上に挿入する

適用する前に挿入内容をプレビューし、同じルールがリストの他の場所にすでにないか確認します。同一のポリシーを重複させると後からの削除があいまいになり、間違ったコピーを消した人は何週間も気づきません。

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

プレビューで期待した位置にちょうど一つのルールが表示されたら、dry-runフラグなしで同じコマンドを適用します。位置1は、先に確認したフレームワークルールの上ではなく、より広いユーザー許可の上に置きます。インターフェース名がこのゲートウェイのトンネルデバイスと一致することを確認してください。存在しないインターフェースに紐づいたルールはリストに残り、正しく見えながら何にも一致しません。適用前にデバイスの参照を改名し、テストが失敗してから直すのではありません。

そのルールには宛先ポートがないため、HTTPSだけでなくそのアドレスのすべてのTCPポートを拒否します。目的が一つのサービスならポートを明示してください。ポリシーより広いルールは、最初の読者を待つ将来のインシデントです。

送信元を単一アドレスに絞るのは、そのアドレスが想定された身元に結びついている場合だけにします。動的割り当てのVPNプールは明日同じアドレスを別のクライアントに渡すことがあり、拒否は人ではなくアドレスを追いかけます。

確立済みフローは新しいルールを生き延びる

既存のセッションが続くのは接続追跡のためです。フローが確立済みとして記録されると、先行ルールはあなたの拒否を参照する前にそのパケットを許可し、転送は何も変わらなかったかのように終わります。したがって、開いた接続を再利用するブラウザでのテストは新しいポリシーについて何も教えてくれません。拒否は展開直後に役立たずに見え、次に接続するユーザーには完全に効いていることがあります。

要件に進行中の通信の切断が含まれるなら、このユーザールールの変更では実現できません。追跡された状態の取り消しは影響範囲の異なる別の操作であり、ルールを追加した人ではなくファイアウォールの所有者に属します。一つのセッションを消すためにゲートウェイの全接続を流し切るのは、二次インシデントを生む修正です。

境界も忘れないでください。このルールはICMP、UDP、IPv6については何も述べていないので、pingの成功は拒否が失敗した証拠になりません。IPv4アドレス一つもウェブサイトではありません。名前は複数のアドレスに解決されることがあり、指定した一つだけが対象です。

新しいフローでテストする

番号付きのユーザールールと有効な生の表示を読み、選択したクライアントから新しい接続を開きます：

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

生の表示が重要なのは、statusが手書きのフレームワークルールを省くため、順序がカーネルの適用するものと違って見えることがあるからです。ルールが間違った場所にあると結論づける前に、両者を比較してください。

次に、ルールが広くなく狭いことを証明する二つの対照を確認します。同じクライアントからの許可された宛先は引き続き機能し、二番目のクライアントはポリシーが許せば拒否された宛先に依然として到達します。両方のテストを壊す拒否はポリシーの変更であり、的を絞った措置ではありません。

テストが終わったら、追加したルールだけを正確に書き直して削除します。ポリシーが恒久的なら、クライアントの身元、宛先の所有者、レビュー日とともにファイアウォールの所有者に引き渡してください。再割り当てされたトンネルアドレスが古い拒否を残さないようにするためです。