- NANOG - lists.nanog.org

Re: [spamtools] Tracking a DDOS
by william＠sokol.elan.net 20 Jan '03

20 Jan '03

So did you aquire those "assets" from clearblue or where the appliedtheory's assets kindof devided between fastnet and clearblue? And if undertand it correctly apliedtheory name & domain are still with clearblue/navisite? If so is it the same for CRL? I'm primarily just curious in terms of finding out what happened to earliest companies that made internet - CRL being one of the first commercial isp... On Mon, 20 Jan 2003, Matt McGuirl wrote: > Fastnet acquired some of AppliedTheory's assets at one point in mid to > late 2002. > > Matt

1 0

standard network symbols/icons
by Michael.Hawk＠i-structure.com 20 Jan '03

20 Jan '03

Hello, Do any of the standards organizations (ISO?) have a set of icons/symbols to represent network devices ranging from routers to servers to load balancers? I've always used the basic Cisco and Juniper icons, but I'm being directed to find something not associated with a vendor in *any* way, but prettier than rectangular boxes. My google and ISO website searches have turned up empty aside from an apparently independent attempt at developing standard symbols: http://www.meshuggeneh.net/shoki/symbols/ Does anyone know of any more official source? Thank you, -mike ------------ Michael Hawk Senior Network Engineer (i)Structure, Inc

3 2

Network Design Consultant
by K. Scott Bethke 20 Jan '03

20 Jan '03

Can anyone here recommend an individual or company who would analyze a working network design from head to toe, suggesting changes and improvements where needed. This would include overall design from a high level but also analyze actual router/switch config's. Looking for someone/somecompany who is not vendor specific, and experienced with high performance, redundant networks. Please respond offlist. I am happy to summarize for anyone interested. -Scotty

1 0

quick note on hash based tracebacks
by Craig Partridge 20 Jan '03

20 Jan '03

The capabilities of hash-based tracebacks has come up a few times in the past couple of days. Most of the discussion has been quite accurate (always nice to see one's work understood!) but there are two points that I thought might benefit from clarification: > The SPIE hash-based > traceback is a much cooler idea, but it has some practical limitations, > including the need to do the trace in more or less real-time (once the > hash table fills up, it becomes useless), and the need for very large > amounts of very fast memory on the tracing routers. So that folks understand this point. SPIE requires a fast memory that equals a fraction of a second (fraction varies depending on configuration) times about .2% of link bandwidth to store its hash information. It then expects each router to cache (on disk) all the hash tables recorded for some period of time. You can actually reduce the router's storage needs by simply sending old hash tables off to an archive (say at your operations center). [Remember, the amount of data kept is a fraction of a percent of the link speed -- so even if you've got ten lines into a box, the total bandwidth required to copy their tables to an archive is, *at worst*, around 1%-2% of the bandwidth of the fastest link]. > There was an IETF > BoF on it, but the folks behind it haven't been pushing it much. > (Randy, do you know the status of it?) Randy encouraged us to go off and write a spec on our own and just bring it to IETF when done. Since we've got a customer paying us to work on a deployable system in his network, we figured we'd take advantage of the experience (something about "running code" :-)). Craig PS: For more info, see the paper in the lastest issue of IEEE/ACM Trans. on Networking, or read the (somewhat less detailed) paper from ACM SIGCOMM 2001. The SIGCOMM paper is available on-line at no charge: http://doi.acm.org/10.1145/383059.383060

1 0

RE: uunet
by Chad Skidmore 20 Jan '03

20 Jan '03

Last week we experienced a significant (for us anyway) DDOS against one of our customers and UUNET was one of the quickest to respond. No, we are not a UUNET customer but Chris (with UUNET) responded very quickly (within 30min I believe) to a post we made to a mail list and began blackholing traffic in UUNET's network. BTW, this was at about 10:30pm on a Monday night his time. WorldCom/UUNET is an easy company to beat on (and probably deserves it some of the time) but the UUNET security team is, in my opinion, top notch. They have been very willing to share information and techniques and been very willing to help others implement DDOS/DOS tracking. I'm not disputing the fact that you probably had a bad experience getting through to the right person. It sounds like the UUNET NOC (like many NOCs) was not terribly helpful. Other forms of communication like NANOG and nsp-sec are often times better forms of communication when it comes to DOS/DDOS attacks and other security issues. Hopefully that will change over time. Regards, Chad ----------------------------------- Chad Skidmore One Eighty Networks http://www.go180.net 509-688-8180 -----Original Message----- From: Scott Granados [mailto:scott@wworks.net] Posted At: Sunday, January 19, 2003 2:27 PM Posted To: NANOG Conversation: uunet Subject: Re: uunet Its just unfortunate that some companies not mentioning names feel this is good practice. Others don't feel this way which is a good thing. Just a note, uunet wouldn't take my call when a ddos attach originated on their network either. Same response with the exception of "Well we don't have security persons available after hours so write us an e-mail and you may get a response within 48 hours". Which to me sounded just plain wrong because I've seen threds onhere to the contrary. ----- Original Message ----- From: "blitz" <blitz(a)macronet.net> To: "Scott Granados" <scott(a)wworks.net> Cc: <nanog(a)merit.edu> Sent: Sunday, January 19, 2003 1:24 AM Subject: Re: uunet > I'll copy this email, and keep it for reference when someone asks > about buying service from UUnet...thanks... > > At 17:17 1/18/03 -0800, you wrote: > > >What's interesting is that I just tried to call the noc and was told > >"We have to have you e-mail the group" > > > >my response, I can't I have no route working to uunet > > > >"Well you have to" > > > >my response, ok I'll use someone elses mail box where do I mail? > > > >"We can't tell you your not a customer" > > > >My response its a routing issue do you have somewhere I can e-mail > >you. > > > >"Your not my customer I really don't care" *click* > > > >Nice. professional too. > > > >Anyone have a number to the noc that someone with clue might answer? > > > >----- Original Message ----- > >From: "David Diaz" <techlist(a)smoton.net> > >To: "Scott Granados" <scott(a)wworks.net>; <nanog(a)merit.edu> > >Sent: Saturday, January 18, 2003 4:35 PM > >Subject: Re: uunet > > > > > > > Im not seeing anything coming from qwest. > > > > > > > > > > > > At 16:55 -0800 1/18/03, Scott Granados wrote: > > > >Is something up on uunet tonight? > > > > > > > >It looks to me that dns is broken forward and reverse but more > > > >likely it > > > >looks like a bad bogan fiilter popped up suddenly. I have issue > > > >as soon > >as > > > >I leave mfn's network and hit uunet. > > > > > > -- > > > > > > David Diaz > > > dave(a)smoton.net [Email] > > > pagedave(a)smoton.net [Pager] > > > www.smoton.net [Peering Site under development] > > > Smotons (Smart Photons) trump dumb photons > > > > > > > > > > >

1 0

Tracking a DDOS
by Roger Marquis 20 Jan '03

20 Jan '03

One of our clients sustained a severe SMTP DDOS attack on New Years' Day. The DDOS was caused by a bulk mailing which had forged their domain name in the return address. The attack was staged over several days from dial-up lines at fast.net (Bethlehem, PA). We contacted fast.net shortly after the massmail began but it continued unabated for two additional days. Some of the source IPs were eventually listed by MAPS and Wirehub and they're still listed to this date. 5 minutes after our call to fast.net's support desk we tracked a portscan from one of their netblocks (206.245.164.0-206.245.164.255, Internet Unlimited, at nearly the same address in Bethlehem, PA). A quick check of the reverse DNS revealed nearly exclusive use by porn, throw-away, and otherwise spam domains. Though we're still tabulating damages and collecting evidence it appears the DDOS was hosted by and allowed to continue unabated by fast.net (aka iuinc.com) after they had knowledge of the problem, knowledge of its source, and knowledge of its effects. Since fast.net/iuinc.com has not replied to our email or phone calls we're looking for anyone with information on this company, its owners or operators, and any history of network or SMTP abuse. All help will be appreciated and kept confidential. Thanks in advance, -- Roger Marquis Roble Systems Consulting http://www.roble.com/

4 4

Re: Is there a line of defense against Distributed Reflective attacks?
by John Kristoff 19 Jan '03

19 Jan '03

On Thu, Jan 16, 2003 at 08:48:03PM -0500, Brad Laue wrote: > Having researched this in-depth after reading a rather cursory article > on the topic (http://grc.com/dos/drdos.htm) only two main methods come > to my mind to protect against it. There are a few more methods, some have already mentioned including something called pushback. Very few solutions, particularly elegant ones are widely deployed today. At some point, sophisticated (or even not so sophisticated) DoS attacks can be hard to distinguish between valid traffic, particularly if widely distributed and traffic is as valid looking as any other bit of traffic. > By way of quick review, such an attack is carried out by forging the > source address of the target host and sending large quantities of > packets toward a high-bandwidth middleman or several such. It doesn't have to be forged, that step just makes it harder to trace back to the original source. There are some solutions that try to deal with this, including an IETF working group called itrace. UUNET also developed something called CenterTrack. BBN has something called Source Path Isolation Engine (SPIE). There are probably other things I'm forgetting, but generally are similar in concept to these. > To my knowledge the network encompassing the target host is largely > unable to protect itself other than 'poisoning' the route to the host in > question. This succeeds in minimizing the impact of such an attack on This is true, the survivability of the victim largely depends on the security of everyone else, which makes solving the problem so exceptionally difficult. > the network itself, but also acheives the end of removing the target > host from the Internet entirely. Additionally, if the targetted host is > a router, little if anything can be done to stop that network from going > down. I'm not sure I fully understand what you're saying here, but a router can be effectively be taken out of service as any other end host or network can by simply overwhelming it with packets to process (for itself or to be forwarded). > One method that comes to mind that can slow the incoming traffic in a > more distributed way is ECN (explicit congestion notification), but it > doesn't seem as though the implementation of ECN is a priority for many > small or large networks (correct me if I'm wrong on this point). If ECN ECN cannot be an effective solution unless you trust all edge hosts, including the attacking hosts, will use it. Since it is a mechanism that is used to signal transmitting hosts to slow down, attackers can choose not to implement ECN or ignore ECN signals. Unless you could control all the ends hosts, and as long as there is intelligence in the end hosts a user could modify, this won't help. > is a practical solution to an attack of this kind, what prevents its > implementation? Lack of awareness, or other? It is still fairly new and not widely deployed. Routers need not only to support it, but also have to be enabled to use it. It is a fairly significant change to the way congestion control is currently done in the Internet and it will take some time before penetration occurs. > Also, are there other methods of protecting a targetted network from > losing functionality during such an attack? Many are reactive, often because you can't know what a DoS is until its happening. In that case, providers can use BGP advertisements to blackhole hosts or networks (though that can essentially finish the job the attacker started). If attacks target a DNS name, the end hosts can change their IP address (though DNS servers may still get pounded). If anything unique about the attack traffic can be determined, filters or rate limits can be placed as close to the sources as possible to block it (and that fails as attack traffic becomes increasingly dispersed and identical to valid traffic). If more capacity than attack traffic uses can be obtained, the attack could be ignored or mitigated (but this might be expensive and impractical). If the sources can be tracked, perhaps they can be stopped (but large number of sources make this a scaling issue and sometimes not all responsible parties are as cooperative or friendly as you might like). There is also the threat of legal response, which could encourage networks and hosts to stop and prevent attacks in the future (this could have negative impacts for the openness of the net and potentially be difficult to enforce when multiple jurisdiations are involved). >From a proactive approach, hosts could be secured to prevent an outsider from using it for attack. The sorry state of system security doesn't seem to be getting better and even if we had perfect end system security, an attacker could still use their own system(s) to launch attacks. Eventually it all boils down to a physical security problem. Pricing models can be used to make it expensive to send attack traffic. How to do the billing and who to bill might not be so easy. ...and there may always be a provider who charges less. Rate limits can be used on a per source, per protocol or per flow basis. Given enough hosts and not enough deployment in the network, this has yet to be effective. Similarly, network based queueing mechanisms (e.g. RED), or pushback approaches already mentioned, which penalize or limit high rate flows are not widely deployed yet. It often takes a combination of techniques used by as many people as possible. Good incident response teams for as many responsible network operators as possible and continued, quicker deployment of best practices to as many network operators, end users and systems developers as possible. ...or you architecturally change the Internet or not use the Internet. For example, go back to dumb end systems and place all the control into the network operated by a select few (e.g. the traditional telephone model). You potentially lose all the good properties the current architecture has and you aren't going to get everyone to change with you anytime soon. I highly recommend Bruce Schneier's book Secrets and Lies, which applies to so much of all these problems and gives you a lot more to think about in a much more readable way than what I have said here. It is especially insightful with regards to all the non- technical problems and non-technical responses to the problems. John

7 9

RE: FW: Re: Is there a line of defense against Distributed Reflective attacks?
by Ray Burkholder 19 Jan '03

19 Jan '03

This whole 'Internet Thing' is a one of the wonders of the modern world. A public transport system that has handled growth easily and efficiently for many years. Some people get leisure from it, some make money from it, some do research on it, some communicate on it,.... It is one of the most pervasive things I've seen. Because of the internet's inherent distributed nature, legislation will get you no where, and besides,l legislation is the easy way out, and not very effective at that. Market forces and the golden rule (if that combo actually works, I'd be amazed) should drive the direction of this dynamic animal we call 'The Internet'. If we lived in Nirvana, the Internet would be a beautiful thing. But as we live in reality, we have to take the good with the bad. But overall, I think the Good is winning over the Bad. I say: Cool. Ray Burkholder > -----Original Message----- > From: todd glassey [mailto:todd.glassey@worldnet.att.net] > Sent: January 19, 2003 12:02 > To: Christopher L. Morrow; Stewart, William C (Bill), RTLSL > Cc: nanog(a)trapdoor.merit.edu > Subject: Re: FW: Re: Is there a line of defense against > Distributed Reflective attacks? > > > You nor any of the ISP's may like this but the facts of the > matter are pretty clean and easily discerned and they all > point to the Governance Model for developing and releasing > protocols whole cloth on the Internet, no matter what they > enable people to do. Its time to take a close accounting of > what this "Internet" thing really is and put some stronger > legislation in place. > > Todd Glassey > > ----- Original Message ----- > From: "Christopher L. Morrow" <chris(a)UU.NET> > To: "Stewart, William C (Bill), RTLSL" <billstewart(a)att.com> > Cc: <nanog(a)trapdoor.merit.edu> > Sent: Friday, January 17, 2003 6:29 PM > Subject: Re: FW: Re: Is there a line of defense against > Distributed Reflective attacks? > > > > > > > > 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. > > > > > that have IP addresses that are registered for that port, and not > > > accepting incoming packets from outside their network > that claim to > > > be from inside (except maybe from registered dual-homed > hosts.) > > > This cuts down on many opportunities for forgery, > > > and means that SYN Flood attacks have a much more limited set of > > > addresses they can forge (e.g. an attacker or zombie can only > > > impersonate other ips sharing its /24 or /29, so it can't > pretend to > > > be its victim in a reflection or smurf attack.) > > > > > > That doesn't stop all reflection attacks; a zombie on a > network that > > > doesn't do anti-spoofing can send SYNs to a big server on > a network > > > that also doesn't anti-spoof, so the server will still SYN-ACK > > > > its not the 'server' that needs 'anti-spoof' its the end host, the > > machine in your livingroom that is on a cable modem for instance... > > the server in this instance is a simple, innocent, machine > doing its > > business. > > > > > to the victim. This cuts out a lot of potential zombie/server > > > pairs. If the server that's being used for reflection is > someone the > > > victim would often talk to, that's a problem (you'd > rather not block > > > connections to Yahoo), but if it's someone the victim > doesn't care > > > about talking to (like router23.example.net) you don't > mind blocking > > > it. (Also, why is router23.example.net SYNACKing somebody > it doesn't > > > know?) > > > > > > > This is an interesting point. The routers shouldn't really > syn-ack (in > > this example) bgp from 'unknown' places... unless you are a > neighbor > > you get squat, or that would be a nice feature, eh? :) For > some folks, > > the problems aren't confined to just bgp, telnet or ssh on > routers are > > also problemmatic, vty acl's are important :) > > > > > But there are probably 20 million web servers or Kazaa or > IM clients > > > out > there, > > > and probably half of them are on networks that don't > spoof-proof, so > > > blocking those is much tougher than blocking the big > ones. And next > > > stop - reflection attacks using big domain servers... > > > > > > > Hmm, I'm not sure, again, that the spoof proof needs to be on the > > kazaa server network, it needs to be on the network where the > > originating attacke is, preferrably as close to that host > as possible, > > like it's default router... Now, the problems with 60million kazaa > > clients openning the floodgates on you are a whole nother problem :) > > > > >

1 0

[Article] RIAA: ISPs should pay for music swapping
by Hank Nussbacher 19 Jan '03

19 Jan '03

http://news.com.com/2100-1023-981281.html?tag=fd_top "CANNES, France--A top music industry representative said Saturday that telecommunications companies and Internet service providers will be asked to pay up for giving their customers access to free song-swapping sites." It gets better. Read the whole thing! -Hank

1 0

FW: Re: Is there a line of defense against Distributed Reflective attacks?
by Stewart, William C (Bill), RTLSL 19 Jan '03

19 Jan '03

-----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 that have IP addresses that are registered for that port, and not accepting incoming packets from outside their network that claim to be from inside (except maybe from registered dual-homed hosts.) This cuts down on many opportunities for forgery, and means that SYN Flood attacks have a much more limited set of addresses they can forge (e.g. an attacker or zombie can only impersonate other ips sharing its /24 or /29, so it can't pretend to be its victim in a reflection or smurf attack.) That doesn't stop all reflection attacks; a zombie on a network that doesn't do anti-spoofing can send SYNs to a big server on a network that also doesn't anti-spoof, so the server will still SYN-ACK to the victim. This cuts out a lot of potential zombie/server pairs. If the server that's being used for reflection is someone the victim would often talk to, that's a problem (you'd rather not block connections to Yahoo), but if it's someone the victim doesn't care about talking to (like router23.example.net) you don't mind blocking it. (Also, why is router23.example.net SYNACKing somebody it doesn't know?) But there are probably 20 million web servers or Kazaa or IM clients out there, and probably half of them are on networks that don't spoof-proof, so blocking those is much tougher than blocking the big ones. And next stop - reflection attacks using big domain servers...

3 2