著者 FreeBSDのセキュリティ更新方法と確認手順
FreeBSDはベースシステムをfreebsd-update、パッケージの脆弱性をpkg auditで確認します。2つのツールと別々の情報源を使う理由を解説します。
FreeBSD におけるセキュリティ更新の扱い
FreeBSD では、セキュリティ更新に 2 つの別々のツールを使用します。FreeBSD サーバーは、2 つの異なる部分で構成されているためです。リリースに含まれるカーネルと userland を指すベースシステムには、freebsd-update でパッチを適用します。その上にインストールしたものはすべて package であり、package には pkg でパッチを適用します。一方だけを実行すると、マシンの半分は未更新のままになります。しかも、システム上の機能からはそのことを確認できません。
SSD Nodes は FreeBSD のイメージを提供していません。SSD Nodes のプランは Linux を実行します。それでもこの記事を掲載するのは、読者層が完全に重なるためです。SSD Nodes の Ubuntu や Debian サーバーを運用している人も、ファイアウォールで FreeBSD を実行していたり、引き継いだ 1 台のマシンで FreeBSD を使用していたりします。Linux 管理者がつまずきやすいのは、このパッチ適用モデルが分かれている点です。そのため、ここで記録しておく価値があります。以下のコマンド、アドバイザリ形式、サポート期間の日付はすべて、2026 年 8 月に FreeBSD のセキュリティページ とプロジェクトのマニュアルページで確認済みです。
コマンドを実行する前に、1 点注意してください。FreeBSD はベースシステムに sudo をインストールしません。ここで説明する操作にはすべて root 権限が必要です。su - を使用するか、先に package から sudo または doas をインストールしてください。
ベースシステムとパッケージは別の体系です
Ubuntu では、apt がマシン全体を管理します。カーネル、openssl、nginx、独自に導入したツールはすべて、1 つのツールから .deb ファイルとして提供され、apt upgrade がそれらをまとめて更新します。
FreeBSD では、この仕組みが 2 つに分かれています。ベースシステムは 1 つの単位として構築され、1 つの単位としてバージョン管理されます。15.1-RELEASE-p3 は、カーネル、C ライブラリ、sshd、/usr/lib に含まれる OpenSSL のコピーを対象とする単一の番号です。これらは pkg から提供されるものではありません。それ以外はすべて /usr/local の下に置かれ、ports tree からビルドされたバイナリパッケージとして提供され、独自のバージョンを持ちます。
そのため、1 台のマシンに OpenSSL が 2 つ存在することがあります。1 つは /usr/lib にあるベースシステム側のコピーで、freebsd-update だけによって修正されます。もう 1 つは /usr/local/lib にあるパッケージ側のコピーで、pkg だけによって修正されます。プログラムがどちらを使用するかは、どちらに対してリンクされたかで決まります。通常、パッケージからインストールしたソフトウェアはパッケージ側のコピーにリンクされます。一方を更新しても、もう一方には反映されません。
次の 3 つのコマンドで、現在の状態を確認できます。
freebsd-version -u
freebsd-version -k
uname -rfreebsd-version -u は、インストール済み userland のパッチレベルを表示します。freebsd-version -k は、インストール済みカーネルのパッチレベルを表示します。freebsd-version(1) には、これが uname と同じではない理由が明記されています。「新しいカーネルがインストールされているものの、システムがまだ再起動されていない場合、freebsd-version は新しいカーネルのバージョンとパッチレベルを表示する」と説明されています。uname -r は、現在実行中のカーネルを表示します。さらに freebsd-version -r もあり、実行中のカーネルを表示しますが、「環境変数の影響を受けない」という違いがあります。UNAME_r が別の値に設定されていることが多い jail 内では、この違いが重要です。
セキュリティ勧告とErrata通知
FreeBSD Security Teamからは2種類の通知が公開されます。両者の意味は異なります。
Security Advisoryは、ベースシステムのセキュリティ脆弱性を扱います。識別子はFreeBSD-SA-26:55.elfのような形式です。SAの文字、2桁の年、その年の通し番号、影響を受けるコンポーネントの順に構成されます。FreeBSD-SA-26:52.if_wgとFreeBSD-SA-26:50.kqueueはいずれも2026-07-29に公開されました。完全な一覧はFreeBSDの勧告ページにあります。
Errata Noticeは、セキュリティへの影響はないものの、リリースブランチに反映する価値がある正確性または安定性の問題を扱います。形式は同じですが、SAの代わりにENを使用します。FreeBSD-EN-26:19.zfs、FreeBSD-EN-26:18.tzdataのようになります。タイムゾーンデータの更新が典型的な例です。古いタイムゾーンデータを利用して攻撃することはできませんが、修正を適用するまでタイムスタンプは誤ったままになります。ErrataはFreeBSDのErrata通知ページに一覧化されています。
どちらの通知もSecurity OfficerのPGP（pretty good privacy）鍵で署名され、security.FreeBSD.orgにアーカイブされています。また、どちらもfreebsd-updateによってマシンに配信されます。
Linux管理者が見落としやすい点があります。どちらの通知もパッケージは対象にしません。セキュリティページには、「FreeBSD Ports Collectionの問題はFreeBSD VuXMLドキュメントで別途扱う」と明記されています。nginxパッケージのリモート脆弱性にSA番号が付与されることはありません。勧告フィードだけを監視している場合、その脆弱性を知ることはできません。
FreeBSD のセキュリティ更新を知るにはどうすればよいですか？
参加するリストは freebsd-security-notifications です。モデレーションがあり、投稿量も少なく、アドバイザリと errata 通知そのものが配信されます。lists.freebsd.org から購読してください。
freebsd-announce にもモデレーションがあり、リリースのお知らせとともにアドバイザリが配信されます。すべての情報を 1 つのリストで受け取りたい場合に適しています。freebsd-security は議論用のリストです。読む価値はありますが、パッチが必要だと知るための場所ではありません。
これらはすべてベースシステムのニュースのみを配信します。パッケージの脆弱性はメールで届きません。コマンドを実行して確認します。
pkg audit と、その背後にあるデータベース
VuXML（Vulnerabilities and Exposures Markup Language）は、FreeBSD プロジェクトが ports と packages のセキュリティ問題を記録するためのデータベースです。各エントリには、影響を受ける package、脆弱なバージョン範囲、CVE（common vulnerabilities and exposures）識別子、簡単な説明が記載されています。全エントリは VuXML インデックス で確認でき、package、CVE、日付の順に並べ替えられます。
pkg audit はこのデータベースを読み取るツールです。
pkg audit -F-F はチェックの前にデータベースの最新コピーを取得します。毎回使用してください。-F を指定しない場合、マシンにすでに保存されているコピーと照合します。そのコピーは数か月古い可能性があるため、問題なしという結果にも意味がありません。このコマンドは、インストール済みのすべての package のバージョンをすべての VuXML エントリと比較し、一致した項目ごとに CVE 番号と VuXML ページへのリンクを表示します。最後に、問題が見つかった件数と、対象になったインストール済み package 数を示す集計行を出力します。
pkg-audit(8) のフラグでは、ほかに 2 つ覚えておくと便利なものがあります。pkg audit -r を指定すると、「脆弱な package に依存し、そのため同様に脆弱である可能性がある package」も表示されます。これにより、脆弱な library が重要になる理由、つまりインストール済みの 6 個のプログラムがその library にリンクしていることを確認できます。pkg audit -R は同じ結果を JSON などの機械処理用形式で出力します。監視チェックにはこの形式を渡します。
pkg package は、/usr/local/etc/periodic/security/410.pkg-audit に定期実行スクリプトをインストールします。このスクリプトは毎日のセキュリティチェックの一部として実行され、結果を root にメールで送信します。/etc/periodic.conf に次の行があることを確認して、有効になっているか確認します。
daily_status_security_pkgaudit_enable="YES"この毎日のメールは、FreeBSD における Ubuntu の unattended-upgrades の習慣に最も近い仕組みです。しかし、この違いこそが重要です。unattended-upgrades は利用者が寝ている間に修正をインストールしますが、pkg audit は修正が必要であることを通知するだけです。pkg audit は報告します。パッチは適用しません。 標準状態の FreeBSD システムが、利用者の操作なしにセキュリティ更新をインストールすることはありません。
脆弱なパッケージを修正する
pkg update
pkg upgradeFreeBSD の package repository には、セキュリティ更新だけを提供する pocket はありません。Ubuntu では noble-security だけから取得し、その他のパッケージは現在の状態に維持できます。FreeBSD には同等の仕組みがないため、1 つの脆弱なパッケージを修正するには、repository が現在提供しているバージョンと、それに伴って更新された依存関係を受け入れる必要があります。パッケージの patch 適用はバックグラウンドジョブではなく、変更作業として計画してください。
使用している repository branch によって、修正が届く速さが決まります。デフォルトは quarterly branch です。handbook では、feature update を受け入れず、より「予測しやすく安定した環境」を提供する branch と説明されています。latest branch では、すべてのパッケージについて最新バージョンが取得されます。そのため、pkg audit -F がパッケージを脆弱と報告し、pkg upgrade が更新対象なしと表示する場合、修正はまだ使用中の branch に到達していません。これが混乱の原因です。
マシンを latest branch に移行するには、システムに付属する repository file をコピーして、そのコピーを編集します。
mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.confコピーしたファイルの url 行で、quarterly を latest に変更します。次に pkg update -f を実行して、新しい catalogue を取得します。repository 名を記憶だけで入力するのではなく、ファイルをコピーしてください。/etc/pkg/FreeBSD.conf 内の名前が、システムで実際に使用されている名前です。また、/usr/local/etc/pkg/repos 配下のファイルは、名前が完全に一致する repository だけを上書きします。
ベースシステムにパッチを適用する
freebsd-update fetch
freebsd-update installfetch は、現在のリリース向けのパッチをダウンロードし、変更するファイルの一覧を表示します。適用するものがない場合は No updates needed to update system to 15.1-RELEASE-p3. と表示して終了します。適用するものがある場合は、最後に install コマンドを実行するよう指示します。freebsd-update install を実行するまで変更は適用されないため、fetch はいつでも安全に実行できます。
freebsd-update(8) は ALPHA、BETA、RC、RELEASE バージョン向けのバイナリ更新を提供します。PRERELEASE、STABLE、CURRENT 向けではありません。stable/15 を追跡する場合はソースからビルドするため、このツールの対象ではありません。
ダウンロードは自動化し、インストールは手動で行います。handbook にある /etc/crontab の行は次のとおりです。
@daily root freebsd-update cronfreebsd-update cron は 1 から 3600 秒の間でランダムに待機してから、fetch とまったく同じ方法で更新をダウンロードし、適用待ちの更新があると root にメールを送信します。このランダムな待機は、インターネット上のすべての FreeBSD マシンが同じ秒に更新ミラーへアクセスすることを避けるためのものです。
出力には、誤解されやすい点が 2 つあります。ソースツリーがないサーバーでは src component not installed, skipped は正常であり、エラーではありません。コンポーネントの集合は /etc/freebsd-update.conf 内の Components 行で制御され、選択肢は src、world、kernel です。
インストールに問題が起きた場合は、freebsd-update rollback で直前にインストールした更新をアンインストールできます。ZFS root では、事前に boot environment を作成して、さらに安全に対処できます。
bectl create pre-patch
freebsd-update fetch installパッチ適用後のシステムが起動しない場合は、loader メニューで古い boot environment を選択すれば、元の状態に戻せます。この復旧手段が、ZFS を root filesystem として実行する実用的な理由の 1 つです。2 つの environment の内容が分岐するまでは、ディスク容量もほとんど消費しません。
FreeBSD のリリースはまだサポート対象ですか？
各リリースには固定のサポート期間があり、セキュリティページのブランチ表に掲載されています。2026年8月時点では、表は次のとおりです。
releng/15.1（15.1-RELEASE）は 2027年3月31日までreleng/15.0（15.0-RELEASE）は 2026年9月30日までreleng/14.4（14.4-RELEASE）は 2026年12月31日までstable/15は 2029年12月31日までstable/14は 2028年11月30日まで
ポイントリリースのサポート期間は短く設定されています。15.0-RELEASE は、この投稿の執筆時点から約7週間後にサポートが終了します。15.1 がリリースされ、サポート終了日が設定されたためです。stable ブランチは数年間維持されます。これらはソースコードのブランチであり、freebsd-update は提供しません。
freebsd-version -u で自分のリリースを確認し、表と照合してください。freebsd-update でも警告を確認できます。期限が近づくと、fetch は次を表示します。
WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.期限を過ぎると、警告は WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE. になります。サポート対象外のリリースも動作し続けます。ただし、セキュリティ勧告が提供されなくなるため、その後に発見されたベースシステムの脆弱性は、恒久的に自分で対処する必要があります。
リリースの更新は、freebsd-update -r 15.1-RELEASE upgrade、次に freebsd-update install、その後に再起動し、再度 freebsd-update install を実行します。続いて pkg-static upgrade -f を実行し、新しいライブラリに対してすべてのパッケージを再インストールします。最後に freebsd-update install を実行します。ハンドブックによると、ライブラリのバージョン番号が変更されたかどうかによっては、インストール処理が3回ではなく2回だけになる場合があります。メンテナンス時間を確保し、開始前に FreeBSD 15 サーバーセットアップガイド を読んでください。
再起動が必要ですか、それともサービスの再起動で十分ですか？
FreeBSD では、次の比較で判断できます。
freebsd-version -k
uname -rfreebsd-version -k はディスク上のカーネルです。uname -r はメモリ上のカーネルです。文字列が異なる場合は新しいカーネルがインストールされていますが、まだ実行されていないため、再起動してください。文字列が一致する場合、パッチはカーネルに影響していないため、再起動しても意味はありません。
ユーザーランドのパッチでは、更新されたコードを使用するサービスを再起動してください。/usr/lib のベース OpenSSL を修正しても、3 週間前に起動し、古いライブラリをアドレス空間にマッピングしたままの sshd には影響しません。ディスク上のファイルは新しくなっています。しかし、実行中のプロセスは古いままです。
service sshd restart同じルールがパッケージにも適用されます。pkg upgrade はディスク上のバイナリを置き換えますが、実行中のプロセスは古いバイナリを開いたまま使用しています。そのため、修正を実際に反映する手順は service nginx restart です。
ベースシステムには Debian の needrestart に相当する仕組みがありません。そのため、通知も表示されず、一覧も作成されません。どのサービスがどの更新済みライブラリにリンクしているかを追跡するか、ベースライブラリに影響するパッチを適用した後は再起動してください。設定をバージョン管理しているサーバーでは、再起動は通常の運用作業です。更新済みだと思い込んで実際には更新されていない状態になるより、はるかにコストが低くなります。
jail を実行しているマシンへのパッチ適用
jail はホストのカーネルを共有するため、カーネルのセキュリティ勧告はホストの問題であり、そのマシン上のすべての jail に影響します。ホストにパッチを適用して再起動すれば、すべての jail についてカーネル側の対応は完了します。各 jail 内の userland は独立したインストールであり、固有のパッチレベルを持ちます。freebsd-version -j <jail> を使うと、ホストからその状態を確認できます。jail 内のパッケージも分離されており、pkg -j <jail> audit -F を使えば jail に入らずに監査できます。この、共有カーネルと分離された userland という構造上の違いは、jail と Docker コンテナの比較方法にもそのまま表れます。
Ubuntu への対応
FreeBSD の各運用手順には対応する Ubuntu の手順があります。そのため、どちらの方向へ移行しても同じ流れを適用できます。
- ベースシステムのパッチ適用: FreeBSD では
freebsd-update fetchの後にfreebsd-update installを実行します。Ubuntu ではapt update && apt upgradeを実行すると、ベースシステムとその他のパッケージを一度に更新できます。 - サードパーティーソフトウェア: FreeBSD では
pkg update && pkg upgradeを実行します。Ubuntu では、再びaptを実行します。 - 既知の脆弱性の確認: FreeBSD では
pkg audit -Fを実行します。Ubuntu 24.04 では、最も近いコマンドはpro security-statusです。インストール済みパッケージのセキュリティ更新に加え、Expanded Security Maintenance の内容も表示します。 - 自動インストール: Ubuntu では
unattended-upgradesがセキュリティ更新を自動的に適用します。FreeBSD には同等の仕組みがないため、freebsd-update cronでダウンロードとメール送信を行い、インストールは手動で実行します。 - セキュリティ勧告フィード: FreeBSD-SA と FreeBSD-EN の項目は
freebsd-security-notificationsで配信されます。Ubuntu Security Notices はubuntu-security-announceで配信されます。 - 脆弱性データベース: FreeBSD の ports とパッケージには VuXML を使用します。Ubuntu のパッケージには Ubuntu CVE tracker を使用します。
- 再起動の確認: FreeBSD では
uname -rに対してfreebsd-version -kを実行します。Ubuntu では/var/run/reboot-requiredの存在を確認します。 - サポート期間: FreeBSD では FreeBSD security page の branch table を確認します。Ubuntu では release schedule と
pro security-statusを確認します。
基本的な手順は、どちらのシステムでも同じです。フィードを購読し、定期的に監査を実行し、何をいつインストールして再起動するかを判断します。FreeBSD では、処理を自動で実行してくれないため、後半の手順も明示的に実行する必要があります。サーバープラットフォームとしての Linux と FreeBSD の詳細な比較では、ワークロードを両者の間で移行した場合に変わるその他の点を説明しています。
FAQ
freebsd-update はパッケージも修正しますか？
いいえ。freebsd-update が対象とするのはベースシステムだけです。つまり、カーネルと、そのリリースに含まれていた userland が対象です。/usr/local にインストールされたソフトウェアはパッケージとして提供され、pkg upgrade で修正されます。既知の脆弱性があるインストール済みパッケージを確認するには pkg audit -F を実行します。ベースシステムのセキュリティ勧告にはパッケージの脆弱性は記載されず、セキュリティメーリングリストでも告知されないためです。
FreeBSD の更新で再起動が必要かどうかを確認するにはどうすればよいですか？
freebsd-version -k と uname -r を比較します。前者はディスク上にインストールされているカーネルを表示します。書き込まれたばかりで、まだ起動に使用されていないカーネルも含まれます。後者は実行中のカーネルを表示します。表示される文字列が異なる場合は、再起動が必要です。一致する場合は userland だけが更新されているため、影響を受けるサービスだけを再起動します。たとえば service sshd restart を実行します。実行中のプロセスは、再起動するまで古いライブラリをメモリにマッピングしたままだからです。
Security Advisory と Errata Notice の違いは何ですか？
Security Advisory は、FreeBSD-SA-26:55.elf のように、ベースシステムのセキュリティ脆弱性を修正します。Errata Notice は、FreeBSD-EN-26:18.tzdata のように、セキュリティ上の影響がない正確性または安定性の問題を修正します。古いタイムゾーンデータなどが該当します。どちらも year:sequence number:component という形式を使用します。どちらも Security Officer が署名し、freebsd-update で配信されます。ports またはパッケージからインストールしたソフトウェアは、どちらの対象にもなりません。
FreeBSD に unattended-upgrades と同等の仕組みはありますか？
ベースシステムにはありません。freebsd-update cron は保留中のベースシステムの修正をダウンロードして root にメールで通知しますが、インストールは行いません。pkg がインストールする periodic script は pkg audit を毎日実行して結果をメールで通知しますが、アップグレードは行いません。自動インストールは、cron job などを使って自分で構築する必要があります。FreeBSD のパッケージ更新では、セキュリティ修正だけをバックポートするのではなく、最新バージョンがインストールされます。そのため、多くの管理者はメールを確認してから手動でインストールします。
FreeBSD のリリースがまだサポート対象かどうかを確認するにはどうすればよいですか？
userland のバージョンを確認するには freebsd-version -u を実行し、FreeBSD の security page にあるサポート対象ブランチの表と比較します。ポイントリリースのサポート期間は短く設定されています。2026 年 8 月時点では、15.0-RELEASE は 2026 年 9 月 30 日に終了し、15.1-RELEASE は 2027 年 3 月 31 日まで継続します。freebsd-update fetch はその日付が近づくと警告します。日付を過ぎると、リリースが HAS PASSED ITS END-OF-LIFE DATE であることを示す行を表示します。その時点以降は、新たな勧告の対象になりません。