diff --git a/Shorewall-docs2/Accounting.xml b/Shorewall-docs2/Accounting.xml index 6db62577f..e63145bbd 100644 --- a/Shorewall-docs2/Accounting.xml +++ b/Shorewall-docs2/Accounting.xml @@ -15,10 +15,10 @@ - 2004-04-19 + 2005-08-28 - 2003-2004 + 2003-2005 Thomas M. Eastep @@ -34,9 +34,6 @@ - Shorewall Traffic Accounting support was added in Shorewall release - 1.4.7. - Shorewall accounting rules are described in the file /etc/shorewall/accounting. By default, the accounting rules are placed in a chain called accounting and can thus be displayed using @@ -122,9 +119,8 @@ - USER/GROUP (Added in Shorewall - 2.2.0) - This column may only be non-empty if the CHAIN is OUTPUT. The - column may contain: + USER/GROUP - This column may only + be non-empty if the CHAIN is OUTPUT. The column may contain: [!][<user name or number>][:<group name or number>] diff --git a/Shorewall-docs2/Actions.xml b/Shorewall-docs2/Actions.xml index e914f4042..45df30d87 100644 --- a/Shorewall-docs2/Actions.xml +++ b/Shorewall-docs2/Actions.xml @@ -15,7 +15,7 @@ - 2005-05-13 + 2005-08-28 2005 @@ -34,6 +34,12 @@ + + This article applies to Shorewall 3.0 and later. If you are running + a version of Shorewall earlier than Shorewall 3.0.0 then please see the + documentation for that release. + +
What are Shorewall Actions? @@ -167,16 +173,16 @@ Reject:REJECT #Common Action for REJECT policy action begins with a capital letter; that way, the name won't conflict with a Shorewall-defined chain name. - Beginning with Shorewall-2.0.0-Beta1, the name of the action may - be optionally followed by a colon (:) and ACCEPT, DROP - or REJECT. When this is done, the named action will become the - common action for policies of type ACCEPT, DROP - or REJECT respectively. The common action is applied immediately - before the policy is enforced (before any logging is done under that - policy) and is used mainly to suppress logging of uninteresting - traffic which would otherwise clog your logs. The same policy name can - appear in multiple actions; the last such action for each policy name - is the one which Shorewall will use. + The name of the action may be optionally followed by a colon + (:) and ACCEPT, DROP or REJECT. When this is done, the + named action will become the common action for + policies of type ACCEPT, DROP or REJECT respectively. The common + action is applied immediately before the policy is enforced (before + any logging is done under that policy) and is used mainly to suppress + logging of uninteresting traffic which would otherwise clog your logs. + The same policy name can appear in multiple actions; the last such + action for each policy name is the one which Shorewall will + use. Shorewall includes pre-defined actions for DROP and REJECT -- see above. @@ -369,12 +375,9 @@ LogAndAccept loc fw tcp 22
Actions and Logging - Prior to Shorewall 2.1.2, specifying a log level (and optionally a - log tag) on a rule that specified a user-defined (or Shorewall-defined) - action would log all traffic passed to the action. Beginning with - Shorewall 2.1.2, specifying a log level in a rule that specifies a user- - or Shorewall-defined action will cause each rule in the action to be - logged with the specified level (and tag). + Specifying a log level in a rule that specifies a user- or + Shorewall-defined action will cause each rule in the action to be logged + with the specified level (and tag). The extent to which logging of action rules occur is governed by the following: diff --git a/Shorewall-docs2/Documentation.xml b/Shorewall-docs2/Documentation.xml index bc26aaf06..9260af172 100644 --- a/Shorewall-docs2/Documentation.xml +++ b/Shorewall-docs2/Documentation.xml @@ -15,7 +15,7 @@ - 2005-06-01 + 2005-08-28 2001-2005 @@ -41,6 +41,12 @@ + + This article applies to Shorewall 3.0 and later. If you are running + a version of Shorewall earlier than Shorewall 3.0.0 then please see the + documentation for that release. + +
Components @@ -254,17 +260,6 @@ - - bogons - - - a parameter file in /usr/share/shorewall used to define the - treatment of packets under the nobogons - interface option. - - - routestopped @@ -314,7 +309,7 @@ a parameter file in /etc/shorewall used to define traffic - accounting rules. This file was added in version 1.4.7. + accounting rules. @@ -429,40 +424,78 @@ NET_OPTIONS=blacklist,norfc1918 - DISPLAY + IPSEC - The name of the zone as displayed during Shorewall - startup. + + Yes - All traffic to/from this zone is encrypted. + + No - By default, traffic to/from some of the hosts in this + zone is not encrypted. Any encrypted hosts are designated using + the ipsec option in /etc/shorewall/hosts. + - COMMENTS + OPTIONS, IN OPTIONS, OUT OPTIONS - Any comments that you want to make about the zone. Shorewall - ignores these comments. + Optional parameters that identify the security policy and + security associations used in communication with hosts in this zone. + A comma-separated list of the following: + + + proto[!]=ah|esp|ipcomp + + mode[!]=transport|tunnel + + reqid[!]=<number> + — A number assigned to a security policy using the + unique:<number> as the SPD level. See setkey(8). + + tunnel-src[!]=<address>[/<mask>] + — Tunnel Source; may only be included with mode=tunnel. Since + tunnel source and destination are dependent on the direction of + the traffic, this option and the following one should only be + included in the IN OPTIONS and OUT OPTIONS columns. + + tunnel-dst[!]=<address>[/<mask>] + — Tunnel Destination; may only be included with + mode=tunnel. + + mss=<number> — Sets + the MSS field in TCP syn packets forwarded to/from this zone. May + be used to compensate for the lack of IPSEC pseudo-devices with + their own MTU in the 2.6 Kernel IPSEC implementation. If specified + in the IN OPTIONS, TCP SYN packets from the zone will have MSS + altered; if specified in the OUT OPTIONS, TCP SYN packets to the + zone will have MSS altered. + + spi[!]=<number> + — The security parameter index of the Security Association. Since + a different SA is used for incoming and outgoing traffic, this + option should only be listed in the IN OPTIONS and OUT OPTIONS + columns. + + strict — Must be + specified when SPD rules are used (e.g., esp encapsulated with + ah). + + next — Separates rules + when strict is used. + - #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 arp_filter - (Added in version 1.4.7) - This option causes + 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 @@ -556,11 +589,42 @@ dmz DMZ Demilitarized zone + + arp_ignore[=<number>] + + + respond to arp requests based on the value of + <number>. + + 1 - reply only if the target IP address is local + address configured on the incoming interface + + 2 - reply only if the target IP address is local + address configured on the incoming interface and both with the + sender's IP address are part from same subnet on this + interface + + 3 - do not reply for local addresses configured with + scope host, only resolutions for global and link addresses are + replied + + 4-7 - reserved + + 8 - do not reply for all local addresses + + If no <number> is given then + the value 1 is assumed + + WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE + INVOLVED IN PROXY ARP. + + + newnotsyn - (Added in version 1.4.6) - This option overrides 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 @@ -572,11 +636,10 @@ dmz DMZ Demilitarized zone 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 - -. + 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 -. @@ -584,15 +647,14 @@ dmz DMZ Demilitarized zone 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. + 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. @@ -629,13 +691,6 @@ dmz DMZ Demilitarized zone source or destination address that is reserved in RFC 1918 will be dropped after being optionally logged. - Prior to Shorewall 2.0.1, addresses blocked by the - standard rfc1918 file include - those addresses reserved by RFC1918 plus other ranges reserved - by the IANA or by other RFCs. Beginning with Shorewall 2.0.1, - these additional addresses are covered by the nobogons option below. - 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 @@ -648,25 +703,6 @@ dmz DMZ Demilitarized zone - - nobogons (Added in Shorewall 2.0.1) - - - Packets arriving on this interface that have a source - address reserved by the IANA or by other RFCs (other than - 1918) are dropped after being optionally logged. See the - /etc/shorewall/bogons file documentation below. - - I personally recommend against using the nobogons - option. The IPV4 address space is being rapidly depleated so - the benefit of blocking traffic from unallocated address - ranges is minimal. Plus the rate at which address blocks are - being assigned causes your /etc/shorewall/bogons file to - become out of date with the result that legitimate traffic - gets blocked. - - - routefilter @@ -688,8 +724,7 @@ dmz DMZ Demilitarized zone proxyarp - (Added in version 1.3.5) - This option causes Shorewall - to set + 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 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. + If this option is specified, all connection requests + from this interface are subject to MAC Verification. May only + be specified for ethernet interfaces. @@ -717,12 +752,12 @@ dmz DMZ Demilitarized zone detectnets - (Added in version 1.4.10) - If this option is specified, - the zone named in the ZONE column will contain only the hosts - routed through the interface named in the INTERFACE column. - Do not set this option on your external - (Internet) interface! The interface must be in the - UP state when Shorewall is [re]started. + If this option is specified, the zone named in the ZONE + column will contain only the hosts routed through the + interface named in the INTERFACE column. Do not set this option on your external (Internet) + interface! The interface must be in the UP state + when Shorewall is [re]started. @@ -730,12 +765,11 @@ dmz DMZ Demilitarized zone nosmurfs - (Added in version 2.0.0) - If this option is specified, - incoming connection requests will be checked to ensure that - they do not have a broadcast or multicast address as their - source. Any such packets will be dropped after being - optionally logged according to the setting of SMURF_LOG_LEVEL - in If this option is specified, incoming connection + requests will be checked to ensure that they do not have a + broadcast or multicast address as their source. Any such + packets will be dropped after being optionally logged + according to the setting of SMURF_LOG_LEVEL in /etc/shorewall/shorewall.conf. @@ -744,9 +778,8 @@ dmz DMZ Demilitarized zone logmartians - (Added in version 2.2.0) - If this option is specified, - the kernel's martian logging facility will be enabled on this - interface + If this option is specified, the kernel's martian + logging facility will be enabled on this interface (/proc/sys/net/ipv4/conf/<interface>/log_martians will be set to 1). See also the LOG_MARTIANS option in shorewall.conf. @@ -757,13 +790,22 @@ dmz DMZ Demilitarized zone sourceroute - (Added in version 2.2.0) - If this option is not - specified for an interface, then source-routed packets will - not be accepted from that interface (sets + If this option is not specified for an interface, then + source-routed packets will not be accepted from that interface + (sets /proc/sys/net/ipv4/conf/<interface> to 1). + + + upnp + + + Incoming requests from this interface may be remapped + via UPNP (upnpd). + + My recommendations concerning options: @@ -867,21 +909,15 @@ loc eth1 192.168.1.255,192.168.12.255 - A physical port name (Shorewall version 2.0.1 and later); - only allowed when the interface names a bridge created by the - brctl addbr command. This port must not be - defined in /etc/shorewall/interfaces and - may optionally followed by a colon (":") and a host or network - IP. See the bridging - documentation for details. + A physical port name; only allowed when the interface + names a bridge created by the brctl addbr + command. This port must not be defined in + /etc/shorewall/interfaces and may + optionally followed by a colon (":") and a host or network IP. + See the bridging documentation + for details. - - - 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. - @@ -896,9 +932,9 @@ loc eth1 192.168.1.255,192.168.12.255 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. + This option causes Shorewall to set up handling for + routing packets sent by this host group back back to the same + group. @@ -906,31 +942,30 @@ loc eth1 192.168.1.255,192.168.12.255 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 specified, connection requests from the hosts + specified in this entry are subject to MAC Verification. This + option is only valid for ethernet interfaces. - tcpflags (Added in Shorewall 2.0.1) + tcpflags - (added in version 1.3.11) - This option causes Shorewall - to make sanity checks on the header flags in TCP packets - arriving from these hosts. 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. + This option causes Shorewall to make sanity checks on + the header flags in TCP packets arriving from these hosts. + 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 (Added in Shorewall 2.0.1 -- only makes sense - for bridge ports) + blacklist (only makes sense for bridge ports) This option causes incoming packets on this port to be @@ -940,8 +975,7 @@ loc eth1 192.168.1.255,192.168.12.255 - norfc1918 (Added in Shorewall 2.0.1 -- only makes sense - for bridge ports) + norfc1918 -- only makes sense for bridge ports) Packets arriving on this port and that have a source @@ -952,20 +986,7 @@ loc eth1 192.168.1.255,192.168.12.255 - nobogons (Added in Shorewall 2.0.1 -- only makes sense for - bridge ports) - - - Packets arriving on this port that have a source address - reserved by the IANA or by other RFCs (other than 1918) are - dropped after being optionally logged. See the - /etc/shorewall/bogons file documentation below. - - - - - nosmurfs (Added in Shorewall 2.0.1 -- only makes sense for - bridge ports) + nosmurfs (only makes sense for bridge ports) If this option is specified, incoming connection @@ -976,6 +997,18 @@ loc eth1 192.168.1.255,192.168.12.255 linkend="Conf">/etc/shorewall/shorewall.conf. + + + ipsec + + + The hosts are accessed via a kernel 2.6 ipsec SA. Note that if + the zone named in the ZONE column is specified as an IPSEC + zone in the /etc/shorewall/zones + file then you do NOT need to specify 'ipsec' here. + + @@ -1122,11 +1155,11 @@ loc eth1:192.168.1.0/24,192.168.12.0/24 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. + 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. @@ -1251,14 +1284,10 @@ loc loc REJECT info 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. + interface. 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). The idea is this: @@ -1278,11 +1307,6 @@ loc loc REJECT info - UNLESS the user defines the zone badly so that intra-zone rules - are required. In that case, Shorewall will not try to guess what the - user's intentions are and will treat traffic within the affected zone(s) - just like any other traffic. - 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 @@ -1302,20 +1326,11 @@ loc loc REJECT info - Beginning with Shorewall 2.0.0, you can control the traffic from - the firewall to itself. As with any zone, fw->fw traffic is enabled - by default. It is not necessary to define the loopback interface (lo) in - /etc/shorewall/interfaces in order to - define fw->fw rules or a fw->fw policy. - - - So long as there are no intra-zone rules for a zone, all - intra-zone traffic for that zone is accepted. As soon as you add a - single rule from the zone to itself, then ALL traffic from that zone - to itself is controlled by the rules and the first policy in - /etc/shorewall/policy that matches the zone to - itself. - + You can control the traffic from the firewall to itself. As with + any zone, fw->fw traffic is enabled by default. It is not necessary + to define the loopback interface (lo) in /etc/shorewall/interfaces in order to define + fw->fw rules or a fw->fw policy.
@@ -1445,6 +1460,62 @@ DNAT net loc:192.168.1.3 tcp ssh + The /etc/shorewall/rules file may now be into + sections. Each section is introduced by a line that + begins with the keyword SECTION which is followed by the section name. + Sections are as listed below and must appear in the order shown. + + + + ESTABLISHED + + + Rules in this section apply to packets in the ESTABLISHED + state. + + + + + RELATED + + + Rules in this section apply to packets in the RELATED + state. + + + + + NEW + + + Rules in this section apply to packets in the NEW and INVALID + states. + + + + + Rules in the ESTABLISHED and RELATED sections are limited to the + following ACTIONs: + +
+ ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions. +
+ + Macros may be used in these sections provided that they expand to + only these ACTIONs. At the end of the ESTABLISHED and RELATED sections, + there is an implicit ACCEPT rule. + + RESTRICTION: If you specify FASTACCEPT=Yes in + /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED sections + must be empty. + + + Unless you understand Netfilter well enough to be comfortable with + the difference between ESTABLISHED, RELATED, INVALID and NEW connection + tracking states, you should omit the ESTABLISHED and RELATED sections + and place all of your rules in the NEW section. + + Entries in the file have the following columns: @@ -1466,9 +1537,8 @@ DNAT net loc:192.168.1.3 tcp ssh ACCEPT+ - Added in Shorewall 2.0.2 Beta 2. Works like ACCEPT but - also exempts the connection from matching DNAT and REDIRECT - rules later in the file. + Works like ACCEPT but also exempts the connection from + matching DNAT and REDIRECT rules later in the file. @@ -1476,9 +1546,8 @@ DNAT net loc:192.168.1.3 tcp ssh NONAT - Added in Shorewall 2.0.2 Beta 2. Exempts matching - connections from DNAT and REDIRECT rules later in the - file. + Exempts matching connections from DNAT and REDIRECT + rules later in the file. @@ -1524,12 +1593,12 @@ DNAT net loc:192.168.1.3 tcp ssh SAME - Added in Shorewall 2.2.4. SAME is useful when more than - one server IP address (an address range, for example) is given - in the DEST column below. SAME works similar to DNAT with the - exception that when multiple connections from an internet host - match a SAME rule then all of the connections will be sent to - the same internal server. + SAME is useful when more than one server IP address (an + address range, for example) is given in the DEST column below. + SAME works similar to DNAT with the exception that when + multiple connections from an internet host match a SAME rule + then all of the connections will be sent to the same internal + server. Unlike when using DNAT rules, SAME rules may not alter @@ -1542,8 +1611,7 @@ DNAT net loc:192.168.1.3 tcp ssh SAME- - Added in Shorewall 2.2.4. SAME generates two iptables - rules: + SAME generates two iptables rules: @@ -1628,13 +1696,23 @@ DNAT net loc:192.168.1.3 tcp ssh action> - (Shorewall 1.4.9 and later) - An action defined in the - An action defined in the /etc/shorewall/actions or /usr/share/shorewall/actions.std files. + + + <macro> + + + The name of a macro defined using a file with name + macro.<name>. Macro files are usually placed in + /etc/shorewall but may reside in any directory on the + CONFIG_PATH. + + The ACTION may optionally be followed by : and @@ -1642,10 +1720,10 @@ DNAT net loc:192.168.1.3 tcp ssh REJECT:info or ACCEPT:debug). 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. Beginning with Shorewall version 2.0.2 Beta 1, a - log tag may be specified. A log tag is a - string of alphanumeric characters and is specified by following the - log level with ":" and the log tag. Example:ACCEPT:info:ftp net dmz tcp 21 + syslog level. The log level may be optionally followed by a + log tag. A log tag is a string of + alphanumeric characters and is specified by following the log level + with ":" and the log tag. Example:ACCEPT:info:ftp net dmz tcp 21 The log tag is appended to the log prefix generated by the LOGPREFIX variable in /etc/shorewall/conf. If @@ -1709,10 +1787,9 @@ ACCEPT:info - - tc 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, + specified interface (example loc:eth4). 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). @@ -1742,9 +1819,9 @@ ACCEPT:info - - tc refers to a connection request from any host in the - specified subnet (example net:155.186.235.0/24). Beginning - with Shorewall 2.1.0, IP address ranges of the form - <first address>-<last + specified subnet (example net:155.186.235.0/24). IP address + ranges of the form <first + address>-<last address> may be specified. This requires that your kernel and iptables have iprange match support. @@ -1800,11 +1877,7 @@ ACCEPT:info - - tc 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-. It is - available with SAME and SAME- rules in all versions that support - those actions. + (load-balancing). @@ -1870,53 +1943,6 @@ ACCEPT:info - - tc If this list begins with ! then the rule will only apply if the original destination address matches none of the addresses listed. - - 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. - - - Specifying SNAT in a DNAT rule is deprecated and this - feature was removed from Shorewall in version 2.1.0. An entry in - /etc/shorewall/masq can serve the same - purpose and is the preferred method of performing SNAT with - Shorewall. See FAQ 2 for an - example. - - - - 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. - - - - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL -# PORT(S) PORT(S) DEST -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. - - - Shorewall does not take any steps to ensure that IP - addresses entered in this column are added to the appropriate - firewall interface. Unless traffic for this address is - automatically routed to the firewall by another router, it is your - responsibility to add the address using your distributions network - configuration facilities. See this article - for additional information. - @@ -1924,9 +1950,8 @@ DNAT loc:192.168.1.0/24 loc:192.168.1.3 tcp 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 + You may rate-limit ACCEPT, DNAT[-], REDIRECT[-] or LOG rules + with an entry in this column. Entries have the form <rate>/<interval>[:<burst>] @@ -1969,10 +1994,10 @@ DNAT loc:192.168.1.0/24 loc:192.168.1.3 tcp USER/GROUP - 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. + 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. @@ -2154,10 +2179,9 @@ ACCEPT fw net tcp www 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.4.10, the interface name can be qualified with ":" followed by a - comma separated list of hosts and/or subnets. If this list begins - with ! (e.g., + host or subnet will be masqueraded. The interface name can be + qualified with ":" followed by a comma separated list of hosts + and/or subnets. If this list begins with ! (e.g., eth0:!192.0.2.8/29,192.0.2.32/29) then only packets addressed to destinations not listed will be masqueraded; otherwise (e.g., @@ -2165,9 +2189,9 @@ ACCEPT fw net tcp www masqueraded if it does match one of the listed addresses. - 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 + 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. @@ -2178,18 +2202,16 @@ ACCEPT fw net tcp www Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules defined in the /etc/shorewall/nat file. - Beginning with Shorewall 2.1.1, if you preceed the interface name - with a plus sign ("+") then the rule will be evaluated before - one-to-one NAT. + If you preceed the interface name with a plus sign ("+") then the + rule will be evaluated before one-to-one NAT. Examples: +eth0 +eth1:192.0.2.32/27 - Also new in the Shorewall 2.1 series, the effect of - ADD_SNAT_ALIASES=Yes can be negated for an entry by following the - interface name by ":" but no digit. + The effect of ADD_SNAT_ALIASES=Yes can be negated for an entry + by following the interface name by ":" but no digit. Examples: @@ -2210,17 +2232,6 @@ eth1::192.0.2.32/27 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. @@ -2238,19 +2249,18 @@ eth1::192.0.2.32/27 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 rounded-robin - fashion. + linkend="Conf" />. 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 + rounded-robin fashion. - Beginning with Shorewall 2.2.0, you may also specify the - source port range to be used (the PROTO column must specify tcp or - udp) by following the address or address range if any with ":" and - the port range (in the format <low - port>-<high port>). + You may also specify the source port range to be used (the + PROTO column must specify tcp or udp) by following the address or + address range if any with ":" and the port range (in the format + <low port>-<high + port>). Examples: @@ -2264,8 +2274,8 @@ eth0 192.168.1.0/24 :4000-5000 tcp from a client assume that when SNAT is being used that all connections between the client and a particular client and a remote server will appear to the server to come from the same external IP - address. Beginning with Shorewall 2.2.4, you can ensure that this is - the case by preceding the ADDRESS range by "SAME:". + address. You can ensure that this is the case by preceding the + ADDRESS range by "SAME:". Example: @@ -2285,7 +2295,7 @@ eth0 10.0.0.0/8 SAME:nodst:192.0.2.44-192.168.2.50 - PROTO (Added in Shorewall version 2.0.2 Beta 1) + PROTO If specified, must be a protocol number of a protocol name @@ -2295,7 +2305,7 @@ eth0 10.0.0.0/8 SAME:nodst:192.0.2.44-192.168.2.50 - PORT(S) (Added in Shorewall version 2.0.2 Beta 1) + PORT(S) If the PROTO column specifies TCP (6) or UDP (17) then this @@ -2327,7 +2337,7 @@ eth0 10.0.0.0/8 SAME:nodst:192.0.2.44-192.168.2.50 - IPSEC (Added in Shorewall version 2.2.0) + IPSEC If you specify a value other than "-" in this column, you must @@ -2424,32 +2434,29 @@ 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" />. + 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. + 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 - <emphasis role="bold">(Shorewall version >= 2.0.2 Beta - 1):</emphasis> You want all outgoing SMTP traffic entering the firewall - on eth1 to be sent from eth0 with source IP address 206.124.146.177. You - want all other outgoing traffic from eth1 to be sent from eth0 with - source IP address 206.124.146.176. + You want all outgoing SMTP traffic entering the firewall on eth1 + to be sent from eth0 with source IP address 206.124.146.177. You want + all other outgoing traffic from eth1 to be sent from eth0 with source IP + address 206.124.146.176. #INTERFACE SUBNET ADDRESS PROTO PORT(S) eth0 eth1 206.124.146.177 tcp 25 @@ -2619,18 +2626,17 @@ eth0 eth1 206.124.146.176 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. + 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. - Beginning with Shorewall 2.1.1, the effect of - ADD_IP_ALIASES=Yes can be negated for an entry by following the - interface name by ":" but no digit. + The effect of ADD_IP_ALIASES=Yes can be negated for an entry + by following the interface name by ":" but no digit. Example: @@ -2664,15 +2670,8 @@ eth0 eth1 206.124.146.176 If Yes or yes, NAT will be effective from the firewall system. Note that with Shorewall 2.0.1 and earlier versions, this column was ignored if the ALL INTERFACES column did not contain "Yes" or "yes". - Beginning with Shorewall 2.0.2 Beta 1, this column's contents are - independent of the value in ALL INTERFACES. - - - 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. - + This column's contents are independent of the value in ALL + INTERFACES. @@ -2708,13 +2707,30 @@ eth0 eth1 206.124.146.176 This file is used to set the following firewall parameters: + + FASTACCEPT + + + Normally, Shorewall accepting ESTABLISHED/RELATED packets + until these packets reach the chain in which the original connection + was accepted. So for packets going from the 'loc' zone to the 'net' + zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net' + chain. + + If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets + are accepted early in the INPUT, FORWARD and OUTPUT chains. If you + set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED + or RELATED sections of /etc/shorewall/rules. + + + STARTUP_ENABLED - (Added at version 2.2.0) - When set to Yes or yes, Shorewall - may be started. Used as guard against Shorewall being accidentally - started before it has been configured. + When set to Yes or yes, Shorewall may be started. Used as + guard against Shorewall being accidentally started before it has + been configured. @@ -2722,10 +2738,9 @@ eth0 eth1 206.124.146.176 MACLIST_TTL - (Added at version 2.2.0) The performance of configurations - with a large numbers of entries in /etc/shorewall/maclist can be - improved by setting the MACLIST_TTL variable in - /etc/shorewall/shorewall.conf. + The performance of configurations with a large numbers of + entries in /etc/shorewall/maclist can be improved by setting the + MACLIST_TTL variable in /etc/shorewall/shorewall.conf. If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the @@ -2753,11 +2768,10 @@ eth0 eth1 206.124.146.176 RFC1918_STRICT - (Added at version 2.2.2) — Traditionally, the RETURN target in - the 'rfc1918' file has caused norfc1918 processing to cease for a - packet if the packet's source IP address matches the rule. Thus, if - you have this entry in Traditionally, the RETURN target in the 'rfc1918' file has + caused norfc1918 processing to + cease for a packet if the packet's source IP address matches the + rule. Thus, if you have this entry in /etc/shorewall/rfc1918: #SUBNETS TARGET @@ -2784,42 +2798,13 @@ eth0 eth1 206.124.146.176 - - DROPINVALID - - - (Added at version 2.2.0 and backported into version 2.0.16) — - Recent 2.6 kernels include code that evaluates TCP packets based on - TCP Window analysis. This can cause packets that were previously - classified as NEW or ESTABLISHED to be classified as INVALID. - - The new kernel code can be disabled by including this command - in your /etc/shorewall/init - file: - - echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal - - Additional kernel logging about INVALID TCP packets may be - obtained by adding this command to /etc/shorewall/init: - - echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid - - Traditionally, Shorewall has dropped INVALID TCP packets - early. The DROPINVALID option allows INVALID packets to be passed - through the normal rules chains by setting DROPINVALID=No. If not - specified or if specified as empty (e.g., DROPINVALID="") then - DROPINVALID=Yes is assumed. - - - LOGALLNEW - (Aded at version 2.2.0)- When set to a log level, this option - causes Shorewall to generate a logging rule as the first rule in - each builtin chain. + When set to a log level, this option causes Shorewall to + generate a logging rule as the first rule in each builtin + chain. @@ -2857,8 +2842,8 @@ eth0 eth1 206.124.146.176 DYNAMIC_ZONES - (Added at version 2.0.2) - When set to Yes or yes, enables - dynamic zones. + When set to Yes or yes, enables dynamic + zones. @@ -2866,10 +2851,10 @@ eth0 eth1 206.124.146.176 CONFIG_PATH - (Added at version 2.0.2) - Specifies where configuration files - other than shorewall.conf may be found. - CONFIG_PATH is specifies as a list of directory names separated by - colons (":"). When looking for a configuration file other than + Specifies where configuration files other than + shorewall.conf may be found. CONFIG_PATH is + specifies as a list of directory names separated by colons (":"). + When looking for a configuration file other than shorewall.conf: @@ -2903,9 +2888,8 @@ eth0 eth1 206.124.146.176 PKTTYPE - (Added at Version 2.0.6) - Normally Shorewall attempts to use - the iptables packet type match extension to determine broadcast and - multicast packets. + Normally Shorewall attempts to use the iptables packet type + match extension to determine broadcast and multicast packets. @@ -2932,10 +2916,10 @@ eth0 eth1 206.124.146.176 RESTOREFILE - (Added at version 2.0.3 Beta 1) - The simple name of a file - in /var/lib/shorewall to be used as the default - restore script in the shorewall save, shorewall restore, shorewall - forget and shorewall -f start commands. See the The simple name of a file in + /var/lib/shorewall to be used as the default restore + script in the shorewall save, shorewall restore, shorewall forget + and shorewall -f start commands. See the Saved Configuration documentation for details. @@ -2945,8 +2929,8 @@ eth0 eth1 206.124.146.176 BRIDGING - (Added at version 2.0.1) - When set to Yes or yes, enables - Shorewall Bridging support. + When set to Yes or yes, enables Shorewall Bridging support. @@ -2954,9 +2938,8 @@ eth0 eth1 206.124.146.176 SMURF_LOG_LEVEL - (Added at version 2.0.0) - Specifies the logging level for - smurf packets (see the nosmurfs - option in Specifies the logging level for smurf packets (see the + nosmurfs option in /etc/shorewall/interfaces). If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not logged. @@ -2967,10 +2950,9 @@ eth0 eth1 206.124.146.176 MODULE_SUFFIX - (Added at version 1.4.9) - The value of this variable - determines the possible file extensions of kernel modules. The - default value is "o gz ko and o.gz". See - for more details. + The value of this variable determines the possible file + extensions of kernel modules. The default value is "o gz ko and + o.gz". See for more details. @@ -2978,12 +2960,12 @@ eth0 eth1 206.124.146.176 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 + 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 @@ -2996,10 +2978,10 @@ eth0 eth1 206.124.146.176 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. + 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. @@ -3007,10 +2989,10 @@ eth0 eth1 206.124.146.176 IPTABLES - (Added at version 2.2.0) — This parameter names the iptables - executable to be used by Shorewall. If not specified or if specified - as a null value, then the iptables executable located using the PATH - option is used. + This parameter names the iptables executable to be used by + Shorewall. If not specified or if specified as a null value, then + the iptables executable located using the PATH option is + used. @@ -3018,11 +3000,11 @@ eth0 eth1 206.124.146.176 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 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 " @@ -3051,15 +3033,15 @@ eth0 eth1 206.124.146.176 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 + 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. @@ -3069,19 +3051,18 @@ eth0 eth1 206.124.146.176 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. + 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. @@ -3089,40 +3070,25 @@ eth0 eth1 206.124.146.176 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 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. - - BOGON_LOG_LEVEL - - - (Added at version 2.0.1) - This parameter determines the level - at which packets logged under the nobogons mechanism are - logged. The value must be a valid syslog level and if no level is - given, then info is assumed. - - - 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. + 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. @@ -3130,12 +3096,11 @@ eth0 eth1 206.124.146.176 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., + 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=""). @@ -3144,13 +3109,13 @@ eth0 eth1 206.124.146.176 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. + 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. @@ -3158,12 +3123,12 @@ eth0 eth1 206.124.146.176 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=""). + 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=""). @@ -3171,12 +3136,12 @@ eth0 eth1 206.124.146.176 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 connection 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. + When set to Yes or yes, + Shorewall will filter TCP packets that are not part of an + established connection 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 @@ -3204,12 +3169,11 @@ eth0 eth1 206.124.146.176 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| + Shorewall can be configured to drop non-SYN TCP packets that + are not part of an existing connection (see NEWNOTSYN above). 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 a @@ -3223,7 +3187,7 @@ eth0 eth1 206.124.146.176 LOG_MARTIANS - (Added in Version 2.2.0) - If set to Yes or yes, sets + If set to Yes or yes, sets /proc/sys/net/ipv4/conf/all/log_martians and /proc/sys/net/ipv4/conf/default/log_martians to 1. Default is which sets both of the above to zero. If you do not @@ -3238,14 +3202,13 @@ eth0 eth1 206.124.146.176 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. + 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. @@ -3286,23 +3249,6 @@ eth0 eth1 206.124.146.176 - - 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 @@ -3433,18 +3379,17 @@ LOGBURST=5 RETAIN_ALIASES - (Added in 2.2.0) - During "shorewall start", IP addresses to - be added as a consequence of ADD_IP_ALIASES=Yes and - ADD_SNAT_ALIASES=Yes are quietly deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed then are - re-added later. This is done to help ensure that the addresses can - be added with the specified labels but can have the undesirable side - effect of causing routes to be quietly deleted. When RETAIN_ALIASES - is set to Yes, existing addresses will not be deleted. Regardless of - the setting of RETAIN_ALIASES, addresses added during "shorewall - start" are still deleted at a subsequent "shorewall stop" or - "shorewall restart". + During "shorewall start", IP addresses to be added as a + consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are + quietly deleted when /etc/shorewall/nat + and /etc/shorewall/masq are processed + then are re-added later. This is done to help ensure that the + addresses can be added with the specified labels but can have the + undesirable side effect of causing routes to be quietly deleted. + When RETAIN_ALIASES is set to Yes, existing addresses will not be + deleted. Regardless of the setting of RETAIN_ALIASES, addresses + added during "shorewall start" are still deleted at a subsequent + "shorewall stop" or "shorewall restart". @@ -3491,9 +3436,9 @@ LOGBURST=5 DELAYBLACKLISTLOAD - (Added in Shorewall 2.2.0) - Users with a large static black - list (/etc/shorewall/blacklist) may want to set - the DELAYBLACKLISTLOAD option to Yes. When DELAYBLACKLISTLOAD=Yes, + Users with a large static black list + (/etc/shorewall/blacklist) may want to set the + DELAYBLACKLISTLOAD option to Yes. When DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before loading the blacklist rules. While this may allow connections from blacklisted hosts to slip by during construction of the blacklist, it can substantially @@ -3503,7 +3448,7 @@ LOGBURST=5 - CLAMPMSS + CLAMPMSS[=<value>] This parameter enables the TCP Clamp MSS to PMTU feature of @@ -3518,10 +3463,9 @@ LOGBURST=5 url="kernel.htm">in your kernel. - Beginning with Shorewall version 2.2.0, you may also set - CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This will set the - MSS field in TCP SYN packets going through the firewall to the value - that you specify. + You may also set CLAMPMSS to a numeric value (e.g., + CLAMPMSS=1400). This will set the MSS field in TCP SYN packets going + through the firewall to the value that you specify. @@ -3593,13 +3537,12 @@ LOGBURST=5 insmod <moduledirectory>/<modulename>.o.gz <module parameters> - Beginning with the 1.4.9 Shorewall release, the value of the - MODULE_SUFFIX option in determines which files the loadmodule function - looks for if the named module doesn't exist. For each file - <extension> listed in MODULE_SUFFIX (default "o - gz ko o.gz"), the function will append a period (".") and the extension - and if the resulting file exists then the following command will be - executed: + The value of the MODULE_SUFFIX option in determines which files the + loadmodule function looks for if the named module doesn't exist. For each + file <extension> listed in MODULE_SUFFIX + (default "o gz ko o.gz"), the function will append a period (".") and the + extension and if the resulting file exists then the following command will + be executed: insmod moduledirectory/<modulename>.<extension> <module parameters>
@@ -3732,8 +3675,7 @@ all all tcp ftp-data - 8your network. - Beginning with Shorewall 1.3.8, the blacklist file has three - columns: + The blacklist file has three columns: @@ -3781,8 +3723,7 @@ all all tcp ftp-data - 8
- /etc/shorewall/rfc1918 — Moved to /usr/share/shorewall in Version - 2.0.0 + /usr/share/shorewall/rfc1918 This file lists the subnets affected by the norfc1918 interface option. Columns in the @@ -3841,67 +3782,8 @@ all all tcp ftp-data - 8/etc/shorewall/rfc1918 and modify the copy.
-
- /usr/share/shorewall/bogons — Added in Version 2.0.1 - - This file lists the subnets affected by the nobogons interface option and nobogons hosts 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 BOGONS_LOG_LEVEL parameter above. - - - - - - - - If you want to modify this file, DO NOT MODIFY - /usr/share/shorewall/bogons. Rather copy that file to - /etc/shorewall/bogons and modify the copy. -
-
- /etc/shorewall/netmap (Added in Version 2.0.1) + /etc/shorewall/netmap Network mapping is defined using the /etc/shorewall/netmap file. Columns in this file @@ -3957,12 +3839,11 @@ all all tcp ftp-data - 8
- /etc/shorewall/routestopped (Added in Version 1.3.4) + /etc/shorewall/routestopped This file defines the hosts that are accessible from the firewall - when the firewall is stopped. Beginning with Shorewall version 2.2.3, - entries in this file are also active while Shorewall is being - [re]started. + when the firewall is stopped. Entries in this file are also active while + Shorewall is being stopped or [re]started. Columns in the file are: @@ -3996,29 +3877,24 @@ eth2 192.168.1.0/24 eth1 - - - - Prior to Shorewall version 2.2.3, the contents of the - /etc/shorewall/routestopped file did NOT affect - connection attempts occurring during the processing of the - shorewall start and shorewall - restart commands. Beginning with version 2.2.3, Shorewall - allows connections defined by the contents of + Shorewall allows connections defined by the contents of /etc/shorewall/routestopped during the potentially - lengthy processing of those commands. + lengthy processing of the commands shorewall start, + shorewall restart, shorewall try + and shorewall stop.
- /etc/shorewall/maclist (Added in Version 1.3.10) + /etc/shorewall/maclist This file is described in the MAC Validation Documentation.
- /etc/shorewall/ecn (Added in Version 1.4.0) + /etc/shorewall/ecn This file is described in the ECN Control Documentation. @@ -4031,111 +3907,20 @@ eth1 - Accounting Documentation.
-
- /etc/shorewall/ipsec (Added in Version 2.1.6) - - This file is used to identify the Security Associations used to - encrypt traffic to hosts in a zone and to decrypt traffic from hosts in a - zone. Use of this file requires a 2.6 kernel that includes the - IPSEC-Netfilter patches and the policy match patch. Your iptables must - also support policy match. For additional information, see the Shorewall Kernel 2.6 IPSEC - documentation. - - - - Columns are: - - - - ZONE - - - The name of a zone defined in /etc/shorewall/zones. - - - - - IPSEC - - - - Yes - All traffic to/from this zone is encrypted. - - No - Only traffic to/from some of the hosts in this zone - is encrypted. Those encrypted hosts are designated using the - ipsec option in /etc/shorewall/hosts. - - - - - - OPTIONS, IN OPTIONS, OUT OPTIONS - - - Optional parameters that identify the security policy and - security associations used in communication with hosts in this zone. - A comma-separated list of the following: - - - proto[!]=ah|esp|ipcomp - - mode[!]=transport|tunnel - - reqid[!]=<number> - — A number assigned to a security policy using the - unique:<number> as the SPD level. See setkey(8). - - tunnel-src[!]=<address>[/<mask>] - — Tunnel Source; may only be included with mode=tunnel. Since - tunnel source and destination are dependent on the direction of - the traffic, this option and the following one should only be - included in the IN OPTIONS and OUT OPTIONS columns. - - tunnel-dst[!]=<address>[/<mask>] - — Tunnel Destination; may only be included with - mode=tunnel. - - mss=<number> — Sets - the MSS field in TCP syn packets forwarded to/from this zone. May - be used to compensate for the lack of IPSEC pseudo-devices with - their own MTU in the 2.6 Kernel IPSEC implementation. If specified - in the IN OPTIONS, TCP SYN packets from the zone will have MSS - altered; if specified in the OUT OPTIONS, TCP SYN packets to the - zone will have MSS altered. - - spi[!]=<number> - — The security parameter index of the Security Association. Since - a different SA is used for incoming and outgoing traffic, this - option should only be listed in the IN OPTIONS and OUT OPTIONS - columns. - - strict — Must be - specified when SPD rules are used (e.g., esp encapsulated with - ah). - - next — Separates rules - when strict is used. - - - - - - See the IPSEC with 2.6 Kernel - documentation for further information. -
- Revision History + + 1.25 + + 2005-08-28 + + TE + + Changes for 3.0. + + 1.24 diff --git a/Shorewall-docs2/blacklisting_support.xml b/Shorewall-docs2/blacklisting_support.xml index 58166b91a..0bc157217 100644 --- a/Shorewall-docs2/blacklisting_support.xml +++ b/Shorewall-docs2/blacklisting_support.xml @@ -15,10 +15,10 @@ - 2004-10-25 + 2005-08-28 - 2002-2004 + 2002-2005 Thomas M. Eastep @@ -38,16 +38,14 @@ Introduction Shorewall supports two different forms of blacklisting; static and - dynamic. Beginning with Shorewall version 1.4.8, the BLACKLISTNEWONLY - option in /etc/shorewall/shorewall.conf controls the degree of blacklist - filtering: + dynamic. The BLACKLISTNEWONLY option in /etc/shorewall/shorewall.conf + controls the degree of blacklist filtering: BLACKLISTNEWONLY=No --  All incoming packets are checked against the blacklist. New blacklist entries can be used to terminate - existing connections. Versions of Shorewall prior to 1.4.8 behave in - this manner. + existing connections. @@ -66,10 +64,12 @@ - Neither form of Shorewall blacklisting is - appropriate for blacklisting 1,000s of different addresses. - The blacklists will take forever to load and will have a very negative - effect on firewall performance. + Dynamic Shorewall blacklisting is not + appropriate for blacklisting 1,000s of different addresses. Static + Blacklisting can handle large blacklists but only if you use + ipsets. Without ipsets, the blacklists will take forever to + load and will have a very negative effect on firewall + performance.
@@ -97,8 +97,8 @@ You list the IP addresses/subnets that you wish to blacklist in /etc/shorewall/blacklist. - Beginning with Shorewall version 1.3.8, you may also specify PROTOCOL - and Port numbers/Service names in the blacklist file. + You may also specify PROTOCOL and Port numbers/Service names in the + blacklist file. @@ -123,14 +123,41 @@ blacklisted hosts to slip by during construction of the blacklist, it can substantially reduce the time that all new connections are disabled during "shorewall [re]start". + + Beginning with Shorewall 2.4.0, you can use ipsets to define your static blacklist. Here's + an example: + + #ADDRESS/SUBNET PROTOCOL PORT ++Blacklistports[dst] ++Blacklistnets[src,dst] ++Blacklist[src,dst] +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE + + In this example, there is a portmap ipset + Blacklistports that blacklists all traffic with + destination ports included in the ipsec. There are also + Blacklistnets (type nethash) and + Blacklist (type iphash) ipsets + that allow blacklisting networks and individual IP addresses. Note that + [src,dst] is specified so that individual entries in the sets can be bound + to other portmap ipsets to allow blacklisting (source + address, destination port) combinations. + For example: + + ipset -N SMTP portmap --from 1 --to 31 +ipset -A SMTP 25 +ipset -A Blacklist 206.124.146.177 +ipset -B Blacklist 206.124.146.177 -b SMTP + + This will blacklist SMTP traffic from host 206.124.146.177.
Dynamic Blacklisting - Dynamic blacklisting support was added in version 1.3.2. Dynamic - blacklisting doesn't use any configuration parameters but is rather - controlled using /sbin/shorewall commands: + Dynamic blacklisting doesn't use any configuration parameters but is + rather controlled using /sbin/shorewall commands: diff --git a/Shorewall-docs2/configuration_file_basics.xml b/Shorewall-docs2/configuration_file_basics.xml index 23db94cb6..86b07dd5e 100644 --- a/Shorewall-docs2/configuration_file_basics.xml +++ b/Shorewall-docs2/configuration_file_basics.xml @@ -15,7 +15,7 @@ - 2005-06-02 + 2005-08-28 2001-2005 @@ -201,15 +201,6 @@ /etc/shorewall and modify the copy. - - - /usr/share/bogons — Defines the behavior - of the 'nobogons' interface option in - /etc/shorewall/interfaces. If you need to change this file, copy it to - /etc/shorewall and modify the - copy. -