Re: slow scans?

[Anton Chuvakin <anton () chuvakin org>]

Ron,

Thanks for the response.

> It really depends on what you want to know.
Just the fact that an unknown party is doing the reconnoissance.

> For example, if you want to detect someone trying to do slow
> TCP host enumeration, you really need a tool that can see all
> of the RST packets coming from a network. Since the source
> address of the scan may be varied, you would need something
> that could say:
RST tracking is a good idea. There are a couple of drawbacks. Networks
with many open ports or (the opposite) heavily firewalled to drop packets
would not be able to use it.

> "I've seen a RST packet leave from a high port on 100+ machines
What about 5 machines, would you want to trigger on that? RST tracking
also seems to suffer from false positives a bit.

> To my knowledge, Dragon and NFR do look for these sorts of
> scans.
Well, PORTSCAN X Y Z is probably not the best for the slow scans, but I am
sure you know better. To test it, I just set the Z on the Dragon I have
here to 10000, let's see what will happen.

> Also, protocol-flow anomaly detection tools like
> Stealthwatch have longer resolution for these sorts of things.
But do they have the good algorithm, that is the question.

> Personally, the advantage is on the attacker, as they can
Very true, especially for multiple sources.

> one of the things we did in Dragon was to look for 'hot ports'.
Like PSTRIGGER?

> tell with much greater accuracy what has occurred than a
> proprietary algorithm.
I am about to test that. The concern is whether the random noise
will drown the slow scan data in this case...

Best,
-- 
  Anton A. Chuvakin, Ph.D., GCIA
     http://www.chuvakin.org
   http://www.info-secure.org