Building a Transparent Firewall with Linux, Part V
Now it's time to configure the Linux bridge with the same firewall policy I implemented under OpenWrt. Listing 2 shows last month's custom iptables script, adapted for use as an Ubuntu init script. (Actually, we're going to run it from the new “upstart” system rather than init, but more on that shortly.)
Listing 2. Custom iptables Startup Script
#! /bin/sh
### BEGIN INIT INFO
# Provides: iptables_custom
# Required-Start: $networking
# Required-Stop:
# Default-Start:
# Default-Stop: 0 6
# Short-Description: Custom bridged iptables rules
### END INIT INFO
PATH=/sbin:/bin
IPTABLES=/sbin/iptables
LOCALIP=10.0.0.253
LOCALLAN=10.0.0.0/24
WEBPROXY=10.0.0.111
. /lib/lsb/init-functions
do_start () {
log_action_msg "Loading custom bridged iptables rules"
# Flush active rules, custom tables
$IPTABLES --flush
$IPTABLES --delete-chain
# Set default-deny policies for all three default tables
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
# Don't restrict loopback (local process intercommunication)
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
# Block attempts at spoofed loopback traffic
$IPTABLES -A INPUT -s $LOCALIP -j DROP
# pass DHCP queries and responses
$IPTABLES -A FORWARD -p udp --sport 68 --dport 67 -j ACCEPT
$IPTABLES -A FORWARD -p udp --sport 67 --dport 68 -j ACCEPT
# Allow SSH to firewall from the local LAN
$IPTABLES -A INPUT -p tcp -s $LOCALLAN --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 22 -j ACCEPT
# pass HTTP and HTTPS traffic only to/from the web proxy
$IPTABLES -A FORWARD -p tcp -s $WEBPROXY --dport 80 -j ACCEPT
$IPTABLES -A FORWARD -p tcp --sport 80 -d $WEBPROXY -j ACCEPT
$IPTABLES -A FORWARD -p tcp -s $WEBPROXY --dport 443 -j ACCEPT
$IPTABLES -A FORWARD -p tcp --sport 443 -d $WEBPROXY -j ACCEPT
# pass DNS queries and their replies
$IPTABLES -A FORWARD -p udp -s $LOCALLAN --dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p tcp -s $LOCALLAN --dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p udp --sport 53 -d $LOCALLAN -j ACCEPT
$IPTABLES -A FORWARD -p tcp --sport 53 -d $LOCALLAN -j ACCEPT
# cleanup-rules
$IPTABLES -A INPUT -j LOG --log-prefix "Dropped by default
↪(INPUT):"
$IPTABLES -A INPUT -j DROP
$IPTABLES -A OUTPUT -j LOG --log-prefix "Dropped by default
↪(OUTPUT):"
$IPTABLES -A OUTPUT -j DROP
$IPTABLES -A FORWARD -j LOG --log-prefix "Dropped by default
↪(FORWARD):"
$IPTABLES -A FORWARD -j DROP
}
do_unload () {
$IPTABLES --flush
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
}
case "$1" in
start)
do_start
;;
restart|reload|force-reload)
echo "Reloading bridging iptables rules"
do_unload
do_start
;;
stop)
echo "DANGER: Unloading firewall's Packet Filters!"
do_unload
;;
*)
echo "Usage: $0 start|stop|restart" >&2
exit 3
;;
esac
Space doesn't permit a detailed walk-through of this script, but the heart of Listing 2 is the “do_start” routine, which sets all three default chains (INPUT, FORWARD and OUTPUT) to a default DROP policy and loads the firewall rules. The example rule set enforces this policy:
Hosts on the local LAN may send DHCP requests through the firewall and receive their replies.
Hosts on the local LAN may connect to the firewall using Secure Shell.
Only the local Web proxy may send HTTP/HTTPS requests and receive their replies.
Hosts on the local LAN may send DNS requests through the firewall and receive their replies.
This policy assumes that the network's DHCP and DNS servers are on the other side of the firewall from the LAN clients, but that its Web proxy is on the same side of the firewall as those clients.
You may recall that with OpenWrt, the state-tracking module that allows the kernel to track tcp and even some udp applications by transaction state, rather than one packet at a time, induces a significant performance hit. Although that's almost certainly not so big an issue on a PC-based firewall that has enough RAM and a fast enough CPU, I'm going to leave it to you to figure out how to add state tracking to the script in Listing 2; it isn't difficult at all!
I have, however, added some lines at the end of the “do_start” routine to log all dropped packets. Although logging on OpenWrt is especially problematic due to the limited virtual disk capacity on the routers on which it runs, this is just too important a feature to leave out on a proper PC-based firewall. On most Linux systems, firewall events are logged to the file /var/log/messages, but if you can't find any there, they instead may be written to /var/log/kernel or some other file under /var/log.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
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.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Tech Tip: Really Simple HTTP Server with Python
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




3 hours 12 min ago
6 hours 59 min ago
7 hours 7 min ago
9 hours 22 min ago
11 hours 51 min ago
21 hours 54 min ago
1 day 2 hours ago
1 day 5 hours ago
1 day 6 hours ago
1 day 8 hours ago