Ubuntu 26.04 fwupd / fwupdmgr の外部通信とプロキシ環境での DROP 調査

Ubuntu 26.04 のサーバーで外向き通信を原則 DROP し、必要な通信だけをプロキシ経由にしていると、fwupd や fwupdmgr の外部通信がログに出ることがあります。これは APT とは別経路の通信で、ファームウェア更新用のメタデータや firmware capsule を扱うためのものです。

この記事では、fwupd / fwupdmgr がどこへ通信しようとしているのか、プロキシ環境ではどこに設定を入れるべきか、外部通信を許可しないサーバーではどう扱うべきかを整理します。手順記事というより、Ubuntu 26.04 で確認した調査資料です。

結論

DROP された通信が fwupd 起因であれば、判断は大きく 2 つです。

• ファームウェア更新を Ubuntu から扱うなら、fwupd.service にプロキシ設定を入れる
• サーバーでは fwupd に外部通信させない方針なら、lvfs remote を無効化する

重要なのは、FW 更新の通信を APT の通信と同一視しないことです。APT にプロキシを設定していても、fwupd daemon が同じ設定を読むとは限りません。サーバー側で外向き通信を DROP している場合、daemon 単位で通信経路を確認する必要があります。

fwupd / fwupdmgr の役割

fwupd はファームウェア更新を扱う daemon で、fwupdmgr はその daemon に対して操作する CLI です。公式の fwupdmgr ドキュメントでも、refresh は有効な remote からオンラインメタデータを取得する操作として説明されています。

つまり、fwupdmgr refresh や fwupdmgr update は、単なるローカル状態確認ではなく、remote が有効であれば外部へ通信し得る操作です。

fwupdmgr --version
fwupdmgr get-devices
fwupdmgr get-remotes

Ubuntu 26.04 で確認した remote 定義

Ubuntu 26.04 の確認環境では、/etc/fwupd/remotes.d/ に次の remote がありました。

sudo grep -RniE 'Enabled|MetadataURI|FirmwareBaseURI|ReportURI|Automatic' \
  /etc/fwupd/remotes.d \
  /var/lib/fwupd/remotes.d \
  /usr/share/fwupd/remotes.d 2>/dev/null

/etc/fwupd/remotes.d/lvfs.conf:Enabled=true
/etc/fwupd/remotes.d/lvfs.conf:MetadataURI=https://cdn.fwupd.org/downloads/firmware.xml.zst
/etc/fwupd/remotes.d/lvfs.conf:ReportURI=https://fwupd.org/lvfs/firmware/report
/etc/fwupd/remotes.d/lvfs.conf:FirmwareBaseURI=https://fwupd.org/downloads
/etc/fwupd/remotes.d/lvfs.conf:AutomaticReports=false
/etc/fwupd/remotes.d/lvfs.conf:AutomaticSecurityReports=false
/etc/fwupd/remotes.d/lvfs-testing.conf:Enabled=false
/etc/fwupd/remotes.d/lvfs-testing.conf:MetadataURI=https://cdn.fwupd.org/downloads/firmware-testing.xml.zst
/etc/fwupd/remotes.d/vendor-directory.conf:Enabled=true
/etc/fwupd/remotes.d/vendor-directory.conf:MetadataURI=file:///usr/share/fwupd/remotes.d/vendor/firmware

この結果から、通常有効なのは安定版の lvfs とローカルの vendor-directory です。外部通信が発生するのは主に lvfs で、メタデータは cdn.fwupd.org、ファームウェア本体やレポート系は fwupd.org を参照します。

DROP ログが出る理由

外向き通信を原則 DROP しているサーバーでは、fwupd が直接 cdn.fwupd.org や fwupd.org へ接続しようとすると DROP されます。この場合、問題は fwupd が不正な通信をしていることではなく、サーバーの外部通信方針と fwupd の remote 設定が合っていないことです。

• APT のプロキシ設定は fwupd daemon に自動適用されるとは限らない
• fwupdmgr を実行したユーザーの環境変数だけでは daemon に届かない場合がある
• systemd 管理の fwupd.service にプロキシ環境変数を持たせる必要がある
• fwupd を使わないサーバーでは remote を無効化する選択もある

fwupd.service にプロキシを設定する

fwupd を利用する方針で、外部通信はプロキシ経由にしたい場合は、fwupd.service の systemd drop-in にプロキシ環境変数を設定します。

sudo install -d -o root -g root -m 0755 /etc/systemd/system/fwupd.service.d

sudo tee /etc/systemd/system/fwupd.service.d/proxy.conf >/dev/null <<'EOF'
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="http_proxy=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=http://proxy.example.com:3128"
Environment="https_proxy=http://proxy.example.com:3128"
Environment="NO_PROXY=127.0.0.1,::1,localhost,.example.com,10.0.0.0/8,192.168.0.0/16,fd00::/8,fe80::/10"
Environment="no_proxy=127.0.0.1,::1,localhost,.example.com,10.0.0.0/8,192.168.0.0/16,fd00::/8,fe80::/10"
EOF

sudo systemctl daemon-reload
sudo systemctl restart fwupd.service

設定後は、systemd から見えている環境変数を確認します。

systemctl cat fwupd.service
sudo systemctl show fwupd.service -p Environment

プロキシ経由で refresh を確認する

プロキシ設定後、remote metadata の更新を試します。

sudo fwupdmgr refresh --force
fwupdmgr get-updates
journalctl -u fwupd.service --no-pager -n 100

ネットワーク側では、サーバーから直接インターネットへ出る通信ではなく、プロキシ宛ての通信だけが出ていることを確認します。プロキシ側では、必要に応じて cdn.fwupd.org と fwupd.org への HTTPS 接続を許可します。

fwupd の外部通信を止める場合

サーバー用途で OS からのファームウェア更新を行わない、または外部メタデータ取得を許可しない方針であれば、lvfs remote を無効化します。

sudo fwupdmgr disable-remote lvfs
fwupdmgr get-remotes

完全に不要であれば、パッケージ自体を削除する判断もあります。ただしデスクトップ環境やベンダーの firmware updater と関係する場合があるため、削除前に依存関係を確認します。

apt-cache rdepends fwupd
apt-cache policy fwupd

切り分けの見方

DROP ログを見たときは、次の順番で切り分けると整理しやすいです。

• 宛先が cdn.fwupd.org または fwupd.org か
• fwupdmgr refresh や GUI の firmware updater 実行タイミングと一致するか
• lvfs remote が有効か
• fwupd.service にプロキシ環境変数が入っているか
• プロキシ側で fwupd の宛先が許可されているか
• そもそもそのサーバーで fwupd による firmware update を使う方針か

セキュリティ設計としての判断

DROP 方針のネットワークでは、通信が DROP されたからすぐ許可する、という考え方は危険です。今回のような firmware update 系の通信は、必要性を判断したうえで次のどちらかに寄せる方が明確です。

• 必要なサーバーだけ、プロキシ経由で LVFS への通信を許可する
• サーバーでは fwupd のオンライン remote を無効化し、firmware update は別手順で扱う

特に仮想マシンやクラウドインスタンスでは、OS 内から firmware update を行う意味が薄い場合があります。一方、物理サーバー、ノート PC、Thunderbolt dock、NVMe などを管理する端末では fwupd が有用なことがあります。機器の種類によって扱いを分けるのが自然です。

参考にした仕様

• fwupdmgr client command line utility
• fwupd remote file format
• fwupd.conf file format
• LVFS documentation

まとめ

Ubuntu 26.04 で fwupd / fwupdmgr の外部通信が DROP される場合、まず remote 定義を確認します。lvfs が有効であれば、fwupdmgr refresh などで cdn.fwupd.org や fwupd.org への通信が発生します。

プロキシ環境では、APT ではなく fwupd.service の systemd drop-in にプロキシ環境変数を設定します。fwupd を使わないサーバーでは、lvfs remote を無効化し、外部通信しない方針に寄せるのが整理しやすいです。

Related posts:

REOL drop pop candy Docker プロキシ設定 – systemd drop-in で daemon に proxy を設定する Ubuntu 22.04 CentOS と Ubuntu の違い Ubuntu 22.04 hosts 設定 Ubuntu 22.04 Kubernetes Cilium 導入の事前確認 Ubuntu 26.04 LVM の基本設定 Ubuntu 26.04 Apache の基本設定 Ubuntu 26.04 MariaDB の基本設定 Ubuntu 26.04 TFTP の基本設定 Ubuntu 26.04 KVM VM の ACL 設定 – OVN logical port 単位で通信を制御する Ubuntu 26.04 kubeconfig の基本 – kubectl の context と複数クラスタ管理 Ubuntu 26.04 NFS マウントの基本設定