January 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

AT&T NYC
by Bryan Heitman 03 Sep '03

03 Sep '03

Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc.

10 11

Blocked by msn.com MX, contact for MSN.COM postmaster ?
by Miquel van Smoorenburg 20 Feb '03

20 Feb '03

I found out that our outgoing SMTP servers have been blocked by the msn.com MXes. In a nasty way, too -- no SMTP error, the TCP connection is simply closed by them immidiately after establishing it. We're not listed on any RBL/DNSBL and have an active abuse desk. I mailed postmaster(a)msn.com, msnhst(a)msn.com, noc(a)microsoft.com, but didn't get a reply from any of them. Does anyone here know who to talk to ? Thanks, Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams.

5 4

What could have been done differently?
by Sean Donelan 04 Feb '03

04 Feb '03

On Tue, 28 Jan 2003, The New York Times wrote: > A spokesman for Microsoft, Rick Miller, confirmed that a > number of the company's machines had gone unpatched, and > that Microsoft Network services, like many others on the > Internet, experienced a significant slowdown. "We, like the > rest of the industry, struggle to get 100 percent > compliance with our patch management," he said. Many different companies were hit hard by the Slammer worm, some with better than average reputations for security awareness. They bought finest firewalls, they had two-factor biometric locks on their data centers, they installed anti-virus software, they paid for SAS70 audits by the premier auditors, they hired the best managed security consulting firms. Yet, they still were hit. Its not as simple as don't use microsoft, because worms have hit other popular platforms too. Are there practical answers that actually work in the real world with real users and real business needs?

20 29

Tracing where it started
by Phil Rosenthal 04 Feb '03

04 Feb '03

Hello, It might be interesting if some people were to post when they received their first attack packet, and where it came from, if they happened to be logging. Here is the first packet we logged: Jan 25 00:29:37 EST 216.66.11.120 --Phil ISPrime

21 32

Remote email access
by Dave Crocker 04 Feb '03

04 Feb '03

Folks, The Ops community and the IETF Email community appear to have different views about appropriate methods for email posting. The difference frequently means that an effort to post a new message from a network with a firewall, to a remote SMTP, is blocked by the outbound firewall. Blocking outbound SMTP (port 25) is supported by the Ops community as a spam-suppression mechanism. Ops support for this blockage appears to be deeply and broadly held. This note is *not* an effort to debate the Ops concern or the preference for blocking outbound port 25. Rather, I would like to pursue a discussion that simply resolves the disparity between the two communities. The goal is to obtain a coherent recommendation that is acceptable to the Ops and the Email communities. It would permit normal users to easily use their normal software and achieve normal access to normal services. Whatever the current choices are, they are inconsistently available and they frequently require technically knowledgeable users and/or special cooperation by the user's remote ISP. My guess is that a brief IETF BCP document would suffice for describing the recommended profile. For completeness, I suggest that the BCP cover "Remote email access" for posting and retrieval, and that it recommend the details that will permit private, authenticated access for all standardized email services. Some current choices: Email standards provide for posting of email to the usual port 25 or to port 773 for the newer "submit" service. (Submit is a clone of SMTP that operates on a different port and is permitted to evolve independently of SMTP, in order to tailor posting by originators, differently from server-to-server email relaying.) There is also a de facto standard for doing SMTP over SSL on port 465, although this collides with the IANA assignment of that port to another service. Standardized SMTP authentication uses the SMTP Auth command or the SASL service within SMTP. It can also use the de fact "POP hack". All 3 of these mechanisms are inline -- as part of the posting protocol -- so that they work over whatever port is being used for posting. Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with SASL. SASL can be used on any SMTP or Submit port. SSL can only be used on port 25 if the SMTP service is not available to other SMTP servers for relaying (or, really, for last-hop SMTP delivery). Some choices are easier for users. Some are easier for service providers. Some are supported more broadly in current software. We need to narrow down the recommended choices, preferably to one per service. Thoughts? d/ -- Dave <mailto:dhc2@dcrocker.net> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850

9 9

Re: What could have been done differently?
by Scott Francis 01 Feb '03

01 Feb '03

On Thu, Jan 30, 2003 at 10:39:17AM -0800, hino(a)ccrl.sj.nec.com said: > IIRC, MS's patches has been digitally signed by MS, and their patching > system checks these sign silently. So, they will claim that > compromised route info and/or DNS spoofing does not affect their > correctness. > > Though, I'm not sure what will happen in key revoking situation. interesting side note ... top of the page right now at http://www.ntk.net details a similar problem facing MS in the UK currently. (Remember when they forgot to renew hotmail.com, and some kind Linux geek fixed it for them ... well, apparently their entry in the Data Protection Register (UK) expired January 8. This means all personal data held by them in the UK is now illegal (passport, anyone?) I wonder if something like this would be useful (or even possible) in the US, of if it would be just another opportunity for bureaucratic bungling ...) > Koji -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui

2 1

Internet Monitoring Center
by Sean Donelan 31 Jan '03

31 Jan '03

Who has the biggest wall of big screen monitors? http://www.washingtonpost.com/wp-dyn/articles/A3409-2003Jan30.html

4 5

Any commodity ISP support end-to-end MTUs > 4470?
by Joe St Sauver 31 Jan '03

31 Jan '03

Hi, Is anyone aware of a commodity ISP supporting end-to-end MTUs greater than 4470 octets (e.g., a 9180 octet "jumbo frame"-clean path, for example)? Feel free to drop me a note directly; I'll summarize for the list if I hear from anyone. Thanks, Joe St Sauver (joe(a)oregon.uoregon.edu) University of Oregon Computing Center

1 0

RE: Internet Monitoring Center
by Kuhtz, Christian 31 Jan '03

31 Jan '03

I very much agree with Vladis here. I'm probably stating the obvious, but.. One of the major points visible during virtually any one of these significant security events is the way coordination works, how well processes are defined and how well they end up working in terms of tactical detection & response. Sure, strategic preparation is crucial, too, laying the ground work for tactical activities, but ultimately it matters how well you can execute and communicate. Question on my mind is just how much more aggressive the impact of a worm etc can be before it overwhelms the ability to coordinate effectively to stop it before everything goes critical. As we gear up on the service provider side, the other side in this arms race tries to think of new ways to create maximum damage quickly. If they fail to beat the their victims to the punch, they fizzle. I don't believe that a large scale monitoring center is effective in the long run as communication becomes evermore pervasive. I believe a coordination/communication's facility is far more effective, and we'd all be better served with that. But unless we can demonstrate that information overload along the lines of "more isn't necessarily better" doesn't increase effectiveness, these knee jerk reactions (with secondary agendas) will continue ever since they were kicked off post-9/11. In fact, I don't think it's all that far off to think that the scale required will tie up tremendous resources and just be in itself another target for being DoS'ed by way of information overload. And I'm not even going to go down the road of all the concerns of what happens with the massive amount of information being collected, in a jurisdiction lacking effective privacy protection as it is. YMMV. Thanks, Christian -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] On Thu, 30 Jan 2003 04:21:40 CST, Jack Bates <jbates(a)brightok.net> said: > in this. My question is why large providers couldn't interlink themselves > and establish guidelines for notification and resolution of network issues. > They manage it for peering, why not for overall performance and security > issues? "I'll get back to you Tuesday or when NANOG posts embarrass me" works for peering issues, but not for security issues. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."

1 0