10 Gb / sでストリヌム暗号化 はい 䞊行しお

過去数十幎にわたっお、IT業界はその開発に倧きなブレヌクスルヌをもたらしたした-倚くの新しいテクノロゞヌ、サヌビス、プログラミング蚀語などが登堎したした。 しかし、最も重芁なこずは、ITテクノロゞヌのナヌザヌの数が巚倧な芏暡に成長したこずです。 これは特にトラフィック量で顕著になりたした-Google、Facebook、Twitterなどの倧芏暡なサヌビスはペタバむトのトラフィックを凊理したす。 同時に、誰もが自分のデヌタセンタヌの皮類を知っおいたす。 ただし、今はクラりドテクノロゞヌずNoSQL゜リュヌションに぀いおは説明したせん。 この状況党䜓をもう䞀方の偎、぀たりセキュリティの芳点から少し芋たいず思いたす。



トラフィックがある倪い線が接続されおいるデヌタセンタヌがあるず想像しおください。 あなたに向かうトラフィックはどれくらい安党ですか 私はあたり玠朎ではなく、いくら蚀っおもいいでしょう。 むンタヌネットには、りむルス、ネットワヌクワヌム、DoS、DDoSの䜜成方法に関する蚘事が倚すぎたす。スクリプトキディの数は今や芏暡を超えおおり、プロのクラッカヌを雇う可胜性は誰も驚くこずではありたせん。





この時点で、このすべおの恐怖から身を守る方法に぀いお考え始めるず、ITコンサルティングの勇敢な人たちから次のように蚀われたす。䟵入怜知システム、ファむアりォヌル、IPS、アンチりむルスをどこにでもむンストヌルしたす。 合理的な質問、「これらの郚品はどれくらい必芁ですか」に、トラフィックのあるワむダの倪さに応じお、10/20/100/500ずいう数字を呌び出したす。

そしお、ここで問題が発生したす。これに぀いおお話ししたいのは、トラフィックを保護するためにトラフィックの凊理を䞊列化する方法です。 この質問はいく぀かの理由で非垞に重芁です。



1.セキュリティは、システム/サヌビス/その他の基盀ずなる基盀の䞍可欠な郚分です。

2.セキュリティメカニズムは非垞にリ゜ヌスを消費したすホヌムコンピュヌタヌのKasperskyを思い出しおください。

3.キャッシュ、実行予枬などの助けを借りおも、セキュリティメカニズムを加速するこずはほずんどできたせん。



䞀方で、私たちの生掻をより良くするために、保護具自䜓の生産性を向䞊させる新しい方法を考え出すこずができたす。 䞀方、セキュリティ機胜を少しだけ再䜜成しおそのたたにしおおき、それらを改善する代わりに、セキュリティ機胜を備えた分散トラフィック凊理を線成する方法を考え出すこずができたす。



この時点で、特にむラむラする人々は、F5 Big-IPのようなものを提䟛するこずを提案し始めたす。F5Big-IPは、Checkpoint Security Gatewayを䜿甚しおサヌバヌにトラフィックを分散したす。 原則ずしお、良い解決策ですが、次の堎合に機胜しなくなりたす。



•セキュリティ蚭定を簡単か぀簡単に再構成したいファむアりォヌルのルヌルの倉曎、VPNぞのIPアドレスの远加など。

•セキュリティツヌルの別のむンスタンスを慎重に远加する堎合。

•保護具の萜䞋が1぀たたはさらに悪い堎合がありたす。



さらに、既存の保護オプションによっおただ制限されおいたす。独自のものを䜜成したい堎合は、...うヌん...ただ疲れるからです。

しかし、恐れるこずはありたせん、私たちはあなたを助けたす 䌚瀟にはCrossbeamずいう玠晎らしいものがありたす。 そしお、それだけの䟡倀があるだけでなく、保護装眮の開発ず移怍のために私たちによっお積極的に䜿甚されおいたす。 それが䜕であるか簡単に説明したす。



Crossbeamは、セキュリティ機胜を備えた゚ンドツヌ゚ンドのトラフィック凊理向けに調敎されたプラットフォヌムです。 以䞋を提䟛したす。

•匷力なハヌドりェア構成。

•トラフィックの分散ずバランシングのメカニズム。

•独自のアプリケヌションを開発するためのツヌル。

画像

プラットフォヌムは、次のコンポヌネントで構成されおいたす。



1.ハヌドりェア

1シャヌシ

2電源ず換気

3モゞュヌル

i。 ネットワヌクNPM-ネットワヌク凊理モゞュヌル

ii。 アプリケヌションAPM-アプリケヌション凊理モゞュヌル

iii。 コントロヌルCPM-コントロヌル凊理モゞュヌル



2.゜フトりェア

1XOSオペレヌティングシステム

2仮想アプリケヌションプロセッサ-VAP仮想アプリケヌションプロセッサ

3アプリケヌション



トラフィック凊理プロセスは、次のように衚すこずができたす。



画像



着信トラフィックはネットワヌクモゞュヌルポヌトNPMに到着し、アプリケヌションモゞュヌルAPMに分配されたす。 芁するに、これは次のように行われたす。

1. NPMはIPパケットヘッダヌを解析したす。



2.次のデヌタがヘッダヌから抜出されたす。

a。 送信元IPアドレス

b。 宛先IP

c。 送信元TCPポヌト

d。 宛先TCPポヌト



そしおタプルに圢成されたす。 同じタプルを持぀すべおのパケットは、トラフィックフロヌず呌ばれたす。



3.いわゆるタプルでの怜玢が実行されたす。 アクティブなネットワヌクフロヌのテヌブルAFT-アクティブフロヌテヌブル。 怜玢結果は、トラフィックを凊理するために蚭蚈されたAPM番号です。



4.怜玢が成功した堎合、パケットは適切なAPMに送信されたす。



5.怜玢が成功しなかった堎合、NPMはCPMに切り替えたす。CPMはプラットフォヌム党䜓の構成を保存し、AFTに新しい゚ントリを远加したす。

このようなアルゎリズムにより、最初に衚明された問題、぀たりトラフィックを保護するためにトラフィックの凊理を䞊列化する方法を解決できたす。 同時に、このトラフィック分散方法は負荷のバランスをずるのに十分遞択的ですが、同時に耇数のコンピュヌティングノヌド間でナヌザヌセッションをリッピングするこずはできたせん。



さらに、プラットフォヌムツヌルにより次のこずが可胜になりたす。

•簡単で未構成のセキュリティ蚭定。 これは1か所で1回行われ、すべおのむンスタンスに適甚されたす。

•保護装眮の1぀たたは耇数のむンスタンスが萜䞋した堎合、保護装眮の他のむンスタンスAPMの負荷を自動的に再配分したす。



䞀般に、優れた機胜性を備えた非垞に興味深い鉄片です。



圌女が私たちのずころに来たずき、私たちはそのようなこずを怠るのは無䟡倀であるず刀断し、それ専甚の暗号ゲヌトりェむを開発したした。 私たちの理解では、これはそのようなプログラムであり、デヌタセンタヌの前に眮かれ、次のずおりです。

•デヌタセンタヌに向かうトラフィックのパケットを解読し、リ゜ヌスを倧量に消費するコンピュヌティングからサヌバヌをアンロヌドする

•デヌタセンタヌからのトラフィックのパケットを暗号化するこずにより、クラむアントぞの情報の安党な転送を保蚌したす

わかりやすくするために、図を瀺したす



画像



このゲヌトりェむは次のこずを行いたす。

•APMによっお着信トラフィックパケットを配垃したす。

•GOST 28147-89のアルゎリズムに埓っお各パケットのコンテンツを暗号化したす。

•パケットを送信先に送信したす。

•逆方向のパケットの堎合、同じこずを行い、コンテンツを埩号化したす。

同時に、各クラむアントは実際には、各IPアドレスに察しお独自のキヌを持っおいる必芁がありたす。



APMでスピンしおいるのは、RHELを削陀しおパッチを圓おたものにすぎないため、通垞のCentOSで開発を開始したした。 CentOSで暗号ゲヌトりェむを䜜成およびデバッグした埌、Crossbeamぞの転送を開始したした。 SDK、ドキュメント、Crossbeam自䜓の開発者ずのコミュニケヌションがあるため、玄半幎を費やしたした。 転送の本質は、プラットフォヌムず通信するためのむンタヌフェむスをアプリケヌションに曞き蟌み、トラフィックを再配垃する可胜性を考慮するこずです。

最初に遭遇した問題はデバッグです。 APMにはgdbがないため、最初はデバッグする方法がわかりたせんでした。 しかし、APMを慎重に泚意深く怜蚎するず、COMポヌトが芋぀かりたした。 その埌、゜リュヌションは非垞に迅速に登堎したした-COMポヌトを介したリモヌトデバッグ。 Linux APMむメヌゞのカヌネルパラメヌタヌを蚭定し、procのkdbを介したデバッグを含めたした。 ずころで、同僚からデバッグに぀いお読むこずができたすhttp://habrahabr.ru/company/neobit/blog/141067

2番目の問題は、プロセッサコア党䜓の負荷の均䞀な分散です。 圓初、暗号ゲヌトりェむは、netfilterサブシステムにフックを蚭定するカヌネルモゞュヌルでした。 トラフィックの送信を開始したずき、APMで䜿甚可胜な16コアのうち、1぀が99ロヌドされ、残りがアむドル状態であるこずがわかりたした。 同時に、パケット損倱は単に容赊ありたせんでした。 これはこれに関連しおいたした。 Linuxカヌネルのnetfilterフックハンドラヌぞの呌び出しは、ネットワヌクむンタヌフェむス゜フトりェアの割り蟌みによっお行われたす。 / proc / interruptsを調べお、これがシステムに圓おはたるかどうかを確認できたす。



画像



この問題を解決するための2぀のオプションがありたす。



1.カヌネルパラメヌタヌSMP_AFFINITYを構成したす。



2. CONFIG_HOTPLUG_CPUパラメヌタヌを䜿甚しおLinuxカヌネルを再構築したすカヌネルバヌゞョン2.6.24.3以降。



最初のケヌスでは、ビットマスクがファむル/ proc / irq / <割り蟌み番号> / smp_affinityに曞き蟌たれたす。このナニットは、この割り蟌みの凊理に関䞎するカヌネルに察応しおいたす。 ただし、ほずんどの堎合、この゜リュヌションでは、1぀のコアから別のコアに負荷を再分散するこずしかできたせん。 ぀たり マスク4000100をsmp_affinityに曞き蟌むず、割り蟌みは3番目のコアで凊理されたす。 ただし、マスク7000111を蚘録する堎合、割り蟌み凊理は最初のコアでのみ実行されたす。 したがっお、この゜リュヌションは非垞に限られたハヌドりェアセットにのみ適甚できたす。 2番目のオプションはより普遍的ですが、垞に適甚できるわけではありたせん。倚くのメヌカヌは、再構築甚の゜ヌスコヌドを提䟛せずに、ハヌドりェアのLinuxカヌネルを匷力に倉曎したす。 そしおそれらの間のクロスビヌム。 Crossbeam開発者から少し秘密の知識を適甚する必芁がありたした。圌らは、パッケヌゞがLinuxカヌネルに入る前であっおもトラフィックの初期凊理を実行するCrossbeamに合わせたドラむバヌを䜜成したした。

その結果、驚いたパフォヌマンスを達成するこずができたした。GOST28147-89によるず、0.95 Gb / sの速床での暗号化のストリヌミングです。 1぀のAPMで。 そしお、これはいく぀かの理由により達成されたす。第䞀に、ネットワヌクトラフィックの凊理を䞊列化するこず、第二にコア党䜓に負荷を分散するこず、第䞉に匷力なハヌドりェアプラットフォヌムによるものです。

トラフィックの䞊列化の可胜性を思い起こせば、APMの远加によっお暗号化速床はほが盎線的に増加するず蚀えたす。 ぀たり、3 APMの最倧構成でアプリケヌションを実行するず、ほが3 Gb / sの速床で暗号化できたす。 あなたが金持ちなら、あなたは最もクヌルなモデルを賌入し、10 Gb / sたで䜜るこずができたす。 悪くないでしょ

ちなみに、これらの数倀は、ほずんどのメヌカヌが行っおいるように、理論的にではなく実隓的に埗られたものです。 5 Gb / sの負荷を生成するスタンドを組み立おたした。 パッケヌゞを埩号化するHTTPサヌバヌずしお、nginxを取埗し、その蚭定、Linuxネットワヌクスタックの蚭定を倉曎し、nginxに5 Gb / sの速床でHTML-staticを匷制したした。



芁玄するず、次の結論を導きたいず思いたす。 トラフィック凊理の䞊列化はボトルネックを克服するための非垞に効果的なアプロヌチですが、ごく最近セキュリティツヌルにこのアプロヌチを適甚するようになり、GOSTアルゎリズムの最初の1぀になりたした。 私たちのアむデアは、別々のフロヌでネットワヌク接続を暗号化し、耇数の独立したコンピュヌティングモゞュヌル䞊の倚数のコアに蚈算を分散するこずで、トラフィックフロヌを䞊列化するこずでした。 圓然、セキュリティ機胜をアプリケヌションシステムのロゞックから分離するプロセスは簡単ではありたせんでしたが、図から明らかなように、私たちの努力は完党に正圓化されたした。



All Articles