1. はじめに
インターネットの普及と発展に伴い、さまざまな業界のビジネスやアプリケーションのインターネットへの依存度が高まっています。しかし、ネットワーク環境の不安定さと複雑さにより、さまざまな異常現象が発生する可能性が高くなります。このような異常現象は、業務の正常な運営を妨げ、ユーザーに迷惑をもたらし、さらには企業のイメージや利益にも影響を及ぼします。したがって、ネットワークの異常を迅速に診断して特定できるソリューションが必要です。
ネットワーク パケット キャプチャ分析テクノロジは、一般的に使用されるネットワーク デバッグ ツールであり、ネットワーク データ パケットをキャプチャし、詳細なデータ分析と統計情報を提供して、ユーザーがネットワークの問題を迅速に特定できるようにします。このうち、TCP RST メッセージは一般的なネットワーク異常現象であり、通常、接続がリセットまたは中断され、サービスの正常な動作が失敗することを示します。
この問題に対し、NetInsideフルトラフィックバックトラッキング解析ソリューション（以下、NetInsideフルトラフィック）は、プローブ装置のバイパスを介して指定リンクの全トラフィックデータを収集・蓄積し、ビジネス上重要な無人運用を実現します。システム、アプリケーション、およびネットワークのリンクは、7 時間×24 時間、全方位のトラフィック監視を実施し、重要なパフォーマンス指標のベースライン値をインテリジェントに学習し、ネットワークに異常が発生したり、ビジネスまたはネットワーク関連のステータスがしきい値に達したりすると、アクティブに監視します。警告を表示し、元のダウンロード後にリアルタイムでパッケージを分析し、デコードして問題の原因を迅速に特定できます。
NetInside は、人間中心のコンセプトで情報部門に合わせた新世代のフルトラフィック遡及分析システムを作成し、ネットワーク データ パケットを最大限に活用して、重要なリンク、主要な機器ポート、コア サービスをカバーする包括的な監視ビューを確立しました。ネットワーク部門のワークフローに合わせて整理し、さまざまなシーンに幅広く対応できる機能と運用を実現します。
サービス指向のフルフロー方式により、NetInside システムはビジネス アプリケーションのネットワーク インフラストラクチャのサポート能力を直接反映できるようになり、リアルタイムの障害診断、アラームのトリガー、およびイベント後のアプリケーション応答の詳細な分析が可能になります。システム全体により、ネットワーク障害の診断、新しいアプリケーションとサービスの導入が根本的に簡素化され、運用コストが削減され、障害位置を迅速に特定する方法が提供されます。ネットワーク攻撃の分析、異常の特定、ユーザー エクスペリエンス、アプリケーションのパフォーマンス、ネットワーク サービスの品質の評価と判断のための信頼できるデータ ベースを提供します。実際のネットワーク トラフィックに依存して、アプリケーションを迅速に検出して定義し、データの正確性と変更結果の検証機能を提供することで、ネットワーク トラフィックの視覚的な範囲と作業効率を大幅に向上させます。高度なデータ統計解析技術を活用したディスカバリやアラームなどの機能により、これまで煩雑で煩雑だった運用プロセスが大幅に簡略化されます。
2. RST の概要
TCP RST (リセット) は、TCP プロトコルの制御メッセージであり、TCP プロトコルのトランスポート層に位置し、TCP 接続を終了したり、不正な接続を拒否したりするために使用されます。TCP RST は通常、TCP 接続の一方の当事者によって送信され、TCP 接続を直ちに終了し、接続がリセットされたことをもう一方の当事者に通知します。
TCP RST メッセージは、TCP ヘッダーの制御ビット フィールド (制御ビット フィールド) にあり、このフィールドは 1 バイトを占め、その 6 番目のビット (RST) は TCP RST メッセージを表すために使用されます。以下は TCP ヘッダーの図です。
TCP ヘッダーの 13 バイト目の 6 ビット目 (つまり、制御ビット フィールド) が TCP RST メッセージを示していることがわかります。このビットが 1 に設定されている場合、TCP RST パケットの送信を意味します。
3. RSTのよくある原因と確認方法
TCP リセット パケットが生成される一般的な状況と理由には、次の 7 つの状況が含まれます。TCP リセット パケットは通常の TCP 接続に影響を与える可能性があるため、注意して使用する必要があることに注意してください。TCP リセット パケットを送信する必要があるかどうか不明な場合は、まずネットワーク管理者またはセキュリティ専門家に確認してください。
3.1. TCP 接続におけるファイアウォールまたはネットワーク デバイスの介入
ファイアウォールまたはネットワーク デバイスが TCP 接続を妨害すると、TCP リセット パケットを送信して接続を終了することがあります。
理由判断：ファイアウォールやネットワーク機器のログを確認し、TCP接続に干渉が発生していないか確認してください。TCP 接続が終了し、TCP リセット パケットを受信した場合、そのパケットはファイアウォールまたはネットワーク デバイスによって送信された可能性があります。
3.2. エンドポイントは接続が失敗したか異常であると判断します
TCP 接続のエンドポイントは、接続が失敗したか異常な状態にあると判断した場合、TCP リセット パケットを送信して接続を終了できます。
理由判断：TCPリセットパケットの有無は、TCP接続のログやネットワークパケットキャプチャツールで確認できます。ある相手が TCP リセット パケットを送信したことが判明した場合、その相手は接続が失敗したか、異常な状況が発生したと考えている可能性があります。
3.3. 攻撃者が TCP リセット パケットを送信する可能性がある
攻撃によっては、攻撃者が TCP リセット パケットを送信して接続を終了したり、受信者を騙したりする場合があります。
理由判断：異常なTCPリセットパケットの有無は、ネットワークパケットキャプチャツールを確認することで確認できます。TCPリセットパケットの送信元アドレスが不明、または通常の通信のIPアドレスと一致しないことが判明した場合、攻撃を受ける可能性があります。
3.4. ネットワークの混雑
ネットワークが混雑すると、ルーターまたはファイアウォールが一部のデータ パケットを破棄し、TCP 接続がタイムアウトまたは失敗する可能性があります。この時点で、接続の一方が TCP リセット パケットを送信して接続を終了することがあります。
理由判断：ネットワークパケットキャプチャツールを確認することで、データパケットの損失やTCP接続のタイムアウトが発生していないかを確認できます。ネットワークの輻輳時に TCP リセット パケットが送信されていることがわかった場合は、接続の一方の側で接続が失敗したと認識されている可能性があります。
3.5. プログラム異常
アプリケーションプログラムやオペレーティングシステムに異常が発生した場合、TCPコネクションが破損したり無効になったりする可能性があります。この時点で、接続の一方が TCP リセット パケットを送信して接続を終了することがあります。
原因判断：アプリケーションプログラムやOSのログを確認することで、異常な動作やエラー情報の有無を確認できます。特定の相手が TCP リセット パケットを送信したことが判明した場合、プログラム例外が原因である可能性があります。
3.6. タイムアウト
TCP 接続が長期間非アクティブになっている場合、その接続は停止していると見なされる場合があります。この時点で、接続の一方が TCP リセット パケットを送信して接続を終了することがあります。
原因判断：TCP接続やネットワークパケットキャプチャツールのログを確認することで、長時間接続が停止していたかどうかを確認できます。一方の当事者が TCP リセット パケットを送信しており、接続が長期間非アクティブであることが判明した場合は、タイムアウトが原因である可能性があります。
3.7. 不正な接続
一部の悪意のあるプログラムまたは攻撃者が違法な TCP 接続を確立しようとすると、接続の一方が TCP リセット パケットを送信して接続をブロックすることがあります。
理由判断：ネットワークパケットキャプチャツールを確認することで、不正なTCP接続要求や接続動作がないかを確認できます。当事者が TCP リセット パケットを送信したことが判明した場合、不正な接続要求が原因である可能性があります。
4. RST 事例分析
以下では、ユーザーが困難な問題を迅速に解決できるように、現場での 2 つの実際のケースを通じて RST の異常な動作を分析します。
4.1. 地方の公安事件
4.1.1. 背景
統合指揮プラットフォームには定期的にデータを本部に送信するスケジュールされたタスクがあり、本部は定期的にデータを地方交通警察分遣隊に送信します。市交通警察分遣隊は、予定されていた任務の実行が失敗していることを発見した。市交通警察分隊が本部に連絡したところ、市交通警察分隊は自身のネットワークをチェックする必要があるとのことで、2日前にアプリケーションサーバー上でスケジュールされたタスクのデータパケットをキャプチャしたところ、接続中にRSTになっていたことが判明したという。プロセス。どのリンクでRSTされたのかは確認できません。
この分析では、ビジネス環境に導入されている NetInside トラフィック分析システムを使用し、トラフィック分析システムを使用してリアルタイムおよび履歴の生トラフィックを提供します。この分析は、フォレンジックの設定、パフォーマンス分析、ネットワーク品質監視、および詳細なネットワーク分析のための統合されたスケジュールされたタスクのトラブルシューティングに焦点を当てています。
4.1.2. 環境の展開
市交通警察分隊と交通警察隊はプライベートネットワークと専用線で相互接続されており、市交通警察分隊のセキュリティドメイン統合コマンドプラットフォームのコアスイッチでは、トラフィックバイパスモードがNetInsideトラフィック分析システムにミラーリングされ、スケジュールされたタスクのトラフィックは NetInside を通じて収集および分析されます。
4.1.3. 分析時間
レポート分析の時間範囲は、2023-05-19 の日中の労働時間です。
4.1.4. 分析の目的
統合コマンド プラットフォームでスケジュールされたタスクの実行が失敗する理由を分析し、問題の根本原因を特定し、問題を解決するための対応策を講じます。
分析を通じて、ネットワーク接続の問題、システム障害、構成エラーなど、スケジュールされたタスクの実行の失敗につながる要因を特定できます。そうすることで、管理者がタイムリーに問題を発見して解決し、統合コマンド プラットフォームの正常な動作を保証できるようになります。ビジネス システムの健全性の問題がないことを見つけて確認します。
4.1.5. 詳細な分析
以下は、この失敗の詳細な分析です。
4.1.5.1. トラフィック送信には明らかな時間間隔がある
システムの二次データの配信傾向を分析すると、10.61.132.78（以下、78）とサーバ10.56.81.80（以下、80）の間には、明確な一定の送信間隔があることが分かります。これはおそらく、いくつかの未知の要因によって引き起こされます。
4.1.5.2. データ送信間隔現象の詳細な分析
以下の図に示すように、分析システムから対応するデータ パケットをダウンロードし、多数の RST パケットを見つけます。
上図のセッション情報（5タプルベースの対話）をランダムに確認すると、異常があることがわかります。
以下の図では、フレーム 19695 より前のすべてのパケットは通常の POST リクエスト操作ですが、フレーム 20756 と 20757 は明らかに前の接続とは関係がありません。
分析を続けます。
通常のデータ送信では、下図に示すように、80 から 78 に流れるデータ パケットの TTL は 119 です。
フレーム 20756 をもう一度見てみると、これも 80 から 78 までのパケットですが、TTL は 124 です。
同時に、この RST パッケージには、参照用のより多くのアプリケーション層情報も含まれています。
そして、フレーム 20757 は上記の RST メッセージの RST です。
分析の結果、約 43 分の時間範囲内で合計 1,846 件の同様の RST が発生しました。
4.1.5.3. 異常な RST がデータ送信に及ぼす影響
分析の結果、上記の RST が発生した後、78 は一定期間停滞し、再び 80 への TCP ハンドシェイク要求を開始し、POST データ操作を実行することがわかりました。
以下は、証拠としてランダムに表示されたいくつかのデータです。
異常な RST の後、78 は 8.19 秒待機してから、接続確立要求を 80 に送信します。
異常な RST の後、78 は 13.14 秒待機してから、接続確立要求を 80 に送信します。
異常な RST の後、78 は 34.34 秒待機してから、接続確立要求を 80 に送信します。
異常な RST の後、78 は 58.43 秒待機してから、接続確立要求を 80 に送信します。
それらを 1 つずつリストする必要はもうありません。
4.1.6. 分析の結論
78 と 80 の間でデータが送信される場合、未知のシステムまたはノードの多数の RST データ パケットが存在し、同時にデータ パケットにより 78 の要求に明らかな遅延が発生します。
4.1.7. 解決策の提案
異常データパケットにはアドレスとプロンプト情報が含まれているため、この情報に基づいて RST を送信している機器を特定できます。デバイスの位置は、TTL 情報に基づいて計算して特定することもできます。
異常な RST を送信するデバイスのポリシーを構成および最適化します。
4.1.8. 質問の検証
異常なRSTを解析したところ、端末制御ソフトから送信されたものであることが判明し、管理者は端末制御ソフトに対してRSTメッセージを送信しないように設定を行った。
NetInside トラフィック分析システムから変更されたポリシーをダウンロードした後、78 と 80 の間のデータ送信パケットを開いて表示すると、異常な RST パケットは表示されません。
同様に、下図に示すように、一定期間が経過すると、異常な RST は表示されなくなります。
端末制御ソフトウェアのポリシー設定が有効であることを示します。
4.1.9. 異常前後の効率比較
最後に、異常発生前後のトラフィック伝送特性を分析して比較します。
4.1.9.1. トラフィック伝送状況の比較
以下は、ポリシー調整前の 78 と 80 の間のデータ送信です。
以下は、ポリシー調整後の 78 と 80 の間のデータ送信です。
比較すると、ポリシーが調整された後、データ送信が大幅に高速化され、途中で明らかな間隔や空白の待機期間がなくなったことがわかります。
4.2. 電化局の事例
4.2.1. 背景
電化局からのユーザーからのフィードバックによると、最近ビデオ システムの使用中に頻繁に中断が発生しており、ユーザーのビデオ エクスペリエンスと作業効率に影響を与えています。
この問題を解決するために、NetInside トラフィック分析システムを電化局のコンピュータ ルームに導入し、トラフィック分析システムを使用してリアルタイムおよび履歴の生トラフィックを提供しました。電化局のビデオ システムの障害分析に焦点を当て、ビデオ システムが中断された具体的な原因を特定します。
4.2.2. 故障現象
ユーザーからのフィードバックによると、次の図に示すように、2023 年 2 月 8 日の 7:20 にビデオの中断が発生し、ビデオ システム管理端末を通じてビデオ トラフィックが切断されました。
4.2.3. 環境の展開
イントラネットの中央コンピュータ室のビデオ領域にある集約スイッチの位置では、関連するトラフィック バイパス モードが NetInside トラフィック分析システムにミラーリングされ、すべてのビデオ トラフィックが NetInside を通じて収集および分析されます。
4.2.4. 故障解析
この問題について、詳しく分析してみましょう。
4.2.4.1. 解析装置フロー収集図
オンサイトのネットワーク担当者とコミュニケーションをとり、実際のネットワーク構造を理解します。次は、ビデオ会議のトラフィック収集図です。
トラフィック収集図には主に、1 つのビデオ システム クライアント、1 つのビデオ システム サーバー、および 1 つのコア スイッチが含まれます。
対応する MAC アドレスがビデオ システム クライアントとビデオ システム サーバーの下に表示されます。
コア スイッチには、対応する 2 つのポートの MAC アドレスが表示されるようにマークが付けられています。
コア スイッチは、ミラーリングを通じてトラフィックをトラフィック分析システムに送信します。
4.2.4.2. 分析のアイデア
1. トラフィック分析システムで異常なデータ パケットを見つけて、データ パケットをダウンロードします。
2. データ パケットを開いて、異常な時点のデータ パケットの内容を確認します。
3. ビデオ データ パケットのプロトコルと詳細な内容を分析します。
4.2.4.3. 詳細な分析
パケットダウンロード
トラフィック分析システムによれば、異常なノードが迅速に発見され、データパッケージがダウンロードされます。
トラフィック分析
トラフィック分析システムはミラーリングされたトラフィックの重複を排除するため、分析システムは 10.21.106.11 によってコア スイッチに送信されたトラフィックと 10.21.30.106 によってコア スイッチに送信されたトラフィックのみを取得します。
通常の送信
データ パケット分析によると、クライアント 10.21.106.11 からサーバー 10.21.30.106 に送信された MAC アドレスは、Src: HuaweiTe_XX:XX:26 ———> dst: HuaweiTe_XX:XX:01 です。
データ パケット分析によると、サーバー 10.21.30.106 からクライアント 10.21.106.11 に送信された MAC アドレスは、Dst: HuaweiTe_XX:XX:0f <——— src: EdgeCore_XX:XX:a8 です。
パケット内の TTL は 64 です。
同時に、データ パケットは VLAN プロトコルを伝送し、VLAN ID は 59 です。
異常送信
データ パケットの分析によると、ビデオが中断された時点で RST が検出され、データ パケットの MAC アドレスが異常でした。サーバー 10.21.30.106 がクライアント 10.21.106.11 に送信した MAC アドレスは次のとおりでした。 HuaweiTe_XX:XX:01、dst:HuaweiTe_XX:XX: 26。通常は、src: EdgeCore_XX:XX:a8、dst: HuaweiTe_XX:XX:0f である必要があります。
パケット内の TTL は 127 です。
VLAN プロトコルが見つかりません。
上記の比較により、異常パケットのMACアドレスが異常、VLANプロトコルが存在しない、TTLホップ数が異常であることがわかりました。
4.2.5. 分析の結論
上記のシステム分析により、ビデオが中断されると、異常な RST データ パケットがネットワークに現れ、その結果、2 つの通信当事者間の TCP 接続が中断されることがわかりました。
4.2.6. 推奨事項
電化局のビデオデータの分析により、ネットワーク上に異常なメッセージがあることが判明し、ネットワークの実際の状況に基づいてさらなる分析を行うことが推奨されます。
5. まとめ
ネットワーク パケット キャプチャ分析テクノロジーに加えて、人工知能や機械学習に基づく異常検出テクノロジーなど、企業が異常を迅速に診断して特定するのに役立つ他の方法もあります。ビジネスデータを分析することで正常なビジネスパターンやルールを学習し、異常なデータを検出して対処する技術です。この方法には高精度と高効率という利点があり、企業が問題を迅速に発見して解決するのに役立ちます。
要約すると、ネットワーク異常はあらゆる業界が遭遇する可能性のある問題であり、迅速に診断して特定できるソリューションが必要です。ネットワーク パケット キャプチャ分析テクノロジは一般的に使用されるソリューションであり、ユーザーがネットワークの問題を迅速に特定するのに役立ちます。さらに、人工知能や機械学習に基づく異常検出テクノロジーなど、企業が異常を迅速に診断して特定できるようにする他の方法もあります。