|
Size: 1885
Comment: mention ip rule
|
Size: 3065
Comment: the bright link is dead. long live the bright link!
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Not ready for human consumption, I'll remove this notice and resume work on this article when I get back from pizza - [LAW] ---- |
|
| Line 4: | Line 2: |
| <<TableOfContents>> | |
| Line 7: | 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 become familiar with the way information flows in and out of the club. | ''ucc-fw'' is located on madako in {{{/etc/init.d/}}} and one point it was 700 lines of arcane iptables commands and cryptic comments, responsible for keeping the baddies out, 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. |
| Line 9: | Line 7: |
| As suggested by its location, ''ucc-fw'' is initialized at boot and can changes can be applied by simply running the script again. | Luckily it is now largely just a firewall. |
| Line 11: | Line 9: |
| == Letting things through == The most common firewall maintenance task you'll come across is also the easiest. == |
As suggested by its location, ''ucc-fw'' is initialized at boot and changes can be applied by simply running the script again. == 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. 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 ACCEPT (the whole world) or FREENETSIN (a smaller subsection of the whole world). Outgoing ports don't need to be unfirewalled. === NATting === Then the NAT occurs. There are a few DNATs for policy purposes, followed by SNATs for the various 172.26.42 networks. |
| Line 17: | Line 29: |
| === Unfirewalling a host === This quick guide assumes the host you wish to unfirewall is on VLAN 3, as most colocated user machines will be. If it is on a different VLAN you should read the rest of this document before trying to adapt these instructions to your specific case. The two sections |
=== 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. |
| Line 20: | Line 34: |
| == Caveats == 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). |
---- CategorySystemAdministration |
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.
Contents
Not just a firewall
ucc-fw is located on madako in /etc/init.d/ and one point it was 700 lines of arcane iptables commands and cryptic comments, responsible for keeping the baddies out, 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.
Luckily it is now largely just a firewall.
As suggested by its location, ucc-fw is initialized at boot and changes can be applied by simply running the script again.
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. 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 ACCEPT (the whole world) or FREENETSIN (a smaller subsection of the whole world). Outgoing ports don't need to be unfirewalled.
NATting
Then the NAT occurs. There are a few 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.
- Find the part of the script entitled 'Inbound machine specific rules' and create a new rule for your host and port.
- 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.
