Quick start: 5分ではじめるサーバーセキュリティスキャン
VPSを立ち上げたばかりで、システムのどこにセキュリティホールがあるか把握できていないなら、まずは以下のコマンドを実行してみてください。UbuntuのデフォルトリポジトリにあるLynisパッケージは古いことが多いため、開発元CISOfyの公式リポジトリから直接導入するのが最も確実です。
# 1. CISOfy公式リポジトリを追加
sudo apt update && sudo apt install -y curl apt-transport-https
curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/cisofy.gpg
echo "deb [arch=amd64] https://packages.cisofy.com/community/lynis/deb/ stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
# 2. Lynisをインストール
sudo apt update
sudo apt install -y lynis
# 3. システム全体の監査を実行
sudo lynis audit system --quick
--quickフラグを付けることで、Enterキーの入力待ちを挟まずに一連の処理をスムーズに実行できます。2〜3分ほどで、100点満点のHardening indexスコアとともに、Warnings(高リスク警告)やSuggestions(改善提案)の一覧が画面に表示されます。
Lynisの動作原理とスキャン結果の読み解き方
Lynisはホスト型のセキュリティ監査ツール(host-based auditing)です。外部から開いているポートを調べるだけのNmapとは異なり、OS内部でroot権限にて直接動作します。カーネル設定、重要なファイルのパーミッション、システムアカウント、systemdサービス、SSH設定から未適用のパッチに至るまで、徹底的に診断します。
以前CentOSからUbuntuへ移行した際、UFWとFail2banを有効化しておけば十分安全だろうと高をくくっていたことがありました。しかし、Node.jsウェブアプリが稼働するサーバーで初めてLynisを実行したところ、Hardening Indexはわずか58/100でした。普段は見落としがちな設定の甘さが次々と浮き彫りになったのです。
ログファイルの確認とリスクレベルの分類
スキャンが完了すると、システム上に2つの重要なファイルが生成されます:
/var/log/lynis.log:各テスト項目や実行されたコマンドの詳細ログ。/var/log/lynis-report.dat:技術的パラメータや提案コード(test-id)がまとめられた簡潔なレポート。
何千行もある生のログをすべて読む必要はありません。以下の主要な2つのグループをgrepで手早く抽出するだけで十分です:
# 危険度の高い警告(Warning)を抽出
sudo grep -E "^Warning:" /var/log/lynis.log
# test-id付きのすべての推奨事項(Suggestion)を抽出
sudo grep -E "^Suggestion:" /var/log/lynis.log
各SuggestionにはSSH-7408やFILE-7524といった識別コードが付与されています。開発元による詳細な対策手順を確認したい場合は、直接コマンドを実行します:
lynis show details SSH-7408
Ubuntuで最も頻出する3大推奨項目
本番環境のサーバー8台を運用して観察した結果、スコアを下げる要因として常に上位に挙がるのは以下の3グループでした:
- カーネルの堅牢化(KRNL-5830):
/etc/sysctl.confでIPスプーフィング防止やSYN flood攻撃対策が有効化されていない。 - SSH設定(SSH-7408):ポートフォワーディングが許可されたままであったり、
ClientAliveInterval 300が未設定、あるいは脆弱な暗号スイートが残っている。 - /tmpパーティションの保護不足:
/tmpや/var/tmpにnoexec,nosuid,nodevのマウントオプションが付与されていない。悪意あるスクリプトをここに配置され、直接実行されるリスクがあります。
監査スケジュールの自動化とアラート通知
一度手動でスキャンしてそのまま放置していては根本的な解決になりません。コードのデプロイ、ユーザー変更、新規パッケージのインストールを行うたびに、セキュリティ構成は容易にズレてしまいます。夜間に定期監査を自動実行することで、継続的なリスク管理が可能になります。
カスタムプロファイルを作成して不要な警告を除外する
サーバーにはそれぞれ固有の役割があります。純粋なNginxウェブサーバーであれば、ApacheやCUPSプリンター関連の項目を計測する必要はありません。カスタムプロファイルを作成し、不要なテストを無効化しましょう:
sudo nano /etc/lynis/custom.prf
以下の設定を記述します:
# Nginxのみ運用の場合はApacheのテストをスキップ
skip-test=HTTP-6622
# 印刷サービス(CUPS)のテストをスキップ
skip-test=PRNT-3802
# 詳細な説明がない警告を非表示にする
silence_warnings_without_description=yes
週次監査用Cronjobの設定
Lynisをcronjobモード(ANSIカラー出力なし、ターミナル不要)で実行し、警告が発生した際にログへ記録するシェルスクリプトを作成します:
sudo nano /usr/local/bin/run-lynis-audit.sh
スクリプトの内容:
#!/bin/bash
LOG_FILE="/var/log/lynis-cron.log"
DATE=$(date +'%Y-%m-%d')
# カスタムプロファイルを使用してバックグラウンドで監査を実行
/usr/sbin/lynis audit system --cronjob --profile /etc/lynis/custom.prf > "$LOG_FILE"
# ログ内の新規警告数をカウント
WARNINGS=$(grep -c "^Warning:" /var/log/lynis.log)
if [ "$WARNINGS" -gt 0 ]; then
echo "[!] $DATE: Lynisセキュリティ警告が $WARNINGS 件検出されました!" >> /var/log/security-alerts.log
fi
スクリプトに実行権限を付与し、毎週月曜日の深夜3時に実行されるよう設定します:
sudo chmod +x /usr/local/bin/run-lynis-audit.sh
echo "0 3 * * 1 root /usr/local/bin/run-lynis-audit.sh" | sudo tee /etc/cron.d/lynis-weekly
本番環境運用の現場から得た実践的ノウハウ
ステージング環境および本番環境のサーバー群でLynisを半年以上運用して得られた、実践における重要な教訓を共有します:
- スコア100点を目指さない:理想的なスコア範囲は75〜85点程度です。90点以上を狙うと極端なカーネルのロックダウンやパーミッション制限が必要となり、Dockerデーモン、Node.jsプロセス、GitLab Runnerなどの正常な動作を妨げる原因になります。
- sysctlの調整は慎重に行う:パケットスプーフィング防止パラメータ
net.ipv4.conf.all.rp_filter = 1は、DockerのネットワークブリッジやWireGuard VPNと競合しやすい傾向があります。本番環境に適用する前に、検証環境で十分にテストしてください。 - AIDEによるファイル整合性監視の併用:Lynisはスキャン時点における設定の脆弱性を指摘するツールです。
/etcや/bin内のシステムファイルに対する不正な改ざんを検知したい場合は、AIDEやTripwireと組み合わせることをおすすめします。 - ログの一元管理:3台以上のノードを管理している場合、各サーバーで
lynis-report.datを手動確認するのは非効率です。メトリクスをGrafana Lokiや集中型rsyslogに直接転送し、ダッシュボードで一元可視化できるようにしましょう。

