収集したすべての証拠が特定のASからの送信元IPアドレスを持つパケットのフラッドである場合、間違った結論にジャンプしている可能性があります。より可能性の高い説明は、これらのソースIPがスプーフィングされていることです。
リフレクション/増幅攻撃には、被害者の送信元IPアドレスを偽装する大量のパケットの送信が含まれます。これが実際に起こっていることであり、ネットワーク内に攻撃を増幅できるサーバーがある場合、攻撃を非難しているネットワークは実際には被害者であり、攻撃者を支援しています。
このような状況では、ソリューションはトラフィックエンジニアリングを適用するのではなく、増幅攻撃で使用できないようにサーバーを構成することです。これを行う方法は、実際にはネットワークエンジニアリングの問題ではありません。
もちろん、すべてのパケットが1つのASから発信されている可能性があります。問題のあるASからの協力により、パケットが実際にASから発信されていることを確認できます。ただし、そのレベルの協力関係では、攻撃をソースでブロックすることもできます。
あなたが何らかの方法で、パケットが本当にあなたが考えるASから発信されている確認を得ることについて考えていないと仮定すると、ソースでブロックすることはできず、代わりにBGPの手段でブロックしたいこれを達成するための多少危険な方法について読んだことがあります。アイデアは、アナウンスするルートにASパスを追加することです。この付加されたASパスには、それらのパケットのソースのAS番号を含めます。
アナウンスが問題のASのBGPルーターに到達すると、ループを検出し、アナウンスをドロップします。一方、世界の他の地域ではループが発生せず、アナウンスを受け入れません。
それが理論です。実際に機能するかどうかは、いくつかの異なる要因に依存します。たとえば、パケットの発信元のAS番号を実際に使用することに依存します。これは、それらのIPアドレスを通知するAS番号とは異なる場合があります。(そのような違いは正当なものであるか、スプーフィングによるものです。)
ASパスが疑わしい場合、ルートをフィルタリングしないアップストリームにも依存します。さらに、あなたから遠く離れたネットワークも、たとえば、攻撃しているASで悪い経験があり、そこからすべてのルートをドロップすることを決定した場合、ルートをドロップする可能性があります。
このアプローチがリスクに見合うかどうかはあなたの意見です。
(再び見つけられるなら、私はこのアプローチのソースにリンクしていたでしょう。)