- Test - lists.nanog.org

Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
by Michael Lamoureux 10 Dec '02

10 Dec '02

"michael" == Michael Dillon <Michael.Dillon(a)radianz.com> writes: >> How do we get software vendors (free, pay, virus) to distribute >> software with appropriate defaults? michael> Second step, publish a directory. I.e. detect the michael> non-conforming devices and publish their IP addresses in an michael> LDAP server. Let me get this straight, you are suggesting that the way to fix the problem that there are potentially millions of insecure machines connected to the Internet is to *PUBLISH* the IP addresses of all of them in an easy to parse format? Cute. Don't tell me...we'll be able to pull the vulnerability that got the hosts in the list too, so we can verify that "our" machines are, indeed, misconfigured? ;-) baffled, Michael

1 0

Route Views
by Harsha Narayan 10 Dec '02

10 Dec '02

Hello, Some prefixes in the Route Views routing table do not have a prefix length specified. For example, 4.0.0.0 and 61.0.0.0 do not have a prefix length specified in the Route Views routing table. 61/8 belongs to APNIC. 4/8 belongs to Genuity. Why is this? How does one find out the prefix length in such cases? Harsha.

3 2

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> > I wouldn't be surprised to see this picked up in the Cook Report and some > > of the trade press because of your postings. The more people become aware > > of how the system is broken, the sooner we can fix it. > People actually read that? Yes. The people who don't read NANOG do read the Cook Report and the trade press. If you want to reach everyone in charge of operating a network then you need to use more media than just NANOG. > A simple solution: > 1) IANA creates an IANA-RESERVED IRR object > 2) Entities switch to using this for their filters, and the > updates happen automagically This is essentially what I am suggesting except using LDAP rather than RADB/IRR technology. I don't believe that RADB will ever be used by the majority of North American network operators but I do believe that LDAP has a chance of 100% penetration in the same way that 100% of network operators use UNIX servers and scripting languages in their network operations. --Michael Dillon

1 0

by popular request, was Guam
by David Lesher 10 Dec '02

10 Dec '02

http://longlines.addr.com/places-routes/Monrovia/020719B-11.jpg http://longlines.addr.com/places-routes/Monrovia/Monrovia.html I think Mt. Weather had same, also. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> I think we can all agree that whoever's responsibility it is, the > current system is broken. You can't actually count on people to read > this list. Absolutely right! And all of this discussion that you have sparked on the list will actually help solve the problem. Unfortunately it ain't gonna happen fast. That's why I would like to see some work done on a general solution to the problem because that will get us a lot more benefit from the effort expended. I wouldn't be surprised to see this picked up in the Cook Report and some of the trade press because of your postings. The more people become aware of how the system is broken, the sooner we can fix it. > Maybe if IANA and ARIN and the other organizations that are > supposed to work together to make all this stuff work weren't so busy > trying to pass the buck, someone might have time to figure something > out... There are more than a few people in ARIN et al. and most of them really do care about finding solutions to these issues. But the Internet is no longer an old boys club which means that there has to be a certain amount of public discussion and process before decisions are made and action is taken. Sadly, this problem could have been predicted but there are too few people willing to think about what we are doing and do some forward planning. ARIN and other membership organizations are only as good as the members themselves. When the members of an organization are apathetic, then the organization doesn't do much more than the same old thing. -- Michael Dillon

4 3

RE: The magic security CD disc Re: HTTP proxies
by Hunter Pine 10 Dec '02

10 Dec '02

As much of a flame magnet as this post may be, I'd actually like to commend MS for their security efforts on Windows XP. If you don't know how to update your system, who cares, XP bugs you by default to install updates. If you don't click on "OK" when it tells you to patch security wholes, who's to blame? MS can't push it, or there'd be yet another lawsuit. If you're not clued enough to understand the concept of passwords in networking security, they've put in a very simple fix, which disallows any user to be used to connect to an SMB share if it has a blank password. Quite a leap from Windows 2000 which doesn't even prompt you for a password to the administrator account it creates. While none of this would stop a determined hacker who has some reason to get to data on your hard drive or something, it does stop the casual exploit scanner from finding machines with open admin access and easy access to install backdoor services, which is more than I can say for most distros of various Unixes. Most computer manufacturers offer their computers with antivirus which automatically update. The adware and spyware stuff, well, users install software, not much you can do about it. Couldn't you just see MS not allowing the install of a program on Windows because it's got spyware? That's a PR nightmare. As another flame magnet statement, I'd just like to point out that linux/freebsd/solaris et al are not designed for the average user to install. The entire lure of linux as a desktop OS is that it's customizable by the user who feels too confined in a "spoon-fed windows environment". Wouldn't shipping a system that has functionality disabled in lieu of security go against this simple principle? If you're such a "computer geek" that you decide you need linux, you'd think you'd do a small bit of reading before jumping into it and installing an insecure machine. As for systems in a server environment, well, I just can't think of any excuse for a sysadmin who installs insecure servers. If you didn't know, than you shouldn't be installing the OS in a server environment anyway. Best regards, Hunter Pine -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Monday, December 09, 2002 6:07 AM To: Sean Donelan; Steven M. Bellovin Cc: nanog(a)merit.edu; Alex Bligh Subject: Re: The magic security CD disc Re: HTTP proxies --On 08 December 2002 23:16 -0500 Sean Donelan <sean(a)donelan.com> wrote: > It takes a lot of time to talk individual users through fixing their > computers. Especially when they didn't break it. They just plugged > the computer in, and didn't spend 4 hours "hardening" it. Most of the > time we're not talking about very complex server configurations, with > full-time system administrators. The "magic" CD would be for people who > don't know they are sharing their computers with the Internet. How unfortunate that the magic CD you refer is not the one with "Microsoft Windows" written on the front :-p Seriously, it is faintly ridiculous that we have operators talking about a magic CD to fix the broken default installations of various operating systems (I include Linux etc. here too). If OS vendors shipped, by default, less broken configs (or at least configs that turned services off - e.g. port 137 - when not required), much, though not all, of this problem would go away. Just like it is (now) considered irresponsible to ship a PABX/Voicemail system with open dialthrough, the same should be true of operating systems. In many such OS's, like it or loath it, automatic or semiautomatic update mechanisms already exist. This would seem to be a good use to put them too. Perhaps NIPC etc. should start talking to OS vendors. Concrete example (not to pick on MS for a change) - every time I've installed a Linux machine I spend 10 or 20 minutes rewriting the (kernel) firewall rules for the box to suit the apps I have installed. It's a completely automable task. Someone unfamiliar with either IP or UNIX would find writing such a script very hard and it would take them much longer. Do mainstraim distributions include such an automatically built script by default? Not to my knowledge. Alex Bligh

2 1

Re: Operational Issues with 69.0.0.0/8...
by bdragon＠gweep.net 09 Dec '02

09 Dec '02

> Hello Everyone, > > I appreciate all of the discussion regarding this issue. Nothing has > changed. This is getting worse. We spoke to one network on Friday that > said they had cleared the problem, yet our users still can't go there. > > For those of you that feel this is not anyone's problem, and that the > internet should just "work it out"; > > I hereby challenge one of you to trade CIDRs with us. You take this > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > resources, and money working out what seems to be "nobody's problem". > Also, if you would like to come over and answer the support calls and > explain to our customers why the competitor's networks can reach these > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > same, right? Ok, you give back the address space to the RIR and get a /19 from your provider. There, problem solved.

1 0

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 09 Dec '02

09 Dec '02

>Why would ARIN specifically provide such a list? ARIN is not responsible >for the unallocated space, and there is more in the world than just ARIN. >There are liability issues with that, not to mention the fact that it is >more an IANA function (if for the sake of argument someone would implement >the list). I consider this to be more of a minor technical issue. ARIN can certain provide an authoritative directory for the unallocated portions of its own allocations. And to answer your why question; because only ARIN has an authoritative and up-to-date view of exactly which addresses are and are not allocated. Rob Thomas is doing some fine work but he is just plugging a gap created by inaction on the part of the RIRs. I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP directories for unallocated IP space at the largest aggregate level. I'd also like to see them all dump the quirky and antiquated whois protocol and move to LDAP as the standard way of querying their directories. The details of which data goes in which directory and whether or not to use referral LDAP or mirrored databases is something which I'm not concerned about. We know a lot about running a distributed directory from experience with DNS so I'm sure that a distributed LDAP hierarchy for the IP address space won't raise any major issues. There is a lot of LDAP expertise out there in the world, lots of books, multiple implementations with years of production experience and people running LDAP directories on a much larger scale than we need. There is no question that it would work, we just need the will to prevail against these problems instead of throwing up our hands and claiming it's too hard, it's impossible and it's not my problem. --Michael Dillon

3 2

Re: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 09 Dec '02

09 Dec '02

Hello Everyone, I appreciate all of the discussion regarding this issue. Nothing has changed. This is getting worse. We spoke to one network on Friday that said they had cleared the problem, yet our users still can't go there. For those of you that feel this is not anyone's problem, and that the internet should just "work it out"; I hereby challenge one of you to trade CIDRs with us. You take this 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, resources, and money working out what seems to be "nobody's problem". Also, if you would like to come over and answer the support calls and explain to our customers why the competitor's networks can reach these sites, but ours can't. Hey - after all, it's just CIDR - it's all the same, right? Some of you have accused others of being too lazy to call the networks that don't work - I assure all of you we have called the ones we know of - over and over. They still don't work. Some of you have suggested that all we need to do is talk to people. We have been calling and talking for a months (almost three to be exact), and the list of inaccessible sites continues to grow. We have called and talked until we are blue in the face. What all of you don't know, is that for the first month we had this CIDR, we could not register hosts on it at NetSol/Verisign, because their core registry did not recognize it. We have been getting F***ed by this CIDR since day one. We have only been successful with two networks in getting filters removed. How many more are out there? I think we can all agree that whoever's responsibility it is, the current system is broken. You can't actually count on people to read this list. Maybe if IANA and ARIN and the other organizations that are supposed to work together to make all this stuff work weren't so busy trying to pass the buck, someone might have time to figure something out... Somebody out there has to have a spare /19 lying around :-) You know - the good old IP numbers like the ones I used to get - they actually worked ;-) What we do know is that the number ARIN took from us sure worked for them. Do you think they would be calling us if their bank suddenly told them that even though they had delivered IP Addresses to us, they could not receive our 3,000.00 dollars because it originated from a bank that has a previously restricted routing code? Todd

3 2

Re: The magic security CD disc Re: HTTP proxies
by Alex Bligh 09 Dec '02

09 Dec '02

--On 09 December 2002 08:39 -0800 Scott Francis <lists-nanog(a)darkuncle.net> wrote: > *cough*OpenBSD*cough* I've had lots of people off-list me to say how wonderfully secure X Y or Z OS distribution is. I am quite sure there is indeed a huge variation. MS fits somewhere into the scale too. The sort of thing I meant though, for example, was how many Linux/BSD distributions, on a *desktop* install, when you select a caching nameserver, have it only bound to 127.0.0.1 rather than bound to INADDR_ANY? Yes, you can tweak the config file, but what % of menu-using users know they should do that, and, if so, do it? How many machines then got infected by a BIND worm that needn't have done? > Taking off my evangelism hat for a moment, I think commercial software > vendors in general will continue to ship whatever maximizes profit. When > it becomes unprofitable to ship insecure buggy bloatware (through legal > liability, for instance), companies will stop doing so. This is exactly my point. If the US government (which appears to be taking an interest), took an interest in making life less comfortable (read profitable) to ship insecure OS's, vendors will start stopping. Until then, security is only something they need package in for those who think they need it - as opposed to 'for the common good'. >From the point of view of traditional microecomics, operating system security has 'externalities' - i.e. costs incurred by third parties. Much the same as pollution. In the general case, sufficient externalities are a good reason to examine some form of government intervention (taxation, regulation etc.). Even when the problems are international, there are historical precedents (drug regulation for instance) for international coordination. Alex Bligh

2 1