November 2003 - Test - lists.nanog.org

Trends in network operator security
by Sean Donelan 30 Dec '03

30 Dec '03

Its 2003 and everyone is making their predictions. What trends are network operators seeing for Internet security? Old favorites Buffer overflows Distributed Denial of Service Poor passwords (cisco/sanfran) Poorly coded systems Blame the user for not protecting poorly coded systems Trends Attack the network (why? because we can) Proxy relay hiding (its not just for SMTP anymore) Combo Bot/Trojan/Worms Embedded software "upgrades" Any other trends network operators are seeing?

2 2

Whitelisting, AOL E.mail etc.
by Robert Mathews 15 Dec '03

15 Dec '03

All: I have weighed the benefit of posting Vs. NOT posting this information to NANOG. I found that posting this note to the larger community was important perhaps for two reasons. They are: 1) The problems that we at the University of Hawai'i experienced from 10/17 - 10/20 with AOL, effected a fairly large userbase. Therefore, I am inclined to believe that someone who is at least partially responsible for the operation or managment of another network similar to our own - could benefit from having this information (I know of at least 2 other large University systems that were effected by the same issue). 2) Having the requisite AOL contact information in any event - might be important toward at least partially achieving a resolve to future problems. Now, a brief recap. Beginning the afternoon of the 17th (EDT), all E.mail traffic from UH' namespace to AOL began to bounce. This condition did not resolve until the morning of the 20th (EDT). Primarily, this was due to AOL's whitelisting, and whitelisting policies. Upon discovering this problem, I began an inquiry into the condition. We were informed that AOL had received complaints from 'its members', who stated that our central E.mail server was responsible for instances of spamming. Subsequently, AOL personnel and I were able to hold a dialog over the weekend to resolve pertinent issues regarding the matter. I wish to give praise the AOL Team, who responded quickly, and were both cooperative and sincere with respect to their desire to resolve issues. I MUST credit Carl Hutzler, Dir. of AntiSpam Operations at AOL, and Charles Stiles, Manager of the Postmaster-Team at AOL especially, for their commitment to resolve this issue expediently. Traffic exchange between AOL and us have been re-established. For your reference, I wish to present the following statement from Carl to me, which may be helpful to you as well. "Anyone can request to receive the complaints that mail transmitted from their IP space generated via a Complaint Feedback Loop. All we need is: 1. Address space (CIDR or otherwise) 2. Abuse email address where you want them sent We will send them in realtime as we get them with the entire original spam included for your analysis. Feel free to have them send this data to me and/or our abuse phone number for now ..." The relevant AOL contacts are as follows: Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler(a)aol.com 703.265.5521 work 703.915.6862 cell Carl Hutzler <cdhutzler(a)aol.com> or Charles Stiles <stilesch(a)aol.com> Manager, Postmaster-Team - AOL All my best, Robert. -------

4 4

WLAN shielding
by Andy Grosser 02 Dec '03

02 Dec '03

Apologies in advance if this may not quite be the proper list for such a question... My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? Feel free to reply off-list. Thanks! Andy --- Andy Grosser, CCNP andy at meniscus dot org ---

10 11

Re: TAT 14 failure
by garrett.allen＠comcast.net 02 Dec '03

02 Dec '03

still seeing decent ping times. anyone detect an actual outage or issue? thanks. > > I saw that link when I googled for TAT-14. I was looking more for a "see, I > told you so" link that I can forward to management that provides proof that > this is why our UK office is down...if you know what I mean. > > Here's an interesting explanation of undersea cabling: > http://davidw.home.cern.ch/davidw/public/SubCables.html > > > -Jack > > > --- Jared Mauch <jared(a)puck.nether.net> wrote: > > > > This is a basic map of the fiber path for those > > that haven't found one yet. > > > > http://www.kddiscs.co.jp/e/business/02_15.html > > > > - jared > > > > On Tue, Nov 25, 2003 at 10:32:16AM -0800, Jack McCarthy wrote: > > > > > > Anyone have additional info regarding this outage? Links? Besides > > tat-14.com > > > - it seems to be down or just flooded with requests. > > > > > > > > > -Jack > > > > > > > > > --- jmalcolm(a)uraeus.com wrote: > > > > > > > > The northern leg of TAT14 seems to have just taken an outage about an > > > > hour ago. As the southern leg was already down due to other faults, > > > > this will probably be an exciting time for many providers. > > > > > > > > > > > > > > > > -- > > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > > > > > >

7 6

TAT 14 failure
by jmalcolm＠uraeus.com 02 Dec '03

02 Dec '03

The northern leg of TAT14 seems to have just taken an outage about an hour ago. As the southern leg was already down due to other faults, this will probably be an exciting time for many providers.

5 5

Re: Have worm? University upgrades network
by warner＠cats.ucsc.edu 01 Dec '03

01 Dec '03

Sean Donelan said > On the other hand, California State-Long Beach is planning to upgrade > its network to deal with the worms. > > > http://www.csulb.edu/~d49er/archives/2003/fall/news/volLIVno49-dorm.shtml While Sean's interpretation draws reasonable inference from the cited article, the particular upgrade we've been told about will use some L2 intercept boxes to scan user computers at the time they attempt to connect to the LB net. They seem to be referring to the installation of the authentication/scanning boxes as part of the network upgrade. The hope/plan is that web redirection for software fixits through an appropriate campus download page will preceed releasing full internet services to the users. I don't think that CSULB is going to add capacity to deal with the icmp scans. Rather they are hopeful that they can use this as a clean up strategy. What we (UC Santa Cruz) share with LB is the vendor that will be adding scanning to their net-auth box: Perfigo. We have heard of the LB plans indirectly through the vendor, but in the context of the article, it all fits. -jim warner, UC Santa Cruz ---

2 1

Equant contact?
by Howard C. Berkowitz 30 Nov '03

30 Nov '03

Might I impose on someone who knows the corporate organization of Equant to contact me offline? TIA, Howard

1 0

Cogentco BGP admin around ?
by Jan Czmok 30 Nov '03

30 Nov '03

Hi! Anybody from Cogentco BGP department around ? i need a urgent BGP reconfiguration. I have a ticket# but no response since 15 hours. Please respond privately --jan -- Jan Czmok, Network Engineering & Support, Global Access Telecomm, Inc. Ph.: +49 69 299896-35 - fax: +49 69 299896-40 - sip:13129*522@inoc-dba.pch.net

1 0

Re: Santa Fe city government computers knocked out by worm
by Sean Donelan 29 Nov '03

29 Nov '03

On Sun, 16 Nov 2003, Jamie Reid wrote: > There was a comment (maybe even mine) in a previous thread > about accepting a base level of potentially compromised hosts > on a network, as the costs of rooting out every last one becomes > unwieldly. Networks are large enough that security must be > viewed as an economy of controls and risks instead of as a binary > state of secure or compromised. If your policy is not to root out every last one, then you need to beef up your network so a single compromised host doesn't bring down the whole network. The Internet is evidence that a network can continue to operate even with a very large number of compromised machines on a daily basis. On the other hand, if a single user downloading a music file on your network can take your entire network off the air for several days, you may have a problem. I've often tried to explain that ISPs generally view worms as a "capacity planning" issue. Worms change the "eco-system" of the Internet and ISPs have to adapt. But ISPs generally can't "fix" the end-users or their computers. System admins were able to completely eradicate the Morris worm. But most modern worms like Nimda, Code Red I/II, Slammer stick around. Sometimes a new worm like Nachi supplants an older worm like Blaster. Even if the ISP tries to be the great network firewall, we have mobile computers with mobile code. Laptops are too common, connecting to multiple networks.

5 12

Re: Worm Bandwidth [was Re: Santa Fe city government computers knocked out by worm]
by Daniel Senie 29 Nov '03

29 Nov '03

At 06:24 PM 11/28/2003, Sean Donelan wrote: >On Sat, 29 Nov 2003, Petri Helenius wrote: > > If you are an access provider, specially in the consumer space, you can > > do many things to help the "Greater Internet" by keeping your own back > > yard in good shape. In the transit business, you are expected to > > deliver the bits regardless of the content so there the only viable > > option is to drop packets where the source or destination addresses > > don´t make sense. > >What is the difference between a transit provider and an access provider, >specially in the consumer space? Why is a transit provider expected to >deliver the bits, but the access provider isn't? Since the bulk of >Internet access is actually provided by wholesale providers (e.g. >AOL/Earthlink buy wholesale modem access from UUNET/Level3), who is >the access provider and who is the transit provider? And how do you handle the situation where a provider is both? UUNet, for example, sells LOTS of T-1 lines to non-ISP businesses, and sells retail dialup services to consumers. Sure they also sell wholesale bandwidth and wholesale dialup services to ISPs, but it's not their whole business. The problem isn't "someone else's problem" for anyone.

2 1