Internet cable cut conspiracy

Michael_Knight 0 Tallied Votes 414 Views Share

Rumors and speculation about why five undersea cables to the Middle East have been severed — and what it means for IT security.

Since Jan. 30, 2008, there has been a troubling pattern of underwater anarchy. At first, it was reported that two, then three, then five undersea fiber-optic cables in key bottlenecks global undersea Internet connection — off the coast of Egypt and in the Persian Gulf — had been severed. Initially, reports claimed that the two Egyptian cuts were due to a ship’s dragging anchor during inclement weather — an explanation that has since been discounted. In the meantime, three more cables appear to have been severed, (for a total of five), all with direct connections to the Middle East, India and Southeast Asia.

With no official account that would sufficiently explain why so many cable disruptions could occur in such a short period of time, rumors and speculation have swirled across blogs, offering explanations from the tongue-in-cheek to the telltale signs of imminent warfare.
What Happened, and When?

On Jan. 30 — five miles north of Alexandria, Egypt and deep in the Mediterranean Sea — two cables 400 yards apart were cut. One of the cables is owned by Indian company FLAG Telecom, a subsidiary of Reliance Communications Ltd.; the other, SEA-ME-WE 4, is owned by a consortium of 16 telecoms and connects 16 cities between Singapore and Marseille, France.

With the cuts, Egypt lost 70 percent of its connectivity, and India lost more than 50 percent of its outbound traffic, “messing up the country’s outsourcing industry,” according to The Economist. Initially, a spokesperson for FLAG Telecom told the The Register that the cut had been caused by a ship's anchor, but the Egypti's telecommunications industry told The Associated Press that there were no ships in the area at the time.

When a third cut occurred on another FLAG Telecom line on Feb. 1 — on the other side of the Arabian Peninsula, in the waters near Dubai — many online observers detected a pattern that some considered malicious. Some bloggers and commenters suggested that the cable cuts represented a precursor to an American invasion of Iran, fueled by incorrect and unfounded rumors that the cuts had left Iran in the dark (proof to the contrary can be found at Renesys and Google's Iranian search engine). Other theories (some of which are absurd) include scuba-diving jihadis attempting to disrupt American NSA (National Security Agency) surveillance; an attempt to delay the opening of the Iranian oil markets; seals (the mammals, not the elite commandos) trained by the U.S. Navy; and the monster from "Cloverfield."

Cover-Up?

Sceptics, meanwhile, have pointed to more mundane culprits such as undersea earthquakes or seafloor mudslides. The anchor explanation from the Alexandria, Egypt cuts seemed like a cover story to some observers, especially after Egyptian officials dismissed them. So many who saw a devious plan at work ignored the fact that the third cut had, in fact, been caused by a shipping incident, according to FLAG Telecom officials, after they discovered a 5-to-6-ton anchor near the scene of the disruption.

On Feb. 4, the Interational Herald Tribune reported that four cables had been cut. The next day, the Khaleej Times reported from Dubai that five cables run by FLAG Telecom and SEA-ME-WE 4 had been severed, affecting 1.7 million Internet users in the United Arab Emirates, in addition to at “least 60 million users in India, 12 million in Pakistan, six million in Egypt and 4.7 million in Saudi Arabia.” The fifth cable outage was due to power issues, but it was swept up into the perceived conspiracy web out of coincidence and convenience.

While the causes of three of the five cuts remain unknown, repair crews are en route. Officials from FLAG Telecom and SEA-ME-WE 4 estimate that the cables will be fully functional within three days, according to Reuters.

The comment storm across the blogosphere following these events has proved largely unreliable but has increased awareness of several important facts: The USS Jimmy Carter, a Seawolf-class nuclear-powered submarine, can spy on the Internet underwater; the Pentagon considers the Internet “an enemy weapons system”; and, President George W. Bush signed a secret order to expand the NSA’s network-monitoring programs just four days before the first two fibre-optic cables were mysteriously disrupted.

Dani AI

Generated

raised the core questions that mattered then (and still matter today): were the 2008 cuts a coordinated attack, and what should network operators learn from them? Public technical workups and industry data show that simultaneous‑looking failures are far more often explained by ordinary maritime and geological causes than by covert sabotage. Industry summaries and operator FAQs record that the majority of subsea faults come from anchors and fishing activity (not sharks or secret submarines), and many incidents are simply amplified when a region depends on only a few physical corridors. (www2.telegeography.com)

How repairs actually happen matters when deciding how long an outage will last. Repair teams use specialised cable ships, ROVs or grapnels to locate and lift ends, then splice in replacement cable on deck; depth, weather and ship availability drive a timeline measured in days to weeks. For the 2008 Mediterranean/Gulf incidents the control‑plane analyses and operator logs show repairs completed over the following one to two weeks rather than instant fixes. Those operational details explain why early, sensational attribution claims are rarely supported by forensic evidence alone. (scribd.com)

Practical, short checklist for network teams (apply immediately during a suspected subsea failure):

  • Confirm the symptom: run traceroute / mtr to affected prefixes and look for path changes or long detours.
  • Check control‑plane: consult public collectors / looking‑glass data (RIPE RIS, RouteViews) to see withdrawals/announcements and AS‑paths.
  • Engage transit/carrier NOC and your CDN/cloud account teams; they can often re‑balance capacity or open emergency circuits.
    Example quick commands:
    traceroute -n <target>
    mtr -r -c 100 <target>
    # then consult RIPE/RouteViews looking glasses for control-plane views

    Use multi‑homing, geographically diverse transit, CDN/edge caching and a pre‑approved emergency bandwidth playbook to reduce exposure; practice these failovers in advance. (ripe.net)

Bottom line: treat dramatic headlines with healthy skepticism, focus on documented telemetry, and build for physical diversity (not just logical redundancy). Historical analyses from 2008 led operators to the same conclusion: reduce single‑corridor dependencies, keep ship/repair timelines in mind, and test runbooks so an anchor strike — however mundane — won’t become a business outage. (www2.telegeography.com)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.