Is a secure, firewall-less network possible? Perhaps, but why would you?

SC Magazine UK had an interesting article by Dan Raywood. Raywood interviews Kevin Dowd of CNS Networks as he sets up a network that doesn’t use any network firewalls. The premise is that in light of the recent Night Dragon attacks as detailed by McAfee has the time of the perimeter firewall finally passed.

Dowd goes through a lengthy explanation that a firewall is not a silver bullet. That keeping network topography as simple as possible is key to making security more practical. Cutting services that are masked by firewalls but unnecessary is another suggestion. To sum it up Dowd recommends:

If you are going to deploy servers, laptops, desktops or any networked equipment the following rules are the simplest way to stay secure:

  • Work out the services you actually need
  • Work out who will need to access those services and create restricted access
  • Disable or remove everything else
  • Review the network regularly

Dowd and Raywood end the article saying:

We therefore believe that businesses should think about effective implementation of security controls to protect their networks and focus on proper internal security, from employee passwords to ensuring that each application and system is properly hardened. Done properly this could, with specific networks, mean that you could remove the need for a firewall completely.

So let’s start with what we agree with. A firewall is not a silver or magic bullet. There are no silver or magic bullets in security. If you think there are, you probably also believe a large Bunny is going to hide some colored eggs at your house this month.

We also agree with KISS – keep it simple stupid.  Adding complexity makes your network … well, more complex. However, on this one you have to realize that sometimes complexity can’t be avoided.

Overall though, my real problem with Dowd and Raywood’s article is just because a firewall isn’t perfect doesn’t mean you throw the baby out with the bath water. I am not aware of anyone saying that by using a firewall you don’t have to use other security technologies. Also using a firewall does not give you an excuse to leave your common sense at the perimeter. In general, I absolutely do not disagree with the premise that an over reliance on firewalls is foolish and would severely put the network at risk.  But using them as a core and central device to limit risk is an appropriate implementation.

Specifically though I have a few more comments on this experiment that Dowd and team ran. They tested the theory by running devices connected directly to the Internet.  In the experiment, they limited what services were running to only those necessary and only to known and trusted hosts.  This is very good practice.  However, in even a moderate size network, this implementation would contradict one of the primary concerns which is complexity.

Consider the scenario where a DMZ is established to permit access to public servers.  It is not possible to limit the services to only the publicly available services as it is necessary to monitor and manage the servers.  So, management services are enabled such as SSH, SNMP, backup services, etc.  Each service increases the attack surface.  Anderson (one of the team leaders in the article) addresses this by using native host firewalls to limit access to services from only known hosts.  Whether he is referring to actual host firewalls (such as iptables) or application specific configuration parameters (such as Apache access control) is unclear, but he is referring to access control filtering at the host level.  So, to effectively control access, every host must be individually configured to define access.  While it may seem an easy solution to standardize configurations as a solution to this problem, it does not address the reality of how these devices are often used.  Different groups of users require different access to different servers.  A traditional network firewall is better suited to address these problems.  Grouping similar devices together into the same rules allows for convenient and easier to manage access rule definitions.  Unique access can be handled as appropriate.

Another particularly interesting fact about this article, is that Anderson is not recommending a firewall-less network.  In fact, Anderson is instead recommending a firewall for every host in the network.  This unfortunately is too complex for most environments beyond the most simple of networks.  And, it reinforces the basic premise that firewalls should be deployed as an effective tool to limit risk to an organization.

In conclusion, though we always welcome discussion around appropriate use and management of firewalls and innovative ways to secure the network, just because a particular attack was successful is not a reason to take up the “throw the firewalls out” chant.


About Jody Brazil

As Founder and CEO of FireMon, Jody Brazil is a seasoned entrepreneur with more than two decades of executive management experience and deep domain expertise in all aspects of networking, including network security design, network security assessment, and security product implementation. Before joining FireMon in 2004, Brazil spent eight years at FishNet Security, serving as Chief Technology Officer, where he was responsible for providing direction for solutions to their customers. Previously, he was president and founder of Beta Technologies, a Network Services and Internet Application Development company. A few of Brazil’s major accomplishments include his implementation of the first load balanced deployment of Check Point firewall software in 1997. A year later he engineered the security solution that allowed, for the first time, the transfer of criminal history data over the Internet as approved by the FBI. Brazil then released the first ever graphical firewall policy change view in 2001 and the first ever firewall rule usage analysis application in 2004.

6 thoughts on “Is a secure, firewall-less network possible? Perhaps, but why would you?

  1. John

    The article does not talk about a firewall on each host, in fact there are no iptables rules on any of the hosts in question. SSH is open to the world, albeit on a nonstandard port to stop my logs filling with brute force attempts and all the other open services are intentionally open.

    Adding a firewall would have provided no benefit since it would just allow access to the services which are already open, but considerable additional costs. The network in question consists of 2 colocated servers on gigabit ethernet, adding a third box as a firewall would result in 50% higher colo charges not considering the cost of a firewall powerful enough to handle a gigabit link.

  2. John

    The key point is, if you don’t need to offer a service then remove it… Don’t be lazy and keep it running while hiding it behind a firewall. That’s a nasty kludge that could fail at any moment.

  3. Andrew Yeomans

    If you want the ability to migrate your servers to an IaaS cloud provider, then you will have to do this work anyway. It forces you to invest in the management systems to rapidly set configurations – but once you have done that, why settle for anything less secure?

    If you are in a simple organisation with many servers or desktops in one place behind a single Internet connection, then firewalls give you an additional single point of control. Most large organisations I know have many mobile workers, also third-party suppliers, needing access from all round the world. Hence the need for moving the protection more locally to the systems.

    You may still keep some firewalls- or maybe their function simplifies to router ACLs instead? See for more information.

  4. jody.brazil Post author

    I don’t disagree with the comments that unneeded services should be removed. This is a similar concept to a good firewall policy design of a positive security model where only necessary services should be exposed to those who need access. Front end services open to the world and properly configured and maintained will benefit very little from a traditional layer 3 firewall, so there is limited value to putting a firewall in front of them. However, what about the database server, the management systems and other protected systems that don’t need to offer ubiquitous access? Just as unneeded services should be removed from a server, systems that don’t need to be made available to the world should be protected. And firewalls are a good way to accomplish this.

  5. Pedro

    Public/Frontend servers have an attack surface. If it’s large or small depends on service needs and whether it’s more than what is strictly required or not is dependent on good implementation.
    Should you remove perimeter protections because they are not a magic solution for all your security needs? That would be a bit silly. You could apply the same principle to any of the security measures you have in place when looked at individually. (That is unless you have found a perfect security feature that is all you need to protect your network).
    You can use social engineering to get past perimeter defenses? So what? You can use social engineering to get past just about any defense you have in place.
    Let’s bring down the castle walls because they can be overcome using a tunnel and concentrate on using thicker Armour for our individual soldiers.
    Not very smart.
    Security is holistic. Overly simplified visions have huge risks involved.
    Rely too heavily on ANY of your defense measures and you are exposing yourself to catastrophic effects and no possibility to establish defense responses when it is overcome. And it WILL be overcome.

  6. Roland Dobbins

    Stateful firewalls make sense in front of client access networks, where unsolicited traffic is generally considered undesirable.

    Stateful firewalls make no sense in front of servers, where every connection is unsolicited, and therefore there is no state to inspect. The stateful firewall actually harms the overall organizational security posture in this case, by instantiating unecessary state in the network, which is a major DDoS vector (it’s quite easy for botnets to take advantage of this stateful DDoS chokepoint by programmatic generation of well-formed traffic which will pass all the firewall rules, but which will ‘crowd out’ legitimate traffic).




    for more context & discussion.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>