DDos 攻撃とは何ですか? node SSR サービスは DDos 攻撃をどのように防止し、対処しますか?次の記事では、DDos 攻撃を理解し、ノード SSR サービスが DDos 攻撃を防止および処理する方法を紹介します。
DDos 攻撃の防止と対処は安定性構築の重要な部分であり、事前に防止しておかないと、攻撃を受けるとサービスが利用できない状態に陥ります。 、ビジネスに多大な損失をもたらす可能性があります
この記事はノード ssr サービスの観点に偏っています、フロントエンド開発の学生はこの側面にもっと注意を払う必要があります。 [関連チュートリアルの推奨事項: nodejs ビデオ チュートリアル ]
一般的な例を挙げると、当社の Web サイトは銀行にたとえられます。通常の状況では、銀行は同時に最大 100 人の業務を処理できます。通常は歩いて移動するだけで済みます。
# 突然、不正組織がみかじめ料を徴収しようとしたが、銀行がそれを拒否したため、不正組織は番号を入手するために 3,000 人、場合によっては 30,000 人もの人員を派遣しました。同時。番号を渡した後は、引き続き番号を受け取ります。その結果、サーバーが処理できなくなり、多数の通常の顧客が待機することになります。これは DDOS 攻撃です。短期間に大量のリクエストを開始し、サーバーのリソースを使い果たし、サーバーのリソースを使い果たすことができなくなります。通常のアクセスに応答するため、Web サイトのパフォーマンスが実際に低下します。 DDOS は攻撃ではなく、大きなクラスの攻撃の総称です。その種類は数十種類あり、常に新しい攻撃方法が考案されています。 Web サイト運営のあらゆる側面が攻撃の対象となる可能性があります。 1 つのリンクが壊れてプロセス全体が実行できない限り、サービスを麻痺させる目的は達成されます。 その中でも、最も一般的な攻撃の 1 つは cc 攻撃です。 CC 攻撃は Web ページをターゲットとしています。CC 攻撃自体は通常のリクエストです。Web サイト上の動的ページに対する通常のリクエストもデータベースとやり取りします。この「通常のリクエスト」が一定のレベルに達すると、サーバーは応答できなくなります。 、それによって崩壊します。baike.baidu.com/item/cc�%…
どうすれば防ぐことができますか?
ビジネス サービス クラスターサービス リンクの最下位層とコア資産、上位層の完全な保護は非常に重要です
外層で悪意のあるトラフィックを遮断した後は、ビジネス クラスタは頻繁な運用とメンテナンスを必要としません ( (容量の拡張と縮小、フローの制限など)、運用と保守のコストを削減します。
ビジネス クラスターは、トラフィックを攻撃するために大量の追加リソースを準備する必要がなく、コストを節約できます。CDN レイヤーへのアクセス
CDN の保護機能には、CDN キャッシュ、ロボット検出、IP レピュテーション データベース、カスタム保護ルール セットの構築 (過去の攻撃と組み合わせたもの) が含まれます。機能やビジネスフォーム)など(有料レベルで有効)
別の余談(個人的な意見)ですが、CDN ベンダーは世界中に無数のサーバーを所有しており、大手 CDN ベンダーはほぼすべてのサーバーに対抗できます。また、保護レベルに応じた料金(保護料)も発生します。個人的には、一部の攻撃はCDNベンダーと違法業者が結託して発生しているのではないかと考えています。不正業者がみかじめ料を請求しているのと同じです。みかじめ料を支払わない場合は、痛みを知らせるために店舗を潰します(攻撃)。 、CDN 保護サービスを購入します。また、数千万以上の QPS を有効にすることができますが、(多くのサーバーを所有する) CDN メーカーを除いて、一般の人には難しいはずです。
これら 2 つについて一緒に説明しますが、これも偏っています。メンテナンス レベルは企業レベルのインフラストラクチャであり、特定のアクセス方法と特定の構成は企業ごとに異なります。ここでは詳細には触れません
nginxの電流制限とは何ですか?
WAF ファイアウォールとは何ですか?
WAF レイヤーを要約すると、次のようになります。悪意のあるスキャナー、IP、サイバーホースなどの脅威を検出および傍受するための豊富なレピュテーション データベースをセットアップします。
包括的な攻撃保護: SQL インジェクション、XSS クロスをサポートします。サイト スクリプティング、ファイル インクルード、ディレクトリ トラバーサル、機密ファイル アクセス、コマンド/コード インジェクション、Web トロイの木馬のアップロード、サードパーティの脆弱性攻撃などの脅威を検出および傍受します。
ここには保護層の種類がたくさんありますので、興味があれば詳細をご覧ください
#5. 起点局の処理能力を向上させる ##鉄を鍛えるには自分の努力が必要提案 1: ssr サービスはルート HTML の戻りのみを処理し、他のすべてのリソースは CDN に配置する必要があります
ssr サービスの場合、提案を行うことが非常に重要です。
こちら juejin を例にするとわかりやすいですが、下の図を見ると juejin 自体も SSR であることがわかります元のサイトはルート HTML のみを処理し、他のすべてのリソース (js、css、画像、フォントなど) は CDN に配置されます。
これの目的は、発信元サイトの処理能力を向上させることでもあります## 提案 2: 攻撃が来た場合、SSR を一時的に CSR にダウングレードする
#SSR レンダリングは CPU 負荷が高くなります (生成するにはコンパイルと解析が必要です) HTML) であるため、ssr サービスの QPS 能力は高くありません。攻撃を受けると簡単に負けてしまいます。
解決策: SSR を一時的に CSR にダウングレードしますCSR (クライアント側レンダリング) にダウングレードすると、サーバー側で複雑な HTML を生成する必要がなく、単純な HTML を返すだけで済みます。
CSR はシングルページ アプリケーションです。最も単純な例は UI コンポーネント ライブラリです。下の図でわかるように、この HTML は非常にシンプルで静的です。この静的 HTML を返すことはサーバー リソースをあまり消費しません.
SSR ダウングレードを実現する方法については、後の記事で書きます。
たとえば、小規模なトラフィック攻撃にしか抵抗できない弾性拡張および収縮機能がある可能性があります。
これは少し企業秘密に関係します...あえて書きませんが、興味のある友人は自分で検索してください。 、または会社の運用と保守について尋ねてください
とにかく、私が推測したことが 1 つあります。一般に、CDN にお金を支払った後は、その後攻撃が行われることはありません。たとえあったとしても、トラフィックが少なく、保護が簡単な攻撃のみである可能性があります。
ssr サービスでは、通常のアクセス時に CDN キャッシュがオンになっていない場合、攻撃を受けたときに一時的に CDN キャッシュをオンにすることができます。
予防策は早ければ早いほど効果的です。攻撃を受けてから始めないでください。
やるべきことをやり、やるべきことに答えた場合にのみ、実際の作業時に構成を操作する余地が得られます。そうでなければ、早く攻撃してくれるように神に祈るしかありません。やめてください... さもなければ、脅迫を受動的に受け入れることしかできません
安全は簡単な問題ではありません、世界が平和でありますように
ノード関連の知識については、nodejs チュートリアル をご覧ください。
以上がDDos攻撃とは何ですか?ノード SSR サービスは攻撃をどのように防止し、処理しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。