背景: Vandalay Industries は輸出入の世界的リーダーとして、オンライン ビジネスを妨害しようとする多くの敵対者の標的となってきました。最近、Vandaly は Web サーバーに対する DDOS 攻撃を経験しています。
Web サーバーが DDOS 攻撃によってオフラインになっただけでなく、停止後はアップロードとダウンロードの速度にも大きな影響がありました。ネットワーク チームは、最新の DDOS 攻撃の前後に実行されたネットワーク速度の結果を提供しました。
スピードテストファイル
Splunk にアップロードされた「server_speedtest.csv」ファイルのスクリーンショット:
evalコマンドを使用して、アップロード速度とダウンロード速度の比率を示す、ratio というフィールドを作成します。ヒント: 比率を作成する形式は| eval new_field_name = 'fieldA' / 'fieldB'とおりです。 | eval new_field_name = 'fieldA' / 'fieldB'
アップロード速度とダウンロード速度の比率を生成するために Splunk で使用されるクエリ - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
このクエリからダウンロードとアップロードの比率を確認できます。
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioヒント: table コマンドの場合は、次の形式を使用します。テーブル フィールドA フィールドB フィールドC
アップロード速度とダウンロード速度の比率を生成するために Splunk で使用されるクエリ - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
上のスクリーンショットから、ダウンロードとアップロードが行われたときの合計イベント タイムラインがわかります。
上のスクリーンショットから、ダウンロードとアップロードが行われた時間と、このアクションを実行した送信元 IP アドレスがわかります。
上のスクリーンショットから、これらのダウンロード イベントとアップロード イベントが縦棒グラフ形式で視覚的に表現されていることがわかります。時間が下部に表示されるため、データがはるかに読みやすくなります。
上記のクエリでの結果に基づくと、2 月 23 日の午後 2 時 30 分頃にダウンロードとアップロードの速度が大幅に低下したことがわかります。以下のスクリーンショットでこれを確認できます。
午後 2 時 30 分にダウンロード数が 7.87 に低下したことがわかります。これは、前回の 109.16 メガビットから大幅に低下しました。したがって、この頃が攻撃が始まったと考えるのが妥当でしょう。
上のスクリーンショットから、ダウンロードメガビット数が 17.56 から 65.34 に増加し、大幅に増加していることがわかります。したがって、これは、システムが回復し始め、通常のネットワーク トラフィック フローに戻り始めた頃であると想定しても問題ありません。
上のスクリーンショットから、2 月 23 日午後 11 時 30 分頃、ダウンロード メガビット数が 78.34 から 123.91 に急増したことがわかります。これは、ネットワーク トラフィック フローが安定し、通常に戻った頃であると考えて間違いありません。
レポートのスクリーンショットと上記の質問への回答を送信してください。
背景: 攻撃の頻度が高いため、マネージャーはサーバー上の機密の顧客データが脆弱でないことを確認する必要があります。 Vandalay は Nessus 脆弱性スキャナーを使用しているため、過去 24 時間のスキャンを取得して、重大な脆弱性が存在するかどうかを確認しました。
Nessus の詳細については、次のリンクを参照してください: https://www.tenable.com/products/nessus
Nessus スキャン結果
Splunk にアップロードされた nessus スキャン結果のスクリーンショット:
10.11.36.23です。クエリでdest_ip="10.11.36.23"を使用します。
以下に示すように、これらのログで検索される重大度レベルには 5 種類があることに注意してください。
重大度レベルが「クリティカル」値である脆弱性をフィルタリングしたいと考えています。クエリではseverity="crtiical"を使用できます。
クエリ全体はsource="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"です。
このログ ファイルからの顧客データベース サーバーからの重大な脆弱性の数を表示するクエリ全体については、以下のスクリーンショットを参照してください。
宛先 IP が 10.11.36.23 (データベース サーバー) の場合、合計 49 件の重大な脆弱性が見つかりました。
[email protected]に電子メールで送信してください。上記のクエリから結果を生成した後、[名前を付けて保存] をクリックし、[アラート] をクリックしてアラートを作成します。
Nessus がデータベース サーバー上の脆弱性を検出するたびにアラートを生成するための詳細を入力します。名前、説明、その他の関連情報を入力します。
生成されたアラートを[email protected]に送信する電子メールの詳細を入力し、電子メールで送信するメッセージの詳細を入力します。
引き続きアラートの詳細を入力し、「保存」をクリックします。
保存すると、アラートを確認し、必要に応じて編集できるようになります。
レポートのスクリーンショットと、アラートが作成されたことを証明するスクリーンショットを送信してください。
背景: Vandalay サーバーでも、管理者アカウントに対するブルート フォース攻撃が発生しています。管理者は、ブルート フォース攻撃が再び発生した場合に SOC チームに通知するための監視を設定することを望んでいます。
管理者ログイン
Splunk にアップロードされた「Administrator_logs.csv」ファイルのスクリーンショット:
ヒント:
失敗したログインを見つけるには、名前フィールドを探します。
攻撃は数時間続いたことに注意してください。
ブルート フォース攻撃の兆候を探したいので、ログをドリルダウンして、アカウントがログオンに失敗した原因を調べたいと考えています。フィールド「name」に移動すると、ログに保持されている値が表示されます。この場合、「アカウントはログオンに失敗しました」というカウントが 1004 であることがわかります。これは、ブルート フォース攻撃が発生したことを示す良い証拠となります。スクリーンショットを参照してください:
これを検索に追加すると、これが発生したときのイベントの合計を確認できます。これにより、これらのイベントの大部分がいつ発生したかがわかり、これがいつ発生したかを示す良い指標となります。スクリーンショットを参照してください:
ご覧のとおり、2 月 21 日の午前 9 時頃に、「アカウントがログオンに失敗しました」というイベントがかなり急増しています。合計 1,004 件のイベントが発生し、午前 9 時にこれらのイベントが 124 件発生し、その後数時間で同様の数が発生したことがわかります。したがって、攻撃はこの頃、つまり 2020 年 2 月 21 日の午前 9 時頃に始まったと考えられます。
これらのイベントのタイムラインから、124 という数字がかなりの急増であることがわかります。このイベントが発生するまでの数時間では、不正ログインの最大数は約 23 件でした。これは正常な動作であると考えられます。スクリーンショットを参照してください:
これを念頭に置き、ブルート フォース攻撃が発生したときに約 124 ～ 135 回のログオン試行があったことを考慮すると、1 時間あたり約 40 回の不正なログオンがベースラインであると考えられます。 1 時間あたりの不正なログオンの範囲は次のようになります。
[email protected]に電子メールを送信します。このタイプのイベントのアラートを作成するには、次の手順を実行しました。
「名前を付けて保存」をクリックしてから「アラート」をクリックします。
アラートをトリガーするタイミング (1 時間あたり 25 回を超える試行) など、アラートの詳細を入力します。
アクションの詳細を入力します。この場合、 [email protected]に電子メールが送信されます。
アラートを保存すると、表示できるようになります。
これで、アカウントのログイン失敗に関するイベントが 25 件を超えたときにトリガーされるアラートが正常に作成されました。
ブルート フォースのタイミング、ベースライン、およびしきい値に関する質問への回答を送信します。さらに、アラートが作成されたことを証明するスクリーンショットを提供してください。
