Virtualizing your Linux Firewall

From WBITT's Cooker!

Revision as of 19:47, 8 March 2011

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

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, 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 failure. 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 it all, 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 of prominent firewall vendors is to create Fear, Uncertainty and Doubts,(FUD), in the minds of the possible customers, about low cost Linux firewalls. When they are successful in doing that, the sales people move to the next step, and convince their customers to purchase the ultra expensive firewall. The interesting point is, that even the IT managers also do not resist in such purchases, because they "feel secure" by merely buying a branded product, and don't want to take any risk by saying "No". After the product is acquired, it is placed on the network, without a well thought out configuration. 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 was, (a) not well configured, (b) no-body well understood it (c) 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, where merely a fly swatter was required in the first place.

In this paper we would discuss the possibility of using Linux based firewalls, running as virtual machines, on a XEN or KVM host. We would also show, how this can be achieved.

Linux as a 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.

It would be interesting for many to know that Cisco PIX uses processors like Intel Celeron, Intel PIII, and AMD's Am5x86; with Intel 440BX and AMD's SC520 chip-sets; with RAM range between 16 MB to 1 GB. [Reference: http://en.wikipedia.org/wiki/Cisco_PIX#Description_of_hardware].

A modern day PC is much more powerful than what is described above. A cut down version / minimal install of Linux OS on a commodity off the self PC, can essentially turn it into a firewall, more powerful than the Cisco PIX. 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 totally free OS and it's tools; Linux.

• 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.
• 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, by having all of the services on one physical machine. However, the purpose of this paper is 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 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.

From this point onwards, we will not discriminate Linux based firewalls against prominent hardware-based branded firewall devices.

The Virtual Firewall

As we noted above, 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 in virtual world.

Advantages

• Compartmentalized Security: Firewall can run as a separate VM. Cache Server can run as a separate VM, 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 the cache server's disk is full, with logs, etc, it will be the only VM, which will not respond. Main firewall VM will keep functioning.
• Service/VM Load Balancing: If cache server/content filtering is taking too much resources, that VM can be moved to another physical machine on the network.
• COTS/in-expensive hardware: This results in ability to have multiple physical machines in stock. In case a hardware failure occurs, the second physical machine can be quickly setup to run VMs and the services they offer.

Disadvantages

• Extra complexity: Virtualization introduces extra level of complexity in the 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.

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 as 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.

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, yet inside the bigger white 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. It also tells us that all machines connected to it are on the same network 192.168.0.0/24. There is no virtual-private network here, such as 192.168.122.0/24.
6. xenbr1 is a software bridge which primarily connects peth1 and eth1 of Domain-0. It also tells us that all machines connected to it are on the same network 192.168.1.0/24. There is no virtual-private network here, such as 192.168.122.0/24.
7. 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, instead of peth1 of the physical host.
8. 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.
9. VM2 runs in the webcache role, and also provides caching DNS services. 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.
10. VM2 can connect to xenbr0 through its network interface on the left (eth0). This is the debatable part. 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, 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.
11. 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 .

Configuration of Virtual Firewall System's components

References

• http://en.wikipedia.org/wiki/Cisco_PIX#Description_of_hardware
• http://cooker.techsnail.com/index.php/Virtualization-XEN