実践：WSLのUbuntuで始める、OpenSCAPを使用した爆速Linuxハードニング入門

Hi, there.

本日は、以前投稿したOpenSCAPの記事について深堀し、具体的な手順をお伝えします。

OpenSCAPで“まず安全側のベースラインを一気に作る”手順

Linux のハードニングで最初に消耗しやすいのは、設定の難しさそのものより、項目数の多さです。SSH、パスワード、ファイル権限、不要サービス、監査設定、カーネルパラメータを一つずつ手で詰めるやり方は、どうしても時間がかかり、設定漏れや設定ゆれも起きやすい。そこで発想を変えて、最初から ベンチマーク準拠のベースラインへまとめて寄せる ために使いたいのが OpenSCAP です。Red Hat は OpenSCAP を、設定コンプライアンススキャン、脆弱性評価、レポート生成、remediation に使う仕組みとして案内しています。

この記事の主題は「監査して学ぶこと」ではありません。最短で、安全寄りの標準形を作ることです。手順としては、WSL の Ubuntu を整える → OpenSCAP を入れる → 利用可能なプロファイルを確認する → ベースラインとの差分を評価する → 必要なら remediation で一気に寄せる、という流れです。remediation には注意点もありますが、白紙から手で harden するより、速く、抜け漏れなく、再現しやすいベースラインを作れます。

前提

今回は Windows 上の WSL2 + Ubuntu を前提にします。WSL は systemd をサポートしており、Microsoft は /etc/wsl.conf に systemd=true を設定し、wsl.exe --shutdown で再起動する手順を案内しています。これにより、Ubuntu を通常の Linux に近い感覚で扱いやすくなります。

OpenSCAP 自体は systemd がないと動かないわけではありませんが、サービス状態や一般的な Linux 環境の感覚に寄せたいので、WSL 側もできるだけ素直な形にしてから進めます。

1. WSLでsystemdを有効にする

まず PowerShell で WSL の状態を確認します。

wsl --version

【キャプチャ1：PowerShell で wsl --version を実行した画面】

WSL が新しければ、Ubuntu 側で wsl.conf を編集します。

sudo nano /etc/wsl.conf

中身を次のようにします。

[boot]
systemd=true

保存したら、PowerShell 側で WSL を再起動します。

wsl.exe --shutdown

その後、Ubuntu を起動し直して確認します。

systemctl list-unit-files --type=service | head

Microsoft の公式手順でも、この設定と wsl.exe --shutdown、および systemctl list-unit-files --type=service による確認が案内されています。

2. OpenSCAPとSCAPコンテンツを入れる

Ubuntu では oscap コマンドは openscap-scanner パッケージから提供されます。また、SCAP Security Guide は Ubuntu の manpage でも案内されており、OpenSCAP と組み合わせて使うベースラインコンテンツです。

まずインストールします。

sudo apt update
sudo apt install -y openscap-scanner ssg-base

入ったことを確認します。

oscap --version

ここでのポイントは、OpenSCAP は評価エンジンで、ベースラインの中身は SSG 側にあるということです。oscap だけではなく、どの data stream と profile を使うかが重要になります。

3. Ubuntu向けdata streamを見つける

OpenSCAP は data stream document を読み、その中に含まれる definitions、benchmarks、profiles、rules に基づいて評価します。Red Hat の説明でも、SCAP Security Guide のコンテンツは data stream として提供される前提です。

Ubuntu 側では、まず data stream の場所を確認します。

dpkg -L ssg-base | grep '/ssg-ubuntu.*-ds.xml$'

見つかったファイルのうち、使うものを変数に入れます。

DS_FILE=$(dpkg -L ssg-base | grep '/ssg-ubuntu.*-ds.xml$' | head -n 1)
echo "$DS_FILE"

/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml のようなパスが出れば準備完了です。ここが見つからない場合は、dpkg -L ssg-base | less で内容を見て、Ubuntu 用の ds.xml を確認します。

4. 使えるプロファイルを確認する

ベースライン構築で最初にやるべきことは、「とりあえず scan」ではありません。どの基準に寄せるかを決めることです。Red Hat は oscap info を使って、利用可能な profile とその説明を確認してからスキャンや remediation を行うよう案内しています。

まず、data stream の情報を見ます。

oscap info "$DS_FILE"

次に、profile を見やすく抜きます。

oscap info "$DS_FILE" | grep -i profile

ここで確認したいのは、「どの profile があるか」です。ベースライン構築の観点では、最初は厳しすぎるものより、現実的に寄せやすい profile を選ぶのがコツです。RHEL 側の例では CIS Level 1 / Level 2、STIG、PCI-DSS など複数プロファイルが用意されており、用途に応じて選ぶ前提になっています。

5. まずは現在地を測る

爆速ベースライン構築といっても、現在地を知らずに remediation を流すのは危険です。最初に一度だけ評価を実行し、どれくらい差分があるかを把握します。Red Hat は oscap xccdf eval --report ... --profile ... の形で評価レポートを出す手順を案内しています。

まず、使う profile を変数に入れます。

PROFILE_ID="ここに使いたいprofile IDを入れる"

評価します。

sudo oscap xccdf eval \
  --profile "$PROFILE_ID" \
  --results results-before.xml \
  --report report-before.html \
  "$DS_FILE"

レポートは Windows 側のブラウザで開くのが楽です。

explorer.exe .

ここで重要なのは、このレポートを学習資料ではなく、差分一覧表として見ることです。何が fail したかを眺めるのではなく、「どこがベースラインから外れているか」を確認します。

6. ベースラインへ一気に寄せる

ここがこの記事の中心です。OpenSCAP は remediation をサポートしており、Red Hat は --remediate を付けた oscap xccdf eval を案内しています。OpenSCAP の説明でも、評価後に失敗したルールへ対応する fix を探し、修正を実行できるとされています。

実行は次の形です。

sudo oscap xccdf eval \
  --profile "$PROFILE_ID" \
  --remediate \
  --results results-remediate.xml \
  --report report-remediate.html \
  "$DS_FILE"

これで、選んだ profile に沿って現在の Ubuntu を 安全寄りの標準形へまとめて寄せる ことができます。これが、手で一項目ずつ harden するやり方との最大の違いです。抜け漏れや設定ゆれをかなり抑えながら、一気にベースラインへ近づけられます。

ただし、Red Hat は remediation を不用意に使うとシステムが non-functional になる可能性があり、自動ロールバック手段は提供していないと明記しています。ですから、本番ではなく、まずは WSL や検証用 VM で試すのが前提です。

7. 再評価して“ベースラインに寄ったか”を確認する

remediation をかけたら終わりではありません。実際にどれだけ寄ったかを、もう一度評価して確認します。

sudo oscap xccdf eval \
  --profile "$PROFILE_ID" \
  --results results-after.xml \
  --report report-after.html \
  "$DS_FILE"

再びレポートを開きます。

explorer.exe .

ここで見るべきなのは、Fail がどれだけ減ったかです。すべての Fail をゼロにすること自体が目的ではありません。目的は、標準形をすばやく作ることです。残った差分は、その後に「WSL では不要」「用途上必要なので戻す」「このルールはあとで手動対応」と切り分ければ十分です。

8. 爆速で終わらせるための現実的な割り切り

ここまで来たら、あとは「何を戻すか」を決める工程です。ベースライン構築で大事なのは、最初から完璧な例外設計をすることではありません。まず標準形へ寄せて、その後に必要な例外だけ戻す ことです。この順番のほうが、白紙から積むよりも速く、ミスも少なくなります。remediation を使う価値は、まさにここにあります。

運用の感覚としては、次の順番が現実的です。

1. profile を決める
2. 現在地を測る
3. remediate で一気に寄せる
4. 再評価する
5. 動作に必要な例外だけ戻す

この順番なら、ハードニングは「膨大な設定項目との格闘」ではなく、「標準との差分管理」に変わります。

9. 余裕があれば、脆弱性面もOpenSCAPで確認する

OpenSCAP は設定ベースラインだけでなく、Ubuntu OVAL と組み合わせることで脆弱性や更新状態の確認にも使えます。Canonical は Ubuntu OVAL を、サポート中リリース向けの機械可読データセットとして提供しており、OpenSCAP で評価できると案内しています。

たとえば次のように取得して評価できます。

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2

oscap oval eval \
  --report oval-report.html \
  com.ubuntu.$(lsb_release -cs).usn.oval.xml

これはベースライン構築そのものではありませんが、作ったベースラインを維持する うえで便利です。

おわりに

Linux ハードニング入門で本当に押したいのは、設定項目を順番に暗記することではありません。安全寄りのベースラインを、速く、手間なく、ミスを減らして作ることです。その意味で、OpenSCAP はかなり優秀です。profile があり、差分確認ができ、remediation で一気に寄せられ、再評価で結果も確認できるからです。

手で全部 harden しようとすると、どうしても設定漏れや設定ゆれが起きます。ですが OpenSCAP を使えば、まず安全側の標準形を作り、そのあとで必要な例外だけ戻す、という進め方ができます。WSL の Ubuntu は、その最初の一歩を試す場所としてかなりちょうどいい環境でしたので題材に取り上げましたが、他のLinux ディストリビューションでも基本的には同様の手順となります。

是非、皆さんの環境でもお試し下しさい。

参考

• https://learn.microsoft.com/en-us/windows/wsl/wsl-config

• https://manpages.ubuntu.com/manpages/bionic//man8/oscap.8.html

• https://documentation.ubuntu.com/security/security-updates/oval/

• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening