Previous month:
September 2013
Next month:
November 2013

October 2013

Eliminate Firewalls?

Director Lt. General Ronnie Hawkins Jr., USAF, announced in a 26 June 2013 interview that the US Defense Information Systems Agency (DISA) was building a security architecture that would ultimately eliminate firewalls. "In the past, we’ve all been about protecting our networks—firewall here, firewall there, firewall within a service, firewall within an organization, firewalls within DISA," Hawkins declared. "We’ve got to remove those and go to protecting the data."

LouiseCohen
Photo by Louise Cohen

Despite that Director Hawkins carefully explained that this represented a shift in emphasis from protecting networks to protecting data, speculation that firewalls would disappear from DISA networks, or generally, any network, resurrected a debate that's been raging for nearly as long as firewalls have existed. The party lines of this debate generally anchor in these themes:

Parties who favor abandoning firewalls argue that firewalls are no more effective today than the line of forts along the Maginot Line in 1940; they are incapable of adapting to the changes in user mobility, the attack landscape, attacker profile, and the levels of sophistication of recent attacks and thus easily circumvented.

Parties opposed to abandoning firewalls say that abandoning any line of defense weakens overall defense, and that perimeter defenses as well as network compartmentalization are essential in any containment strategy.

Three problems arise each time folks argue to eliminate firewalls:

There is a tendency to think of a firewall as a hardware device or software rather than to think of the functions that the devices or software perform. These functions include address translation, network traffic inspection, routing, application proxy, content inspection, traffic or content filtering (blocking or removal), and logging. The functions collectively attempt to enforce security policies built around the traditional "AAA" model (authentication, authorization, and auditing).

 There is a tendency to discount the functions of firewalls that are effective. Firewall systems remain an effective way to protect networks where data are hosted against attacks that threaten data availability (e.g., traffic- or system-crippling DoS attacks) and to control costs of resources. On the Firewall Wizards mail list [fw-wiz], Tim Harris of FBN Services posts: 

    The largest function that firewalls perform today is a coarse filtering of traffic. They eliminate the obvious bad traffic as well as traffic that is misdirected… That reduces my cost because I need less bandwidth and less robust equipment. It also means I save on CPU cycles because that traffic is checked once at the perimeter rather than forcing every device to inspect it. 

    Coarse filtering is effective. Firewall systems are effective coarse filters. Given how many security systems are not effective, why eliminate one from your arsenal that is? Simply put, don't eliminate firewall systems, but use them where they can be most effective. As Greg Young posted in [fw-wiz], "a more complex Internet edge doesn't mean your data center doesn't need protecting from the outside and the WAN."

Laarly, in far too many cases there's nothing but a firewall system between adversary and asset. We can argue that firewall systems were the worst invention ever because they allowed software development to remain lax with regard to secure programming practices and lax rather than secure host configuration. It's also hard to argue that firewall systems aren't the panacea they are commonly perceived to be. But until we can evolve and implement security architectures to truly protect data at rest whether in a data center, cloud, or client device (irrespective of who owns the device), it's impractical to leave data unprotected.

Don't abandon Firewalls: Complement or Collapse Functionality

DISA and similarly motivated organizations are not likely to abandon "firewall" functionality if they truly want to protect data. This functionality must be effectively collapsed close to data at rest (i.e., at the datacenters or clouds where the data are hosted), on the user device (in the forms of cryptography and data compartmentalization), and in policy (by adoption of permission models that adhere to the principle of least privilege).

Security architectures that seek to "protect data not networks" are in truth shifting security focus onto what attackers target: information. DISA and others are considering cloud architectures because the cloud (or datacenter) models separate application and data hosting from (client, user) network access. This will, over time, allow agencies or organizations to eliminate firewall systems "outside" the cloud or datacenter, and rely more on role-based access controls and other centralized security measures.

There's nothing magical or revolutionary in this strategy, and despite the illusion of controversy, it's a sound one.

This article originally appeared at The Tranformed Data Center 23 July 2013.

Spamhaus puts foot down HARD on Chinanet-GD

Cnet1

Anti-spam and block listing not-for-profit Spamhaus has added an entire /12 block of IP addresses allocated to Chinanet Guongdong Province Network (Chinanet-GD) for "Spammer, malware and botnet hosting for months. Ignoring multiple notifications sent by Spamhaus and 3rd parties". 

Drill down at the Spamhaus Advisory and you'll find 92 SBL Listings dating back to March 2010.

The rap sheet suggests this allocation is a proverbial wretched hive of scum and villainy: I counted 17 different abuses with multiple offenses for each abuse: 

ApnicComment/Forum Spam
  • Spammer hosting
  • Malware DNS server
  • Spam source
  • Snowshoe spam range
  • Botnet spammer hosting
  • Malware botnet controller
  • Phish source
  • Open relay emitting spam
  • Spammer + botnet hosting
  • Malware distribution
  • Yoyo DDoS botnet controller
  • Known repeat domain fraud spammers
  • Trojan dropper
  • Hacked server spamming
  • Worm.Dorkbot botnet controller
  • Phish redirector

This will be an interesting cleanup for Chinanet-GD. Spamhaus requires that all unresolved SBL records on behalf of CHINANET-GD must be resolved before the escalation will be removed.

Oh, and if you find evidence of spam arriving from this block in the future contact the abuse email abuse_gdnoc@189.cn

And Spamhaus.