Arbor security expert: Firewalls ineffective on cloud servers
- 01 September, 2009 17:35
- Comments 2
Putting firewalls in front of servers to mitigate threat is the number one security mistake cloud computing providers commit, according to Arbor Networks’ solutions architect for Asia-Pacific, Roland Dobbins.
He is visiting Australia as a keynote speaker at the Australian Network Operators Group 03 (AusNOG-03) summit.
Drawing on the July 4 distributed denial of service (DDoS) attacks on the Republic of Korea and US, Dobbins said old habits died hard and many organisations were ill-equipped to fend off the assaults despite previous occurrences.
“People are designing and implementing systems that are brittle and do not scale well and are not defensible,” he said. “We learnt that DDoS attacks were very run-of-the-mill but because organisations are often unprepared, even small unsophisticated attacks can take them down.”
While Australia largely avoided the July 4 incident, Dobbins said the country’s situation was very much like the rest of the world.
Internet security shortcomings are a global trend and Dobbins flagged lack of preparation as common practice among cloud providers. But the biggest blunder was an over-reliance on firewalls.
Companies deploy firewalls under the impression that they are the panacea for all security dangers. This was wrong, according to Dobbins, because firewalls were stateful inspection devices which only allow packets that have connected with an external host to go through.
“By definition, every connection that comes into a Web server, a DNS or a mail server is an unsolicited connection,” he said. “By placing that firewall in front of a server serves no purpose from a security standpoint. Secondly, it makes things worse because even the biggest firewall has finite amounts of memory used for state table space so attackers can craft traffic that will pass that rule and crowd out legitimate user traffic.”
Dobbins was concerned about the lack of talk about DDoS in cloud computing discussions despite him labelling it “the cloud model killer”. With the cloud model predicated upon applications and data being hosted in a datacentre and remotely accessed by users, a successful DDoS attack on a cloud provider can cause severe collateral damage, he said.
“Cloud computing has the potential to raise the bar on security that is only if providers do the things they need to do,” Dobbins said.
He recommends a six-phase methodology for dealing with all types of security incidents:
1. Preparation: The single most important step to allow the execution of the other five phases. Cloud providers need to design and implement the architecture of its cloud services in a way that is scalable in the face of an attack and to ensure visibility in their network traffic and application behaviour so to exert total control.
2. Detection and identification: This is being able to understand an event is taking place and having visible network traffic is the key to this step.
3. Classification: Once an event is detected, the next stage is to classify the hazard and understand what type of threat is this particular event to the application services and infrastructure.
4. Trace back: Again, traffic visibility is vital the moment it ingresses a network. From peers, upstream, downstream and from users, providers can find out where the breach is happening.
5. Reaction: Take appropriate action to mitigate threat. Companies that are unprepared are prone to take a stab in the dark and can make things worse.
6. Post-mortem: After the attack, sit down to discuss how the attack was handled. Gather feedback and take it back to the preparation phase.
Come socialise with us! Facebook | LinkedIn
- Bookmark this page
- Share this article
- Got more on this story? Email ARN
- Follow ARN on twitter
- Premier Media Group Fast Study
- In Search of the Long-Term Archiving Solution —Tape Continues to Be a Major Player
- Red Light In the Control Centre Saves Hours of Chaos
- Spectra Logic and Australian National University Success Story - March 2012
- Market Potential-Strategy Guide to the Active Archive Market
-
Facebook scammers host Trojan horse extensions on the Chrome Web Store
-
Webroot: Growth in security
-
Sice quits Acronis, joins Staples
-
Sice quits Acronis, joins Staples
-
Conroy to receive secret filter forum report
Get exclusive access to ARN's news, research and invitation only events. 
Comments
Ken Baker
DDo
The article by Arbor security expert 1 Sep 09 is obviously self-serving for Arbor who'se main product is based on traffic observation and management. Unfortunately Arbor's product is almost useless at providing any accurate or immediate mitigation of DDoS attacks. Such devices based on the old-generation signature based methodologies (fingerprints in Arbor's marketing jargon) can't manage large attacks, fail under sophisticated attacks and can themselves be attack targets. So is that why the Arbor expert does not recommend installing a DDoS defence appliance which is the only obvious and real way to mitigate DDoS attacks?
Roland Dobbins
Modern DDoS mitigation systems.
Mr. Baker,
Thanks for your comments - you raise some interesting points which definitely should be addressed.
Arbor's Peakflow SP anomaly-detection system is deployed on the largest Internet Service Provider (ISP) networks in the world, and is used to detect, classify, and traceback DDoS attacks in real-time on those networks.
Our anomaly-detection technology isn't at all dependent upon fingerprints or signature-type technologies; we can detect, classify, and traceback minute-0 attacks which have never been seen before, much less day-0 attacks. Our fingerprint-sharing program is simply a way for Arbor to share even more detailed classification information with our customers, but isn't necessary for the operation of the system in production environments.
The second component of our solution is the Arbor Threat Management System (TMS), which is an intelligent DDoS mitigation system (IDMS) of the type you describe. Peakflow SP detects, classifies, and traces back the attack traffic, and then activates the TMS in order to dynamically divert traffic directed at the target system into the TMS itself (TMSes can be clustered in parallel; our top-end unit supports 10gb/sec of traffic, so cleaning centers can be constructed which can handle 160gb/sec or greater of mitigation capacity, depending upon the load-leveling capabilities of the routing/switching infrastructure within the cleaning center). The TMS analyzes the traffic, including sophisticated antispoofing and layer-7 protocol analysis, drops the bad traffic, and then re-injects the good traffic to the servers, thereby protecting the servers from the effects of the DDoS.
Peakflow SP can also serve as the trigger for source-based remotely-triggered blackholing (S/RTBH) to quickly drop attack traffic at the edges of the network, making use of the existing edge router infrastructure to drop traffic based upon the layer-3 source or destination IP address. This can be useful for simple packet-flooding attacks in which the more sophisticated antispoofing and mitigation capabilities of the TMS aren't needed.
Finally, our recommendation for moving servers from firewalls isn't intended to be self-serving at all; during my time at a major manufacturer of Internet infrastructure, including firewalls, I made the same recommendation. Any major Internet site you visit do not in fact have firewalls placed in front of their servers due to the fact that stateful inspection in front of the servers doesn't make sense, as described in the article above, and because the firewalls themselves become DDoS chokepoints. Our Arbor TMS IDMS can protect firewalls and everything behind them, so we've no pecuniary interest in recommending this well-known Best Current Practice (BCP); we simply believe than an educated customer is an empowered customer, and a strong, resilient architecture is in everyone's interests.
During the recent RoK/USA DDoS attacks, for example, we saw Web application firewalls (WAFs) placed in front of servers fail very quickly, under traffic loads far smaller than the servers themselves were capable of withstanding. Placing firewalls in front of servers simply makes no sense; they have their place in separating LAN access networks from the Internet, but are iatrogenic in Internet Data Center (IDC) environments.
Again, thank you for your comments, and I hope the above information provides a useful clarification. To learn more about Arbor's DDoS detection and mitigation capabilities, please feel free to visit the Arbor Networks <a href="http://www.arbornetworks.com">web site</a>.
Roland Dobbins, Solutions Architect
Arbor Networks
Post new comment