Differences between revisions 9 and 13 (spanning 4 versions)
Revision 9 as of 2008-08-20 01:17:54
Size: 5489
Editor: LukeWilliams
Comment: combine caveats with overview
Revision 13 as of 2009-12-23 14:50:08
Size: 5467
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
[[TableOfContents]] <<TableOfContents>>
Line 5: Line 5:
''ucc-fw'' is located on madako in {{{/etc/init.d/}} and at time of writing weighs in at nearly 700 lines of arcane iptables commands and cryptic comments, and is responsible for keeping the baddies out. It is also responsible for keeping costs down by making sure the right data goes out the right link, NAT for the Silk link, and a lot of other things the reasons for which will become apparent as you familiarize yourself with the way information flows in and out of the club. As suggested by its location, ''ucc-fw'' is initialized at boot and can changes can be applied by simply running the script again. ''ucc-fw'' is located on madako in {{{/etc/init.d/}}} and at time of writing weighs in at nearly 700 lines of arcane iptables commands and cryptic comments, and is responsible for keeping the baddies out. It is also responsible for keeping costs down by making sure the right data goes out the right link, NAT for the Silk link, and a lot of other things the reasons for which will become apparent as you familiarize yourself with the way information flows in and out of the club. As suggested by its location, ''ucc-fw'' is initialized at boot and changes can be applied by simply running the script again.
Line 29: Line 29:
At this point you'll want to refer to the [http://pub1.zcjh.tpc.edu.tw:9100/computer/Lists/Discussion/Attachments/1/PacketFlow.png diagram showing the order packets go through the various tables]. The mangle PREROUTING table comes first, and it is basically a filter saying whether packets should get NATted or not - mark 1 will be, packets going to local subnets shouldn't be, and the mangle FREENETSOUT table is set up by toipset.sh (document) so that packets not to FREENETs get mark 1 applied. At this point you'll want to refer to the [[http://pub1.zcjh.tpc.edu.tw:9100/computer/Lists/Discussion/Attachments/1/PacketFlow.png|diagram showing the order packets go through the various tables]]. The mangle PREROUTING table comes first, and it is basically a filter saying whether packets should get NATted or not - mark 1 will be, packets going to local subnets shouldn't be, and the mangle FREENETSOUT table is set up by toipset.sh (document) so that packets not to FREENETs get mark 1 applied.
Line 46: Line 46:
== Caveats ==


The devil has a name, and it is ucc-fw. This article aspires to be a reference manual for the UCC firewall. It does not aspire to be a reference manual for iptables, and readers are expected to familiarize themselves with the basics of iptables syntax before attempting to change the central firewall.

Not just a firewall

ucc-fw is located on madako in /etc/init.d/ and at time of writing weighs in at nearly 700 lines of arcane iptables commands and cryptic comments, and is responsible for keeping the baddies out. It is also responsible for keeping costs down by making sure the right data goes out the right link, NAT for the Silk link, and a lot of other things the reasons for which will become apparent as you familiarize yourself with the way information flows in and out of the club. As suggested by its location, ucc-fw is initialized at boot and changes can be applied by simply running the script again.

One trick is that it isn't just iptables that is doing the magic - the "ip" command is used for some of the source routing. ip rule list will show you some of that (fwmark etc), and ip route list table all or ip route list table bright are handy.

Overview

The firewall script has several distinct parts. Let's look at them in turn:

Madako firewalling

First up is the incoming firewall for madako itself. This is fairly restrictive, only allowing SSH from everywhere (and even that has fail2ban in front of it). Other things are only allowed from UCC, UWA or occasionally FREENETs. PPTP connections and SSH are allowed from SNAP, but nothing else.

Main firewall

This section is about access control. There are two main chains, TOOUTSIDE and FROMOUTSIDE that most rules are added to, and there's two extra targets, FREENETSIN and FREENETSOUT that jump to a long list of free networks stored using ipset. Ports like CIFS, MSSQL are blocked, as is access to machines with vulnerable OSen (like IRIX). Hosts in $UNFIREWALLED can receive charged traffic and do their own firewalling. Next comes the magic Silk link stuff, see below. After this comes a long list of rules to open ports for particular hosts, in roughly ascending order by IP. Incoming ports are generally opened to FREENETSIN. Outgoing ports don't need to be unfirewalled to go to FREENETs or the Silk link, only if they need to go out to charged IPs, in which case see below as well.

This is where the tentacles start emerging. The idea is to force traffic not going to FREENETs over the Silk link, while offering various services on both the Silk and byte-charged links.

Mark 1 is set on packets that should go out the bright link. Mark 2 is set on connections coming in over the Silk link, so they can be matched on the way out and sent back out the bright link. Mark 3 is set on connections coming in over AARNet destined for unfirewalled IPs that need to go back out over AARNet. This is set for all hosts in $UNFIREWALLED, and can be added to hosts outside this range. Mark 4 is set on port 80 connections from the clubroom, wireless and loft so they can be transproxied, which makes the Silk link suck a lot less for browsing.

Packets with Mark 1 pass through the TOOUTSIDE chain, as they'll be NATted and sent over the Silk link.

At this point you'll want to refer to the diagram showing the order packets go through the various tables. The mangle PREROUTING table comes first, and it is basically a filter saying whether packets should get NATted or not - mark 1 will be, packets going to local subnets shouldn't be, and the mangle FREENETSOUT table is set up by toipset.sh (document) so that packets not to FREENETs get mark 1 applied.

NATting

Then the NAT occurs. First up, anything with mark 1 (most outgoing traffic on Silk) gets SNATted to 203.24.97.254. Next come the DNAT rules for incoming ports on the Silk link, which come as groups of 3 rules - two DNATs (which could be unified?) and one to set mark 2 (which you'll recall causes the outgoing traffic to be get mark 1, causing it to go back out over Silk. This is possibly only needed for hosts in $UNFIREWALLED). Then a few other DNATs for policy purposes, followed by SNATs for the various 172.26.42 networks.

Common Tasks

Most changes to ucc-fw are relatively mundane: unblocking a port, forwarding a port, and unfirewalling a particular host (eg: for a colocated user machine).

Letting things through

The most common firewall maintenance task you'll come across is also the easiest. Letting a port through is as simple as a couple of well-placed lines. The exact syntax for how to allow a port through to a host is an exercise left for the reader, but in most cases you should be able to copy existing entries and modify them to suit your purposes.

  1. Find the part of the script entitled 'Inbound machine specific rules' and create a new rule for your host and port.
  2. If the host isn't on the machine room network then you'll also need to add a couple of rules to the 'Incoming traffic for unfirewalled IPs' section. Have a look at what marcel and paradise are doing, as a guide.

Unfirewall incoming ports, set up a NAT. Something else?


CategorySystemAdministration