ファイアウォールの変更を、締め出されずに検証する

ルールを入れると、すでにつないでいる端末は応答し続け、次のログインは拒否される。このずれこそが、これから変える接続の上でファイアウォールの変更を試す難しさのすべてだ。コネクション追跡は一度だけ判断してその後は見なくなるので、確立済みのフローは新しいポリシーを見られない唯一の検査になる。以下では三つの戻り道を比べ、そのうえでルールを変更し確認する順序を定める。

生き残ったセッションが最も弱い証拠である理由

ステートフルなファイアウォールはフローの最初のパケットを評価し、その判定をエントリが生きている限り保持する。後から足したルールは、あとで始まるフローに適用される。だから、あなたが打ち込んでいるウィンドウは使えたままで、ほかの全員は拒否される。そこから学べるのは数分前のポリシーにすぎない。そのフローで撮ったキャプチャでさえ、マシンがすでに出した判断を映しているだけだ。

動いているセッションは計測ではなく非常口として扱う。意味のある検査はすべて新しいルールが評価する送信元から新しいフローを開く必要があり、最初の検査は失敗すると最も痛いものを選ぶべきだ。そのセッションが唯一の入口であるうちは、変更はまだ行う準備ができていない。

戻る三つの道を、何に依存するかで並べる

選択肢は、試験対象の装置にどれだけ依存するかで並べる。ルールが誤っていたときに頼るのは、その順位だからだ。ファイアウォールを一度も通らないコンソールは独立しており、演習済みのロールバックはほぼそうで、すでに開いているセッションはそうではない。

変更の前にコンソールでログインし、機能することを証明する。使ったことのない帯域外の経路は、代替手段ではなく図面でしかない。ロールバックは、その基盤で、そのルールセットのまま、承認された手順に従って演習してからでなければ座を得ない。本番機の上で即興してはならない。手順は書き出し、別の人に読み返してもらう。順序を完了するのにあなたの記憶が要るなら、それは計画ではない。

変更は一つ、そして評価されるべき接続

稼働中のルールセットと、それを所有するファイルを保存し、それから一つの狭い編集だけを行う。テストごとに変更を一つにすれば結果を帰属できる。同時に二つ変えると、動くマシンだけが残り、どちらの編集が効いたのか分からなくなる。基盤が設定を読み込まずに解析できるなら、まずそれを行い、何も失われないうちに打ち間違いを落とす。

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

次に、コンソールをつないだまま、変更したルールに一致する送信元から新しいセッションを始める。成功したらもう一度だけ繰り返す。最初の試行は、テーブルがすでに持っていたエントリに当たることがあるからだ。失敗しても、中に入る道と取り消す判断は残る。それが手に入る最も安い悪い結果だ。

カウンタ、状態、ファイルは別々の問いに答える

三つの観察はどれも単独では説得力に見え、ほかの二つについて誤らせる。カウンタは、いま作ったフローが編集したルールに届いたかを示す。状態テーブルは、マシンがすでに確立済みと考えるフローを示し、だから壊れたルールでも健康に見えることがある。保存したファイルは、次の再読み込み後に装置がどう動くかを示すが、それはいま動いているルールセットの動作とは違うかもしれない。

ss -tn state established

カウンタは合計ではなく差分として読む。意味があるのは、テストのフローが動かした数だけだ。カウンタが一度も増えないルールは、紙の上でどれほど正しく見えても一致していない。拒否のケースも確かめる。何も拒否したことのないポリシーは、塞ぎたかったものを拒否できると証明していない。展開が実際に運ぶ各ファミリで一つのインターフェースをたどる。v4 のルールは v6 のフローについて何も語らないからだ。

保存したルールセットから復元し、そのうえでファイルを一致させる

変更が失敗したら、ログインが再び通るまで許可ルールを足すのではなく、保存したルールセットを読み込む。許可を一つ足すたびに症状は静まり、インシデントとその記憶より長く残る穴が空く。復元し、再接続し、失敗した比較を試した内容の記録のそばに残す。

変更が成功したら、ディスク上のファイルが稼働中のルールセットを記述するようにし、再読み込みでそれが再現されることを確かめる。自分の設定ファイルからずれた稼働中のルールセットは、次の再起動のために仕掛けられた罠だ。