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

flow-smurf.pl (1.34 KB)

smurf-email.pl (2.96 KB)

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.