Following an agreement early last year, Twitter's Internet service was taken over by NTT America, a unit of the Japanese telecommunications giant Nippon Telegraph and Telephone Corp. The switch seemed to improve the site's frequently faulty service, and the rate of outages and slowness has decreased considerably. Twitter has weathered major news events such as the 2008 presidential election, this year's election and its aftermath in Iran, and the death in June of Michael Jackson.
The attack yesterday was one of the few major outages the sites has experienced recently. (David Colker has some added details about the attack here.)
Kazuhiro Gomi, NTT's chief operating officer and chief technology officer, agreed to an interview Thursday night as Twitter was still under siege. He discussed the process that NTT uses to protect Twitter, the intensity of the attack and why Twitter was vulnerable to a DDOS attack.
At approximately 9:30 a.m. Eastern Time the attack started coming in. Shortly after that, the Twitter servers became unreachable. At that time we realized it was a DDOS attack. Within the NTT network we have a mechanism to drop the malicious packets of the DDOS. So we correctly tuned it and then turned it on at around 11 o'clock. So that mechanism turned on and the Twitter page became accessible at that time. For the exact time, you'd have to refer back to Twitter's official comment, but by my understanding it was about an hour and a half or two hours that Twitter was inaccessible.
Are there some residual performance issues?
The current situation [as of Thursday evening] is that all the traffic going to Twitter needs to be scrubbed -- basically, filtered -- which was not the case before the incident happened. And another factor is that the attack is still going on -- therefore the traffic needs to be scrubbed continually. That process slows things down a little bit.
So you'll keep scrubbing the packets until the attack stops?
How would you characterize the severity of the attack?
That's really hard to quantify, but in my past experience -- that the Twitter page was unreachable is definitely one of the worst-case scenarios. From that perspective, it was pretty bad.
Do you have a sense of how and whether you'd be able to track it back to the source?
To be quite honest, that is very difficult. The nature of a DDOS attack is that it's coming from all over the place, so it's really difficult to identify the source.
In talking to some security analysts, it was suggested that in
business-grade applications and online commerce, there's a feature
that would automatically protect you from DDOS attacks. Why didn't
Twitter have that?
That's purely Twitter's decision and I need to observe their decisions. We are their network provider and we have a mechanism that I explained earlier to protect our customers from DDOS, like we did today. So in one sense they are guarded by using NTT's network -- it's fair to say that. But there's definitely different methods. Like in the financial world, it may be that a quicker response is required -- and [in the financial world] they might have ... a more strict contract to make it happen.
Is it correct to say that the system that defends against DDOS is not something that's always "on"?
It's pretty much a kicked-on, retroactive system. For this case, we see that the customer is under attack, and we kick it in after the fact.
What can be the motivation of the attacks in these cases?
That varies. I think more recently there's some political parties unhappy with something and do a DDOS attacks to kill servers -- that happened at many U.S. government sites and so forth. I'm not in the position to determine that this is another case of such, but that's one likely scenario. But it's too difficult to determine what that was.
-- David Sarno
Follow my variable-rate stream of tech and culture-related musings on Twitter: @dsarno