12

Internet service was widely disrupted in Egypt starting Jan 27th at about 22:15 UTC, in the space of about 20 minutes: How Egypt Killed the Internet. Service was largely restored 5 1/2 days later on Feb 2 at about 9:30 UTC: Overview of routing activity in Egypt - RIPE

As described at On the ground amid Egyptians' protests It disrupted much more than browsing and messaging:

The handful of bellhops working at the Sheraton Hotel near Cairo International Airport had to scurry from room to room, using their master keys to help guests into their rooms becasue the hotel's magnetic key system wasn't working - it relies on Internet access to update guests' keys.

What other perhaps surprising lessons can be learned here about the ramifications of a DoS attack?

Improve this question
4
  • Some questions. Why are you saying Egypt's "Experiment" ? What is the "experiment" ? And why are you describing it as a Denial of Service ? Wasn't it on purpose? Didn't the gov. ordered the ISPs to shut-down ? Where is the DoS on that?
    – labmice
    Jan 31, 2011 at 9:45
  • 5
    @labmice: The Egyptian government denied service to the customers of the Egyptian ISPs. It might be a de jure DoS rather than a SYN flood, but a DoS it is nonetheless.
    – user185
    Jan 31, 2011 at 12:02
  • @labmice - I was trying to be a bit satirical about the actions of Egypt's government. But I wanted to draw attention to the effects of those actions, which are worthy of study to inform others of the results of a sudden massive lack of availability of network service.
    – nealmcb
    Jan 31, 2011 at 16:07
  • Scarily it appears some folks in the US have not learned from Egypt at all - networkworld.com/news/2011/013111-egypt-kill-switch.html
    – Rory Alsop ♦
    Feb 1, 2011 at 19:49

4 Answers 4

Reset to default
14

We are reminded that testing a 24x7 infrastructure is a Very Hard Problem.

Testing helps

Door locks that depend on internet-access, large enterprise products that depend on unidentified network resources. If you can't disable part of your environment to see what else breaks, you really have no idea.

Obviously, door locks shouldn't depend on internet access and if you decided they should depend on a working LAN, you better make sure it's fully in your control.

I've worked in environments where the NetApp systems and the DNS-systems were mutually dependant, and this was only discovered while bringing an entire datacenter back online after a power outage.

I've worked in environments where supposedly stand-alone, hour long compile processes depended on network resources. This was only discovered when the network failed at a critical time of software release.

Other engineering disciplines (water, power, etc) have had this problem for centuries.

At least in IT environments, you have the option to automatically re-create your environment somewhere isolated and see what happens when parts of your re-created test setup dies.

Design for offline functionality

This is actually my biggest concern with 'the cloud'.

Everything becomes dependant on reliable, high-speed networks. I personally try to work around having to depend on reliable networks: Instead of a web-based CMS that requires network access to edit content in-place, I have a static website that I edit offline and upload when I'm on a fast network.

I sync my IMAP account to local disk, so I don't have to wait for network latency or service availability.

Most of my work these days is stored in git, so I can work fully offline while making it easy to backup and share my work whenever I'm on a fast network.

Google Reader fetches content from around the internet and stores all my feeds until my offline client connects to Google Reader and downloads a full copy. I can get to my desired content regardless of how broken these sites are, because only the route between my computer and Google needs to function.

I know these are very simple examples (and some, like Google Reader, have privacy implications) but anytime you can design a system that allows for full offline mode, while making the best of a network when it's available, I think that's a golden design to shoot for.

Just as a suggestion: Perhaps door locks should be able to cache some sort of credentials for X hours or days to prevent network problems from rendering an entire hotel inoperable.

Improve this answer
1

For every intention there are unintended consequences.

Always have backup options or don't run mission critical systems solely in an environment that can be attacked via DoS.

Great question.

Improve this answer
0

Costs of a DoS can be substantial.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.