Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Yahoo! Lessons Learned

  • From: Basil Kruglov
  • Date: Wed Feb 09 15:56:29 2000

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?





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.