Sunday, November 10, 2013

isowall: an isolating firewall

While researching a virus infection, Dragos Ruiu asked for the world's simplest firewall to isolate/quarantine the infected machine, so that it has access to the Internet, but not to the local network. So I created just such a firewall: isowall.

As a demonstration, I'm running isowall on a "Raspberry Pi", a $50 hobbyest Linux machine. The laptop in this picture may be infected with a virus. I want the laptop to still access the Internet, but not access my local network, where it may spread the infection. As you can see, the laptop has a direct Ethernet link to the Raspberry Pi running isowall (short purple cable to white USB Ethernet), which then links to the rest of my home network (grey cable).

The command-line on the Raspberry Pi looks like the following. As you can see, the infected laptop has an IP address of and connects via 'eth1', but it can only exchange packets with the local router (and hence the Internet), and not any of the other devices on the local network.

The security guarantee of isowall rests on the fact that there is no TCP/IP stack bound to 'eth1'. Isowall has it's own TCP/IP. Today's firewalls fail because they are extensions to the existing network stack of the operating system. This introduces a huge attack surface and a lot of complexity, meaning hackers can attack the firewalls themselves, and users will misconfigure firewall rules. What isowall does is separate the two duties: TCP/IP firewalling is done wholly separate from the Linux TCP/IP stack.

You can see his principle when you run 'ifconfig'. As you can see, 'eth1' has no IP address assigned to the network adapter. The infected machine can attack this Ethernet port all it wants, it won't get anywhere, because there's nothing listening on that Ethernet except for isowall.

Another security guarantee that isowall provides is that it prevents common user configuration errors. It has the simplest, most necessary configuration options possible. This is shown in the above picture, where all the options are specified on the command-line. This means all options can be read to verify that you are secure.

Let's say that you do something wrong, and add an IP address to 'eth1'. If isowall detects this, it will refuse to startup. If this is done after isowall is running, it'll shut down with a nasty warning message, as shown below.

Lastly, there is another security guarantee: simple code. All the TCP/IP packet parsing and evaluation is contained in the function "is_valid()" at the top of the file "main.c" in the isowall source code. Anybody can read this code and verify that isowall doesn't have a bug that would allow a hacker to bypass or attack the firewall.


Isowall is for the paranoid. Let's say that you fear the smartest hackers in the world have infected your laptop. You want to connect it to the Internet to so you can analyze what it's doing, but you don't want the infection to spread. Isowall is probably the best guarantee you'll get.

Notes: In the above demonstration, notice the option "--reuse-external". Isowall is actually intended for use in systems with three adapters, where you control the system over 'eth0', then bridge between 'eth1' and 'eth2'. However, the Raspberry Pi has power issues, and can't always power two additional Ethernet adapters. Thus, I use 'eth0' both for the control connection (with an operating system IP address) and the 'external' network. This is perfectly secure as far as I can tell, though it breaks the model a bit.



CCD said...

One idea to get around the power limitation would be to use a small 4 port usb externally powered hub and a couple of USB to ethernet interfaces (or even wifi). I do this with the beagle bone black for a few projects.

I did something very similar to this concept a few years ago, but I didn't go as far as eliminating the ip stack or inserting between the infected system and the switch. With an esxi server and 4 interfaces, used a centos 6 vm with three virtual interfaces, and setup two interfaces as a bridging firewall so it was transparent between the kids infected machines and the external firewall. Still used IPTABLES but at layer 2 and still let me allow or block packets based on layer 3 criteria and inspect packets with snort and argus and such but reduced the potential attack surface area. It was a fun project. I also used a third interface.

CCD said...

was trying to say at the end the third interface was for management of the firewall, locked to just the system I needed to access it from.

Unknown said...

why do ppl create screenshot of plaintext console-output? W(

Robert Graham said...

I create screenshots to show that which HAS been done, not that which CAN be done. A screenshot of text gives higher confidence that it hasn't been changed. For example, you can see the color of the text that it unique to Raspbian.

Zach Varnell said...
This comment has been removed by the author.
Zach Varnell said...

This would also be good for isolating honeypots. That way even if an attacker broke out of Kippo (or whatever other software) they couldn't pivot to other machines on the network.