FIN攻撃とは正確に何であるかを知りたかっただけです。 TCP経由の接続の終了を示すために使用されるFINフラグについて知っています。しかし、FIN攻撃とは正確には何ですか?

コメント

  • 自分で調査を行ったことはありますか? " FIN攻撃"についてどのように知りましたか?
  • 基本的には課題で与えられました。いくつかの読み取りを行ってきましたが、TCPヘッダーのフラグとしてFINに遭遇しただけです。ただし、FIN攻撃については何もありません。
  • 次に、" FIN攻撃"?スキャンとフラッドがありますが、'どちらかを"攻撃として説明するかどうかはわかりません"
  • この回答に対する2つの質問を読むと、FINスキャンを意味していると想定していることがわかります。スキャンは攻撃ではありません。 FINスキャンのことですか、それともまだ必要な答えが得られないのですか…?
  • ええ、私はそれだけ考えました。 'まだ多くの情報はありませんが、ファイアウォールをバイパスできる場合があるため、基本的にFINパケットを使用してどこかに穴を見つけると考えています。

回答

これは、もともと「卑劣なファイアウォールバイパス」を目的とした古い攻撃であり、いくつかの要因に依存していました。現在では珍しいことです。古いUnixOS、ステートフルファイアウォールの欠如、NIDS / NIPSの欠如など。これは、まったく新しいまたは新しいTCP / IPスタックをテストする場合(つまり、攻撃自体ではなくフィンガープリント技術として)に役立つ可能性があります。 (またはあなたやあなたの環境にとって初めてのことです)、これはまれですが発生する可能性があります。

これが最新の代替品であるTCPプロトコルスキャンです:

nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip> 

これはTCPACKスキャンとほぼ同じです(ホスト、開いているポート、ファイアウォールルールセットなどをマッピングするために使用できますが、一部のNIPS、IDS、および最新のファイアウォールが検出する警告があります-別のおそらく私がいる状況固有のイベントインシデントレスポンダーやセキュリティオペレーションセンターには、最近注目すべき重要事項があるため、通知しません):

nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip> 

ただし、出力はわずかに異なり、他のパケットレベルの違いも確認できます。

より高度な手法を開発するために探しているのは、RSTパケットの微妙な点とそのウィンドウサイズを特定することです。ウィンドウサイズがゼロ以外の場合は、TCPACKスキャンの代わりにTCPウィンドウスキャンを使用するように切り替えることをお勧めします。詳細については、 http://nmap.org/book/man-port-scanning-techniques.html

を参照してください。

NSEガイド。ただし、BNAT、fragroute、osstmm-afd、0trace、lftなど、WAF、IDS、IPS、リバースプロキシ、ゲートウェイ、詐欺システムなどの他のインラインの非ファイアウォールデバイスを検出する可能性のある他の多くの手法があります。ハニーポットまたはアクティブな防御。ネットワーク侵入テストを実行する場合は、これらすべてに注意する必要がありますが、これらはあらゆる種類のネットワークおよびセキュリティの問題のトラブルシューティングに役立ちます。

コメント

  • 回答に感謝しますが、それでも' FIN攻撃が何であるかわかりません。ああ、Nmapsが大好きです:D
  • 短いバージョンは、セッションに属していない' FINを送信し、応答から学習します。取得する。 @atdre 'の残りの回答は十分です。'彼にこの詳細を追加してもらいたいのです。
  • ええ、ちょうどいいですね。FINスキャンを攻撃的に使用する方法を理解しようとしているだけです。

回答

FIN攻撃(FINスキャンを意味すると思います)はTCPポートスキャンの一種です。

RFC 793によると、「閉じたポートへのトラフィックは常にRSTを返す必要があります」。 RFC 793は、ポートが開いていて、セグメントにフラグSYN、RST、またはACKが設定されていないかどうかも示しています。パケットをドロップする必要があります。すでに閉じられているセッションの古いデータグラムである可能性があります。

したがって、FIN攻撃が行うことは、これを悪用することです。閉じたポートにFINパケットを送信すると、RSTが返されます。応答がない場合は、ファイアウォールによってドロップされているか、ポートが開いていることがわかります。また、FIN攻撃はSYNスキャンよりも見えません(応答を確認するためにSYNを送信します)。

ただし、多くのシステムは常にRSTを返します。そして、ポートが開いているか閉じているかを知ることはできません。たとえば、Windowsはこれを行いますが、UNIXは行いません。

コメント

  • うーん、基本的には応答を得るために送信されるので、"攻撃者"そして何をすべきか知っていますか?
  • はい、開いているポートについてターゲットマシンをプローブします。これは、管理者または攻撃者が脆弱性を見つけるために実行する可能性があります。
  • ああ、そうです。私も同じことを考えていました。ただし、確認が必要です。

回答

FINスキャン、NULL、XMAS、またはカスタムフラグスキャン-だった-はファイアウォールをバイパスし、IDSを回避するために使用されることがある、と私は引用します:

FINスキャン:主な利点これらのスキャンタイプには、特定のステートフルでないファイアウォールやパケットフィルタリングルーターをこっそり通過できるというものがあります。このようなファイアウォールは、(アウトバウンド接続を許可しながら)着信TCP接続を防止しようとします。これらのスキャンの完全なファイアウォールバイパス機能を実証するには、かなり不完全なターゲットファイアウォール構成が必要です。最新のステートフルファイアウォールでは、FINスキャンで追加情報が生成されることはありません。

SYN / FIN興味深いカスタムスキャンタイプの1つはSYN / FINです。ファイアウォール管理者またはデバイスの製造元は、「SYNHagのみが設定された着信パケットをすべてドロップする」などのルールを使用して着信接続をブロックしようとする場合があります。発信接続の2番目のステップとして返されるSYN / ACKパケットをブロックしたくないため、SYNフラグのみに制限します。このアプローチの問題は、ほとんどのエンドシステムが以下を含む最初のSYNパケットを受け入れることです。他の(非ACK)フラグも同様です。たとえば、NmapOSフィンガープリントシステムはSYN / FIN / URG / PSHパケットを開いているポートに送信します。データベース内のフィンガープリントの半分以上が、SYN / ACKで応答します。これらは、このパケットでのポートスキャンを可能にし、通常は完全なTCP接続も可能にします。一部のシステムはSYN / RSTパケットにSYN / ACKで応答することさえ知られています!TCP RFCは、最初にどのフラグが受け入れられるかについてあいまいですSYNパケット、ただしSYN / RSTは確かに偽物のようです。例5.13は、EreetがGoogleのSYNIFINスキャンを成功させていることを示しています。彼はscanme.nmap.orgに飽きてきているようです。

Gordon “Fyodor” LyonによるNMAPネットワークの発見

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です