From bf741d1fc535a62ac11cb3c45e7fbaff22e3fda2 Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Sat, 13 Dec 2003 06:10:36 +0000 Subject: [PATCH] DocBook XML conversion git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@839 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/Documentation.xml | 4512 ++++++++++++++++++++++++++++++ 1 file changed, 4512 insertions(+) create mode 100644 Shorewall-docs/Documentation.xml diff --git a/Shorewall-docs/Documentation.xml b/Shorewall-docs/Documentation.xml new file mode 100644 index 000000000..d4f3eb016 --- /dev/null +++ b/Shorewall-docs/Documentation.xml @@ -0,0 +1,4512 @@ + + +
+ + Shorewall 1.4 Reference + + + + Tom + + Eastep + + + + + 2001 + + 2002 + + 2003 + + Thomas M. Eastep + + + 2003-12-08 + + + This documentation is intended primarily for reference. + Step-by-step instructions for configuring Shorewall in common setups may + be found in the QuickStart + Guides. + + + +
+ Components + + Shorewall consists of the following components: + + + + params + + + a parameter file installed in /etc/shorewall that can be used + to establish the values of shell variables for use in other files. + + + + + shorewall.conf + + + a parameter file installed in /etc/shorewall that is used to + set several firewall parameters. + + + + + zones + + + a parameter file installed in /etc/shorewall that defines a + network partitioning into "zones" + + + + + policy + + + a parameter file installed in /etc/shorewall/ that establishes + overall firewall policy. + + + + + rules + + + a parameter file installed in /etc/shorewall and used to + express firewall rules that are exceptions to the high-level + policies established in /etc/shorewall/policy. + + + + + blacklist + + + a parameter file installed in /etc/shorewall and used to list + blacklisted IP/subnet/MAC addresses. + + + + + ecn + + + a parameter file installed in /etc/shorewall and used to + selectively disable Explicit Congestion Notification (ECN - RFC + 3168). + + + + + functions + + + a set of shell functions used by both the firewall and + shorewall shell programs. Installed in /etc/shorewall prior to + version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 and in + /usr/lib/shorewall in later versions. + + + + + modules + + + a parameter file installed in /etc/shorewall and that + specifies kernel modules and their parameters. Shorewall will + automatically load the modules specified in this file. + + + + + tos + + + a parameter file installed in /etc/shorewall that is used to + specify how the Type of Service (TOS) field in packets is to be set. + + + + + common.def + + + a parameter file installed in in /etc/shorewall that defines + firewall-wide rules that are applied before a DROP or REJECT policy + is applied. + + + + + init.sh + + + a shell script installed in /etc/init.d to automatically start + Shorewall during boot. + + + + + interfaces + + + a parameter file installed in /etc/shorewall/ and used to + describe the interfaces on the firewall system. + + + + + hosts + + + a parameter file installed in /etc/shorewall/ and used to + describe individual hosts or subnetworks in zones. + + + + + maclist + + + a parameter file installed in /etc/shorewall and used to + verify the MAC address (and possibly also the IP address(es)) of + devices. + + + + + masq + + + This file also describes IP masquerading under Shorewall and + is installed in /etc/shorewall. + + + + + firewall + + + a shell program that reads the configuration files in + /etc/shorewall and configures your firewall. This file is installed + in /usr/share/shorewall. + + + + + nat + + + a parameter file in /etc/shorewall used to define one-to-one NAT. + + + + + proxyarp + + + a parameter file in /etc/shorewall used to define Proxy Arp. + + + + + rfc1918 + + + a parameter file in /etc/shorewall used to define the + treatment of packets under the norfc1918 + interface option. + + + + + routestopped + + + a parameter file in /etc/shorewall used to define those hosts + that can access the firewall when Shorewall is stopped. + + + + + tcrules + + + a parameter file in /etc/shorewall used to define rules for + classifying packets for Traffic + Shaping/Control. + + + + + tunnels + + + a parameter file in /etc/shorewall used to define IPSec + tunnels. + + + + + shorewall + + + a shell program (requiring a Bourne shell or derivative) used + to control and monitor the firewall. This should be placed in /sbin + or in /usr/sbin (the install.sh script and the rpm install this file + in /sbin). + + + + + accounting + + + a parameter file in /etc/shorewall used to define traffic + accounting rules. This file was added in version 1.4.7. + + + + + version + + + a file created in /etc/shorewall/ (/var/lib/shorewall in + version 1.3.2-1.3.8 and /usr/lib/shorewall beginning in version + 1.3.9) that describes the version of Shorewall installed on your + system. + + + + + users and usersets + + + files in /etc/shorewall allowing connections originating on + the firewall to be policed by the user id and/or group id of the + user. + + + + + actions and action.template + + + files in /etc/shorewall that allow you to define your own + actions for rules in /etc/shorewall/rules. + + + +
+ +
+ /etc/shorewall/params + + You may use the file /etc/shorewall/params file to set shell + variables that you can then use in some of the other configuration files. + + It is suggested that variable names begin with an upper case letter + to distinguish them from variables used internally within the Shorewall + programs + + + shell variables + + NET_IF=eth0 +NET_BCAST=130.252.100.255 +NET_OPTIONS=blacklist,norfc1918 + + + + /etc/shorewall/interfaces record + + net $NET_IF $NET_BCAST $NET_OPTIONS + + + The result will be the same as if the record had been written + + net eth0 130.252.100.255 blacklist,norfc1918 + + Variables may be used anywhere in the other configuration files. +
+ +
+ /etc/shorewall/zones + + This file is used to define the network zones. There is one entry in + /etc/shorewall/zones for each zone; Columns in an entry are: + + + + ZONE + + + short name for the zone. The name should be 5 characters or + less in length (4 characters or less if you are running Shorewall + 1.4.4 or later) and consist of lower-case letters or numbers. Short + names must begin with a letter and the name assigned to the firewall + is reserved for use by Shorewall itself. Note that the output + produced by iptables is much easier to read if you select short + names that are three characters or less in length. The name + "all" may not be used as a zone name nor may the zone name + assigned to the firewall itself via the FW variable in . + + + + + DISPLAY + + + The name of the zone as displayed during Shorewall startup. + + + + + COMMENTS + + + Any comments that you want to make about the zone. Shorewall + ignores these comments. + + + + + + /etc/shorewall/zones file released with Shorewall + + + + + ZONE + + DISPLAY + + COMMENTS + + + + + + net + + Net + + Internet + + + + loc + + Local + + Local networks + + + + dmz + + DMZ + + Demilitarized zone + + + +
+ + You may add, delete and modify entries in the /etc/shorewall/zones + file as desired so long as you have at least one zone defined. + + + If you rename or delete a zone, you should perform "shorewall + stop; shorewall start" to install the change rather than + "shorewall restart". + + + + The order of entries in the /etc/shorewall/zones file is + significant in some cases. + +
+ +
+ /etc/shorewall/interfaces + + This file is used to tell the firewall which of your firewall's + network interfaces are connected to which zone. There will be one entry in + /etc/shorewall/interfaces for each of your interfaces. Columns in an entry + are: + + + + ZONE + + + A zone defined in the file or + "-". If you specify "-", you must use the file to define the zones accessed via this + interface. + + + + + INTERFACE + + + the name of the interface (examples: eth0, ppp0, ipsec+). Each + interface can be listed on only one record in this file. + + + DO NOT INCLUDE THE LOOPBACK INTERFACE + (lo) IN THIS FILE!!! + + + + + + BROADCAST + + + the broadcast address(es) for the sub-network(s) attached to + the interface. This should be left empty for P-T-P interfaces (ppp*, + ippp*); if you need to specify options for such an interface, enter + "-" in this column. If you supply the special value + "detect" in this column, the firewall will automatically + determine the broadcast address. In order to use "detect": + + + + the interface must be up before you start your firewall + + + + the interface must only be attached to a single + sub-network (i.e., there must have a single broadcast address). + + + + + + + OPTIONS + + + a comma-separated list of options. Possible options include: + + + + arp_filter + + + (Added in version 1.4.7) - This option causes + /proc/sys/net/ipv4/conf/<interface>/arp_filter to be + set with the result that this interface will only answer ARP + 'who-has' requests from hosts that are routed out of + that interface. Setting this option facilitates testing of + your firewall where multiple firewall interfaces are connected + to the same HUB/Switch (all interface connected to the single + HUB/Switch should have this option specified). Note that using + such a configuration in a production environment is strongly + recommended against. + + + + + newnotsyn + + + (Added in version 1.4.6) - This option overrides NEWNOTSYN=No for packets arriving on + this interface. In other words, packets coming in on this + interface are processed as if NEWNOTSYN=Yes had been specified + in . + + + + + routeback + + + (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets that arrive on this + interface back out the same interface. If this option is + specified, the ZONE column may not contain "-". + + + + + tcpflags + + + (added in version 1.3.11) - This option causes Shorewall + to make sanity checks on the header flags in TCP packets + arriving on this interface. Checks include Null flags, + SYN+FIN, SYN+RST and FIN+URG+PSH; these flag combinations are + typically used for "silent" port scans. Packets + failing these checks are logged according to the + TCP_FLAGS_LOG_LEVEL option in and are + disposed of according to the TCP_FLAGS_DISPOSITION option. + + + + + blacklist + + + This option causes incoming packets on this interface to + be checked against the blacklist. + + + + + dhcp + + + The interface is assigned an IP address via DHCP or is + used by a DHCP server running on the firewall. The firewall + will be configured to allow DHCP traffic to and from the + interface even when the firewall is stopped. You may also wish + to use this option if you have a static IP but you are on a + LAN segment that has a lot of Laptops that use DHCP and you + select the norfc1918 option + (see below). + + + + + norfc1918 + + + Packets arriving on this interface and that have a + source address that is reserved in RFC 1918 or in other RFCs + will be dropped after being optionally logged. If packet mangling is enabled in + /etc/shorewall/shorewall.conf , then packets arriving + on this interface that have a destination address that is + reserved by one of these RFCs will also be logged and dropped. + + Addresses blocked by the standard rfc1918 file include those addresses + reserved by RFC1918 plus other ranges reserved by the IANA or + by other RFCs. + + Beware that as IPv4 addresses become in increasingly + short supply, ISPs are beginning to use RFC 1918 addresses + within their own infrastructure. Also, many cable and DSL + "modems" have an RFC 1918 address that can be used + through a web browser for management and monitoring functions. + If you want to specify norfc1918 + on your external interface but need to allow access to certain + addresses from the above list, see FAQ + 14. + + + + + routefilter + + + Invoke the Kernel's route filtering (anti-spoofing) + facility on this interface. The kernel will reject any packets + incoming on this interface that have a source address that + would be routed outbound through another interface on the + firewall. + + + If you specify this option for an interface then the + interface must be up prior to starting the firewall. + + + + + + dropunclean + + + Packets from this interface that are selected by the + 'unclean' match target in iptables will be optionally + logged and then dropped. + + + This feature requires that UNCLEAN match support be + configured in your kernel, either in the kernel itself or as + a module. UNCLEAN support is broken in some versions of the + kernel but appears to work ok in 2.4.17-rc1. + + Update 12/17/2001: + The unclean match patch from 2.4.17-rc1 is available + for download. I am currently running this patch + applied to kernel 2.4.16. + + Update 12/20/2001: + I've seen a number of tcp connection requests with OPT + (020405B40000080A...) being + dropped in the badpkt chain. This + appears to be a bug in the remote TCP stack whereby it is + 8-byte aligning a timestamp (TCP option 8) but rather than + padding with 0x01 it is padding with 0x00. It's a tough + call whether to deny people access to your servers because + of this rather minor bug in their networking software. If + you wish to disable the check that causes these connections + to be dropped, here's + a kernel patch against 2.4.17-rc2. + + + + + + logunclean + + + This option works like dropunclean + with the exception that packets selected by the + 'unclean' match target in iptables are logged + but not dropped. The level at which the + packets are logged is determined by the setting of LOGUNCLEAN + and if LOGUNCLEAN has not been set, "info" is assumed. + + + + + proxyarp + + + (Added in version 1.3.5) - This option causes Shorewall + to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp + and is used when implementing Proxy ARP Sub-netting as + described at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. + Do not set this option if you + are implementing Proxy ARP through entries in . + + + + + maclist + + + (Added in version 1.3.10) - If this option is specified, + all connection requests from this interface are subject to + MAC Verification. May + only be specified for ethernet interfaces. + + + + + My recommendations concerning options: + + + + External Interface -- tcpflags,blacklist,norfc1918,routefilter + + + + Wireless Interface -- maclist,routefilter,tcpflags + + + + Don't use dropunclean + -- It's broken in my opinion + + + + Use logunclean only when + you are trying to debug a problem + + + + Use dhcp and proxyarp when needed. + + + + + + + + You have a conventional firewall setup in which eth0 connects to + a Cable or DSL modem and eth1 connects to your local network and eth0 + gets its IP address via DHCP. You want to check all packets entering + from the internet against the <link linkend="Blacklist">black list</link>. + Your /etc/shorewall/interfaces file would be as follows: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + net + + eth0 + + detect + + dhcp,norfc1918,blacklist + + + + loc + + eth1 + + detect + + + + + + + + + + You have a standalone dialup GNU/Linux System. Your + /etc/shorewall/interfaces file would be: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + net + + ppp0 + + + + + + + + + + + + You have local interface eth1 with two IP addresses - + 192.168.1.1/24 and 192.168.12.1/24 + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + loc + + eth1 + + 192.168.1.255,192.168.12.255 + + + + + + + +
+ +
+ /etc/shorewall/hosts Configuration + + For most applications, specifying zones entirely in terms of network + interfaces is sufficient. There may be times though where you need to + define a zone to be a more general collection of hosts. This is the + purpose of the /etc/shorewall/hosts file. + + + The only times that you need entries in /etc/shorewall/hosts are: + + + + You have more than one zone connecting through a single + interface; or + + + + You have a zone that has multiple subnetworks that connect + through a single interface and you want the Shorewall box to route + traffic between those subnetworks. + + + + IF YOU DON'T HAVE EITHER OF THOSE + SITUATIONS THEN DON'T TOUCH THIS FILE!! + + + Columns in this file are: + + + + ZONE + + + A zone defined in the file. + + + + + HOST(S) + + + The name of a network interface followed by a colon + (":") followed by a comma-separated list either: + + + + An IP address (example - eth1:192.168.1.3) + + + + A subnet in CIDR notation (example - eth2:192.168.2.0/24) + + + + The interface name much match an entry in + /etc/shorewall/interfaces. + + + If you are running a version of Shorewall earlier than + 1.4.6, only a single host/subnet address may be specified in an + entry in /etc/shorewall/hosts. + + + + + + OPTIONS + + + A comma-separated list of option + + + + routeback + + + (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets sent by this host group + back back to the same group. + + + + + maclist + + + Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to + MAC Verification. + This option is only valid for ethernet interfaces. + + + + + + + + If you don't define any hosts for a zone, the hosts in the zone + default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the + interfaces to the zone. + + + You probably DON'T want to specify any hosts for your internet + zone since the hosts that you specify will be the only ones that you + will be able to access without adding additional rules. + + + + Your local interface is eth1 and you have two groups of local + hosts that you want to make into separate zones: + + 192.168.1.0/25 +192.168.1.128/ + + Your /etc/shorewall/interfaces file might look like: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + net + + eth0 + + detect + + dhcp,norfc1918 + + + + - + + eth1 + + 192.168.1.127,192.168.1.255 + + + + + + + + The '-' in the ZONE column for eth1 tells Shorewall that + eth1 interfaces to multiple zones. + + + + + + ZONE + + HOST(S) + + OPTIONS + + + + + + loc1 + + eth1:192.168.1.0/25 + + + + + + loc2 + + eth1:192.168.1.128/25 + + + + + + + + + + You have local interface eth1 with two IP addresses - + 192.168.1.1/24 and 192.168.12.1/24 + + 192.168.1.0/25 +192.168.1.128/25 + + Your /etc/shorewall/interfaces file might look like: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + net + + eth0 + + detect + + dhcp,norfc1918 + + + + loc + + eth1 + + 192.168.1.127,192.168.1.255 + + + + + + + + Your /etc/shorewall/hosts file might look like: + + + + + + ZONE + + HOST(S) + + OPTIONS + + + + + + loc + + eth1:192.168.1.0/25 + + + + + + loc + + eth1:192.168.1.128/25 + + + + + + + + If you are running Shorewall 1.4.6 or later, your hosts file may + look like: + + + + + + ZONE + + HOST(S) + + OPTIONS + + + + + + loc + + eth1:192.168.1.0/25,192.168.1.128/25 + + + + + + + + +
+ Nested and Overlapping Zones + + The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow + you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that they appear + in the /etc/shorewall/zones file. So if you have nested zones, you want + the sub-zone to appear before the super-zone and in the case of + overlapping zones, the rules that will apply to hosts that belong to + both zones is determined by which zone appears first in + /etc/shorewall/zones. + + Hosts that belong to more than one zone may be managed by the + rules of all of those zones. This is done through use of the special + CONTINUE policy described below. +
+
+ +
+ /etc/shorewall/policy Configuration + + This file is used to describe the firewall policy regarding + establishment of connections. Connection establishment is described in + terms of clients who initiate connections and + servers who receive those connection requests. + Policies defined in /etc/shorewall/policy describe which zones are allowed + to establish connections with other zones. + + Policies established in /etc/shorewall/policy can be viewed as + default policies. If no rule in /etc/shorewall/rules applies to a + particular connection request then the policy from /etc/shorewall/policy + is applied. + + Four policies are defined: + + + + ACCEPT + + + The connection is allowed. + + + + + DROP + + + The connection request is ignored. + + + + + REJECT + + + The connection request is rejected with an RST (TCP) or an + ICMP destination-unreachable packet being returned to the client. + + + + + CONTINUE + + + The connection is neither ACCEPTed, DROPped nor REJECTed. + CONTINUE may be used when one or both of the zones named in the + entry are sub-zones of or intersect with another zone. For more + information, see below. + + + + + NONE + + + (Added in version 1.4.1) - Shorewall should not set up any + infrastructure for handling traffic from the SOURCE zone to the DEST + zone. When this policy is specified, the LOG + LEVEL and BURST:LIMIT + columns must be left blank. + + + + + For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that the policy + is applied. + + Entries in /etc/shorewall/policy have four columns as follows: + + + + SOURCE + + + The name of a client zone (a zone defined in the file , the name of the + firewall zone or "all"). + + + + + DEST + + + The name of a destination zone (a zone defined in the file , the name of the + firewall zone or "all"). Shorewall automatically + allows all traffic from the firewall to itself so the name of the firewall zone cannot appear in + both the SOURCE and DEST columns. + + + + + POLICY + + + The default policy for connection requests from the SOURCE + zone to the DESTINATION zone. + + + + + LOG LEVEL + + + Optional. If left empty, no log message is generated when the + policy is applied. Otherwise, this column should contain an integer + or name indicating a syslog + level. + + + + + LIMIT:BURST - optional + + + If left empty, TCP connection requests from the SOURCE zone to the DEST + zone will not be rate-limited. Otherwise, this column specifies the + maximum rate at which TCP connection requests will be accepted + followed by a colon (":") followed by the maximum burst size + that will be tolerated. Example: 10/sec:40 + specifies that the maximum rate of TCP connection requests allowed + will be 10 per second and a burst of 40 connections will be + tolerated. Connection requests in excess of these limits will be + dropped. See the rules file documentation + for an explaination of how rate limiting works. + + + + + In the SOURCE and DEST columns, you can enter "all" to + indicate all zones. + + + policy file installed by default + + + + + SOURCE + + DEST + + POLICY + + LOG LEVEL + + LIMIT:BURST + + + + + + loc + + net + + ACCEPT + + + + + + + + net + + all + + DROP + + info + + + + + + all + + all + + REJECT + + info + + + + + +
+ + This table may be interpreted as follows: + + + + All connection requests from the local network to hosts on the + internet are accepted. + + + + All connection requests originating from the internet are + ignored and logged at level KERNEL.INFO. + + + + All other connection requests are rejected and logged. + + + + + The firewall script processes the /etc/shorewall/policy file from + top to bottom and uses the first applicable policy + that it finds. For example, in the following policy file, the + policy for (loc, loc) connections would be ACCEPT as specified in the + first entry even though the third entry in the file specifies REJECT. + + + + + + SOURCE + + DEST + + POLICY + + LOG LEVEL + + LIMIT:BURST + + + + + + loc + + all + + ACCEPT + + + + + + + + net + + all + + DROP + + info + + + + + + loc + + loc + + REJECT + + info + + + + + + + + +
+ IntraZone Traffic + + Shorewall allows a zone to be associated with more than one + interface or with multiple networks that interface through a single + interface. Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all + traffic from a zone to itself provided that there is no explicit policy + governing traffic from that zone to itself (an explicit policy does not + specify "all" in either the SOURCE or DEST column) and that + there are no rules concerning connections from that zone to itself. If + there is an explicit policy or if there are one or more rules, then + traffic within the zone is handled just like traffic between zones is. + + Any time that you have multiple interfaces associated with a + single zone, you should ask yourself if you really want traffic routed + between those interfaces. Cases where you might not want that behavior + are: + + + + Multiple 'net' interfaces to different ISPs. You + don't want to route traffic from one ISP to the other through + your firewall. + + + + Multiple VPN clients. You don't necessarily want them to + all be able to communicate between themselves using your + gateway/router. + + +
+ +
+ The CONTINUE policy + + Where zones are nested or overlapping, + the CONTINUE policy allows hosts that are within multiple zones to be + managed under the rules of all of these zones. Let's look at an + example: + + + /etc/shorewall/zones + + + + + ZONE + + DISPLAY + + COMMENTS + + + + + + sam + + Sam + + Sam's system at home + + + + net + + Internet + + The Internet + + + + loc + + Loc + + Local Network + + + +
+ + + /etc/shorewall/interfaces + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + - + + eth0 + + detect + + dhcp,norfc1918 + + + + loc + + eth1 + + detect + + + + + +
+ + + /etc/shorewall/hosts + + + + + ZONE + + HOST(S) + + OPTIONS + + + + + + net + + eth0:0.0.0.0/0 + + + + + + sam + + eth0:206.191.149.197 + + + + + +
+ + + Sam's home system is a member of both the sam zone and the net + zone and as described above , that means + that sam must be listed before + net in /etc/shorewall/zones. + + + + /etc/shorewall/policy + + + + + SOURCE + + DEST + + POLICY + + LOG LEVEL + + + + + + loc + + net + + ACCEPT + + + + + + sam + + all + + CONTINUE + + + + + + net + + all + + DROP + + info + + + + all + + all + + REJECT + + info + + + +
+ + The second entry above says that when Sam is the client, + connection requests should first be process under rules where the source + zone is sam and if there is no match + then the connection request should be treated under rules where the + source zone is net. It is important + that this policy be listed BEFORE the next policy (net + to all). + + + Partial /etc/shorewall/rules + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ... + + + + + + + + + + + + + + + + + + + + DNAT + + sam + + loc:192.168.1.3 + + tcp + + ssh + + - + + + + + + + + + + DNAT + + net + + loc:192.168.1.5 + + tcp + + www + + - + + + + + + + + + + ... + + + + + + + + + + + + + + + + + + + +
+ + Given these two rules, Sam can connect to the firewall's + internet interface with ssh and the connection request will be forwarded + to 192.168.1.3. Like all hosts in the net + zone, Sam can connect to the firewall's internet interface on TCP + port 80 and the connection request will be forwarded to 192.168.1.5. The + order of the rules is not significant. + + Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can SSH to the + firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects + to the firewall's external IP, he should be connected to the + firewall itself. Because of the way that Netfilter is constructed, this + requires two rules as follows: + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ... + + + + + + + + + + + + + + + + + + + + DNAT + + sam + + fw + + tcp + + ssh + + - + + + + + + + + + + DNAT + + net!sam + + loc:192.168.1.3 + + tcp + + ssh + + - + + + + + + + + + + ... + + + + + + + + + + + + + + + + + + + + + + The first rule allows Sam SSH access to the firewall. The second + rule says that any clients from the net zone with the exception of those + in the 'sam' zone should have their connection port forwarded to + 192.168.1.3. If you need to exclude more than one zone in this way, you + can list the zones separated by commas (e.g., net!sam,joe,fred). This + technique also may be used when the ACTION is REDIRECT. +
+
+ +
+ /etc/shorewall/rules + + The /etc/shorewall/rules file defines exceptions to the policies + established in the /etc/shorewall/policy file. There is one entry in + /etc/shorewall/rules for each of these rules. + + Shorewall automatically enables firewall->firewall traffic over + the loopback interface (lo) -- that traffic cannot be regulated using + rules and any rule that tries to regulate such traffic will generate a + warning and will be ignored. + + Entries in the file have the following columns: + + + + ACTION + + + + + ACCEPT, DROP, REJECT, CONTINUE + + + These have the same meaning here as in the policy file + above. + + + + + DNAT + + + Causes the connection request to be forwarded to the + system specified in the DEST column (port forwarding). + "DNAT" stands for "Destination + Network Address + Translation" + + + + + DNAT- + + + The above ACTION (DNAT) generates two iptables rules: + + + + a header-rewriting rule in the Netfilter + 'nat' table + + + + an ACCEPT rule in the Netfilter 'filter' + table. DNAT- works like DNAT but only generates the + header-rewriting rule. + + + + + + + REDIRECT + + + Causes the connection request to be redirected to a port + on the local (firewall) system. + + + + + REDIRECT- + + + The above ACTION (REDIRECT) generates two iptables + rules: + + + + a header-rewriting rule in the Netfilter + 'nat' table + + + + an ACCEPT rule in the Netfilter 'filter' + table. REDIRECT- works like REDIRECT but only generates + the header-rewriting rule. + + + + + + + LOG + + + Log the packet -- requires a syslog level (see below). + + + + + QUEUE + + + Forward the packet to a user-space application. This + facility is provided to allow interfacing to ftwall for Kazaa filtering. + + + When the protocol specified in the PROTO column is TCP + ("tcp", "TCP" or "6"), Shorewall + will only pass connection requests (SYN packets) to user + space. This is for compatibility with ftwall. + + + + + + <user-defined + action> + + + (Shorewall 1.4.9 and later) + + + + + Beginning with Shorewall version 1.4.7, you may rate-limit the + rule by optionally following ACCEPT, DNAT[-], REDIRECT[-] or LOG + with + + < <rate>/<interval>[:<burst>] > + + where <rate> is the number of connections per + <interval> ("sec" or "min") and + <burst> is the largest burst permitted. If no burst value is + given, a value of 5 is assumed. + + There may be no whitespace embedded in the specification. + + + rate-limit + + ACCEPT<2/sec:4> net dmz tcp 80 + + The first time this rule is reached, the packet will be + accepted; in fact, since the burst is 4, the first four packets + will be accepted. After this, it will be 500ms (1 second divided + by the rate of 2) before a packet will be accepted from this rule, + regardless of how many packets reach it. Also, every 500ms which + passes without matching a packet, one of the bursts will be + regained; if no packets hit the rule for 2 second, the burst will + be fully recharged; back where we started. + + + + When rate limiting is specified on a rule with "all" + in the SOURCE or DEST fields below, the limit will apply to each + pair of zones individually rather than as a single limit for all + pairs of zones covered by the rule. + + + Rate limiting may also be specified in the RATE LIMIT column + below; in that case, it must not be specified as part of the ACTION + column. + + The ACTION (and rate limit) may optionally be followed by + ":" and a syslog level + (example: REJECT:info or ACCEPT<2/sec:4>:debugging). This + causes the packet to be logged at the specified level prior to being + processed according to the specified ACTION. Note: if the ACTION is + LOG then you MUST specify a syslog level. + + The use of DNAT or REDIRECT requires that you have NAT + enabled. + + + + + SOURCE + + + Describes the source hosts to which the rule applies.. The + contents of this field must begin with the name of a zone defined in + /etc/shorewall/zones, $FW or "all". If the ACTION is DNAT or + REDIRECT, sub-zones may be excluded from the rule by following the + initial zone name with "!' and a comma-separated list of + those sub-zones to be excluded. There is an example + above. + + If the source is not 'all' then the source may be + further restricted by adding a colon (":") followed by a + comma-separated list of qualifiers. Qualifiers are may include: + + + + interface name + + + refers to any connection requests arriving on the + specified interface (example loc:eth4). Beginning with + Shorwall 1.3.9, the interface name may optionally be followed + by a colon (":") and an IP address or subnet + (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24). + + + + + IP address + + + refers to a connection request from the host with the + specified address (example net:155.186.235.151). If the ACTION + is DNAT, this must not be a DNS name. + + + + + MAC Address + + + in Shorewall + format. + + + + + subnet + + + refers to a connection request from any host in the + specified subnet (example net:155.186.235.0/24). + + + + + + + + DEST + + + Describes the destination host(s) to which the rule applies. + May take most of the forms described above for SOURCE plus the + following two additional forms: + + + + An IP address followed by a colon and the port number that the server is listening on + (service names from /etc/services are not allowed - example + loc:192.168.1.3:80). + + + + A single port number (again, service names are not + allowed) -- this form is only allowed if the ACTION is REDIRECT + and refers to a server running on the firewall itself and + listening on the specified port. + + + + Restrictions: + + + + MAC addresses may not be specified. + + + + In DNAT rules, only IP addresses may be given -- DNS names + are not permitted. + + + + You may not specify both an IP address and an interface + name in the DEST column. + + + + Unlike in the SOURCE column, a range of IP addresses may be + specified in the DEST column as <first address>-<last + address>. When the ACTION is DNAT or DNAT-, + connections will be assigned to the addresses in the range in a + round-robin fashion (load-balancing). This + feature is available with DNAT rules only with Shorewall 1.4.6 and + later versions; it is available with DNAT- rules in all versions + that support DNAT-. + + + + + PROTO + + + Protocol. Must be a protocol name from /etc/protocols, a + number or "all". Specifies the protocol of the connection + request. + + + + + DEST PORT(S) + + + Port or port range (<low port>:<high port>) + being connected to. May only be specified if the protocol is tcp, + udp or icmp. For icmp, this column's contents are interpreted as + an icmp type. If you don't want to specify DEST PORT(S) but need + to include information in one of the columns to the right, enter + "-" in this column. You may give a list of ports and/or port + ranges separated by commas. Port numbers may be either integers or + service names from /etc/services. + + + + + SOURCE PORTS(S) + + + May be used to restrict the rule to a particular client port + or port range (a port range is specified as <low port + number>:<high port number>). If you don't want to + restrict client ports but want to specify something in the next + column, enter "-" in this column. If you wish to specify a + list of port number or ranges, separate the list elements with + commas (with no embedded white space). Port numbers may be either + integers or service names from /etc/services. + + + + + ORIGINAL DEST + + + This column may only be non-empty if the ACTION is DNAT or + REDIRECT. + + If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column + is left empty, any connection request arriving at the firewall from + the SOURCE that matches the rule will be forwarded or redirected. + This works fine for connection requests arriving from the internet + where the firewall has only a single external IP address. When the + firewall has multiple external IP addresses or when the SOURCE is + other than the internet, there will usually be a desire for the rule + to only apply to those connection requests directed to particular IP + addresses (see Example 2 below for another usage). Those IP + addresses are specified in the ORIGINAL DEST column as a + comma-separated list. + + The IP address(es) may be optionally followed by ":" + and a second IP address. This latter address, if present, is used as + the source address for packets forwarded to the server (This is + called "Source NAT" or SNAT. + + If this list begins with "!" then the rule will only + apply if the original destination address matches none of the + addresses listed. + + + When using SNAT, it is a good idea to qualify the source + with an IP address or subnet. Otherwise, it is likely that SNAT + will occur on connections other than those described in the rule. + The reason for this is that SNAT occurs in the Netfilter + POSTROUTING hook where it is not possible to restrict the scope of + a rule by incoming interface. + + + + + DNAT loc:192.168.1.0/24 loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3 + + + + If SNAT is not used (no ":" and second IP address), + the original source address is used. If you want any destination + address to match the rule but want to specify SNAT, simply use a + colon followed by the SNAT address. + + + + + RATE LIMIT + + + Beginning with Shorewall version 1.4.7, you may rate-limit + ACCEPT, DNAT[-], REDIRECT[-] or LOG rules with an entry in this + column. Entries have the form + + <rate>/<interval>[:<burst>] + + where <rate> is the number of connections per + <interval> ("sec" or "min") and + <burst> is the largest burst permitted. If no burst value is + given, a value of 5 is assumed. + + There may be no whitespace embedded in the specification. + + + Let's take + + ACCEPT<2/sec:4> net dmz tcp 80 + + The first time this rule is reached, the packet will be + accepted; in fact, since the burst is 4, the first four packets + will be accepted. After this, it will be 500ms (1 second divided + by the rate of 2) before a packet will be accepted from this rule, + regardless of how many packets reach it. Also, every 500ms which + passes without matching a packet, one of the bursts will be + regained; if no packets hit the rule for 2 second, the burst will + be fully recharged; back where we started. + + + + When rate limiting is specified on a rule with "all" + in the SOURCE or DEST fields below, the limit will apply to each + pair of zones individually rather than as a single limit for all + pairs of zones covered by the rule. + + + Rate limiting may also be specified in the ACTION column + above; in that case, it must not be specified as part of the RATE + LIMIT column. + + If you want to specify any following columns but no rate + limit, place "-" in this column. + + + + + USER SET + + + Beginning with Shorewall release 1.4.7, output rules from the + firewall itself may be restricted to a particular set of users + and/or user groups. See the User Set Documentation for details. + + + + + + You wish to forward all ssh connection requests from the internet + to local system 192.168.1.3. You wish to limit the number of connections + to 4/minute with a burst of 8 (Shorewall 1.4.7 and later only): + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + DNAT<4/min:8> + + net + + loc:192.168.1.3 + + tcp + + ssh + + + + + + + + + + + + + + + + You want to redirect all local www connection requests EXCEPT + those to your own http server (206.124.146.177) to a Squid transparent + proxy running on the firewall and listening on port 3128. Squid will of + course require access to remote web servers. This example shows yet + another use for the ORIGINAL DEST column; here, connection requests that + were NOT (notice the "!") originally destined to 206.124.146.177 + are redirected to local port 3128. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + REDIRECT + + loc + + 3128 + + tcp + + www + + - + + !206.124.146.177 + + + + + + + + ACCEPT + + fw + + net + + tcp + + www + + + + + + + + + + + + + + + + You want to run a web server at 155.186.235.222 in your DMZ and + have it accessible remotely and locally. the DMZ is managed by Proxy ARP + or by classical sub-netting. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ACCEPT + + net + + dmz:155.186.235.222 + + tcp + + www + + - + + + + + + + + + + ACCEPT + + loc + + dmz:155.186.235.222 + + tcp + + www + + + + + + + + + + + + + + + + You want to run wu-ftpd on 192.168.2.2 in your masqueraded DMZ. + Your internet interface address is 155.186.235.151 and you want the FTP + server to be accessible from the internet in addition to the local + 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that since the + server is in the 192.168.2.0/24 subnetwork, we can assume that access to + the server from that subnet will not involve the firewall (<ulink + url="FAQ.htm#faq2">but see FAQ 2</ulink>). Note that unless you have + more than one external IP address, you can leave the ORIGINAL DEST + column blank in the first rule. You cannot leave it blank in the second + rule though because then <emphasis role="bold">all ftp connections</emphasis> + originating in the local subnet 192.168.1.0/24 would be sent to + 192.168.2.2 <emphasis role="bold">regardless of the site that the user + was trying to connect to</emphasis>. That is clearly not what you want. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + DNAT + + net + + dmz:192.168.2.2 + + tcp + + ftp + + + + + + + + + + + + DNAT + + loc:192.168.1.0/24 + + dmz:192.168.2.2 + + tcp + + ftp + + - + + 155.186.235.151 + + + + + + + + + + If you are running wu-ftpd, you should restrict the range of + passive in your /etc/ftpaccess file. I only need a few simultaneous FTP + sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry + is appropriate: + + passive ports 0.0.0.0/0 65500 65534 + + If you are running pure-ftpd, you would include "-p + 65500:65534" on the pure-ftpd runline. + + The important point here is to ensure that the port range used for + FTP passive connections is unique and will not overlap with any usage on + the firewall system. + + + + You wish to allow unlimited DMZ access to the host with MAC + address 02:00:08:E3:FA:55. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ACCEPT + + loc:~02-00-08-E3-FA-55 + + dmz + + all + + + + + + + + + + + + + + + + + + You wish to allow access to the SMTP server in your DMZ from all + zones. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ACCEPT + + all + + dmz + + tcp + + 25 + + + + + + + + + + + + + + When 'all' is used as a source or destination, + intra-zone traffic is not affected. In this example, if there were two + DMZ interfaces then the above rule would NOT enable SMTP traffic between + hosts on these interfaces. + + + + Your firewall's external interface has several IP addresses + but you only want to accept SSH connections on address 206.124.146.176. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + ACCEPT + + net + + fw:206.124.146.176 + + tcp + + 22 + + + + + + + + + + + + + + + + (For advanced users running Shorewall version 1.3.13 or later). + From the internet, you with to forward tcp port 25 directed to + 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also + want to allow access from the internet directly to tcp port 25 on + 192.0.2.177. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + DNAT- + + net + + dmz:192.0.2.177 + + tcp + + 25 + + 0 + + 192.0.2.178 + + + + + + + + DNAT- + + net + + dmz:192.0.2.177 + + tcp + + 25 + + 0 + + 192.0.2.179 + + + + + + + + ACCEPT + + net + + dmz:192.0.2.177 + + tcp + + 25 + + + + + + + + + + + + + + Using "DNAT-" rather than "DNAT" avoids two extra + copies of the third rule from being generated. + + + + (Shorewall version 1.4.6 or later). You have 9 http servers + behind a Shorewall firewall and you want connection requests to be + distributed among your servers. The servers are + 192.168.1.101-192.168.1.109. + + + + + + ACTION + + SOURCE + + DEST + + PROTO + + DEST PORT(S) + + SOURCE PORT(S) + + ORIGINAL DEST + + RATE LIMIT + + USER SET + + + + + + DNAT + + net + + loc:192.168.1.101-192.168.1.109 + + tcp + + 80 + + + + + + + + + + + + + + + Look here for information on other services. +
+ +
+ /etc/shorewall/common + + Shorewall allows definition of rules that apply between all zones. + By default, these rules are defined in the file /etc/shorewall/common.def + but may be modified to suit individual requirements. Rather than modify + /etc/shorewall/common.def, you should copy that file to + /etc/shorewall/common and modify that file. + + The /etc/shorewall/common file is expected to contain iptables + commands; rather than running iptables directly, you should run it + indirectly using the Shorewall function 'run_iptables'. That way, + if iptables encounters an error, the firewall will be safely stopped. +
+ +
+ /etc/shorewall/masq + + The /etc/shorewall/masq file is used to define classical IP + Masquerading and Source Network Address Translation (SNAT). There is one + entry in the file for each subnet that you want to masquerade. In order to + make use of this feature, you must have NAT enabled. + + Columns are: + + + + INTERFACE + + + The interface that will masquerade the subnet; this is + normally your internet interface. This interface name can be + optionally qualified by adding ":" and a subnet or host IP. + When this qualification is added, only packets addressed to that + host or subnet will be masqueraded. Beginning with Shorewall version + 1.3.14, if you have set ADD_SNAT_ALIASES=Yes in , + you can cause Shorewall to create an alias label + of the form interfacename:digit (e.g., eth0:0) + by placing that label in this column. See example 5 below. Alias + labels created in this way allow the alias to be visible to the + ipconfig utility. THAT IS THE ONLY THING THAT + THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR + SHOREWALL CONFIGURATION. + + + + + SUBNET + + + The subnet that you want to have masqueraded through the + INTERFACE. This may be expressed as a single IP address, a subnet or + an interface name. In the latter instance, the interface must be + configured and started before Shorewall is started as Shorewall will + determine the subnet based on information obtained from the + 'ip' utility. + + + When using Shorewall 1.3.13 or earlier, when an interface + name is specified, Shorewall will only masquerade traffic from the + first subnetwork on the named interface; if the interface + interfaces to more that one subnetwork, you will need to add + additional entries to this file for each of those other + subnetworks. Beginning with Shorewall 1.3.14, shorewall will + masquerade/SNAT traffic from any host that is routed through the + named interface. + + + The subnet may be optionally followed by "!' and a + comma-separated list of addresses and/or subnets that are to be + excluded from masquerading. + + + + + ADDRESS + + + The source address to be used for outgoing packets. This + column is optional and if left blank, the current primary IP address + of the interface in the first column is used. If you have a static + IP on that interface, listing it here makes processing of output + packets a little less expensive for the firewall. If you specify an + address in this column, it must be an IP address configured on the + INTERFACE or you must have ADD_SNAT_ALIASES enabled in . Beginning with Shorewall version 1.4.6, you may + include a range of IP addresses in this column to indicate that + Netfilter should use the addresses in the range in round-robin + fashion. Beginning with Shorewall version 1.4.7, you may include a + list of ranges and/or addresses in this column; again, Netfilter + will use all listed ranges/addresses in rounde-robin fashion. + + + + + + You have eth0 connected to a cable modem and eth1 connected to + your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file + would look like: + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth0 + + 192.168.9.0/24 + + + + + + + + + + You have a number of IPSEC tunnels through ipsec0 and you want to + masquerade traffic from your 192.168.9.0/24 subnet to the remote subnet + 10.1.0.0/16 only. + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + ipsec0:10.1.0.0/16 + + 192.168.9.0/24 + + + + + + + + + + You have a DSL line connected on eth0 and a local network + (192.168.10.0/24) connected to eth1. You want all local->net + connections to use source address 206.124.146.176. + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth0 + + 192.168.10.0/24 + + 206.124.146.176 + + + + + + + + Same as example 3 except that you wish to exclude 192.168.10.44 + and 192.168.10.45 from the SNAT rule. + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth0 + + 192.168.10.0/24!192.168.10.44,192.168.10.45 + + 206.124.146.176 + + + + + + + + <emphasis role="bold">(Shorewall version >= 1.3.14):</emphasis> + You have a second IP address (206.124.146.177) assigned to you and wish + to use it for SNAT of the subnet 192.168.12.0/24. You want to give that + address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <xref + linkend="Conf" />. + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth0:0 + + 192.168.12.0/24 + + 206.124.146.177 + + + + + + + + <emphasis role="bold">(Shorewall version >= 1.4.7):</emphasis> + You want to use both 206.124.146.177 and 206.124.146.179 for SNAT of the + subnet 192.168.12.0/24. Each address will be used on alternate outbound + connections. + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth0 + + 192.168.12.0/24 + + 206.124.146.177,206.124.146.179 + + + + + +
+ +
+ /etc/shorewall/proxyarp + + If you want to use proxy ARP on an entire sub-network, I suggest + that you look at the Proxy ARP Subnet + Mini HOWTO. If you decide to use the technique described in that + HOWTO, you can set the proxy_arp flag for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by including the proxyarp option in the + interface's record in . When using Proxy + ARP sub-netting, you do NOT include any + entries in /etc/shorewall/proxyarp. + + The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for + enabling Proxy ARP on a small set of systems since you need one entry in + this file for each system using proxy ARP. Columns are: + + + + ADDRESS + + + address of the system. + + + + + INTERFACE + + + the interface that connects to the system. If the interface is + obvious from the subnetting, you may enter "-" in this + column. + + + + + EXTERNAL + + + the external interface that you want to honor ARP requests for + the ADDRESS specified in the first column. + + + + + HAVEROUTE + + + If you already have a route through INTERFACE to ADDRESS, this + column should contain "Yes" or "yes". If you want + Shorewall to add the route, the column should contain "No" + or "no". + + + + + + After you have made a change to the /etc/shorewall/proxyarp file, + you may need to flush the ARP cache of all routers on the LAN segment + connected to the interface specified in the EXTERNAL column of the + change/added entry(s). If you are having problems communicating between + an individual host (A) on that segment and a system whose entry has + changed, you may need to flush the ARP cache on host A as well. + + ISPs typically have ARP configured with long TTL (hours!) so if + your ISPs router has a stale cache entry (as seen using "tcpdump + -nei <external interface> host <IP addr>"), it may + take a long while to time out. I personally have had to contact my ISP + and ask them to delete a stale entry in order to restore a system to + working order after changing my proxy ARP settings. + + + + You have public IP addresses 155.182.235.0/28. You configure your + firewall as follows: + + eth0 - 155.186.235.1 (internet connection) +eth1 - 192.168.9.0/24 (masqueraded local systems) +eth2 - 192.168.10.1 (interface to your DMZ) + + In your DMZ, you want to install a Web/FTP server with public + address 155.186.235.4. On the Web server, you subnet just like the + firewall's eth0 and you configure 155.186.235.1 as the default + gateway. In your /etc/shorewall/proxyarp file, you will have: + + + + + + ADDRESS + + INTERFACE + + EXTERNAL + + HAVEROUTE + + + + + + 155.186.235.4 + + eth2 + + eth0 + + No + + + + + + You may want to configure the servers in your DMZ with + a subnet that is smaller than the subnet of your internet interface. See + the Proxy + ARP Subnet Mini HOWTO for details. In this case you will want to + place "Yes" in the HAVEROUTE column. + + + + Do not use Proxy ARP and FreeS/Wan on the same system unless you + are prepared to suffer the consequences. If you start or restart + Shorewall with an IPSEC tunnel active, the proxied IP addresses are + mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to + the interface that you specify in the INTERFACE column of + /etc/shorewall/proxyarp. I haven't had the time to debug this + problem so I can't say if it is a bug in the Kernel or in FreeS/Wan. + + You might be able to work around + this problem using the following (I haven't tried it): + + In /etc/shorewall/init, include: + + qt service ipsec stop + + In /etc/shorewall/start, include: + + qt service ipsec start + +
+ +
+ /etc/shorewall/nat + + The /etc/shorewall/nat file is used to define one-to-one NAT. There + is one entry in the file for each one-to-one NAT relationship that you + wish to define. In order to make use of this feature, you must have NAT + enabled. + + + If all you want to do is forward ports to servers behind your + firewall, you do NOT want to use one-to-one NAT. Port forwarding can be + accomplished with simple entries in the rules file. + Also, in most cases Proxy ARP provides a + superior solution to one-to-one NAT because the internal systems are + accessed using the same IP address internally and externally. + + + Columns in an entry are: + + + + EXTERNAL + + + External IP address + + + This should NOT be the primary IP address of the interface + named in the next column. + + + + + + INTERFACE + + + Interface that you want the EXTERNAL IP address to appear on. + Beginning with Shorewall version 1.3.14, if you have set + ADD_IP_ALIASES=Yes in , you can specify an + alias label of the form interfacename:digit + (e.g., eth0:0) and Shorewall will create the alias with that label. + Alias labels created in this way allow the alias to be visible to + the ipconfig utility. THAT IS THE ONLY THING + THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN + YOUR SHOREWALL CONFIGURATION. + + + + + INTERNAL + + + Internal IP address. + + + + + ALL INTERFACES + + + If Yes or yes (or left empty), NAT will be effective from all + hosts. If No or no then NAT will be effective only through the + interface named in the INTERFACE column. + + + + + LOCAL + + + If Yes or yes and the ALL INTERFACES column contains Yes or + yes, NAT will be effective from the firewall system. + + + For this to work, you must be running kernel 2.4.19 or later + and iptables 1.2.6a or later and you must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel. + + + + + + Look here for additional information and an + example. +
+ +
+ /etc/shorewall/tunnels + + The /etc/shorewall/tunnels file allows you to define IPSec, GRE, + IPIP, OpenVPN, PPTP + and 6to4.tunnels with end-points on your firewall. To use ipsec, you must + install version 1.9, 1.91 or the current FreeS/WAN development + snapshot. + + + For kernels 2.4.4 and above, you will need to use version 1.91 or + a development snapshot as patching with version 1.9 results in kernel + compilation errors. + + + Instructions for setting up IPSEC tunnels + may be found here, instructions for IPIP and GRE + tunnels are here, instructions for OpenVPN + tunnels are here, instructions for PPTP + tunnels are here, instructions for 6to4 + tunnels are here, and instructions for integrating Shorewall with other types of + tunnels are here. +
+ +
+ /etc/shorewall/shorewall.conf + + This file is used to set the following firewall parameters: + + + + ADMINISABSENTMINDED + + + (Added at version 1.4.7) - The value of this variable affects + Shorewall's stopped + state. When ADMINISABSENTMINDES=No, only traffic to/from + those addresses listed in /etc/shorewall/routestopped is accepted + when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in addition + to traffic to/from addresses in /etc/shorewall/routestopped, + connections that were active when Shorewall stopped continue to work + and all new connections from the firewall system itself are allowed. + If this variable is not set or is given the empty value then + ADMINISABSENTMINDED=No is assumed. + + + + + SHOREWALL_SHELL + + + (Added at version 1.4.6) - This parameter is used to specify + the shell program to be used to interpret the firewall script + (/usr/share/shorewall/firewall). If not specified or specified as a + null value, /bin/sh is assumed. + + + + + LOGFORMAT + + + (Added at version 1.4.4) - The value of this variable generate + the --log-prefix setting for Shorewall logging rules. It contains a + 'printf' formatting template which accepts three arguments + (the chain name, logging rule number (optional) and the + disposition). To use LOGFORMAT with fireparse, set it as: + + LOGFORMAT="fp=%s:%d a=%s " + + If the LOGFORMAT value contains the substring '%d' + then the logging rule number is calculated and formatted in that + position; if that substring is not included then the rule number is + not included. If not supplied or supplied as empty + (LOGFORMAT="") then "Shorewall:%s:%s:" is assumed. + + + /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log + messages in the 'show log', 'status' and + 'hits' commands. This part should not be omitted (the + LOGFORMAT should not begin with "%") and the leading part + should be sufficiently unique for /sbin/shorewall to identify + Shorewall messages. + + + + + + CLEAR_TC + + + (Added at version 1.3.13) - If this option is set to + 'No' then Shorewall won't clear the current traffic + control rules during [re]start. This setting is intended for use by + people that prefer to configure traffic shaping when the network + interfaces come up rather than when the firewall is started. If that + is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do + not supply an /etc/shorewall/tcstart file. That way, your traffic + shaping rules can still use the 'fwmark' classifier based on + packet marking defined in /etc/shorewall/tcrules. If not specified, + CLEAR_TC=Yes is assumed. + + + + + MARK_IN_FORWARD_CHAIN + + + (Added at version 1.3.12) - If your kernel has a FORWARD chain + in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause + the marking specified in the tcrules file to occur in + that chain rather than in the PREROUTING chain. This permits you to + mark inbound traffic based on its destination address when SNAT or + Masquerading are in use. To determine if your kernel has a FORWARD + chain in the mangle table, use the "/sbin/shorewall show + mangle" command; if a FORWARD chain is displayed then your + kernel will support this option. If this option is not specified or + if it is given the empty value (e.g., + MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is + assumed. + + + + + RFC1918_LOG_LEVEL + + + (Added at version 1.3.12) - This parameter determines the + level at which packets logged under the 'norfc1918' + mechanism are logged. The value must be a valid syslog level and if no level is + given, then info is assumed. Prior to Shorewall version 1.3.12, + these packets are always logged at the info level. + + + + + TCP_FLAGS_DISPOSITION + + + (Added in Version 1.3.11) - Determines the disposition of TCP + packets that fail the checks enabled by the tcpflags interface option and must have + a value of ACCEPT (accept the packet), REJECT (send an RST response) + or DROP (ignore the packet). If not set or if set to the empty value + (e.g., TCP_FLAGS_DISPOSITION="") then + TCP_FLAGS_DISPOSITION=DROP is assumed. + + + + + TCP_FLAGS_LOG_LEVEL + + + (Added in Version 1.3.11) - Determines the syslog level for logging + packets that fail the checks enabled by the tcpflags interface option.The value must + be a valid syslogd log level. If you don't want to log these + packets, set to the empty value (e.g., + TCP_FLAGS_LOG_LEVEL=""). + + + + + MACLIST_DISPOSITION + + + (Added in Version 1.3.10) - Determines the disposition of + connections requests that fail MAC + Verification and must have the value ACCEPT (accept the + connection request anyway), REJECT (reject the connection request) + or DROP (ignore the connection request). If not set or if set to the + empty value (e.g., MACLIST_DISPOSITION="") then + MACLIST_DISPOSITION=REJECT is assumed. + + + + + MACLIST_LOG_LEVEL + + + (Added in Version 1.3.10) - Determines the syslog level for logging + connection requests that fail MAC + Verification. The value must be a valid syslogd log level. + If you don't want to log these connection requests, set to the + empty value (e.g., MACLIST_LOG_LEVEL=""). + + + + + NEWNOTSYN + + + (Added in Version 1.3.8) - When set to "Yes" or + "yes", Shorewall will filter TCP packets that are not part + of an established connention and that are not SYN packets (SYN flag + on - ACK flag off). If set to "No", Shorewall will silently + drop such packets. If not set or set to the empty value (e.g., + "NEWNOTSYN="), NEWNOTSYN=No is assumed. + + If you have a HA setup with failover to another firewall, you + should have NEWNOTSYN=Yes on both firewalls. You should also select + NEWNOTSYN=Yes if you have asymmetric routing. + + + + + LOGNEWNOTSYN + + + (Added in Version 1.3.6) - Beginning with version 1.3.6, + Shorewall drops non-SYN TCP packets that are not part of an existing + connection. If you would like to log these packets, set LOGNEWNOTSYN + to the syslog level at + which you want the packets logged. Example: LOGNEWNOTSYN=ULOG| + + + Packets logged under this option are usually the result of + broken remote IP stacks rather than the result of any sort of + attempt to breach your firewall. + + + + + + DETECT_DNAT_ADDRS + + + (Added in Version 1.3.4) - If set to "Yes" or + "yes", Shorewall will detect the first IP address of the + interface to the source zone and will include this address in DNAT + rules as the original destination IP address. If set to "No" + or "no", Shorewall will not detect this address and any + destination IP address will match the DNAT rule. If not specified or + empty, "DETECT_DNAT_ADDRS=Yes" is assumed. + + + + + MULTIPORT + + + + Removed in version 1.4.6 -- the value of this parameter is + now automatically detected by Shorewall + + + If set to "Yes" or "yes", Shorewall will use + the Netfilter multiport facility. In order to use this facility, + your kernel must have multiport support + (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, Shorewall + will generate a single rule from each record in the + /etc/shorewall/rules file that meets these criteria: + + + + No port range(s) specified + + + + Specifies 15 or fewer ports + + + + Rules not meeting those criteria will continue to generate an + individual rule for each listed port or port range. + + + + + NAT_BEFORE_RULES + + + If set to "No" or "no", port forwarding rules + can override the contents of the file. If set + to "Yes" or "yes", port forwarding rules cannot + override one-to-one NAT. If not set or set to an empty value, + "Yes" is assumed. + + + + + FW + + + This parameter specifies the name of the firewall zone. If not + set or if set to an empty string, the value "fw" is assumed. + + + + + SUBSYSLOCK + + + This parameter should be set to the name of a file that the + firewall should create if it starts successfully and remove when it + stops. Creating and removing this file allows Shorewall to work with + your distribution's initscripts. For RedHat, this should be set + to /var/lock/subsys/shorewall. For Debian, the value is + /var/state/shorewall and in LEAF it is /var/run/shorwall. Example: + SUBSYSLOCK=/var/lock/subsys/shorewall. + + + + + STATEDIR + + + This parameter specifies the name of a directory where + Shorewall stores state information. If the directory doesn't + exist when Shorewall starts, it will create the directory. Example: + STATEDIR=/tmp/shorewall. + + + If you change the STATEDIR variable while the firewall is + running, create the new directory if necessary then copy the + contents of the old directory to the new directory. + + + + + + MODULESDIR + + + This parameter specifies the directory where your kernel + netfilter modules may be found. If you leave the variable empty, + Shorewall will supply the value "/lib/modules/`uname + -r`/kernel/net/ipv4/netfilter. + + + + + LOGRATE and LOGBURST + + + These parameters set the match rate and initial burst size for + logged packets. Please see the iptables man page for a description + of the behavior of these parameters (the iptables option --limit is + set by LOGRATE and --limit-burst is set by LOGBURST). If both + parameters are set empty, no rate-limiting will occur. + + + + + LOGRATE=10/minute +LOGBURST=5 + + + + + + LOGFILE + + + This parameter tells the /sbin/shorewall program where to look + for Shorewall messages when processing the "show log", + "monitor", "status" and "hits" commands. If + not assigned or if assigned an empty value, /var/log/messages is + assumed. + + + + + NAT_ENABLED + + + + Removed in Shorewall 1.4.6 -- the value of this parameter is + now automatically detected by Shorewall + + + This parameter determines whether Shorewall supports NAT + operations. NAT operations include: + + + One-to-one NAT + + Port Forwarding + + Port Redirection + + Masquerading + + + If the parameter has no value or has a value of "Yes" + or "yes" then NAT is enabled. If the parameter has a value + of "no" or "No" then NAT is disabled. + + + + + MANGLE_ENABLED + + + + Removed in Shorewall 1.4.6 -- the value of this parameter is + now automatically detected by Shorewall + + + This parameter determines if packet mangling is enabled. If + the parameter has no value or has a value of "Yes" or + "yes" than packet mangling is enabled. If the parameter has + a value of "no" or "No" then packet mangling is + disabled. If packet mangling is disabled, the /etc/shorewall/tos + file is ignored. + + + + + IP_FORWARDING + + + This parameter determines whether Shorewall enables or + disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). + Possible values are: + + + + On or on + + + packet forwarding will be enabled. + + + + + Off or off + + + packet forwarding will be disabled. + + + + + Keep or keep + + + Shorewall will neither enable nor disable packet + forwarding. + + + + + If this variable is not set or is given an empty value + (IP_FORWARD="") then IP_FORWARD=On is assumed. + + + + + ADD_IP_ALIASES + + + This parameter determines whether Shorewall automatically adds + the external address(es) in . + If the variable is set to "Yes" or "yes" then + Shorewall automatically adds these aliases. If it is set to + "No" or "no", you must add these aliases yourself + using your distribution's network configuration tools. + + + Shorewall versions before 1.4.6 can only add addresses to + the first subnetwork configured on an interface. + + + If this variable is not set or is given an empty value + (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed. + + + + + ADD_SNAT_ALIASES + + + This parameter determines whether Shorewall automatically adds + the SNAT ADDRESS in . If + the variable is set to "Yes" or "yes" then Shorewall + automatically adds these addresses. If it is set to "No" or + "no", you must add these addresses yourself using your + distribution's network configuration tools. + + + Shorewall versions before 1.4.6 can only add addresses to + the first subnetwork configured on an interface. + + + If this variable is not set or is given an empty value + (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed. + + + + + LOGUNCLEAN + + + This parameter determines the logging level of mangled/invalid + packets controlled by the 'dropunclean and logunclean' + interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets + selected by 'dropclean' are dropped silently + ('logunclean' packets are logged under the 'info' + log level). Otherwise, these packets are logged at the specified + level (Example: LOGUNCLEAN=debug). + + + + + BLACKLIST_DISPOSITION + + + This parameter determines the disposition of packets from + blacklisted hosts. It may have the value DROP if the packets are to + be dropped or REJECT if the packets are to be replied with an ICMP + port unreachable reply or a TCP RST (tcp only). If you do not assign + a value or if you assign an empty value then DROP is assumed. + + + + + BLACKLIST_LOGLEVEL + + + This paremter determines if packets from blacklisted hosts are + logged and it determines the syslog level that they are to be logged + at. Its value is a syslog level + (Example: BLACKLIST_LOGLEVEL=debug). If you do not assign a value or + if you assign an empty value then packets from blacklisted hosts are + not logged. + + + + + CLAMPMSS + + + This parameter enables the TCP Clamp MSS to PMTU feature of + Netfilter and is usually required when your internet connection is + through PPPoE or PPTP. If set to "Yes" or "yes", the + feature is enabled. If left blank or set to "No" or + "no", the feature is not enabled. + + + This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel. + + + + + + ROUTE_FILTER + + + If this parameter is given the value "Yes" or + "yes" then route filtering (anti-spoofing) is enabled on all + network interfaces. The default value is "no". + + + +
+ +
+ /etc/shorewall/modules Configuration + + The file /etc/shorewall/modules contains commands for loading the + kernel modules required by Shorewall-defined firewall rules. Shorewall + will source this file during start/restart provided that it exists and + that the directory specified by the MODULESDIR parameter exists (see above). + + The file that is released with Shorewall calls the Shorewall + function "loadmodule" for the set of modules that I load. + + The loadmodule function is called as follows: + + loadmodule <modulename> [ <module parameters> ] + + where + + + + <modulename> + + + is the name of the modules without the trailing ".o" + (example ip_conntrack). + + + + + <module parameters> + + + Optional parameters to the insmod utility. + + + + + The function determines if the module named by <modulename> + is already loaded and if not then the function determines if the + ".o" file corresponding to the module exists in the + moduledirectory; if so, then the following command is + executed: + + insmod moduledirectory/<modulename>.o <module parameters> + + If the file doesn't exist, the function determines of the + ".o.gz" file corresponding to the module exists in the + moduledirectory. If it does, the function assumes + that the running configuration supports compressed modules and execute the + following command: + + insmod moduledirectory/<modulename>.o.gz <module parameters> +
+ +
+ /etc/shorewall/tos Configuration + + The /etc/shorewall/tos file allows you to set the Type of Service + field in packet headers based on packet source, packet destination, + protocol, source port and destination port. In order for this file to be + processed by Shorewall, you must have mangle support enabled. + + Entries in the file have the following columns: + + + + SOURCE + + + The source zone. May be qualified by following the zone name + with a colon (":") and either an IP address, an IP subnet, a + MAC address in + Shorewall Format or the name of an interface. This column + may also contain the name of the firewall zone to indicate packets + originating on the firewall itself or "all" to indicate any + source. + + + + + DEST + + + The destination zone. May be qualified by following the zone + name with a colon (":") and either an IP address or an IP + subnet. Because packets are marked prior to routing, you may not + specify the name of an interface. This column may also contain + "all" to indicate any destination. + + + + + PROTOCOL + + + The name of a protocol in /etc/protocols or the protocol's + number. + + + + + SOURCE PORT(S) + + + The source port or a port range. For all ports, place a hyphen + ("-") in this column. + + + + + DEST PORT(S) + + + The destination port or a port range. To indicate all ports, + place a hyphen ("-") in this column. + + + + + TOS + + + The type of service. Must be one of the following: + + + Minimize-Delay (16) + + Maximize-Throughput (8) + + Maximize-Reliability (4) + + Minimize-Cost (2) + + Normal-Service (0) + + + + + + + /etc/shorewall/tos file that is included with Shorewall + + + + + SOURCE + + DEST + + PROTOCOL + + SOURCE PORT(S) + + DEST PORT(S) + + TOS + + + + + + all + + all + + tcp + + - + + ssh + + 16 + + + + all + + all + + tcp + + ssh + + - + + 16 + + + + all + + all + + tcp + + - + + ftp + + 16 + + + + all + + all + + tcp + + ftp + + - + + 16 + + + + all + + all + + tcp + + - + + ftp-data + + 8 + + + + all + + all + + tcp + + ftp-data + + - + + 8 + + + +
+ + + Users have reported that odd routing problems result from adding + the ESP and AH protocols to the /etc/shorewall/tos file. + +
+ +
+ /etc/shorewall/blacklist + + Each line in /etc/shorewall/blacklist contains an IP address, a MAC + address in Shorewall Format or subnet address. + + + + + 130.252.100.69 +206.124.146.0/24 + + + Packets from hosts listed in the + blacklist file will be disposed of according to the value assigned to the + BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL + variables in /etc/shorewall/shorewall.conf. Only packets arriving on + interfaces that have the 'blacklist' + option in /etc/shorewall/interfaces are checked against the blacklist. The + black list is designed to prevent listed hosts/subnets from accessing + services on your network. + + Beginning with Shorewall 1.3.8, the blacklist file has three + columns: + + + + ADDRESS/SUBNET + + + As described above. + + + + + PROTOCOL + + + Optional. If specified, only packets specifying this protocol + will be blocked. + + + + + PORTS + + + Optional; may only be given if PROTOCOL is tcp, udp or icmp. + Expressed as a comma-separated list of port numbers or service names + (from /etc/services). If present, only packets destined for the + specified protocol and one of the listed ports are blocked. When the + PROTOCOL is icmp, the PORTS column contains a comma-separated list + of ICMP type numbers or names (see "iptables -h icmp"). + + + + + Shorewall also has a dynamic + blacklist capability. + + + The Shorewall blacklist file is NOT + designed to police your users' web browsing -- to do that, I suggest + that you install and configure Squid + with SquidGuard. + +
+ +
+ /etc/shorewall/rfc1918 (Added in Version 1.3.1) + + This file lists the subnets affected by the norfc1918 interface option. Columns in the + file are: + + + + SUBNET + + + The subnet using VLSM notation (e.g., 192.168.0.0/16). + + + + + TARGET + + + What to do with packets to/from the SUBNET: + + + + RETURN + + + Process the packet normally thru the rules and policies. + + + + + DROP + + + Silently drop the packet. + + + + + logdrop + + + Log then drop the packet -- see the RFC1918_LOG_LEVEL + parameter above. + + + + + + +
+ +
+ /etc/shorewall/routestopped (Added in Version 1.3.4) + + This file defines the hosts that are accessible from the firewall + when the firewall is stopped. Columns in the file are: + + + + INTERFACE + + + The firewall interface through which the host(s) comminicate + with the firewall. + + + + + HOST(S) - (Optional) + + + A comma-separated list of IP/Subnet addresses. If not supplied + or supplied as "-" then 0.0.0.0/0 is assumed. + + + + + + When your firewall is stopped, you want firewall accessibility + from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces + through eth1 and your local hosts through eth2. + + + + + + INTERFACE + + HOST(S) + + + + + + eth2 + + 192.168.1.0/24 + + + + eth1 + + - + + + + + +
+ +
+ /etc/shorewall/maclist (Added in Version 1.3.10) + + This file is described in the MAC + Validation Documentation. +
+ +
+ /etc/shorewall/ecn (Added in Version 1.4.0) + + This file is described in the ECN Control + Documentation. +
+
\ No newline at end of file