Re: [nsp] packet tracing

From: Jon Lewis (jlewis@inorganic5.fdt.net)
Date: Sun Jun 28 1998 - 14:38:04 EDT


A few people asked for summaries...so here goes.

Here's a helpful suggestion from J Rowley <jrowley@groovin.org>. I'd
played with ip accounting on a 2501 long ago, but had forgotten it could
be of use for tracking the sort of attack one of our customers was
responsible for. I've not used this to while tracking an attack yet, but
it looks like it may be the best solution...at least for finding the
source and destination IPs of the traffic. Just turn on ip accounting on
the interface the traffic is coming from and watch the stats build up. In
the case of a ping flood without forged saddr, in no time, you should see
the IPs involved.

> IP Accounting:
>
> config t
> int s4/4
> ip account
> CNTL-Z
>
> clear ip account
> show ip account
>
> which will gives you the source, destination addresses and number of
> packets and bytes.

J Rowley also suggested access-lists applied to the interface the traffic
came from. I'd already been doing that to nail down what protocol was
being used (was it icmp, udp, tcp).

As for real sniffing, the "debug ip packet access-list#" works, but I'd
missed one step. I'd been turning off the ip route-cache on the
interface the traffic was coming into the router from. The online help
made it pretty obvious I needed to turn off ip route-cache on the
interface through which the traffic was _leaving_ my router. Once I did
that, I was burried with packet info, CPU load on the 3640 shot up to 99%,
BGP sessions cleared, and for a moment, I thought we were going to have to
reboot...but it came back to normal on its own.

I was able to cut/paste the data from my xterm, save it to a file, run the
file through awk and sort, and see where all the traffic was coming from.

It appears the ip accounting option doesn't even impact CPU load...so it's
probably a better place to start when tracing an unusually high bandwidth
packet flow.

Now...for my next windmil to attack...I've noticed via my BGP
distribute-list input filter that someone else appears to occasionally
announce our CIDR block. i.e. I use the following:

Extended IP access list 190
    deny ip 10.0.0.0 0.255.255.255 any
    deny ip 172.16.0.0 0.15.255.255 any
    deny ip 192.168.0.0 0.0.255.255 any
    deny ip 127.0.0.0 0.255.255.255 any
    deny ip 0.0.0.0 0.255.255.255 any
    deny ip 224.0.0.0 31.255.255.255 any
    deny ip host 192.0.0.0 host 255.0.0.0
    deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255
    deny ip 209.212.128.0 0.0.31.255 any log-input
    permit ip any 0.0.0.0 255.255.255.0 (407451 matches)
    deny ip any any (189 matches)

For the line "deny ip 209.212.128.0 0.0.31.255 any" I regularly see some
matches. This must have been a slow weekend as there aren't any for that
or the private IP blocks. I played around with log and log-input, but
neither gives me any info other than the fact that the route was received
and blocked. If possible, I'd like to find out who is announcing our CIDR
block (i.e. an AS path would be nice) so I can have a talk with them.
Does anyone know of a way to do so? Should I just change that line to a
permit with log, so I can hopefully see it via sh ip bgp 209.212.128.0
after I see it log the route, or will my router refuse it even without the
access-list?

------------------------------------------------------------------
 Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
 Network Administrator | drawn and quartered...whichever
 Florida Digital Turnpike | is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____





This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:14 EDT