KUSANAGIと「しゃべって」みた日～Gemini CLIで自然言語運用の実験

こんにちは。KUSANAGI 開発チーム、プロダクトマネジャーの相原です。

サーバ運用と聞くと、黒い画面に難しいコマンドを打ち込む姿を思い浮かべる方も多いかもしれません。
KUSANAGIも、専用コマンドでできるだけ運用を楽にしていますが、オプションなども含めて「正しい」書式で入力する必要があります。

私は以前から、「OK, Google.」のように声や自然な文章でKUSANAGIを操作できたら…と思っていました。
そんな中、KUSANAGIの自然言語操作を可能にするGemini CLIがOSSとして利用できるようになり、その未来がぐっと近づいたと感じました。
今回は、Gemini CLIを使ってKUSANAGIサーバをAIと会話しながら運用する実験レポートをお届けします。

Gemini CLIとは？KUSANAGIサーバを自然言語で操作できるAIエージェント

Gemini CLIは、GoogleのGeminiをターミナルから使えるオープンソースのAIエージェントです。
自然言語で書いた指示を解釈し、実行に必要なシェルコマンドを提案・実行してくれます。

サーバ運用の自動化やKUSANAGIの運用効率化にも応用でき、MCPによる機能拡張や非対話モードを活用した自動化など、多くの可能性を秘めています。

KUSANAGIにGemini CLIをインストール

今回は、KUSANAGI 9 AlmaLinux OS 9（無償版、プロビジョン済み環境）にGemini CLIを導入しました。

1. Node.jsをインストール

Gemini CLIを利用するには、Node.js version 20以上が必要です。KUSANAGIの無償版にはNode.jsがインストールされていないので、リポジトリからインストールします。

# dnf install kusanagi-nodejs22

2. Gemini CLIをインストール

# npm install -g @google/gemini-cli

3. 初期設定

kusanagiユーザーに切り替えてGemini CLIを起動します。操作範囲は起動ディレクトリ以下になるため、プロファイル配下で作業するのが安全です。

 gemini

今回はGoogleの個人アカウントを使う方法を紹介しますが、個人アカウントや無料APIではコマンドや結果が学習データに利用されるため、機密情報を扱わないことが重要です。実運用では、有料APIなど学習されない認証方法を検討してください。

※Gemini CLI 認証設定：https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/authentication.md

認証手順は以下の通りです。

Gemini CLI再起動 → 認証用URLが表示されるのでコピー（①）
ブラウザで開き、Googleにログイン（②）
表示されたコードをコピー（③）
サーバの「Enter the authorization code:」に貼り付ければ完了

※Gemini CLIをLinuxで動作させる方法は初期からかなり変わっているので。最新の情報を確認するようにしてください。

KUSANAGIと自然言語で会話する

ステータス確認

「KUSANAGIのステータスを確認して説明してください」と入力すると、kusanagi statusの結果を取得し、サーバ構成や稼働中サービスを自然言語でわかりやすく解説してくれます。

✦ KUSANAGIのステータスが確認できました。結果は以下の通りです。

   * プロファイル名: kusanagi-x
   * FQDN: kusanagi-x.local
   * アプリケーションタイプ: WordPress (wp)
   * KUSANAGIバージョン: 9.6.13-1.el9

  稼働中のサービス:

   * nginx (nginx129): WebサーバーとしてNginxが有効で、稼働中です。
   * php (php81): PHP-FPMが有効で、稼働中です。
   * mariadb (mariadb10.6): MariaDBが有効で、稼働中です。

  停止中のサービス:

   * httpd (httpd24): Apacheはインストールされていますが、現在停止しています。
   * psql, pgpool-II: PostgreSQL関連のサービスは利用されていません。

  その他:

   * キャッシュ: bcache（bcache-based page cache）とfcache（file-based page cache）は両方とも無効（off）になっています。
   * WAF (Web Application Firewall): 無効（off）です。
   * SELinux: 無効（off）です。

  要約すると、現在この環境はNginx、PHP 8.1、MariaDB
  10.6の構成でWordPressサイトが稼働している状態です。キャッシュやWAFは利用されていません

状態を平易に説明

「今のKUSANAGIの状態を分かりやすく教えて」と聞くと、用語をかみ砕き、読み方まで添えて説明してくれました。非エンジニアにも優しい印象です。「kusanagi-x という名前のWordPressサイト」はちょっと惜しい^^;

✦ KUSANAGIは現在、以下のような状態で稼働しています。

   * プロファイル: kusanagi-x という名前のWordPressサイトが設定されています。
   * Webサーバー: Nginx（エンジンエックス）が稼働して、サイトを表示しています。
   * PHP: PHPバージョン8.1が動作しています。
   * データベース: MariaDB（マリアデービー）というデータベースが稼働しています。

  要するに、WordPressサイト「kusanagi-x」が、Nginx上で正常に動いている状態です。

  補足情報:
   * パフォーマンスを高速化するためのキャッシュ機能（bcache, fcache）は現在オフになっています。
   * セキュリティを強化するWAF（Web Application Firewall）とSELinuxもオフの状態です。

サーバ負荷状況を自然言語で解析

「サーバの負荷状況を教えて」という質問に対し、uptimeやtop、dfなどのコマンドを実行。
CPUの待機率、ロードアベレージ、メモリやディスクの空き容量を数値付きで解説し、「非常に快適な状態です」とまとめてくれました。

✦ 現在のサーバーの負荷状況は非常に低く、安定して稼働しています。

   * CPU:
       * CPUはほとんど処理を行っておらず、90%以上が待機状態です。
       * 処理待ちのタスクを示すロードアベレージも「0.00」で、負荷は全くかかっていません。

   * メモリ:
       * メモリにも十分な空きがあります。システムが高速化のために利用しているキャッシュメモリを除いても、余裕のある状態
         です。

   * ディスク容量:
       * メインのディスク容量は約13%の使用率で、空き容量も全く問題ありません。

  全体として、CPU、メモリ、ディスクのいずれのリソースにも大きな余裕があり、サーバーは非常に快適な状態です。

アクセスログ解析で攻撃兆候をAIが分類

最新100件のアクセスログを解析し、コマンドインジェクションや管理画面スキャンなど、攻撃の可能性があるアクセスを分類・解説。
最後に「必要ならファイアウォールで拒否可能」と対策案まで提示してくれました。プロンプト未調整でここまでの精度は優秀です。

✦ アクセスログを確認しました。いくつか攻撃の可能性がある不審なアクセスが見つかりました。

  攻撃の可能性が高いアクセス:

   1. コマンドインジェクションの試み:
       * IPアドレス: **.***.**.***
       * リクエスト: GET /cgi-bin/nobody/Search.cgi?action=*******
       * 解説: これは、CGIの脆弱性を狙った典型的なコマンドインジェクション攻撃です。wgetコマンドを実行させ、外部から不正なシェルスクリプト
         (rondo.cye.sh) をダウンロードして実行しようとしています。幸い、このサーバーには該当するCGIが存在しないため、ステータスコード404
         Not Foundとなり、攻撃は失敗しています。

   2. 設定ファイルへのアクセス試行:
       * IPアドレス: ***.**.**.**
       * リクエスト: GET /.git/config HTTP/1.1
       * 解説: これは、CGIの脆弱性を狙った典型的なコマンドインジェクション攻撃です。wgetコマンドを実行させ、外部から不正なシェルスクリプト
         (rondo.cye.sh) をダウンロードして実行しようとしています。幸い、このサーバーには該当するCGIが存在しないため、ステータスコード404
         Not Foundとなり、攻撃は失敗しています。

  その他の不審なアクセス:

   * 存在しない管理画面へのアクセス:
       * IPアドレス: ***.**.**.*
       * リクエスト: GET /cgi-bin/luci/*********1
       * 解説: luci (OpenWrtの管理画面) や login.asp (古いルーターや機器で使われることが多い)
         といった、一般的によく知られた管理画面のパスをスキャンしています。WordPressとは関係ないため、404 Not Found
         になっています。これは無差別な脆弱性スキャンの一環です。

   * 判読不能なリクエスト (プロトコルエラー):
       * IPアドレス: *.***.**.***, ***.***.***.***, **.***.**.**
       * リクエスト: \x16\x03\x01..., SSH-2.0-Go, t3 12.1.2 など
       * 解説: これは、CGIの脆弱性を狙った典型的なコマンドインジェクション攻撃です。wgetコマンドを実行させ、外部から不正なシェルスクリプト
         (rondo.cye.sh) をダウンロードして実行しようとしています。幸い、このサーバーには該当するCGIが存在しないため、ステータスコード404
         Not Foundとなり、攻撃は失敗しています。

  まとめ:

  いくつかの攻撃的なスキャンが確認できましたが、いずれもサーバーのセキュリティ設定によって防がれており、現時点で直接的な被害には至っていません。

  特に危険なのはコマンドインジェクションを試みた **.***.**.*** です。このような攻撃は常に発生する可能性があるため、引き続き注意が必要です。

  必要であれば、これらの不審なIPアドレスからのアクセスをファイアウォールで拒否することも可能です。

サーバへの侵入試行を自然言語で調査

「サーバへの侵入攻撃があったか調べて」と依頼すると、WordPressコアファイルの改ざんチェック、管理者ユーザーの確認、不審ファイル検出、ログイン履歴確認を順番に実行。結果、侵入の痕跡は見つからず、全ての攻撃は防御されていることが確認できました。

✦ 承知しました。サーバーへの侵入の形跡がないか、いくつかの観点から調査します。

  これまでの調査では、攻撃の試みはありましたが、いずれも失敗しているように見えました。より詳しく、以下の手順で侵入の痕跡がないか確認していきます。

   1. WordPressコアファイルの改ざんチェック: WordPressの公式ファイルと現在のファイルを比較し、改ざんがないか確認します。
   2. WordPressの管理者ユーザーの確認: 不審な管理者アカウントが追加されていないか確認します。
   3. 最近変更されたファイルの確認: Webサイトのディレクトリ内で、直近に作成または変更されたファイルがないか探します。
   4. システムへのログイン履歴の確認: 身に覚えのないログイン成功履歴がないか確認します。

（中略）

総合的な結論:

  これまでの調査結果を総合すると、以下のようになります。

   1. WordPressコアファイル: KUSANAGIによるセキュリティ設定（Basic認証）が追加されている以外、改ざんの痕跡は見つかりませんでした。
   2. 管理者ユーザー: 不審な管理者は追加されていませんでした。
   3. 不審なファイル: Webサイト内に最近変更された不審なファイルは見つかりませんでした。
   4. ログイン履歴: ご自身のIPアドレス以外からのログイン履歴は見つかりませんでした。

  以上のことから、サーバーへ侵入された明確な痕跡は見つかりませんでした。

  アクセスログには攻撃の試みがありましたが、それらはすべてサーバー側で防がれており、侵入には至っていないと考えられます。