[stalk:01257] Snort での対策 Re: FYI:fragroute がZDNN で紹介されています

["shikap@xxxxxxxxxxxx" <shikap@xxxxxxxxxxxx>]

しかＰです。

Snortがfragroute対策版を仮リリースしました。

http://www.snort.org/dl/snapshots/snort-stable-snapshot.tar.gz

また、snort-1.8.7のリリースに向けて上記スナップショットの機能を
バックポート中のようです。

お急ぎの方はstableを、急いでない方は1.8.7待ち、というところでしょうか。

文末に、コミッターのChris Green氏の「対策したよ」メールをつけておきます。
＃これを見るとsnort1.8.6がどういうパターンで翻弄されてしまうかわかります。
＃＃長くなってごめんなさい＞All m(__)m

いじょ。

At 4:52 PM +0900 02.4.22, shikap@xxxxxxxxxxxx wrote:
>しかＰです。
>
>
>At 5:38 AM +0900 02.4.22, Kensuke Nezu wrote:
>>ZDNNでも紹介されました。
>>★「悪質なプログラムを偽装できるツール」
>>http://www.zdnet.co.jp/news/0204/20/b_0419_07.html
>
>より詳細な文章はこちら。
>http://www.zdnet.co.jp/news/0204/22/e_hacker.html
>
>ヘッドラインの方はちょっと誤解を招きやすい文章かもしれないですね。
>詳細な方はもう少しつっこんだ話が書いてあります。
>
>ただ、何で今頃になってこう持ち上げられているのかなぁ。
>すでにそのようなツールが存在していたことをTERASHIMAさんが書かれて
>いるわけですしね。
>＃うーん、やっぱり新旧使ってみなきゃだめかなぁ・・・時間が・・・
>
>さて、snortは一部脆弱性が残っているとRoesch氏みずから語っているのですが、
>本当にほかのIDSは影響を受けないんでしょうか？
>＃だれかほかのIDSユーザに試して欲しい、と言ってみるテスト。
>＃ちなみにsnortの対応は今週中、なんて発言もありますね＞詳細版のほう
>
>いじょ。

ここから文末までGreen氏のポストしたメールです。

To: snort-devel@xxxxxxxxxxxxxxxxxxxxx, snort-users@xxxxxxxxxxxxxxxxxxxxx
From: Chris Green <cmg@xxxxxxxxxxxxxx>
Lines: 117
Subject: [Snort-devel] fragroute related fixes need testing on real networks
Sender: snort-devel-admin@xxxxxxxxxxxxxxxxxxxxx
X-BeenThere: snort-devel@xxxxxxxxxxxxxxxxxxxxx
X-Mailman-Version: 2.0.9-sf.net
List-Help: <mailto:snort-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=help>
List-Post: <mailto:snort-devel@xxxxxxxxxxxxxxxxxxxxx>
List-Subscribe: 
<https://lists.sourceforge.net/lists/listinfo/snort-devel>,<mailto:snort-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=subscribe>
List-Id: Gathering place for Snort developers 
<snort-devel.lists.sourceforge.net>
List-Unsubscribe: 
<https://lists.sourceforge.net/lists/listinfo/snort-devel>,<mailto:snort-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=snort-devel>
X-Original-Date: Mon, 22 Apr 2002 19:34:58 -0400
Date: Mon, 22 Apr 2002 19:34:58 -0400

Hey folks,

I just committed a lot of changes today to snort's HEAD branch in CVS
to deal with the test cases iterated in fragroute.

To get the full benefit of these changes:

preprocessor frag2: detect_state_problems
processessor stream4: detect_state_problems

These need a lot of testing and there may very well be more problems
laying around.

If things go well, I'll backport the changes to snort-stable and
release a 1.8.7

If you find a new set of options that evade snort, drop me a line and
I'll work to fix and/or detect them and give you full credit.

The bugtraq post was the first I'd seen the README.snort so let me
just say that I spent a lot of Thursday superlate-> Today thinking
about the problems while trying to get work done.

Anyway, fragroute is a neat tool and does a lot of the stuff that has
been on the todo list to check.  Ahh only hours in the day.

>
>  1. older TCP retransmission chaff (snort's TCP segment reassembly
>     seems to always favor newer data, even for properlby sequenced
>     received data):
>
>	tcp_seg 1
>	tcp_chaff rexmit
>	order random


Should be fixed and if we see retransmissions of older data that
differs from what we already have, we generate an alert and throw away
the packet

>
>  2. forward TCP segmentation overlap, favoring newer data (both Windows
>     and Unix operate this way, in contrast to Ptacek and Newsham's
>     results):
>
>	tcp_seg 1 new

Fixed and generates alerts on packets that are part of a stream that
has already been reassembled.

>  3. chaff TCP segments with older TCP timestamp options forcing PAWS
>     elimination:
>
>	tcp_seg 1
>	tcp_chaff paws
>	order random

This should be relooked at but after making the first two changes,
this one was picked up very loudly.

>
>  4. older IP fragment duplicates (snort's IP fragment reassembly seems
>     to always favor newer data, even for properly sequenced received
>     data):
>
>	ip_frag 8
>	ip_chaff dup
>	order random
>

Alert on frags with option data and suck them all away.

Philosophical question:  Should we ignore frags we didn't see the
first fragment of?

>
>  5. IP duplicate fragment chaff with bad options:
>
>	ip_frag 8
>	ip_chaff opt
>	order random
>

Once the opts were tossed, things worked fine

>
>  6. either TCP or IP chaffing with short TTLs (that expire before
>     reaching the end host, but pass by the monitor):
>
>	ip_frag 8
>	ip_ttl 11
>	ip_chaff 10
>	order random
>
>	tcp_seg 1
>	ip_ttl 11
>	tcp_chaff 10
>	order random
>

TCP stream stuff already had the min_ttl option to detect this attack
so that it will throw away anything underneath that.

I added this option to frag2

Also, there is a ttl_limit option to both.  Basically, this will alert
on anything that is different by more than a certain limit

The default is 5 picked off the cuff.  Know of any papers that measure
the avg and std deviation of TTLs on normal internet traffic across a
large sample and I'll be your buddy.

Thanks for your help and patience,
Chris
--
Chris Green <cmg@xxxxxxxxxxxxxx>
Fame may be fleeting but obscurity is forever.


_______________________________________________
Snort-devel mailing list
Snort-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/snort-devel
--
- このメイリングリストに関する質問・問い合せ等は
- <security-talk@xxxxxxxxxx>までお知らせください
--
------------------------------------------------------------------------
　　 　　　　　　　　しっ知らない間に増えてるぅ！
　http://toolbar.www.infoseek.co.jp/Skin?pg=skin_12_if.html&svx=971122