Vote for the Student Tech Fund's renewal during the ASUC Elections @ April 5-7!
The OCF is funded by the Student Technology Fund, which will expire if not renewed. read more »
While the external firewall regulates network traffic to the OCF from outside the OCF network, internal firewalls are responsible for regulating network traffic between different machines within the OCF.
OCF machines are broadly classed into internal and DMZ. Internal machines are those which are not running user code and are not staff VMs, specifically those in the IP range 5-90 (excluding the ones in the DMZ listed below). The DMZ consists of all other machines, including:
Each server filters input traffic as follows:
In addition to input rules, it's necessary to have some output rules as well to protect devices that we don't trust to have reliable firewalls, such as printers and IPMI devices. The rules for those devices work a little differently:
Output rules are not a perfect solution, since they operate on a voluntary mechanism and can't prevent non-OCF hosts that may be connected to our network from contacting these special devices anyway. Preventing this is a future project.
It's important to note that internal firewalls are set up to only filter traffic from other OCF machines. Traffic from outside the OCF network is the sole responsibility of the external firewall.
Internal firewalls are implemented using iptables rules set by Puppet with the
puppetlabs-firewall module. We place all of our input
rules in the
PUPPET-INPUT chain and all of our output rules in the
Firewall rules are added by using
ocf::firewall::firewall46should generally be used in most cases. It inserts IPv4 and IPv6 iptables rules, but only adds the IPv6 iptables rule if the host has a public IPv6 address. This prevents Puppet errors otherwise occurring due to IPv6 addresses not being resolved.
firewall_multishould be used if IP addresses need to be manually specified in the firewall rule.
firewall_multiboth internally use the
firewallresource. Direct use of the
firewallresource should be avoided since such resources wouldn't be subject to the ordering constraints generally placed on firewall resources.
Note that all of the following commands need to be run as root.
iptables command allows you to inspect and debug IPv4 firewall rules:
iptables -L: list firewall rules
iptables -L PUPPET-INPUTlists our input firewall rules
iptables -L PUPPET-OUTPUTlists our output firewall rules
-voption to list more detailed info (like statistics and input/output interface)
-noption to show IP addresses and port numbers instead of hostnames and port names
iptables -S: dump firewall rules in machine-parseable format
iptables -S <chain>: dump firewall rules for a given chain
iptables -F <chain>: deletes all of the rules in the given chain.
iptables -Fon that chain and subsequently rerunning Puppet will clear the issue.
iptables -D <chain> <rulenum>: Deletes the rulenum-th rule from the given chain (i.e.
iptables -A <chain> <rule-specification>: Adds the specified rule to the given chain. Note that this command is not particularly useful for the
PUPPET-OUTPUTchains, since any added rules will be purged by Puppet.
For IPv6 firewall rules, you need to use the
ip6tables command instead. The
invocation is the same as for
Iptables rules are not automatically persisted across reboots. In order for your
changes to iptables to be preserved across reboots, you need to additionally
service netfilter-persistent save. This is done automatically after
every Puppet run which results in iptables rules being modified, but if you
manually fiddle with iptables you may need to run it yourself.
In an emergency, it's possible to effectively disable firewalling of input
traffic on a server by setting
false in that server's hieradata. Turning on this option causes the rules in
the PUPPET-INPUT chain which reject traffic to be deleted, effectively disabling
the firewall's function of filtering input packets.
An analogous kill switch does not currently exist for output-traffic firewalling, but can be easily added.