Hi, I, as many of you have had to deal with various types of denial of service attacks or other attacks. A good number of these attacks can be characterized by one host sending to many destinations, many hosts on one subnet sending to one destination, one host sending to very similar or the same IP address (host/port scans) etc. Confronted with detecting this to warn my customers if they are victims, or admonish my customers if they are the culprits, I wrote a tool to give me some indication when this kind of thing is going on, while it is still happening using netflow data. I modified Ciscos' fdget program they make available on one of their ftp sites to look for self similar source or destination addresses in netflow data blocks. Thanks go to Cisco for leting me distribute this to the group. You can give it a try if you want. It is avaliable via anonymous ftp on venera.isi.edu in subdirectory mon. The file names you will need to know to retrieve by name are: smurfind.c C program README.smurfind documentation flowdata.h C program definitions (written by cisco folks) smurfind.rc sample data file You can't do an ls on the directory. I used version 5 netflow data to debug the code. I haven't tested it against version 1 or other versions. B.T.W. The program dumps legitimate data as suspect. If however the rate at which the program shows suspect data changes, that is when you need to look more closely. The output from the program is very valuable to confront the guilty party to demonstrate that something inapropriate is going on. Let me know what you think. Walt Prue Los Nettos
On Thu, Jan 28, 1999 at 11:28:18AM -0800, prue@isi.edu wrote:
I, as many of you have had to deal with various types of denial of service attacks or other attacks. A good number of these attacks can be characterized by one host sending to many destinations, many hosts on one subnet sending to one destination, one host sending to very similar or the same IP address (host/port scans) etc.
I wrote something like this a few weeks ago, it's included in a package we've been using at OSU for the past few years. We get scanned in some form or another about ten times a day :( ftp://ftp.net.ohio-state.edu/users/maf/cisco/flow-tools.tar.gz flow-dscan match src ip with dst ip and portlist < 1024. Tries to locate host and port scans. Includes an ager so it can be run continually without eating up an infinite amount of memory. A suppress list can also be specified with a src ip, and optional protocol srcport and dstport. By disabling the ager and setting the dump state option this can be used to create a srcIP to dstIP/portmap<1024 table. examples: locate port and host scans in rf, but ignore TCP replies from a busy MS web server. Don't run in the background. echo "12.19.68.8 6 80 -" > dscan.suppress flow-dscan < -b rf same, but dump the internal state on exit to "statefile" flow-dscan -b -s statefile -p < rf Connect to flow-capture to process real time flows. Runs in the background, logs to syslog LOG_LOCAL6 nc flow-collector.foobar.edu 9991 | flow-dscan -w The statefile is just the internal hash table. It's a mapping of srcIP to dstIP's and ports < 1024. type=hash bucket depth flags srcIP H 0 1 0 152.171.152.171 type=include nflows dstIP I 10777445 128.146.125.90 type=hash bucket depth flags srcIP H 0 5 0 206.12.206.12 type=include nflows dstIP I 4635135 128.146.161.7 type=include nflows dstIP I 19387662 128.146.48.7 type=port nports portnum P 1 53 -l can be used to load this statefile before processing the flows, use for interrupted operation. when running live, SIGHUP will reload the suppress list, and SIGUSR1 will dump state. The ager runs every 1000 flows. It runs down a subset of the hash table each run, removing records that were created 90,000 flows prior to the current. Modify the ager timeout with -t The host scanner works by counting the length of the destination IP hash chain. If it goes above 64, then the src is considered to be scanning. Modify depth trigger with -D. The port scanner works by keeping a bitmap of the destination port number < 1024 per destination IP. If it goes above 64, the src is considered to be port scanning the destination. Modify port trigger with -P. When a src has been flagged as scanning it will not be reported again until the record is aged out and enough flows trigger it again. Remove the -b flag and it will run in the background and log via syslog Use the built in interface filters to limit detection to inbound or outbound scans on a border router. For example if interface 1 is the outside (Internet) interface and 2 and 3 are the inside (Campus) interfaces detect only inbound scans flow-dscan -i1 -I2,3 If you can't figure out the interface numbers, try using flow-print first. -w is a built in web filter. Use of this could possibly hide real scans. -m is a built in multicast address filter -O,-P,-T can trigger a messages based on excessive octets, packets, or flow duration. This can be used to detect denial of service attacks. -h lists the other options. -- mark
participants (2)
-
Mark Fullmer -
prue＠ISI.EDU