Slashdot Mirror
Fort N.O.C.'s Security in Obscurity
penciling_in writes "Brock N. Meeks of MSNBC reports
on his recent visit to VeriSign's secret location: 'The unassuming building
that houses the "A" root sits in a cluster of three others; the architecture
looks as if it were lifted directly from a free clip art library. No signs or
markers give a hint that the Internet's most precious computer is inside
humming happily away in a hermetically sealed room. This building complex could
be any of a 100,000 mini office parks littering middle class America.' The
report goes on to say: 'Access to the Network Operations Center, the "NORAD"
of the Internet's traffic monitoring, requires the electronic badge and then a
double biometric hand print scan.' And here are Karl
Auerbach and Robert
Alberti offering their interesting analysis of this report on CircleID."
Sure, the
I'm still fuming about that.
Trolling is a art,
Although the article says that the location is a secret, a link from the article to www.root-servers.org happily tells you that server A is in Dulles.
Sigh. Deep Sigh.
There's more than the 'A' root server. Taking "it" down leaves a whole hurd of other root servers alive. Located all around the world.
The above linked articles are full of that which promoteth growth.
This is also the building that has the big red button labeled "Hijack Internet Traffic"
One bad monkey spoils the whole barrel.
It's cool to see someone write about the building you used to work in! I worked in this building, a bit more than 2 years ago. I was in Network Solutions' consulting arm, whose DC office was in that building, two floors under the NOC. The security really is as spectacular (and low-key) as you'd expect. You would NOT believe the camera surveillance they have facing outwards...you can see some of it, but you can't see some of them at all. And the cameras themselves are startlingly cool...there's a small strip mall across a major highway from the facility, with a clear line of sight. One of the security guys showed me how far the zoom worked, as he zoomed in on a guy smoking in front of a bookstore in the strip mall...about half a mile away. It was still a clear picture.
When 9/11 happened, we were not allowed back into the building for a couple of days, but all they had to stand up as barriers were road cones. Luckily, they're finally moving to a location that isn't just obscure and secure, but armored, as I hear their Mountain View, CA location is.
For your security, this post has been encrypted with ROT-13, twice.
If this building were destroyed by a nuclear weapon, what would be the impact on the Internet?
The temple from Tron?
Approch, Program, and speak to your User...
Never answer an anonymous letter. - Yogi Berra
This story is news, but I kept expecting some point of contention in the article, rather than some musings on decorating schemes that were compared to clip art.
I found my point here:
The root server operators "have no contract with anyone, no guarantee of level of service, they could turn [the root servers] off tomorrow with no consequences at all because they are doing it out of the kindness of their heart," said Internet consultant Ambler. "ICANN needs contracts with the root server operators that specify minimum levels of service and minimum levels of security and the root servers need to be paid for that," he said.
Why is it so confusing to imagine that (a) People do like to do things out of the "kindness" of their collective hearts, and (b) security is not always "secured" by either contracts or money? I understand the legal protections associated with contracts, but I think there's a chance that the root server operator system, as it stands, could alternatively be viewed as something successful - something, much like the open source software movement, that works, not because of contracts or restrictive covenants, but because people enjoy contributing to something useful for their own and others' use.
I guess amazon.com which went public in 1997 must have been frequented only be researches and nerds for the first 5 years of operation.
Back in the good old days, if you had a recent copy of hosts.txt all this was irrelevant :-).
But it's been most of a decade since just anyone could download it.
If you really wanted to hide it, disguise the building as a whore house next door to a police station.
The hookers and the johns could really be Verisign employees running the root server.
In case a real customer showed up and was unfazed by the police station next door, tell him that most of the girls are at the doctors office for their tuberculosis test and the rest are being treated for various venereal diseases.
Or you could disguise it as a crack house. The neighbors would assume that everyone running around with machine guns were drug smugglers.
Or just disguise it as a police station. When someone comes in seeking assistance, tell them "We don't handle those kind of cases any more."
I can only hope that their NOC has multiple fibers coming to the building and that those fibers aren't in the same trench.
The other potential source for a single-point of failure is the OS that the root server uses. If Verisign uses any kind of monoculture, they will not be as secure as we might hope. A hacker or botched OS patch could hose the thing.
Two wrongs don't make a right, but three lefts do.
Bah! That's nothing. You need to traverse a gauntlet of obsolete motherboards, dead power supplies, empty CD cases and soda cans as well as a floor mined with tiny machine screws to get to my NOC. That's assuming you got past my wife at the front door.
In Australia in the past year or two, some folks dressed up as maintenence workers and drove off with an allegedly important government server.
So it does happen.
I still have to test every 5-pin simplex lock for important rooms to make sure that it's not a simple combination, because when I had access to a datacenter, it was a damn simple lock.
Gentoo Sucks
Nope, VeriSign was never in Palo Alto. It was dotCom era, rents in Palo Alto were way high by that time. VeriSign started in Redwood Shores and then moved to Mountain View. These days they own the old Netscape campus.
The operations center is another matter, those are in unmarked buildings at several locations. If you look at some of the displays of root server locations you will see blobs in the San Francisco and Washington D.C. areas. Well duhh! Who would have guessed that the DNS servers would be so close physically to MAE West and MAE East?
The Circle ID stories are both slashdotted. So we can't hear if Karl and co are saying 'nah, we don't need high bandwidth roots capable of a good slashdotting' which if they were would be somewhat ironic.
The point that the article does not really mention is that at the moment running the DNS roots is done on a voluntary basis. ICANN is getting a free ride here. After the DDoS event in 2002 it was clear that 1) the roots were a major target 2) There was a big difference in the quality of service.
Given the importance of the roots shouldn't we actually invest something so the people running them can afford to do the job well? VeriSign can afford to run its systems the way it does because it has revenue from other sources. How do you justify the cost of a high end four way server to be dedicated to root ops if you are a non-profit? ICANN could at least pay for hardware and bandwidth.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
The design documentation of the Internet is globally available... wait for it.. on the Internet!
If you examine it, you will notice that
a) DNS is not part of the original design
b) as designed, it WON'T survive a nuke
c) nobody intended it to.
What it *was* designed for was a limited fault tolerance - based on the idea that phone companies suck and the guy that runs the next node is an idiot who can't be trusted to tie his own shoes.
Turns out they were right about those last two points, incidentally.
Many of the root server operators have deployed mirrors of their machines using "anycast".
.com, .net, .org, and .in-addr.arpa. The roots are heavily cached and easily replicated. It isn't quite so easy to handle a loss of connectivity to the big top level domain servers.
Anycast is a way of using routing information so that a single IP address appears at many locations on the net. Packets flowing to an anycast IP address tend to go to the nearest instance of such an address.
Physical security isn't the risk that the roots face - the issue is damaged connectivity to those 13 addresses on which those root machines are to be found.
As I mentioned in my note on Circle-ID, the biggest risk isn't to root servers but rather to the set of servers that deliver
I've suggested a "DNS on a CDROM" (which I guess should be updated to "DNS on a DVD") in which all the stuff needed to get a local but limited DNS running in cases when a community has been cut off from the main body of DNS services.
Unless the NOC was ordered at this place, I'm not impressed.
Hate me!
You mean like this?
ROOT-A /--
--\
)(
--/ \--
20 MBs
- Distributing the database to major servers (at least one machine from each of the 13 often-virtual root servers, plus the master DNS servers at the Tier 1 ISPs, the CCTLD servers, and some small number of other sites
- Answering DNS queries from the major servers
- Answering DNS queries from any random machine on the Internet
The system becomes performance-critical to lots of people because too many machines send queries to the root servers (or theThe root zone itself is probably under 10KB of data that doesn't change every day - if you provide a separate server for zone transfers and let 1000 other DNS servers have access to it (firewalled to prevent any other IP traffic), that's about half an hour on a 56kbps modem. Remember that all it's doing is answering good questions like "Where are .com's name servers?" "Where are .za's name servers", bad questions like "Where are .example,com's name servers?", "Where is 10.in-addr.arpa?" and ugly questions like "Where is Ping of Death?". Let the major servers handle most of the work, absorb the ugly packets and do some queries for bad packets, and let the general public query those anycast machines - they should be querying their ISPs' servers, or their upstreams', which cache the real information, and even when their queries aren't bogus, they shouldn't be blocking the internet-stability-critical traffic.
The .net, .com, and .org domains are a similar problem, except of course they aren't served by the root servers. The zones are much bigger, a few gigabytes size, but probably only 10% of it changes in any given month, or 99.9999% of the existing domains, which ought to be enough to call the Internet stable, using about 1 Mbps (10GB * 1%/day * 8 bits/byte / 24*60*60 ), and again, keep the public query traffic separate from the zone transfer traffic, and maybe offer a third set of DNS servers to answer queries from the big ISPs to handle things like newly created domain names. The reason to keep that kind of query traffic separate is to avoid attacks like "query bogus00001.com" "query bogus00002.com" ... etc.
Obvious flame-attracting discussion points:
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
According to an October 2002 study, 98% of queries to the F Root Server (and therefore probably to the other root servers) are unnecessary. Either they're duplicates (75%) or they're for bogus TLDs (.localhost, .elvis, .corp, etc.) or they're in-addr.arpa queries for RFC1918 addresses, or they're some other bogus query, and they should have been served out of cache or handled by some ISP's DNS instead of bothering the roots. Maybe the A Root has some important functions, but they aren't what it spends its time on. And 50% of the queries come from about 220 servers - they should either be caching responses, or be shuffled off to some server that handles them (I guess anycast will help with this...) as well as cleaning up their act if they're broken, which some of them are.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks