自分のプライベートネットワークで動かしてるんだけど、かわいいからね。おもちゃみたいなCのユーティリティを書いて、Dockerに対応させたから、Proxmoxにポンと投げられるようにしたんだ。https://github.com/jkingsman/RFC865-QotD-Server-for-Docker

記事によると、攻撃は45秒だったみたい。昔、かなり有名なウェブサイトを運営してたけど、90秒の攻撃がよく来てたんだ。推測するに、DDoSサービスの中には短い攻撃を無料サンプルとして提供するのがあって、私たちが有名だったから狙われたんだと思う。ありがたいことに、ほとんどの場合、攻撃は私たちのサービスじゃなくてウェブサイトに向けられたから、ウェブサイトの可用性はあまり重要じゃなかった。大抵の攻撃は大したことなくて、すぐに飽きて他に移っていった。ウェブサーバーを落とす攻撃はちょっと嬉しかったけど…それを使ってウェブサーバーと実際に仕事をしてるサーバーの調整ができたからね。

プロバイダーが誰かはわからないけど、攻撃はほぼ確実にプロバイダーを狙ってたんじゃなくて、彼らのプラットフォーム上にホストされているサイトを狙ってたと思う。多くのホスティング会社は、顧客にCloudflareのDDoS防止を提供するようなものをアップセルしてるんだ。狙われたサイトはおそらく政治的か物議を醸すようなものだったんじゃないかな。私はホスティングプロバイダーで働いてて、こういうことには常に対処してるよ。

100%の解決策ではないけど、ISPがやったら大いに助かることがあるよね：1) 偽のソースアドレスを防ぐために出口フィルタリングを行うこと 2) 大量の悪意のあるトラフィックを送信している顧客を一時的にシャットオフすること

どうやら、広まっている解決策はないし、どこでも機能する単一の解決策もないみたい。ソースアドレスフィルタリング（BCP 38）は部分的には効果があったけど、データセンターでやるのは難しいし望ましくない。ここで使われると推測されるIoTデバイスには、上流で解決策が必要だね。MUD（RFC 8520）みたいなものが提案されてるけど、問題もある - 開発者は自分のデバイスのすべての通信をリストアップして、それを何らかの形で提供できる必要がある（MUDプロファイルサーバー）。消費者の中には、自分からは絶対にやらない人もいるし、デバイスメーカーに自分がデバイスを持っていることを知らせたくない人もいる（つながった大人のおもちゃとか考えてみて…）。それに、IoTデバイスはオーナーによって更新されないことが多いから、何年もIoTボットネットのDoS攻撃が続くと思っておいた方がいいよ。

カパチャス？最悪で嫌われる解決策かもしれないけど、一応言っとこうと思って。もしかしたら、失敗したカパチャが多すぎると、1時間くらいIPに接続できなくなるかもね。

トラフィックごとにお金を取るようにすればいいんじゃない？

消費者向けの家庭やオフィス用ルーターは、クライアントにIP接続を無制限で提供してるけど、なんでそうなってるんだろう？デフォルトでは、利用可能な帯域幅を全部使えるようになってるはずだし、ISPから消費者へのサービス（たぶん有料）もそうだと思うけど、なんで消費者ルーターのIoTでそれがデフォルトなの？プリンターが500Mbpsの送信速度を必要とする理由って何？それとも、私の高級な歯ブラシとか？

脆弱性のあるIoTデバイスを特定して壊す？

インターネットのユーザーや接続デバイスが増えるにつれて、DDoSのトラフィック量と単一接続のトラフィック量の比率はどんどん大きくなるよね。でも、それが本当にそうかはわからないな。大規模なDDoS攻撃の記録は増えてるけど、接続の帯域幅も増えてるし。7Tbpsはかなりのトラフィックだけど、1Gの対称接続を持つ7000台のノードがあれば達成できるんだよね。ボットネットのサイズもそんなに大きくなってない気がする。ボリュメトリックDDoSの基本的な解決策は、もっと大きなパイプを持つことなんだけど、これはある程度は効果があるけど、7Tbpsの下り容量を確保するのは難しいし、7Tbpsのリフレクターにならないように気をつけないといけない。もっとスケーラブルな方法は、BGPを使ってトラフィックが自分のところに来る前に落とすことだね。ホスティング施設やそのISP、あるいは自分のISPとの関係によっては、特定のIPへのパケットを自分のネットワークの一つ前で落とすのは結構簡単だよ。たまに、そのブロックが広がることもあるし、BGPフロースペックのようなものはもっと具体的なフィルタリングを約束してる… 攻撃されたIPへの全パケットを落とすことで、経路上の他のIPへの攻撃を軽減できるけど、攻撃されたIPへの全UDPを落とすと、攻撃トラフィックを全部受けてしまって、非攻撃トラフィックは通過させるかもしれない… DNSやHTTP/3を攻撃中に生き残らせたいなら、もっと具体的なルールも可能だよ。45秒の攻撃に対抗するためには、BGPベースの対策にはかなりの自動化が必要だね。

銀行はすでにパターン認識を通じて不正検出を見つけてるし、ISPも同じことができるよね。接続が1000/1000のリンクで300/10を超えたことがなくて、その80%がTCPのdstport 80か443だったら、すぐに全ての可能なdstportに900のUDPを送信し始めたら、何かおかしいんじゃない？「あなたのネットワークは異常な量のトラフィックを生成していて、ウイルスに感染したデバイスが原因と思われます。そのため、速度を100/20に制限しました。デバイスを確認して接続を解除する手順はこちらをお読みください: ____」

1Gbpsの光ファイバーインターネットが普及してる今、現代のPiボードや古いデスクトップでも1Gbpsのボットホストになり得るって考えるとすごいよね。

これはエイプリルフールのジョークじゃないよ。90年代のLinuxだと、これらのサービスがデフォルトで有効になってるかもしれない。ネットワークのデバッグをちょっとでも楽にするために作られたんだろうね。

それはMicrosoft Services for Unixの一部なの？私が攻撃を受けてたとき、チャージンリフレクターの主なソースだった気がするし、似たような感じだね。

へぇ、これ面白そうだね。ネット上にいくつかのQOTDサーバーが点在してるってアイデアが好きだな。でも、最初に聞いたのがDDoS攻撃に悪用されてるってことなのは残念だね。

サポートはあるよね。手間なくオンにできるかって言うと、そうじゃないかな。どうやってそんなに多くのアクティブなサービスを見つけたのか、ちょっと疑問だよ。正直、その小さな割合だと、誤分類の可能性が高いと思う。

しばらくQOTDサーバーを運営してたけど、実は2ヶ月前に引退したんだ。あんまり人気はなかったよ。

QOTDはTCPでも使えるから、UDPを使った時の問題を避けられるんだよね。

セキュリティの多くは、クライアントがあまり技術的じゃないから、賢く見せるために作り上げてるだけだよね。誰かがポート17でパケットを見て、ポート17を調べて、QOTDサービスが攻撃に関与してるって決めつけたんだろうね。たぶん。