Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Estonian Cyberwar and Its Implications for U.S. National Security (2007) (iar-gwu.org)
68 points by rfreytag on Sept 30, 2016 | hide | past | favorite | 12 comments


TL;DR: Estonia had a heavy reliance on internet infrastructure but wasn't big enough to take the gut punch of a large-scale, sustained, possibly state-sponsored DDoS. To prevent a similar scenario, the US should broaden the legal authority of law enforcement and intelligence agencies and invest in R&D.

To be honest, I don't really follow this line of reasoning, and felt like this was basically two separate articles glued on top of each other (a nice summary of the Estonia situation, followed by an unrelated and therefore mostly ill-motivated set of policy proposals)

The author himself concedes that an Estonia-like scenario is highly unlikely in the US for the obvious reason -- we have a crap-load more bandwidth than Estonia and a lot of experience with large-scale DDoS attacks. Conversely, intrusions, not DDoS, are apparently the most damaging form of cyber-attack against the US government and US organizations. But the concrete policy recommendations (esp. regarding taking the gloves off of LE/intel agencies) are mostly motivated by DDoS, not intrusions. And the policy recommendations that do address intrusions contain a lot of IMO magical thinking -- throwing R&D money at military contractors, for instance.


Speaking of gluing separate issues on top of each other:

If the US government had the same kinds of online services they have in Estonia, could those services withstand the kind of DDoS attack recently used against krebsonsecurity?


Well, let's take one agency - the IRS. Could they take what happened to krebsonsecurity? Maybe, maybe not.

But then you have the Department of Agriculture, the State Department, and on and on. So: Could that scale of attack shut down one agency? Plausibly yes. Could it shut down the Federal government's internet presence? Almost certainly no.


There might be a potential issue regarding architecture. Government systems are typically dependant on each other within the same agency. Taking down one server le service might have a domino effect on the rest. Lots of these systems are old and have merely been updated with web guis.


It's all just evil hacking to a large group of people which makes it very easy to link the two.


It does all fall under the rubric of "governments aren't yet as good at computer and network security as they need to be."


Well, if a government wants to place essential services on the internet (what is great, by the way), it must get enough redundancy to ensure the internet keeps working when something bad happens (what is a great thing to do by itself, by the way).

People assume they can just run essential services over untrusted infrastructure and "everything will be ok!" "look how much we are saving!". That's stupid, and this level of stupidity coming from any high administrator is unacceptable.

But, anyway, I can not believe a country can not live with its bureaucratic engine stopped for a couple of weeks. Yes, some important things will be late, but nothing that urgent should be demanding bureaucratic decisions, because those aren't really that fast. The physical protests must be much more worrying.

Just as a last note, it's borderline absurd that ISPs accept that their users forge other ISPs addresses. We badly need some international regulation on this matter - but instead governments are busy negotiating TPP and similar treaties.


> Just as a last note, it's borderline absurd that ISPs accept that their users forge other ISPs addresses. We badly need some international regulation on this matter - but instead governments are busy negotiating TPP and similar treaties.

They can also adopt BCP38 -- maybe quite a few could be persuaded to do so via lobbying from customers or other ISPs.

http://www.bcp38.info/index.php/Main_Page

(anyone want to contribute text to fill in the information for network providers?)


The "Estonian Cyberwar" is also described in Fred Kaplan's "Dark Territory: The Secret History of Cyber War" [1] as one of the defining moments of the coming of age of international cyber offense and defense, and as one of the turning points of the power grab by the NSA on the cyber security issues.

Interesting read. I find the way the book is structured quite unwelcoming and hard to digest (too many timeline jumps), but it's packed with interesting information.

[1] https://www.amazon.com/Dark-Territory-Secret-History-Cyber/d...


This sets a nice historical perspective on evolution of DDoS attacks and Internet in general.

>The cyberattacks that had begun on April 26 averaged about 1,000 packets on the first day. By the second day, the attack rates averaged 2,000 packets per hour, a rate that increased exponentially throughout the three weeks of attacks. May 9 marked the heaviest day of cyberattacks, averaging a rate of over 4 million incoming packets of information per second at hundreds of targeted websites.

2007: 1000 packets per hour is a "DDoS attack".

2016: New DDoS Attack record 1.5+ Tbps


> 2007: 1000 packets per hour is a "DDoS attack".

Where do you get this from? If we're talking brute-force DDoS (overloading packet processing or link throughput), 1000 packets/hr was certainly not a DDoS attack in 2007. In fact, you'd get much more than 1000 packets/hr on any machine connected to the internet even without doing anything.

If you're talking about some smarter kind of DDoS (slowloris-style), then you can do a lot of damage with few packets. But that's a different attack and if you found similar flaws today you could exploit them with a similarly small number of packets.

If you're referring to the timeline in your earlier quote, I don't think they mean that the initial load was intended to knock anything offline. It's just a classic ramp-up often used in DDoS attacks, because it lets you determine the targets breaking point exactly before you go all in.


>Where do you get this from?

I cited the source.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: