Building a Transparent Firewall with Linux, Part IV

Arm your stealth firewall with a custom iptables script.

I've been writing a multipart series on building a transparent (bridging) firewall using Linux. Specifically, I'm using the distribution OpenWrt running on a Linksys WRT54GL broadband router, a hardware choice driven mainly by my curiosity about the WRT54GL's built-in five-port Ethernet switch and its ability to run OpenWrt Linux.

So far I've covered installing OpenWrt, recompiling a new OpenWrt image with iptables' bridging functionality enabled and configuring networking using OpenWrt's uci (Unified Configuration Interface) command.

This month, I review the example network topology and finally begin configuring iptables, the heart of the whole undertaking. Before I do so, however, there are a few OpenWrt housecleaning tasks to get out of the way: tweaking the kernel and network configurations, and disabling OpenWrt's native firewall system.

Kernel Parameters and a Network Tweak

Recompiling the OpenWrt image with CONFIG_BRIDGE_NETFILTER=y set in the Linux kernel is the first of two steps in enabling iptables' bridging mode in OpenWrt. The second step is either to delete the following parameters in /etc/sysctl.conf or set each of them to “1” rather than “0”:

net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0

In addition, I need to correct an error I made in the OpenWrt network configuration I showed you last time. You may recall that I changed OpenWrt's default configuration, such that all Ethernet ports were assigned to a single VLAN and bridge.

But possibly due to the way the Linux kernel interacts with the bridge hardware on my Linksys WRT54GL, with that configuration, I find that iptables ignores inter-VLAN traffic—that is, traffic between ports on the same VLAN. In order to get iptables to work properly on this hardware and on OpenWrt, I actually need two VLANs: one corresponding to my “uplink” (the Ethernet port connected to the outside world) and my “LAN” (everything else). These two VLANs, however, are still associated with the same bridge interface.

To create a separate VLAN for my uplink port, which is my WRT54GL's “WAN” port (or “port 4” to OpenWrt), I issue these commands on my router:

root@sugartongs:/etc/config# uci set network.eth0_1=switch_vlan
root@sugartongs:/etc/config# uci set network.eth0_1.device="eth0"
root@sugartongs:/etc/config# uci set network.eth0_1.vlan="1"
root@sugartongs:/etc/config# uci set network.eth0_1.ports="4 5"

(Port 5, you'll recall, is a virtual port associated with the kernel, that must be included in all “ports” statements in OpenWrt network configurations, which is why our “...ports” statement is set to “4 5” rather than just “4”.)

To remove the WAN port from the other VLAN (eth0_0) I set up last time, I use this command:

root@sugartongs:/etc/config# uci set network.eth0_0.ports="0 1 2 3 5"

Next, in my bridge configuration, for the network I named “lan”, I associate both VLANs with the bridge:

root@sugartongs:/etc/config# uci set 
 ↪network.lan.ifname="eth0.0 eth0.1"

And finally, I list my new network configuration to make sure everything's correct, commit the changes and reboot:

root@sugartongs:/etc/config# uci show network
root@sugartongs:/etc/config# uci commit
root@sugartongs:/etc/config# reboot

Listing 1 shows what the resulting /etc/config/network file looks like.

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions