Lynis の hardening index：60 から 85 へ

2026-04-27

新しい VPS で Lynis を初めて走らせると、たいてい 60 前後の数字と、どれから手をつければよいのか分からない長い提案の一覧が出ます。よい知らせ：80 から 85 は一晩の作業で、しかも大半の手順は見せかけではなく本当にやる価値があります。悪い知らせ：最後の十五点は借りている仮想マシンでは手が届かず、それを追いかけるのは間違いです。

この index が示すものと示さないもの

hardening index は、重みづけ込みで、通過したテストの総数に対する割合です——安全性のパーセンテージではありません。Lynis はおよそ三百のテストを走らせ、二つの別々の一覧を出します。本当の問題らしく見える warnings と、改善しうる事柄である suggestions です。常に警告から始めてください。たいていほんの数件しかありません。

百点は起こりません。ある提案はシステムを入れる時点の決断を要求し（/home、/tmp、/var の分割）、あるものは VPS には無いブートローダーへのアクセスを要求し、いくつかは互いに矛盾します。そして自分の index を他人のものと比べるのは無意味です。Lynis はマシンで動いているものに対して減点するからです。動いているサービスが一つ増えるたび、開いたポートが一つ、独自の設定が一つ、そして新しい提案が十件ほど増えます。だからこそ高い数字は SSH 以外は何も動いていないところでよく見られます。サイトとデータベースとメールを載せた実働サーバーなら、85 はよい結果です。

root で実行してください

sudo lynis audit system

sudo なしでは、Lynis はシステムファイルを必要とするテストをすべて飛ばし、低い index を報告します——サーバーが悪いからではなく、その確認が見えなかったからです。レポートは /var/log/lynis-report.dat に、読める形のログは /var/log/lynis.log に書かれます。

出力の各行はテスト識別子で始まります。たとえば SSH-7408 や KRNL-6000 です。その識別子で説明もテストの止め方も探せます——その形を覚えておいてください。以下のすべてはこれを軸に回ります。

実際に数字を動かすもの

SSH（SSH-7408）。最も重い塊です。一つのテストが十を超えるパラメータを同時に見ます。sshd_config 全体を編集しないでください。パッケージ更新が成果を消してしまわないよう、別ファイルを置きます。

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

サービスを読み直す前の sshd -t は必須です。セッションが開いているうちに設定を間違えると、あなたは外に取り残されます。そして PasswordAuthentication no を入れる前に、鍵が本当に効くことを——開いたままの二つ目のターミナルから——確かめてください。

カーネルパラメータ（KRNL-6000）。このテストは二十ほどの sysctl 値を見ます。そのためのファイル：

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

入っていないツール。提案のかなりの部分は単に「無いものを入れよ」です。auditd（システムイベントの記録）、aide（ファイルの完全性）、debsums（パッケージの完全性）、unattended-upgrades（自動セキュリティ更新）、sysstat と acct（プロセスの記録）、マルウェアスキャナ。それぞれが提案を一つ二つ閉じますが、点数のために入れないでください。それらが無ければ、事故の後に何も再構成できません。

労力に見合う小さな項目。/etc/login.defs の umask 027、同じファイルのパスワード有効期間、/etc/issue と /etc/issue.net のバナー、root だけが読めるコンパイラ（chmod 700 /usr/bin/gcc）。バナーについて正直に言えば、安全には何も寄与しません。法的な形式です——ただし点数は確かにくれます。

login.defs の落とし穴

sed の行置換で umask を編集すると、ファイルに UMASK の行が複数残ることがよくあります。すると Lynis は値を数えず、設定は済んでいるように見えるのにテスト AUTH-9328 は赤いままです。編集後に確認してください。

grep -c '^UMASK' /etc/login.defs

ちょうど一行であるべきです。そのファイルの他のパラメータについても同じことが言えます。

誤検知と、その正しい黙らせ方

いくつかの警告はあなたのサーバーにはまったく当てはまりません。生きた例：ある大手プロバイダーの VPS で、テスト PKGS-7388 がセキュリティリポジトリが見つからないと報告します——リポジトリが deb822 形式でミラーファイル参照として記述されており、Lynis は見慣れた書き方を探しているからにすぎません。セキュリティ更新はきちんと届いています。

これはレポートから行を消すのではなく、プロファイルで黙らせます。プロファイルファイルの拡張子は .prf です（.prof ではありません——ここで三十分を失うのは簡単です）。自分のルールは /etc/lynis/custom.prf に入れます。

skip-test=PKGS-7388
skip-test=KRNL-5788

ルールは一つ。各行には、なぜそのテストを飛ばすのかを書いたコメントが必要です。半年後には、当てはまらないから切ったのか、直すのが面倒だったから切ったのかを覚えていません——そしてこの二つの違いこそが要点なのです。

やってはいけないこと

数字を追いかけないでください。都合の悪いテストを切れば index は簡単に膨らみますし、ある水準から先はそれが唯一の道です——ただしサーバーがそれで安全になるわけではありません。役に立つのは別のことです。自分の値を記録し、その変化を見ること。更新の後や誰かが設定を書き換えた後に落ちた index は、その絶対値よりずっと価値のある信号です。

だからこそ Lynis は一度きりではなく定期実行し、比べるものが残るようレポートを保存する価値があります。一つのページにまとめるとどう見えるかは下のデモで：index、テスト識別子つきの警告一覧、そして前回の実行から何が変わったかです。