Hi,
Just wanted to post a quick thanks to you all for supplying some great
info... I especially appreciate Richard sharing his quick-ref, very nice,
very clever stuff.
Thanks to all for sharing and spreading the wealth, it's very much
appreciated. If there's value (and permission) to cobble all this info
together onto a webpage, I'd be happy to do it.
thanks,
Charles
On Wed, 9 Feb 2000, Richard Steenbergen wrote:
> 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
>
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:10 EDT