Hmm, why not? We have some smurf-detecting tools (incorporated into ip accounting system here) but we never try to optimise them. Through - it's not too difficult to detect SMURF or network scan or attack from the frauded addresses - all you need is: (1) 10 minute accounting snapshot (2) a lot of memory and CPU (to make programs simpler) (3) perl. For example: (1) Build the table: / address - the number of neighbour addresses with the uni-directed traffic/ (2) Get NN top addresses (3) For every, check the average number of _simular_ neighbour addresses (from the same network). In case if this _average_ number < 5 OR total number < 20 (all numbers should be configurable) - skip this case. (4) Analyse the direction of the traffic. If the SINGLE address is on YOUR side and DIFFERENT addresses are on the other side - it looks like SMURF. If SINGLE address is on other side and different addresses are on your side - looks like network scanning. You can improve this by analyzing the type of traffic (we are forced to forget this information because we can't collect so much information - now (withouth ports/protocols) it's about 400,000 records/10 minutes, and this number increases dramatically if you try to hold network protorol and port info; and then we use boths IP ACCOUNT and NETFLOW methods to collect info. Anyway, the principles are the same: If there is: - a lot of UNIDIRECTIONAL TRAFFIC - FROM or TO the SINGLE address but TO or FROM the different ones THEN it's suspicious traffic and we should analyse it more carefully to determine - if it's one of: - someone SCAN US - our customer scan someone other - someone smurf (or make DNS storm) our customer. This means - you collect some data base (I prefere SQL but it takes a lot of time and forces us to use CC program), in the form: ADDR ADDR NPACKS NPORTS Then look for the unidirectional records Then look for the number of DIFFERENT pairs for every SRC or DST address and then got 10 - 100 top records and analyse carefully. Sorry, I don't think the quality of our own analyser is good enougph to be published here, because our goal was to provide data for SQL data base (in the form - NETWORK NETWORK PACKETS_IN BYTES_IN PACKETS_OUT BYTES_OUT) where NETWORK is <CLASS NAME EXTENTION> name, and smurf detection was done as the second-level task. But the idea was just the same. What's a pity CISCO did not published any libraries for autho-config loading and/or analysing, and everyone (just as our NOC) are caused to write this tools themself. It's possilbe to block scans and/or smurf-like attacks authomatically in some cases. On Tue, 16 Mar 1999, Stephen Sprunk wrote:

Date: Tue, 16 Mar 1999 09:50:57 -0600 From: Stephen Sprunk <ssprunk@cisco.com> To: nanog@merit.edu Subject: Smurf amp detection and notification scripts

Since no scripts to do what I was looking for have been forthcoming, I broke down and decided to prove to myself I still know perl. Find attached the following:

flow-smurf.pl

Takes a sorted output (simple unix sort) from "sh ip cache flow" and finds what it believes are smurf amplifiers. The thresholds for number of bytes, number of flows, prefix length, etc are all tunable. Outputs a list of suspect prefixes.

smurf-email.pl

Takes a list of prefixes, looks them up in whois, and prints a list of contact email addresses and the associated prefixes. Also emails the contacts if you specify a return address. Requires ipw.

Stephen

ObRandy: "no ip routing" will stop smurf attacks

| | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: NSA, Network Consulting Engineer :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Pager: 800-365-4578 / 800-901-6078 C I S C O S Y S T E M S Email: ssprunk@cisco.com

Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)