手当たり次第に書くんだ

飽きっぽいのは本能

Ubuntu 26.04 nftables の基本設定 – OS firewall の責務と通信制御

作者: si62512548投稿日: カテゴリー: Ubuntuタグ: , , , , , , , , Ubuntu 26.04 nftables の基本設定 – OS firewall の責務と通信制御 へのコメントはまだありません

Ubuntu 26.04 でサーバーの通信を OS 側で制御する場合、nftables は基本になる機能です。複数 NIC、VLAN、Bonding、Bridge、Policy Based Routing、Reverse Path Filtering を整理した後は、どの通信を許可し、どの通信を拒否するのかを firewall として明示する必要があります。

この記事では、Ubuntu 26.04 Server で nftables を使う時の考え方を整理します。単に設定例を貼るのではなく、input、forward、output の責務、IPv4 / IPv6 の扱い、SSH を閉じないための確認、PBR や Bridge / FRR との関係を分けて考えます。

Ubuntu 26.04 サーバー管理ガイドに戻る
この記事で確認すること
参考書籍
参考書籍
ストーリーで覚える Linux CLI 入門
Ubuntu Server のネットワーク確認、CLI 操作、設定ファイル管理を押さえたい場合の参考書籍です。
Amazon で見る
このリンクは Amazon アソシエイトリンクです。

nftables は OS 側の firewall である

nftables は、Linux の packet filtering / NAT / mangling を扱う仕組みです。古い環境では iptables が使われていましたが、現在の Linux では nftables を前提に考える場面が増えています。

chain見る通信主な用途
inputサーバー自身へ入る通信SSH、Web、DNS、監視などの受信制御
forwardサーバーを通過する通信router、bridge、NAT、VM 間通信の制御
outputサーバー自身から出る通信外部通信、更新、監視送信、内部宛て通信の制御

サーバー単体の firewall と、ネットワーク境界の firewall は同じではありません。nftables は OS 自身の通信を制御できますが、ネットワーク全体の境界制御、WAF、IDS / IPS、クラウド security group とは責務が違います。

そのため、nftables を設計する時は、まず対象を分けます。サーバー自身を守るのか、ルーターとして通過通信を制御するのか、外向き通信を制限するのか。この主語が曖昧なまま ruleset を作ると、どの通信を許可しているのか分かりにくくなります。

現在の状態を確認する

まず、nftables が入っているか、現在の ruleset がどうなっているか、サービスが有効かを確認します。既存ルールがある環境では、いきなり上書きせず現状を保存してから変更します。

コマンド
nft --version
sudo nft list ruleset
systemctl status nftables.service --no-pager
systemctl is-enabled nftables.service

sudo nft list ruleset で何も表示されない場合は、nftables の ruleset が空の状態です。ただし、別の firewall 管理ツールが nftables backend を使っている可能性もあるため、環境全体の管理方針を確認します。

設定ファイルの置き方

Ubuntu では、/etc/nftables.conf を入口にして ruleset を読み込ませる構成が分かりやすいです。複数ファイルに分ける場合も、最終的にどの順序で include されるかを固定します。

コマンド
sudo mkdir -p /etc/nftables.d
sudo tee /etc/nftables.conf >/dev/null <<'EOF'
#!/usr/sbin/nft -f
flush ruleset
include "/etc/nftables.d/*.nft"
EOF
sudo chmod 600 /etc/nftables.conf

flush ruleset は既存の ruleset を消してから読み込む指定です。管理外のルールを残したい環境では注意が必要です。サーバーごとに nftables を一元管理する場合は、ruleset を明示的に作り直す方が分かりやすくなります。

host firewall の最小構成

次は、サーバー自身へ入る通信を制御する最小構成です。SSH を管理セグメントからだけ許可し、loopback、確立済み通信、ICMP を許可します。実際の管理セグメントや公開ポートは環境に合わせます。

設定ファイル例
table inet filter {
  set mgmt_v4 {
    type ipv4_addr
    flags interval
    elements = { 10.0.10.0/24 }
  }
  set mgmt_v6 {
    type ipv6_addr
    flags interval
    elements = { fd00:10::/64 }
  }
  chain input {
    type filter hook input priority filter;
    policy drop;
    ct state established,related counter accept
    ct state invalid counter drop
    iifname "lo" counter accept
    ip protocol icmp counter accept
    ip6 nexthdr ipv6-icmp counter accept
    tcp dport 22 ip saddr @mgmt_v4 counter accept
    tcp dport 22 ip6 saddr @mgmt_v6 counter accept
    counter drop
  }
  chain forward {
    type filter hook forward priority filter;
    policy drop;
  }
  chain output {
    type filter hook output priority filter;
    policy accept;
  }
}

この例は、host firewall としての最小構成です。Web サーバー、DNS、監視 agent、Prometheus exporter などを公開する場合は、用途ごとに許可ルールを追加します。重要なのは、何を許可しているのかが ruleset から読めることです。

コマンド
sudo tee /etc/nftables.d/10-filter-inet.nft >/dev/null <<'EOF'
table inet filter {
  set mgmt_v4 {
    type ipv4_addr
    flags interval
    elements = { 10.0.10.0/24 }
  }
  set mgmt_v6 {
    type ipv6_addr
    flags interval
    elements = { fd00:10::/64 }
  }
  chain input {
    type filter hook input priority filter;
    policy drop;
    ct state established,related counter accept
    ct state invalid counter drop
    iifname "lo" counter accept
    ip protocol icmp counter accept
    ip6 nexthdr ipv6-icmp counter accept
    tcp dport 22 ip saddr @mgmt_v4 counter accept
    tcp dport 22 ip6 saddr @mgmt_v6 counter accept
    counter drop
  }
  chain forward {
    type filter hook forward priority filter;
    policy drop;
  }
  chain output {
    type filter hook output priority filter;
    policy accept;
  }
}
EOF
sudo chmod 600 /etc/nftables.d/10-filter-inet.nft

IPv6 も同じ粒度で見る

IPv4 だけを制御して、IPv6 側が空いている状態は避けます。Ubuntu 26.04 を dual stack で使う場合、IPv4 と IPv6 は同じ意図で許可・拒否されているか確認します。

table inet を使うと、IPv4 と IPv6 を同じ table の中で扱えます。ただし、ip saddr と ip6 saddr のように、アドレスファミリごとの条件は分けて書きます。

  • IPv4 の管理セグメントだけでなく IPv6 の管理セグメントも許可する
  • ICMP と ICMPv6 を同じものとして扱わない
  • IPv6 の neighbor discovery を壊さない
  • 公開サービスが IPv6 でも listen しているか確認する

IPv6 を無効にしていない環境では、IPv6 を firewall 設計の外に置かないことが重要です。

構文確認をしてから反映する

nftables の設定は、必ず構文確認をしてから反映します。SSH 接続中のサーバーで firewall を変更する場合、事前確認なしに反映するのは危険です。

コマンド
sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

nft -c -f は構文確認です。ここで失敗する場合は ruleset を反映しません。反映後は sudo nft list ruleset で、意図した table / chain / policy が入っているかを確認します。

再起動後も ruleset を読み込むには、nftables.service を有効化します。

コマンド
sudo systemctl enable nftables.service
sudo systemctl restart nftables.service
systemctl status nftables.service --no-pager
sudo nft list ruleset

SSH を閉じないための考え方

nftables で最も避けるべき事故は、自分の管理経路を閉じることです。特に input chain の policy を drop にする場合は、SSH の送信元、待ち受け port、管理 NIC、IPv4 / IPv6 のどちらで接続しているかを確認します。

  • 作業中の SSH 接続元 IP を確認する
  • SSH が IPv4 / IPv6 のどちらで接続されているか確認する
  • input を drop にする前に明示的な SSH 許可を入れる
  • console や別経路で復旧できる状態にする
  • 反映後に新しい SSH session で接続確認してから古い session を閉じる
コマンド
who
ss -tnp | grep ':22'
ip route get 10.0.10.10
ip -6 route get fd00:10::10

nftables の学習では input drop の例が多く出てきますが、実サーバーでは段階的に進めるべきです。まず ruleset の読み込み、log、counter、output 制御などから確認し、管理経路を固定してから input の default policy を厳しくします。

PBR / FRR / Bridge との関係

FRR、OSPF、BGP、Policy Based Routing、KVM bridge などを使うサーバーでは、nftables を単純な host firewall としてだけ見ると不足します。ルーティングプロトコルや forwarded traffic を止めていないかを確認します。

  • FRR が使う protocol / port を許可しているか
  • forward chain の policy が用途に合っているか
  • bridge や VM 間通信を止めていないか
  • PBR の戻り経路と firewall の許可条件が合っているか
  • Reverse Path Filtering と矛盾していないか
  • IPv4 と IPv6 の両方で同じ意図になっているか

特に router 的に使う Ubuntu では、input だけでなく forward chain が重要になります。サーバー自身宛ての通信と、サーバーを通過する通信を混同しないことが大切です。

ログと counter を確認する

nftables は、rule ごとに counter を付けることで、どのルールに packet が当たっているかを確認できます。drop する通信は、必要に応じて rate limit 付きで log を出すと切り分けしやすくなります。

コマンド
sudo nft list ruleset
journalctl -k -n 100 --no-pager
journalctl -k -g nft --no-pager

ログを出しすぎると、kernel log が騒がしくなります。drop log は rate limit をかけ、常時大量に出る状態を放置しない方がよいです。ACL の設計が悪い状態をログで埋めるのではなく、不要な通信そのものを減らすことも重要です。

まとめ

Ubuntu 26.04 の nftables は、OS 側で通信の意図を明示するための基本機能です。input、forward、output のどこを制御しているのかを分けて考えることで、サーバー自身宛ての通信、通過通信、外向き通信を整理できます。

重要なのは、nftables を入れることではなく、どの通信を許可し、どの通信を拒否するのかを設計することです。SSH を閉じないこと、IPv4 / IPv6 を両方見ること、PBR、FRR、Bridge、Reverse Path Filtering と責務を混同しないことを意識すると、Ubuntu 26.04 の firewall 設計は扱いやすくなります。

関連する記事
Ubuntu 26.04 nftables の基本設定 – OS firewall の責務と通信制御

関連記事

Ubuntu 26.04 FRR routing の基本設定 – OSPF / BGP を使う前に決めること Ubuntu 22.04 iptables ホストファイアウォール – nftables 時代の位置づけと設定例 Ubuntu 26.04 Policy Based Routing の基本設定 – 複数インターフェイスの出口を分ける Ubuntu 26.04 Reverse Path Filtering の基本設定 – 複数インターフェイスと PBR で rp_filter を確認する Ubuntu 26.04 Netplan の基本設定 – IP アドレス / DNS / ルーティングを管理する Ubuntu 26.04 VLAN の基本設定 – Netplan で tagged VLAN を扱う Ubuntu 26.04 Bonding の基本設定 – active-backup と 802.3ad を使い分ける Ubuntu 26.04 sysctl の基本設定 – カーネルパラメータとネットワーク設定を管理する

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る