August 2001 - Test - lists.nanog.org

Right way to gum up CodeRed (I think)
by M. David Leonard 20 Aug '01

20 Aug '01

Guys- There is a neat 'tarpit' package called LaBrea. It runs off a single boot floppy (Trinux, I believe), supports vifs, and is verrrry sticky on incoming TCP/IP connections. Install it on an old clunker machine you've got lying around collecting dust. Give it some unassigned (and unadvertised) IP addresses in your block and let it cling for up to 24 minutes on each connection attempt. Slows CodeRed right down, with a minimum of bandwidth wasted. IMHO it sounds much better than 50MB 'default.ida' files. Plus, it does the same to script kiddies trying to run a port scan. David Leonard ShaysNet

2 1

RE: LaBrea tarpit info and URL
by Roeland Meyer 20 Aug '01

20 Aug '01

|> From: Patrick Greenwell [mailto:patrick@cybernothing.org] |> Sent: Sunday, August 19, 2001 6:01 PM |> |> On Sun, 19 Aug 2001, M. David Leonard wrote: |> |> > -------- Original Message -------- |> > From: "Tom Liston" <tliston(a)premmag.com> (by way of Matt Fearnow |> > <matt(a)incidents.org>) |> > Subject: [unisog] New tool: LaBrea |> > To: unisog(a)sans.org |> > |> > OK folks, the time has come to fight back... |> > |> > Following up on my original work on CodeRedneck, I'm |> pleased to announce a |> > new tool to let us *ethically* take a stand. Come on... |> let's build us |> > some tarpits. |> |> Yawn. So someone adds a timeout to their |> scanner/worm/whatever. "Problem" |> solved. Didn't we try something like this wrt email address scanners? Only in that case, we actually tried to poison them. I don't believe that worked very well either. In addition, it melts down the saint runs you do to manage your own networks. For various sizes of LANs, this is a problem. However, a tcp_wrappers boobie-trap mightn't be such a bad idea. It detects a scan from outside the net-block and tries it's level best to return the favor with a saint run, reporting whatever it finds. Of course, one needs a solution for the deadly-embrace problem. Once CodeRed infestation is confirmed, one has a variety of options. 1) Send demand letter to infested host's owner, to cease and desist. 2) Raise automated blocks, for that host, at your border (adaptive shielding). 3) Use the CodeRed backdoor to force that host to shutdown, or worse. However, LaBrea seems useless.

1 0

RE: LaBrea tarpit info and URL
by Joe Blanchard 19 Aug '01

19 Aug '01

David, thanks for this information. Finally a bit of useful commentary regarding CodeRed and perhaps a partial rebuttal to it. -Joe -----Original Message----- From: M. David Leonard [mailto:mdl@equinox.shaysnet.com] Sent: Sunday, August 19, 2001 5:38 PM To: nanog(a)nanog.org Subject: LaBrea tarpit info and URL I have received a few requests for more information on LaBrea, so I am forwarding the e-mail describing it to the nanog list. I apologize if this is off-topic. David Leonard ShaysNet -------- Original Message -------- From: "Tom Liston" <tliston(a)premmag.com> (by way of Matt Fearnow <matt(a)incidents.org>) Subject: [unisog] New tool: LaBrea To: unisog(a)sans.org OK folks, the time has come to fight back... Following up on my original work on CodeRedneck, I'm pleased to announce a new tool to let us *ethically* take a stand. Come on... let's build us some tarpits. Announcing: LaBrea LaBrea is a Linux boot disk, based on the Trinux/Linux distribution (http://www.trinux.org) combined with the techniques used by CodeRedneck to set up a "tarpit" on your netblock. Essentially, what LaBrea does is to create "virtual machines" on your unused IP addresses, firewall them, and then latch onto any inbound traffic by using TCP/IP's tenacity against anyone who tries to connect. You have a bunch of unused IPs? Here's what you do: Get yourself an old machine and a generic NIC. The machine doesn't need to be a barn burner (see below). Heck, it doesn't even need a hard drive! LaBrea is run from a RAM disk. Hook your old doorstop machine up to the network, somewhere where the portscanners will be sure to find it... Download the LaBrea boot disk image from http://www.threenorth.com/LaBrea (Many, *many* thanks to Tim Rushing for hosting this for me!) Create a real, live boot disk from the image. See instructions at: http://trinux.sourceforge.net/install.html (Don't worry... it's easy. You can do it from Windows or Linux...) You'll need to pick a main IP address for the LaBrea machine. This IP address will temporarily need HTTP access to download the packages needed by Trinux to boot. You'll also need to know the netmask of the IPs you want to use, as well as your gateway address and the address of a DNS server. Now, using any text editor, create a list of the IPs (one per line) that you want to teergrube and save it on the boot floppy under /tux/config as a file named "LaBrea". (Note: DON'T include the "main" IP address in this list... it will be taken care of automatically.) Pop the LaBrea disk into your machine, and boot 'er up. It *should* recognize your NIC and fire off. If it doesn't... well, look around at the Trinux site for help. (I've fired it up on three machines here with three different NICs and it recognized every one of them...) It'll ask you some questions. First of all, DON'T DO DHCP ADDRESS RESOLUTION. It won't work, I disabled it, but I didn't feel like digging through the innards of the Trinux boot disk to remove the question. So just don't do it... OK? Since it can't use DHCP, here's where you'll need to know the IP address, netmask, gateway, etc... (Remember? I told you that you'd need to know that...) Answer the questions, and the boot disk will set up the network connection and then it'll go out and grab any additional files that it needs to set up and run. The machine will then alias itself to all of the IPs that you listed. It will use iptables to DROP all inbound TCP connections, and then it will launch LaBrea to teergrube ALL connection attempts to those IP addresses. *ALL* TCP CONNECTION ATTEMPTS. ON **EVERY** PORT. :-) :-) :-) To make the process more automatic the next time you boot, drop into BASH and run the command "savecfg". That'll save your IP address, netmask, etc... back out to the floppy so it won't have to ask you about it if you reboot. How well does it work? Well, currently I have a 50 IP "tarpit" running on an old Pentium 233 that was sitting around without a HDD. From the logfiles, I pulled the following information after booting it up and running it for about 45 minutes. I picked a pretty generic 10 minute "chunk" of time and followed all of the initial connections that came in: During my 10 minute sample, I had 54 inbound connections. Now remember, these are previously *UNUSED* IP addresses. There is no reason for anything to come after them. All inbound connections were to port 80. (Gee, I wonder what that's from ;-) I held onto those 54 connections for an average of 1 minute 41 seconds each. Therefore, in that 10 minute period, I wasted 1 hour 30 minutes and 32 seconds of CodeRed scanning time. But folks, CodeRed is running on NT, and NT has a *short* TCP time out. What this does to CodeRed connections ain't nothin' compared to what it'll do to a Linux based RPCPortmapper scanner: TWENTY FOUR MINUTES a connection! Did I mention that LaBrea is set up to minimize impact on your network? Using TCP window advertisement, LaBrea chokes down the inbound packets to 10 data bytes each. Let's see... I held onto that RPC scanner for 24 minutes, and all he got to send me was 170 bytes of data... This is fun.... Man, this is fun. I can't think of a time I've enjoyed my job more... Some background: My original proposal can be found here: http://www.incidents.org/archives/intrusions/msg01215.html Mihnea Stoenescu's validation of the idea is described here: http://www.incidents.org/archives/intrusions/msg01239.html The announcement of CodeRedneck: http://www.incidents.org/archives/intrusions/msg01262.html Many thanks to Mihnea Stoenescu, Donald Smith, and Tim Rushing for all of their help on this. -TL

1 0

RE: trolled! (Re: Code Red 2 Erratication)
by Joe Blanchard 19 Aug '01

19 Aug '01

Nuff said, I'm tired of getting email from net.kook as well. Sorry all but the thought is that sending back a few packets to a Victimizing system is bad has got me mad. Sorry to have wasted packets on this. -Joe -----Original Message----- From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] Sent: Sunday, August 19, 2001 3:15 AM To: nanog(a)nanog.org Subject: trolled! (Re: Code Red 2 Erratication) On Sun, Aug 19, 2001 at 02:49:05AM -0700, Joe Blanchard wrote: > Who was/is talking about a DOS??? I wasn't. Your impling that my fix (which > doesn't work and I've gotten many responses about having "tried that") > causes a DOS. Um, Please re-evaluate the data I have shared. There is > NOTHING I have offered that is not already known. You come to my website, > ask for a file (default.ida) and I send it to you, Wheres the DOS in that? > Legal or not, Um, next case... [.. fragment of private thread deleted ..] *sigh* The answers are in your inbox. I'm signing off from this thread now, it's gotten just a little too surreal for me after we've been discussing this for the past several hours in a private thread. Joe, you win. I'm such an idiot for once again being trolled by a net.kook. Please, somebody turn up the noise level (another spam flame war, yes? please?) to drown out the pain before the rest of the NANOG flame horde chimes in. Is there a cure for this or is it terminal? :^) Foolishly trolled, Chris -- Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."

2 1

RE: Code Red 2 Erratication
by Joe Blanchard 19 Aug '01

19 Aug '01

Who was/is talking about a DOS??? I wasn't. Your impling that my fix (which doesn't work and I've gotten many responses about having "tried that") causes a DOS. Um, Please re-evaluate the data I have shared. There is NOTHING I have offered that is not already known. You come to my website, ask for a file (default.ida) and I send it to you, Wheres the DOS in that? Legal or not, Um, next case... -----Original Message----- From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] Sent: Sunday, August 19, 2001 2:34 AM To: Joe Blanchard Subject: Re: Code Red 2 Erratication On Sun, Aug 19, 2001 at 02:02:10AM -0700, Joe Blanchard wrote: > With regard to the legality of sending back such packets I have to laff, and > hard at this. Your certainly under some misguided Idea that the laws have > actually any presidense in this case, that is regarding sending back packets > to an attacking party that kills their OS. The infected host is not what matters, and none of my recent statements have been about 'killing somebody's OS' if you read them carefully. As I tried to explain to you before, hypothetically speaking, if you happen to take out, say, a DSL cloud (if you had a larger pipe or used different method of responding to the probe which wasn't as bw intensive and caused greater damage proportional to bw used), perhaps take the ATM cloud out with it because of, for instance, massive demand for bw.. you're in essence enacting a DoS and are subject to the same sort of procedures with which DoS are responded to. I'm amazed your providers aren't taking the same steps with your current problem. Further, if perhaps you end up taking out vital national infrastructure with your attack you will end up facing the consequences (remember, some of the ckts used for inet traffic share resources with the rest of the world). A DoS in response to a DoS can also lead to your networks being cut off from the rest of the world as well. Significant backlash in various colors is not far fetched at all. These scenarios have been discussed quite frequently in various forums as well as in various legal departments, and depending on the circumstances there are legal issues you might want to consider. You might want to consult those in your legal department with background in telecommunications litigation. Go ahead, test the legal system. I am not making this up. It's your choice, not mine. I am trying to share information with you in the hope that it may help you understand the shortcomings of your approach and perhaps helps you find a better solution. It may be worthwhile to take up the typical emergency response procedures and do things like summarize the ip addrs of the offending hosts with individual date/timestamps and submit them to providers with the remark that they are causing a DoS on your network. The fact that your direct providers aren't willing to help you as the customer is very regrettable. You might also have angles by engaging your legal department depending on what sort of contracts you have with your provider(s). Contesting the billing sometimes gets a provider's attention. I don't see why escalating thru your provider up the food chain doesn't get you results. The reply that it is 'too difficult' most certainly doesn't ring true in this matter. I don't speak for or represent BellSouth. The Security & Abuse team @ BellSouth.net can be reached at abuse(a)bellsouth.net and in general that should be your primary point of contact if you have issues with BellSouth.net customers. If you have any problems with BellSouth.net responding to your requests feel free to contact me and perhaps I can help with the escalation. If you have any other questions, send them on. -- Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. I speak for myself only."

4 3

RE: Code Red 2 Erratication
by Joe Blanchard 19 Aug '01

19 Aug '01

Never mind, seems to do nothing that I can see. Oh Well -Joe -----Original Message----- From: Joe Blanchard Sent: Saturday, August 18, 2001 10:40 PM To: nanog(a)merit.edu Subject: Code Red 2 Erratication Not sure if this will do anything, but perhaps it will. I created a file on several Appache servers called default.ida containing garbage and weighting about 50 megs in size. I've not had a chance to test the effects on the CodeRed worm infected boxes nor the results of this, but it in theroey should choke them. I know it choked my browser, at least in netscape on a linux box and then an IE5 browser on a MS box. Maybe a fix? Who knows. -Joe

1 0

Code Red 2 Erratication
by Joe Blanchard 19 Aug '01

19 Aug '01

Not sure if this will do anything, but perhaps it will. I created a file on several Appache servers called default.ida containing garbage and weighting about 50 megs in size. I've not had a chance to test the effects on the CodeRed worm infected boxes nor the results of this, but it in theroey should choke them. I know it choked my browser, at least in netscape on a linux box and then an IE5 browser on a MS box. Maybe a fix? Who knows. -Joe

1 0

The Cidr Report
by CIDR Report 18 Aug '01

18 Aug '01

This is an auto-generated mail on Fri Aug 17 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 17Aug01 0) General Status Table History ------------- Date Prefixes 100801 102845 110801 102706 120801 102533 130801 102657 140801 102662 150801 102621 160801 102577 170801 102866 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11408 Number of ASes announcing only one prefix: 6792 (3875 cidr, 2917 classful) Largest number of cidr routes: 852 announced by AS701 Largest number of classful routes: 1406 announced by AS701 1) Gains by aggregating at the origin AS level --- 17Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1258 970 288 22.9% Telstra Pty Ltd AS701 1406 1188 218 15.5% UUNET Technologies, Inc. AS2551 798 637 161 20.2% ICG NetAhead, Inc AS4151 289 165 124 42.9% USDA AS4293 379 270 109 28.8% Cable & Wireless USA AS6595 164 58 106 64.6% DoD Education Activity Network As AS577 294 188 106 36.1% Bell Advanced Communications Inc. AS16473 173 70 103 59.5% Bell South AS13999 113 11 102 90.3% Mega Cable S.A. de C.V. AS705 245 145 100 40.8% UUNET Technologies, Inc. AS6429 200 103 97 48.5% AT&T Chile Internet S.A. AS7018 741 652 89 12.0% AT&T AS4755 210 123 87 41.4% Videsh Sanchar Nigam Ltd. Autonom AS7046 324 254 70 21.6% UUNET Technologies, Inc. AS724 231 164 67 29.0% DLA Systems Automation Center AS6471 123 60 63 51.2% ENTEL CHILE S.A. AS12302 94 33 61 64.9% MobiFon S.A. AS1239 457 398 59 12.9% Sprint AS4200 126 68 58 46.0% Apex Global Information Services, AS3464 148 91 57 38.5% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS703 309 254 55 17.8% UUNET Technologies, Inc. AS3908 320 266 54 16.9% Supernet, Inc. AS226 147 94 53 36.1% Los Nettos AS1 543 490 53 9.8% BBN Planet AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS209 284 232 52 18.3% Qwest AS4323 240 189 51 21.2% Time Warner Communications, Inc. AS17561 113 62 51 45.1% Internet service provision to Wes AS855 145 95 50 34.5% Canadian Research Network For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

2 1

Re: verizon atm outage
by Robert Boyle 18 Aug '01

18 Aug '01

---- Original Message ---- From: nathan(a)robotics.net To: alex(a)nac.net, Subject: Re: verizon atm outage Date: Fri, 17 Aug 2001 22:39:59 -0400 (EDT) > >On Fri, 17 Aug 2001, Alex Rubenstein wrote: > >> Interesting. >> >> Out of about 350 PVCs on an OC3 in to the Newark ATM switch >cluster, we're >> seeing four circuits down; could be considered normal.. >> >> We're not seeing any additional loss or latency at this point. > >Ditto, my OC3s in BOS, NYC, and DCA into Verizon ATM cloud are all >up. Same here at 2:30AM. It seems that whatever they did earlier tonight generated traps on exactly 36 of our circuits all in LATA 224 in NJ from 7-9PM with momentary (<60 seconds) loss of LMI. Nothing on any of our other 100+ circuits in NY or NJ and nothing since then... All of our ATM and Frame circuits are up and no new alarms have been received. I find it hard to believe the upgrade went that smoothly, but we still have another 4.5 hours for them to play. -Robert

1 0

Re: verizon atm outage
by Robert Boyle 17 Aug '01

17 Aug '01

At 08:11 PM 8/17/2001 -0400, you wrote: >verizon techs are encountering problems with equiptment in the entire >mid-atlantic region. ADSL outages are expected, and may last several >hours each. they will be rolling outages, rather than blanketing the >entire former BA territory at once. > >i didn't get a lot of details from the 5 different people in 3 >different departments that i talked to, but it sounded gnarly and >everyone was sounding very pessimistic. > >i gathered that there was some routine maintainance that turned into >this widespread outage. they expect areas to be going up and down for >"the entire weekend." one tech told me to advise my customers to >reset their modems before attempting to connect again, but he couldn't >explain to me what was going on. > >fun fun fun. > >anyone else hear a different story? This is the official notice. It isn't supposed to start for another 3 hours, but we have been seeing periodic bouncing on about 30-40 customer T1 lines. 8/18/2001 - Verizon has notified us of scheduled network outage: "...to allow the upgrade of the Frame Relay CBX-9000/500 switches in the Atlantic Coastal LATA of New Jersey. The planned upgrade being instituted will bring extended functionality and ensure a more robust network through deployment of new software and hardware revisions. This upgrade will take place on August 18th, 2001. All work directly affecting customer circuits is scheduled to begin no earlier than midnight and end no later than seven AM. Please be aware that while the upgrade is taking place, you may experience sporadic PVC interruptions due to rerouting, on your frame relay circuits in this LATA. The scheduled window for circuits to be down is four hours. Your circuits may be down for all or part of this four hour window." As always, Tellurian's NOC will be monitoring circuits and opening tickets if any customer's service is not restored by 7AM as promised by Verizon. All our Verizon Frame Relay and ATM circuits are ok at this time. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "It is never too late to be what you might have been." -George Eliot

3 2