私のプロジェクトはしばしばDDOSによって拷問されたため、DDOS攻撃に対する保護を無料で提供するHighLoad Labに転送することが決定されました。
すべてがすばらしかった、彼らは自分たちを通して私たちのサーバーにトラフィックをプロキシした。 サーバーでは、HighLoadを除くすべての着信IPアドレスがブロックされました。
問題
しかし、11月13日から14日の夜に、サーバーの速度が大幅に低下し始めました。理由はわかりませんでした。負荷がなく、iptablesは何も受け入れませんでしたが、sshで作業していてもブレーキは顕著でした。
午後、サーバーがクラッシュしました。 私はまだ理由を知りませんでした、そして、私に最初に起こったのは、長い間更新されていなかった古いslackwarカーネルでした。 クラスノゴルスク、Rednetのオフィスに行き、システムを新しいDebianに再配置することが決定されましたが、すべてが私が計画したものとはかけ離れていました...
理由
考えられる理由を考えているうちに、電話が鳴った。 通信中には、 krasnogorsk.ruの最高管理者がいました 。 彼は、保護および洗浄システムがオフになったときに、機器の交換中に発生したDDOS攻撃が原因で事故が発生したと述べました。
私たちのサーバーはホームプロバイダーに配置されていたため、主にクライアントトラフィックが影響を受けました（通常のインターネットユーザー）
この攻撃は、COMCORバックボーンで検出され、IPアドレスを切断しました。 ピーク時に、攻撃は300 Mbpsに達しました。
HighLoadフィルターが保存されなかったのはなぜですか？
攻撃者は私たちの古いIPアドレスを知っていて、トラフィック浄化システムをバイパスして攻撃を特別に実行しました。当然、すべてのブロックモードのiptablesは役に立ちません。
まとめ
これでサーバーは誰にも知らないIPに転送され、トラフィックはHighLoad Labを通過し、Gmailを介してWebサーバーメールを構成し、リンクからアバターをダウンロードするためにすべての送信接続を切断しました。
これで、スキームは次のようになります。
ユーザーリクエスト->サーバーの外部IPアンチDoS->トラフィッククリーニングシステム-> nginx->クリーニングされたトラフィックはサーバーに送られます-> nginx-> apache->同じチェーンに沿ってユーザーに戻ります。 最も重要なことは、攻撃者にWebサーバーの実際のIPアドレスを焼き付けないことです。
設計と編集の支援 ： as3k