クリスマスに喰らった広域IPからのDDoSを排除した話。そこでの「友軍相撃(Friendly Fire)」をやらかしたという失敗談です。
事前背景
- クリスマスに自分のWebサイトを狙ったDDoSを喰らいました。
- そのとき、ipsetで /8という超高域ブロックを実施。
このときのメモはこちらにまとめています。
その結果 何が起きたか（事象）
- s3fsの不調: Wasabi（東京リージョン）のバケットがマウントされず、
df -hコマンドが数分間フリーズ（Dステート一歩手前の待機状態）。 - Nextcloudの孤立: 管理画面に「このサーバーにはインターネット接続がありません」と警告が表示され、アプリストアやアップデートチェックなどの外部通信がすべて遮断された。
- システム負荷: 通信のタイムアウト待ちにより、VFS（仮想ファイルシステム）レイヤーでプロセスが滞留しました。
2. 原因切り分け（診断）
調査の結果、ネットワーク層およびカーネル層での遮断を確認しました。
エンドポイント疎通確認:
curl -v を実行した際、特定のIP帯域（103.151.x.x 等）へのTCPハンドシェイクが Trying... のまま進まず、タイムアウトすることを確認。
この時点で、「ああ、超・広範囲のブロックが徒になったか」と実感です。
ブロックルールの特定:
ipset list コマンドにより、自作の防御システム『ONE OUTS』で使用している ufw-blocklist に、以下の広域ブロックが登録されていることを突き止めました。
103.0.0.0/8（Wasabi東京リージョンを含むアジア圏の広大な帯域）85.0.0.0/8（Nextcloud公式サーバーを含む欧州圏の広大な帯域）
結論: 昨年末のDDoS攻撃を鎮圧するために設定した「第1オクテット（/8）単位のブロック」が、正常な業務通信を巻き添えにする（Friendly Fire）結果を引きおこしたのです。
3. 対処（ufw-blocklistの解除）
干渉していた巨大なブロックエントリを ipset から削除し、通信路を復旧させました。
- Wasabi (Tokyo) への疎通を確保
sudo ipset del ufw-blocklist 103.0.0.0/8- Nextcloud 公式サーバーへの疎通を確保
sudo ipset del ufw-blocklist 85.0.0.0/8- 設定の永続化
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.saveこの状態では、まだs3fsプロセスが固まっていますので、これも対処。
- 念のためs3fsプロセスを強制終了。
sudo killall -9 s3fs- 固まっていたマウントを解除。
sudo fusermount -u -z /mnt/wasabi2- fstabに基づく再マウント
sudo mount -a4. 復旧確認（検証）
各サービスが正常なステータスに戻ったことを確認しました。
通信確認:
curl -I https://s3.ap-northeast-1.wasabisys.com で 303 See Other が即座に返ることを確認。
マウント確認:
df -h が遅延なく応答し、Wasabiバケットの容量が表示されることを確認。
Nextcloud確認:
管理画面の「インターネット接続なし」の警告が消え、外部連携機能が復旧したことを確認。
なぜ気づくのが遅れたか？
「このマウントはバックアップのため、普段めったに触れなかった」に尽きます。
今回、バックアップをいじるようになってからようやく気づいた次第です。これに関しては反省。
「使ってなければそれは見えていないのと同じ」というバイアスでした。
今回の教訓
これは、対象のIPアドレスをシャットアウトする「慈悲なき王」です。
を身を以て体感しました。なので、これを振るう時は更に注意する必要がありました。
それにしても、「自分だけが使うサーバのため、被害が自分だけで済んで良かった」と改めて思った次第です。こちらの記事にて
「『いい鉄砲は打ち手を選ぶ』ってことわざ知ってるか？
威力のある鉄砲は その分扱いも難しく危険
だから未熟者が使うと打ち手の方がケガをするってことさ」が自分へ向かうことのないよう、日々、管理/監視を怠らないようにする必要があると知った出来事でした。
が、まさに自分に向かっていったというお話しで、本件を締めます。