Sorry it took a long while for me to reply to your note 
- it arrived in
the midst of travel, followed by the holidays.
I have another questions regarding bro(version 07a90).I'am testing the
capability
of bro to detect port scanner.After , i have found others problem:1) It don't detect Fin, Xmas and Null scans.
Correct (though actually I'd have thought it would detect Xmas scans).
Bro's scan detection is implemented in terms of connection_attempt,
connection_rejected, and connection_established events, and Xmas and Null
packets don't lead to these, since they're illegal-from-the-get-go. You
could quite easily extend the event engine to aid with detecting these,
though. What you'd do is modify TCP_Connection::NextPacket to generate
events when it sees those types of packets, and then in your policy script
hand the corresponding connections to check_scan(), to process like any
other possible connection scan.
Regarding detecting FIN scans, this is a bit tricky. The reason is because
when you see a FIN go by, you don't know if it might be legitimate (for
a connection that was established before Bro started running) or not. The
way to tell is to see what sort of reply it elicits; basically, you want to
generate an event if you see a FIN elicit a RST reply, and if there was
no connection state in existence prior to the transmission of the FIN. This
could likewise be added to TCP.cc, but requires more care, because it's a
new connection state (FIN-transmitted-but-no-state-in-effect-when-it-was).
2) Bro don't detect two time the seme scan betweent the same hosts on
the same ports.
That's a policy decision. You could if you wanted modify check_scan()
to clear the corresponding entries in the connection state tables in
order to pick this up.
3) It consume a great quantity of memory.
Yes, and this needs work for high-volume environments. The first thing
you can do is "@load reduce-memory", which trims a lot of timers and the
like in order to decrease memory consumption. It helps considerably.
A better solution is in the pipeline - Robin Sommer of the University
of Saarbrucken has developed a general mechanism for timing out Bro state,
which I'm working on integrating into the next release.
To resolve the first i have added a script to detect Fin, Xmas and Null
scans usuing the weird event their produce.And all works good.
That certainly will work, though it's not the cleanest match to the problem
(which would entail new events, per the above).
To resolve the 2° and the 3°, i have added to scan.bro a recursive
function (that use bro delete function and a table of support) to delete
the record of the table scan_triples(is deleted also the table of support).
Yes, that should help with #2.
While the first problem seems to be resolved, the second is gotten worse.
I'm not sure why it makes it worse, but it also likely wouldn't help, since
for big scans, the state will just get created again anyway.
There is a way to easy delete a subset of a table?
Only if you know which elements you want to get rid of.
or another way to
reduce the consume of memory of the scan analyzer?
If reduce-memory doesn't do the trick for you, let me know and I'll try
to put together a distribution snapshot with Robin's state expiration hooks
so you can try using that.
Vern