Does this sound draconian? The death of a thousand cuts is far worse. By the way, we have talked about Loki and distributed denial of service tools like Trinoo using echo requests and replies for other purposes. Perhaps you would want to take a close look at the content of that

ping in the trace as well.

"Random" Port Scan

This scan was well on its way to setting a speed record. This is another example of scanning ports that don't make any sense. There is no detectable signature; the purpose of the scan is

unknown:

11:48:42.413036 prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) win 512

11:48:42.415953 prober.18987 > host.arpa.net.248: S 909993377:909993377(0) win 512

11:48:42.416116 prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) win 512

11:48:42.416279 prober.19032 > host.arpa.net.828: S 323265067:323265067(0) win 512

11:48:42.416443 prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0) win 512

11:48:42.556849 prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) win 512

11:48:42.560124 prober.19150 > host.arpa.net.228: S 1832011492:1832011492(0) win 512

11:48:42.560824 prober.19151 > host.arpa.net.840: S 3231869397:3231869397(0) win 512

11:48:42.561313 prober.19152 > host.arpa.net.1003: S 2435718521:2435718521(0) win 512

11:48:42.561437 prober.19153 > host.arpa.net.6: S 2632531476:2632531476(0) win 512

11:48:42.561599 prober.19165 > host.arpa.net.280: S 2799050175:2799050175(0) win 512

11:48:42.563074 prober.19166 > host.arpa.net.845: S 2065507088:2065507088(0) win 512

11:48:42.563115 prober.19226 > host.arpa.net.653: S 1198658558:1198658558(0) win 512

11:48:42.563238 prober.19227 > host.arpa.net.444: S 1090444266:1090444266(0) win 512

11:48:42.565041 prober.19274 > host.arpa.net.907: S 2414364472:2414364472(0) win 512

Okay, we don't know the purpose of the scan, and that is frustrating. So as an analyst, what do we know about this? We know it is fast and we know that the source port behavior is unpredictable—sometimes it skips, and sometimes it doesn't. Why doesn't the trace make sense? Why in the world is someone scanning so many unknown ports? I am not sure that we will ever know these answers. In the past few years, there have been a lot of very odd scan patterns. The best guess I have is that someone was using nmap, hping2, isic, packetx, or a similar tool to craft scans that had no possible purpose, probably from spoofed source addresses. That answers how, but not why!

Here is a guess: to drive intrusion-detection analysts crazy; to see what they would report and what they wouldn't; to see whether the scanners could cause a CNN news report that the world was under some horrid new cyber attack. Granted, it is far fetched, but it is the best I can come up with. How should the analyst react to this trace and other unknown seemingly random scans? I do recommend reporting stuff like this, because you never know what piece of information will help your CIRT. If your firewall is set to deny everything not specifically allowed, and none of your hosts answer back, however, don't get stressed. The best idea is to

create a directory named "Scans_From_Mars" and file these detects there.

Database Correlation Report

I am a strong fan of allowing analysts to "fire and forget"—that is, when they see a detect, just report it and move on. When we first started doing fairly large-scale intrusion detection (five sites, 12,000 computers or so), the analyst had to manually check all the sensors for a correlation of source port, source IP, destination port, destination IP, and so on. Back then, if you were looking for something like correlation of TTL field or some behavior of the sequence number, it might take days to sort it out.

Life is too short for that kind of madness. After a pattern has been detected and reported, the database looks to see whether any correlations exist. This is what such a report might look like. This report was generated by a military correlation system known as Dark Shadow. It is based on an Oracle database. When an analyst detects and reports an intrusion attempt, Dark Shadow checks for that pattern across its data window of X sensor locations for Y months. If it finds a match, it creates a correlation report. This is why the analyst can operate in a fire-and-forget mode.

Note that from the source port ranges, it appears that two processes are running (destination port 111 is contacted by source ports from 617–1023, and destination port 25 by ports 2294–29419) on scanner, one to check email and the other to check portmapper. The two processes are probably bound by a shell script and reading from a file of target IP addresses.

SNMP/ICMP

The Simple Network Management Protocol (SNMP), even before the exploits that followed the release of the PROTOS toolkit in early 2002, could provide an attacker with a lot of information about your hosts and network configuration. According to the RFC NSMP is port 161 TCP and UDP. I have never seen a TCP version of SNMP in practice, but for safety, ) port 161 TCP and UDP should be blocked from the Internet.

It is amazing how many devices, such as micro hubs, x-terminals, and printers, have SNMP agents. By default, these devices are protected by a well-known password (community string), typically "public." Many security-conscious organizations change this password, usually to one of the following:

●Private

●Internal

●The name of the organization

Note: Forgive me if you thought I was serious. The choices of private, internal, or the name of the organization for SNMP community strings are not advised. Pick something hard to guess. In the following trace, notice the use of broadcast for both SNMP and ICMP. This is a very