ditto regarding the badly disguised spam stuff.

I was here before there were user id's and I just happened to get in pretty early the day they opened registrations.

I get Sydney because that is one of the only places that is approximately 30ms away. The details on what the traceroute's actually had in them are fuzzed away by the reporter, so you can't rely on them to say anything in particular.

Anycast nodes switching about could look a whole lot like the latency just going up to the uninitiated. Most internet providers don't actually have a huge say in which anycast node for a service gets chosen by their network unless they actually have a local node in their own network.

To address the issue in the article, I expect that if Chorus / Telecom received a request to tap your connection you will never know that they have tapped it. The dark fibre circuits we have through them are provisioned on day one with an optical tap that is configured to direct a small percentage of the light to any gear that they might one day connect to it. The latency would be completely unaffected.

What makes more sense given the story is that Dotcom was on a fast fibre tail using a service that was actually in Sydney somewhere ( ~30ms away ) and for whatever reason this service switched to a node in the middle of the USA which could be 180ms away. Nothing there to do with taps or government conspiracies. They may well have been tapping his circuit as well, but the latency won't be anything to do with it. Even if they did have to divert his connection through some GCSB site, the latency would not be as high as 180ms.

As far as ping times to perth, from the same box in skytower:

[ ~ ]$ ping www.perthix.com
PING www.perthix.com (203.188.158.32) 56(84) bytes of data.
64 bytes from 203.188.158.32: icmp_seq=1 ttl=120 time=81.3 ms
64 bytes from 203.188.158.32: icmp_seq=2 ttl=120 time=80.1 ms
64 bytes from 203.188.158.32: icmp_seq=3 ttl=120 time=81.2 ms
^C
--- www.perthix.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 80.181/80.933/81.383/0.628 ms

I've got my own access card for Level 47 and 48 of Sky tower, I'm aware of exactly what it is and why we decided to buy co-location space up there.

Our connection from skytower has to go a way across town before it hits the southern cross landing station, so the best case latency across southern cross is a bit lower again.

My point earlier on was that you can get anywhere return trip in New Zealand on a fibre circuit in under 35ms. Add the 24ms to get across to Australia or the 120ms to get to San Jose and you still don't get to 180ms unless you are using ADSL2+ or cable. Our POP in Christchurch is 20ms from Skytower in Auckland.

I get 24ms between a host in our network physically in Skytower in Auckland and a host in a Vocus datacenter in Sydney.

[ ~ ]$ ping ns03.vocus.net.au
PING ns03.vocus.net.au (203.92.28.98) 56(84) bytes of data.
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=1 ttl=55 time=24.8 ms
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=2 ttl=55 time=24.6 ms
64 bytes from isv02.syd01.nsw.VOCUS.net.au (203.92.28.98): icmp_seq=3 ttl=55 time=24.7 ms
^C
--- ns03.vocus.net.au ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.698/24.761/24.872/0.150 ms

200 is totally awful! How much of that is made up by the last mile latency?

At the place I work, I would accept as a fault any report from a customer of latency of 200ms to anywhere physically in New Zealand ( aside from end customer tail latency ). Most ISP's in New Zealand peer at either WIX or APE or both and we pay extortionate rates for paid peering with Telecom and TelstraClear to handle the two exceptions to that rule.

The worst case for us is that we have an end customer in Christchurch that is talking to an end customer in Christchurch of an ISP that only peers with us in Auckland. Even that only means about 40ms worst case plus the latency of the tail circuits.

If I recall correctly ( cant remember where I read it ) Mr Dotcom had fibre from his place at Coatesville to sky tower. That is something in the order of 35km, which should be like 1 or 2ms. You would have to have a very home user grade circuit like cable or dsl to get exactly 30ms across Auckland.

If the latency figures in the article are accurate then the traffic wasn't staying in the country at all. You can get from one end of the country to the other in 35ms round trip, so even the original 30ms seems rubbish unless the circuit was DSL. The way they were making out it was a high end connection that doesn't seem likely. 180ms will easily get you too Australia and all going well will get you to San Jose from New Zealand.

Since about '93:
Slackware
Redhat
Suse
Ubuntu
Mint

What if you have run something that updates the id3 tags, album art or volume levels as I expect most people do. I ran windows media player once ( by mistake ) and I think it wanted to do this by default? Any fiddling with any of the stuff in the header is going to change the hash of the file completely. I guess they could get more sophisticated and just hash the parts of the mp3 that aren't in the header. I'm sure you could get around that by just flipping the least significant bit somewhere in each track. Seems like prosocuting based on that would be getting into voodoo territory for the cops in my country. I reckon equal odds of bringing in a psychic and presenting a 'strong feeling' the mp3's are the estranged child of some RIAA IP. In all seriousness they would just ask you where the originals are and hope that you don't have a plausible story about a house fire or burglary or something.

The range of a wireless link is determined by adding the strengths of the Access Point and Client antennas together. To state it another way, if someone puts a higher gain antenna on their laptop then they can connect to your AP from futher away. Trying to secure something by diffuse or decrease your signal strength at the AP end is a great way of feeling more secure without actually being more secure.

Or a 2 digit one that just turned up to tell everyone to get off his lawn =)

I don't know how to say it better than I did in the post you were replying to. I'll try, but perhaps you should read it again.

You can stop almost everything you don't want coming in with a non-stateful static ACL on the upstream router or something like a 3750 switch. The web server or reverse proxy or whatever you have then only has to handle traffic destined for port 80 ( and perhaps ssh from a couple of IP's ). A switch or a router can run that ACL in hardware at the line rate of the port without operating a state table at all, and it doesn't give the attacker a new easy way of taking your site out.

Theres no reason why the host can't have local firewalling too, but it is pretty well irrelevant at that point.

Well hopefully you aren't going to be consulting on anything important that gets deployed.

A stateless ACL on a switch or router that does it in a hardware path will do just fine dropping packets destined for unintended services, and it won't act as an additional attack vector.

A firewall in front of a server farm is a 'layer' that only does harm, and does not do any good.

The article writer is just a clueless journalist but the guy he is getting the technical content from knows what he is talking about. Look up the NANOG archives for Roland Dobbins if you want to read through the flame wars along these lines before. Any firewall that does stateful filtering is just another attack vector in a big web server deployment. Most firewalls can be either crashed or will start refusing new connections with only a few thousand packets per second of the right stuff. Either way your site is down and the DDOS successful when it happens. If you put in non-stateful ACL's on a router or switch that does them in a hardware path in front of your web farm to filter anything other than port 80 then you can eliminate most of the cruft at line rate without giving the attacker a nice juicy state table to destroy. Your web server has to maintain the connection state to run anyway, so why not just let it do that and have the problem distributed among all your web servers, they deal with it a heap better than any firewall.