Re: slow scans?

[Ron Gula <ronald.gula () verizon net>]

It really depends on what you want to know.

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:

"I've seen a RST packet leave from a high port on 100+ machines
in the last four days, your network is being slowly probed by
many remote machines."

To my knowledge, Dragon and NFR do look for these sorts of
scans. Also, protocol-flow anomaly detection tools like
Stealthwatch have longer resolution for these sorts of things.

Personally, the advantage is on the attacker, as they can
easily vary their source address, and the time between packets.
Without some heavy gear to really keep these things in memory,
one of the things we did in Dragon was to look for 'hot ports'.
By this I mean, just set up some rules to look for failed
requests to certain ports. If you don't have any TCP services
above port 1024, then looking for a RST packet coming from
there is a good indication that a connection failed. If you
get large numbers of these, then you will probably be able to
tell with much greater accuracy what has occurred than a
proprietary algorithm.

Ron Gula, CTO
Tenable Network Security


At 01:46 PM 2/12/2003 -0500, Anton Chuvakin wrote:
> All,
>
> This is a somewhat generic information query for methods to detect slow
> (aka "low and slow")  port scans and network scans using IDS (or whatever
> other means).
>
> By slow scans I mean port probes occurring over the period of hours to
> months (!) against the different destinations and even potentially from
> different sources (both in the form of coordinated and spoofed scans).
>
> The only resource I identified was the Spice/Spade from the Silicon
> Defense site. References in
> http://www.silicondefense.com/pptntext/Spice-JCS.pdf seem to be pretty
> outdated and the detection methods are implied to be inferior to that of
> Spice.
>
> Also, the classic X packets in Y second to Z port/hosts seem to be pretty
> useless for truly slow scans, such as those spanning days and weeks.
> Plotting pictures of sequential port accesses seem to only reveal the
> sequential scans from a single source against a single destination, which
> are relatively easy to pick up. Anything more high tech?
>
> And finally, does anybody really care? I know for sure that some folks do,
> but I suspect their percentage is reeeally small. Is that so?
>
> Thanks a lot for any tips, references and information pointers.
>
> Best,
> --
>   Anton A. Chuvakin, Ph.D., GCIA
>      http://www.chuvakin.org
>    http://www.info-secure.org