サーバーのセキュリティ監査は、一度に完璧に行うことよりも「決まった頻度で同じ項目を確認し、前回との差分を見る」ことのほうが効果があります。この記事では、Linux で WordPress を運用しているサーバーを例に、毎週・毎月・四半期ごとに確認したい項目と具体的なコマンド、結果の記録の仕方、Lynis を使った定期診断の進め方を説明します。読み終えると、自分のサーバーに合った監査の手順書を作り、無理なく続けられるようになります。
定期監査の考え方
監査の目的は、設定が「意図した状態から変わっていないか」と「新しい弱点が生まれていないか」を確かめることです。そのため、最初に一度、正しい状態（ベースライン）を記録しておき、以降はそれとの差分を見るのが基本になります。
すべてを毎日確認しようとすると続きません。変化しやすく影響の大きいものは高い頻度で、変化しにくいものは低い頻度で確認する、と頻度を分けるのが現実的です。
- 毎週：更新の有無、ログイン履歴、異常なログ、ディスク使用量
- 毎月：ユーザーと権限、待ち受けポート、ファイアウォール、ファイルの改ざん確認、WordPress の管理者とプラグイン
- 四半期：Lynis などによる総合診断、外部からのポートスキャン、バックアップの復元テスト、手順書自体の見直し
以下のコマンドは Ubuntu / Debian を中心に書いています。RHEL 系ではパッケージ管理やログの場所が異なるため、読み替えてください。
最初にベースラインを記録する
監査の前に、現在の正しい状態をファイルに保存しておきます。保存先は root だけが読める場所にし、次のコマンドは root のシェルで実行する前提です（sudo -i で切り替えます）。
mkdir -p /root/audit && chmod 700 /root/audit
cd /root/audit
D=$(date +%Y%m%d)
ss -tulpn > ports-$D.txt
getent passwd > users-$D.txt
getent group sudo > sudo-$D.txt
find / -xdev -perm -4000 -type f 2>/dev/null | sort > suid-$D.txt
crontab -l 2>/dev/null > cron-root-$D.txt次回の監査では同じコマンドを実行し、diff ports-前回.txt ports-今回.txt のように比較します。差分が出た項目だけを詳しく調べればよいので、確認の手間が大きく減ります。
毎週の点検
更新の有無
セキュリティ更新の適用漏れは、最も多い弱点の1つです。
sudo apt update && apt list --upgradable
# 再起動が必要な状態か（Ubuntu）
ls /var/run/reboot-required 2>/dev/nullunattended-upgrades で自動更新している場合も、実際に適用されているかを /var/log/unattended-upgrades/ のログで確認します。カーネルやライブラリの更新は、再起動やサービスの再起動をするまで反映されないことがあります。needrestart を入れておくと、再起動が必要なサービスを教えてくれます。
ログイン履歴と認証ログ
last -n 20 # 最近のログイン
sudo journalctl -u ssh --since "7 days ago" | grep -i "accepted"見覚えのない時間帯や接続元からのログインがないかを確認します。新しいディストリビューションでは last コマンドの提供方法が変わり、別パッケージ（wtmpdb など）になっている場合があるため、コマンドが見つからないときは journalctl の結果を中心に確認します。失敗したログインの数が多いこと自体は、インターネットに公開されたサーバーでは珍しくありません。注目すべきは成功したログインです。SSH のサービス名は環境によって ssh または sshd なので、合わせてください。
ディスクとログの異常
df -h
sudo journalctl -p err --since "7 days ago" | tail -n 50ディスクが急に増えている場合は、ログの急増や不審なファイルの設置を疑います。
毎月の点検
ユーザーと権限
# ログインできるシェルを持つユーザー
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}'
# sudo グループのメンバー（RHEL 系は wheel）
getent group sudo
# sudoers の追加設定
sudo ls -l /etc/sudoers.d/退職者や作業終了後の外部委託先のアカウント、使われていない SSH 公開鍵（各ユーザーの ~/.ssh/authorized_keys）が残っていないかを確認します。不要なアカウントは削除する前にロックし、影響がないことを確かめてから削除します。
SSH の実効設定
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'sshd -T は設定ファイルを読み込んだ結果の実効値を表示するため、Include されたファイルの設定も含めて確認できます。設定ファイルを目で追うより、実際に効いている状態を正しく把握できます。
待ち受けポートとファイアウォール
ss -tulpn
sudo ufw status verbose # ufw の場合
sudo nft list ruleset # nftables の場合ベースラインと比べて、新しく待ち受けているポートがないかを確認します。データベースが 0.0.0.0 で待ち受けているなど、外部に開く必要のないポートが見つかったら、待ち受けアドレスを 127.0.0.1 に変えるか、ファイアウォールで閉じます。Docker を使っている場合、公開ポートがファイアウォールのルールより優先されることがあるので、次の外部スキャンでも確認します。
ファイルの改ざん確認
WordPress では、WP-CLI でコアファイルとプラグインのチェックサムを確認できます。WP-CLI は root ではなく、サイトのファイルを所有するユーザー（sudo -u www-data など）で実行します。
cd /var/www/example
wp core verify-checksums
wp plugin verify-checksums --all公式ディレクトリにない有料プラグインなどは比較対象がないため、チェックサムを確認できません。OS 全体のファイルについては、AIDE などのファイル整合性チェックツールでベースラインを作り、差分を確認する方法があります。
WordPress の管理者とプラグイン
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --update=available
wp plugin list --status=inactive見覚えのない管理者アカウントは侵害の兆候である可能性があります。使っていないプラグインは、無効化しているだけでもファイルは残るため、不要なら削除を検討します。作業前にはファイルとデータベースのバックアップを取ってください。
cron と SUID ファイル
ベースラインの cron と SUID ファイルの一覧を再取得して差分を見ます。/etc/cron.d/ や各ユーザーの crontab に見覚えのないジョブがないか、SUID ビットの付いたファイルが増えていないかを確認します。攻撃者が侵入後に永続化のために使いやすい場所です。
四半期の総合診断
Lynis で設定全体を診断する
Lynis は、OS の設定を幅広く点検し、改善の提案を出してくれるオープンソースの監査ツールです。
sudo apt install lynis # ディストリビューションのパッケージは古い場合がある
sudo lynis audit system結果の「Warnings」と「Suggestions」に改善項目が並び、詳細は /var/log/lynis.log、機械で読める形式の結果は /var/log/lynis-report.dat に保存されます。最後に表示される Hardening index は改善の目安になりますが、点数を上げること自体を目的にしないでください。提案の中には、サーバーの用途に合わないものも含まれます。各項目について「自分の環境で必要か」を判断し、対応しない場合はその理由を記録しておきます。
ディストリビューションのパッケージは最新版より古いことがあるため、新しいテスト項目を使いたい場合は提供元の配布物を確認してください（2026年10月現在）。
外部からのポートスキャン
サーバーの内側から見た状態と、外から見える状態は一致しないことがあります。別のネットワークから nmap でスキャンし、意図したポートだけが開いているかを確認します。
nmap -Pn -p- example.comスキャンは自分が管理するサーバーに対してだけ行ってください。クラウドやレンタルサーバーによっては、スキャンについて規約で定めている場合があるので、事前に確認します。
バックアップの復元テスト
バックアップが取れていても、復元できなければ意味がありません。四半期に一度は、ステージング環境にバックアップから復元し、サイトが表示され、管理画面にログインできるところまで確認します。復元にかかった時間も記録しておくと、障害時の見通しが立てやすくなります。
結果を記録して続ける
監査の結果は、日付、実施者、確認した項目、見つかった問題、対応内容と期限を表やチケットに残します。「問題なし」も記録の対象です。記録が続いていれば、問題が起きたときに「いつまでは正常だったか」を判断する材料になります。
手順をシェルスクリプトにまとめて出力をファイルに保存すると、毎回同じ手順で実施でき、差分も取りやすくなります。ただし、スクリプトで自動化した場合も、結果を人が読む時間を予定に入れておくことが大切です。
まとめ
- 最初にベースラインを記録し、以降は差分を中心に確認する
- 毎週は更新・ログイン履歴・ログ、毎月はユーザー・SSH・ポート・改ざん・WordPress の管理者とプラグイン、四半期は総合診断と復元テスト
sshd -Tやss -tulpnで実効の状態を確認し、外部からのスキャンでも見え方を確かめる- WordPress は
wp core verify-checksumsとwp plugin verify-checksumsで改ざんを確認する - Lynis の提案は用途に合わせて取捨選択し、対応しない理由も記録する
- 結果は「問題なし」も含めて記録し、手順書を定期的に見直す