はじめに
お疲れ様です！
世の中には「Ubuntu をスキャンしてみた」「Windows Server の脆弱性を調べてみた」みたいな記事はたくさんあります。
しかし、機能がほぼ存在しない自作OSに脆弱性診断を当てるという実験は、なかなかお目にかかれないと思います。
今回、私が開発している UmuOS-0.1.6-dev に対して、業界標準の脆弱性スキャナ Nessus（ネサス） を実際に使って診断してみました。
結果は、予想通りであり、予想外でもあった。
そして何より、脆弱性診断ツールが暗黙に置いている“前提”が浮き彫りになった。
この記事は、OS 設計の思想と脆弱性診断の関係を、実験結果を交えて深掘りします。
UmuOS-0.1.6-dev とは何か
UmuOS-0.1.6-dev は、私が趣味と研究目的で開発している 最小構成 OS です。
UmuOS は、日常利用を目的とした OS ではありません。
UmuOS-0.1.6-dev は 研究・観測・理解のために存在する OS で、目的は「便利に使える OS を作ること」ではなく、 OS や Linux カーネルの挙動を観測し、理解し、検証すること にあります。
一般的な Linux ディストリビューションと同じである必要はないし、POSIX 互換性や GNU ツールチェーンの再現を目指すわけでもないです。
UmuOS が重視するのは以下の点です。
- 前提条件を明確にし、OS の責務を限定すること
- “何をしないか”を先に決めることで、構造の純度を保つこと
- 開発環境と実行環境を分離し、OS 内部を単純に保つこと
- 互換性よりも、UmuOS 内での一貫性と理解しやすさを優先すること
- コマンドやツールは「使いやすさ」ではなく「観測しやすさ」を目的とすること
UmuOS は完成を目指さないOSです。
途中の設計判断そのものが成果であり、止まった時点の状態も研究結果であると考えています。
したがって、UmuOS は 「使うための OS」ではなく、「理解するための OS」 であるのです！
現時点（0.1.6-dev）で使える機能はほぼ無い。
- telnet
- FTP
- 以上（笑）
SSH も無ければ、systemd も無い。
glibc も無ければ、パッケージ管理も無い。
当然、Webサーバも無いし、デーモンもほぼ動いていないです。
Nessus（ネサス）とは何か
Nessus（ネサス） は Tenable 社が提供する、世界的に使われている脆弱性スキャナです。
- OS 判定
- サービス検出
- CVE の照合
- 設定ミスの検出
- 認証スキャン（SSH/WinRM）
- プラグインによる詳細診断
など、非常に高機能で、公共系や企業のセキュリティ診断でも使われている印象があります。
ただし Nessus は（良い意味で）「一般的な Linux / Windows」 を前提にしている部分があります。
たとえば、
- systemd がある
- glibc がある
- パッケージ管理がある
- 主要サービスが動いている
みたいな世界観で、プラグインが積み上がっている。
ここが今回の実験のポイントでした。
実験の前提（脅威モデル）
先に断っておくと、今回の話は 「UmuOS は安全です！」 と言いたいのではなく、
「最小構成OSに対して、スキャナが何を“見れる/見れない”のか」 を観測したい、という実験です。
今回の前提はこんな感じ。
- UmuOS は研究・観測用で、インターネットに公開する用途ではないです。
- QEMU/KVM 上で動かし、ネットワークは、意図して隔離されている前提となります！
- したがって、診断結果の解釈は「外部公開サービスの評価」とは異なるとの認識です。
今回の実環境を、構成図レベルで書くとこうです。
Nessus（Win11 Pro / 192.168.0.10）
└─（自宅LAN: 192.168.0.0/24）
└─ QEMU/KVMホスト（富士通 PRIMERGY / 192.168.0.200 / ブリッジ接続）
└─ UmuOS-0.1.6-dev（ゲスト / 192.168.0.202）
- Nessus はメインマシン（Win11 Pro）の localhost 上で実行
- UmuOS は自宅サーバー（PRIMERGY）の QEMU/KVM 上で稼働
- ゲストNICはブリッジ接続のため、UmuOS は自宅LAN（192.168.0.0/24）に直接ぶら下がっている状態
- UmuOS はアウトバウンド方向（例：時刻合わせ等）ではインターネットへ出られる
- ただし、本記事の診断・解釈は「インターネット公開サービスの評価」ではなく、自宅LAN内の観測として扱う
実験条件（環境・前提）
ここでは、今回の診断で使った環境と前提を簡潔にまとめます。
実行環境（どのマシンで何を動かしたか）
-
メインマシン（開発端末 / Nessus 実行端末）
- 機種：MINISFORUM MiniPC
- IP：192.168.0.10
- CPU：12th Gen Intel(R) Core(TM) i9-12900HK (2.50 GHz)
- RAM：32.0 GB
- 役割：開発端末 / Nessus を localhost 上で実行
- 補足：開発作業では、自宅サーバー側の Ubuntu 24.04 LTS（開発環境）へ SSH 接続している
-
自宅サーバー（仮想化ホスト）
- 機種：富士通 PRIMERGY
- IP：192.168.0.200
- CPU：Xion
- RAM：32.0 GB
- 役割：QEMU/KVM ホスト（Ubuntu 開発環境など複数ゲストを運用）
-
UmuOS-0.1.6-dev（診断対象）
- 稼働場所：自宅サーバー（PRIMERGY）の QEMU/KVM 上
- IP：192.168.0.202
対象
- UmuOS-0.1.6-dev（QEMU/KVM ゲスト）
ネットワーク構成
- ブリッジ接続（UmuOSゲストが 192.168.0.0/24 に直接参加）
- QEMU/KVMホスト：富士通 PRIMERGY（192.168.0.200）
- UmuOS-0.1.6-dev（ゲスト）：192.168.0.202
- Nessus 実行端末（開発端末）：192.168.0.10
- 到達性：192.168.0.10 → 192.168.0.202 へ TCP/UDP が到達する構成
Nessus 側の設定
- 未認証スキャン（認証スキャンなし）
- スキャンプロファイル：基本スキャン（Safe Checks のON/OFFなど、分かれば追記）
開放ポート（観測）
- 23/tcp（telnet）
- 21/tcp（FTP）
nmap -sS -sV 192.168.0.202（抜粋）はこんな感じでした。
tama@umudev:~$ sudo nmap -sS -sV 192.168.0.202
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-02-19 00:39 JST
Nmap scan report for 192.168.0.202
Host is up (0.00011s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
23/tcp open telnet security DVR telnetd (many brands)
MAC Address: 52:54:00:12:34:56 (QEMU virtual NIC)
Service Info: Device: webcam; CPE: cpe:/h:dlink:dcs-932l
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds
実験と結果：UmuOS-0.1.6-dev に Nessus を当ててみた
さて、実際にスキャンしてみた結果がこれだ。
結論から言うと、Nessus が検出したのは以下の通り。
検出結果（概要）
まず大枠はこんな感じ。
-
Medium（CVSS 6.5）：暗号化されていない Telnet サーバー
- 平文ログインが可能
- → 盗聴・なりすましの土台になりやすい
-
Low（CVSS 2.1）：ICMP タイムスタンプ要求（リモート日付開示）
- 古典的な“時刻”系の情報
- → 直接の侵入というより「手がかり」
-
Informational：情報収集（下準備）
- ポート/サービス検出
- OS 指紋 / ゲスト判定 など
- → ここで集めた情報を元に、次のプラグインが動く
画面右側の「ホストの詳細」も、今回の実験の味が出ていて面白い。
- IP：192.168.0.202
- MAC：52:54:00:12:34:56（QEMU仮想NIC）
- OS推定：Linux カーネル 2.6（※推定）
- スキャン時間：6分
この時点で、Nessus がやっているのは
「既存のディストロ前提のCVE照合」よりも先に、まず“相手が何者か”を固める作業なんですよね。
Informational の中身（実際に表示されたもの）
Informational で並んだ項目も、「スキャナの仕事」が透けて見えるので、あえて書き出しておきます。
- Nessus SYNスキャナー（ポートスキャナー）
- 共通プラットフォーム列挙（CPE）
- デバイスタイプ
- イーサネットMACアドレス
- FTPサーバーの検出
- ホストの完全修飾ドメイン名（FQDN）解決
- KVM / QEMU ゲスト検出（資格情報なしのチェック）
- Nessusスキャン情報
- OS フィンガープリントが検出されました
- OS識別
- サービス検出
- TCP/IPタイムスタンプをサポート
- Telnetサーバーの検出
- トレースルート情報
（このへんが“脆弱性が少ない”というより、そもそもNessusが得意な土俵＝パッケージ/CVE照合の土俵に乗ってないのが見えます）
結果をどう読むか（考察）
この結果は、UmuOS-0.1.6-dev の設計思想をかなり素直に反映していると感じました。
1. “刺さった”のは Telnet
Telnet は平文通信なので、これは当然 Medium になります。
ただしここは、
「脆弱性ではあるが、直ちに問題かどうかは“前提”で決まる」 と思っています。
たとえば UmuOS を閉じた検証ネットワーク内だけで使うなら、優先度は下がる。
逆に、外部に出る可能性があるなら、真っ先に潰すべきです。
（次のバージョンで Telnet→SSH を検討、という流れはこのまま残す価値あります）
2. ICMP timestamp は“古典的な軽微な情報”
ICMP timestamp 応答は、昔から「時間情報が漏れる」系の話として知られています。
ただ、これは環境次第で、
閉じた検証環境なら“観測できる方が嬉しい”場面もある。
一方で、外部公開を想定するなら、パケットフィルタ等で落とす／応答しない実装に寄せる、などが候補になります。
3. それ以外が Informational に寄る理由
つまり、
Nessus が突っつける場所がほとんど無い（= 前提としている土俵がない）
ということ。
普通の Linux なら数十〜数百件の CVE が出ることもあります。
しかし UmuOS-0.1.6-dev は、
- パッケージ管理なし
- glibc なし
- systemd なし
- サービスほぼなし
- バナーも標準と違う
- カーネルも独自構成（少なくともディストロ既定と同じではない）
なので、CVE照合や構成監査の“材料”がそもそも少ない。
4. OS 判定が「Linux 2.6」っぽく見える理由
UmuOS-0.1.6-dev は Linuxカーネル6.18.1 を利用しているが、Nessus は
- TCP/IP スタックの癖
- 応答タイミング
- ポート構成
- バナー情報
などから OS を推測します（少なくとも挙動としてはそう見える）。
しかし UmuOS は既存ディストロの特徴をほぼ持っていないため、
**「古い Linux に似ている」**という雑な推測になりやすい。
個人的にはこれは「Nessusが悪い」というより、
指紋照合は“似ているもの”に寄るという性質が見えた、という話だと思います。
ここから見える“脆弱性診断ツールの限界”
今回の実験で強く感じたのは、
Nessus は“存在するもの”しか評価できないということです。
- 存在しないパッケージは脆弱化しない
- 存在しないサービスは攻撃されない
- 存在しない機能は誤設定しようがない
つまり、
最小構成 OS は、脆弱性診断ツールの前提を超えてしまう
という現象が起きる。
ここが今回いちばん面白かったところでした。
「機能が無い OS はウイルスにも感染しない」ということは？
今回の結果を見て、私は改めてこう思いました。
攻撃者が期待する“実行環境”が無ければ、できる攻撃はかなり減る。
- ELF ローダが無い
- glibc が無い
- 書き込み可能なファイルシステムが無い
- 外部からコードを持ち込む経路が少ない
UmuOS-0.1.6-dev はこれらをほぼ持っていません。
つまり、いわゆる「一般的なLinuxを前提にしたマルウェア」が、そのまま動く可能性は下がる。
ただし、“ゼロになる”とは限らないです。
たとえば telnet/FTP 実装のバグや、カーネル/ネットワーク層の欠陥は普通に攻撃面になり得る。
なのでここは、
「機能が少ないほど攻撃面は減る（ただし残る面はある）」
くらいの温度感で考えるのが現実的かなと思っています。
まとめ：最小構成 OS のセキュリティは“思想”で決まる
今回の実験で分かったことはシンプル。
- 攻撃面が小さければ、指摘される点も小さくなる
- 存在しない機能は、スキャンの対象にならない
- OS の設計思想がそのままセキュリティ特性になる
- 脆弱性診断ツールには“前提”がある
- 最小構成 OS はその前提を（良くも悪くも）外れる
UmuOS-0.1.6-dev はまだ発展途上ですが、
「余計なものを入れない」という判断が、結果として攻撃面の縮小につながる
ということは、今回かなり実感できました。
次のバージョン（0.1.7-dev）では、必要に応じて Telnet → SSH への移行なども検討しつつ、
まずはこの“最小構成の美学”を大切に育てていきたいです。
おわりに
自作 OS に脆弱性診断を当てるという、普通のエンジニアはまずやらない実験。
しかし、やってみると OS 設計の本質とセキュリティの関係がよく見える。
この記事が、「OS を作るとはどういうことか」「セキュリティはどこから生まれるのか」を考えるきっかけになれば嬉しいです。
UmuOS-0.1.6-dev の進化はまだ始まったばかり。
リポジトリ
Umuプロジェクトのコードやドキュメントは、こちらにまとめています。