How do firewalls in Linux differ from the ones used in Windows or other systems?
Are network-based firewalls more vulnerable?
Turnbull: This lack of a host firewall poses some risks as it assumes that:
a. Your firewall is unbreakable;
b. Your attacker is not already inside your network.
The first risk is probably best expressed as a failure to secure your environment using the principle of defense in depth. A defense-in-depth security model requires that you not rely on a single layer or mechanism to secure your environment from attack. Instead you deploy security at each potential "control" point in your environment. In the case of firewalls, this means controlling the traffic as it enters your network and then again before it enters your host.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The second risk is more obvious. A large percentage of attacks come from internal sources. Internal sources may have inside knowledge that provides them significant advantages over an external attacker. Assuming that placing a firewall at the perimeter of your network will protect your hosts from attack ignores this potential threat.
So, are Linux firewalls safer?
Turnbull: In the Linux world, most distributions come with some form of host firewall enabled by default. For example, as part of the Red Hat installation process, the iptables firewall is configured and enabled. This ensures that your hosts will have some form of protection in the event that your perimeter firewall is compromised or fails, or if the attacker that is targeting the host is already inside your network.
Microsoft's introduction of the software-based Windows Firewall suggests that companies are slowly becoming aware of a need to firewall individual hosts. This awareness has mainly been limited to desktop or laptop hosts at this stage, but going forward I would suggest that more and more Windows server hosts will have host firewalls installed.
Are there any firewall "gotchas" to look out for?
Turnbull: Probably the biggest "gotcha" with host firewalls is outgoing traffic. Too many people assume that simply allowing all outgoing traffic because they have restricted the incoming traffic is an acceptable security model. This kind of security model is one of the reasons worms, viruses and botnets propagate so easily. Once running on a system, nothing stops them from making as many external connections as they like and attempting to compromise or infect other hosts. You should be able to identify the vast majority of the incoming and outgoing traffic flow alike that your server requires -- this is easier than you think it is. As with incoming traffic, only let the outgoing traffic you absolutely need out of the system.
Another "gotcha" is testing. Take the time to learn how to use tools like tcpdump and ethereal to test your firewall rules. A minor mistake in a firewall rule can sometimes be very hard to trace and the easiest way to troubleshoot is to watch the traffic as it enters and leaves your system.
Additionally, if you are configuring firewalls remotely you should consider that a poorly defined rule could disconnect you from the host without any way for you to connect again (for example, changing the default policy to "Deny" or installing a rule restricting ssh). This is particularly annoying if you are in a different country from the host being configured. I'd recommend you write a simple test script for testing new rules. It should implement the new rule or rules for a set period (most people use the "sleep" command) and then stops iptables or reverts back to an older ruleset in case you have locked yourself out of the host. When you are satisfied that your rule works, you can implement it for real and add it to your permanent firewall configuration.
Should different criteria be used for VPN versus remote traffic?
Turnbull: A VPN tunnel merely provides an encrypted tunnel between two network segments. It does not ensure that the packets flowing through that tunnel are not malicious. Thus if you are connecting to a remote network, especially one where you do not have control of the security of that network, then you should treat all traffic from that network as untrusted. Additionally an attacker who has access to a remote network connected to your network with a VPN tunnel has the potential to use that tunnel to penetrate your network. I'd recommend treating VPN and remote traffic with equal consideration when assessing any firewall rules.
In addition to securing outsourced services for the Commonwealth Bank of Australia, James Turnbull is the author of Hardening Linux and resident security expert on SearchEnterpriseLinux.com.