先日、海外のRedditで興味深い投稿が話題になりました。
Claude Codeを使っていた時のことです。
SSH経由でLinuxサーバーを操作していたところ、AIが異常なCPU使用率を検知しました。
調査の結果、サーバーが暗号通貨マイニングに悪用されていたことが判明したのです。
この投稿では、活発な議論が展開されました。
本記事では、このエピソードから得られるセキュリティの教訓について考察します。
投稿の概要
投稿者によると、事の経緯は以下のようなものでした。
Webサイトのバックエンドとして、Linuxサーバーを使用していました。
普段通りにClaude Codeで作業していたところ、突然、Claudeが異常なCPU使用率について言及。
調査を進めると、あるLinuxサービスが大量のCPUを消費していました。
さらに掘り下げた結果、原因が判明。
ハッカーがサーバーで暗号通貨をマイニングしていたのです。
侵入経路も特定されました。
データベース用のポートを閉じ忘れていたのです。
幸い、まだユーザーは存在しない段階でした。
最終的に、Claudeが問題を修正。
危険なポートを閉じ、ハッカーを排除したとのことです。
コミュニティの反応：懐疑的な声が多数
この投稿に対して、多くのユーザーが懐疑的でした。
あるユーザーは「完全にナンセンス」とコメント。
別のユーザーも疑問を呈しています。
「Claudeが自発的にCPU使用率を検知した？ハッキングと診断した？すべて自力で修正した？信じがたい」と。
投稿の真偽よりも、批判が集まったのは別の点でした。
データベースポートをインターネットに公開していたこと。
AIにサーバーへの完全なSSHアクセスを与えていたこと。
これらが根本的な問題だという意見が大半を占めたのです。
最も重要な警告：サーバーは依然として侵害されている
このスレッドで最も支持を集めたアドバイスがあります。
その『修正』は無意味です。 マシンは依然として侵害されています。 完全にワイプしてください。 ゼロから再構築する必要があります。
これは非常に重要な指摘でした。
侵入スクリプトにはバックドアが含まれていることが多いのです。
再起動時に自動的に有効化されるケースもあります。
ポートを閉じただけでは不十分。
悪意のあるプログラムは除去されません。
同様の経験をしたユーザーからも証言がありました。
私も同じ問題に遭いました。サーバーを新しく作り直した。 バックアップから復元を始めた。 すると、新しいサーバーにも感染してしまった。 3回目でようやくロックダウンして、クリーンな状態を保てるようになりました。
侵入経路の可能性
コメント欄では、侵入経路についても議論が行われました。
投稿者はデータベースポートの開放が原因と述べていました。
しかし、多くのユーザーが疑問を呈しています。
「ポートが開いているだけで、どうやってリモートコード実行まで？」という指摘です。
いくつかの可能性が挙げられました。
データベースにはファイルシステムと連携する機能があります。
これを悪用すれば、cronジョブの作成やSSHキーの追加が可能です。
MS SQL Serverなら、シェルコマンドを直接実行できます。
また、React/Next.jsの重大なCVE（React2Shell）も候補に挙がりました。
投稿時期と重なっていたのです。
この脆弱性により、多くのサーバーが危険な状態になりました。
rootとしてコマンド実行される状態です。
あるユーザーはこうコメントしています。
npmの脆弱性か？ ReactのCVEか？ Next.jsとReactを使っている人は皆やられた。 アプリがrootで動いていたら終わりだ。
同様の経験を報告するユーザーたち
興味深いことに、類似の経験を報告するユーザーも複数現れました。
私にも同じことが起きた。 Kinsingというマルウェアだった。 悪意のある.shファイルと.pwnedファイルを発見した。 原因はおそらくDockerかPostgresの設定だと思う。
Redisサーバーの設定ミスで同じ経験をした。 Claudeがcronジョブを大量に発見した。 中国のIPアドレスからのボットだった。
ホスティング会社から高負荷の通知を受けた。 Sonnetがクリプトマイナーを見つけた。 削除してシステムを堅牢化してくれた。 ただ、Node.jsのアップグレードまではしてくれなかった。 古い脆弱なバージョンのままだった。 そのため、数時間後にマイナーが戻ってきた。
AIにサーバーアクセスを与えることへの懸念
AIへの権限付与についても、懸念が表明されました。
Claude Codeにサーバーへの完全なアクセス権を与えている。 この事実が、ハッカーがいる理由を説明している。 セキュリティプラクティスの完全な無視だ。
このコメントは多くの支持を集めました。
投稿者は反論しています。
「私はバイブコーダーなんだ。失敗から学ぶタイプだから大目に見てくれ。」
しかし、厳しい意見が返ってきました。
「自分のものを壊すのはいい。でも、その結果として他の人のものが壊れるようでは困る。」
ユーモラスな反応
深刻な議論の一方で、ユーモアのあるコメントも多数ありました。
最も支持を集めたコメントはこちらです。
Claudeがハッカーを排除する前に、Spotifyを開いたか？ The Prodigyを爆音で流したか？ そうでないなら、Anthropicのトレーニングプロセスに疑問を呈する。
こんなジョークも人気でした。
プロットツイスト： 『ハッカー』は別のClaude Codeのインスタンスだった。 あなたの信頼を得るために自らを犠牲にしたのだ。 本当の侵害はこれからだ。
さらに皮肉なコメントも。「ヒーローはClaude。ハッカーもClaude。」
実践的なセキュリティの教訓
この事例から、いくつかの重要な教訓が得られます。
データベースはインターネットに直接公開しない
「DBはインターネットにさらすな。すべてDockerに入れろ。」
このアドバイスが示すように、内部ネットワーク接続のみを使うのが基本です。
侵害されたサーバーは完全に再構築する
ポートを閉じる。
マルウェアを削除する。
これだけでは不十分です。
バックドアが残っている可能性が高い。
クリーンインストールから始めるべきでしょう。
AIツールへの権限付与には慎重に
便利だからといって油断しない。
本番サーバーへの完全なアクセス権を与えるリスクを理解しておくべきです。
適切な監視ツールを使用する
Tripwireのようなファイル整合性監視ツールが有効です。
ログが改ざんされた場合でも侵入を検知できます。
最新の脆弱性情報に注意を払う
React2ShellのようなCVEは危険です。
発見から悪用までの時間が非常に短い。
パッケージの更新を怠らないようにしましょう。
まとめ
この話が完全に真実かどうかは分かりません。
しかし、議論から得られる教訓は貴重です。
AIコードアシスタントは強力なツールです。
しかし、セキュリティの基本を代替するものではありません。
基本を無視してAIに頼る。
これは新たなリスクを生み出します。
サーバー運用で大切なことは何か。
開いているポートの確認。
適切なファイアウォール設定。
定期的なセキュリティアップデート。
侵害時の適切な対応手順の理解。
これらが不可欠です。
AIに「修正してもらった」と安心してはいけません。
根本的な原因を理解する。
適切な対策を講じる。
それが、真のセキュリティ向上につながるでしょう。
