March 2003 - Test - lists.nanog.org

RE: scope of the 69/8 problem
by Cutler, James R 10 Mar '03

10 Mar '03

RE: "If the roots and gTLDs are truly unwilling to help..." The cost of installing entirely new root hints files on every Internet-attached name server around the world is ridiculously large. It has nothing to do with willing. Perhaps, if the problem were defined in proper terms, and a solution involving moving, for example, .net or .org to the blackballed space were made to the registry/DNS owners, a discussion of real possible events could ensue. In the meantime, most of the discussion in this thread is wasted time and going to the wrong targets. - James R. Cutler, EDS 800 Tower Drive, Troy, MI 48098 1 248 265 7514 james.cutler(a)eds.com -----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: 2003-03-10, Monday 6:23 PM To: nanog(a)merit.edu Subject: scope of the 69/8 problem FS> Date: Mon, 10 Mar 2003 17:41:56 -0500 FS> From: Frank Scalzo FS> Moving all root-servers WOULD fix the problem. Although I doubt FS> anyone is really going to be willing to make the news by causing FS> that much of an outage. I'm eager to see stats indicating how large the problem is. If the problem is this severe, it seems all the more wrong to let innocent third parties suffer due to what IP space was bestowed upon them. If the roots and gTLDs are truly unwilling to help, and a handful of entities can't cooperate, I have serious concerns why they have been handed responsibility for such a critical piece of infrastructure. I'd expect "it's too hard to be a good netizen" whining on other lists... but NANOG? Roots and TLDs? Perhaps this is an omen of the Internet yet to come. Oh joy. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

2 1

Fwd: Re. Port 445 issues (was: Port 80 Issues)
by Jonathan Claybaugh 10 Mar '03

10 Mar '03

A fine gentleman in New Zealand passed this information along. A nice in-depth analysis. A sign of infection seems to be heavy outbound traffic on 5800 and 5900, which could be useful if you want to stop an outbound flood without null routing the destination network. -----Original Message----- From: Arjen De Landgraaf Sent: Monday, 10 March 2003 12:18 p.m. To: 'Jonathan Claybaugh'; nanog(a)merit.edu Subject: RE: Port 445 issues (was: Port 80 Issues) E-Secure-IT issued a security alert on Saturday New Zealand Time. Info: This attack is currently intensifying. (See the DShield port 445 graph website at the bottom of this alert for info on increase.) For updates we strongly advise subscribers to activate their alert notifications on the E-Secure-IT folder: "Port 445 Worm info" in location: http://www.e-secure-it.co.nz/dscgi/ds.py/View/Collection-2519 New info on 445 will not be placed in this Virus Alert folder anymore, but only in the new port 445 folder instead. This is done to keep the "virus alerts" free for not 445 related alerts. Analysis (combined info from messages collected in the port 445 folder): Early indication of possible infection: 1. Your infrastrucutre contains server(s) running Windows 2000 or NT 2. Server(s) have (incoming) port 445 open 3. Outgoing ports 5800 and 5900 opened (activated by worm) 4. Server(s) sending large quantities of packets to 445 out with consecutive IP's as destination addresses. 5. Servers contain a Dvldr32.exe executable (responsible for outgoing packets) Other indications(see also file analysis further down this alert): Possible Abnormal files installed: file size dvldr32.exe %windir%/system32(NT/2K)%windir%/system(9x) 745,984 explorer.exe %windir%/fonts 212,992 omnithread_rt.dll %windir%/fonts 57,344 VNCHooks.dll %windir%/fonts 32,768 rundll32.exe %windir%/fonts 29,336 cygwin1.dll %windir%/system32(NT/2K) 944,968 cygwin1.dll %windir%/system(9x) 944,968 C:\WINDOWS\Start Menu\Programs\Startup\inst.exe 684,562 C:\WINNT\All Users\Start Menu\Programs\Startup\inst.exe 684,562 Possible Register changes: The regedit table is modified as follows: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run] "TaskMan"="C:\\WINDOWS\\Fonts\\rundll32.exe" "Explorer"="C:\\WINDOWS\\Fonts\\explorer.exe" [HKEY_CURRENT_USER\Software\ORL] [HKEY_CURRENT_USER\Software\ORL\WinVNC3] "SocketConnect"=dword:00000001 "AutoPortSelect"=dword:00000001 "InputsEnabled"=dword:00000001 "LocalInputsDisabled"=dword:00000000 "IdleTimeout"=dword:00000000 "QuerySetting"=dword:00000002 "QueryTimeout"=dword:0000000a "Password"=hex:[here we do some shields] "PollUnderCursor"=dword:00000001 "PollForeground"=dword:00000001 "PollFullScreen"=dword:00000001 "OnlyPollConsole"=dword:00000001 "OnlyPollOnEvent"=dword:00000001 [HKEY_CURRENT_USER\Software\ORL\VNCHooks] [HKEY_CURRENT_USER\Software\ORL\VNCHooks\Application_Prefs] [HKEY_CURRENT_USER\Software\ORL\VNCHooks\Application_Prefs\EXPLORER.EXE] Dvldr32.exe analysis: Dvldr32.exe is packed by Aspack. This virus, which is written by MS VC6.0, send out amount of packages with the aim to infect the network. This File also include 3 executable files. Two of them are "Psexesvc" and "Remote process lancher". They are command tools which published by Sysinternals Corporation. They don't create to the file system, and been called by the Dvldr32.exe only. Another program is a install package which made by a uncommon install tool. The package include 5 files,3 of them (Explorer.exe,VNCdll32.dll and Omnithread_rt.dll) are networking managerial tools which belong to the corporation AT&T. Rundll32.dll is not the normal one in the Microsoft operating system. It maybe a Linux's program which transplanted to Windows. Spread principle: When running , the program will select 2 IP sections in random and connect the target host's port on 445 to get networking package. Once the target machine's administrator's password is null or in the list following here , the program will copy itself to its system. Passwords tried by worm to enter system: No password "admin" "Admin" "password" "Password" "1" "12" "123" "1234" "12345" "123456" "1234567" "12345678" "123456789" "654321" "54321" "111" "000000" "00000000" ."11111111" "88888888" "pass" "passwd" "database" "abcd" "abc123" "oracle" "sybase" "123qwe" "server" "computer" "Internet" "super" "123asd" "ihavenopass" "godblessyou" "enable" "xp" "2002" "2003" "2600" "0" "110" "111111" "121212" "123123" "1234qwer" "123abc" "007" "alpha" "patrick" "pat" "administrator" "root" "sex" "god" "foobar" "a" "aaa" "abc" "test" "test123" "temp" "temp123" "win" "pc" "asdf" "secret" "qwer" "yxcv" "zxcv" "home" "xxx" "owner" "login" "Login" "pwd" "pass" "love" "mypc" "mypc123" "admin123" "pw123" "mypass" "mypass123" Backdoor: The virus uses the regular system managerial tool VNC(edition is 3.3.3.9) (from AT&T) as its backdoor, and installs it to the target computer's operating system. Though some technical disposals, the icon will not appear when VNC is running. Because the VNC cannot connect the computer when the machine is locked, this function is limited. E-Secure-IT collates all available info around this new port 445 attack, We strongly advise subscribers to activate their alert notifications on the E-Secure-IT folder: "Port 445 Worm info" in location: http://www.e-secure-it.co.nz/dscgi/ds.py/View/Collection-2519 For further info on VNC and TightVNC (Virtual Network Computing) - AT&T, see the E-Secure-IT folder: http://www.e-secure-it.co.nz/dscgi/ds.py/View/Collection-729 Web address of updated graphs: http://isc.incidents.org/port_details.html?port=445 E-Secure-IT Administrator www.e-secure-it.us

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Michael.Dillon＠radianz.com 10 Mar '03

10 Mar '03

>> I don't think ARIN can help the situation. ISPs just need to remove the >> access lists from each router in the network and centralize them. >I totally agree with you. However, as always, centralized systems, while >ease management and scalability, everything becomes a trust issue and a >single point of failure or source of problems... Yeah, who would you trust to maintain a centralized database of IP address ranges? >May be, this could be a subscription based type of service, something like >RADB, where everyone subscribes into a central filtering list that is >managed by a seperate organization? Yup, you're right. This should be done by a 3rd party organization, not an ISP. I wonder whether there are any 3rd party organizations trusted by ISPs that have experience in maintaining a database of IP address ranges? ARIN, perhaps? >I really like the Rob's bogon >route-server setup. That's probably because you are a router geek. I have nothing against Rob's setup but I know that the vast majority of geeks know nothing about route-servers and have no incentive to learn about them. But they all know what LDAP is, some of them already run LDAP servers and the rest probably plan to learn more about LDAP some day. We could leverage that widespread knowledge of LDAP by publishing route data (or any other data regarding attributes of IP address ranges) using the IETF standard LDAPv3 protocol. In fact, I know that Rob is considering setting up an LDAP server as an alternative way to offer bogon data. I think this is a great idea as a testbed, i.e. offer the data through many protocols and see which is most popular. Howevere, I think that when it does become popular, it needs to be integrated with ARIN's authoritative database of IP address delegations. -- Michael Dillon

3 2

RE: 69/8...this sucks -- Centralizing filtering..
by Mark Segal 10 Mar '03

10 Mar '03

What surprises me most about this entire thread is the lack of centralized filtering. Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. Regards, mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 > -----Original Message----- > From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: March 10, 2003 10:17 AM > To: nanog(a)merit.edu > Subject: Re: 69/8...this sucks > > > > > Date: Mon, 10 Mar 2003 09:46:33 +0000 > > From: Michael.Dillon > > > > I have suggested that ARIN should set up an LDAP server to > publish the > > delegation of all their IP address space updated > > Not bad, but will the lazy ISPs set up an LDAP server to > track changes they aren't tracking now? Will those with > erroneous filters magically change simply because of LDAP? I > still contend the answer is is a boot to the head that > screams to them, "Update your freaking filters!" > > > Eddy > -- > Brotsman & Dreger, Inc. - EverQuick Internet Division > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 (785) 865-5885 Lawrence and [inter]national > Phone: +1 (316) 794-8922 Wichita > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) > From: A Trap <blacklist(a)brics.com> > To: blacklist(a)brics.com > Subject: Please ignore this portion of my mail signature. > > These last few lines are a trap for address-harvesting > spambots. Do NOT send mail to <blacklist(a)brics.com>, or you > are likely to be blocked. >

11 14

RE: 69/8...this sucks -- Centralizing filtering..
by McBurnett, Jim 10 Mar '03

10 Mar '03

I saw it version of this earlier: Enter configuration commands, one per line. End with CNTL/Z. Router(config)#ip route clueless No seriously.. What if that customer has a VPN design with a dial backup behind their firewall. Using BGP to suck down a default route from the provider, when that default route goes away, then the internal router initiates the dial backup solution to the remote network. They should not be sending out any BGP routes though.. But.. See example above... OR They are in the process of preparing for Multi-homeing and just have not got it up yet... You know one provider is toiling with the T-1 facility FOC etc.. Sure this is somewhat unusual, but I have seen it, and corrected it... Jim >It would be nice if vendors had a variant to (in cisco terms) ip verify >unicast reverse-path that would work in asymmetrical networks. >If you only >have a single link to the internet, the command works well, >but then why >would you ever run bgp for a single uplink? > >-Jack > >

3 2

RE: 69/8...this sucks
by McBurnett, Jim 10 Mar '03

10 Mar '03

>> IIRC, some RFC recommends updating the root zone cache monthly... >> following this would ensure one had proper root/gTLD addresses. >> >> The above also would break DNS for broken networks for a two >> month stretch... long enough to flush out bad rules. >> > > You want to move things like gtld servers, >yahoo/google (and other 'important' things), including >things like oscar.toc.aol.com into these. > > This will leave the clueless to buy a clue and >stimulate the economy ;-) > > - jared Hey if it will be a great Stimulas package I bet we could get congressional research funding to try it..... ;) J

2 1

RE: 69/8...this sucks
by McBurnett, Jim 10 Mar '03

10 Mar '03

>From EB Dreger > >I suggest a rotation like so: > > Jan-Apr: 69.w.w.0 > Apr-Jul: 69.x.x.255 > Jul-Oct: 70.y.y.0 > Oct-Jan: 70.z.z.255 > >where the middle two octets are predetermined ahead of time. > >IIRC, some RFC recommends updating the root zone cache monthly... >following this would ensure one had proper root/gTLD addresses. > >The above also would break DNS for broken networks for a two >month stretch... long enough to flush out bad rules. > > >Eddy Okay, let's assume that we all agree to this.. Who are the players? ARIN, gTLD Owners, and who else? Let's get some emails fired off.. Who is going to ARIN in Memphis? Jack? Dr Race? Volunteers to broach this? Any gTLD owners on list? Let's go for it.. I think this is a great Idea... Maybe we need to look at applying this elsewhere!!!! J

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by McBurnett, Jim 10 Mar '03

10 Mar '03

<SNIP> >Oh, I agree that there are times when BGP is used in a single uplink >scenario, but it is not common. However, someone pointed me to >ip verify >unicast source reachable-via any which seems to be available >on some of the >cisco Service provider releases. It's an interesting concept >and I'm itching >to play with it. If you aren't in my routing table, then why >accept the IP >address? > >-Jack Well, If you don't access my address and I happen to be a poor ole 69/8 or <FILL IN NEW NET BLOCK HERE> then your customers may not be able to get to me... But there are an aweful lot of ifs to this ^^^^^^^^^^. And I don't remember that command syntax at all.... Yea, I want to test that too.. Maybe I can make a visit to the local Cisco office and borrow some time in the Lab.... I want to see this is action, and how it may affect my routing... or maybe I can get a quick answer from the local CCIEs... Hey have you checked the Feature Navigator and seen which versions it is in? Catch me off-list.... Later, J

1 0

Re: 69/8...this sucks -- Centralizing filtering..
by Michael.Dillon＠radianz.com 10 Mar '03

10 Mar '03

>I can think of two organisations which could probably take care of a >good chunk of the problem, if people were prepared to leave it up to >them. The routing system is already largely dependent on the >interoperability of bugs produced by these people, and so arguably no >additional trust would be required. Cisco is already a member of ARIN. If anyone out there buys Juniper routers, perhaps you might suggest that they also join ARIN and work together with Cisco and the network operators to move this forward. --Michael Dillon

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Michael.Dillon＠radianz.com 10 Mar '03

10 Mar '03

>What I really meant by single pt. of failure was... problems of losing the >filtering list if the central system is down... Granted, this would not >cause any network issues.. We know how to set up central authorities without central systems or obvious single points of failure. For instance, the DNS has a single root authority but there are 13 distributed servers publishing authoritative data. And not all of those servers are single systems. For some time now Vixie's root server has been at least two systems using his own FreeBSD kernel hack to handle load balancing and failover. Also, people are beginning to realize that having a local cache of authoritative data is a wise thing and is not very difficult to do. That's why ISC is now offering a replica service for network operators to set up local copies of Vixie's F root server. I would expect that the LDAP service for IP address range attributes would leverage all of this knowledge about architecture. LDAP may a more versatile protocol than DNS but it is clearly from the same family tree of directory service protocols and there are no major roadblocks preventing it from being deployed in a sane fashion. --Michael Dillon

1 0