|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Yahoo! Lessons Learned
Hello NANOG folks...(this is rather long, sorry) In light of those new attacks i decided to demonstate that some NSPs are as clueless as those DoS monkies. lets take a look at 206.251.5.238 [noc:/usr3/staff/basil/work/security/DoS-attacks/jan30-2000/2nd]: ll total 64 -rw-r--r-- 1 basil staff 1614 Jan 30 16:27 amps -rw-r--r-- 1 basil staff 62058 Jan 30 16:23 jan30-smurf -rw-r--r-- 1 basil staff 68 Jan 30 17:23 possible-idiots let me demonstate: from jan30-smurf file. icmp 207.204.18.146 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 12.2.79.2 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 132.248.1.27 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 146.64.123.161 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 194.52.223.39 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet etc... full list of amps/logs are available upon request.. during the attack there was 2 traceroutes, probably to see our "network performance" ;) Jan 30 15:46:20 gw 748: *Jan 30 15:46:00: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33462), 1 packet Jan 30 15:46:25 gw 749: *Jan 30 15:46:06: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33463), 1 packet etc... Jan 30 15:46:20 gw 748: *Jan 30 15:46:00: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33462), 1 packet Jan 30 15:46:25 gw 749: *Jan 30 15:46:06: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33463), 1 packet 202.216.31.97 webserv1.dlinx.co.jp 206.251.5.238 www3.galttech.com route-views.oregon-ix.net>traceroute 206.251.5.238 Type escape sequence to abort. Tracing the route to www3.galttech.com (206.251.5.238) 1 nero-eugene-hub.oregon-ix.net (198.32.162.2) [AS 2914] 4 msec 0 msec 0 msec 2 eugene-isp.nero.net (207.98.64.41) [AS 3701] 0 msec 4 msec 0 msec 3 xcore2-serial0-1-0.SanFrancisco.cw.net (204.70.32.5) [AS 3561] 16 msec 16 msec 8 msec 4 bordercore1.SanFrancisco.cw.net (166.48.12.1) [AS 3561] 16 msec 12 msec 12 msec 5 frontier-communications.SanFrancisco.cw.net (166.48.13.242) [AS 3561] 536 msec 508 msec 560 msec 6 pos1-0-0-155M.hr3.SNV.gblx.net (206.251.0.113) [AS 3549] 552 msec 448 msec 436 msec 7 www3.galttech.com (206.251.5.238) [AS 3549] 436 msec 388 msec 404 msec XX pos0-0-0-155M.hr3.SNV.gblx.net (206.132.150.210) | 13 Mb/s, 433 us (86.3 ms), +q 19.5 ms (31.7 KB) *2 <--Ethernet! XX www3.galttech.com (206.251.5.238) Now lets get on that box, virtually of course, and see what is going on there - http://www.thebigboss.com/opt/ (don't ask where we got this info from, lets just say we have an informant, note: he/she is not one of those DoS kiddies) According to the same person, *.jp proxies are being used to access that box, to run those atacks. 9 hours before that smurf we were under another one of those Distributed DoSes, [noc:/usr3/staff/basil/work/security/DoS-attacks/jan30-2000/]: ll total 90 drwxr-xr-x 2 basil staff 512 Jan 30 17:23 2nd/ -rw-r--r-- 1 basil staff 4003 Jan 30 11:59 acl-110 -rw-r--r-- 1 basil staff 65796 Jan 30 11:42 jan30-2000 Jan 30 09:45:07 gw 93: *Jan 30 09:44:48: %SEC-6-IPACCESSLOGP: list 110 denied tcp 195.42.93.14(1671) (Serial1/0 *HDLC*) -> 207.152.95.11(7), 1 packet Jan 30 09:45:09 gw 95: *Jan 30 09:44:49: %SEC-6-IPACCESSLOGP: list 110 denied tcp 158.117.186.23(1545) (Serial1/0 *HDLC*) -> 207.152.95.11(9), 1 packet Jan 30 09:45:10 gw 96: *Jan 30 09:44:51: %SEC-6-IPACCESSLOGP: list 110 denied tcp 146.158.235.55(1893) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet Jan 30 09:45:10 gw 97: *Jan 30 09:44:52: %SEC-6-IPACCESSLOGP: list 110 denied tcp 158.54.158.117(1289) (Serial1/0 *HDLC*) -> 207.152.95.11(7), 1 packet Jan 30 09:45:12 gw 99: *Jan 30 09:44:53: %SEC-6-IPACCESSLOGP: list 110 denied tcp 160.137.84.13(1982) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet Jan 30 09:45:13 gw 101: *Jan 30 09:44:54: %SEC-6-IPACCESSLOGP: list 110 denied tcp 147.128.16.56(1527) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet etc..i suspect the same kiddies did it 206.251.5.238... The box is still up and running and kiddies are still [d]DoSing from that server. ---- Lessons to be learned (?) * ip verify unicast reverse-path, works and works quite nicely. * if you can't do unicast reverse-path for some reason, do this deny ip 0.0.0.0 255.255.255.0 any log-input deny ip 0.0.0.255 255.255.255.0 any log-input deny ip any 0.0.0.0 255.255.255.0 log-input deny ip any 0.0.0.255 255.255.255.0 log-input * i think it is time for some ISPs/NSPs to re-think their network policies for example: how about CARing ICMP and related crap at MAEs/NAPs as well as at private interconnections? How about putting nice filters for every non-BGP/singlehomed customer to prevent them from spoofing? Ever try calling Sprint, Level3, @HOME/@WORK, UUnet, Qwest/Iconnet, Corecomm, Savvis etc.. etc.. [with few exceptions, BBNPlanet/ISPDirect and C&W], asking them to shutdown their amps or to track down those [d]DoSes? And how about releasing phone numbers for Security Departments, and not those free-toll dialup support monkies who has no clue wtf is going on. besides they won't transfer you to the real NOC or Security because you're not a customer/peer. Another excuse "our policy states that you have to send logs to abuse/security @ company... and they will take a look at it in the morning." Sometimes you just can't wait, and blackholing isn't really an option. Sometimes we get telephone calls in the middle of a night, "why is your X.X.X.X flooding our entire network?" Guess what, moron, you're the one who's flooding.. go fix it.. and they quickly hung up, 90% of the time they don't know how to fix [http://www.quadrunner.com/~chuegen/smurf.cgi] nor care "its only affecting our network at night...who cares.. we're fine during the day!" To summarize: How about taking those [d]DoSes seriously? Educate your NOCs, impliment new policies, new ACLs/CAR. Force your downstreams & peers to do the same. oh and by the way: *for all those stock holders* If i'm not mistaken, Exodus and few others cannot put ACLs/CAR for their customers (policies.. policies... politics, apparantely DoSes are good for their stock ;) X0 Mbps attack tcp/udp attack for Y number of hours and poor customer will end up paying couple more Ks than he/she usually does. Now lets multiple those X/Y... flood those non high-profile sites and you will get nice check every month. even better, just flood your competition out of business, some people just can't afford Flat 100Mbps/Gigabit pipes. -Basil Kruglov My current ratio is 1.5:1 (one, sometimes two DoS[es]:daily), whats yours?
|