悪意のある攻撃と脆弱性。商用SOCはそれと何の関係がありますか?

前書き



SOCへの接続を選択する場合、企業は、プロバイダーを単独で対処するのが難しい可能性のある複雑なインシデントや脅威に対処する際の「セーフティネット」と見なすことがよくあります。同時に、サービスのパイロットテストの段階で、デジタル資産の情報の安定性を確保するための既存の戦略にボトルネックや重大な欠陥が現れることがよくあります。そのため、SOCは、会社とサービスプロバイダーが協力して、距離全体にわたって互いに補完し、助け合う共同の「旅」です。







図: 1.一般的な会社の弱点



私たちは、情報セキュリティの確保において、私たち自身とクライアントの両方で長年の経験を積み重ねてきました。そして、それを読者と共有したいと思います。この記事の一部として、商用SOCによって正常に防止されたいくつかのケースを紹介します。それらから多くの有用なことを学ぶことができます。



ケース1.「プロキシレギュラー」



アテンダントは、10.XX70ホスト(YYru)の10.XX250アドレスからのネットワーク攻撃を記録しました。KerioWinRoute







ファイアウォールソフトウェアが10.XX250ホストにインストールされていることが判明 しました。操作を担当するホストによると、このソフトウェアはファイアウォールとしてのみ使用されていました。ホストスキャンにより、次のことがわかりました







。KerioWebインターフェイスはポート443に快適に配置されています











2.魂をまっすぐ見つめるケリオ



しかし、http-proxyが実行されていたオープンポート3128は、それほど興味をそそりませんでした。チェックを続けると、10.XX250:3128プロキシを使用すると、資格情報を入力しなくてもインターネットにアクセスできることがわかりました。インターネットアクセスは外部IP89.XX18で実行されました。外部IPアドレスをスキャンすると、可用性が示されました:



3128 / tcp -KerioWinRouteファイアウォールプロキシサーバーポート。



このサービスでは、Connectメソッドを使用することが部分的に可能であることが判明しました。



















結果:ポート3128 / tcpのプロキシを介して、インターネットから会社の内部ネットワークへのアクセスが可能です。



31415 / TCP-mrelaydソフトウェアサービスの



操作github.com/thinkberg/jta/blob/master/tools/mrelayd.c



Mrelaydはtelnet-proxyと同様に機能します。接続アドレスを指定するには、「relay」メソッドが使用されます。これは、「relaytargethosttargetport」のような行として示されます。



次に例を示します。







この場合、ssh接続をプロキシするには、ProxyCommand(openssh)オプションまたはPuttyの接続オプションを使用できます。







結論:制御プロトコルを介して、内部ネットワークにアクセスすることが可能です。



この例は、その明らかな単純さにもかかわらず、企業における正しいプロキシサーバー構成の重要性を示しています。実際、そうでなければ、ネットワーク境界に脆弱なサービスがなく、リモート制御プロトコルのブルートフォース認証による攻撃のバリエーションを除外しても、内部デジタル資産への情報の影響が発生する可能性があります。



ケース2.可能性のある(実際には不可能な)ルーター



パイロットプロジェクトでは、インターネットからアクセスできるネットワーク機器のWebインターフェースに、運用監視センターの専門家の注目が集まりました。デフォルトのパスワードは機能しませんでしたが、幸運を祈って、管理者アカウントの6文字のパスワードを総当たり攻撃しようとしました。







図: 3.簡単にアクセスできるように見えます(デフォルトのアカウントを使用)。



試行は成功し、さらなる調査が可能になりました。インターフェースのリストでは、とりわけ「PPTPクライアント」タイプの「患者」が注目され、その設定では、企業の内部ネットワーク内のホストに接続するための資格情報が慎重に指定されていました。







見つかった資格情報を使用して接続が成功し、デバイスの外部IPアドレスが決定されました







外部IPスキャンは、暗号通貨マイニングに関連するポートの存在を示しました(これはシステムの侵害の可能性の兆候です)。さらに、ポート5000 / tcpでのサービスが注目を集めました。不運な5000 / tcpは、任意のスクリプトの起動を可能にする脆弱なサービスをホストします。



操作例:







図。 4.Webインターフェイスを介して起動された内部サービスにpingを実行します







。 5. / etc / shadowファイルの出力



これで十分と思われますが、さらなるチェックの一環として、79 / tcpで実行中の監視サービスCactiがデフォルトのアクセスパスワードを使用していることがわかりました。







図: 6.監視対象のデバイス



Cactiにアクセスするという事実により、ログの収集とSNMPコミュニティに関する情報を取得することもできました。







この例では、資格情報を使用して、によって採用されたパスワードポリシーに準拠していないシステムにアクセスするというすでに退屈な問題が再び発生します。会社。



ケース3.ペネトレーションテストとSOC



ますます多くの場合、SOC MTCテストのフレームワーク内の企業にとって、パイロットサービスプロジェクトとペネトレーションテスト形式の情報システムの定期的な監査を組み合わせるのは良い形式です。

最新のSOCには、SLAに従って、システムの最初の侵害の事実と、システムに足場を築き、特権を増やし、攻撃を仕掛ける潜在的な「攻撃者」のさらなる試みの両方を検出する機能があります。すでに企業ネットワーク内にあるホスト。この目的のために、顧客のWindows / Unixシステムおよびその他の利用可能な情報セキュリティシステムの監査ポリシーがそれに応じて構成されます。収集されたセキュリティイベントは、開発された相関ルールに基づいて処理されます。これにより、SOCアナリストは潜在的なインシデントを効果的に検出して対応できます。







図: 7.通常のペネトレーションテストの場合、SOCとの「対抗」の最初のラウンドは非常に迅速に終了します。



その後、譲歩として、請負業者の活動に目をつぶって、クライアントは、雇われたペネトレーションテストの専門家が仕事を続けることを提案します。これもまた、SOCの有効性を強調しています。インフラストラクチャのセキュリティをチェックするために会社に雇われたペンテスターの活動をすぐに計算します。 SOCを使用することの有効性と実現可能性の問題はすぐに消えます。



以下は、ある企業の簡単なケーススタディ







です。ご覧のとおり、ネットワークへの最初の接続の瞬間を含む、「攻撃者」のすべてのアクションが特定され、企業に提示されました。



アカウントの侵害、潜在的な攻撃者のIPアドレス、およびペネトレーションテストが顧客のホストに悪意のあるサービスをインストールしたという事実が特定されました。実際のインシデントが発生した場合、収集されたすべての情報は、適切に対応し、会社のデジタル資産を保護するのに十分すぎるほどです。



そして結論として



実際のSOCケースの説明は、他の何ものと同様に、企業がそのようなサービスを使用することの重要性と便宜性を理解することを可能にするはずであることに注意したいと思います。



セキュリティイベントの収集の適切な設定、それらの分析、会社に適した相関ルールの作成、実際のインシデントに投影されたサイバーインテリジェンスプラットフォームによる情報セキュリティイベントの強化-に接続することの将来の効率を理解および評価することを可能にしますSOCプロバイダー。



特定の情報セキュリティツールが私的な脅威に対する保護を提供することを真剣に理解する必要がありますが、それらは「国境で」起こっていることの完全な全体像を提供しません。 SOCは、熟練した人材、革新的なテクノロジー、構造化されたプロセスを組み合わせて、サイバー脅威から組織をリアルタイムで包括的に保護します。



たとえば、MTS SOCの一部として、接続されたソースシステムと相関ルールの最終リストについてお客様と合意します。保護された会社と一緒に、組織化された顧客提供のアクセストンネルを介してソースシステムに接続し、ソースシステムからログを転送し、ログを転送するために、それら、会社のログ収集サーバー、およびSOCシステム間に安全な接続を設定します会社のログ収集サーバーに、そしてそこからSOCシステムにリアルタイムで。







図: 8.顧客をSOCプロバイダーに接続するスキーム



SOCチームは、会社の従業員とともに、情報セキュリティインシデントの検出、ネットワークのプロファイリング、およびホストアクティビティのルールを調整して、誤検知を最小限に抑えます。追加の機能として、外部境界の脆弱性の制御と情報セキュリティインシデントの調査があります。



インシデントの調査結果に基づいて、実行された作業に関するレポートが作成されます。 SOCチームは、インシデントを分析し、ソースシステムと原因を確立することに加えて、将来同様のインシデントが発生する可能性を防止または軽減するための一連の技術的な推奨事項を作成します。



記事の著者:

MTS SOC Dmitry Berkovetsの上級専門家であり、#CloudMTSプロバイダーのAlexanderKarpuzikovの情報セキュリティ製品の責任者。



欠員



#CloudMTSチームに参加したい場合は、新しい欠員があります。



ネットワークエンジニア

UI / UXデザイナー

Golang開発

者DevOpsエンジニア



All Articles