What About About Detecting Scans?

Until some brilliant researcher comes up with a better technique, scan detection will boil down to testing for X events of interest across a Y-sized time window. An intrusion detection system can and should have more than one scan detect window. For instance, we have seen several scans that exceed five events per second. By using a short time window in the range of one to three seconds, the system can detect a high-speed scan and alert in near real time, three to five seconds after the scan begins. Nipping such scans in the bud is one of the best uses of automated reaction. The next reasonable time window is on the order of one to five minutes. This will detect slower but still obvious scans. The Shadow intrusion detection system has had some success with a scan detect of five to seven connections to different hosts over a one hour window. At a later date, they employed scan detect code for a 24-hour time window in order to investigate the TCP half-open scans that are plaguing the Internet. These half-open scans are detailed in the stealth section of this chapter. Scans have also been detected using database queries with rates as low as five packets over 60 days. A scan rate that low would make sense only if it was interleaved (executed in parallel from multiple source addresses) to the extreme. More on that later!

This example may appear to be similar at first glance to smurf. In contrast to the smurf attacks, the broadcast echo requests here are spaced reasonably far apart in time. The source IP address is not spoofed. The time delay between broadcasts gives the attacker time to process the echo replies without getting overloaded.

As we discussed in Chapter 6, "Detection of Exploits," the zero is an archaic broadcast; UNIX and other systems will often still answer it. Windows systems will not; they will answer the 255 broadcast. This allows the attacker to distinguish between types of systems.