On Wed, Feb 09, 2000 at 01:11:00PM -0500, Charles Sprickman wrote:
> Hello,
>
> With all the attacks happening these days (yahoo, cnn, etrade, etc.), I'm
> wondering if anyone here could share their techniques for tracking down
> source addresses using netflow (or any other nifty methods you may have).
>
> While many attacks have varying source addresses, some don't and it seems
> possible to at least try to block some of the traffic. Basically what I'm
> looking to do is hopefully start a thread here where we can share info
> about how to identify and quell some of the more common attacks.
>
> Some ideas:
>
> -netflow for dummies
> -quick-n-dirty netflow collector setup
> -using tcpdump/snoop to identify huge flows
> -capabilities of various cisco platforms for flow collection and filtering
> (ie: when will the router just fall over and die)
> -talking to / educating your upstream
>
> Just thought it would be useful for some of us smaller ops on this list to
> start talking about this now rather than at the time someone is being hit
> and is in a panic... This seems like a more appropriate forum than NANOG,
> so I'm posting here, let me know if this is not a good assumption.
I wrote a little txt for educating coworkers a while back:
How to trace spoofed packet streams
Background
Spoofing is the process of claiming to be someone, something, or from
somewhere that you are not. Spoofed IP packets with forged source
addresses are almost always BAD, usually used to hide the origin of
something like a DoS (Denial of Service) attack. Because of the
connectionless nature of the IP/network layer, it is very difficult to
find the true source, or distinguish legitimate packets from spoofed ones.
However, most attacks attempting to consume network or system resources
to deny service involve sending many such packets. As long as routing
remains consistant, these form a logical concept known as a "packet stream"
(think of it like flowing water, with the fluid-like properties of a
stream instead of individual water molecules).
Spoofed packet streams can be traced to their true source by working
backwards from a known point (usually the "victim" or a network egress
point), hop by hop, finding the source interface(s) and moving to that
router, until either a) you find the source of the spoofed packets, or
b) the next hop is device not under your administrative control (someone
elses network), at which point you must contact them and request they
continue the trace. Unfortunantly, many people are not educated in the
techniques of tracing spoofed packet streams, and those that are cannot
always be located in a timely fashion, even in large backbone providers.
AboveNet will not be the one to drop the ball in these situations. :P
Finding the source interface
The Easy Way (log-input):
The easiest method for locating the source interface of a certain type of
packet flow with Cisco equipment and modern IOS is an access-list with the
"log-input" directive. You place an access-list on the downstream interface,
with "log-input" directive on the traffic you wish to watch, and then
permitting everything else. This only disadvantage to this approach is that
placing an access-list can cause CPU strain on an already loaded router,
especially when used on older routers and heavily used interfaces.
core1.iad#conf t
Enter configuration commands, one per line. End with CNTL/Z.
! Create the access list which we will be monitoring, permits so as not to
! disturb anything, we're just looking. 216.200.92.162 is "being attacked".
core1.iad(config)#access-list 169 permit ip any host 216.200.92.162 log-input
core1.iad(config)#access-list 169 permit ip any any
! Apply the access-list on the interface going out to the target or previously
! located next-hop.
core1.iad(config)#int pos3/3
core1.iad(config-if)#ip access-group 169 out
! Wait for a few seconds... One packet per second will be logged, be sure
! to get a fair sized sample so you don't miss anything, usually 5 to 10
! seconds is good.
core1.iad(config-if)#no ip access-group 169 out
core1.iad(config-if)#end
core1.iad#sh ip access 169
Extended IP access list 169 (Compiled)
permit ip any host 216.200.92.162 (50291 matches)
permit ip any any (982813 matches)
! Bingo, looks like we've got a winner
core1.iad#sh log
...
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 186.15.46.2(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 115.230.162.206(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 63.67.171.136(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 247.222.61.101(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 31.67.251.29(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 76.114.4.35(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
SLOT 2:2d01h: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 8.46.19.5(0) (POS1 *HDLC*) -> 216.200.92.162(0), 1 packet
! Ding ding ding... Random source SYN flood coming in from pos2/1, one of the
! obvious earmarks is the IPs. If you can't tell it just from looking at those IPs, the
! block 64.0.0.0/2 is reserved, so that 76.114.4.35 is a dead giveaway.
! Don't forget to clean up your mess.
core1.iad(config)#no access-list 169
core1.iad#sh int pos2/1
POS2/1 is up, line protocol is up
Hardware is Packet over SONET
Description: OC3 to core2.nyc, AboveNet 03-NYC-IAD-0001, 1-408-367-6666
Internet address is 209.249.203.106/30
! Proceed to the next hop, 209.249.203.105, and repeat.
The really really obnoxious way (flow stats):
NetFlow switching is an alternative Cisco switching mechanism designed to
increase the efficiency of access-lists (which only need to be exaustively
searched at the beginning of the flow instead of for every packet in the
flow), and to provide for fine-grain traffic pattern analysis. It is much
less disruptive on underpowered routers then an access-list, but also more
difficult to use, requiring you to test almost every interface one at a
time until you find the correct one. On a GSR, flow is entirely distributed
and will not goto the GRP, so you probably don't want to even bother, just
use log-input.
In order to use NetFlow, you must activate it on the interface (the one which
will show up as SrcIf) in question with "ip route-cache flow". NetFlow can be
used in conjunction with other switching methods, such as CEF and Fast
Switching, however when distributed fast-switching is enabled only those
packets passed up to the RSP will show up in the flow cache (traffic destined
for null0 and for the router itself). You will need do disable distributed
switching with the "no ip route-cache distributed" command on each interface
you wish to test. As long as CEF is enabled, it will be used for forwarding.
chicago#wr t
...
interface POS0/0/0
description OC3 crossconnect to core1.ord:pos0/2
ip address 216.200.254.90 255.255.255.252
no ip directed-broadcast
ip pim sparse-dense-mode
no ip route-cache optimum
ip route-cache distributed
ip ospf cost 145
pos scramble-atm
hold-queue 300 in
hold-queue 300 out
...
chicago#conf t
Enter configuration commands, one per line. End with CNTL/Z.
chicago(config)#int pos0/0/0
chicago(config-if)#ip route-cache flow
chicago(config-if)#no ip route-cache distributed
chicago(config-if)#ip route-cache distributed
chicago(config-if)#end
chicago#sh ip cache flow | inc 216.200.92.162
...
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa11/0/0 171.215.150.86 AT1/0 216.200.92.162 06 99A4 081E 1
Fa11/0/0 137.153.105.67 AT1/0 216.200.92.162 06 86AF 8E4D 1
Fa11/0/0 185.119.145.108 AT1/0 216.200.92.162 06 2EA2 FE87 1
Fa11/0/0 123.84.18.102 AT1/0 216.200.92.162 06 31AF 98A2 1
Fa11/0/0 185.193.169.80 AT1/0 216.200.92.162 06 2EA5 FE09 1
Fa11/0/0 253.73.43.19 AT1/0 216.200.92.162 06 8CAE F2C6 1
Fa11/0/0 121.192.137.65 AT1/0 216.200.92.162 06 CEB0 BE01 1
Fa11/0/0 45.7.139.108 AT1/0 216.200.92.162 06 34AE 62F4 1
Fa11/0/0 175.77.156.74 AT1/0 216.200.92.162 06 87A5 BC95 1
Fa11/0/0 45.228.119.119 AT1/0 216.200.92.162 06 B4AB 620D 1
Fa11/0/0 87.222.160.16 AT1/0 216.200.92.162 06 B3A6 445D 1
Fa11/0/0 77.108.47.74 AT1/0 216.200.92.162 06 24AF 02C3 1
Fa11/0/0 221.196.111.127 AT1/0 216.200.92.162 06 9CA9 5258 1
Fa11/0/0 199.1.168.117 AT1/0 216.200.92.162 06 7BAF F493 1
Fa11/0/0 59.116.238.53 AT1/0 216.200.92.162 06 51AF 58A7 1
Fa11/0/0 181.87.159.5 AT1/0 216.200.92.162 06 90B0 4AAE 1
Fa11/0/0 169.146.161.81 AT1/0 216.200.92.162 06 76AF 2E20 1
Fa11/0/0 199.221.72.15 AT1/0 216.200.92.162 06 7BA1 F43F 1
In case this format isn't clear, lets explain a few things. First of all
its in hex to save space. Under protocol, 0x06 is TCP, 0x11 is UDP, and
0x01 is ICMP. Other protocol numbers can be found in RFC 1700 or
/usr/include/netinet/in.h on your nearest unix machine. Port numbers are
in hex, big endian (network byte order), if you get bored enough to decode
them.
Tracing across a shared access medium (Ethernet):
The only effective way to do this is with an access-list and log-input.
The only difference is, the results will look something like this:
main3.sjc#sh log
...
Jan 10 2:26:04.379: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 6.190.253.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
Jan 10 2:26:05.379: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 180.86.222.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
Jan 10 2:26:06.379: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 85.64.240.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
Jan 10 2:26:07.379: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 164.130.218.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
Jan 10 2:26:08.379: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 103.113.155.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
Jan 10 2:26:09.399: %SEC-6-IPACCESSLOGP: list 169 permitted tcp 71.82.200.0(0) (FastEthernet3/0/0 00d0.bc83.58a0) -> 206.252.192.20(0), 1 packet
You then resolve the hardware MAC address to an IP with:
main3.sjc#sh ip arp 00d0.bc83.58a0
Protocol Address Age (min) Hardware Addr Type Interface
Internet 209.249.192.32 15 00d0.bc83.58a0 ARPA FastEthernet3/0/0
Name: kt-abovenet.sjc.kt.co.kr
Address: 209.249.192.32
-- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - ISX Network Engineer, Vienna VA
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:09 EDT