Misskeyサーバー「ぬくもりすきー」での情報漏洩について

【利用者の皆様へのお願い】 この事態を受けて、以下の対応を強くお願いいたします:

  • パスワードの変更
  • 二段階認証の有効化
  • 他サービスで同じパスワードを使用している場合は、そちらも変更

ご不明な点やご心配な点がございましたら、この記事のコメント欄やX・Misskeyのアカウントまでお問い合わせください。

2025年11月27日に発生したMisskeyサーバー「ぬくもりすきー」での情報漏洩についての詳細と原因と経緯をまとめました。
最初に漏洩したと考えられる範囲はデータベース内の利用者約500名のアカウントやパスワードといった情報の流出が確認できました。

応急処置として管理側で問題となった設定ファイルやデータベースのアクセス制限を強化し、各利用者様にはパスワードの変更と2段階認証を付けるようにお願いしました。
原因としてこのようなミスがなぜ起きたのかとまとめますと「バラバラに運用していたブログとMisskeyのサーバー代金を節約する目的で1つにまとめようと十分な検証や相談を行わずに実行した結果この失敗が発生した」からです。

まずサーバー代金の節約についてですがMisskeyのサーバー代金は月に18.77ドル、ブログの方のサーバー代金は年に50ドルで1年間に大体275ドル(約42000円)を支払っており、これを年に145ドル(約22000円)のサーバーに1つにまとめる事によって、1年で2万円の資金の余裕ができると考えた事がこの失敗の発端でした。

そして借りたサーバーは2つのサーバーよりも高性能なサーバーで、片方のサービスに大きな負荷がかかってももう片方のサービスのリソースに余裕があればそこからリソースを分けてもらって負荷を緩和できると考えたのも理由の1つで、また過去にサーバーのデータベースの移行作業を行っていたのもあり、ブログという他のサービスを同居させるのは初めてだが今回も上手くいくだろうとたかを括っていた事も原因でした。

次に問題となったサーバーの構成について説明します。
Misskeyとブログを1つのサーバーにまとめるにあたってリバースプロキシという、サーバー内部へのアクセスの振り分けやセキュリティの強化といった機能があるものを使い、適切にブログとMisskeyへのアクセスを振り分けようと考えました。

その際に使ったのはNginx Proxy Manager(NPM)という、GUIから設定できるリバースプロキシを使ってアクセスを振り分けようとしましたが、ここで設定を誤って(外部からサーバーのIP:各Webサービスに対応するポート)でアクセスできるようにしてしまい、設定ファイルが外部から読み込めるようになっていました。

Apacheはサーバーのコントロールパネルに付属していたものであり、ここを下手にいじるのは良くないし、これなら簡単に設定できるだろうと安易に考えてDockerでNPMをインストールしましたが、詳細な設定を行うのが難しくてアクセスを適切に振り分けられなかった上、ブログへのアクセスがNPM→Apacheとリバースプロキシの機能が重複していたりと煩雑でセキュリティホールが生まれやすい環境になってしまっていました。

調べ直してみるとコントロールパネルに付属していたApacheもしくはnginxでもCUIでファイルを作成し、適切に設定すればそれがリバースプロキシとして安全に機能するという事が判明しました。

Apacheかnginx単体で済ませた構成にするべきでしたし、そもそもいきなりサーバーを移転して設定するのではなく、練習用の環境を構築して入念なテストを行う・専門家や利用者であるぬくもりすきーの方々に相談と報告をして、合意や助言を得る所から始めないといけませんでした。
本来テストが必要な状況下において、テスト無しで構成変更を行ったために重大なセキュリティインシデントが発生しました。

また設定ファイルからデータベース(PostgreSQL)のパスワードが読み取れたとしてもデータベースに入れなければ無意味なのですが、恐らくバックアップのデータベースの復元作業中に一時的に外部からのアクセスができる状態になっており、そのタイミングで侵入されたと推測しています。
不具合を防ぐ為に「postgresql.conf」という設定ファイルを触らずデフォルトのままにしていましたが、PostgreSQLのデフォルト設定では「listen_addresses = ‘localhost’」でサーバー内のみにデータベースを公開する設定がコメントアウトで設定が無効化されており、恐らくそれによって全世界にデータベースを公開してしまい、外部からの侵入を許した原因の1つになっていました。
訂正:デフォルトではlocalhostのみの公開になっているとご指摘により判明しました。他の原因ではないか調査中です。

19.3. Connections and Authentication
19.3.Connections and Authentication # 19.3.1. Connection Settings 19.3.2. TCP Settings 19.3.3. Authentication 19.3.4. SS...
Access Denied - Error Page

最後に先程も言及したのですが私自身の根本的な問題として、他の人々とろくに話をせずに重要な事を勝手に決めてしまった事に尽きます。
「専門家や利用者であるぬくもりすきーの方々」と今回のサーバー移転のような大事な話ができる信頼関係の構築を怠った事で私自身の暴走した行動の歯止めができず、思いつきのままに行動した末に今回の情報漏洩に繋がってしまいました。

最終的に決断して行動するのは私自身ですが、正しくそれらを行うにあたっての準備というか、大事な人々との繋がりを軽視し話をする事が圧倒的に不足しておりました。
この件につきましては他のMisskeyの各管理者様への報告とセキュリティの見直しを行い、外部からの不正なアクセスを防ぐようにしました。具体的には

【既に実施した対策】

  • Nginx Proxy Managerを削除し、Caddyを利用して適切な設定に変更
  • PostgreSQLの設定を修正(listen_addresses = ‘localhost’を有効化)
  • 全てのポートのファイアウォール設定を見直し
  • 設定ファイルの権限を適切に制限
  • 他のMisskey管理者様へコミュニティ内で正式なレポートを作成と報告と情報共有

今後他でこのような事の再発防止策としては専門家や利用者への助言や合意の獲得、事前に練習環境を作ってテストを行うべきである事を他のMisskeyサーバーの管理人様らに注意喚起しました。

これらの原因が積み重なり、ぬくもりすきーのデータの情報漏洩に繋がってしまった事を深くお詫び申し上げます。

コメント

タイトルとURLをコピーしました