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.
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.
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
| 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 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
- Home, My Backup Data Center
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




21 min 54 sec ago
50 min 24 sec ago
1 hour 48 min ago
3 hours 17 min ago
4 hours 25 min ago
5 hours 12 min ago
5 hours 33 min ago
11 hours 48 min ago
17 hours 26 min ago
23 hours 26 min ago