nftables動的セット活用による本番IP遮断自動化と整合性検証フロー

動的セットが注目される背景と iptables との違い

Linux のパケットフィルタリング基盤は、長らく iptables が担ってきました。しかし 2026年現在、主要なディストリビューション（Debian 12・Ubuntu 24.04・RHEL 9 系）はいずれも nftables をデフォルトのファイアウォールフレームワークとして採用しています。nftables が現場で支持される理由のひとつが、動的セット（dynamic set）の仕組みです。

iptables でIP遮断を自動化する場合、スクリプトから iptables -I INPUT ... を繰り返し呼び出す方式が一般的でした。この方式はルールの追加ごとにカーネルとのやり取りが発生し、大量のエントリを扱うと顕著な遅延が生じます。また設定全体の原子性が保証されないため、スクリプト実行中にパケットが意図しないルールを通過するリスクもありました。

nftables の動的セットはこの問題を構造的に解決します。セット（IPアドレスや範囲の集合）とルール（セットへの参照）を分離することで、ルール自体を変更せずにセットのメンバーだけを動的に追加・削除できます。エントリ操作は nft コマンドひとつで完結し、カーネル内のルックアップも O(1) に近いハッシュテーブルで処理されるため、数万エントリでもレイテンシへの影響は無視できるレベルに収まります。

動的セットの定義とルール設定の基本構成

まず nftables の設定ファイル（/etc/nftables.conf）に、動的セットとそれを参照するルールを定義します。以下は実務でよく使われるシンプルな構成例です。

table inet filter {
    set blocklist {
        type ipv4_addr
        flags dynamic, timeout
        timeout 1h
        gc-interval 5m
    }

    chain input {
        type filter hook input priority filter; policy drop;
        ip saddr @blocklist drop
        ct state established,related accept
        iif lo accept
        tcp dport { 22, 80, 443 } accept
    }
}

flags dynamic を指定することで、実行時に nft add element コマンドでエントリを追加できるようになります。timeout フラグと timeout 1h の組み合わせにより、追加から1時間後にエントリが自動削除されます。これは一時的な遮断に適しており、永続遮断が必要な場合は timeout フラグを外した静的セットを別途用意して使い分けるのが現場の定石です。

設定を有効化するには nft -f /etc/nftables.conf を実行し、その後 systemctl enable --now nftables でサービスとして起動します。RHEL 9 / AlmaLinux 9 環境では firewalld が nftables のフロントエンドとして動作しているため、直接 nft コマンドを使うと設定が競合します。この場合は firewalld を停止するか、firewalld の --direct ルールまたは ipset 連携を経由するか、用途に応じて判断が必要です。

自動遮断スクリプトと systemd タイマーによる連携フロー

動的セットの真価は、外部の検知ログを読み込んでリアルタイムにエントリを追加する自動化フローにあります。以下は Nginx のアクセスログから HTTP 429 / 400 を多発しているIPを抽出して遮断する例です。

#!/bin/bash
# /usr/local/sbin/nft-block-abuser.sh
LOGFILE=/var/log/nginx/access.log
TABLE=inet
SET=blocklist
THRESHOLD=100
WINDOW=5  # 過去5分

START=$(date -d "-${WINDOW} minutes" +"%d/%b/%Y:%H:%M" 2>/dev/null || \
        date -v -${WINDOW}M +"%d/%b/%Y:%H:%M")

awk -v start="$START" '
  $0 ~ start, 0 { print $1 }
' "$LOGFILE" | \
grep -E ' (429|400) ' "$LOGFILE" | \
awk '{ print $1 }' | sort | uniq -c | \
awk -v thr="$THRESHOLD" '$1 >= thr { print $2 }' | \
while read -r ip; do
    nft add element $TABLE $SET "{ $ip }" 2>/dev/null || true
    logger -t nft-block "Blocked abuser: $ip"
done

スクリプトは chmod 750 で保護し、root または専用サービスアカウント（nftadm 等）で実行します。systemd タイマーと組み合わせて5分ごとに走らせるには、以下の2ファイルを /etc/systemd/system/ に配置します。

# nft-block.service
[Unit]
Description=nftables abuser block

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/nft-block-abuser.sh
User=root

# nft-block.timer
[Unit]
Description=Run nft-block every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
AccuracySec=30s

[Install]
WantedBy=timers.target

systemctl enable --now nft-block.timer で有効化します。cron と比べて systemd タイマーを選ぶ利点は、依存関係管理・ジャーナルへの出力・実行失敗時の通知が標準で利用できる点です。

整合性検証フローの設計と継続運用

自動化を本番に投入した後は、設定が意図通りに機能し続けているかを定期的に検証する仕組みが不可欠です。現場では次の3段階を検証フローとして組むケースが増えています。

• 構文・ロード検証： nft -c -f /etc/nftables.conf でドライランを実行し、設定ファイルの構文エラーを CI/CD パイプラインまたはデプロイ前フックで検出します。
• セット状態の整合性確認： nft list set inet filter blocklist の出力をパースし、エントリ数・タイムスタンプ・フラグが期待値と一致するかをチェックします。異常な急増（DDoS 時の誤検知連鎖など）を検出するための上限閾値も設定しておくと安全です。
• 実効性テスト： 専用のテスト用IPアドレス（本番ネットワーク外の検証ホスト）を手動でセットに追加し、そのホストからの疎通が確かに遮断されることを定期確認します。月次の変更作業前後に実施するのが標準的な運用です。

整合性チェックのスクリプトを別の systemd タイマー（例：nft-verify.timer、OnCalendar=hourly）で走らせ、エラーを systemd-cat でジャーナルに記録すれば、journalctl -u nft-verify 一発で状態履歴を確認できます。Prometheus + node_exporter の textfile コレクタと連携させてメトリクス化し、Grafana で可視化する構成も、監視基盤が整っている現場では一般化しつつあります。

切り戻し手順と誤遮断発生時の対処

自動化の最大のリスクは誤遮断です。特に正規ユーザーや監視ホストがセットに入ってしまうケースは、検知が遅れると障害に直結します。以下の対策を事前に組み込んでおくことが重要です。

ホワイトリストセットの優先適用： input チェーンの先頭に ip saddr @whitelist accept を置き、監視IPや管理踏み台のアドレスを静的セットで保護します。動的セットへの追加スクリプト側でもホワイトリストとの突合チェックを入れることで二重に保護できます。

即時削除コマンドの周知： 特定のIPを手動でセットから削除するには nft delete element inet filter blocklist { 203.0.113.1 } を実行します。このコマンドをオペレーションWikiに記載し、オンコールメンバー全員が迷わず実行できる状態にしておくことが運用上の基本です。

フルフラッシュ（緊急時）： 大規模な誤遮断が発生した場合は nft flush set inet filter blocklist でセット内の全エントリを即座にクリアできます。その後 journalctl -u nft-block --since "1 hour ago" でログを確認し、原因となったスクリプトの判定ロジックを修正してから再有効化する流れが標準的な切り戻し手順です。

2026年現在の環境差分と今後の動向

2026年時点で注意が必要な環境差分をまとめます。

Ubuntu 24.04 LTS では ufw バックエンドが nftables に切り替わっています。ufw enable と直接 nft コマンドを併用すると設定が上書きされる場合があるため、どちらか一方に統一することが推奨されます。

Debian 12 Bookworm では nftables.conf のデフォルト配置が /etc/nftables.conf に統一されており、旧来の /etc/nftables/ ディレクトリ形式からの移行が完了しています。既存サーバーを Debian 11 からアップグレードした場合、古いインクルードパスが残っていないか確認が必要です。

カーネル側では Linux 6.4 以降でセットの並行操作性能が改善されており、高トラフィック環境でのエントリ追加時のスパイクが従来より小さくなっています。Raspberry Pi OS（Bookworm ベース）を含む ARM 環境でも同様の改善が恩恵として得られます。

Fail2ban との統合については、バージョン 1.1 以降で nftables アクションが標準バンドルされています。独自スクリプトを書かずに banaction = nftables-multiport を指定するだけで動的セットへの連携が完結するため、SSH や Postfix などの既存の Fail2ban ルールを流用したい場合はこちらのほうが保守コストを抑えられます。一方、ログ形式や判定ロジックを細かくカスタマイズしたい場合は本記事で示した独自スクリプト方式の柔軟性が活きてきます。

nftables の動的セットは、iptables 時代の「ルールの肥大化」という構造的な課題を解消しつつ、自動化と整合性検証の両立を現実的なコストで実現できるアーキテクチャです。本番環境への適用に際しては、ホワイトリストの事前整備と切り戻し手順の文書化を必ず並走させることで、自動化のメリットを安全に享受できます。