CyberPatriot Linux ハードニングツールキット

競技中の時間的プレッシャーの中で Debian/Ubuntu 系システムをハードニングするためのモジュール式 Bash ツールキット。CyberPatriot National Youth Cyber Defense Competition の複数シーズンにわたって構築・改良されており、直近では 2025 年準決勝ラウンドの Linux 部門でプラチナティアに入賞した。

これは汎用のコンプライアンスフレームワークではない。6 時間の時間制限付き演習のためのチェックリスト自動化ツールである。Linux ハードニングパスのうちスクリプト化可能な大部分を、正確に、迅速に、冪等に実行し、触れたものすべてをログに記録し、判断が必要な部分は実行者に委ねる。

目次

• なぜこれが存在するのか
• アーキテクチャ
• クイックスタート
• 実際に何をするのか
• 競技における安全性の注意事項
• 設定
• リポジトリ構成
• テスト
• セキュリティコントロールと参考文献
• このプロジェクトが意図的に行わないこと
• ライセンス

なぜこれが存在するのか

CyberPatriot の Linux ラウンドでは、ライブイメージがルーブリックに照らして採点される。ルーブリックはかなり予測可能な一連のハードニング手順 -- アカウント衛生、パスワードポリシー、ファイアウォール設定、サービス公開、ファイルパーミッション、パッチレベル -- を、厳しい時間制限の下で評価する。しかも通常、どの脆弱性が仕込まれているかの事前通知はない。そのチェックリストを手作業で、正確に、カウントダウンの中でこなすことこそ、チームが未知の内容ではなくタイプミスや忘れた手順によって簡単な得点を失う場面である。

このツールキットは、まさにそのプレッシャーの下で書かれた単一のモノリシックスクリプトとして始まった。このリポジトリはそのスクリプトの書き直しである。チェックリストのカバレッジは同じままだが、小さな単一目的のモジュールに再構成され、読みやすく、テストしやすく、個別に推論しやすくなっており、自明でない判断はすべて特定の CIS Benchmark セクションまたは NIST SP 800-53 コントロールに紐付けられている（セキュリティコントロールと参考文献を参照）。

アーキテクチャ

flowchart TD
    A[bin/harden.sh] --> B[lib/common.sh<br/>logging, backups, run wrapper]
    A --> C[Service-role prompts<br/>or --config file]
    A --> D[lib/packages.sh<br/>updates, attack-tool removal]
    A --> E[lib/firewall.sh<br/>default-deny + ufw]
    A --> F[lib/ssh.sh]
    A --> G[lib/services.sh<br/>samba/ftp/mail/http/mysql/dns]
    A --> H[lib/users.sh<br/>account review, hidden UID 0]
    A --> I[lib/kernel.sh<br/>sysctl hardening]
    A --> J[lib/pam.sh<br/>password policy, lockout]
    A --> K[lib/filesystem.sh<br/>permissions, cron, banners]
    A --> L[lib/monitoring.sh<br/>fail2ban, auditd, rkhunter]
    A --> M[lib/forensics.sh<br/>baseline snapshot]
    D & E & F & G & H & I & J & K & L & M --> N[(~/hardening-run/<br/>log + backups + baseline)]

すべてのモジュールは bin/harden.sh から source される。このスクリプトが引数解析、サービス役割の質問、実行順序を担う。モジュール同士が直接呼び合うことはなく、各モジュール内の状態を変更するすべてのコマンドは lib/common.sh の run() ラッパーを通る。これによりプロジェクト全体でドライラン対応、一貫したログ記録、致命的でないエラー処理を実装する場所が 1 か所に集約される。

クイックスタート

git clone <this-repo>
cd cyberpatriot-linux-hardening
sudo ./bin/harden.sh

マシンの役割について短い一連の yes/no 質問（Samba、FTP、SSH、Web サーバーなどが必要かどうか）を尋ねられた後、上記のモジュール群を通して無人で実行される。ログ、タイムスタンプ付きの設定バックアップ一式、システムベースラインスナップショットが ~/hardening-run/ に書き出される。

実際のラウンドでは、パッケージごとの確認プロンプトをスキップし、役割の質問にはその場で入力する代わりに用意した回答ファイルから答える：

cp examples/config.env.example my-machine.env
# edit my-machine.env for this box's actual role
sudo ./bin/harden.sh --config my-machine.env --auto-approve

何も触る前に、正確に何をするのかを確認したい場合：

sudo ./bin/harden.sh --dry-run --config my-machine.env

実際に何をするのか

tools/find-port-owner.sh と tools/list-nonstandard-users.sh は、同じ種類のトリアージ作業のための小さなスタンドアロンユーティリティであり、メインスクリプトとは独立して使用できる -- 使用方法は各ヘッダーを参照。

競技における安全性の注意事項

保護すべきマシンを壊してしまうハードニングスクリプトは、時間制限付きのラウンドでは役立たず以下である。いくつかのデフォルトはそのことを反映しており、無人で実行する前に理解しておく価値がある：

• SSH パスワード認証はデフォルトで有効。 より厳格な鍵のみの CIS 推奨は設定値 1 つ分の違い（SSH_PASSWORD_AUTH=no）だが、ここでのデフォルトは、まだ誰も鍵を用意していないときにチームが自分たちのマシンから締め出されることを避ける方を優先している。
• デュアルユースツールは自動削除されず、レビューされる。 nmap、Wireshark、tcpdump、netcat の各種は一般的な攻撃者ツールだが、一般的な管理者ツールでもあり、一部の競技イメージではマシンの宣言された役割のために特定のツールが明示的に必要とされる。これらは確認後にパージされ、黙って削除されることはない。
• ClamAV と rkhunter/chkrootkit スイープはオプトイン（INSTALL_CLAMAV、RUN_BASELINE_SCAN）。これはこのスクリプトが実行しうる最も遅い 2 つの処理であり、どちらも単独ではシステム状態を変更しないためである。チェックリストが要求する場合、または時間に余裕がある場合は有効にすること。
• ここにあるものはスコアリングエンジンの接続性を検証しない。 ファイアウォールモジュールはデフォルトで送信全許可であり、役割が不要とするサービスの受信ポートのみを閉じる。しかし特定のイメージが非標準ポートでスコアリングサーバーやローカルエージェントに報告する場合、それを確認するのは利用者の責任である -- 初めてマシンをハードニングする前に実際に何がリッスンしているか不明な場合は、以前の実行による ~/hardening-run/baseline/listening_ports.txt を参照すること。
• GRUB パスワードは自動化されない。 同じ理由から：不適切な GRUB パスワードは、ハードニングパスをラウンド途中で迅速な復旧手段のない起動不能なマシンに変えてしまう可能性がある。手動手順については docs/security-controls.md を参照。
• すべてのモジュールは冪等である。 すでにハードニングされたマシンに対してスクリプトを再実行しても（たとえば部分的な実行が中断された後など）、設定ブロックが重複したりエラーで終了したりすることはない。

設定

bin/harden.sh は、事前に回答しない場合、マシンのサービス役割について対話的に尋ねる。プロンプトをスキップするには、examples/config.env.example をコピーし、実際の役割を記入して --config で渡す。ファイルから省略した変数は対話的プロンプトにフォールバックするため、部分的に記入された設定ファイルでも問題ない。

sudo ./bin/harden.sh --config my-machine.env

フラグ：

リポジトリ構成

.
├── bin/harden.sh                    orchestrator: parses args, asks role questions, runs modules in order
├── lib/
│   ├── common.sh                    logging, backups, idempotent file edits, the run() wrapper
│   ├── packages.sh                  updates, attack-tool removal
│   ├── ssh.sh                       SSH install/removal and hardening
│   ├── services.sh                  samba/ftp/telnet/mail/printing/mysql/http/dns
│   ├── firewall.sh                  ufw default-deny posture
│   ├── users.sh                     account review, hidden UID 0 / empty password detection
│   ├── kernel.sh                    sysctl hardening
│   ├── pam.sh                       password policy, account lockout
│   ├── filesystem.sh                permissions, cron, rc.local, banners, anomaly scan
│   ├── monitoring.sh                fail2ban, auditd, rkhunter, chkrootkit, ClamAV
│   └── forensics.sh                 read-only system baseline snapshot
├── tools/
│   ├── find-port-owner.sh           resolve a listening TCP port to a process path
│   └── list-nonstandard-users.sh    flag UID >= 1000 accounts not on an expected list
├── docs/
│   ├── security-controls.md         every hardening decision, mapped to its source standard
│   └── editor-cheatsheet.md         small editor commands worth remembering under pressure
├── examples/config.env.example      annotated template for non-interactive runs
└── .github/workflows/shellcheck.yml lint on every push/PR

テスト

すべてのスクリプトは GitHub Actions 経由で push 時に ShellCheck でリントされる（.github/workflows/shellcheck.yml）。PR を開く前にローカルでチェックするには：

shellcheck lib/*.sh bin/*.sh tools/*.sh

bin/harden.sh --dry-run もそれ自体がテストである。ファイルシステムに触れたり何かをインストールしたりせずに、すべてのモジュールの制御フローとログ記録を実行し、実際に実行する前に使い捨ての VM に対して変更を健全性チェックする最速の方法である。新しいモジュールに関する完全な期待事項（冪等性、破壊的アクションを run() 経由でルーティングすること、新しいハードニング手順の出典を引用すること）については CONTRIBUTING.md を参照。

セキュリティコントロールと参考文献

各モジュールのヘッダーコメントと docs/security-controls.md は、各判断の背後にある特定の標準セクションを引用している。全体を通して使用されている一次情報源：

参照されている検出ツール（ベンダリングはされておらず、apt 経由でインストール）： fail2ban、 Linux Audit / auditd、 rkhunter、 chkrootkit。Lynis と OpenSCAP はフォローアップとして独立した監査に推奨されており、このプロジェクトによって自動実行されることはない。

このプロジェクトが意図的に行わないこと

• GRUB ブートローダーパスワードの自動化（起動不能マシンのリスク；上記参照）
• SUID／誰でも書き込み可能／rootkit スキャンで見つかったものの自動修復 -- 検出結果は人間によるレビューのためにログに記録され、自動的に処理されることは決してない
• いかなる種類の攻撃的列挙ツールのダウンロードや実行
• 明示的に認識しないパッケージへの干渉 -- 見慣れないパッケージ（スコアリングエージェントである可能性が十分にある）は推測せずに放置される
• GUI 専用設定（スクリーンロックのタイムアウト、アップデートマネージャーの設定、ブラウザー設定）のカバー -- これらは依然として手作業で確認する必要がある

これらそれぞれの背後にある完全な理由については docs/security-controls.md を参照。

ライセンス

MIT。LICENSE を参照。