背景#
10 日の夜 11 時頃、多くの人々がバックエンドの再初期化が必要であることに気付きました。Mongo データベースはクリアされ、身代金の手紙だけが残されました。他のメンバー、私も含めてすぐに調査しましたが、私も被害に遭いました。そのため、Innei はセキュリティ警告を特別に発行しました。
身代金の手紙の元のテキスト：（From wibus
私たちはすべてのデータベースを削除し、サーバーにコピーをダウンロードしました。回復の唯一の方法は、0.01 BTC を bc1qmaacz9fdvnkujqlf8m547mzzh0l5t0ajn699th に送金することです。支払い期限は 48 時間です。支払いが完了したら、incomings99112@onionmail.comにコード：xxxxxx をメールしてください。データベースを回復します。詳細については、https://paste.sh/UY6_vtGL#THGqRdL9oQqUc-28RPDOWSbBをご覧ください。
もちろん、mx-space は優れた CMS システムであり、自動バックアップ機能が付属しています。毎日午前 1 時に当日のデータが自動的にバックアップされます。そのため、私は直接ファイル管理にアクセスして当日のバックアップファイルと近日のバックアップファイルをダウンロードしました。これにより、復元が容易になり、また、ファイルをグループで共有し、グループ内の意見を確認することができます。
分析#
間違いなく、ハッキングされたということは脆弱性があることを意味します。蠅は継ぎ目のない卵には止まりませんからね。グループ内のいくつかのユーザー（私を含む）が報告したように、削除されたデータベースには共通点があります：サービスプロバイダー / VPS のファイアウォールがない、Mongo コンテナがマッピングポートを開き、デフォルトで 0.0.0.0 にマッピングされている（つまり、パブリックネットワークから直接アクセス可能）、データベースに認証メカニズムがないため、攻撃されました。
解決策と今後の対策#
不要なマッピングを無効にする#
最初のセキュリティ警告で Innei は不要なマッピングを無効にすることを提案しました。
以前のバージョンの Docker Compose ファイルでは、mongo と Redis それぞれにポートマッピングがありましたが、IP が指定されていないため、Docker のデフォルト動作により、それらは直接 0.0.0.0 にマッピングされ、つまり公開されます。実際には、mongo と Redis はメインコンテナと同じネットワークにあるため、接続に問題はありませんので、ポートマッピングを完全に削除することができます。以下はポートマッピングを削除した後の一部の内容です。
mongo:
container_name: mongo
image: mongo
volumes:
- ./data/db:/data/db
networks:
- app-network
restart: always
redis:
image: redis
container_name: redis
networks:
- app-network
restart: always
networks:
app-network:
driver: bridge
ファイアウォールの設定#
次に、この問題はポートの公開によって引き起こされたものであることを考慮して、サーバーに UFW をインストールしてポートをブロックしました。もちろん、インストール後にサーバーの SSH ポートと 1Panel ポートを許可してからファイアウォールを起動する必要があります。そうしないと、サーバーに接続できない / パネルにアクセスできない場合があります（
sudo apt update
sudo apt install ufw
sudo ufw allow 22/tcp # SSHが標準ポート以外で実行されている場合、上記のコマンドの22ポートを該当するSSHポートに置き換える必要があります。
sudo ufw allow 8090/tcp # 1Panelシステムのポートを開放し、8090をパネルのポートに変更します
sudo ufw enable # UFWを起動します！
1Panel には、対応するファイアウォール機能もあります。UFW を起動した後、パネルで UFW を管理できます。非常に便利です。
コンテナの権限を低下させる#
timoの提案と指導に感謝します。操作は非常に簡単ですが、私は Linux について十分に理解していないので、調べてコマンドを見つけました（
まず、Compose の設定ファイルを直接変更し、user: nodeという行を追加します。以下は変更後の一部です（ファイルの抜粋）
version: '3.8'
services:
app:
container_name: mx-server
image: innei/mx-server:latest
command: bash ./docker-run.sh
environment:
- TZ=Asia/Shanghai
- NODE_ENV=production
- ALLOWED_ORIGINS
- JWT_SECRET
- ENCRYPT_KEY
- ENCRYPT_ENABLE
volumes:
- ./data/mx-space:/root/.mx-space
ports:
- '2333:2333'
depends_on:
- mongo
- redis
links:
- mongo
- redis
networks:
- app-network
restart: always
user: node
healthcheck:
test:
[
'CMD',
'curl',
'-f',
'http://127.0.0.1:2333/api/v2/ping'
]
interval: 1m30s
timeout: 30s
retries: 5
start_period: 30s
この制約を追加すると、コンテナ内で node ユーザー（UID 1000）でコマンドが実行されるようになります。また、ホストマシンのプロセスも UID 1000（システムに UID 1000 のユーザーが存在しない場合があります）を使用して実行されるため、デフォルトの root ではなくなり、セキュリティリスクも少なくなります。
ただし、コンテナは UID 1000 で実行されるため、コンテナ内のデータは/home/node/に配置されますが、データフォルダの所有権はまだ root にあります。したがって、コンテナの設定ファイルと対応するホストマシンのマッピングフォルダの所有権も同時に変更する必要があります。これらはすべて Linux の基本的な操作ですが、コマンドラインを使用しない場合は、パネルのファイル管理で直接変更できますので、追加の説明は不要です。