Setting up a Linux system as a firewall for a small -network is a fairly straight-forward task if you understand the basics -and follow the documentation.
-This guide doesn't attempt to acquaint you with all of the features -of Shorewall. It rather focuses on what is required to configure -Shorewall in its most common configuration:
-Here is a schematic of a typical installation.
-
If you are running Shorewall under Mandrake 9.0 or later, you can
-easily configure the above setup using the Mandrake "Internet
-Connection
-Sharing" applet. From the Mandrake Control Center, select "Network
-& Internet" then "Connection Sharing".
-
Note however, that the Shorewall configuration produced by
-Mandrake Internet Connection Sharing is strange and is apt to confuse
-you if you use the rest of this documentation (it has two local zones;
-"loc" and "masq" where "loc" is empty; this conflicts with this
-documentation which assumes a single local zone "loc"). We therefore
-recommend that once you have set up this sharing that you uninstall the
-Mandrake Shorewall RPM and install the one from the download page then follow the instructions in
-this Guide.
-
Shorewall requires that you have the iproute/iproute2 package -installed (on RedHat, the package is called iproute). You -can tell if this package is installed by the presence of an ip -program on your firewall system. As root, you can use the 'which' -command to check for this program:
-[root@gateway root]# which ip-
/sbin/ip
[root@gateway root]#
I recommend that you first read through the guide to familiarize
-yourself with what's involved then go back through it again making your
-configuration changes. Points at which configuration changes are
-recommended are flagged with 
. Configuration notes that are unique to
-LEAF/Bering are marked with 
- If you edit your configuration files on a Windows
-system, you must save them as Unix files if your editor supports that
-option or you must run them through dos2unix before trying
-to use them. Similarly, if you copy a configuration file from your
-Windows hard drive to a floppy disk, you must run dos2unix against the
-copy before using it with Shorewall.
If you
-have an ADSL Modem and you use PPTP to communicate with a server in
-that modem, you must make the changes
-recommended here in addition to those detailed below. ADSL with
-PPTP is most commonly found in Europe, notably in Austria. The configuration files for Shorewall are
-contained in the directory /etc/shorewall -- for simple setups, you
-will only need to deal with a few of these as described in this guide.
-After you have installed Shorewall, download
-the two-interface
-sample, un-tar it (tar -zxvf two-interfaces.tgz) and and copy the
-files
-to /etc/shorewall (these files will replace files with the same
-name).
As each file is introduced, I suggest that you look through the -actual file on your system -- each file contains detailed configuration -instructions and default entries.
-Shorewall views the network where it is running as being composed of -a set of zones. In the two-interface sample configuration, the -following zone names are used:
-| Name | -Description | -
| net | -The Internet | -
| loc | -Your Local Network | -
Zones are defined in the -/etc/shorewall/zones file.
-Shorewall also recognizes the firewall system as its own zone - by -default, the firewall itself is known as fw.
-Rules about what traffic to allow and what traffic to deny are -expressed in terms of zones.
-For each connection request entering the firewall, the request is -first checked against the /etc/shorewall/rules file. If no rule in -that file matches the connection request then the first policy -in /etc/shorewall/policy that matches the request is applied. -If that policy is REJECT or DROP the request is first checked -against -the rules in /etc/shorewall/common if that file exists; otherwise the -rules in /etc/shorewall/common.def are checked.
-The /etc/shorewall/policy file included with the two-interface -sample -has the following policies:
---- -
-- -Source Zone -Destination Zone -Policy -Log Level -Limit:Burst -- -loc -net -ACCEPT -- - - -net -all -DROP -info -- - - -all -all -REJECT -info --
--In the two-interface sample, the line below is included but -commented out. If you want your firewall system to have full access to -servers on the internet, uncomment that line.
-- -
-- -Source Zone -Destination Zone -Policy -Log Level -Limit:Burst -- - -fw -net -ACCEPT -- -
The above policy will:
-
- At this point, edit your /etc/shorewall/policy
-and make any changes that you wish.
The firewall has two network interfaces. Where Internet -connectivity -is through a cable or DSL "Modem", the External Interface will -be -the ethernet adapter that is connected to that "Modem" (e.g., eth0) -unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the -External Interface will be a ppp interface (e.g., ppp0). If you -connect via a regular modem, your External Interface will also be ppp0. -If you connect via ISDN, your external interface will be ippp0.
-
If your external interface is ppp0
-or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
Your Internal Interface will be an ethernet -adapter (eth1 or eth0) and will be connected to a hub or switch. Your -other computers will be connected to the same hub/switch (note: -If you have only a single internal system, you can connect the firewall -directly to the computer using a cross-over cable).
- Do not connect the internal and
-external interface to the same hub or switch except for testing AND you
-are running Shorewall version 1.4.7 or later. When using these
-recent versions, you can test using this kind of configuration if you
-specify the arp_filter option
-in /etc/shorewall/interfaces for all interfaces connected to the common
-hub/switch. Using such a setup with a production firewall is strongly
-recommended against.
-
The Shorewall two-interface
-sample configuration assumes that the external interface is eth0
-and the internal interface is eth1. If your configuration is
-different, you will have to modify the sample /etc/shorewall/interfaces file
-accordingly. While you are there, you may wish to review the list of
-options that are specified for the interfaces. Some hints:
If your external interface is ppp0 or ippp0, -you can replace the "detect" in the second column with "-".
-If your external interface is ppp0 or ippp0 -or if you have a static IP address, you can remove "dhcp" from the -option list.
-Before going further, we should say a few words about -Internet Protocol (IP) addresses. Normally, your ISP will -assign you a single Public IP address. This address may be -assigned via the Dynamic Host Configuration Protocol (DHCP) or -as part of establishing your connection when you dial in (standard -modem) or establish your PPP connection. In rare cases, your ISP may -assign you a static IP address; that means that you configure -your firewall's external interface to use that address permanently. However -your external address is assigned, it will be shared by all of your -systems when you access the Internet. You will have to assign your own -addresses in your internal network (the Internal Interface on your -firewall plus your other computers). RFC 1918 reserves several Private -IP address ranges for this purpose:
-10.0.0.0 - 10.255.255.255-
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Before starting Shorewall, you should
-look at the IP address of your external interface and if it is one of
-the above ranges, you should remove the 'norfc1918' option from the
-external interface's entry in /etc/shorewall/interfaces.
You will want to assign your addresses from the same -sub-network (subnet). For our purposes, we can -consider a subnet to consists of a range of addresses x.y.z.0 - -x.y.z.255. Such a subnet will have a Subnet Mask of -255.255.255.0. The -address x.y.z.0 is reserved as the Subnet Address and x.y.z.255 -is reserved as the Subnet Broadcast Address. In -Shorewall, a subnet is described using Classless InterDomain -Routing (CIDR) notation with consists of the subnet address -followed by "/24". The "24" refers to the number of consecutive leading -"1" bits from the left of the subnet mask.
-Example sub-network:
---- -
-- -Range: -10.10.10.0 - 10.10.10.255 -- -Subnet Address: -10.10.10.0 -- -Broadcast Address: -10.10.10.255 -- - -CIDR Notation: -10.10.10.0/24 -
It is conventional to assign the internal interface -either the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).
-One of the purposes of subnetting is to allow all -computers in the subnet to understand which other computers can be -communicated with directly. To communicate with systems outside of the -subnetwork, systems send packets through a gateway -(router).
- Your local computers (computer 1 and
-computer 2 in the above diagram) should be configured with their
-default gateway to be the IP address of the firewall's internal
-interface.
The foregoing short discussion barely scratches the -surface regarding subnetting and routing. If you are interested in -learning more about IP addressing and routing, I highly recommend "IP -Fundamentals: What Everyone Needs to Know about Addressing & -Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
-The remainder of this quide will assume that you have -configured your network as shown here:
- 
The default gateway for computer's 1 & 2 would be
-10.10.10.254.
-
WARNING:
-Your ISP might assign your external interface an RFC 1918
-address. If that address
-is in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT
-RFC 1918 subnet for your local network.
-
The addresses reserved by RFC 1918 are sometimes -referred to as non-routable because the Internet backbone -routers don't forward packets which have an RFC-1918 destination -address. When one of your local systems (let's assume computer 1) sends -a -connection request to an internet host, the firewall must perform -Network Address Translation (NAT). The firewall rewrites -the source address in the packet to be the address of the firewall's -external interface; in other words, the firewall makes it look as -if the firewall itself is initiating the connection. This is -necessary -so that the destination host will be able to route return packets back -to the firewall (remember that packets whose destination address -is reserved by RFC 1918 can't be routed across the internet so the -remote host can't address its response to computer 1). When the -firewall -receives a return packet, it rewrites the destination address back to -10.10.10.1 and forwards the packet on to computer 1.
-On Linux systems, the above process is often referred -to -as IP Masquerading but you will also see the term Source -Network -Address Translation (SNAT) used. Shorewall follows the convention -used -with Netfilter:
-Masquerade describes the case where you let -your firewall system automatically detect the external interface -address.
-SNAT refers to the case when you explicitly -specify the source address that you want outbound packets from your -local network to use.
-In Shorewall, both Masquerading and SNAT are configured -with entries in the /etc/shorewall/masq file. You will normally use -Masquerading if your external IP is dynamic and SNAT if the IP -is static.
- If your external firewall interface is
-eth0, you do not need to modify the file provided with the
-sample. Otherwise, edit /etc/shorewall/masq and change the first column
-to the name of your external interface and the second column to the
-name of your internal interface.
If your external IP is static, you can
-enter it in the third column in the /etc/shorewall/masq entry if you
-like although your firewall will work fine if you leave that column
-empty. Entering your static IP in column 3 makes processing outgoing
-packets a little more efficient.
-
-
- If you are using the Debian package, please check
-your
-shorewall.conf file to ensure that the following are set correctly;
-if they are not, change them appropriately:
-
One of your goals may be to run one or more servers on -your local computers. Because these computers have RFC-1918 addresses, -it is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their -connection requests to the firewall who rewrites the destination -address to the address of your server and forwards the packet to -that server. When your server responds, the firewall automatically -performs SNAT to rewrite the source address in the response.
-The above process is called Port Forwarding or -Destination Network Address Translation (DNAT). You configure port -forwarding using DNAT rules in the /etc/shorewall/rules file.
-The general form of a simple port forwarding rule in -/etc/shorewall/rules is:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -DNAT -net -loc:<server local ip address> [:<server -port>] -<protocol> -<port> -- -
Example 1 - you run a Web Server on computer 2 and you want to -forward -incoming TCP port 80 to that system:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -DNAT -net -loc:10.10.10.2 -tcp -80 -- -
Example 2 - you run an FTP Server on computer 1 so you want to -forward -incoming TCP port 21 to that system:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -DNAT -net -loc:10.10.10.1 -tcp -21 -
-- -
For FTP, you will also need to have FTP connection tracking and NAT
-support
-in your kernel. For vendor-supplied kernels, this means that the
-ip_conntrack_ftp
-and ip_nat_ftp modules must be loaded. Shorewall will automatically
-load
-these modules if they are available and located in the standard place
-under
-/lib/modules/<kernel version>/kernel/net/ipv4/netfilter.
-
A couple of important points to keep in mind:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -DNAT -net -loc:10.10.10.2:80 -tcp -5000 -- -
- At this point, modify /etc/shorewall/rules to
-add any DNAT rules that you require.
Normally, when you connect to your ISP, as part of -getting an IP address your firewall's Domain Name Service (DNS) -resolver will be automatically configured (e.g., the /etc/resolv.conf -file will be written). Alternatively, your ISP may have given you -the IP address of a pair of DNS name servers for you to -manually configure as your primary and secondary name servers. -Regardless -of how DNS gets configured on your firewall, it is your -responsibility to configure the resolver in your internal systems. You -can take -one of two approaches:
-You can configure your internal systems to use your -ISP's name servers. If you ISP gave you the addresses of their servers -or if those addresses are available on their web site, you can -configure your internal systems to use those addresses. If that -information isn't available, look in /etc/resolv.conf on your -firewall system -- the name servers are given in "nameserver" records -in that file.
- You can configure a Caching Name
-Server on your firewall. Red Hat has an RPM for a caching
-name server (the RPM also requires the 'bind' RPM) and for Bering
-users, there is dnscache.lrp. If you take this approach, you configure
-your internal systems to use the firewall itself as their primary (and
-only) name server. You use the internal IP address of the firewall
-(10.10.10.254 in the example above) for the name server address. To
-allow your local systems to talk to your caching name server, you
-must open port 53 (both UDP and TCP) from the local network to the
-firewall; you do that by adding the following rules in
-/etc/shorewall/rules.
--- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- -ACCEPT -loc -fw -tcp -53 -- - - - -ACCEPT -loc -fw -udp -53 -- -
The two-interface sample includes the following rules:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- -ACCEPT -fw -net -tcp -53 -- - - - -ACCEPT -fw -net -udp -53 -- -
Those rules allow DNS access from your firewall and may -be removed if you uncommented the line in /etc/shorewall/policy -allowing all connections from the firewall to the internet.
-The sample also includes:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -ACCEPT -loc -fw -tcp -22 -- -
That rule allows you to run an SSH server on your -firewall and connect to that server from your local systems.
-If you wish to enable other connections between your -firewall and other systems, the general format is:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -ACCEPT -<source zone> -<destination zone> -<protocol> -<port> -- -
Example - You want to run a Web Server on your firewall -system:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- -ACCEPT -net -fw -tcp -80 -#Allow web access -from the internet -- - -ACCEPT -loc -fw -tcp -80 -#Allow web access -from the local network -
Those two rules would of course be in addition to the -rules listed above under "You can configure a Caching Name Server -on your firewall"
-If you don't know what port and protocol a particular -application uses, look here.
-Important: I don't recommend enabling telnet -to/from the internet because it uses clear text (even for login!). -If you want shell access to your firewall from the internet, -use SSH:
---- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- - -ACCEPT -net -fw -tcp -22 -- -
Bering users will want to
-add the following two rules to be
-compatible with Jacques's Shorewall configuration.
--- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIGINAL ADDRESS -- -ACCEPT -loc -
-fw -udp -
-53 -
-#Allow DNS Cache to -work -
-- - -ACCEPT -loc -fw -tcp -80 -#Allow weblet to work --
-
-
- Now edit your /etc/shorewall/rules file to add or
-delete other connections as required.
The installation
-procedure configures your system to start Shorewall at system
-boot but
-beginning with Shorewall version 1.3.9 startup is disabled so that
-your system won't try to start Shorewall before configuration is
-complete.
-Once you have completed configuration of your firewall, you can enable
-Shorewall startup by removing the file /etc/shorewall/startup_disabled.
-
IMPORTANT: Users of the .deb package must edit
-/etc/default/shorewall and set 'startup=1'.
-
The firewall is started using the "shorewall start" -command and stopped using "shorewall stop". When the firewall is -stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. -A running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from your -Netfilter configuration, use "shorewall clear".
- The two-interface sample assumes that
-you want
-to enable routing to/from eth1 (the local network) when
-Shorewall is stopped. If your local network isn't connected to eth1
-or if you wish to enable access to/from other hosts, change
-/etc/shorewall/routestopped accordingly.
WARNING: If you are connected to your firewall
-from the internet, do not issue a "shorewall stop" command unless you
-have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped.
-Also, I don't recommend using "shorewall restart"; it is better
-to create an alternate
-configuration and test it using the "shorewall try" command.
-
Last updated 11/15/2003 - Tom Eastep
- - -