- Test - lists.nanog.org

Microsoft Product Informational Resources
by Ben Arnold 22 Jan '04

22 Jan '04

After reading NANOG for a few years now and I have found the information here to be very helpful. After sharing the wealth of information I have found here with some of the members of the MIS department here, they asked if there might be some similar organizations with a focus on Microsoft system and network administration. They have access to the MSDN services; however, they were particularly interested in an organization not directly affiliated with Microsoft that might have a comparable level of knowledge as those in NANOG do regarding networking. If anyone has any ideas for such resources, the suggestions would be greatly appreciated. Also if there are past threads that I might have overlooked regarding this subject and someone will point me that direction, I will gladly search the archives again. Thank you to all for the great information in the past and any future suggestions. Sincerely, Ben Arnold Network Operations barnold(a)vpntranet.com VPNtranet, L.L.C.

1 0

AS number for i.root-servers.net.
by Lars-Johan Liman 22 Jan '04

22 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Friends, Those of you who treat routing to the root DNS servers in a special way, can you please verify that you treat the routing to i.root-servers.net (the NORDUnet/Autonomica server administrated from Stockholm) the way you intend. Prefix: 192.36.148.0/24 Originating AS: 29216 NOTE: This prefix is anycast from several locations on the net (currently Stockholm, Helsinki, London, and Milan), but in all cases, the originating AS should be 29216. The source AS was changed in October 2003, but we suspect that the change from the old AS (8674) hasn't quite been communicated to all dark corners of the net. Please help us convey that information. Best regards, /Liman hostmaster(a)i.root-servers.net #---------------------------------------------------------------------- # There are 10 kinds of people in the world. Those who understand # binary numbers, and those who don't. #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQCVAwUBQA+gLzySCHj+AqGZAQF32QP9E5ZfmpXVuU9jZULHtOE30sG0SyBBImFK lP90UgKjIj9yFsLtqwzKf8NcwgRDzAfUtiiMNUPCbhItHZPT8dYiEuBXM/96fH/t TqSoG+LfJb5lHfo8BKE1257g/3VC+EKZwYDOyr3O+ceWfl3hL86qXxzqxUxs0Xj7 BY8T6YEy4pc= =SlP3 -----END PGP SIGNATURE-----

1 0

Re: sniffer/promisc detector
by Dave Israel 22 Jan '04

22 Jan '04

Clipped for brevity... On 1/21/2004 at 10:52:00 +0000, Michael.Dillon(a)radianz.com said: > > >> > Uhm, that would be wrong. This is simply "security through > obscurity". > >> Yes, it is wrong for the _smart books_. But it works in real life. > > >Actually, an automated script or manual scan can find it trivially. > > If security through obscurity was useless then the USAF > would never have developed the stealth bomber. [...] Yes. But making a bomber "stealth" means designing it to be difficult to detect by an opponent. It doesn't mean painting "I am Not a Bomber, I Am The Ice Cream Man" on the side and hoping nobody takes a second glance at it. Somebody else pointed out that nmap in its basic mode isn't terribly fast. That's true. But redesigning for speed wouldn't be that hard. Scan lots of ports in parallel, checking just for an ACK back from a SYN, then go through those that responded in order of likelihood (22, then unassigned ports, then assigned ones), and having it stop when it finds ssh, and you reduce the time required by several orders of magnitude. And that's assuming you don't have the help of tons of zombies. If everybody tries to get obscure with their ports, then this will become common, and it will be the people who are legitimately trying to connect who get annoyed by the obscurity. And if you're only trying to provide services for members of your organization, a VPNish solution makes a lot more sense than complicated custom port juggling. So, okay, sure, like many other things, if a small number of clueful people are doing this, then they will reap benefits for it. If it becomes widely spread practice, there will be more harm than good from it, and people will start ignoring it, working around it, and/or taking direct action against it that will render it pointless or harmful to the user. Lots of things have hit this death and been forgotten or relegated back to the fringe. I'll risk the wrath of many and mention multicast. Somewhere out there, Randy Bush is probably thinking of his vision of the future of deaggregated /24s. -Dave

2 1

Nachi/Welchia Aftermath
by Brent Van Dussen 21 Jan '04

21 Jan '04

Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of remaining infected hosts were rebooted and the worm removed itself. Network traffic has finally returned to normal. What kind of effects did everyone see from this devastating worm and what lessons did we learn for preventing network downtime in the future?

14 24

Re: Nachi/Welchia Aftermath
by sthaug＠nethelp.no 21 Jan '04

21 Jan '04

> T(> The 2948G-L3 and the 4908G-L3 I believe are Prefix/ASIC based. > T(> I believe the 3550-EMI is as well, but I'm not familiar with that > T(> equipment. All 3550s are prefix/ASIC based, EMI or SMI doesn't matter. > Anyone know about the: > Cisco Catalyst 3750 ? 3750s are also prefix/ASIC based. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Outbound Route Optimization
by Paul Vixie 21 Jan '04

21 Jan '04

> > ... depends on your isp, and whether their routing policies (openness > > or closedness of peering, shortest vs. longest exit, respect for MEDs) > > are a good match for their technology/tools, skills/experience, and > > resources/headroom. > > In practice, all of the above just turn out to be marketing sauce > or in some cases, outright lies. well, sometimes. if someone claims to do longest exit but is buying a congested L2-in-L2 or L2-in-L3 pipe from someone else to do "remote peering" in order to avoid spend, then they lied. on the other hand if someone spends like hell on their core infrastructure but then runs RIPv2 as their igp and doesn't peer except in three places worldwide then all the money in the world won't help their measured performance. > There is no substitute for dollar spend (opex and capex) to make > a network perform. There is no magic sauce, there is no silver > bullet. You have adequate resources, you will have adequate > performance. see above, i mostly agree but there have been counterexamples. > > metrics, which is usually not very good. but there's another limit, > > which is bgp path symmetry. most tcp implementations are still > > stone-aged > > AKA optimizing for outbound doesn't do you any good on optimizing > for inbound. more to the point, even if you have an outbound-heavy customer base, your inbound quality still going to have an impact on your output quality, and your inbound quality is generally unaffected by spend alone. > > (experience says they're not going to trust your MEDs even if > > they're close enough to hear them.) > > Most people don't trust MEDs for a reason paul, and it is not because > they want to mess with your customers. whoa there big guy. i didn't say, either in the part you quoted or in the part you didn't quote, that not listening to med's was evil intentioned. not that it matters. intentions are irrelevant, the fact is that there aren't a lot of ways to control the routing decisions made by others. the most you can do is give other networks more opportunities to shortest-exit onto your network where you, if you've spent enough, can make things like quality and symmetry happen.

1 0

Re: Diversity as defense
by sgorman1＠gmu.edu 21 Jan '04

21 Jan '04

I can see how the biology analogy could lead itself to preordained outcome, but I do not think it was the case in this research. For one it is really just a biology analogy, the mathematics are standard graph theory/statititical mechanics. Actually, the original results we got back from the simulations had mass network failure occuring when 23-24% of nodes were compromised, all being of the same species. Ended up we had a flaw in the code, but with that result you could not really argue that monopolies cause a security vulnerbility. It would be impossible to enforce a mandate saying no one vendor could have more 23% of market. The conclusion would be that even with a thriving competitive market vendor specific vulnerbilites can do heavy damage. Going after Microsoft or any other quasi monopoly in this case would not accomplish much. If you look at code red affecting microsoft servers, they only made up 23-24% of servers connected to the Internet at the time (and that was all MS.... I will say it is easy to fall into the politically biased trap, especially as more people pay attention to what you are doing, but it is something we try hard to stay away from. Sorry if this has wandered of topic in that regard. As an aside it is interesting that no worm has yet exploited a platform that has a large market share and is at the core of the network. ----- Original Message ----- From: Jamie Reid <Jamie.Reid(a)mbs.gov.on.ca> Date: Wednesday, January 21, 2004 11:20 am Subject: Re: Diversity as defense > > These questions are of a personal interest etc... > > Interesting use of biological metaphors. Is security accurately > expressed as an > economy? Or rather, can security problems be solved as problems of > economy? > > I think it is a very compelling and thought provoking paper, but I > wonder if using a > specific biological model to support an economic conjecture is > sufficiently immune to > being coloured by political bias. > > I am not accusing the authors of unacknowledged bias, however, the > segway > from a biological model to an economic conclusion exposes the > conclusions to > being interpreted as a moral indictment of monopolies in the > marketplace. > > I don't mean to harp, as I have asked questions about the > motivations behind > some of your research before (namely the value of linking of > attacks to country > of origin), and I hope have any of my misconceptions corrected as > effectively > as they were previously. > > Best, > > > > > -- > Jamie.Reid, CISSP, jamie.reid(a)mbs.gov.on.ca > Senior Security Specialist, Information Protection Centre > Corporate Security, MBS > 416 327 2324 > >>> <sgorman1(a)gmu.edu> 01/19/04 03:35pm >>> > > > We've been seeing a bit of media attention of late to diversity as > a technique to make networks more secure: > > http://news.com.com/2009-7349_3-5140971.html?tag=nefd_lede > > The usual suspect is Microsoft with 97% of OS's, but Cisco's 86% > of the router market has been cited as well as SNMP > vulnerabilities of two years ago. The diversity, monoculture and > agricutlure analogy makes nice press, but how realistic is > diversity as a defense. Is cost the biggest hurdle or limited > avaiability of competitive products, or simply no bang for the > buck by diversifying. We've run some simulations testing the > effects of different levels of diversity, but wanted some feedback > on feasibility. > > http://arxiv.org/abs/cond-mat/0401017 > > Any comments, feedback or discussion would be greatly appreciated. > > best, > > sean >

1 0

Re: sniffer/promisc detector
by Dave Israel 21 Jan '04

21 Jan '04

On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said: > > > > > > Uhm, that would be wrong. This is simply "security through obscurity". > Yes, it is wrong for the _smart books_. But it works in real life. Of > course, it should not be the last line of defense; but it works as a first > line very effectively. > > If I rate safety as a number (10 is the best, 0 is the worst): > - unpatched sshd on port 22 - safety is zero (will be hacked by automated > script in a few weeks) > - patched sshd on port 22 - safety is 5 (even patched sshd have a bugs, and > I do not know, what happen first - I patch next bug or hacker's script find > this sshd and hack it) > - unpatched sshd on port 30013 - safety is 7 (higher) because no one > automated script can find it, and no one manual scan find it in reality > - patched sshd on port 30013 - safety is 9 > - turn off power - safety is 10. Secure system, is a dark system. > > (I did not rated firewalls etc). Actually, an automated script or manual scan can find it trivially. All you have to do is a quick port scan, looking for this: 12:31 biohazard~>telnet [somewhere] [port] Trying [ip_address]... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_3.4p1c Plus, if you put it on a non-standard port, you tend to use the same one across the enterprise, so it is only really obscure once. Moving port numbers only protects you against idle vandalism; it is useless against people who truly wish you harm. You really need a firewall, particularly one that can detect a port scan and shut off the scanner, for changing ports to have any real security. It is kind of like a 4-digit PIN being useless for a bank card without the 3-try limit. -Dave

3 2

sniffer/promisc detector
by Gerald 21 Jan '04

21 Jan '04

Subject says it all. Someone asked the other day here for sniffers. Any progress or suggestions for programs that detect cards in promisc mode or sniffing traffic? Gerald

19 30

RE: sniffer/promisc detector
by Michel Py 20 Jan '04

20 Jan '04

> Alexei Roudnev wrote: > - turn off power - safety is 10. Secure > system, is a dark system. I have to disagree on this one; there is WOL (Wake-up On Lan), the system can be lit remotely. - turn off power - safety is 9 - Unplug all cords - safety is 10 Michel.

2 1