月のアーカイブ2009年

産卵MS WordやExcelからCMDプロンプト

2009年10月15日

これは、古いトリックですが、私はまだ彼らは単にメニューからアイコンを削除して、スタート - >実行]オプションを無効にすることにより、コマンドプロンプトからユーザーをロックアウトされていると考える管理者の数を参照してください。この記事では私が誰かのリスクがプロンプトへのアクセスを達成する（完全になくすことはないが）ビジュアルアプリケーション（VBA）のための基本的なだけでなく、軽減する方法と、コマンドプロンプトを作成する方法を説明します。

VBAでコマンドプロンプトを作成する

このテクニックは、VBAをサポートする任意のアプリケーションで動作しますが、私は特に私の例ではMicrosoft Wordを使用するつもりです。ここでは、あなたがする必要があるものです。

Microsoft Wordを起動する
VBAエディタを起動するために"ALT - F11"を押してください
左側のペインで"ThisDocumentクラス"をダブルクリック
エディタウィンドウが表示されたら、テキストのタイプは第1図に示すように、
"F5"キーを押してください

図1：私たちの簡単なVBスクリプト

あなたは、コマンドプロンプトウィンドウがタスクバーに表示されるはずです。ここでは、コピー/貼り付けできるように、手順4で必要なコードのコピーは次のとおりです。

サブGetCMD（）
シェル"cmd.exeをcmd.exeを"
End Subの

産卵からコマンドプロンプトをVBAを防ぐ方法

コマンドプロンプトの実行で無効にできますグループポリシーエディタツール。手順は次のとおりです。

[スタート]ボタンをクリック - >ファイル名を指定して実行
"gpedit.mscと"（引用符なし）のタイプ
[ユーザーの構成]をクリック - >管理用テンプレート - >システム
"コマンドプロンプトへのアクセスを防ぐ"ためのリストを下へ検索し、それをダブルクリック

あなたに2つのオプションがあります。

コマンドプロンプトへのアクセスを有効化/無効化
はい/いいえコマンドプロンプトスクリプト処理を無効にしない

あなたの最初のオプションを無効にすると、cmd.exeに直接アクセスすることが防止されるが、スマートユーザーはバッチファイルを介してそれに得ることができます。スクリプトのアクセスを防止するために、同様に二つ目のオプションを無効にする必要があります。しかし、これはすべてのスクリプトを防止し、多くの環境では大混乱を再生することができます。また、これらの設定の両方が同様に管理者アカウントに適用されます。これにより、管理者とトラブルシューティングがはるかに困難になります。

両方のオプションが無効になっている環境で、ユーザーは依然としてcommand.comの代わりにcmd.exeを使用してこれらの設定を回避することができます。これを修正するには、ユーザーのアクセス許可を通じてcommand.comへのアクセスを制限する必要があります。あなたはまだいくつかの古い16ビットアプリケーションを実行している場合は、この修正は、それらを中断します。

これらの手順のすべてが完全にしかし問題は解決しない。彼らはデバッグで何をしているかを知っているユーザーは、単に別の場所にcmd.exeをコピーし、偽のコマンドを実行するためにそれを使用するときにプロンプトが達成されるようにそれを変更することができます。だから我々はまた、"DEBUG.EXEを"削除する必要があります。

その場合でも、経験豊富なプログラマは、上記のセキュリティチェックのすべてを回避するための実行可能ファイルを作成することができます。だから我々は同様にドライブにコピーまたは書き込みをすべて機能を削除する必要があります。我々はその時点でかなり無駄なコンピュータを持っているは言うまでもない。

Execの概要

誰かスマートなシステムへのアクセスを持っている場合、それはあなたがコマンドラインになってからの彼または彼女を防止できるようになる疑問です。グループポリシーエディタは、ほとんど確かにそれはより困難なものにすることができますが、ツールは、単に攻撃のリスクを低減します。あなたは完全に深刻なシステムの操作と有用性を妨げることなく、リスクを排除することはできません。

コメントなし »

で掲示される4予告、 Windowsセキュリティ

タグ： Windowsのコマンドライン Windowsセキュリティウィンドウのヒント

"標的型攻撃への対処"の話のPDF

2009年10月14日

今後数週間にわたって、私は場所の数でこの講演を与えることでしょう。出席とスライドのPDF版を要求された人のために、ここに私が約束したリンクです：保護-に対する標的-攻撃- R2

3コメント »

で掲示される3 - errに、一般的なセキュリティ

タグ：アプリケーションのホワイトリストのマルウェア

tsharkのチャレンジ-ユーバーオタク回答

2009年10月13日

私の前回の記事で私は質問であなたを残し：私たちは攻撃者とWebサーバ間のステートフルインスペクションファイアウォールを配置する場合我々はtsharkのとデコードのファイルで見てきたものを考えると、どのような影響を与えることは（もしあれば）があるでしょう？言い換えれば、攻撃者はパケットスニファを実行している場合、彼らはまだ、Webサーバーが404エラーを漏れ参照してくださいだろうか？

そして答えは...

多分。

すべてのステートフルインスペクション型のファイアウォールは等しいわけではありません。いくつかは、若干異なって他のものよりパケットを処理します。例えば、いくつかは（チェックポイント、Juniper Netscreenおよび他のような）ルールは、新しい状態テーブルエントリを生成可能にするために、非SYNパケットをしましょう。いくつか（シスコ、Netfilterとその他）でのみ、適切なセッションの確立（TCPの3パケットのハンドシェイクを確認する必要がある）を持つ状態のテーブルを生成します。

NIPSは、インターネット上の攻撃者に有効なリセットパケットを送信。上記のファイアウォールのそれぞれには、リセットパケットを参照してくださいと、状態テーブルからそのエントリを削除します。 Webサーバーがしかし、通信を継続する場合は、ファイアウォールの最初のセットのみでは、パケットが攻撃者に漏れるせることだ。ファイアウォールの2番目のセットは、単純にトラフィックをドロップします。我々が代わりにドロップルールの拒否ルールでそれらを設定すれば実際に、彼らはこのように生理学研究所で作成された問題を解決してWebサーバー上でセッションを終了してしまいます。

なぜ一部のベンダーは、確認応答パケットが新しい状態テーブルエントリを生成できますか？正当なセッションは、常にSYNパケットで開始する予定ですので、これはビットの直感だ。これは良い機能的な意味をなす2つの理由があります。

ファイアウォールルールを更新すると、アクティブなセッションを強制終了しない
アクティブ - アクティブセットアップでは、状態テーブルの同期をする前にトラフィックを渡します。

もちろん、我々は、セキュリティのコストで機能性を増加させました。残念ながらそれは典型的なトレードオフです。

あなたがこの挑戦を楽しんでいた願っています。興味がある場合は、私は将来、よりを掲載する予定です。

2コメント »

で掲示される2 -警告、ネットワークセキュリティ、パケットの復号化

タグ：ファイアウォールネットワークセキュリティパケットの復号化

tsharkのチャレンジ-決勝回答

2009年10月9日

私の最後のポストでは、トレースファイルは、単一の砥石で研がれたネットワークベースの侵入防止システムは、HTTPクライアントからWebサーバーへの攻撃を阻止しようとしていたセッションが含まれていることを決定していた。私たちは、クライアントのデータ要求はかなり怪しまれ、セッション中に送信するリセットパケットを担当したサードパーティのシステムを（NIPS）を証明しなかったと結論付けた。

この記事では、我々はまだ二つの疑問に答える必要があります。

攻撃が成功するか？
なぜ、Webサーバーは、NIPSが送信したTCPリセットパケットを無視するのですか？

攻撃が成功するか？

攻撃者はファイル"startstop.htmlが""管理"ディレクトリ内に配置されたかどうかを識別するために探していました。リセットパケットが送信された後、攻撃者に送信されるパケットの一つを見てみましょう：

tsharkの- N - R challenge1.cap - X frame.number == 11
11 0.711825 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
0000 00 50 8B EA 20 AB 00 B0 D0 20 7099 E3 08 00 45 00。P.。 ...。 } ... E.
0010 01 A7 37 47 40 00 40 06 73 8B 0C 21 F7 04 94 4E .. 7G @。@。秒！... N
0020 F7 0A 00 50 69 2A、3A 88 39 CD 6A 97 B9 4C 80 19 ...円周率*：。。0.9 J. L.。
0030 19 20 8C D4 00 00 01 01 08 0A 3D 76 0E D3 00 EC。 ... ... ..=ています...。
0040 48 4B 48 54 54 50 2F 31 2E 31 20 34 30 34 20 4E HKHTTP/1.1 404 N
0050 6F 74 20 46 6F 75 6E 64 0D 0A 44 61 74 65 3A 20 otが見つかりません..日付：
0060 54 75 65 2C 20 32 35 20 4A 75 6E 20 32 30 30 32火、2002年6月25日
0070 20 30 30 3A 33 34 3A 35 38 20 47 4D 54 0D 0A 53 0時34分58秒GMT .. S
0080 65 72 76 65 72 3A 20 41 70 61 63 68 65 0D 0A 43 erver：Apacheの.. C
0090 6F 6E 6E 65 63 74 69 6F 6E 3A 65 73 20 63 6C 6F onnection：クローズ
6F 00A0 0D 0A 43 6E 74 65 6E 74 2D 54 79 70 65 3A 20 ..のContent - Type：
00b0 74 65 78 74 2F 68 74 6D 6C 3B 20 63 68 61 72 73テキスト/ html;文字
00c0 65 74 3D 69 73 6fは2D 38 38 35 39 2D 31 0D 0A 0Dら= ISO - 8859 - 1 ...
00d0 0A 3C 21 44 4F 43 54 59 50 45 20 48 54 4D 4C 20。<！DOCTYPE HTML
00e0から50 55 42 4C 49 43 20 22 2D 2F 2F 49 45 54 46 2F PUBLIC" - / / IETF /
00f0 2F 44 54 44 20 48 54 4D 4C 20 32 2E 30 2F 2F 45 / DTD HTML 2.0 / / E
0100 4E 22 3E 0A 3C 48 54 4D 4C 3E 3C 48 45 41 44 3E N">。<HTML> <HEAD>
0110 0A 3C 54 49 54 4C 45 3E 34 30 34 20 4E 6F 74 20。<TITLE> 404ない
75 0120 46 6F 6E 64 3C 2F 54 49 54 4C 45 3E 0A 3C 2fは</ TITLE> </が見つかりました
0130 48 45 41 44 3E 3C 42 4F 44 59 3E 0A 3C 48 31 3E HEAD> <BODY>。<H1>
0140 4E 6F 74 20 46 6F 75 6E 64 3C 2F 48 31 3E 0A 54が見つかりません</ H1>。T
彼がURLを要求した0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4C
0160 20 2F 63 66 69 64 65 2F 41 64 6D 69 6E 69 73 74 / CFIDE / Administ
0170 72 61 74 6F 72 2F 73 74 61 72 74 73 74 6F 70 2E rator / startstop。
0180 68 74 6D 6C 20 77 61 73 20 6E 6F 74 20 66 6F 75 htmlは酔ってはなかった
このサーブで0190 6E 64 20 6F 6E 20 74 68 69 73 20 73 65 72 76 65 ND
01A0 72 2E 3C 50 3E 0A 3C 2F 42 4F 44 59 3E 3C 2F 48 R.の<P>。</ BODY> </ H
01b0 54 4D 4C 3E 0A 00 03 00 07 TML> ... ..

攻撃者の質問に対する答えができるように、"サーバーにあるファイルですが、リセットパケットが発行された後、サーバーがクライアントに設定されるすべてのパケットに応答します。今問題になる、攻撃者はこの情報を参照してくださいか？

リセットパケットが攻撃者に送信されたときに、リセットはTCPのセッションを殺しているはずです。これは、このデータが到着したとき、受信ポート（TCP/26922）が閉状態にされている必要があることを意味します。これは実際には真されていた、私はTCP/26922が現在閉じていることを告げて、攻撃者のシステムから返ってくるACK /リセットを参照してくださいことを期待する。我々はそれらのパケットを見ることはない。

なぜリモートポートの近くではないのですか？リセットパケットは有効ですので、セッションを殺しているはずです。経験豊富な攻撃者が攻撃を実行しながらバックグラウンドでパケットスニファを実行する予定です。それは、攻撃者は何が起こっているのかを考え出したと単純にすべての着信リセットパケットをフィルタリングする彼らの攻撃のシステム上のファイアウォールルールを作成しているということはいえます。これは機能し続ける彼らのツールを許されているでしょう。であっても、ファイアウォールなしでそれらのパケットスニファは、彼らが求める答えが含まれているというフィルタ。だから、非常に良い機会攻撃者が事実にもかかわらず、NIPSは、ネットワークを保護して、我々はに対して脆弱であるかを考え出したているがあります。

なぜ、Webサーバーがリセットパケットを無視するのですか？

私たちの最後の疑問は、なぜWebサーバーがNIPSによって送信されるリセットパケットを無視するかです。これには二つの問題を引き起こしている。

攻撃者が望む情報は漏れを続けている
攻撃者は複数のファイルのプローブを行う場合、それらはWebサーバー上のセッションテーブルをいっぱいに可能性が

それは実際には正常に接続の片側を殺すことでDoS攻撃を発生させNIPSとなるため、2番目の項目は恐ろしいの一種です。我々は、ベンダーのギアパッチを適用して最新の状態であったとしても、だから我々はWebサーバを殺してしまわないかのためにお金を支払った。私はDoS攻撃自分自身にお金を使うときにうわあ、私はそれを嫌う。

のは、それらのリセットパケットをもう一度見てみましょう：

tsharkの- N - R challenge1.cap frame.number == 6またはframe.number == 7
6 0.031319 12.33.247.4 - > 148.78.247.10 TCP 80> 26922 [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は
7 0.031385 148.78.247.10 - > 12.33.247.4 TCP [TCPは、失われたセグメントをACK応答] 26922> 80 [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は

tsharkのは、パケット7が失われたセグメントである私達に語っていることに注意してください。言い換えれば、tsharkのはTCPのシーケンス番号は、ホストが予期しているウィンドウ内にないことを告げています。シーケンスを見て、確認応答番号は、理由を説明します。値は、パケット6のものと同じです。あなたはパケット6および7はまた、同じIP ID値（45298）を持っていた最後のポストから覚えているかもしれません。

だから、ここには何が起こったかが表示されます。

クライアントは、弊社のWebサーバにHTTPの攻撃を送信
NIPSは、攻撃を検出
NIPSは、セッションを殺すために攻撃者に有効なTCPリセットを送信
NIPSは、パケット内の送信元と宛先のIPアドレスをスワップCRCを再計算して、Webサーバーに同じリセットを送信
それが許容できるシーケンス番号が含まれていないため、Webサーバはリセットを無視

あなたは"どのようにベンダーがこれを逃すのか？"、自問している可能性があります。攻撃ツールは、それらに脆弱なファイルを示していないので、すべてがOKに動いていたと仮定、私の最高の推測では、ベンダーがいくつかシミュレートされた攻撃を実行したということです。言い換えれば、ワイヤ上でネットワークを保護するための製品を作成したベンダーは、自社の製品が実際に回線上に何をやっていたを見にしなくてもすむ。 Hummm ...

ボーナス質問

OK、このいずれかで楽しんでいる場合、ここでは、決定的に秘密のピラミッドの頂点に基づいて超オタクのステータスを証明するように答えるのボーナス質問があります：

我々は、このサブネットと攻撃者との間のステートフルインスペクションファイアウォールを配置すると仮定します。攻撃者は依然として、パケットスニッファと回答を見ることができるでしょう？

私は来週の答えを投稿します。

コメントなし »

で掲示される2 -警告、パケットデコード

タグ：パケットデコード

tsharkのチャレンジ-ヒント4

2009年10月8日

私の最後のポストでは、クライアントシステムはおそらく脆弱なファイルであることが知られているためにプローブするツールのいくつかの種類を実行していたことが確認された。我々はまだだけでなく、サーバがそれらを無視していた理由として、しかし、リセットパケットを説明する必要があります。

今私たちも、このパケットキャプチャは、2つのエンドポイントとの関係で撮影されたか分からない。私は、TTLの情報をプリントアウトするために"- Tフィールドは"スイッチを使用してtsharkのを実行するつもりです。 TTLを分析することにより、我々はクライアントとサーバの関係で盗聴されている場所を決定することができるはずです。私はまた、パケットの順序で異常がないかどうかを確認するためにIP IDをプリントアウトするつもりです。

ここにコマンドと出力は次のとおりです。

tsharkの- R challenge1.cap - Tフィールドの- e frame.number - E ip.src - E tcp.srcport - E ip.ttl - E ip.id
1 148.78.247.10 26922 49 0x2a6b
2 12.33.247.4 80 64 0 × 0000
3 148.78.247.10 26922 49 0x2a95
4 148.78.247.10 26922 49 0x2a96
5 12.33.247.4 80 64 0 × 3743
6 12.33.247.4 80 255 0xb0f2
7 148.78.247.10 26922 255 0xb0f2
8 12.33.247.4 80 64 0 × 3744
9 12.33.247.4 80 64 0 × 3745
10 12.33.247.4 80 64 0 × 3746
11 12.33.247.4 80 64 0 × 3747
12 12.33.247.4 80 64 0 × 3748
13 12.33.247.4 80 64 0 × 3749
14 12.33.247.4 80 64 0x374a
15 12.33.247.4 80 64 0x374b
16 0x374c 12.33.247.4 80 64
0x374d 17 12.33.247.4 80 64

148.78.247.10はクライアントです。それがセッションを開始し、その上部のソースポートを使用して通信するので、我々はそれを知っている。 12.33.247.10は、ポート80から通信して私たちのHTTPサーバです。

パケット1で我々は、クライアントが49のTTLを持っている参照してください。知られているオペレーティングシステムのための最も近い開始TTLマッチは64ですので、これはクライアントがLinux、UNIX、または徒歩15ホップに座ってMacのシステムである私達に伝えます。パケット2では、64のTTL値を持つ複数のサーバーを参照してくださいので、ローカルネットワーク上に座って、前述のオペレーティングシステムのいずれかでなければなりません。そう、我々はサーバーと同じコリジョンドメイン上にありますが、クライアントから車で15ホップに座って。

問題は、しかしながらあります。パケット6と7を見てください。ここでは、両方のシステムのTTLが255に変更してください。 OSは、セッション中のTTLを変更することはありませんので、これは非常に疑わしい見えます。さらに、我々はすでにクライアントが私たちから15ホップに座っていることが判明。 255は、TTLフィールドは、単一バイト（IPヘッダのバイト8）であるとして可能な最大TTL値です。送信元IPアドレスがリモートクライアントであると主張するので、にもかかわらず、パケットがどこがローカルネットワークから発信されていること方法はありません。パケットが1つまたは複数のルータを越えていた場合、TTLの値は下がるだろう。

IP ID情報は、右のいずれかを見ていません。クライアントからの最初の三つのパケットでは、IP ID値0x2a6b（10859）、0x2a95（10901）、および0x2a96（10902）を参照してください。これは、クライアントはおそらく1増分IP IDを使用しているを教えてくれる、私達はちょうど最初に送信されると番目のパケット間のパケットの42を見ていない。我々はクライアントから参照して、次のIP IDが0xb0f2（45298）です。 [OK]を、我々は34000パケット以上逃した場合を除き、このIP IDがジャイブしません。

上記の分析が唯一の理論的なそれが一貫性のないTTLの値がなかったらなる注意してください。を見て3つだけのパケットで、我々は正確にIP IDのインクリメントを識別することはできません。それはIP IDのインクリメントは完全にランダムであり、システムは単に1つの権利他の後に、2つの増分IP IDを割り当てるために起こったこと、また可能性が、非常に可能性はほとんどありません。それでも、一緒にTTLおよびIP ID情報を組み合わせると、彼らはこの最後のパケットが同じシステムから発信されていることができなかったことを示している。

私たちは、で動作するようにサーバからのより多くのIP IDのデータを持っているので、ここではその見てみましょう。 IDは、次のとおりです。

0（0）
0 × 3743（14147）
0xb0f2（45298）
0 × 3744（14148）
0 × 3745（14149）
0 × 3746（14150）
0 × 3747（14151）
0 × 3748（14152）
0 × 3749（14153）
0x374a（14154）
0x374b（14155）
0x374c（14156）
0x374d（14157）

トレース内のパケット6からである第三記載されているIPのID、を見てみましょう。他のIP IDのすべての増分1であるが、このIP IDが属していないことに注意してください。実際、我々は、それは+1でIP IDのサーバをインクリメントすることと、このパケットがサーバから発信された方法がないことを示すことができる。

ヒュム。奇妙なのリセットに、これらの疑わしいパケットのラインアップは我々が見たのだろうか。

tsharkの- R challenge1.cap - Tフィールドの- e frame.number - E ip.src - E tcp.srcport - E ip.ttl - E ip.id - E tcp.flags.reset
1 148.78.247.10 26922 49 0x2a6b 0
2 12.33.247.4 80 64 0 × 0000 0
3 148.78.247.10 26922 49 0x2a95 0
4 148.78.247.10 26922 49 0x2a96 0
5 12.33.247.4 80 64 0 × 3743 0
6 12.33.247.4 80 255 0xb0f2 1
7 148.78.247.10 26922 255 0xb0f2 1
8 12.33.247.4 80 64 0 × 3744 0
9 12.33.247.4 80 64 0 × 3745 0
10 12.33.247.4 80 64 0 × 3746 0
11 12.33.247.4 80 64 0 × 3747 0
12 12.33.247.4 80 64 0 × 3748 0
13 12.33.247.4 80 64 0 × 3749 0
0x374a 0 14 12.33.247.4 80 64
15 12.33.247.4 80 64 0x374b 0
16 12.33.247.4 80 64 0x374c 0
17 12.33.247.4 80 64 0x374d 0

ヘクタールああ！我々は奇妙なTTLとIP ID値を持つパケットを見るのであれば、これらは、セッション中に送信される奇妙なリセットパケットでした。

それは、リセットパケットを送信するために、会話に飛び込むているいくつかの他社システムのように僕には見える。これらの奇妙なパケットが255のTTLを持っているので、我々は、それは我々が盗聴されている場所と同じコリジョンドメイン上にある必要があります知っている。それは、同じコリジョンドメイン上にあるので、イーサネットのヘッダ情報を参考にしてください。

tsharkの- R challenge1.cap - Tフィールドの- e frame.number - E ETH - E tcp.flags.reset
1イーサネットII、Srcの：HewlettP_ea：20：AB（〇時50分08秒B：EA：20：ab）は、DST：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）0
2イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07分D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
3イーサネットII、Srcの：HewlettP_ea：20：AB（〇時50分08秒B：EA：20：ab）は、DST：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）0
4イーサネットII、Srcの：HewlettP_ea：20：AB（〇時50分08秒B：EA：20：ab）は、DST：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）0
5イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07分D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
6イーサネットII、Srcの：D - Link_8f：E0：0C（午前0時50：BA：8F：E0：0C）、DST：HewlettP_ea：20：AB（0時50分08秒B：EA：20：AB）1
7イーサネットII、Srcの：D - Link_8f：E0：0C（午前0時50：BA：8F：E0：0C）、DST：DellComp_20：7D：E3（00：B0：D0：20：07 D：E3）1
8イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07分D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
9イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07分D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
10イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
11イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
12イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
13イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
14イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
15イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
16イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0
17イーサネットII、Srcの：DellComp_20：7D：E3（00：B0：D0：20時07 D：E3）、DST：HewlettP_ea：20：AB（午後十二時50分08秒B：EA：20：AB）0

したがって、クライアントがインターネットから入ってくると、それはルータやファイアウォールのどちらかとして動作するHPシステムを通過する。当社のウェブサーバは、Dellのハードウェア上で実行されています。私たちがリセットされます（パケット6および7）の両方のD - LinkのNICを使用して同じシステムによって生成されていることに注意してください。

では、なぜD - Linkシステムでは、セッションを強制終了しようとするのですか？クライアントが疑わしいファイルの要求を送信した直後に発生していました。それは、D - Linkシステムでは、実際には単一の砥石で研がれた侵入防御システム（IPS）であるように僕には見える。攻撃が検出されると、IPSは接続の両端にリセットパケットを送信することにより、攻撃を防止しようとします。

しかし、我々はまだいくつかの疑問を持っている。攻撃が成功し、なぜサーバーはセッションを殺すためにIPSの試みを無視するように見えるのですか？

調べるために次のエピソードへの電源を入れます。

コメントなし »

で掲示される2 -警告、パケットデコード

タグ：パケットデコード

tsharkのチャレンジ-ヒント3

2009年10月7日

これは私が先週発行されたtsharkのデコード課題へのヒント第三のセットです。次の場所からデコードファイルのコピーをつかむことができる挑戦のページ。

私の最後のポストでは、いくつかの矛盾を発見TCPストリームです。のは、何か場違いに見えるかどうかを確認するためにペイロードを詳しく見てみましょう。私が使うことになるコマンドは次のとおりです。

tsharkの- R challenge1.cap - X |以下

あなたがWindows上で実行している場合は、"more"コマンドで"少ない"コマンドを置き換えます。

"- x"のスイッチは、ヘッダーの概要とともに、各パケットのペイロードを印刷するtsharkの原因となります。パケット4にページダウンすると以下の内容が出力されます。

4 0.030787 148.78.247.10 - > 12.33.247.4 HTTP GET / CFIDE /管理者/ startstop.html HTTP/1.0
0000 00 B0 D0 20 7099 E3 00 50 8B EA 20 AB 08 00 45 00 ...} .. P.。 ... E.
0010 01 11 2A 96 00 00 31 06 CF D2 94 4E F7 0A 0C 21 ..* ... 1 ...。N ...！
0020 F7 04 69 2A 00 50 6A 97 B8 6F 3A 88 39 CD 80 18 ..私*. Pjの.. O：0.9 ...
0030 FF FF 42 FC 00 00 01 01 08 0A 00 EC 48 4bは3D 76 .. B ... ... ... HK = V
0040 0E 8B 47 45 54 20 2F 63 66 69 64 65 2F 41 64 6D .. / CFIDE / ADMのGET
0050 69 6E 69 73 74 72 61 74 6F 72 2F 73 74 61 72 74 inistrator /スタート
0060 73 74 6F 70 2E 68 74 6D 6C 20 48 54 54 50 2F 31 stop.html HTTP / 1
0070 2E 74 73 30 0D 0A 48 6F 3A 20 31 32 2E 33 33 2E 0.0 ..ホスト：12.33。
0080 32 34 37 2E 34 0D 0A 55 73 65 72 2D 41 67 65 6E 247.4 ..ユーザアジャン
0090 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 5BのT：Mozilla/5.0 [
00A0 65 6E 20 28 57 69 6E 39 35 3B 20 55 29 0D 0A EN]（Win95の、U）5D ..
00b0 52 65 66 65 72 65 72 3A 20 68 74 74 70 3A 2F 2FのReferer：http://の
00c0 31 32 2E 33 33 2E 32 34 37 2E 34 2F 0D 0A 58 2D 12.33.247.4/..X-
00d0 46 6F 72 77 61 72 64 65 64 2D 46 6F 72 3A 20の31転送 - の場合：1
00e0から34 38 2E 36 34 2E 31 34 37 2E 31 36 38 0D 0A 43 48.64.147.168 .. C
00f0 61 63 68 65 2D 43 6F 6E 74 72 6F 6C 3A 20 6D 61痛み - コントロール：MA
0100 78 2D 73 74 61 6C 65 3D 30 0D 0A 50 72 61 67 6D X -陳腐= 0 .. Pragm
0110 61 3A 20 6E 6F 2D 63 61 63 68 65 0D 0A 0D 0A CE：no - cacheに... ..
0120 F8 43 76。Cv値

これは、不審なファイル名に"GET"要求です。右見ていないこのペイロードのフィールドがいくつかあります。 "HOST："フィールドは、クライアントがアクセスしようとしたWebサーバーを識別してください。これは、常に"www.fubar.com"または類似のように、完全修飾ドメイン名でなければなりません。サーバのIPアドレスがリストされているという事実は、Webブラウザがこのセッションを生成するために使用されていないと言われます。

同じ物理サーバー上で複数のWebサイトをホストすることが可能です。サーバはこのホストのフィールドを分析することによってアクセスする特定のサイトを割り出し。 Webブラウザがこのルールに従っていない場合、同じ物理ボックス上でホストされている複数のサイトとのコロケーションサーバーでも機能することはない。だから、これはクライアントが実際のWebサーバープロセスではなく、システム上でホストされるWebサイトの後に起こっていると言われます。

"ユーザーエージェント："フィールドには、同様に違和感があると思います。それはクライアントがWindows 95を実行していることは可能ですが、それはほとんどありません。

Refererフィールドは、同様に間違っています。これは私たちに彼らがこのページに指示されたときにクライアントがアクセスしていた完全なURIを表示する必要があります。それは、完全修飾ドメイン名だけでなく、このページにそれらを参照されるサイト上で正確なページを含める必要があります。リファラが検索エンジンの場合は実際には、フィールドでも、私たちのサイトに指示されたときに、検索パラメータが使用されたものが含まれます。 IPアドレスを一覧表示すると、完全に間違っています。

このペイロードの情報のいずれかの最後の興味深い部分があります。 "のX - Forwarded - For："フィールドは、IPヘッダーのソースIPアドレスがこのフィールドに書かれているIPアドレスのためのHTTPプロキシとして動作していることを告げ。攻撃者が公共のプロキシサーバの彼らの攻撃をバウンスするのは、珍しいことではありません。この方法では、Webサーバのアクセスログで攻撃を検出する場合は、送信元IPアドレスとして敵対的な実体であると思われるのX - Forwarded - Forフィールドは表示されません。

そこで、疑わしい値を持つパケットを使用して、自分のアイデンティティを隠すためにしようとしているIPから、疑わしいファイルの要求を持っている。我々は、これはおそらく脆弱なファイルであることが知られているを探して、攻撃者である私達に伝えるために、IDSは必要ありません。

今17を介してパケット8を見てみましょう。それぞれがクライアント"ごめんなさい、私はその脆弱なファイルを実行していないに指示しようとするサーバです。あなたが私を侵害する場合404エラーメッセージを経由して、"別の脆弱なファイルを試してみてください。

ので、流れは次のようになります：

クライアントは、潜在的に脆弱なファイルのためのプローブを送信します。
サーバは接続をリセット
クライアントは接続をリセット
サーバは、継続的にそのファイルを持っていないクライアントに伝えます

では、なぜリセットされ、その理由は、それらをサーバが無視するのですか？調べるために明日のチューニング...

コメントなし »

で掲示される3 - errに、パケットの復号化

タグ：パケットデコード

tsharkのチャレンジ- Hints2

2009年10月6日

昨日は、デコードファイルの初期見てみるの続きです。我々は、複数の再送が続く404エラーを見たので、最初のパスは、私たちの頭を悩ま残しました。このヒントでは、少し深くトレースについて詳しく説明。

のが我々の最初のデコードに戻って、パケット単位で何が起こったかに従ってみましょう：

tsharkの- R challenge1.cap
1 0.000000 148.78.247.10 - > 12.33.247.4 TCP 26922>のhttp [SYN]のSeq = 0勝利= 65535 Len関数= 0 MSS = 1460 = 0 TSV = 15485003 TSER = 0であった
2 0.000080 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [SYN、ACK] SEQ = 0 ACK = 1勝= 5792 Len関数= 0 MSS = 1460 TSV = 1031147147 TSER = 15485003 = 0、WAS
3 0.029341 148.78.247.10 - > 12.33.247.4 TCP 26922>のhttp [ACK] SEQ = 1 ACK = 1勝= 65535 Len関数= 0 TSV = 15485003 TSER = 1031147147
4 0.030787 148.78.247.10 - > 12.33.247.4 HTTP GET / CFIDE /管理者/ startstop.html HTTP/1.0
5 0.030841 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [ACK] SEQ = 1 ACK = 222優勝= 6432 Len関数= 0 TSV = 1031147150 TSER = 15485003
6 0.031319 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は
7 0.031385 148.78.247.10 - > 12.33.247.4 TCP [TCPは、失われたセグメントをACK応答] 26922>のhttp [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は
8 0.031610 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
9 0.031664 12.33.247.4 - 見つかりませんでした> 148.78.247.10 HTTP HTTP/1.1 404（テキスト/ HTML）
10 0.251838 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
11 0.711825 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
12 1.631812 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
13 3.471773 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
14 7.153143 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
15 14.511594 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
16 29.231324 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
17 58.670815 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]

私たちの最初の三つのパケットはTCPハンドシェイクです。この部分はかなり正常に見えます。パケット4では、我々は、クライアントがファイルのための"GET"リクエストを送信してください。このファイルの要求は私として疑わしい打つ。 "管理"ディレクトリの"startstop.html"という名前のファイルには、まさに我々が広く一般にまで提供したいというファイルとは思えません。我々は、このメモを作成し、後でそれに戻ってくる。

パケット5では、我々は、サーバがデータの要求を確認してください。このパケットの後、物事は少し奇妙になる。パケット6では、我々は、サーバが接続を殺すために、リセットパケットを送信してください。これは、サーバーが何かがセッションに何か問題があったし、それが回復不能であることを感じていることを示しています。それが信頼できると非常に難しいしようとするので、これはTCPのための非常に奇妙な動作です。それは通常、それは何かが間違っていたと判断した場合、接続を再確立するために複数の試みを送信します。あなたがより密接に、TCPが接続を維持しようとする方法に一致する17を介してパケット10の通常のリカバリ動作を、見ることができます。パケット5と6の間にタイムスタンプで0.5ミリ秒の違いがあります。通常のオペレーティングシステムは、TCPセッションが回復不能であることを時間のその短い期間で決定することはない。

パケット7では、物事がおかしな動作を続けます。私たちは、クライアントが独自のリセットパケットでサーバのリセットパケットに応答してください。これは確かに、エラーパケットに応答することはありませんRFCの状態など、通常のIPの動作ではありません。ため、通常のセッション中に、エラーのこのタイプの交換を参照してくださいことはない。何かは明らかに非常に間違っている。

パケット9では、我々は、サーバが404エラーメッセージを送信してください。ここではいくつか問題があります。起動するには、サーバはすでにそれが回復不能になるセッションを考慮したことを示すリセットを送った。システムがリセットパケットを発行した後、データを送信し続けることはありません。実際には、サーバはパケット17へのすべての方法を送信し続ける。この活動を作るものであっても見知らぬ人には、クライアントが同様にリセットを発行していることです。サーバだけがリセットを発行したという事実を無視されていないので、それはまた、クライアントから送信されたリセットを無視しています。

ので、これは非常に奇妙なTCPの動作であることは言うまでもない。私の次の記事で私は何が起こっているか、より良い外観を得るために、ペイロードに深く詳しく説明します。

コメントなし »

で掲示される3 - errに、パケットの復号化

タグ：パケットデコード

tsharkのチャレンジ- Hints1

2009年10月5日

先週、私はlibpcapファイルを投稿して、同じくらいあなたがtsharkのを使用してトレースに関するできたとして把握することに挑戦。この記事では私はデコードを分析するプロセスを始めます。私はそれを完全にカバーしてウィル。ここで私の目標でも開始するかわからない人に足を放棄することです。週が進むにつれて、私は詳細を追加します。

はじめに

あなたが最初にすべきことは、ファイルの内容を見てです。私はファイルの内容を読み取るために- rスイッチを使用します。これは、最初に検出されたインターフェイス上での盗聴のtsharkのデフォルト設定を上書きします。通常、私は"小さい"コマンド（または"複数の"Windowsでの）出力をパイプしますが、ファイル内のわずか17パケットがあります。

tsharkの- R challenge1.cap
1 0.000000 148.78.247.10 - > 12.33.247.4 TCP 26922>のhttp [SYN]のSeq = 0勝利= 65535 Len関数= 0 MSS = 1460 = 0 TSV = 15485003 TSER = 0であった
2 0.000080 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [SYN、ACK] SEQ = 0 ACK = 1勝= 5792 Len関数= 0 MSS = 1460 TSV = 1031147147 TSER = 15485003 = 0、WAS
3 0.029341 148.78.247.10 - > 12.33.247.4 TCP 26922>のhttp [ACK] SEQ = 1 ACK = 1勝= 65535 Len関数= 0 TSV = 15485003 TSER = 1031147147
4 0.030787 148.78.247.10 - > 12.33.247.4 HTTP GET / CFIDE /管理者/ startstop.html HTTP/1.0
5 0.030841 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [ACK] SEQ = 1 ACK = 222優勝= 6432 Len関数= 0 TSV = 1031147150 TSER = 15485003
6 0.031319 12.33.247.4 - > 148.78.247.10 TCP HTTP> 26922 [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は
7 0.031385 148.78.247.10 - > 12.33.247.4 TCP [TCPは、失われたセグメントをACK応答] 26922>のhttp [RST、ACK] SEQ = 1 ACK = 222ウィン= 0 len = 0は
8 0.031610 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
9 0.031664 12.33.247.4 - 見つかりませんでした> 148.78.247.10 HTTP HTTP/1.1 404（テキスト/ HTML）
10 0.251838 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
11 0.711825 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
12 1.631812 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
13 3.471773 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
14 7.153143 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
15 14.511594 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
16 29.231324 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]
17 58.670815 12.33.247.4 - > 148.78.247.10 TCP [TCP再送] [再構築されたPDUのTCPセグメント]

すぐに私の注意を引くいくつかの詳細：

これは、HTTPセッションです。
接続が存在しないファイル（＃9の404エラー）にアクセスしよう
セッションとの通信の問題（＃10から17は再送ですが）があった

ので、すぐにこのトレースには、いくつかの質問を私の葉：

存在しないファイルに対する要求で何が起こっているのでしょうか？
なぜ我々は、通信の問題を抱えている？

それは今のところこれだけです。明日私は別のヒントを掲載します。

コメントなし »

で掲示される3 - errに、パケットの復号化

タグ：パケットデコード

tsharkのデコードチャレンジ

2009年10月2日

私の前回の記事で私はtsharkのをカバーし、デコード時に出力を操作する方法について説明しました。そこに行って、より学ぶためには良い方法はありませんので、私は挑戦を投稿することを決めた。この記事では私はlibpcapファイルを提供するでしょう。あなたの使命氏フェルプス、あなたがそれを受け入れることを選択してください、tsharkのを使用してデコードファイル内で何が起こっているか識別するために試みることです。

tsharkのインストール

tsharkのをインストールするには、Wiresharkをインストールする必要があります。次の場所から現在のコピーをつかむことができるダウンロードページ。一度行うと、インストールプロセスは、使用しているプラットフォームに依存しています。

のLinux / UNIX

もし、FedoraやRed Hatを実行している場合は、ダウンロードページを訪問する必要はありません。あなたがyumを通じて直接Wiresharkをインストールすることができます。

SU -
にyum - yをインストールwireshark.i586

あなたがUNIX系のOSや他のLinuxディストリビューションを実行している場合、あなたは上記のリンクからtarアーカイブを取得し、システムのWiresharkをコンパイルする必要があります。それらの多くがあるように依存関係に細心の注意を払う。 "。/ configureが"あなたのバイナリをビルドする前に、正常に完了することを確認します。

ウィンドウズ

自己解凍型の実行可能ファイルをダウンロード
実行可能ファイルを実行します。
"実行"ボタンをクリックして、不明な発行元の画面を受け入れる
画面上のデフォルトを受け入れるプロンプトに従って、
（ボックスがチェックされていることを確認してください）WinPcapをインストールする
管理者以外のユーザーがツールを実行する場合はNPFのサービスをインストールします。
パスステートメントの末尾に：に"\ Program Files \ WiresharkのC"を追加します

OS X

（インテルまたはPPC）プロセッサの種類に一致する画像を選択する
DiskimageMounterで開く
"私にfirst.rtfを読む"を開きます。
"クイックセットアップ"の指示に従ってください

挑戦

ここでの課題のファイルは次のとおりです。

challenge1.cap

そしてここにあなたのダウンロードを確認するためにファイルのハッシュは以下のとおりです。

MD5：ea92f08d9ba104c6cf7756564eb5aef9 challenge1.cap
SHA - 1：71041ab0f670c5b9558183a56fe1bb80e8b10506 challenge1.cap

幸運を祈ると、来週から私は、デコードプロセスを移動するために、毎日ファイルについて、もう少し情報を掲載します。

コメントなし »

で掲示される3 - errに、パケットの復号化

タグ：パケットデコード

tsharkのと分析されたパケット

2009年10月1日

以前の記事で私はのディスプレイ出力の調整方法について説明tsharkのを。ポストは多くの関心を生成し、ので、私はパケットをデコードするtsharkのを使用していくつかの追加情報を追加することにしました。この記事は、あなたが上記にリンクされているものを読んでいることを前提とし。

なぜtcpdumpの/ windumpの代わりにtsharkのを使うのか？

多くの昔のデコーダは誓うのtcpdump 、そしてそれはWindowsの相手ですwindump 。両方は素晴らしいツールですが、少し時代遅れになっている。パッチはまだ時間までの時間から解放されていますが、少しは彼らのデコード機能を更新するまたは拡大するために行われています。 Wiresharkのは一方だけでなく、それはそのようなtsharkのようなツールが含まれているように、デコードが含まれ数百のプロトコルをサポートするとリストが増えている時間のすべて。あなたは確かデコーダなしでパケットを分析することができますが、彼らはプロセスがはるかに速く行かせる。

なぜWiresharkの代わりにtsharkのを使うのか？

Wiresharkは、あなたが、詳細なペイロードの解析を行っている素晴らしいツールです。あなたが複数のパケットに特定のフィールドに従うことを望むなら、それはしかし、少々退屈することができます。例えばのは、我々は複数のパケット上のTCPシーケンス番号のインクリメントを視聴したいとしましょう。 Wiresharkのと、私は各パケットを介して中央のペインとページ内のシーケンス番号の位置に注意する必要があります。複数のパケットを超える値を整列する方法がないので、私は私の計算を実行するときに以前の値を覚えておくことを余儀なくしています。しかしtsharkのでは、我々はこのような何かを行うことができます。

tsharkの- N - Tフィールドは- E ip.src - E tcp.seq - E tcp.len
64.111.96.38 0 0
64.111.96.38 1 0
64.111.96.38 1 363
64.111.96.38 364 1448
64.111.96.38 1812 1448
64.111.96.38 3260 1448
64.111.96.38 4708 1448
64.111.96.38 6156 1448
64.111.96.38 7604 1448
64.111.96.38 10500 310
64.111.96.38 9052 1448
64.111.96.38 10810 0

TCPのシーケンス番号（2番目のフィールド）は、ペイロードのサイズ（3番目のフィールド）に基づいてインクリメントすることを忘れないでください。パケット10と11が順序通りに受信できなかったことに注意してください。これは私達の場所と特定されたIPアドレス間で利用可能な複数のパスが存在する意味するかもしれません。 Wiresharkはこのビューでは、同様に私たちは、この情報を表示するでしょうが、それは流れに従うことが少し簡単です。

フィールドの表示の詳細

同様に上記のようにように、私の以前の記事で説明したように、"- T"スイッチが表示されて出力を操作するために使用することができます。あなたは、XML、PostScriptやプレーンテキストから選択することができます。それはあなたが選び、あなたがプリントアウトしたい特定のフィールドを選択できるように最も便利なオプションは、"フィールド"です。上記のように、"- e"スイッチは、その後、表示したいフィールドを識別するために使用することができます。フィルタの完全なリストを見つけることができるここに。最も一般的に使用される値の素敵なチートシートを見つけることができるここに。

あなたが特定のプロトコルを定義する場合、tsharkのは、そのヘッダーから、より重要なフィールドの一部が表示されます。唯一のイーサネットヘッダーを確認する例を示します。

tsharkの- Tフィールドは、電子ETH
イーサネットII、Srcの：TyanComp_56：3B：14（00：E0：81:56:3 B：14）、DST：Dell_d1：FE：EF（午後12時12分03秒カテゴリー：D1：FE：EF）
イーサネットII、Srcの：TyanComp_56：3B：14（00：E0：81:56:3 B：14）、DST：Dell_d1：FE：EF（午後12時12分03秒カテゴリー：D1：FE：EF）
イーサネットII、Srcの：TyanComp_56：3B：14（00：E0：81:56:3 B：14）、DST：Dell_d1：FE：EF（午後12時12分03秒カテゴリー：D1：FE：EF）

彼らは送信元および宛先MACアドレスのように"面白い"ではないとして、タイプとCRCフィールドは、表示されないことに注意してください。我々はそれらを参照する場合（ip.typeとip.trailer）特に、これらのフィールドを定義する必要があります。

印刷分野の1つの副作用はtsharkの指定したフィールドが含まれていないすべてのパケットのための空白行を追加することです。ないすべてのパケットは、URIが含まれるように、HTTPパケットを分析するときに痛みができます。この上をきれいにする簡単な方法は、grepにパイプをすることです。次に例を示します。

tsharkの- Tフィールド- E http.request.uri | grepの- v"を^ $"
/
/ styles.cssの
/テンプレート/クラシック/画像/ starsnstripes.gif
/テンプレート/クラシック/画像/ unionjack.gif
/テンプレート/クラシック/画像/ amazon.header.gif
/ c_images/2009/05/07/71090.2.jpg

私の前回の記事で、私はgrepを議論だけでなく、Windows用の無料のバージョンを取得する場所。上記のgrepコマンドは、指定された値が含まれていないすべての行を一致させるためには"- v"スイッチを使用しています。 "^ $"空白行が定義されています。すべての空白行からので、上記のgrepコマンドをフィルタ。

より多くの表示オプション

tsharkのは、他の有用な多くの表示オプションを持っています。例えば、出力の先頭にヘッダを印刷することができます。

tsharkの- N - Tフィールドの- e ip.src - E ip.dst - Eヘッダ= yの
ip.src ip.dst
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100

スプレッドシートまたはデータベースに情報をインポートする予定の場合は、フィールド間で使用する文字を定義することができます。

tsharkの- Tフィールドは- E ip.src - E ip.dst - E tcp.dstport - Eヘッダ= Y - Eセパレータ=;
ip.src、ip.dst。tcp.dstport
64.111.96.38、12.5.200.100、34831
64.111.96.38、12.5.200.100、34831
64.111.96.38、12.5.200.100、34831

パケットの統計情報

tsharkのは、同様に固体の統計的な能力を持っています。もしたくさんのファイルを処理する必要がある場合は、時にはそれは生の統計を見てから始めるのに役立つている。 "- Z"スイッチは、あなたが分析したい統計情報を指定するために使用されます。通常、これらは、デコード情報の末尾に印刷が、"- q"を使用している場合のみ統計情報が出力されるスイッチになります。次に例を示します。

C：\テスト>のtshark - Q - zのHTTPは、stat、- zのHTTP、木- R test.cap
================================================== =============
HTTP /パケットカウンタ値率のパーセント
-----------------------
合計HTTPパケット64915 0.048999
HTTPリクエストパケット459 0.000346 0.71パーセント
24 0.000018 5.23パーセントのGET
HEAD 433 0.000327 94.34パーセント
オプション2 0.000002 0.44パーセント
HTTP応答パケット448 0.000338 0.69パーセント
？：壊れた0 0.000000 0.00パーセント
1XX：情報0 0.000000 0.00パーセント
の2xx：成功12 0.000009 2.68パーセント
200 OK 12 0.000009 100.00パーセント
3xx：リダイレクト0 0.000000 0.00パーセント
4xx：クライアントエラー436 0.000329 97.32パーセント
404は432 0.000326 99.08パーセントが見つかりません
403 4 0.000003 0.92パーセント
5xxの：サーバーエラー0 0.000000 0.00パーセント
他のHTTPパケットは64008 0.048314 98.60パーセント
================================================== =============
================================================== =============
HTTP統計情報
応答パケットで* HTTPステータスコード
HTTP 200 OK
HTTP 403アクセス
HTTP 404が見つかりません
HTTPリクエストメソッドの*一覧
24のGET
オプション2
HEAD 433
================================================== =============

物事のカップルは、この出力に突き出す。最初に、我々は、誰かが彼らが許可を持っていなかった何かにアクセスしようとしたこと示す4 403エラーを持っている。また、459のHTTPリクエストのうち、そのうちの432は、存在しないファイルのためだった。我々はまた、プロキシになる可能性が"HEAD"要求の多くを見ている、またはWebサーバーのアクセスログに記録されてから維持しようとする攻撃である可能性があります。明らかにこのキャプチャファイルには、さらなる調査が正当いくつかの疑わしいトラフィックが含まれます。

あなたがそれらを必要とする場合tsharkのも一般的なスループットの統計情報を生成することができます。これは、DoS攻撃を確認するための優れた方法です。

tsharkのは、- q - zのIOは、stat、10 - R test.cap
================================================== =============
IO統計
間隔：10.000秒
列＃0：
|コラム＃0
時間|フレーム|バイト
000.000から010.000 254 145081
010.000から020.000 145 80003
020.000から030.000 125 65527
030.000から040.000 4 264
================================================== =============

（注）のtsharkは秒単位で定義された指定された間隔、のためのフレームとバイトカウントを出力します。唯一の問題は、ワイヤーのパケットオフをキャプチャする場合、キャプチャが終了するまで、統計情報が表示されないことです。

Execの概要

tsharkのは、それのカウンターパートtcpdumpとwindumpを超えている非常に対応のパケット解析ツールです。柔軟な出力表示と一緒に豊富なデコード機能を組み合わせ、とtsharkのは、多くのパケットデコーダのための最適なツールとなっています。

コメントなし »

で掲示される2 -警告、ネットワークセキュリティ、パケットの復号化

タグ：パケットデコード