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