- NANOG - lists.nanog.org

Anyone using Cingular wireless? (IXO/TAP number request)
by Alan Clegg 29 Jan '01

29 Jan '01

I've recently moved to Cingular Wireless (formerly BellSouth Mobility DCS in this area) for "all of my wireless communication needs". They are, however, unable to offer me information regarding an IXO (or TAP) number that I can use to send text pages from a "regular old modem". I've used qpage and hylafax previously (with another paging company), and would REALLY like to get this working (since GMS works amazingly well down in the RF hole where I live). If anyone has contacts with Cingular, or knows where I might find more info (I've done web-searches, and the best I've come up with at this point is http://www.qpage.org/phone-numbers.html which does not list BellSouth DCS *OR* Cingular [but does list some of the other companies that are now part of the "Cingular family"]), please let me know. If it matters, it would be for a phone based out of the "Chapel Hill" dialing area of Central/Eastern North Carolina. Thanks, AlanC {stomping on the boundaries of wireless connectivity} -- Alan B. Clegg abc(a)bsdi.com Member of Technical Staff http://www.bsdi.com Berkeley Software Design, Inc. 1-800-800-4BSD

3 2

Hanging SMTP sessions...
by Jason Blakey 29 Jan '01

29 Jan '01

Hi all, anyone come across stuff like this? We are runing qmail 1.03, and i'm seeing some strange things. I have a number of SMTP sessions which just hang, and then time out. No mail is actually accepted from these sessions... load is 0.00, so the processes are just hanging around for no reason... and it's always the same sources... Samples (from netstat) 0------------------ tcp 0 0 pg-mail.playground:smtp 204.187.152.24:3893 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 209.146.253.254:44124 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 204.187.152.24:4565 ESTABLISHED tcp 0 0 pg-mail.playground:smtp orr.pwgsc.gc.ca:60495 ESTABLISHED tcp 0 0 pg-mail.playground:smtp pchgate.pch.gc.ca:37814 ESTABLISHED tcp 0 0 pg-mail.playground:smtp orr.pwgsc.gc.ca:61092 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 204.187.152.24:1245 ESTABLISHED tcp 0 0 pg-mail.playground:smtp mail1.rogers.com:44081 ESTABLISHED tcp 0 0 pg-mail.playground:smtp ftp.compmore.net:3004 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 204.187.152.24:1833 ESTABLISHED tcp 0 0 pg-mail.playground:smtp mail.quicken.ca:57669 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:43970 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:43974 ESTABLISHED tcp 0 0 pg-mail.playground:smtp mail.cyberus.ca:59054 ESTABLISHED tcp 0 0 pg-mail.playground:smtp neptunium.dowco.co:4925 ESTABLISHED tcp 0 0 pg-mail.playground:smtp macdonald.gallery:14792 ESTABLISHED tcp 0 0 pg-mail.playground:smtp ftp.compmore.net:3011 ESTABLISHED tcp 0 0 pg-mail.playground:smtp m1.eisa.com:20388 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 192.197.69.17:51878 ESTABLISHED tcp 0 0 pg-mail.playground:smtp orr.pwgsc.gc.ca:36108 ESTABLISHED tcp 0 0 pg-mail.playground:smtp hades.edc-see.ca:3952 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:45472 ESTABLISHED tcp 0 0 pg-mail.playground:smtp orr.pwgsc.gc.ca:39246 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:45502 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:46075 ESTABLISHED tcp 0 0 pg-mail.playground:smtp fwd.rc.gc.ca:60801 ESTABLISHED tcp 0 0 pg-mail.playground:smtp mail.cyberus.ca:59837 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 209.146.253.254:44880 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 204.187.152.24:4960 ESTABLISHED tcp 0 0 pg-mail.playground:smtp 192.197.69.17:54598 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:46671 ESTABLISHED tcp 0 0 pg-mail.playground:smtp mail.cyberus.ca:60005 ESTABLISHED tcp 0 0 pg-mail.playground:smtp coal.sentex.ca:2764 ESTABLISHED tcp 0 0 pg-mail.playground:smtp orr.pwgsc.gc.ca:45323 ESTABLISHED tcp 0 0 pg-mail.playground:smtp jabba.galaxy.sout:46913 ESTABLISHED Any help appreciated... Thanks, jason -- This email from Jason Blakey - jblakey(a)frogboy.net - www.frogboy.net "The luckiest man in the world"

1 0

Re: Proactive steps to prevent DDOS?
by Sean Donelan 29 Jan '01

29 Jan '01

On Sun, 28 January 2001, Jerry Scharf wrote: > The first step is effective emergency response. I have seen hours pass as > secret handshakes and people on the "right list" were located and made the > right calls. People start their generators on a planned basis to make sure > they work. How many people practice DDOS attack recovery? It's something you > can actually do today that will help the most in a real attack. In general, companies with effective "all-hazard" contingency plans survive natural, malicious and procedural error problems the best. Not only do the teams get more practice, because the teams handle more incidents. But the team's wider range of experience helps them deal with the unusual, unexplained, and unexpected. When a failure happens, often it is not clear what the root cause is. I'm not a fan of the NIPC's approach of focusing "cybersecurity." Starting with malicious activity seems to delay effective response. First put the fire out, then figure out if it was arson (rather simplistic, and not completely true). As you point out, testing those plans on a regular basis is needed. You might be surprised, but not everyone starts their generators on a planned basis. Or if they do have some automated clock schedule the run the engine, no one every checks if the engine ran or can support a load. The more reliable the service, the less the backup procedures are tested. But as folks find out, it only takes one accident to pay for all of that extra stuff. I haven't run a NOC in over a year, and I still get asked by people to pass messages between other NOCs' engineers who can't figure out how to get through each other's front lines because they've never called each other before. While it works, everyone agrees its not how it should work. > This is a malicious attack designed to cause failure, so I think that any > measures of the style discussed will only save you from the small attacks. Not > that avoiding some attacks isn't good, it's just not much help in the general > case. I think the issue of malice makes it very hard to plan for like storm > water or freeway traffic. I have no proof to say that large sites fare better > than small ones. They can handle more, but attract much more serious attacks > with much more glory for the perpetrators. I don't think there is a 100% solution, but the motivation for the attacks can help a bit. Most of the attacks that make the news seem to have an opportunistic motivation. I know the underground is going to think this is trash-talking, but many of the attacks seem to show the intelligence of natural phenomena. Blow hard until something falls down. The attackers don't seem to care what falls down. I like a good hack. But doing the same thing over and over again seems boring. If I knew of more targetted attacks, I might change my mind. > Many people are pinning their hopes on traffic flow tagging as the way to > manage/solve this in the long term. No one knows yet when it can be deployed > in a large enough scale to work and what it will take then to handle it. > > I'm hoping you realize the spectacular failure mode of your DNS propose. You > DOS the DNS in-addr servers and the whole site goes away. That should take a > lot less traffic than swamping the pipes. DNS has enouh problems digesting all > the things it's trying to do now (DNSSEC, v6, large packets...), no need to > make it worse. I did say conservative transmission mode, not cease transmission mode. Only after a positive request to stop transmitting should it throttle things to zero. But the devil is in the details, is there a way once alerted, an edge device can probe the data stream and distinguish an uncontrolled flood from a large data transfer. What is large today, may be ordinary in a few years. Without a working IPSEC and DNSSEC, how would you know the source of that UDP packet is authoritative. And I didn't want to suggest RSVP might be useful for something. You're correct, source quench has been proposed as the solution for a lot of problems, but it always seems to be worse than the disease. And since it would require a change on the source's behaivor, it doesn't really meet my stated problem. IP stacks are getting smarter. It seems like I need a distributed response to a distributed attack. Well-behaived traffic shouldn't be affected. Senders with poor manners should be put in a queue with other rude traffic. Concentrating on self-defense at the target seems limited, and not very effective. Again, trying to find a historical framework, you can't build a castle so strong, it can't be breached. So who are you gonna call for help? The Bell Heads came up with a partial solution for the telephone network, call-gapping. The network operator can quickly instruct most of the edge switches in the network to rate limit traffic to a particular destination, regardless of the root cause. It could be people calling about an earthquake, wanting to be on Who Wants to be a Millioniare or a telephone based DDOS attack. Yes, Viriginia it is easier to take down a circuit-based network with a DDOS than "the" phone company likes to admit. Try calling a major airline's reservation number from O'Hare airport in the middle of a snowstorm. But again, this would require changes outside the control of the target of the attack. There is risk the operator will make a mistake implementing the process, making things worse. Its cheaper to tell the customer to move along.

1 0

Re: Proactive steps to prevent DDOS?
by Sean Donelan 29 Jan '01

29 Jan '01

So which one of those things do you think any of the victims wasn't doing before, and how will the steps now prevent a future DDOS attack from affecting its servers? If the victims had done all of these things before they were attacked, would it have prevented the attack from affecting their service? Those aren't just rhetorical questions, I'm trying to understand how to approach this. If you view DDOS as a traffic surge, can we use any lessons from other phenomenon involving surges, such as vehicle traffic at rush hour, water runoff from a storm, lightning strike. You can't control the weather, but you can do a lot to mitigate the damages. Methods for handling surges: - Limit the source (e.g. metering lights on freeways) - Divert the surge (e.g. lightning arresters on electric circuits) - Buffer the surge (e.g. detention basins for water runoff) How can we signal uncooperative sources to limit or even cease sending traffic? Preferablly without impacting cooperative sources. Historically, the "nice guys" traffic gets throttled, while the "bad guys" traffic blasts through. If you don't get enough tokens or credits, you don't send. RED and friends work with cooperative sources. How can we identify and drop the excess traffic at the earliest point? Should it be a cascaded system, i.e. you have several stages instead of one big muttha firewall. Do you really want to carry the traffic across the entire Internet, just to drop it on the last link? How can we size the protective systems and the final system so we won't overrun their available resources (requires knowing how large the resources actually are)? Is there anyway to mitigate the slashdot effect for small sites as well as large sites? Larges sites can throw more capacity at the problem to buffer the surge. Its been at least a week since someone suggested putting a bad idea into DNS. How about using the inability to reach the DNS server to rate limit the sources. Every once in a while, the IP stack (protocol layer violation) queries the in-addr.arpa servers for the destination network. The in-addr.arpa servers respond with additional credits, or zero credits (source quench), or don't respond signalling the source to switch to a conservative transmission mode. If you don't trust the end-to-end system to respond to the signals, the upstream edge router could enforce it. Is that idea horrendous enough? On Sat, 27 January 2001, Jeff Ogden wrote: > >At 4:15 PM -0800 1/26/01, Sean Donelan wrote: > >Fine, does this work better for you? > > > >Help me, what proactive steps can I take to protect my network from a DDOS? > > There isn't a lot that can be done, but there are a few steps you can > take to "get ready" for a DDOS attack. > > --Make sure you have monitoring of your routers or firewalls in place > so you'll get an early alert of a possible DOS attack. This will at > least allow you to start working on the problem (and drafting > press releases :-). > > --Talk to all of your up stream providers so you know how to contact and > work with them if they are a source of a DOS attack against you. If your > up stream provider isn't willing to work with you on this, start the > process of getting a new up stream provider. > > --Look into the systems that are being developed and starting to become > available that help automate the work to diagnose DDOS attacks. > Encourage your up streams to do the same. > > --Make sure you have in place the filtering on your own networks that you > wish everyone else had in place on their networks. This won't protect > you from being attacked, but it will prevent you and your users from > attacking others (or at least using spoofed IP addresses to do so), and > that in turn may prevent you from being the target of a retaliatory DOS > attack. It can also prevent or limit the spread of a DOS attack that > originates within your network or from someone down stream. From your > customer's point of view there may not be much difference between > you being the source of or the target of a DOS attack--either way > performance is likely to be poor and customers are likely to be unhappy. > > -Jeff Ogden > Merit

3 2

Re: sorry to ruin several of your evenings...
by Paul Vixie 28 Jan '01

28 Jan '01

tkernen(a)deckpoint.ch (Thomas Kernen) writes: > > (the root name servers were all done last week, for example.) > > What about TLD managers, do/can they get the info at the same time as the > root-server admins? I don't know. ISC is considering a membership program which would allow system vendors and TLD operators to receive the same kinds of notifications that "support customers" and root name server operators receive now. But at the moment, the system vendors and TLD operators are still reached through CERT when there's something critical to announce.

1 0

Re: Proactive steps to prevent DDOS?
by Jason Legate 28 Jan '01

28 Jan '01

> I would add careful use of some rate-limiting > functionality, > (already mentioned in Richard Steenbergen's > http://www.e-gerbil.net/ras/dos.txt) > so you can rate-limit things like icmp and acks > numbered 0 and anything > else that show themselves to be obvious candidates > over time. In actuality, in a TCP SYN packet, an ack of 0 is very common. If you view legitimate syn's generated by real stacks, you will see at dword offset 7: 0x00000000. Last time I checked, this was a 0 for all intents and purposes. By rate-limiting acks of 0, you are rate-limiting most syn packets, which I don't think is the ultimate goal. -j __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/

1 0

Re: sorry to ruin several of your evenings...
by Paul A Vixie 28 Jan '01

28 Jan '01

> Without being aware of what your disclosure policies are, I'll go ahead > and ask... what are the flaws, and are they also in 8.2.2-p7? if 8.2.2-P7 were safe, you can bet that the warning ("don't run anything earlier") would have come with 8.2.2-P7. > I don't see anything at: > > http://www.isc.org/products/BIND/bind-security.html > > that mentions p7. Sure, I could diff a bunch of stuff... you can bet that dozens of kiddies all over the world are diffing stuff. maybe you'll be faster than them, find the specific problem, develop a patch that's different from "install 8.2.3", and deploy it before you're hit. > Sorry to bring this to NANOG, but it's a bit more appropriate than gabbing > about what a root server is. Also, note that Bugtraq is gone until > Monday, so there'll be no talk of this there. there are several major announcements planned for monday. ISC wanted to get the new code on the street soon enough to give people a running head start at upgrading. (the root name servers were all done last week, for example.)

2 1

How common is lack of DNS server diversity?
by Sean Donelan 28 Jan '01

28 Jan '01

Mice and Men found that 38% of the .COM domains surveyed had all their name servers on the same subnet. And 75% had one or more configuration errors. http://www.menandmice.com/dnsplace/healthsurvey.html DNS, like most databases, suffers from information entropy. In other words, it takes a lot of energy to keep information correctly updated while it is being changed. Anyone who has been Hostmaster for even a moderately sized ISP knows there is an amazing number of ways for people to mess up any of the pieces of data required to make the whole thing work. As several people pointed out, you can't really assume close IP addresses are in fact topologically close on the network. For example, if you look at the name severs for GENUITY.NET Domain servers in listed order: DNSAUTH1.SYS.GTEI.NET 4.2.49.2 DNSAUTH2.SYS.GTEI.NET 4.2.49.3 DNSAUTH3.SYS.GTEI.NET 4.2.49.4 They appear to be closely related. However, the addresses are in fact routed to very diverse locations on Genuity's network. You will find the same thing if you look at the name servers for UU.NET Domain servers in listed order: AUTH00.NS.UU.NET 198.6.1.65 AUTH60.NS.UU.NET 198.6.1.181 These servers are also geographically diverse. So I'm not sure if the 38% number is a true indication of how much diversity DNS servers have.

11 12

RE: More 6509 problems...
by Danny Snyder 28 Jan '01

28 Jan '01

I don't believe that is the case. According to Cisco, it is required to make several of the line cards installable in the FlexWAN modules work correctly. I don't know what the details of distributed CEF are, but it made my DS3s work, and that's the main thing I was looking for.... :-) --Danny -----Original Message----- From: Berger, Gary [mailto:Gary.Berger@dowjones.com] Sent: Tuesday, January 30, 2001 10:48 AM To: agudgeon(a)firstnet.co.uk; 'Danny Snyder'; nanog(a)merit.edu Subject: RE: More 6509 problems... Correct me if I am wrong but I believe Distributed CEF is only applicable to distributed line cards which need the X-Bar backplane. Gary Berger Internal Consultant, Principal Dow Jones Enterprise Network Services -----Original Message----- From: Alison Gudgeon [mailto:agudgeon@firstnet.co.uk] Sent: Tuesday, January 30, 2001 11:36 AM To: 'Danny Snyder'; nanog(a)merit.edu Subject: RE: More 6509 problems... Hi Hybrid IOS I've got IP CEF DISTRIBUTED set globally. Did you have it enabled or disabled on the T3 interface? Ali -----Original Message----- From: Danny Snyder [mailto:dsnyder@nowdocs.com] Sent: 30 January 2001 16:21 To: agudgeon(a)firstnet.co.uk; nanog(a)merit.edu Subject: RE: More 6509 problems... Alison, I've had VERY similar problems with a 6509 (Sup 1a + MSFC2) with a FlexWAN and a PA-2T3+. After spending the better part of two weeks on the phone with Cisco, we finally determined that ip cef distributed needed to be turned on in global configuration. Also, are you running native IOS or Catalyst OS on the Supervisor and IOS on the MSFC ? Danny Snyder Network Administrator NowDocs, Inc. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alison Gudgeon Sent: Tuesday, January 30, 2001 10:18 AM To: nanog(a)merit.edu Subject: More 6509 problems... Hi, Is anyone doing the following: 6509 (supervisor 1a + msfc) - with a flexWAN adapter to take a Packet Over Sonet OC-3 card. I'm having great problems getting up/up on the interface, the current situation is up/down, a hardware loop at the telco kit brings the line up/up but otherwise just up/down. Config is default I've just put IP's on. I'm running very new code - 12.1(4)E1 many thanks in advance for any help. Kind Regards Alison

1 0

Anyone from nasa.gov around?
by Jay R. Ashworth 28 Jan '01

28 Jan '01

Would someone please re-map webmaster(a)nasa.gov to an X500 address that *points* somewhere? Sheesh. Fifteen years ago today... and no tribute or nothing. All. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

1 0