この記事は、「ネットワーク インフラストラクチャを制御する方法」シリーズの XNUMX 番目です。 シリーズのすべての記事の内容とリンクが見つかります。 ここで.

В 最初の部分 この章では、データ センター セグメントにおけるネットワーク セキュリティのいくつかの側面について説明しました。 この部分は「インターネット アクセス」セグメントに専念します。

インターネットアクセス

セキュリティのトピックは、間違いなく、データ ネットワークの世界で最も複雑なトピックの XNUMX つです。 これまでの例と同様に、深さと完全性を主張することはせずに、ここでは非常に単純ですが、私の意見では重要な質問と、その答えがネットワークのセキュリティのレベルを上げるのに役立つことを願っています。

このセグメントを監査するときは、次の点に注意してください。

• デザイン
• BGP設定
• DOS/DDOS 保護
• ファイアウォールでのトラフィックフィルタリング

デザイン

エンタープライズ ネットワークのこのセグメントの設計例として、次をお勧めします。 руководство シスコ内から 安全モデル.

もちろん、他のベンダーのソリューションの方が魅力的に見えるかもしれません (「」を参照)。 ガートナー クアドラント 2018）、この設計に詳しく従うことをお勧めするわけではありませんが、その背後にある原理と考え方を理解することは有益であると私は考えています。

注意：

SAFE では、「リモート アクセス」セグメントは「インターネット アクセス」セグメントの一部です。 ただし、この一連の記事では、それを個別に検討します。

このセグメントのエンタープライズ ネットワーク用の標準機器セットは次のとおりです。

• ボーダールーター
• ファイアウォール

備考1

この一連の記事でファイアウォールについて話すとき、私は次のことを意味します。 NGFW.

備考2

ここでは、L2/L1 接続を確保するために必要なさまざまな種類の L2/L3 またはオーバーレイ L1 over L2 ソリューションの考慮を省略し、L3 レベル以上の問題のみに限定します。 L1/L2 の問題については、「」の章で部分的に説明しました。クリーニングと文書化"

このセグメントでファイアウォールが見つからなかった場合でも、結論を急ぐ必要はありません。

と同じようにやってみましょう 前の部分まずは質問から始めましょう。あなたの場合、このセグメントでファイアウォールを使用する必要がありますか?

これは、ファイアウォールを使用し、複雑なトラフィック フィルタリング アルゴリズムを適用するのに最も正当な場所であると言えます。 で 1の一部 データセンターセグメントにおけるファイアウォールの使用を妨げる可能性のある 4 つの要因について説明しました。 しかし、ここではそれらはもはやそれほど重要ではありません。

例1。 遅れ

インターネットに関しては、1ミリ秒程度の遅延を言っても仕方がありません。 したがって、このセグメントの遅延がファイアウォールの使用を制限する要因になることはありません。

例2。 Производительность

場合によっては、この要因が依然として重要である可能性があります。 したがって、一部のトラフィック (ロード バランサーからのトラフィックなど) がファイアウォールをバイパスできるようにする必要がある場合があります。

例3。 信頼性

この要素は依然として考慮する必要がありますが、インターネット自体の信頼性が低いことを考えると、このセグメントにおける重要性はデータセンターほど重要ではありません。

したがって、サービスが http/https 上に存在すると仮定します (セッションは短い)。 この場合、XNUMX つの独立したボックス (HA なし) を使用し、そのうちの XNUMX つにルーティングの問題がある場合、すべてのトラフィックを XNUMX 番目のボックスに転送できます。

または、ファイアウォールをトランスペアレント モードで使用し、ファイアウォールに障害が発生した場合に、問題を解決しながらトラフィックがファイアウォールをバイパスできるようにすることもできます。

したがって、おそらく単に 価格 このセグメントでのファイアウォールの使用を放棄せざるを得なくなる要因となる可能性があります。

重要！

このファイアウォールをデータセンターのファイアウォールと組み合わせたいという誘惑があります (これらのセグメントに対して XNUMX つのファイアウォールを使用します)。 解決策は原理的には可能ですが、次の点を理解しておく必要があります。 インターネット アクセス ファイアウォールは実際には防御の最前線にあり、悪意のあるトラフィックの少なくとも一部を「引き受ける」ため、当然、このファイアウォールが無効になるリスクの増加を考慮する必要があります。 つまり、これら XNUMX つのセグメントで同じデバイスを使用すると、データセンター セグメントの可用性が大幅に低下します。

いつものように、企業が提供するサービスに応じて、このセグメントの設計は大きく異なる可能性があることを理解する必要があります。 いつものように、要件に応じてさまざまなアプローチを選択できます。

例

CDN ネットワークを使用するコンテンツ プロバイダーの場合 (たとえば、次を参照) 一連の記事) の場合、トラフィックのルーティングとフィルタリングに別個のデバイスを使用して、数十、さらには数百のポイント オブ プレゼンスにわたるインフラストラクチャを作成したくない場合があります。 費用もかかるし、単純に不必要かもしれません。

BGP の場合、必ずしも専用ルーターを用意する必要はなく、次のようなオープンソース ツールを使用できます。 クアッガ。 したがって、おそらく必要なのは、XNUMX 台または複数のサーバー、スイッチ、および BGP だけです。

この場合、サーバーまたは複数のサーバーが CDN サーバーだけでなくルーターの役割も果たすことができます。 もちろん、詳細はまだたくさんあります (バランスを確保する方法など) が、実行可能であり、当社のパートナーの XNUMX 社で使用して成功したアプローチです。

完全な保護 (インターネット プロバイダーが提供するファイアウォール、DDOS 保護サービス) を備えた複数のデータ センターと、L2 スイッチとサーバーのみを備えた数十または数百の「簡素化された」ポイント オブ プレゼンスを持つことができます。

しかし、この場合の保護はどうなるのでしょうか？

たとえば、最近人気のあるものを見てみましょう。 DNS 増幅 DDOS 攻撃。 その危険性は、大量のトラフィックが生成され、すべてのアップリンクが 100% 単に「詰まる」という事実にあります。

私たちのデザインの場合はどうなるでしょうか。

• AnyCast を使用する場合、トラフィックはポイント オブ プレゼンス間で分散されます。 合計帯域幅がテラビットの場合、これ自体が実際に (ただし、最近、テラビット単位の悪意のあるトラフィックによる攻撃がいくつかあります)、アップリンクの「オーバーフロー」から保護します。
• ただし、一部のアップリンクが詰まった場合は、このサイトをサービスから削除するだけです (プレフィックスのアドバタイズを停止します)。
• また、「完全な」（したがって保護された）データセンターから送信されるトラフィックの割合を増やすこともできるため、保護されていないポイント オブ プレゼンスから悪意のあるトラフィックのかなりの部分を除去できます。

この例にはもう XNUMX つの小さなメモがあります。 IX 経由で十分なトラフィックを送信すると、そのような攻撃に対する脆弱性も軽減されます。

BGP の設定

ここには XNUMX つのトピックがあります。

• 接続性
• BGP の設定

接続性についてはすでに少し説明しました。 1の一部。 重要なのは、顧客へのトラフィックが最適なパスをたどることを確認することです。 最適性は必ずしもレイテンシだけを指すわけではありませんが、通常、レイテンシの低さが最適性の主な指標となります。 一部の企業にとってこれはより重要ですが、他の企業にとってはそれほど重要ではありません。 それはすべて、提供するサービスによって異なります。

例1

あなたが交換業者であり、クライアントにとってミリ秒未満の時間間隔が重要である場合、当然、インターネットの種類についてはまったく話になりません。

例2

あなたがゲーム会社で、数十ミリ秒が重要である場合、当然、接続は非常に重要です。

例3

また、TCP プロトコルの特性により、XNUMX つの TCP セッション内のデータ転送速度は RTT (往復時間) にも依存することを理解する必要があります。 CDN ネットワークも、コンテンツ配信サーバーをコンテンツの消費者の近くに移動することでこの問題を解決するために構築されています。

接続の研究はそれ自体興味深いトピックであり、単独の記事または一連の記事を作成する価値があり、インターネットがどのように「機能する」かを十分に理解する必要があります。

役立つリソース:

ripe.net
bgp.he.net

例

小さな例を XNUMX つだけ挙げてみましょう。

データセンターがモスクワにあり、単一のアップリンク、Rostelecom (AS12389) があると仮定します。 この場合 (シングル ホーム)、BGP は必要なく、Rostelecom のアドレス プールをパブリック アドレスとして使用する可能性が高くなります。

あなたが特定のサービスを提供しており、十分な数のウクライナからのクライアントがいて、彼らが長い遅延について苦情を言っていると仮定しましょう。 調査中に、それらの一部の IP アドレスが 37.52.0.0/21 グリッド内にあることがわかりました。

トレースルートを実行すると、トラフィックが AS1299 (Telia) を通過していることがわかり、ping を実行すると、平均 RTT が 70 ～ 80 ミリ秒でした。 これは次のサイトでも見ることができます 探しているガラス ロステレコム.

Whois ユーティリティ (ripe.net またはローカル ユーティリティ上) を使用すると、ブロック 37.52.0.0/21 が AS6849 (Ukrtelecom) に属していることを簡単に判断できます。

次に、に行くことで、 bgp.he.net AS6849 は AS12389 と関係がないことがわかります (これらは相互にクライアントでもアップリンクでも、ピアリングもありません)。 しかし、見てみると、 ピアのリスト AS6849 の場合、たとえば、AS29226 (Mastertel) および AS31133 (Megafon) が表示されます。

これらのプロバイダーの検索結果を見つけたら、パスと RTT を比較できます。 たとえば、Mastertel の場合、RTT は約 30 ミリ秒になります。

したがって、80 ミリ秒と 30 ミリ秒の差がサービスにとって重要な場合は、接続について検討し、AS 番号とアドレス プールを RIPE から取得し、追加のアップリンクを接続するか、IX 上にポイント オブ プレゼンスを作成する必要があるかもしれません。

BGP を使用すると、接続を改善できるだけでなく、インターネット接続を冗長的に維持することもできます。

このドキュメント には、BGP を構成するための推奨事項が含まれています。 これらの推奨事項はプロバイダーの「ベスト プラクティス」に基づいて作成されたという事実にもかかわらず、(BGP 設定が完全​​に基本的ではない場合でも) 間違いなく有用であり、実際に、で説明した強化の一部である必要があります。 最初の部分.

DOS/DDOS 保護

現在、DOS/DDOS 攻撃は多くの企業にとって日常的な現実となっています。 実際、あなたは何らかの形で頻繁に攻撃を受けています。 あなたがこれにまだ気づいていないという事実は、あなたに対して標的型攻撃がまだ組織されておらず、おそらく気づかずに使用している保護手段 (オペレーティング システムに組み込まれているさまざまな保護手段) が、攻撃を引き起こすのに十分であることを意味します。あなたとあなたの顧客のために提供されるサービスの低下が最小限に抑えられるようにします。

機器のログに基づいて、リアルタイムで美しい攻撃マップを描画するインターネット リソースがあります。

それは それらへのリンクを見つけることができます。

私のお気に入り マップ チェックポイントから。

DDOS/DOS に対する保護は通常、階層化されています。 その理由を理解するには、どのような種類の DOS/DDOS 攻撃が存在するかを理解する必要があります (たとえば、次を参照)。 ここで または ここで)

つまり、次の XNUMX 種類の攻撃があります。

• ボリューム攻撃
• プロトコル攻撃
• アプリケーション攻撃

たとえば、ファイアウォールを使用して最後の XNUMX 種類の攻撃から身を守ることができたとしても、アップリンクを「圧倒する」ことを目的とした攻撃から身を守ることはできません (もちろん、インターネット チャネルの総容量がテラビット単位で計算されていない場合は、あるいは、さらに良いのは、数十テラビット単位です)。

したがって、防御の第一線は「大量」攻撃に対する保護であり、プロバイダーはこの保護を提供する必要があります。 まだそれに気づいていないのなら、今はただ幸運なだけです。

例

複数のアップリンクがあるが、この保護を提供できるプロバイダーは XNUMX つだけであるとします。 しかし、すべてのトラフィックが XNUMX つのプロバイダーを経由する場合、先ほど簡単に説明した接続はどうなるでしょうか?

この場合、攻撃中に接続を部分的に犠牲にする必要があります。 しかし

• これは攻撃の間のみです。 攻撃が発生した場合は、トラフィックが「アンブレラ」を提供するプロバイダーのみを通過するように BGP を手動または自動で再構成できます。 攻撃が終わったら、ルーティングを以前の状態に戻すことができます
• すべてのトラフィックを転送する必要はありません。 たとえば、一部のアップリンクまたはピアリングを介した攻撃がないことがわかった場合 (またはトラフィックが重要ではない場合)、これらの BGP ネイバーに向けて競合属性を持つプレフィックスをアドバタイズし続けることができます。

「プロトコル攻撃」や「アプリケーション攻撃」からの保護をパートナーに委任することもできます。
ここで ここで あなたは良い研究を読むことができます（翻訳）。 確かに、この記事は XNUMX 年前のものですが、DDOS 攻撃から身を守る方法についてのアイデアを提供します。

原則として、自分自身をこれに限定し、保護を完全にアウトソーシングすることができます。 この決定には利点もありますが、明らかな欠点もあります。 事実は、（これも会社の取り組み次第ですが）ビジネスの存続について話し合うことができるということです。 そして、そのようなことは第三者に任せてください...

したがって、(プロバイダーからの保護に加えて) 第 XNUMX および第 XNUMX の防御線を編成する方法を見てみましょう。

したがって、第 XNUMX の防御線は、ネットワークの入り口にあるフィルタリングとトラフィック リミッター (ポリサー) です。

例1

いずれかのプロバイダーの助けを借りて、DDOS に対して傘をかぶせたと仮定しましょう。 このプロバイダーが Arbor を使用してトラフィックをフィルタリングし、ネットワークのエッジでフィルタリングすると仮定します。

Arbor が「処理」できる帯域幅は限られており、プロバイダーは当然のことながら、このサービスを注文するすべてのパートナーのトラフィックを常にフィルタリング装置を通過させることはできません。 したがって、通常の状態では、トラフィックはフィルタリングされません。

SYN フラッド攻撃があったと仮定します。 攻撃が発生した場合にトラフィックを自動的にフィルタリングに切り替えるサービスを注文した場合でも、これが即座に行われるわけではありません。 XNUMX 分以上攻撃を受け続けます。 そして、これは機器の故障やサービスの低下につながる可能性があります。 この場合、エッジ ルーティングでトラフィックを制限すると、その間に一部の TCP セッションが確立されなくなりますが、インフラストラクチャを大規模な問題から守ることができます。

例2

異常に多数の SYN パケットが発生するのは、SYN フラッド攻撃だけが原因ではない可能性があります。 (100 つのデータセンターに対して) 約 XNUMX 万の TCP 接続を同時に実行できるサービスを提供すると仮定します。

主要プロバイダーの 50 つで短期的な問題が発生した結果、セッションの半分が切断されたとします。 アプリケーションが、深く考えずにすぐに (またはすべてのセッションで同じ一定の時間間隔を置いて) 接続を再確立しようとするように設計されている場合、約 XNUMX 個以上の SYN パケットを受信することになります。同時に。

たとえば、証明書の交換を伴うこれらのセッション上で ssl/tls ハンドシェイクを実行する必要がある場合、ロード バランサーのリソースを枯渇させるという観点から見ると、これは単純な「DDOS」よりもはるかに強力な「DDOS」になります。 SYN フラッド。 このようなイベントはバランサーが処理する必要があるように思えますが...残念ながら、私たちはそのような問題に直面しています。

そしてもちろん、この場合もエッジルーター上のポリサーが機器を節約します。

DDOS/DOS に対する保護の XNUMX 番目のレベルは、ファイアウォールの設定です。

ここでは、XNUMX 番目と XNUMX 番目のタイプの両方の攻撃を止めることができます。 一般に、ファイアウォールに到達するすべてのものをここでフィルタリングできます。

協議会

ファイアウォールに与える仕事をできる限り少なくし、最初の XNUMX つの防御線をできる限りフィルタリングしてください。 だからこそ。

たとえば、サーバーのオペレーティング システムが DDOS 攻撃に対してどれだけ耐性があるかをチェックするためにトラフィックを生成しているときに、通常の強度のトラフィックでファイアウォールを 100% 負荷して「強制終了」したということが偶然起こったことはありますか? ? そうでない場合は、単に試していないだけでしょうか?

一般に、先ほども述べたように、ファイアウォールは複雑なものであり、既知の脆弱性やテスト済みのソリューションとうまく連携しますが、異常なもの、単なるガベージや不正なヘッダーを持つパケットを送信した場合は、何らかの問題を抱えていることになり、問題を抱えているわけではありません。 (私の経験に基づくと) 非常に低い確率で、トップエンドの機器でさえ呆然とする可能性があります。 したがって、ステージ 2 では、通常の ACL (L3/L4 レベル) を使用して、ネットワークに入る必要のあるトラフィックのみを許可します。

ファイアウォールでのトラフィックのフィルタリング

ファイアウォールについての話を続けましょう。 DOS/DDOS 攻撃はサイバー攻撃の一種にすぎないことを理解する必要があります。

DOS/DDOS 保護に加えて、次の機能リストのようなものを使用することもできます。

• アプリケーションファイアウォール
• 脅威の防止 (ウイルス対策、スパイウェア対策、脆弱性)
• URLフィルタリング
• データフィルタリング（コンテンツフィルタリング）
• ファイルのブロック (ファイル タイプのブロック)

このリストから何が必要かを決めるのはあなた次第です。

つづきます

出所： habr.com