スイッチが入ることはない
ボタンはない。スクラビングは、小さい拠点では毎秒4テラビット、最大では12テラビットの帯域で全サイトの前面で常時稼働しており、パケットを落とす判断はエッジのハードウェアで受信時に行われる。したがって、攻撃の最初の30秒は最後の30秒とまったく同じようにフィルタリングされる。これは、攻撃を検知し、プレフィックスをリダイレクトし、アナウンスが伝播するのを待つ必要があるどのシステムにも当てはまらない。
内部から見えるもの
通常はまったく何もない。反射型UDP、SYNフラッド、増幅されたDNS応答のセット。どのような形状のボリューム攻撃も上流でドロップされ、ポートには到達しない。パネルのグラフにはそれが表示される。インターフェースのカウンタには表示されない。
届く可能性があるのは、実際のトラフィックと区別できないものだけだ。低速HTTPフラッド、最も高価なエンドポイントへのリクエストのストリーム、クレデンシャルスタッフィングの実行などだ。レイヤー7では、エッジはアプリケーションを知らなければ助けになれない。それがDDoS Proアドオンの存在理由だ。カスタムシグネチャ、パスごとのレート制限、そして発生中に一緒に作成してくれる担当者だ。
結論を出す前に自分の制限を確認する
私たちに報告される攻撃のおよそ半分は、通常の月曜日のトラフィックでconntrackテーブルが満杯になるか、listenキューがあふれているだけだ。
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50nf_conntrack: table full, dropping packet カーネルログの は、ファイアウォールが自分自身について話しているのであって、ネットワークが攻撃を報告しているわけではない。
私たちが行うこと
検知はフローベースで宛先ごとに行われる。シグネチャが一致すると、一致するトラフィックは数秒以内にドロップされ、それ以外のトラフィックはそのまま残る。サイトが吸収できる量を超えるボリュームが発生した場合（これはまれで、発生したこともある）、宛先アドレスは、サイト上の全員の劣化を許す代わりに、指定されたウィンドウ全体で一括フィルタリングされる。ウィンドウを指定したメールが届き、その時間は分単位で測定される。
攻撃トラフィックはフェアユースに対してカウントされない。それはあなたのトラフィックではなく、あなたが要求したものでもない。
後でお伝えできること
ベクトル、ピークビットレート、ピークパケットレート、持続時間、送信元のおおよその地理。それがフローカウンタが保持するものだ。
引き渡せないものはパケットキャプチャだ。そもそも存在しないからだ。インスタンスを通過するトラフィックは記録しておらず、そのポリシーには、トラフィックが敵対的になったときに自動的に有効になる例外はない。詳細はログに記録するものに記載されている。インシデントの最中にこれを不満に思う人もたまにいるが、それは残りのポリシーに価値をもたらすのと同じ性質だ。
やるべきでないこと
- アドレスを変更しないこと。攻撃は1分以内に追従し、今度はDNSもおかしくなる。
- 再起動しないこと。再起動中のインスタンスは遅くなるだけで、フィルタリングされない。
- パニックになって千行のnftablesルールセットを貼り付けないこと。インスタンスでドロップするものはすべて、すでにネットワークの高価な部分を通過している。
- 最初に/statusを確認すること。サイト自体にインシデントがある場合、それはチケットが書かれる前にそこに公開される。
それでもチケットを開く
インスタンスID、タイムゾーン付きのタイムスタンプ、実際の症状、サービスがセカンダリネットワークから到達可能だったかどうか。中央値の初回応答は、1日24時間どの時間帯でも11分で、ライブイベント中は、すでにグラフを見ている担当者から返信が来る。