Akamai が Microsoft の RPC サービスの脆弱性を発見した経緯

一昨日、 Akamai の研究者は、Microsoft のWindows RPCサービスに 2 つの重要な脆弱性を発見しました。深刻度スコアが4.3のCVE-2022-38034と、スコアが8.8のCVE-2022-38045です。これらの脆弱性は、設計上の欠陥を悪用して、キャッシュ メカニズムを通じてMS-RPCセキュリティ コールバックをバイパスする可能性があります。パッチが適用されていないすべてのWindows 10およびWindows 11 コンピューターが影響を受けることが確認されました。

あらゆるところに潜むセキュリティの脅威に対して、 Akamai のセキュリティ ソリューションが「保護シールド」を構築します。

Akamai の強力なセキュリティ ソリューションの詳細については、こちらをご覧ください。

いつでもどこでもあらゆるセキュリティ リスクを把握できます。

これらの脆弱性はマイクロソフトに開示されており、マイクロソフトも10月の「 Patch Tuesday 」でパッチを通じて関連する問題を修正した。脆弱性の発見プロセスは、 Akamai の研究者が開発した自動化ツールと方法論によってサポートされました。この投稿では、脆弱性と、調査中に使用したツール ( RPCツールキット コード リポジトリ) に関する情報を提供します。

背景

MS-RPCは、 Windowsオペレーティング システムの基礎の 1 つです。 1990 年代に誕生して以来、システムの多くの機能やコンポーネントに深く根付いています。サービスマネージャーですか? RPCなしでは生きていけません!ラス？ RPCが必要です! COM ? RPCにも依存します。ドメイン コントローラーで実行される一部のドメイン操作でも、 RPCの使用が必要になります。 RPC は非常に一般的になったため、このテクノロジは広範囲に調査、文書化、研究されているはずだと多くの人が考えています。

実際にはそうではありません。 Microsoft はRPCの使用に関する優れたドキュメントを多数提供していますが、この脆弱性に関連するトピックに関するコンテンツはあまりなく、研究者はRPC 、特にそのセキュリティに十分な注意を払っていません。これはおそらく、 RPC ( MS-RPCだけでなく、Microsoft も間違いなく関与しています) があまりにも複雑であるため、研究して理解するのがより困難であるためです。

しかし、私たちは常に挑戦を歓迎しているので、 MS-RPCの深海に飛び込むことにしました。これは興味深い研究テーマであるだけでなく、セキュリティにも影響を与えるからです。結局のところ、現在でもRPCを使用する一般的な攻撃手法は数多く存在します( MS-COM経由で開始されるT1021.003 、 MS - TSCH経由で開始される T1053.005 、 MS - SCMR経由で開始されるT1543.003など)。 MS-RPCにはセキュリティ メカニズムが組み込まれていますが、簡単に回避または悪用される脆弱性があったらどうなるでしょうか。公開されたRPCサービスが悪用され、ユーザーが意図しない方法でコンピューターに影響を与える可能性がある場合はどうなるでしょうか?

実際、私たちはキャッシュを通じてセキュリティ メカニズムを回避する方法を発見し、他の要件を満たすことなくリモート サーバーで権限を昇格するために悪用できるサービスを発見しました (詳細は後述)。現在、これらの潜在的なエクスプロイトの例として、 WksSvcとSrvSvcの 2 つを挙げることができます。開示プロセスが完了したら、他の脆弱性の詳細も公開します。

この投稿では、 RPCサーバーのセキュリティ コールバック メカニズム、キャッシュを介してそれを回避する方法、および自動化された調査方法によって Windows サービスに潜在的な脆弱性があるかどうかを調べる方法に焦点を当てます。自動化ツールと生の出力は、 GitHubで入手できるRPCツールキットで利用できます。このリポジトリには、私たちが頼りにしている他の有用な参考資料やその他の研究へのリンクも提供されています。

セキュリティコールバック

脆弱性自体について説明する前に、まずMS-RPCによって実装されている最も基本的なセキュリティ メカニズムの 1 つであるセキュリティコールバックについて簡単に説明する必要があります。セキュリティ コールバックを使用すると、 RPCサーバー開発者はRPCインターフェイスへのアクセスを制限できるため、独自のロジックを適用して特定のユーザーへのアクセスを許可したり、認証を強制したり、トランスポート タイプを設定したり、特定のOpnum (サーバーによって公開される関数はOpnum 、つまり「操作番号」で表すことができます) へのアクセスをブロックしたりできます。

RPCランタイムは、クライアントがサーバーによって公開された関数を呼び出すたびに、このようなコールバックを発行します。

RPCセキュリティ コールバック

私たちの研究は主にリモートクライアントとサーバーの相互作用に焦点を当てています。サーバー側のRPCランタイム実装は、 ALPCエンドポイントおよびリモート エンドポイント (名前付きパイプなど)の実装とは異なるため、これは特に重要です。

キャッシュメカニズム

パフォーマンスを向上させ、使用率を高めるために、 RPCランタイムはセキュリティ コールバックの結果をキャッシュします。基本的に、これは、セキュリティ コールバックを呼び出す前に、ランタイムが最初にキャッシュされた項目を使用しようとすることを意味します。実装を詳しく見てみましょう。

RPC_INTERFACE::DoSyncSecurityCallback は、セキュリティ コールバックを呼び出す前に、まずキャッシュ エントリがあるかどうかを確認します。これを行うには、 OSF_SCALL::FindOrCreateCacheEntryを呼び出す必要があります。

OSF_SCALL::FindOrCreateCacheEntry は次の操作を実行します。

1. SCALL (クライアント呼び出しを表すオブジェクト)からクライアントのセキュリティ コンテキストを取得します。
2. クライアントのセキュリティ コンテキストからキャッシュ ディクショナリを取得します。
3. インターフェイス ポインターを辞書のキーとして使用し、キャッシュ項目を値として使用します。
4. キャッシュ エントリが存在しない場合は作成されます。

RPCランタイム内部キャッシュ プロセス

各キャッシュ エントリには、インターフェイス内のプロシージャの数、ビットマップ、インターフェイス生成という3 つの重要なフィールドがあります。

RPCサーバーのライフサイクル中に、たとえばサーバーが既存のインターフェイスに対してRpcServerRegisterIf3を呼び出した後などに、インターフェイスが変更されることがあります。これにより、 RPC_INTERFACE::UpdateRpcInterfaceInformationへの後続の呼び出しが発生し、インターフェースが更新され、インターフェースの世代が増加します。この方法では、キャッシュ エントリが元のインターフェイスから取得された可能性があるため、キャッシュは「リセット」する必要があることを認識します。

キャッシュ メカニズムは、インターフェイス ベース モード (デフォルトの動作) と呼び出しベース モードの 2 つのモードで動作します。

• インターフェースベースのキャッシュ

このモードでは、キャッシュはインターフェース ベースで動作します。つまり、キャッシュの観点からは、2 つの異なる関数への 2 つの呼び出しは、同じインターフェース上にある限り区別できません。

キャッシュされた項目が使用できるかどうか、または安全なコールバックを呼び出す必要があるかどうかを確認するために、 RPCランタイムは、キャッシュされた項目に格納されているインターフェイス生成と実際のインターフェイス生成を比較します。キャッシュ エントリの初期化プロセスによってインターフェイス生成がゼロにリセットされるため、比較が最初に実行されるときのインターフェイス生成は異なる必要があり、セキュリティ コールバックが常に呼び出されます。コールバックが正常に返された場合、 RPCランタイムはキャッシュされた項目のインターフェイス生成を更新します (これにより、キャッシュされた項目が成功したものとして「マーク」され、セキュリティ コールバックを再度呼び出さなくてもインターフェイスにアクセスできるようになります)。次回クライアントが同じインターフェースで関数を呼び出すときには、キャッシュされたエントリが使用されます。

• 呼び出しベースのキャッシュ

このモードは、 RPCインターフェイスがRPC_IF_SEC_CACHE_PER_PROCフラグを使用して登録されている場合に使用されます。このモードでは、キャッシュは、セキュリティ コールバックがビットマップ経由でアクセスできるプロシージャを追跡します。したがって、クライアントがFoo関数を呼び出し、セキュリティ コールバックが正常に返された場合、 Fooのエントリがキャッシュされます。クライアントがBar関数を呼び出すと、セキュリティ コールバックが再度呼び出されます。

呼び出しベースのキャッシュとインターフェースベースのキャッシュ

キャッシュ関連の要件

では、キャッシュが適切に機能するためにはどのような条件を満たす必要があるのでしょうか?まず、いくつかの用語を明確にする必要があります。 MS-RPC は、バインディング ハンドルを使用してクライアントとサーバー間の論理接続を表します。クライアントとサーバーは両方とも、指定された関数を使用してバインディング データを操作できます。

バインディングを認証できます。これは、サーバーが認証情報を登録するときに発生します( RpcServerRegisterAuthInfoを呼び出すことによって)。その後、クライアントはバインディングに認証情報を設定できます。これにより、サーバーはクライアントの ID に関する情報を取得できるようになります。認証プロセスでは、クライアント用に作成されたセキュリティ コンテキスト オブジェクトが出力されます。

キャッシュ メカニズム全体はこのセキュリティ コンテキストに基づいています。つまり、バインディングが認証されていない場合は、クライアントのセキュリティ コンテキストを作成できず、キャッシュを使用できません。キャッシュが適切に機能するためには、サーバーとクライアントの両方が認証情報を登録して設定する必要があります。

しかし、サーバーが認証情報を登録しない場合はどうなるでしょうか?キャッシュはまだ使用できますか?これには多重化が含まれます。

多重化

Windows 10バージョン1703より前では、サービスは他のサービスと同じSvchostプロセスを共有できました。一部のRPCランタイム オブジェクトはすべてのインスタンス間で共有されるため、この動作はMS-RPCのセキュリティに影響を及ぼします。たとえば、エンドポイント ( TCPポート7777など) を登録すると、そのエンドポイントは同じプロセスで実行されているすべてのインターフェースにアクセスできるようになります。したがって、ローカルでのみアクセス可能だった他のサービスにも、リモートでアクセスできるようになります。 Microsoft もこの動作についてここで説明しています。

エンドポイントを多重化できることはよく知られており、文書化されていますが、ここでは非常によく似た別の動作であるSSPI多重化について説明します。認証情報登録プロセスの一環として、サーバーは使用する認証サービスを指定する必要があります。認証サービスは、クライアントから受信した認証情報を処理するソフトウェア パッケージであるセキュリティ サポート プロバイダー( SSP ) です。ほとんどの場合、 NTLM SSP 、 Kerberos SSP 、またはMicrosoft Negotiate SSPが使用され、 KerberosとNTLMの間で最適なオプションが選択されます。

RPCランタイムは認証情報をグローバルに保存します。つまり、2 つのRPCサーバーが同じプロセスを共有し、そのうちの 1 つが認証情報を登録すると、もう 1 つのサーバーもその認証情報を取得します。これにより、クライアントはいずれかのサーバーにアクセスするときにバインディングを認証できるようになります。セキュリティの観点から、サーバーが認証情報を登録しない場合は、クライアントがバインディングを認証することは期待されず、バインディングはキャッシュされません。しかし、そうではありません。

CVE-2022-38045 — Srvsvc

RPCセーフ コールバックとキャッシュの基本を理解したので、このメカニズムを実際の環境で悪用できるかどうかを確認できます。私たちは、過去に段階的に悪用された脆弱性がすでに発見されていたSrvsvcを選択しました。

Srvsvc はMS-SRVSインターフェイスを公開します。サーバーサービス ( LanmanServerとも呼ばれます) は、 SMB共有の管理を担当するWindowsのサービスです。共有とは、Common Internet File System ( CIFS ) サーバーを介してネットワーク経由でアクセスできるリソース (ファイル、プリンター、ディレクトリ ツリー) です。基本的に、テザリングにより、ユーザーはネットワーク上の他のデバイスを使用して日常的なタスクを実行できるようになります。

Srvsvcのセキュリティ コールバックを調査しているときに、すでに発見されている脆弱性に加えて、この関数に他の脆弱性が含まれている可能性があることに気付きました。セキュリティ コールバックのロジックを見てみましょう。

Srvsvcのセキュリティコールバックロジック

上記のように、 Srvsvcのセキュリティ コールバックには次のロジックが含まれています。

1. リモート クライアントが64 ～ 73 (含む)の範囲の機能にアクセスしようとすると、アクセスは拒否されます。
2. 非クラスター アカウントのリモート クライアントが58 ～ 63 (両端を含む)の範囲の機能にアクセスしようとすると、アクセスは拒否されます。

したがって、本質的には、リモート クライアントはインターフェイス上の特定の機能にアクセスできなくなります。この範囲チェックから、制限された関数は機密関数であり、意図した (ローカル) プロセスによってのみ呼び出すことができることがわかります。

このチェックはこれらの機能へのリモート アクセスを防止しようとしますが、リモート攻撃者はキャッシュを悪用するだけでこの制限を回避できます。まず、リモート攻撃者はスコープ内にない関数、つまりリモートで使用できる関数を呼び出すことができます。セキュリティ コールバック関数はRPC_S_OKを返すため、 RPCランタイムは結果を正常にキャッシュできます。インターフェースがRPC_IF_SEC_CACHE_PER_PROCフラグで登録されていないため、インターフェース ベースのキャッシュが使用されます。したがって、次に攻撃者が同じインターフェース上で任意の関数を呼び出すと、キャッシュされたエントリが直接使用され、アクセスが可能になります。つまり、攻撃者は安全なコールバックをまったく呼び出さずに、アクセスできないはずのネイティブ関数を呼び出すことができるようになります。

RPCセキュリティ コールバックのキャッシュ バイパス プロセス

Srvsvc は認証情報を登録しないため、通常、クライアントはバインドを認証できず、キャッシュを有効にすることができません。しかし、サーバー コンピューターのメモリが3.5 GB未満の場合、 Srvsvc は他のサービスと同じSvchostプロセスを共有することになります。 AD ハーベスト サイトとサブネット サービスとリモート デスクトップ構成サービスは認証情報を登録するため、 Srvsvc はキャッシュ攻撃に対して脆弱です。

この特定のケースでは、攻撃者はOpnum 58 ～ 74 を使用して制限された機能にアクセスできます。攻撃者がこれらの機能を悪用する方法の 1 つは、リモート コンピューターに認証を強制することです。

宝探しを始めましょう

セキュリティ コールバック キャッシュ メカニズムを悪用すると、実際の脆弱性につながる可能性があることを知った後、キャッシュ攻撃の影響を受ける可能性のある他のインターフェイスを特定することにしました。しかし、すべてのインターフェースを手動で見つけようとすると、時間がかかり、骨の折れる作業になるため、自動化された方法を使用して完了する予定です。

この場合、 RPCインターフェイスを見つけるには、現在実行中のプロセスを介して、またはファイル システムを介しての 2 つの方法があります。

実行中のプロセスの場合、リモート サーバー上のリモート エンドポイント マッパーを照会する(たとえば、 Impacketのrpcmapまたはrpcdumpツールを使用する) か、ローカルで ( RpcViewやRpcEnumなどのツールを使用する)メモリにロードされている RPC サーバーを表示できます。ただし、このアプローチでは問題が発生します。現在ロードされていないすべてのポートが失われ、クライアント ポートはまだ登録されていないため表示できません。

あるいは、ファイルにコンパイルされたRPCインターフェイスをWindowsファイル システムで検索することもできます。各インターフェースについて、 RpcServerRegisterIfに渡されたパラメータを分析して登録情報を調べます。これはRpcEnum の動作と多少似ていますが、メモリではなくファイル システムを検索します。

メモリにロードされないインターフェースをカバーするために、私たちの研究では最終的にファイル システム アプローチを選択しました。私たちはこのプロセスを自動化するためのスクリプトとツールをいくつか作成し、 RPCツールキット リポジトリに公開しました。

キャッシュ対応インターフェースを見つけるために、実際にRPCインターフェース自体を解析する必要はなく、必要なすべての情報はRPCサーバーの登録呼び出しから抽出できます。登録関数は、 RPCインターフェイス構造、登録フラグ、およびセキュリティ コールバック ポインターを受け入れます。ただし、 RPCインターフェイス構造を解析すると、インターフェイスによって公開される関数、インターフェイスがクライアントとサーバーのどちらによって使用されているかなど、多くの有用な情報も得られます。私たちが最も懸念しているのはRPCサーバー (脆弱性が存在する可能性がある) ですが、 RPCクライアントもサーバーへの呼び出しに関する貴重な洞察を提供します。

RPCサーバー インターフェイスの構造については、このドキュメントを参照してください。さまざまなフィールドを推測する必要がなくなります。また、サイズ フィールドと転送構文は変更されていません (実際には、 DCE NDRとNDR64 の2 つの転送構文が可能ですが、 DCE NDRは偶然発見されたものです)。

PEファイルに保存されたRPCインターフェイス構造コード スニペットのスクリーンショット。ボックス内の内容はサイズと転送構文です。

これら 2 つの定数 ( Yaraまたは正規表現を使用) を検索することで、すべてのRPCインターフェース構造を簡単に見つけることができます。インタープリタ情報フィールドが見つかると、それを使用して、サーバーが実際に実装している関数を理解できます。

クリーンな出力の例

しかし、インターフェースの安全性コールバックに関する情報はまだ不足しています (そのような情報が存在する場合)。また、インターフェースがキャッシュされるかどうかもわかりません。このためには、信頼できる友人である逆アセンブラに頼る必要があります。優れた逆アセンブラーはすべて、 RPCサーバー内のすべてのインターフェイス登録関数呼び出しを簡単に見つけることができるxref機能を提供します。この時点では、関数呼び出し引数を解析し、それを使用してインターフェイス構造アドレス (収集したRPCサーバー データと相互参照するため)、安全なコールバック アドレス (存在する場合)、およびRPCインターフェイス タグを抽出する必要があります。

RPCサービス登録の分解

弊社が公開したクリーンアップ スクリプトでは、上記の一連の操作を実現できます。このスクリプトと、 Windows Server 2012およびServer 2022での出力は、 RPCツールキットで入手できます。

本当に効果があるのでしょうか？

これらの方法や理論は良さそうに聞こえますが、本当に成果を上げることができるのでしょうか?

答えは「はい」です。セキュリティ コールバックとキャッシュの両方を備えたインターフェースは120 個以上ありますが、その多くは十分に文書化されていません。ほとんどの場合、セキュリティ コールバックはキャッシュ メカニズムによってそれほど影響を受けないため、これ自体は慌てる必要はありません。通常、セキュリティ コールバックによって実行されるチェックは、トランスポート プロトコル シーケンス ( TCPなど) や認証レベルなど、キャッシュできない値に対して行われます。変更を行うには新しい接続を確立する必要があり、キャッシュがリセットされてキャッシュ バイパス対策が無効になるため、新しいセキュリティ コンテキストが必要になります。

しかし、この研究方法にはいくつかの抜け穴も見つかりました。他の脆弱性はまだ開示プロセスが完了していないため、現時点で議論できるのはそのうちの 1 つだけです。

翻訳

• CVE-2022-38034 CVSSスコア: 4.3

WksSvc はMS-WKSTインターフェイスを公開します。このサービスは、ドメイン メンバーシップ、コンピューター名、およびSMBプリント サーバーなどのSMBネットワーク リダイレクターへの接続を管理する役割を担います。このインターフェースのセキュリティ コールバックを見ると、いくつかの関数が他の関数とはまったく異なる方法で処理されていることがわかります。

WksSvcセキュリティ コールバックの一部。さまざまな関数とさまざまなOpnumの違いを示しています。

Opnumが8 ～ 11の関数は、ローカル クライアント経由で呼び出されたときにもチェックされます。つまり、それらの関数へのリモート呼び出しは許可されません。しかし、キャッシュがあるため、最初にリモート呼び出しを許可する別の関数を呼び出し、次にこの制限された関数を呼び出すとどうなるでしょうか?

ご想像のとおり、最初の呼び出しで作成されたキャッシュ エントリのおかげで、元々ローカル呼び出しに制限されていたこの関数をリモートで呼び出すことができるようになります。ここで新たな疑問が生じます。これらの機能は、ローカル クライアントに使用を制限するほど重要なのでしょうか?

公開されている関数には、 NetrUseAdd 、 NetrUseGetInfo 、 NetrUseDel 、 NetrUseEnumなどがあります。これらはすべてnetapi32.dllを介してアクセスできるので、おそらく見覚えがあるでしょう(たとえばNetUseAdd を参照)。

これは、この攻撃で何ができるかについての手がかりを与えてくれるので良いことです。つまり、リモート サーバーを指定したネットワーク共有フォルダーに接続し、選択した論理ドライブ文字にマップすることもできます。これは、 net useの機能と非常によく似ています。 （偶然？そうではないかも！）

これにより、次の 2 つの攻撃シナリオを指定できます。

1.共有フォルダーへの認証を要求し、それをNTMLリプレイ攻撃用に別のサーバーに転送したり、オフライン パスワード クラッキング用にトークンを保存したりできます。

悪意のあるファイルサーバーに認証を要求し、認証プロセス中にNTハッシュを盗む

2.あるいは、興味深いファイルや役に立つファイルを使用して、既存のファイル サーバーを偽装する (または新しいファイル サーバーを装う) こともできます。これらのファイルは当社の管理下にあるため、対象ユーザーを感染させるために適切と思われるあらゆる方法で武器に変えることができます。

悪意のあるウェブサーバーを中間者攻撃やフィッシングサーバーとして使用し、不注意なユーザーに武器化された文書やマルウェアを配信する

上記の 2 つのシナリオと、ローカル呼び出しに制限されている関数をリモートで呼び出す機能により、Microsoft はこの脆弱性をEoPとして分類し、スコア4.3を与えています。

しかし、これはすべてではありません。まだ注意を払う必要がある問題がいくつかあります。

セキュリティコンテキスト

WksSvcの下のRPCサーバーは、認証登録自体は実行しません。サービスをスタンドアロンで実行する場合、クライアント認証は実行できません (実行すると、 RPC_S_UNKNOWN_AUTHN_SERVICEエラーが発生します)。したがって、 SSPI多重化メカニズムを同時に悪用するには、このサービスを他のサービスと一緒に実行する必要があります。これにより、影響を受けるWindowsバージョンも、 Windows 10 1703より前のバージョン、または3.5 GB未満の RAMで実行されているWindowsの新しいバージョンに制限されます。

ログインセッション

もう 1 つの問題は、ネットワーク マップされたフォルダーの動作方法に関係しています。これらは常に、マップされたフォルダーを作成したユーザーのログオン セッションに制限されます。セキュリティ バインディングとキャッシュを取得するには最初にログインする必要があるため、これは、既存の (対話型) セッションとは異なる別のログイン セッションをターゲット マシン上に常に作成することを意味します。つまり、これは私たちの脆弱性が何の影響も及ぼさないことを意味します。作成したネットワーク マッピングは、短いログイン セッションにのみ存在します。通常のユーザーがコンピューターにログインしたときに作成されるネットワーク マッピングとは異なり、作成したマッピングはまったく表示されません。

作成された論理ドライブ文字が、攻撃が開始されたログイン セッションのコンテキストにのみ存在し、対話型セッションには表示されないことを示すWinObj のスクリーンショット

この問題を克服するために、 NetrUseAddのコードをさらに深く調べました。いくつかのフラグをNetrUseAddに渡すと、グローバル名前空間にマッピングが作成され、すべてのユーザーに影響することがわかりました。これらのフラグは、使用可能なヘッダー ファイルLMUse.hにも存在します。

LMUse.hで表示されるグローバル マッピング フラグ

これらのフラグを使用すると、コードは対話型セッションに影響を及ぼし、悪用される可能性のあるグローバル マッピングを正常に作成できます。

WksSvcの悪用に成功したWinObjと Explorer のスクリーンショット スニペット: リモート サーバーにグローバル ドライブ マッピングを作成し、ログインしているユーザーの Explorer で表示できるようにします。

要約する

MS-RPCは、 Windowsの一部のコア機能も担う大規模で複雑なプロトコルです。開発者がRPCサーバーを保護するために使用できるセキュリティ機能はありますが、セキュリティに影響を与える可能性のある脆弱性が含まれているため、これはセキュリティ研究者にとって依然として興味深いトピックです。

それにもかかわらず、このテーマに関する研究はあまり発表されていません。この投稿では、 MS-RPC (セキュリティ コールバック) の大規模なセキュリティ メカニズムを調査し、コールバック結果のキャッシュという形でバイパス メカニズムを発見しました。また、脆弱なRPCサーバーを発見するための調査方法についても説明し、脆弱性を悪用して調査結果を実証します。

この記事で提供されるコンテンツとRPCツールキットのコード ベースが、他の人の研究作業に役立つことを願っています。

セキュリティに関して他にご質問はありますか?もしそうなら、コメント欄に残しておきましょう！同時に、コンピューティング、ストレージ、ネットワーク、コンテナをワンストップで構成できる Akamai Linode クラウド コンピューティング プラットフォームをぜひご体験ください。今すぐクリックして体験すると、100 ドルのクラウド使用割り当ても受け取れます↓↓↓

クリックして相談し、1対1の独占ソリューションを入手してください

テクノロジーには境界がなく、インタラクションはゼロ距離です。セキュリティ関連のトピックをもっと見たい場合は、 Akamaiをフォローしてください。