Smurf amp detection and notification scripts

Alex P. Rudnev alex at Relcom.EU.net
Tue Mar 16 16:44:40 UTC 1999


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 at cisco.com>
> To: nanog at 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 at 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)





More information about the NANOG mailing list