5分でサーバーセキュリティ監査を実行する
新しいサーバーを受け取った直後、またはVPSのデプロイが完了した直後に、最初に浮かぶ疑問がある：このサーバーはハッカーに開かれているのだろうか？Lynisはたった3つのコマンドでその疑問に答えてくれる：
# Lynisをインストール (Ubuntu/Debian)
sudo apt install lynis -y
# システム全体を監査する
sudo lynis audit system
# 概要結果を表示する
sudo lynis show detailsスキャンには約2〜3分かかる。出力の末尾にHardening indexの行が表示される — 100点満点のセキュリティスコアだ。新規インストールのUbuntuサーバーは通常55〜65点を獲得する。実際の目標は80+に引き上げることだ。
なぜLynisは他のスキャナーと違うのか？
NessusやOpenVASは外部からサーバーをスキャンする — リモートからX線を撮るようなものだ。Lynisは違う：サーバーの内部で直接実行され、設定ファイル、カーネルパラメータ、ユーザー権限、そしてリモートスキャナーでは見えない200以上のチェックポイントを直接読み取る。
10台以上の実際のサーバーを監査した結果、ほとんどが共通の脆弱性を抱えていることに気づいた：SSHがまだrootログインを許可している、ファイアウォールが有効になっていない、ログローテーションが設定されていない、SUID/SGIDファイルが管理されていない。それぞれ修正に5〜10分しかかからない — しかしスキャンツールがなければ見逃しやすい。
Lynisは何をチェックするのか？
- 認証：SSH設定、PAM、sudoルール、パスワードポリシー
- ファイルシステム：マウントオプション、誰でも書き込み可能なファイル、SUID/SGIDバイナリ
- カーネル：sysctlパラメータ、カーネルハードニング
- ネットワーク：開いているポート、ファイアウォール状態、TCP/IPスタック設定
- ソフトウェア：パッケージ更新、マルウェアスキャナー、ログデーモン
- ユーザーとグループ：UID 0アカウント、空のパスワード、ホームディレクトリ権限
Lynisの結果を読む — 出力の各行を理解する
スキャン後のターミナルはかなり威圧的に見える — 数百行にわたるカラフルな文字の壁だ。実際の構造はとてもシンプルで、4つの記号を覚えるだけでいい：
[OK]— 合格、何もする必要なし[WARNING]— 問題あり、早めに修正すべき[SUGGESTION]— 改善の提案、優先度に応じて対処[FOUND]— 注目すべきものを検出、さらにレビューが必要
出力の末尾にスクロールすると最も重要な部分がある — SuggestionsとWarningsのセクションだ：
# 警告の詳細を表示する
grep -A 3 "Warning" /var/log/lynis.log
# 完全なレポートを表示する
cat /var/log/lynis-report.datファイル/var/log/lynis-report.datにはすべての結果がmachine-readable形式で保存されており、自動解析やモニタリングスクリプトへの投入に便利だ。
よくある警告とその修正方法
1. SSHのrootログインが許可されている
# 修正：SSHのrootログインを無効にする
sudo sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl reload sshd2. ファイアウォールが有効になっていない
# UFWを有効にする
sudo ufw enable
sudo ufw allow ssh
sudo ufw status3. カーネルハードニング — sysctlが最適化されていない
# /etc/sysctl.confに追加する
cat >> /etc/sysctl.conf << 'EOF'
# IPフォワーディングを無効にする（ルーターでない場合）
net.ipv4.ip_forward = 0
# SYNフラッド攻撃への対策
net.ipv4.tcp_syncookies = 1
# /proc内のカーネルポインタを隠す
kernel.kptr_restrict = 2
# dmesgアクセスを制限する
kernel.dmesg_restrict = 1
EOF
sudo sysctl -p4. マルウェアスキャナーがない
# rkhunterをインストール
sudo apt install rkhunter -y
sudo rkhunter --update
sudo rkhunter --check上級：本番環境向けLynisのカスタマイズ
非インタラクティブモードでLynisを実行（cronジョブ用）
# サイレント実行、Enterを求めない
sudo lynis audit system --quiet --no-colors 2>&1 | tee /tmp/lynis-$(date +%Y%m%d).log
# タイムスタンプ付きでレポートを保存する
sudo cp /var/log/lynis-report.dat /var/backups/lynis-report-$(date +%Y%m%d).dat週次監査のcronジョブを作成する
# crontabに追加する
sudo crontab -e
# 毎週月曜日の午前3時に実行する
0 3 * * 1 /usr/bin/lynis audit system --quiet > /var/log/lynis-weekly.log 2>&1カスタムプロファイル — 関係のないチェックをスキップする
DockerでIPフォワーディングを意図的に有効にしているサーバーの場合、毎回スキャンするたびにLynisに警告を出してほしくない。除外するためにカスタムプロファイルを作成しよう：
# カスタムプロファイルを作成する
sudo cp /etc/lynis/default.prf /etc/lynis/custom.prf
# custom.prfに例外を追加する
echo 'skip-test=NETW-3012' >> /etc/lynis/custom.prf
# カスタムプロファイルで実行する
sudo lynis audit system --profile /etc/lynis/custom.prfテストID（NETW-3012など）は出力またはファイル/var/log/lynis-report.datで確認できる。
時系列でhardening indexを追跡する
# レポートからhardening indexを取得する
grep 'hardening_index' /var/log/lynis-report.dat
# 出力形式：hardening_index=67
# 警告を修正した後、再実行して比較するLynis使用時の実践的なTips
すべての提案を一度に修正しないこと。 Lynisは通常30〜50の提案を出すが、すべてが必要なわけではない。まずWarningsを処理し、次にSuggestionsに取り掛かる。Suggestionsの中では、認証とネットワークに関連するものを優先しよう — それが最大の攻撃対象となる。
本番環境に触れる前にステージングでテストすること。 sysctlやPAM設定などの変更は、実行中のサービスに影響を与える可能性がある。実体験として：本番環境でカーネルハードニングを修正した際、IPフォワーディングを無効にしたことでいくつかのコンテナがネットワークエラーを起こした。ステージング先行、本番後回し — 例外なし。
Lynisは設定を監査するものであり、パッケージの脆弱性を監査するものではない — これは知っておくべき限界だ。完全なパッチ適用には、以下も組み合わせよう：
- セキュリティパッチを自動更新する
unattended-upgrades - ブルートフォースをブロックする
fail2ban - マルウェアをスキャンする
ClamAVまたはrkhunter
セットアップ完了後すぐにベースラインを保存すること。 重要な警告を修正してhardening indexが80+になったら、レポートをベースラインとして保存しよう。次回大きな変更がある際に再実行してdiffを取る — 設定のドリフトを検出する最速の方法だ。
# ベースラインを保存する
sudo lynis audit system
sudo cp /var/log/lynis-report.dat /root/lynis-baseline-$(date +%Y%m%d).dat
# 後で比較する
diff /root/lynis-baseline-20240101.dat /var/log/lynis-report.dat | grep '^[<>]'新しいサーバーをオンボードするたびに、Lynisの実行を最初のステップにすべきだ — コードをデプロイする前でさえも。今日30分のスキャンと基本的な修正が、後にインシデントをトレースする徹夜を防いでくれるかもしれない。
