- Test - lists.nanog.org

2 BGP links with different path to the same ASes question
by Adam Obszynski 20 Aug '01

20 Aug '01

Hello nanog, Supose that we got network: AS 1 ---- iBGP ---- AS 1 | link 1 | link 2 | | AS 2 ---- iBGP ---- AS 2 and now, we want on one of those links (link 1) - setup only peering session and on (link 2) - start normaln internet tranis and if we pay for internet transit and not pay for peering, our idea is: - send peering IP packets via link1 - send packets from internet via link2 only way that i can see is the usage of source-route PS: assume that networks of AS1 and AS2 are big and meshed networks and there is need for set up a lot of acls and routemaps and take them all up of date! any better hints ? -- Adam Obszyński

2 2

PSInet help please...
by Rich Sena 20 Aug '01

20 Aug '01

Can someon at PSI- net contact me directly - I need to bend a favor... -- Richard Sena The Mitre Corporation e: rsena(a)mitre.org Lead Engineer 202 Burlington Road v: +1-781-271-3712 Dept: R10N; MS C020 Bedford, MA 01730-1420 f: +1-781-271-2600

1 0

LaBrea tarpit info and URL
by M. David Leonard 20 Aug '01

20 Aug '01

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

3 2

Using 120k BGP routes on the Lucent AP-1000
by Martin Cholkowski 20 Aug '01

20 Aug '01

HI, I was wondering if anyone has setup the Lucent AP-1000 for 120k BGP routes. I have used the configuration commands to increase configured BGP routes to 120000 and configured paths to 40000. I have also increased the IP routes to 120000. When I tried to increase the IP route memory though, the BGP operational routes have reduced to 5000, so I had to leave the memory untouched. The router seems to operate BGP OK but crashes from time to time. This tells me that IP route memory needs to be increased. I have 128k of RAM onboard the router. I wonder if anyone is using the AP1000 for 120k BGP routes and has a working configuration that they can send me. Thanks in advance. Martin Cholkowski

2 1

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 20 Aug '01

20 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