nanog mailing list archives

Re: Smurf amp detection and notification scripts


From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Tue, 16 Mar 1999 19:44:40 +0300 (MSK)

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)




Current thread: