飼い猫がDDoS攻撃を知らせてくれた出来事
(dannyguo.com)- 正式なオンコールローテーションがなかった時期、午前3時に猫が眠っている人を起こしたおかげで、AWS CloudWatchアラートとWebサイト障害をすぐに確認できた
- ロードバランサーのunhealthy targetsアラートの後、サイトが開かなくなり、複数の国に関連する多数のIPから大量のリクエストが届いていた
- 製品は米国ユーザー向けにのみ提供されていたため、国際トラフィックは異常であり、状況からDDoS攻撃だった
- サーバーでIPを1つずつブロックする方法は非効率になり得たが、すでに設定済みのAWS WAFの国別ブロックルールにより、約1時間で数十万件のリクエストをブロックした
- 攻撃開始のころ、カスタマーサポートのメールボックスには、Apacheの脆弱性でサイトを停止させたとしてBitcoinで5,000ドルを要求する脅迫メールが届いており、会社は返信しなかった
午前3時に明らかになった障害
- 当時そのスタートアップには正式なオンコールローテーションがなく、チームで緊急通知を一緒に見守る形で運用していた
- 午前3時ごろ、猫が髪をグルーミングして眠りを覚まし、携帯電話を見ると数分前にAWS CloudWatchのアラートが届いていた
- アラートの原因はロードバランサーのunhealthy targetsで、Webサイトは実際に読み込まれなかった
- 監視ダッシュボードには、複数の国に関連する多数のIPアドレスから届く大量のリクエストが表示されていた
- 製品は米国ユーザー向けにのみ提供されていたため、国際トラフィックは普段と異なっており、状況からDDoS攻撃と判断された
AWS WAFで防いだリクエストの急増
- 最初に思い浮かんだ対応はサーバーレベルでIPアドレスをブロックすることだったが、攻撃者がより多くの送信元IPを使えるなら手間がかかり、効果も限定的になり得た
- すでに設定していたAWS Web Application Firewallを活用し、即時の障害対応用として他国からのリクエストをブロックするルールを追加した
- ルールが適用された後、約1時間で数十万件のリクエストがブロックされ、Webサイトは再び動作し始めた
- リクエストの急増も止まり、当面の障害は解消された
攻撃直後に届いた脅迫メール
- その日の朝、攻撃開始のころにカスタマーサポートのメールボックスに届いていたメールを確認した
- 送信者はWebサイトの脆弱性を見つけてApacheをクラッシュさせたと主張したが、会社はApacheを使用していなかった
- Webサイトのすべてのトラフィックを止め、数か月間維持できるとして、Bitcoinで5,000ドルを送れば「solution file」を渡すと要求した
- 会社は返信しなかった
- 携帯電話は夜間におやすみモードだったため、AWS通知の振動や音が猫を先に起こしたという説明は当てはまらなかった
- 当事者は、猫が朝まで待てない何かをどういうわけか察知したのだと考えており、PagerDutyアラームよりはるかに不快感の少ない起こされ方だったと見ている
1件のコメント
Hacker News のコメント
いつものことだが、内部者脅威は見落としやすい。文法が怪しい脅迫メール？ Bitcoin の身代金要求？ 実はその攻撃の黒幕が猫だった可能性は考えなかったのか？
Kansas には地震はあまりないが、私が初めて、そして唯一感じた地震はいまでも覚えている
熟睡していたら Siamese の猫が前足で私の顔をたたいて起こし、ベッドの端に座って普段と違って攻撃的にうなっていた
30秒もしないうちに揺れ始めた。どうやって分かったのかは分からないが、かなり驚いたし、2020年に旅立ってしまったけれど今でも恋しい
最近の NYC の地震でも、人が揺れを感じる前に犬たちが遠吠えする動画があり、かなりよくある現象だと思う
数週間前に Taipei でマグニチュード7.4の地震に遭ったとき、私が考えていたのは約束どおり犬のところへ戻らなければ、ということだけだった。出かける前に犬が不安そうにしていたのだが、私が出かけるのを察知したのか、私が向かっていた地震を感知したのかは分からない
岩石には P波とS波 という2種類の音がある。P波は圧力波なのでより速く、S波は左右に揺れながら少し遅い。猫は、人間が感じる地震より少し先に届くP波のシューッという音で目を覚ました可能性が高い
2種類の波があり、P波が先に到達することは https://manoa.hawaii.edu/exploringourfluidearth/physical/oce... で確認できる
携帯電話はサイレントだったが、画面は点滅し続けていたのかもしれない。私のものもそのモードではそう動作する
最初の職場には、監視ダッシュボードで障害が起きる前に察知する人がいた。本人も何を見ているのか説明も理解もできず、他の人も真似できなかったが、何かおかしいと言うと、たいていすぐにアラートが来た
ある建設現場の監督が、地中や壁の中の配管を異常にうまく見つけるので作業員たちに尊敬されていた、という文章を読んだことがある。最初は超能力だと信じ始めたが、後には典型的なパターンと、たまに見える直感に反する手がかりを無意識に学んでいたのだと結論づけたという。たとえば建物の壁にある通気口を見て、地下に下水管がある可能性に気づくといった具合だ
「このゲームはそろそろ落ちる、セーブしないと」とかなり正確に察知できるところまでいった。セーブして10秒後に再開すると実際にクラッシュしたのだが、いまだにどうやって分かったのか分からない
5,000ドルとは、なかなか王子様っぽい金額だね。2016年にうちの会社もそういう要求を受けた
DDoSを受け、無視することにしたが、念のため BTC は少し調べておいた。その後 DDoS 防御を山ほど適用するのに5,000ドルよりずっと多くかかったが、脅迫犯に金を払わないことにはそれだけの価値がある
私たちはどのメールにも返信しなかった。攻撃者たちもかなり間抜けで、接続の良い場所にあった Web サーバーだけを攻撃していた
実際に金を稼いでいるサービスは Caribbean にあり、1.5Mbps の T1 と 0.5Mbps の衛星バックアップしかなかった。そこならずっと簡単に、長時間飽和させられたし、そうなれば時間あたりの売上損失は約100万ドルだったはずだ
1人の攻撃者に5千ドル払うほうが防御の構築より安く見えるかもしれないが、防御を整えれば今後攻撃を受けにくくなる可能性が高い。そして言うとおり、犯罪者に金を払わないこと自体に価値がある
「返信はしなかったが、振り返るとからかってみるのも面白かったかもしれない」という部分については、無反応だけが唯一有効な返答だ
からかえば、かえって目立って別の攻撃の標的になる可能性がある。それで何が得られるのか？
それでも想像するのは面白かったし、とくに記事でリンクされていたこの動画を見てからはなおさらだった: https://www.youtube.com/watch?v=dWzz3NeDz3E
以前、家族の一人が食洗機から水が漏れているのを猫アラートのおかげで知った
結論としては、猫が助けようとしたのか、あるいは殺そうとしたのか、そのどちらかだった
屋外で寝ていた人がカラスの鳴き声で目を覚ますのだが、まさにそのとき大型ネコ科動物、おそらくトラがこっそり近づいていた
ある人物はカラスがその人に警告しようとしたのだと見なし、別の人物は、その鳥が食事の後の残りかすを食べようとして、眠っている人間のことをトラに知らせたのだと見なす
「ひどい文法」だなんて、ChatGPT以前の時代らしいね
もう少し真面目に言うと、DDoS攻撃を永遠に防ぐ方法はいつか出てくるのだろうか？ どんな脅威も悪いものだが、DDoSは最もつまらない攻撃タイプのように思える。特別な技術や知識は必要なく、スクリプトを走らせるか、そもそもサービスとして代行してくれる人に金を払えばいい
IPアドレス、IPv6ならサブネットは一般ユーザーにとって限られたリソースであり、帯域幅も同じ。ほとんどの増幅攻撃にはIPスプーフィングが必要だが、通常の接続では不可能な場合が多い
容量ベースの攻撃なら、より多くの帯域幅を持つ側が勝つ。攻撃者はここで増幅を使える。負荷ベース、またはアプリケーション層攻撃なら、ファイアウォールレベルで攻撃者IPをブロックすることで解決できる。この事例ではすでにWAF/Cloudfrontがあったので、純粋な容量攻撃ではなくアプリケーション層攻撃に近い
ブロックすべき攻撃者IPを見つける作業は、送信元IPごとのコストを正確に帰属させ、正当なユーザー活動という利益も送信元IPごとに正確に帰属させたうえで、コストが利益を大きく上回るIPや範囲をブロックする問題だ
言うほど簡単ではない。コストは、開いた接続がメモリを占有すること、TLSハンドシェイク、Webサーバーにとってパースが高コストなリクエスト、高コストなデータベースクエリを引き起こすリクエスト、入出力帯域幅など、さまざまな形で現れる。だから多くの場合はCloudflareや、ここでのようにCloudfrontを前段に置き、この事例のように手動ルールで回避する
プロトコル層でDDoSに強くする方法があれば素晴らしいが、それが可能なのかはよく分からない
そして容量ベースのDDoSがある。これは誰よりも多くの帯域幅を持てば防げるが、かなり難しく、自分自身が潜在的な攻撃者にもなってしまう
ここでの革新は、BGPでトラフィックフィルターを広める形だ。ヌルルーティングが最小機能製品に相当する。このIPが攻撃されているので、できるだけ早くそちら向けのトラフィックを捨てろ、という具合だ。もっと精密なシステムも見たことがあり、UDPを捨てる、フラグメント化されたパケットを捨てる、UDP/TCPの特定ポートの送受信パケットを捨てる、といった方式だった
こうしたシステムの多くは、特殊なルートが直接ピアの先へ伝播しないよう設計されているが、場合によっては伝播することが望ましいこともある
顧客の大半がメキシコにいて、カナダがDDoSを仕掛けてきて自分とカナダの間の回線が詰まったとしても、大きな問題ではないかもしれない。メキシコ側のコンシューマールーターたちが、そのカナダのボトルネックを助けようとしない限りは、という話だ
猫の給餌器を通知につないだのかと思った
いずれにせよかわいい。猫の名前は何だったの？
名前はBambooだった。残念ながら癌で亡くなった。引き取って最初にしたことの一つが、私の竹の鉢植えを食べようとしたことだったので、そう名付けた
無線の猫用給餌器がインターネットに依存していたのだが、餌が出てこなかったため、猫が管理者に抗議しに行った
この本を思い出した: Dogs that Know When their Owners are Coming Home https://www.sheldrake.org/books-by-rupert-sheldrake/dogs-tha...
トークンバケットでDDoSを防ぐのは簡単すぎて、普通、猫に起こしてもらう必要があるのは私のDiscordが襲撃されているときくらいだ
ファイアウォールやイングレス側で、アプリケーションサーバーに到達する前に過剰な負荷を生むパケットを捨てる方式に近いように見える
接続要求の量やユニークIPアドレス数が十分に大きい攻撃なら、依然としてサービスを過負荷にできる
トークンバケットは通常、全体的なレジリエンス戦略の一部であって、すべてのサービス拒否問題を解決する万能薬ではない