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)
(1) Build the table:
/ address - the number of neighbour addresses with the uni-directed
(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
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.