一元化されたファイアウォールランブラーグループ

なぜそれを作成したのですか？

長い間、ランブラーグループでは、3層のデータセンターネットワークアーキテクチャを使用していました。このアーキテクチャでは、各プロジェクトまたはインフラストラクチャコンポーネントが専用のvlanに存在していました。すべてのトラフィック（vlan間およびデータセンター間の両方）は、エッジレベルの機器を通過しました。



エッジ機器は、さまざまな機能を実行できる高価なルーターであるため、その上のポートも高価です。時間の経過とともに、水平方向のトラフィックが増加し（たとえば、データベースレプリケーション、さまざまなサービスへの要求などのマシン間）、ある時点で境界ルーターのポート使用率の問題が発生しました。



このようなデバイスの主な機能の1つは、トラフィックフィルタリングです。その結果、ACLの管理も難しくなりました。すべてを手動で行う必要があり、隣接する部門によるタスクの実行にも時間がかかりました。アクセスレベルでのポートの構成に追加の時間が費やされました。同じNOCの手動アクションを実行するだけでなく、潜在的なセキュリティ問題を特定する必要がありました。ホストはそれぞれ場所を変更するため、他の人のvlanに不正にアクセスする可能性があるためです。







何かを変える時が来ました、そして、Closネットワークまたは彼らがまた呼ばれるように、IP工場は救助に来ました。







外部の類似性にもかかわらず、このアーキテクチャと以前のアーキテクチャの根本的な違いは、リーフレイヤーを含む各デバイスがルーターとして機能し、サーバーのデフォルトのゲートウェイがトップオブラックであるということです。したがって、異なるプロジェクトのホスト間の水平方向のトラフィックは、エッジではなく、スパインレイヤーを通過できるようになりました。



さらに、同じスパインレベルで、データセンターを相互に接続でき、2つのサーバー間のパス上に存在するネットワークデバイスは4つまでです。このアーキテクチャのエッジ機器は、通信事業者を接続するためにのみ必要であり、（インターネットとの間の）垂直トラフィックのみを許可します。



Closネットワークの主な機能は、ホスト間のトラフィックをフィルタリングできる場所がないことです。したがって、この機能はサーバー上で直接実行する必要があります。集中型ファイアウォールは、トラフィックを受信するホスト自体のトラフィックをフィルタリングするプログラムです。

要件

集中型ファイアウォールを実装する必要性は、一度にいくつかの要因によって決定されました。

• エンドユーザーと
• 既存のインフラストラクチャ。

したがって、アプリケーションの要件は次のとおりです。

1. ファイアウォールは、ホストおよび仮想マシン上で機能し、ルールを作成できる必要があります。さらに、ルールのリストは、ファイアウォールが実行されている環境と異なってはなりません。つまり、ルールは同じです。
2. . , – ssh, ( Prometheus), .
3. , -.
4. , – .
5. .
6. : « , ».

Rambler Groupクラウドは非常に動的です。仮想マシンの作成と削除、サーバーのインストールと解体が行われます。したがって、ポイントツーポイントアクセスは使用しません。インフラストラクチャには「ホストグループ」の概念があります。



ホストグループは、サーバーの役割を一意に説明するサーバーのグループのマークアップです。たとえば、news-prod-coolstream-blueです。



これにより、別の要件が発生します。ユーザーは、ホストグループ、プロジェクトなどの高レベルのエンティティを操作する必要があります。

アイデアと実装

タリング



集中型ファイアウォールは、エージェントの構成を必要とする大きくて複雑なものです。問題の発見には5分以上かかることがあるため、エージェントとサーバーとともにツールが表示され、エージェントが正しく構成されているかどうか、および何を修正する必要があるかがユーザーに通知されます。たとえば、ホストの重要な要件は、ホストグループまたはPTRにDNSレコードが存在することです。このツールは、これらすべてとはるかに多くのことを教えてくれます（その機能については以下で説明します）。



統合ファイアウォール



次の原則に従うようにしています。「点滅ルール」を取得しないようにするには、ホスト上でファイアウォールを構成するアプリケーションのみを使用する必要があります。つまり、サーバーに独自のカスタマイズツールが既にある場合（たとえば、ルールが別のエージェントによって構成されている場合）、アプリケーションはそこに属していません。逆の条件も機能します。ファイアウォールエージェントが存在する場合、ルールを設定するのは彼だけです。これが完全な制御の原則です。



ファイアウォールはiptablesではありませ



んご存知のように、iptablesはnetfilterを操作するための単なるコマンドラインユーティリティです。ファイアウォールを異なるプラットフォーム（Windows、BSDシステム）に移植するために、エージェントとサーバーは独自のモデルで動作します。これについては、以下の「アーキテクチャ」セクションで詳しく説明します。



エージェントは論理エラーを解決しようとしません



上記のように、エージェントは決定を行いません。HTTPサーバーがすでに実行されているポート443を閉じたい場合は、問題ありません。閉じてください。

建築

そのようなアプリケーションのアーキテクチャで何か新しいものを思い付くのは困難です。

• エージェントがあり、ホスト上でルールを構成します。
• サーバーがあり、ユーザー定義のルールを提供します。
• ライブラリとツールがあります。
• 高レベルのリゾルバーがあります。ip-addressをホストグループ/プロジェクトに変更し、その逆も同様です。以下のすべてについて詳しく説明します。

Rambler Groupには多くのホストとさらに多くの仮想マシンがあり、それらはすべて、何らかの形で、何らかのエンティティに属しています。

• VLAN
• 通信網
• 事業
• ホストグループ。

後者は、ホストのプロジェクトへの帰属とその役割について説明しています。たとえば、news-prod-backend-api、ここで：news --project; prod-そのenv、この場合は本番です。バックエンド-役割; apiは任意のカスタムタグです。



Resolver



Firewallはネットワークレベルやトランスポートレベルで機能し、ホストグループとプロジェクトは高レベルのエンティティです。したがって、「友達を作る」ために、ホスト（または仮想マシン）の所有者を理解するには、アドレスのリストを取得する必要があります。このコンポーネントを「高レベルリゾルバー」と名付けました。高レベルの名前を一連のアドレスに変更し（リゾルバーに関しては「含まれている」）、逆に、アドレスをエンティティの名前に変更します（「含む」）。



ライブラリ-コア



一部のコンポーネントの統合と統合のために、ライブラリが登場しました。これはコアとも呼ばれます。これは、独自のコントローラーとビューを備えたデータモデルであり、入力して読み取ることができます。このアプローチは、サーバー側とエージェントコードを大幅に簡素化し、ホスト上の現在のルールをサーバーから受信したルールと比較するのにも役立ちます。



モデルを埋めるためのいくつかのソースがあります。

• ルールファイル（2つの異なるタイプ：簡略化され、ルールを完全に記述しています）
• サーバーから受信したルール
• ホスト自体から受け取ったルール。

エージェント



エージェントはiptablesに対するバインディングではなく、Cライブラリlibiptc、libxtables上のラッパーを使用して動作するスタンドアロンアプリケーションです。エージェント自体は決定を下さず、ホスト上のルールを構成するだけです。



エージェントの役割は最小限です。ルールファイル（デフォルトのものを含む）を読み取り、サーバーからデータを取得し（リモート操作用に構成されている場合）、ルールを1つのセットにマージし、前の状態と異なるかどうかを確認し、異なる場合は適用します。



エージェントのもう1つの重要な役割は、初期インストール中、またはサーバーから無効な応答を受信したときに、ホストをカボチャに変えないことです。これを回避するために、ssh、監視アクセスなどの一連のルールをデフォルトでパッケージに提供します。ファイアウォールエージェントが200番目の応答コード以外の応答コードを受信した場合、エージェントはアクションを実行しようとせず、前の状態を終了します。ただし、論理エラーからは保護されません。ポート80、443でのアクセスを拒否すると、Webサービスがホストで実行されている場合でも、エージェントは引き続きそのジョブを実行します。



Tulza



Tulzaは、プロジェクトを管理するシステム管理者および開発者を対象としています。目標は非常にシンプルです。ワンクリックで、エージェントの作業に関するすべてのデータを取得できます。ユーティリティは次のことを教えてくれます。

• 実行中のエージェントデーモンです
• ホストのPTRレコードはありますか
• .

この情報は、問題を早期に診断するのに十分です。



サーバー



サーバーはアプリケーション+データベースです。仕事のすべての論理は彼によって実行されます。サーバーの重要な機能は、IPアドレスを保存しないことです。サーバーは、ホストグループ、プロジェクトなどの名前のトップレベルオブジェクトでのみ機能します。



ベースのルールは次のとおりです。アクション：Accept Src：project-B、project-C Dst：Project-B Proto：tcpポート：80、443。



サーバーは、どのルールを誰に与えるかをどのように理解しますか？要件から、エージェントが実行されている場所（ホストまたは仮想マシン）に関係なく、ルールは同一である必要があります。



エージェントからの要求は、常に1つの値（IPアドレス）でサーバーに送信されます。各エージェントが自分自身のルールを要求すること、つまり、彼が目的地であることを覚えておくことが重要です。



サーバーの動作を理解しやすくするために、プロジェクトに属するホストルールを取得するプロセスを検討してください。



リゾルバーが最初に機能します。そのタスクは、IPアドレスをホスト名に変更してから、このホストが含まれているエンティティを見つけることです。 HL-Resolverは、ホストがプロジェクトAに含まれていることをサーバーに応答します。HL-Resolverはデータソースを参照します（これについては前に説明していません）。データソースは、サーバー、プロジェクト、ホストグループなどに関する一種の企業ナレッジベースです。



次に、サーバーは、destination = projectnameを持つプロジェクトのすべてのルールを探します。データベースにアドレスが含まれていないため、プロジェクト名の名前をhostenymsに変更してからアドレスに変更する必要があります。これにより、要求はリゾルバーを介してデータソースに再度送信されます。 HL-Resolerはアドレスのリストを返し、その後エージェントはルールの準備ができたリストを受け取ります。



宛先が仮想マシンを備えたホストである場合、同じスクリプトがホストだけでなく、その上の各仮想マシンに対しても実行されます。



以下は、単純なケースを示す図です。ホスト（ハードウェアまたは仮想マシン）がProject-Aでホストのルールを受け取ります。

リリース

一元化されたファイアウォール管理があれば、すべてを一元的に破壊することもできると推測するのは難しいことではありません。したがって、エージェントとサーバーのリリースは段階的に実行されます。



サーバーの場合-Blue-Green + A / Bテスト

Blue-Greenは、2つのホストグループが関与する展開戦略です。そして、切り替えは部分1、3、5、10 ... 100％で行われます。したがって、新しいリリースで問題が発生した場合、サービスのごく一部のみが影響を受けます。



エージェントの場合、カナリア

カナリア（またはカナリア展開）はA / Bテストにいくぶん似ています。一部のエージェントのみを更新し、メトリックを確認します。すべてが順調である場合、100％まで別の大きなピースなどを取ります。

結論

その結果、システムエンジニア向けのセルフサービスを作成し、ネットワークアクセスを1か所から管理できるようにしました。したがって、私たちは：

• HTTP-API
• .