Virtualizing your Linux Firewall

From WBITT's Cooker!

Revision as of 17:32, 15 March 2011 by Kamran (Talk | contribs)
Jump to: navigation, search

Alternate Titles: "Virtual Firewall Systems" Affordable and Robust Linux Firewalls

Author: Muhammad Kamran Azeem [CISSP, RHCE, OCP (DBA), CCNA] (http://wbitt.com , http://techsnail.com)

E-mail: kamran at wbitt dot com

Created: 08 March 2011

Updated: (Please see the footer area of this document for this information.)

Category: Virtualization, Security (Firewalls)

License: Copyright (c) 2011 by Muhammad Kamran Azeem. Permission to copy, distribute (sell or giveaway) and translate, provided you retain the name of the original author.

Synopsis: This paper discusses the concept of running your Linux Firewall as a Virtual Machine.

Contents

Introduction

In today's IT world, almost all IT managers know what exactly it means for the business, when a firewall is down. When this alarm is raised, it is just like the fire alarm. All of a sudden there is immense panic, there are question marks on everyone's face, productivity is halted, and people rush to see, who reaches to the coffee machine first; except the IT staff. To the IT staff, it seems like hell has broken loose. The managers of all level, almost all at once, start yelling at the IT staff, to get the network back up as soon as possible. It is quite a scene!

For people using hardware based firewalls of prominent brands, like Cisco PIX, Juniper NetScreen, or SonicWall, etc, this can actually mean a lot of downtime. Especially in cases when the firewall device has actually got burnt because of some power surge. They would have to wait for a replacement unit to arrive. In case the firewall was cracked, by a cracker, it would again mean a lot of downtime, as the firewall device has to be re-configured, probably from a clean backup, if there was any!

Normally there is only one such device in an environment, because they are pretty expensive. And, as noted above, a burnt device, or any component of it, such as a WAN port, can seriously cripple your business to a complete halt.

Many people consider Cisco PIX as the Holy Grail of firewalls. Same is the general point of view about other hardware-based/proprietary firewalls, such as Juniper NetScreen, SonicWall, CheckPoint, NetGear, etc. There is nothing much you can do "different", with the so-called hardware/proprietary firewalls, compared to what you can do with Linux based firewalls. One of the popular strategy used by the sales people / vendors is to create Fear, Uncertainty and Doubt,(FUD), about low cost Linux firewalls, in the minds of customers. When they are successful in doing so, they (sales people) move to the next step, and convince their customers to purchase the ultra expensive firewall from brand X. The interesting point is, that even the IT managers at the customer side, do not resist in such purchases. Because, they "feel secure" by merely purchasing a branded product, and don't want to take any risk by saying "No". Once the brand X firewall product is acquired by the customer, it is placed on the network, without a well thought out configuration/plan. In a hurry to brag "I have configured the brand X firewall and placed it in production in 30 minutes", the IT staff, constantly under the influence of the brand X name/reputation, puts something on the network, which is, (a) not well configured, (b) no-body understands it well enough (c) is outrageously expensive, and (d) was not required in the first place. Most of the time it ends up like buying a rocket launcher to kill a fly.

In this paper we would discuss the possibility of using Linux based firewalls, running as both physical/hardware appliances; and as virtual machines, on a XEN / KVM host. We would also show, how this (firewall virtualization) can be achieved.

The Physical Firewall

The brand X hardware firewalls

We would use an example from real world to explain this point. i.e. It would be interesting for many to know that the processors used in Cisco PIX firewalls were Intel Celeron, Intel PIII, and AMD's Am5x86. The chipsets used on the mainboards of these firewalls were Intel 440BX and AMD's SC520 chip-sets. And the RAM ranged between 16 MB to 512 MB (to 1 GB). [Reference: http://en.wikipedia.org/wiki/Cisco_PIX#Description_of_hardware].

Also, if you are thinking of buying any of the Cisco PIX firewall, you should note that Cisco PIX firewalls have reached EOL (End Of Life). Models such as Cisco PIX 501 or Cisco PIX 515 are not produced any more. The new models, (so to speak), are now available in a blade form factor, (for blade enclosures), as "Security Modules". You can still purchase used devices for anywhere between $500 to $5000, depending on model, specifications, and of-course, the quality. The Cisco PIX firewall may been one of the best seller in the enterprise firewall areana, its ISO command line interface was never liked (and never fully understood) by the general (non-Cisco) IT staff.

The Linux Physical Firewall

Fundamentally, any hardware-based firewall is a collection of hardware and software components. A hardened Linux box, with enough resources, used "solely" in a firewall role, can confidently be termed as a hardware firewall; and it can compete with any branded firewall you can throw against it. Besides, it is the configuration, which makes a firewall strong; not it's brand.

A modern day PC is much more powerful than what is described above. A cut down version / minimal install of Linux OS of your choice, on a commodity off the self (COTS) PC, can essentially turn it into a firewall, more powerful than the Cisco PIX. Linux and its command line interface is very well understood by almost all Open Source enthusiasts. Plus, there is a lot of help out there on the Internet. Thus, using Linux as the OS for your firewall is an excellent choice. As you know, Linux OS is normally available free of cost. So the only direct costs are the hardware costs for such a firewall. The cost of a custom made (Linux) firewall device, range between $200-$900, depending on your requirements. Still it is much lower a price compared to $5000+ for a branded firewall. A Linux based hardware firewall can offer almost all services which any other type of firewall can offer. It is just the matter of adding the right modules and software pieces to it. For example, a basic Packet Filtering Linux Firewall can work as a Stateful Firewall, merely by adding a connection tracking kernel module, and some configuration. The following non-exhaustive list provides an insight into what all can be accomplished by using Linux OS and it's free tools.

  • Packet Filtering: IPTables
  • NAT: NAT module in IPTables
  • Stateful Filtering: Connection Tracking module in IPTables
  • Web Proxy/Caching Service: Squid, etc.
  • Web Content Filtering: SquidGuard, DansGuardian, etc.
  • Anti Virus: CLAMAV, etc.
  • Anti SPAM: Spamassassin, etc.
  • VPN: OpenVPN, OpenSWAN, etc.
  • Intrusion Detection Systems: Snort, etc.
  • Network Monitoring and Alerting: MRTG, MON, Nagios, ganglia, etc.
  • An SMTP relay: Sendmail, Postfix, etc.
  • .... and more.

You can have one "thick" Linux firewall, in your network, by having all of the security services on one physical machine, which is an advantage in it's own. (You will not experience virtualization overheads, explained later). There are many Open Source firewall projects, which are reliable and robust; and are being used in production networks all over the world. Shorewall, SmoothWall, Untangle, Endian, IPCop, CopFilter and pfSense are few excellent firewall solutions , usable in environments ranging from SOHO, to enterprise.

To give you an idea of the hardware, and related costs, consider a normal PC, with P4 or higher processor, 800 MHz or higher speed, 256 MB or more RAM, and 40 GB or more disk space, with at least 2 Network cards. A PC with such hardware specifications is an ideal candidate for a firewall device/appliance. 800 MHz processor is good enough to handle about 50 users. The more users you have, the more powerful processor you need, (along more RAM), because the primary function of any firewall (packet filtering), eats the most of the CPU. If you also need to provide VPN, you should consider a processor with speed in excess of 1.6 GHz. As noted above, the cost of such custom made (Linux) firewall device, range between $200-$900, depending on your requirements. Again, it is much lower a price compared to $5000+ for a branded firewall.

Note: While power is a concern for any equipment you are running, don't fall into the trap of using Atom processors, just for the reason that they consume low power. Atom processors do not have enough compute power to act as an efficient firewall for a larger network.

While this paper is about Virtualizing your firewalls, make no mistake in understanding that a physical/hardware firewall, will always outperform a virtual one. This is because there are no virtualization overheads, nor any infrastructure complexities. If you can afford the cost of extra hardware, the power consumption, and the configuration time, we recommend that you use a physical (Linux) firewall instead of setting up a virtual one. It is highly recommended to have redundancy of the equipment, to provide business continuity. Linux firewalls are very efficient and secure, (if configured correctly), economical, and affordable, compared to their branded counter parts. There is no reason, why you should not use one.

The Virtual Firewall

In this paper, we try to explain, how compartmentalized security model can be implemented, by running most of the services listed above as separate "thin" virtual machines, on a single physical server. And that for the sake of ensuring business continuity, a copy of all VMs can be kept on a second (in-expensive) physical machine. In case of hardware failure, the firewall and it's related components can be run from this second machine, without significant downtime.

Thus, instead of running one "thick" physical machine as firewall, we can run multiple "thin" virtual machines. Below are few of advantages and disadvantages of running your firewall as a VM.

Advantages

  • Compartmentalized Security: One VM can be setup to act as a firewall, while the other VM can run services like WebCache, DNS, etc. If a cracker gains access to the cache server, that is the only VM affected. Your main firewall will still continue to handle traffic.
  • No single point of failure: If one VM's disk is full, with logs, etc, it will be the only VM, which will fail, or will not respond. The other VM will keep functioning.
  • Service/VM Load Balancing: If the VM running the WebCache/content-filtering services is taking too much physical resources of the physical host, that VM can be moved to another physical machine on the network.
  • COTS/in-expensive hardware: This gives you the (financial) freedom to have multiple physical machines in stock. In case a hardware failure occurs, the second physical machine can be quickly setup to run these VMs and the services they offer.

Disadvantages

  • Virtualization overhead: Virtualization means, that there must be a Hypervisor (XEN: Domain-0), to host all virtual machines. The hypervisor itself consumes certain amount of resources, mainly RAM, and CPU. And if RAM is scarce, there is little left for VMs to run efficiently, on a system which is already low on physical resources.
  • Extra complexity: Virtualization introduces extra level of complexity in the infrastructure/network. The administrator has not only to take care of the physical machine and it's network connections, for example; he also has to take care of the VMs, the virtual networks inside the machine, and a keep an eye on the resource utilization.
  • Requirement of additional IPs: All virtual and physical network interfaces (of physical and virtual machines) need to have IPs assigned to them. Thus there is a requirement of additional IPs.


Note: If you do not plan to host many thin VMs on your physical host, or if you are low on hardware resources, you can simply let go of the idea of Virtualizing your firewall, and just go ahead with a physical (Linux based) firewall. One of the key principals of security is to keep your system "managed" and "manageable". The moment the complexity of any system becomes un-manageable, it develops vulnerabilities, which can later be exploited. Thus, simplicity must be a fundamental idea when designing any system; and firewalls are not an exception.

Designing a Virtual Firewall System

Scenario

While designing a Virtual Firewall System, and it's components, you should first make a list of tasks it will be performing for your network. In this document, we have the assumption, that you are placing such a firewall between Internet and your LAN users, to protect them from each other. Internet is reachable through a DSL router, which has a public IP. The LAN interface of this DSL router is connected to a switch, to which all of your users are connected to. The DSL router, is providing DHCP, DNS and NAT services to your users. We will also assume that the DSL Router has a built-in firewall, which no-one has bothered to configure for your setup, or has very limited firewall features. The users need to be protected (from the Internet), and also provided with some basic services, such as a cache server. The Internet needs to be protected from the LAN users, such as, any virus infected PC should not send floods of emails/spam through your DSL router, towards the internet. Thus a need to place a Linux firewall in between. First, here is how the setup looks like when there is no firewall placed on the network.

Figure 1: A typical set up without a firewall.


Here is what a non-virtualized "thick" solution looks like:

Figure 2: A typical set up. Physical firewall machine placed between Internet and LAN.

The Proposed Solution: Virtual Firewall System

We have used XEN as an example to create a Virtual Firewall System. The design is shown in the diagram below. You can also use KVM, if you want to.

Figure 3: A Virtual Firewall System. Two VMs inside the physical machine.

Larger version of this diagram is available at: http://cooker.techsnail.com/images/d/dd/Firewall-Virtualization-03.png

The diagram is explained as following:

  1. The physical/gateway/firewall machine shown in Figure 2, in the previous section, has been replaced by a large box.
  2. peth0 and peth1 are the physical network cards of the physical machine.
  3. pCPU = Physical CPU, pRAM = Physical RAM, and pDISK = Physical Disk
  4. The grey box inside the big white box is supposed to be Domain-0. In a perfect diagram, VM1 and VM2 should be drawn outside the grey box. You can still assume the grey box to be Domain-0 for ease of understanding. For better understanding, check the XEN network concepts explained in this article: [Reference: http://cooker.techsnail.com/index.php/Virtualization-XEN]
  5. xenbr0 is a software bridge which primarily connects peth0 and eth0 of Domain-0 to the bridge. peth0 is connected through a virtual uplink. Whereas eth0 is connected to the bridge on vif0.0 port. The xenbr0 software bridge also tells us that all machines connected to it are on the same network 192.168.0.0/24.
  6. xenbr1 is a software bridge which primarily connects peth1 and eth1 of Domain-0 to the bridge. peth1 is connected through a virtual uplink. Whereas eth1 is connected to the bridge on vif0.1 port. The xenbr0 software bridge also tells us that all machines connected to it are on the same network 192.168.1.0/24.
  7. VM1 is firewall and VM2 is webcache.
  8. Notice the change in IP assignment in Figure 3, compared to Figure 2. The IP used as GATEWAY by the LAN users, is now assigned to eth1 of VM1 (firewall), instead of peth1 (or eth1) of the physical host.
  9. VM1 runs in the firewall role. It has two interfaces, each connecting to a different bridge, (xenbr0 and xenbr1), and thus essentially becomes/acts-as a router. The eth0 interface of VM1 is connected to vif1.0 port on xenbr0. The eth1 interface of VM1 is connected to vif1.1 port on xenbr1. VM1 runs DHCPD service listening and serving on it's eth1 interface.
  10. VM2 runs in the webcache role, and also provides caching DNS services, using BIND (caching-nameserver). It is running Squid on port 3128. It also has two interfaces(, which may be debatable). The right hand side network interface (eth1) of VM2 is to be connected to xenbr1. This will ensure that the requests from users can reach it. The eth0 interface of VM2 is connected to vif2.0 port on xenbr0. The eth1 interface of VM2 is connected to vif2.1 port on xenbr1.
  11. Make sure that the network interfaces of the VMs get connected to correct bridges. The command "brctl show" can help you verify, which port is connected to which bridge.
  12. VM2 (webcache) can connect to xenbr0 through its network interface on the left (eth0). (This is the debatable part mentioned in the previous point; the link connected VM2's eth0 to xenbr0 is marked with a "*" for this purpose). If you want squid to get it's web pages from the internet, by going through VM1 (firewall), then there is no need to connect this link (marked with "*"). In this case, it would need to have it's GATEWAY set to the IP of VM1's eth1, which is 192.168.1.254 . However, remember that this way, there is an extra hop for each web page request. i.e. A web request from a user will first land on VM1, (because it is the gateway for all users). From there the firewall rules will DNAT the traffic to VM2, as the firewall allows outgoing web requests only from the IP of VM2 (192.168.1.253). VM2 then sends the web request on the users behalf to the gateway, which allows it to go to the Internet and fetch the web page. However, if this link (marked with "*") is in place, then each time VM2 will get a user's web request, it can contact the internet directly, bypassing the firewall. One can argue that in this way security can be fooled, or firewall can be bypassed, if for example, a user sets his/her IP manually to the IP of VM2 (the cache server). However, certain protection mechanisms, such as turning off packet forwarding, and few IPTables/firewall rules on the cache server, should be able to control this.
  13. It is important to note that the network 192.168.1.0/24 is invisible to the DSL router. Therefore, it is important to add a network route manually in the DSL router configuration, such as: Network 192.168.1.0/24 is reachable through this DSL router's LAN interface, using the gateway IP as 192.168.0.21 .
  14. The reader might be thinking that the DHCPD running on VM1 (firewall) may be conflicting with the dnsmasq service running on this physical host. The reality is, that (a) dnsmasq does not run as init script (can be turned off with chkconfig); it is called internally from libvirtd service (b) dnsmasq only bounds to virbr0 interface/192.168.122.1 (by default); and listens and serves VMs connected to this virtual bridge only. [Reference: http://permalink.gmane.org/gmane.comp.emulators.libvirt/21519]
  15. When using XEN, the libvirtd service can be configured to be either turned on, or turned off. It is safe to let it remain turned on, even if you don't seem to be using it. The libvirtd service creates a private bridge, virbr0 and connects a private network to it (192.168.122.0/24), as shown in Figure 3. There is no harm in letting it do that. This may prove useful in test situations, where you may want to create a "private" virtual machine on the XEN host, such as VM3 and VM4 shown in the diagram. The dnsmasq service (run internally through libvirtd) has mechanism to service the DHCP, DNS requests of any virtual machines connected to this particular virtual private network. The libvirtd service also adds certain rules in the iptables firewall on the host system to provide NAT (MASQUERADE) services to virtual machines connected to virbr0, which is beyond the scope of this paper.
  16. VM3 and VM4 have only one network interface card. They are connected to virbr0 on ports vif3.0 and vif4.0 respectively.

Configuration of Virtual Firewall System's components

The configuration of the components is not a big science. There is nothing to be afraid of. We have one physical server, with two physical interface cards, and two VMs running inside it. We would recommend at least 1 GB of physical RAM and 2.x GHz Intel P4 (or higher), or an AMD Athlon XP processor (or higher). The physical disk size depends on your requirement, and the amount of software you are going to install. We would recommend you to use LVM on the disk, on the host OS, so you can add and remove virtual disks easily. It is also easy to resize disks this way. Below is an example breakdown of the machines, in terms of RAM and Disk requirements.

  • Physical Machine: Bare bone (text/minimal) installation of CENTOS 5.5, with XEN Hypervisor. [512MB RAM, 2 GB LVM slice for (/), 128 MB slice for swap]
  • VM1 (Firewall): Bare bone (text/minimal) installation of CENTOS 5.5, with IPTables. [ 128MB RAM, 1 GB LVM slice for (/), 64 MB slice for swap]
  • VM2 (WebCache): Bare bone (text/minimal) installation of CENTOS 5.5, with IPTables, Squid, SquidGuard and optioanally SARG. [ 384MB RAM, 2-4 GB LVM slice for (/), 20GB - 30GB LVM slice for squid's cache directory, 64 MB slice for swap]

Configuration of Physical Machine

  • Physical machine "does not" run any service, other than the following: SSH, xend, libvirt (optional).
  • SSH allows key based authentication only. Direct root logins are dis-allowed.
  • Packet forwarding is disabled
  • The services xend (and libvirt) are configured to be accessed by the IPs from the right hand side LAN only.
  • There are no custom firewall/iptables rules on this machine. (You shouldn't). If you still want to add rules at this level, refer to the document: [Reference: http://cooker.techsnail.com/index.php/XEN,_KVM,_Libvirt_and_IPTables]
  • The libvirtd service provides some extra rules in the physical host's iptables rules-set. It also sets up a private bridge (virbr0), with the network 192.168.122.0/24.
  • The DNSMASQ service can be configured to be turned off using (chkconfig --del), however it would still be called internally from the libvirtd service.
  • DNSMASQ service provides DHCP, DNS and NAT (Masquerade) services only to the virtual machines connected to virbr0. Thus it is safe to let it run on the physical host.
  • As noted earlier, libvirtd can be configured to be turned off on the physical host, if you are not using virbr0, or any other capability provided by libvirtd.

Configuration of VM1 (Firewall)

  • This machine does not run any service, other than SSH, and DHCPD.
  • IPTables rules are configured to filter (and redirect) traffic on various criteria, such as Source/Destination IP addresses and Ports, and packet state.
  • Minimum number of IPTables rules, or efficient design of IPTables rules, as well as absence of extra services enable the firewall to work at peak performance.
  • Packet forwarding is enabled. (/etc/rc.local or /etc/sysctl.conf)
  • Certain TCP/IP kernel parameters can further be adjusted for performance gains. (optional)
  • There are no disk intensive operations on this VM.

Configuration of VM2 (WebCache)

  • This machine does not run any services, except: SSH, squid, SMTP Relay (PostFix), and DNS (BIND/caching-nameserver).
  • Squid is only accessible from the right hand side LAN (192.168.1.0/24).
  • Packet forwarding is disabled.
  • Squid is the major disk I/O intensive process, running on this VM.

Related Open Source Firewall Solutions

If you are not confident in setting up your firewall, yourself, there are other alternatives, which you can safely use, in both non-virtualized and virtualized setups. These are:

References

Retrieved from "http://cooker.wbitt.com/index.php/Virtualizing_your_Linux_Firewall"
Personal tools