diff --git a/Shorewall/Documentation b/Shorewall/Documentation deleted file mode 100644 index 8303e8f78..000000000 --- a/Shorewall/Documentation +++ /dev/null @@ -1,2560 +0,0 @@ -################################################################################ - This documentation provides a quick reference to the configuration - files. - -Please refer to http://www.shorewall.net/Documentation_Index.html for -the complete Shorewall documentation. - -Copyright © 2006 Thomas M. Eastep - -Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no -Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. -################################################################################ - /etc/shorewall/accounting - - Accounting rules exist simply to count packets and bytes in categories - that you define in this file. You may display these rules and their - packet and byte counters using the "shorewall show accounting" command. - - Please see http://shorewall.net/Accounting.html for examples and - additional information about how to use this file. - - - Columns are: - - ACTION - What to do when a match is found. - - COUNT - Simply count the match and continue - with the next rule - DONE - Count the match and don't attempt - to match any other accounting rules - in the chain specified in the CHAIN - column. - [:COUNT] - - Where is the name of - a chain. Shorewall will create - the chain automatically if it - doesn't already exist. Causes - a jump to that chain. If :COUNT - is including, a counting rule - matching this record will be - added to - - CHAIN - The name of a chain. If specified as "-" the - 'accounting' chain is assumed. This is the chain - where the accounting rule is added. The chain will - be created if it doesn't already exist. - - SOURCE - Packet Source - - The name of an interface, an address (host or net) or - an interface name followed by ":" - and a host or net address. - - DESTINATION - Packet Destination - - Format the same as the SOURCE column. - - PROTOCOL A protocol name (from /etc/protocols), a protocol - number, "ipp2p", "ipp2p:udp" or "ipp2p:all" - - DEST PORT(S) Destination Port number. If the PROTOCOL is "ipp2p" - then this column must contain an ipp2p option - ("iptables -m ipp2p --help") without the leading - "--". If no option is given in this column, "ipp2p" - is assumed. - - Service name from /etc/services or port number. May - only be specified if the protocol is TCP or UDP (6 - or 17). - - You may place a comma-separated list of port numbers in - this column if your kernel and iptables include - multiport match support. - - SOURCE PORT(S) Source Port number - - Service name from /etc/services or port number. May - only be specified if the protocol is TCP or UDP (6 - or 17). - - You may place a comma-separated list of port numbers in - this column if your kernel and iptables include - multiport match support. - - USER/GROUP This column may only be non-empty if the CHAIN is - OUTPUT. - - The column may contain: - - [!][][:][+] - - When this column is non-empty, the rule applies only - if the program generating the output is running under - the effective and/or specified (or is - NOT running under that id if "!" is given). - - Examples: - - joe #program must be run by joe - :kids #program must be run by a member of - #the 'kids' group - !:kids #program must not be run by a member - #of the 'kids' group - +upnpd #program named upnpd (This feature was - #removed from Netfilter in kernel - #version 2.6.14). - - In all of the above columns except ACTION and CHAIN, the values "-", - "any" and "all" may be used as wildcards. Omitted trailing columns are - also treated as wildcards. - - Please see http://shorewall.net/Accounting.html for examples and - additional information about how to use this file. - -################################################################################ - /etc/shorewall/blacklist - - This file contains a list of IP addresses, MAC addresses and/or - subnetworks. - - Columns are: - - ADDRESS/SUBNET - Host address, subnetwork, MAC address, IP address - range (if your kernel and iptables contain iprange - match support) or ipset name prefaced by "+" (if - your kernel supports ipset match). - - MAC addresses must be prefixed with "~" and use "-" - as a separator. - - Example: ~00-A0-C9-15-39-78 - - A dash ("-") in this column means that any source - address will match. This is useful if you want to - blacklist a particular application. - - PROTOCOL - Optional. If specified, must be a protocol number - or a protocol name from /etc/protocols. - - PORTS - Optional. May only be specified if the protocol - is TCP (6) or UDP (17). A comma-separated list - of destination port numbers or service names from - /etc/services. - - When a packet arrives on an interface that has the 'blacklist' option - specified in /etc/shorewall/interfaces, its source IP address is - checked against this file and disposed of according to the - BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL variables in - /etc/shorewall/shorewall.conf - - If PROTOCOL or PROTOCOL and PORTS are supplied, only packets matching - the protocol (and one of the ports if PORTS supplied) are blocked. - - Example: - - To block DNS queries from address 192.0.2.126: - - ADDRESS/SUBNET PROTOCOL PORT - 192.0.2.126 udp 53 - - Example: - - To block DNS queries from addresses in the ipset 'dnsblack': - - ADDRESS/SUBNET PROTOCOL PORT - +dnsblack udp 53 - - Please see http://shorewall.net/blacklisting_support.htm for additional - information. - -################################################################################ - /etc/shorewall/ecn - - Use this file to list the destinations for which you want to - disable ECN. - - This feature requires kernel 2.4.20 or later. If you run 2.4.20, - you also need the patch found at http://www.shorewall.net/ecn/patch. - That patch is included in kernels 2.4.21 and later. - - INTERFACE - Interface through which host(s) communicate with - the firewall - HOST(S) - (Optional) Comma-separated list of IP/subnet - If left empty or supplied as "-", - 0.0.0.0/0 is assumed. If your kernel and iptables - include iprange match support then IP address ranges - are also permitted. - - For additional information, see http://shorewall.net/Documentation.htm#ECN - -################################################################################ - /etc/shorewall/hosts - - THE ONLY TIME YOU NEED THIS FILE IS WHERE YOU HAVE MORE THAN - ONE ZONE CONNECTED THROUGH A SINGLE INTERFACE. - - IF YOU DON'T HAVE THAT SITUATION THEN DON'T TOUCH THIS FILE. ------------------------------------------------------------------------------- - IF YOU HAVE AN ENTRY FOR A ZONE AND INTERFACE IN - /etc/shorewall/interfaces THEN DO NOT ADD ANY ENTRIES FOR THAT - ZONE AND INTERFACE IN THIS FILE. ------------------------------------------------------------------------------- - This file is used to define zones in terms of subnets and/or - individual IP addresses. Most simple setups don't need to - (should not) place anything in this file. - - The order of entries in this file is not significant in - determining zone composition. Rather, the order that the zones - are defined in /etc/shorewall/zones determines the order in - which the records in this file are interpreted. - - ZONE - The name of a zone defined in /etc/shorewall/zones. You may - not list the firewall zone in this column. - - HOST(S) - The name of an interface defined in the - /etc/shorewall/interfaces file followed by a colon (":") and - a comma-separated list whose elements are either: - - a) The IP address of a host - b) A subnetwork in the form - / - c) An IP address range of the form -. Your kernel and iptables must have iprange - match support. - d) 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 or a range. - See http://www.shorewall.net/bridge.html - for details. Specifying a physical port - name requires that you have BRIDGING=Yes in - /etc/shorewall/shorewall.conf. - e) The name of an ipset (preceded by "+"). - - Examples: - - eth1:192.168.1.3 - eth2:192.168.2.0/24 - eth3:192.168.2.0/24,192.168.3.1 - br0:eth4 - br0:eth0:192.168.1.16/28 - eth4:192.168.1.44-192.168.1.49 - eth2:+Admin - - OPTIONS - A comma-separated list of options. Currently-defined - options are: - - maclist - Connection requests from these hosts - are compared against the contents of - /etc/shorewall/maclist. If this option - is specified, the interface must be - an ethernet NIC and must be up before - Shorewall is started. - - routeback - Shorewall should set up the - infrastructure to pass packets - from this/these address(es) back - to themselves. This is necessary if - hosts in this group use the services - of a transparent proxy that is - a member of the group or if DNAT is used - to send requests originating from this - group to a server in the group. - - norfc1918 - This option only makes sense for ports - on a bridge. - - The port should not accept - any packets whose source is in one - of the ranges reserved by RFC 1918 - (i.e., private or "non-routable" - addresses. If packet mangling or - connection-tracking match is enabled in - your kernel, packets whose destination - addresses are reserved by RFC 1918 are - also rejected. - - blacklist - This option only makes sense for ports - on a bridge. - - Check packets arriving on this port - against the /etc/shorewall/blacklist - file. - - tcpflags - Packets arriving from these hosts are - checked for certain illegal combinations - of TCP flags. Packets found to have - such a combination of flags are handled - according to the setting of - TCP_FLAGS_DISPOSITION after having been - logged according to the setting of - TCP_FLAGS_LOG_LEVEL. - - nosmurfs - This option only makes sense for ports - on a bridge. - - Filter packets for smurfs - (packets with a broadcast - address as the source). - - Smurfs will be optionally logged based - on the setting of SMURF_LOG_LEVEL in - shorewall.conf. After logging, the - packets are dropped. - - ipsec - The zone is 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 the 'ipsec' - option here. - - For additional information, see http://shorewall.net/Documentation.htm#Hosts - -################################################################################ - /etc/shorewall/interfaces - - You must add an entry in this file for each network interface on your - firewall system. - - Columns are: - - ZONE Zone for this interface. Must match the name of a - zone defined in /etc/shorewall/zones. You may not - list the firewall zone in this column. - - If the interface serves multiple zones that will be - defined in the /etc/shorewall/hosts file, you should - place "-" in this column. - - If there are multiple interfaces to the same zone, - you must list them in separate entries: - - Example: - - loc eth1 - - loc eth2 - - - INTERFACE Name of interface. Each interface may be listed only - once in this file. You may NOT specify the name of - an alias (e.g., eth0:0) here; see - http://www.shorewall.net/FAQ.htm#faq18 - - You may specify wildcards here. For example, if you - want to make an entry that applies to all PPP - interfaces, use 'ppp+'. - - There is no need to define the loopback interface (lo) - in this file. - - BROADCAST The broadcast address for the subnetwork to which the - interface belongs. For P-T-P interfaces, this - column is left blank.If the interface has multiple - addresses on multiple subnets then list the broadcast - addresses as a comma-separated list. - - If you use the special value "detect", Shorewall - will detect the broadcast address(es) for you. If you - select this option, the interface must be up before - the firewall is started. - - If you don't want to give a value for this column but - you want to enter a value in the OPTIONS column, enter - "-" in this column. - - OPTIONS A comma-separated list of options including the - following: - - dhcp - Specify this option when any of - the following are true: - 1. the interface gets its IP address - via DHCP - 2. the interface is used by - a DHCP server running on the firewall - 3. you have a static IP but are on a LAN - segment with lots of Laptop DHCP - clients. - 4. the interface is a bridge with - a DHCP server on one port and DHCP - clients on another port. - - norfc1918 - This interface should not receive - any packets whose source is in one - of the ranges reserved by RFC 1918 - (i.e., private or "non-routable" - addresses). If packet mangling or - connection-tracking match is enabled in - your kernel, packets whose destination - addresses are reserved by RFC 1918 are - also rejected. - - routefilter - turn on kernel route filtering for this - interface (anti-spoofing measure). This - option can also be enabled globally in - the /etc/shorewall/shorewall.conf file. - - logmartians - turn on kernel martian logging (logging - of packets with impossible source - addresses. It is suggested that if you - set routefilter on an interface that - you also set logmartians. This option - may also be enabled globally in the - /etc/shorewall/shorewall.conf file. - - blacklist - Check packets arriving on this interface - against the /etc/shorewall/blacklist - file. - - maclist - Connection requests from this interface - are compared against the contents of - /etc/shorewall/maclist. If this option - is specified, the interface must be - an ethernet NIC and must be up before - Shorewall is started. - - tcpflags - Packets arriving on this interface are - checked for certain illegal combinations - of TCP flags. Packets found to have - such a combination of flags are handled - according to the setting of - TCP_FLAGS_DISPOSITION after having been - logged according to the setting of - TCP_FLAGS_LOG_LEVEL. - - proxyarp - - Sets - /proc/sys/net/ipv4/conf//proxy_arp. - Do NOT use this option if you are - employing Proxy ARP through entries in - /etc/shorewall/proxyarp. This option is - intended soley for use with Proxy ARP - sub-networking as described at: - http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet - - routeback - If specified, indicates that Shorewall - should include rules that allow - filtering traffic arriving on this - interface back out that same interface. - - arp_filter - If specified, this interface will only - respond to ARP who-has requests for IP - addresses configured on the interface. - If not specified, the interface can - respond to ARP who-has requests for - IP addresses on any of the firewall's - interface. The interface must be up - when Shorewall is started. - - arp_ignore[=] - - If specified, this interface will - respond to arp requests based on the - value of . - - 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 is given then the value - 1 is assumed - - WARNING -- DO NOT SPECIFY arp_ignore - FOR ANY INTERFACE INVOLVED IN PROXY ARP. - - nosmurfs - Filter packets for smurfs - (packets with a broadcast - address as the source). - - Smurfs will be optionally logged based - on the setting of SMURF_LOG_LEVEL in - shorewall.conf. After logging, the - packets are dropped. - - detectnets - Automatically taylors the zone named - in the ZONE column to include only those - hosts routed through the interface. - - sourceroute - 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// - accept_source_route to 1). - Only set this option if you know what - you are you doing. This might represent - a security risk and is not usually - needed. - - upnp - Incoming requests from this interface - may be remapped via UPNP (upnpd). - - WARNING: DO NOT SET THE detectnets OPTION ON YOUR - INTERNET INTERFACE. - - The order in which you list the options is not - significant but the list should have no embedded white - space. - - Example 1: Suppose you have eth0 connected to a DSL modem and - eth1 connected to your local network and that your - local subnet is 192.168.1.0/24. The interface gets - it's IP address via DHCP from subnet - 206.191.149.192/27. You have a DMZ with subnet - 192.168.2.0/24 using eth2. - - Your entries for this setup would look like: - - net eth0 206.191.149.223 dhcp - local eth1 192.168.1.255 - dmz eth2 192.168.2.255 - - Example 2: The same configuration without specifying broadcast - addresses is: - - net eth0 detect dhcp - loc eth1 detect - dmz eth2 detect - - Example 3: You have a simple dial-in system with no ethernet - connections. - - net ppp0 - - - For additional information, see - http://shorewall.net/Documentation.htm#Interfaces - -################################################################################ - /etc/shorewall/maclist - - This file is used to define the MAC addresses and optionally their - associated IP addresses to be allowed to use the specified interface. - The feature is enabled by using the maclist option in the interfaces - or hosts configuration file. - - Columns are: - - DISPOSITION ACCEPT or DROP (if MACLIST_TABLE=filter, then REJECT - is also allowed) - - INTERFACE Network interface to a host. If the interface - names a bridge, it may be optionally followed by - a colon (":") and a physical port name (e.g., - br0:eth4). - - MAC MAC address of the host -- you do not need to use - the Shorewall format for MAC addresses here. If IP - ADDRESSES is supplied then MAC can be supplied as - a dash ("-") - - IP ADDRESSES Optional -- if specified, both the MAC and IP address - must match. This column can contain a comma-separated - list of host and/or subnet addresses. If your kernel - and iptables have iprange match support then IP - address ranges are also allowed. - - For additional information, see http://shorewall.net/MAC_Validation.html - -################################################################################ - /etc/shorewall/masq - - Use this file to define dynamic NAT (Masquerading) and to define - Source NAT (SNAT). - - WARNING: The entries in this file are order-sensitive. The first - entry that matches a particular connection will be the one that - is used. - - WARNING: If you have more than one ISP, adding entries to this - file will *not* force connections to go out through a particular - ISP. You must use PREROUTING entries in /etc/shorewall/tcrules - to do that. - - Columns are: - - INTERFACE -- Outgoing interface. This is usually your internet - interface. If ADD_SNAT_ALIASES=Yes in - /etc/shorewall/shorewall.conf, you may add ":" and - a digit to indicate that you want the alias added with - that name (e.g., eth0:0). This will allow the alias to - be displayed with ifconfig. THAT IS THE ONLY USE FOR - THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER - PLACE IN YOUR SHOREWALL CONFIGURATION. - - This may be qualified by adding the character - ":" followed by a destination host or subnet. - - If you wish to inhibit the action of ADD_SNAT_ALIASES - for this entry then include the ":" but omit the digit: - - eth0: - eth2::192.0.2.32/27 - - Normally Masq/SNAT rules are evaluated after those for - one-to-one NAT (/etc/shorewall/nat file). If you want - the rule to be applied before one-to-one NAT rules, - prefix the interface name with "+": - - +eth0 - +eth0:192.0.2.32/27 - +eth0:2 - - This feature should only be required if you need to - insert rules in this file that preempt entries in - /etc/shorewall/nat. - - If you place COMMENT in this column, then the rest of the - line will be attached as a comment to the Netfilter rule(s) - generated by the following entry. The comment will appear - delimited by "/* ... */" in the output of "shorewall show - nat" - - SOURCE (formerly called SUBNET) - - Set of hosts that you wish to masquerade. You can specify this - as an address (net or host) or as an interface. If you give - the name of an interface, the interface must be up before you - start the firewall (Shorewall will use your main routing table - to determine the appropriate addresses to masquerade). - - In order to exclude a addrress of the specified SOURCE, you - may append "!" and a comma-separated list of IP addresses - (host or net) that you wish to exclude. - - Example: eth1!192.168.1.4,192.168.32.0/27 - - In that example traffic from eth1 would be masqueraded unless - it came from 192.168.1.4 or 196.168.32.0/27 - - ADDRESS -- (Optional). If you specify an address here, SNAT will be - used and this will be the source address. If - ADD_SNAT_ALIASES is set to Yes or yes in - /etc/shorewall/shorewall.conf then Shorewall - will automatically add this address to the - INTERFACE named in the first column. - - You may also specify a range of up to 256 - IP addresses if you want the SNAT address to - be assigned from that range in a round-robin - range by connection. The range is specified by - -. - - Example: 206.124.146.177-206.124.146.180 - - You may also use the special value "detect" - which causes Shorewall to determine the - IP addresses configured on the interface named - in the INTERFACES column and substitute them - in this column. - - Finally, you may also specify a comma-separated - list of ranges and/or addresses in this column. - - This column may not contain DNS Names. - - Normally, Netfilter will attempt to retain - the source port number. You may cause - netfilter to remap the source port by following - an address or range (if any) by ":" and - a port range with the format - - . If this is done, you must - specify "tcp" or "udp" in the PROTO column. - - Examples: - - 192.0.2.4:5000-6000 - :4000-5000 - - You can invoke the SAME target using the - following in this column: - - SAME:[nodst:][,...] - - The may be single addresses - or "detect" as described above. - - SAME works like SNAT with the exception that - the same local IP address is assigned to each - connection from a local address to a given - remote address. - - If the 'nodst:' option is included, then the - same source address is used for a given - internal system regardless of which remote - system is involved. - - If you want to leave this column empty - but you need to specify the next column then - place a hyphen ("-") here. - - PROTO -- (Optional) If you wish to restrict this entry to a - particular protocol then enter the protocol - name (from /etc/protocols) or number here. - - PORT(S) -- (Optional) If the PROTO column specifies TCP (protocol 6) - or UDP (protocol 17) then you may list one - or more port numbers (or names from - /etc/services) separated by commas or you - may list a single port range - (:). - - Where a comma-separated list is given, your - kernel and iptables must have multiport match - support and a maximum of 15 ports may be - listed. - - IPSEC -- (Optional) If you specify a value other than "-" in this - column, you must be running kernel 2.6 and - your kernel and iptables must include policy - match support. - - Comma-separated list of options from the - following. Only packets that will be encrypted - via an SA that matches these options will have - their source address changed. - - Yes or yes -- must be the only option - listed and matches all outbound - traffic that will be encrypted. - - reqid= where is - specified using setkey(8) using the - 'unique: option for the SPD - level. - - spi= where is the - SPI of the SA. - - proto=ah|esp|ipcomp - - mode=transport|tunnel - - tunnel-src=
[/] (only - available with mode=tunnel) - - tunnel-dst=
[/] (only - available with mode=tunnel) - - strict Means that packets must match - all rules. - - next Separates rules; can only be - used with strict.. - - Example 1: - - You have a simple masquerading setup where eth0 connects to - a DSL or cable modem and eth1 connects to your local network - with subnet 192.168.0.0/24. - - Your entry in the file can be either: - - eth0 eth1 - - or - - eth0 192.168.0.0/24 - - Example 2: - - You add a router to your local network to connect subnet - 192.168.1.0/24 which you also want to masquerade. You then - add a second entry for eth0 to this file: - - eth0 192.168.1.0/24 - - Example 3: - - You have an IPSEC tunnel through ipsec0 and you want to - masquerade packets coming from 192.168.1.0/24 but only if - these packets are destined for hosts in 10.1.1.0/24: - - ipsec0:10.1.1.0/24 196.168.1.0/24 - - Example 4: - - You want all outgoing traffic from 192.168.1.0/24 through - eth0 to use source address 206.124.146.176 which is NOT the - primary address of eth0. You want 206.124.146.176 added to - be added to eth0 with name eth0:0. - - eth0:0 192.168.1.0/24 206.124.146.176 - - Example 5: - - 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. - - eth0 eth1 206.124.146.177 tcp smtp - eth0 eth1 206.124.146.176 - - THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!! - - For additional information, see http://shorewall.net/Documentation.htm#Masq - -################################################################################ - /etc/shorewall/nat - - This file is used to define one-to-one Network Address Translation - (NAT). - - WARNING: If all you want to do is simple port forwarding, do NOT use this - file. See http://www.shorewall.net/FAQ.htm#faq1. Also, in most - cases, Proxy ARP is a better solution that one-to-one NAT. - - Columns are: - - EXTERNAL External IP Address - this should NOT be the primary - IP address of the interface named in the next - column and must not be a DNS Name. - - If you put COMMENT in this column, the rest of the - line will be attached as a comment to the Netfilter - rule(s) generated by the following entries in the - file. The comment will appear delimited by "/* ... */" - in the output of "shorewall show nat" - - To stop the comment from being attached to further - rules, simply include COMMENT on a line by itself. - - INTERFACE Interface that has the EXTERNAL address. - If ADD_IP_ALIASES=Yes in shorewall.conf, Shorewall - will automatically add the EXTERNAL address to this - interface. Also if ADD_IP_ALIASES=Yes, you may - follow the interface name with ":" and a digit to - indicate that you want Shorewall to add the alias - with this name (e.g., "eth0:0"). That allows you to - see the alias with ifconfig. THAT IS THE ONLY THING - THAT THIS NAME IS GOOD FOR -- YOU CANNOT USE IT - ANYWHERE ELSE IN YOUR SHORWALL CONFIGURATION. - - If you want to override ADD_IP_ALIASES=Yes for a - particular entry, follow the interface name with - ":" and no digit (e.g., "eth0:"). - INTERNAL Internal Address (must not be a DNS Name). - - ALL INTERFACES If Yes or yes, NAT will be effective from all hosts. - If No or no (or left empty) then NAT will be effective - only through the interface named in the INTERFACE - column - - LOCAL If Yes or yes, NAT will be effective from the firewall - system - - For additional information, see http://shorewall.net/NAT.htm - -################################################################################ - /etc/shorewall/netmap - - This file is used to map addresses in one network to corresponding - addresses in a second network. - - WARNING: To use this file, your kernel and iptables must have - NETMAP support included. - - Columns are: - - TYPE Must be DNAT or SNAT. - - If DNAT, traffic entering INTERFACE and addressed to - NET1 has it's destination address rewritten to the - corresponding address in NET2. - - If SNAT, traffic leaving INTERFACE with a source - address in NET1 has it's source address rewritten to - the corresponding address in NET2. - - NET1 Network in CIDR format (e.g., 192.168.1.0/24) - - INTERFACE The name of a network interface. The interface must - be defined in /etc/shorewall/interfaces. - - NET2 Network in CIDR format - - See http://shorewall.net/netmap.html for an example and usage - information. - -################################################################################ - /etc/shorewall/policy - - THE ORDER OF ENTRIES IN THIS FILE IS IMPORTANT - - This file determines what to do with a new connection request if we - don't get a match from the /etc/shorewall/rules file . For each - source/destination pair, the file is processed in order until a - match is found ("all" will match any client or server). - - INTRA-ZONE POLICIES ARE PRE-DEFINED - - For $FW and for all of the zoned defined in /etc/shorewall/zones, - the POLICY for connections from the zone to itself is ACCEPT (with no - logging or TCP connection rate limiting but may be overridden by an - entry in this file. The overriding entry must be explicit (cannot use - "all" in the SOURCE or DEST). - - Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf, then - the implicit policy to/from any sub-zone is CONTINUE. These implicit - CONTINUE policies may also be overridden by an explicit entry in this - file. - - Columns are: - - SOURCE Source zone. Must be the name of a zone defined - in /etc/shorewall/zones, $FW or "all". - - DEST Destination zone. Must be the name of a zone defined - in /etc/shorewall/zones, $FW or "all" - - POLICY Policy if no match from the rules file is found. Must - be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE". - - ACCEPT - Accept the connection - DROP - Ignore the connection request - REJECT - For TCP, send RST. For all other, - send "port unreachable" ICMP. - QUEUE - Send the request to a user-space - application using the QUEUE target. - CONTINUE - Pass the connection request past - any other rules that it might also - match (where the source or - destination zone in those rules is - a superset of the SOURCE or DEST - in this policy). - NONE - Assume that there will never be any - packets from this SOURCE - to this DEST. Shorewall will not set - up any infrastructure to handle such - packets and you may not have any - rules with this SOURCE and DEST in - the /etc/shorewall/rules file. If - such a packet _is_ received, the - result is undefined. NONE may not be - used if the SOURCE or DEST columns - contain the firewall zone ($FW) or - "all". - - If the policy is DROP or REJECT then the policy should - be followed by ":" and one of the following: - - a) The word "None" or "none". This causes any default - action defined in /etc/shorewall/shorewall.conf to - be omitted for this policy. - b) The name of an action (requires that USE_ACTIONS=Yes - in shorewall.conf). That action will be invoked - before the policy is enforced. - c) The name of a macro. The rules in that macro will - be applied before the policy is enforced. This - does not require USE_ACTIONS=Yes. - - LOG LEVEL If supplied, each connection handled under the default - POLICY is logged at that level. If not supplied, no - log message is generated. See syslog.conf(5) for a - description of log levels. - - Beginning with Shorewall version 1.3.12, you may - also specify ULOG (must be in upper case). This will - log to the ULOG target and sent to a separate log - through use of ulogd - (http://www.gnumonks.org/projects/ulogd). - - If you don't want to log but need to specify the - following column, place "-" here. - - LIMIT:BURST If passed, specifies the maximum TCP connection rate - and the size of an acceptable burst. If not specified, - TCP connections are not limited. - - Example: - - a) All connections from the local network to the internet are allowed - b) All connections from the internet are ignored but logged at syslog - level KERNEL.INFO. - d) All other connection requests are rejected and logged at level - KERNEL.INFO. - - #SOURCE DEST POLICY LOG - # LEVEL - loc net ACCEPT - net all DROP info - # - # THE FOLLOWING POLICY MUST BE LAST - # - all all REJECT info - - See http://shorewall.net/Documentation.htm#Policy for additional information. - -################################################################################ - /etc/shorewall/providers - - This file is used to define additional routing tables. You will - want to define an additional table if: - - - You have connections to more than one ISP or multiple connections - to the same ISP - - - You run Squid as a transparent proxy on a host other than the - firewall. - - To omit a column, enter "-". - - Columns are: - - NAME The provider name. Must be a valid shell variable name. - The names 'local', 'main', 'default' and 'unspec' are - reserved and may not be used as provider names. - - NUMBER The provider number -- a number between 1 and 15 - - MARK A FWMARK value used in your /etc/shorewall/tcrules - file to direct packets to this provider. - - If HIGH_ROUTE_MARKS=Yes in shorewall.conf, then the - value must be a multiple of 256 between 256 and 65280 - or their hexadecimal equivalents (0x0100 and 0xff00 - with the low-order byte of the value being zero). - Otherwise, the value must be between 1 and 255. - - DUPLICATE The name of an existing table to duplicate. May be - 'main' or the name of a previous provider. - - INTERFACE The name of the network interface to the provider. - Must be listed in /etc/shorewall/interfaces. - - GATEWAY The IP address of the provider's gateway router. - - You can enter "detect" here and Shorewall will - attempt to detect the gateway automatically. - - [ EXPERIMENTAL ] For PPP devices, you may omit this - column. - - OPTIONS A comma-separated list selected from the following: - - track If specified, inbound connections on this interface - are to be tracked so that responses may be routed back - out this same interface. - - You want to specify 'track' if internet hosts will be - connecting to local servers through this provider. - - balance The providers that have 'balance' specified will - get outbound traffic load-balanced among them. By - default, all interfaces with 'balance' specified - will have the same weight (1). You can change the - weight of an interface by specifiying balance= - where is the weight of the route out of - this interface. - - loose Shorewall normally adds a routing rule for each - IP address on an interface which forces traffic - whose source is that IP address to be sent using - the routing table for that interface. Setting - 'loose' prevents creation of such rules on this - interface. - - optional - If the interface named in the INTERFACE column is not - up and configured with an IPv4 address then ignore - this provider. - - COPY A comma-separated lists of other interfaces on your - firewall. Only makes sense when DUPLICATE is 'main'. - Only copy routes through INTERFACE and through - interfaces listed here. If you only wish to copy - routes through INTERFACE, enter 'none' here. - - Example: You run squid in your DMZ on IP address 192.168.2.99. Your DMZ - interface is eth2 - - #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS - Squid 1 1 - eth2 192.168.2.99 - - - Example: - - eth0 connects to ISP 1. The IP address of eth0 is 206.124.146.176 and - the ISP's gateway router has IP address 206.124.146.254. - - eth1 connects to ISP 2. The IP address of eth1 is 130.252.99.27 and the - ISP's gateway router has IP address 130.252.99.254. - - eth2 connects to a local network. - - #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY - ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 - ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 - - See http://www.shorewall.net/MultiISP.html for additional - information. - -################################################################################ - /etc/shorewall/proxyarp - - This file is used to define Proxy ARP. - - Columns are: - - ADDRESS IP Address - - INTERFACE Local interface where system is connected. - - EXTERNAL External Interface to be used to access this system - - HAVEROUTE If there is already a route from the firewall to - the host whose address is given, enter "Yes" or "yes" - in this column. Otherwise, entry "no", "No" or leave - the column empty and Shorewall will add the route for - you. If Shorewall adds the route,the route will be - persistent if the PERSISTENT column contains Yes; - otherwise, "shorewall stop" or "shorewall clear" will - delete the route. - - PERSISTENT If HAVEROUTE is No or "no", then the value of this - column determines if the route added by Shorewall - persists after a "shorewall stop" or a "shorewall - clear". If this column contains "Yes" or "yes" then - the route persists; If the column is empty or contains - "No"or "no" then the route is deleted at "shorewall - stop" or "shorewall clear". - - Example: Host with IP 155.186.235.6 is connected to - interface eth1 and we want hosts attached via eth0 - to be able to access it using that address. - - #ADDRESS INTERFACE EXTERNAL - 155.186.235.6 eth1 eth0 - - See http://shorewall.net/ProxyARP.htm for additional information. - -################################################################################ - /etc/shorewall/rfc1918 - - Lists the subnetworks that are blocked by the 'norfc1918' interface - option. - - The default list includes those IP addresses listed in RFC 1918. - - DO NOT MODIFY THIS FILE. IF YOU NEED TO MAKE CHANGES, COPY THE FILE - TO /etc/shorewall AND MODIFY THE COPY. - - Columns are: - - SUBNETS A comma-separated list of subnet addresses - (host addresses also allowed as are IP - address ranges provided that your kernel and iptables - have iprange match support). - TARGET Where to send packets to/from this subnet - RETURN - let the packet be processed normally - DROP - silently drop the packet - logdrop - log then drop - - By default, the RETURN target causes 'norfc1918' processing to cease - for a packet if the packet's source IP address matches the rule. Thus, - if you have: - - SUBNETS TARGET - 192.168.1.0/24 RETURN - - then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though - you also have: - - SUBNETS TARGET - 10.0.0.0/8 logdrop - - Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic - to be logged and dropped since while the packet's source matches the - RETURN rule, the packet's destination matches the 'logdrop' rule. -################################################################################ - /etc/shorewall/route_rules - - Entries in this file cause traffic to be routed to one of the - providers listed in /etc/shorewall/providers. - - Columns are: - - SOURCE(optional) - An ip address (network or host) that - matches the source IP address in a packet. - May also be specified as an interface - name optionally followed by ":" and an - address. If the device 'lo' is specified, - the packet must originate from the firewall - itself. - - DEST(optional) An ip address (network or host) that - matches the destination IP address in a packet. - - If you choose to omit either SOURCE or DEST, - place "-" in that column. Note that you - may not omit both SOURCE and DEST. - - PROVIDER The provider to route the traffic through. - May be expressed either as the provider name - or the provider number. May also be 'main' - or 254 for the main routing table. This can - be used in combination with VPN tunnels, see - example 2 below. - - PRIORITY - The rule's priority which determines the order - in which the rules are processed. - - 1000-1999 Before Shorewall-generated - 'MARK' rules - - 11000- 11999 After 'MARK' rules but before - Shorewall-generated rules for - ISP interfaces. - - 26000-26999 After ISP interface rules but - before 'default' rule. - - Rules with equal priority are applied in - the order in which they appear in the file. - - Example 1: You want all traffic coming in on eth1 to be routed to the ISP1 - provider: - - #SOURCE DEST PROVIDER PRIORITY - eth1 - ISP1 1000 - - Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple - providers. In this case you have to set up a rule to ensure that - the OpenVPN traffic is routed back through the tunX interface(s) - rather than through any of the providers. 10.8.0.0/24 is the - subnet choosen in your OpenVPN configuration (server 10.8.0.0 - 255.255.255.0) - - #SOURCE DEST PROVIDER PRIORITY - - 10.8.0.0/24 main 1000 - - For additional information, see - http://www.shorewall.net/MultiISP.html - -################################################################################ - /etc/shorewall/routestopped - - This file is used to define the hosts that are accessible when the - firewall is stopped or when it is in the process of being - [re]started. - - Columns are: - - INTERFACE - Interface through which host(s) communicate with - the firewall - HOST(S) - (Optional) Comma-separated list of IP/subnet - addresses. If your kernel and iptables include - iprange match support, IP address ranges are also - allowed. - - If left empty or supplied as "-", - 0.0.0.0/0 is assumed. - OPTIONS - (Optional) A comma-separated list of - options. The currently-supported options are: - - routeback - Set up a rule to ACCEPT traffic from - these hosts back to themselves. - - source - Allow traffic from these hosts to ANY - destination. Without this option or the 'dest' - option, only traffic from this host to other - listed hosts (and the firewall) is allowed. If - 'source' is specified then 'routeback' is redundant. - - dest - Allow traffic to these hosts from ANY - source. Without this option or the 'source' - option, only traffic from this host to other - listed hosts (and the firewall) is allowed. If - 'dest' is specified then 'routeback' is redundant. - - critical - Allow traffic between the firewall and - these hosts throughout '[re]start', 'stop' and - 'clear'. Specifying 'critical' on one or more - entries will cause your firewall to be "totally - open" for a brief window during each of those - operations. - - NOTE: The 'source' and 'dest' options work best when used - in conjunction with ADMINISABSENTMINDED=Yes in - /etc/shorewall/shorewall.conf. - - Example: - - INTERFACE HOST(S) OPTIONS - eth2 192.168.1.0/24 - eth0 192.0.2.44 - br0 - routeback - eth3 - source - - See http://shorewall.net/Documentation.htm#Routestopped and - http://shorewall.net/starting_and_stopping_shorewall.htm for additional - information. - -################################################################################ - /etc/shorewall/rules - - Rules in this file govern connection establishment. Requests and - responses are automatically allowed using connection tracking. For any - particular (source,dest) pair of zones, the rules are evaluated in the - order in which they appear in this file and the first match is the one - that determines the disposition of the request. - - In most places where an IP address or subnet is allowed, you - can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to - indicate that the rule matches all addresses except the address/subnet - given. Notice that no white space is permitted between "!" and the - address/subnet. ------------------------------------------------------------------------------- - WARNING: If you masquerade or use SNAT from a local system to the internet, - you cannot use an ACCEPT rule to allow traffic from the internet to - that system. You *must* use a DNAT rule instead. ------------------------------------------------------------------------------- - - The rules file is divided into sections. Each section is introduced by - a "Section Header" which is a line beginning with SECTION followed by the - section name. - - Sections are as follows and must appear in the order listed: - - ESTABLISHED Packets in the ESTABLISHED state are processed - by rules in this section. - - The only ACTIONs allowed in this section are - ACCEPT, DROP, REJECT, LOG and QUEUE - - There is an implicit ACCEPT rule inserted - at the end of this section. - - RELATED Packets in the RELATED state are processed by - rules in this section. - - The only ACTIONs allowed in this section are - ACCEPT, DROP, REJECT, LOG and QUEUE - - There is an implicit ACCEPT rule inserted - at the end of this section. - - NEW Packets in the NEW and INVALID states are - processed by rules in this section. - - Note: If you are not familiar with Netfilter to the point where you are - comfortable with the differences between the various connection - tracking states, then I suggest that you omit the ESTABLISHED and - RELATED sections and place all of your rules in the NEW section - (That's after the line that reads SECTION NEW'). - - WARNING: If you specify FASTACCEPT=Yes in shorewall.conf then the - ESTABLISHED and RELATED sections must be empty. - - You may omit any section that you don't need. If no Section Headers appear - in the file then all rules are assumed to be in the NEW section. - - Columns are: - - ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE, - LOG, QUEUE, COMMENT, a , or an . - - ACCEPT -- allow the connection request - ACCEPT+ -- like ACCEPT but also excludes the - connection from any subsequent - DNAT[-] or REDIRECT[-] rules - NONAT -- Excludes the connection from any - subsequent DNAT[-] or REDIRECT[-] - rules but doesn't generate a rule - to accept the traffic. - DROP -- ignore the request - REJECT -- disallow the request and return an - icmp-unreachable or an RST packet. - DNAT -- Forward the request to another - system (and optionally another - port). - DNAT- -- Advanced users only. - Like DNAT but only generates the - DNAT iptables rule and not - the companion ACCEPT rule. - SAME -- Similar to DNAT except that the - port may not be remapped and when - multiple server addresses are - listed, all requests from a given - remote system go to the same - server. - SAME- -- Advanced users only. - Like SAME but only generates the - NAT iptables rule and not - the companion ACCEPT rule. - REDIRECT -- Redirect the request to a local - port on the firewall. - REDIRECT- - -- Advanced users only. - Like REDIRET but only generates the - REDIRECT iptables rule and not - the companion ACCEPT rule. - - CONTINUE -- (For experts only). Do not process - any of the following rules for this - (source zone,destination zone). If - The source and/or destination IP - address falls into a zone defined - later in /etc/shorewall/zones, this - connection request will be passed - to the rules defined for that - (those) zone(s). - LOG -- Simply log the packet and continue. - QUEUE -- Queue the packet to a user-space - application such as ftwall - (http://p2pwall.sf.net). - COMMENT -- the rest of the line will be attached - as a comment to the Netfilter rule(s) - generated by the following entres. - The comment will appear delimited by - "/* ... */" in the output of - "shorewall show ". To stop - the comment from being attached to - further rules, simply include - COMMENT on a line by itself. - -- The name of an action defined in - /etc/shorewall/actions or in - /usr/share/shorewall/actions.std. - -- The name of a macro defined in a - file named macro.. If - the macro accepts an action - parameter (Look at the macro - source to see if it has PARAM in - the TARGET column) then the macro - name is followed by "/" and the - action (ACCEPT, DROP, REJECT, ...) - to be substituted for the - parameter. Example: FTP/ACCEPT. - - The ACTION may optionally be followed - by ":" and a syslog log level (e.g, REJECT:info or - DNAT:debug). This causes the packet to be - logged at the specified level. - - If the ACTION names an action defined in - /etc/shorewall/actions or in - /usr/share/shorewall/actions.std then: - - - If the log level is followed by "!' then all rules - in the action are logged at the log level. - - - If the log level is not followed by "!" then only - those rules in the action that do not specify - logging are logged at the specified level. - - - The special log level 'none!' suppresses logging - by the action. - - You may also specify ULOG (must be in upper case) as a - log level.This will log to the ULOG target for routing - to a separate log through use of ulogd - (http://www.gnumonks.org/projects/ulogd). - - Actions specifying logging may be followed by a - log tag (a string of alphanumeric characters) - are appended to the string generated by the - LOGPREFIX (in /etc/shorewall/shorewall.conf). - - Example: ACCEPT:info:ftp would include 'ftp ' - at the end of the log prefix generated by the - LOGPREFIX setting. - - SOURCE Source hosts to which the rule applies. May be a zone - defined in /etc/shorewall/zones, $FW to indicate the - firewall itself, "all", "all+", "all-", "all+-" or - "none". - - When "none" is used either in the SOURCE or DEST - column, the rule is ignored. - - "all" means "All Zones", including the firewall itself. - "all-" means "All Zones, except the firewall itself". - When "all[-]" is used either in the SOURCE or DEST column - intra-zone traffic is not affected. When "all+[-]" is - "used, intra-zone traffic is affected. - - Except when "all[+][-]" is specified, clients may be - further restricted to a list of subnets and/or hosts by - appending ":" and a comma-separated list of subnets - and/or hosts. Hosts may be specified by IP or MAC - address; mac addresses must begin with "~" and must use - "-" as a separator. - - Hosts may be specified as an IP address range using the - syntax -. This requires that - your kernel and iptables contain iprange match support. - If you kernel and iptables have ipset match support - then you may give the name of an ipset prefaced by "+". - The ipset name may be optionally followed by a number - from 1 to 6 enclosed in square brackets ([]) to - indicate the number of levels of source bindings to be - matched. - - dmz:192.168.2.2 Host 192.168.2.2 in the DMZ - - net:155.186.235.0/24 Subnet 155.186.235.0/24 on the - Internet - - loc:192.168.1.1,192.168.1.2 - Hosts 192.168.1.1 and - 192.168.1.2 in the local zone. - loc:~00-A0-C9-15-39-78 Host in the local zone with - MAC address 00:A0:C9:15:39:78. - - net:192.0.2.11-192.0.2.17 - Hosts 192.0.2.11-192.0.2.17 in - the net zone. - - Alternatively, clients may be specified by interface - by appending ":" to the zone name followed by the - interface name. For example, loc:eth1 specifies a - client that communicates with the firewall system - through eth1. This may be optionally followed by - another colon (":") and an IP/MAC/subnet address - as described above (e.g., loc:eth1:192.168.1.5). - - DEST Location of Server. May be a zone defined in - /etc/shorewall/zones, $FW to indicate the firewall - itself, "all". "all+" or "none". - - When "none" is used either in the SOURCE or DEST - column, the rule is ignored. - - When "all" is used either in the SOURCE or DEST column - intra-zone traffic is not affected. When "all+" is - used, intra-zone traffic is affected. - - Except when "all[+]" is specified, the server may be - further restricted to a particular subnet, host or - interface by appending ":" and the subnet, host or - interface. See above. - - Restrictions: - - 1. MAC addresses are not allowed. - 2. In DNAT rules, only IP addresses are - allowed; no FQDNs or subnet addresses - are permitted. - 3. You may not specify both an interface and - an address. - - Like in the SOURCE column, you may specify a range of - up to 256 IP addresses using the syntax - -. When the ACTION is DNAT or DNAT-, - the connections will be assigned to addresses in the - range in a round-robin fashion. - - If you kernel and iptables have ipset match support - then you may give the name of an ipset prefaced by "+". - The ipset name may be optionally followed by a number - from 1 to 6 enclosed in square brackets ([]) to - indicate the number of levels of destination bindings - to be matched. Only one of the SOURCE and DEST columns - may specify an ipset name. - - The port that the server is listening on may be - included and separated from the server's IP address by - ":". If omitted, the firewall will not modifiy the - destination port. A destination port may only be - included if the ACTION is DNAT or REDIRECT. - - Example: loc:192.168.1.3:3128 specifies a local - server at IP address 192.168.1.3 and listening on port - 3128. The port number MUST be specified as an integer - and not as a name from /etc/services. - - if the ACTION is REDIRECT, this column needs only to - contain the port number on the firewall that the - request should be redirected to. - - PROTO Protocol - Must be "tcp", "tcp:syn", "udp", "icmp", - "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all". - "ipp2p*" requires ipp2p match support in your kernel - and iptables. - - "tcp:syn" implies "tcp" plus the SYN flag must be - set and the RST,ACK and FIN flags must be reset. - - DEST PORT(S) Destination Ports. A comma-separated list of Port - names (from /etc/services), port numbers or port - ranges; if the protocol is "icmp", this column is - interpreted as the destination icmp-type(s). - - If the protocol is ipp2p, this column is interpreted - as an ipp2p option without the leading "--" (example - "bit" for bit-torrent). If no port is given, "ipp2p" is - assumed. - - A port range is expressed as :. - - This column is ignored if PROTOCOL = all but must be - entered if any of the following ields are supplied. - In that case, it is suggested that this field contain - "-" - - If your kernel contains multi-port match support, then - only a single Netfilter rule will be generated if in - this list and the CLIENT PORT(S) list below: - 1. There are 15 or less ports listed. - 2. No port ranges are included. - Otherwise, a separate rule will be generated for each - port. - - SOURCE PORT(S) (Optional) Port(s) used by the client. If omitted, - any source port is acceptable. Specified as a comma- - separated list of port names, port numbers or port - ranges. - - If you don't want to restrict client ports but need to - specify an ORIGINAL DEST in the next column, then - place "-" in this column. - - If your kernel contains multi-port match support, then - only a single Netfilter rule will be generated if in - this list and the DEST PORT(S) list above: - 1. There are 15 or less ports listed. - 2. No port ranges are included. - Otherwise, a separate rule will be generated for each - port. - - ORIGINAL DEST (0ptional) -- If ACTION is DNAT[-] or REDIRECT[-] - then if included and different from the IP - address given in the SERVER column, this is an address - on some interface on the firewall and connections to - that address will be forwarded to the IP and port - specified in the DEST column. - - A comma-separated list of addresses may also be used. - This is usually most useful with the REDIRECT target - where you want to redirect traffic destined for - particular set of hosts. - - Finally, if the list of addresses begins with "!" then - the rule will be followed only if the original - destination address in the connection request does not - match any of the addresses listed. - - For other actions, this column may be included and may - contain one or more addresses (host or network) - separated by commas. Address ranges are not allowed. - When this column is supplied, rules are generated - that require that the original destination address - matches one of the listed addresses. This feature is - most useful when you want to generate a filter rule - that corresponds to a DNAT- or REDIRECT- rule. In this - usage, the list of addresses should not begin with "!". - - See http://shorewall.net/PortKnocking.html for an - example of using an entry in this column with a - user-defined action rule. - - RATE LIMIT You may rate-limit the rule by placing a value in - this colume: - - /[:] - - where is the number of connections per - ("sec" or "min") and is the - largest burst permitted. If no is given, - a value of 5 is assumed. There may be no - no whitespace embedded in the specification. - - Example: 10/sec:20 - - USER/GROUP This column may only be non-empty if the SOURCE is - the firewall itself. - - The column may contain: - - [!][][:][+] - - When this column is non-empty, the rule applies only - if the program generating the output is running under - the effective and/or specified (or is - NOT running under that id if "!" is given). - - Examples: - - joe #program must be run by joe - :kids #program must be run by a member of - #the 'kids' group - !:kids #program must not be run by a member - #of the 'kids' group - +upnpd #program named upnpd (This feature was - #removed from Netfilter in kernel - #version 2.6.14). - - Example: Accept SMTP requests from the DMZ to the internet - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL - # PORT PORT(S) DEST - ACCEPT dmz net tcp smtp - - Example: Forward all ssh and http connection requests from the - internet to local system 192.168.1.3 - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL - # PORT PORT(S) DEST - DNAT net loc:192.168.1.3 tcp ssh,http - - Example: Forward all http connection requests from the internet - to local system 192.168.1.3 with a limit of 3 per second and - a maximum burst of 10 - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE - # PORT PORT(S) DEST LIMIT - DNAT net loc:192.168.1.3 tcp http - - 3/sec:10 - - Example: Redirect all locally-originating www connection requests to - port 3128 on the firewall (Squid running on the firewall - system) except when the destination address is 192.168.2.2 - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL - # PORT PORT(S) DEST - REDIRECT loc 3128 tcp www - !192.168.2.2 - - Example: All http requests from the internet to address - 130.252.100.69 are to be forwarded to 192.168.1.3 - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL - # PORT PORT(S) DEST - DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 - - Example: You want to accept SSH connections to your firewall only - from internet IP addresses 130.252.100.69 and 130.252.100.70 - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL - # PORT PORT(S) DEST - ACCEPT net:130.252.100.69,130.252.100.70 $FW \ - tcp 22 - - See http://www.shorewall.net/Documentation.htm#Rules for additional - information. - -################################################################################ - Based on tc4shorewall version 0.5 by Arne Bernin - - /etc/shorewall/tcclasses - - Define the classes used for traffic shaping in this file. - - A note on the rate/bandwidth definitions used in this file: - - - don't use a space between the integer value and - the unit: 30kbit is valid while 30 kbit is NOT. - - - you can use one of the following units: - - kbps Kilobytes per second - mbps Megabytes per second - kbit Kilobits per second - mbit Megabits per second - bps or a - bare number Bytes per second - - - if you want the values to be calculated for you depending - on the output bandwidth setting defined for an interface - in tcdevices, you can use expressions like the following: - - full/3 causes the bandwidth to be calculated - as 3 of the the full outgoing - speed that is defined. - - full*9/10 will set this bandwidth to 9/10 of - the full bandwidth - - DO NOT add a unit to the rate if it is calculated ! - - Columns are: - - INTERFACE Name of interface. Each interface may be listed only - once in this file. You may NOT specify the name of - an alias (e.g., eth0:0) here; see - http://www.shorewall.net/FAQ.htm#faq18 - - You may NOT specify wildcards here, e.g. if you - have multiple ppp interfaces, you need to put - them all in here! - - Please note that you can only use interface names - in here that have a bandwidth defined in the tcdevices - file - - MARK The mark value which is an integer in the range 1-255. - You define this marks in the tcrules file, marking - the traffic you want to fit in the classes defined - in here. - - You can use the same marks for different interfaces. - - RATE The minimum bandwidth this class should get, - when the traffic load rises. If the sum of the rates - in this column exceed the INTERFACE's OUT-BANDWIDTH, - then the OUT-BANDWIDTH limit may not be honored. - - CEIL The maximum bandwidth this class is allowed to use - when the link is idle. Useful if you have traffic - which can get full speed when more needed services - (e.g. ssh) are not used. - - You can use the value "full" in here for setting - the maximum bandwidth to the defined output bandwidth - of that interface. - - PRIORITY The priority in which classes will be serviced by - the packet shaping scheduler and also the priority - in which bandwidth in excess of the rate will be - given to each class. - - Higher priority classes will experience less delay - since they are serviced first. Priority values - are serviced in ascending order (e.g. 0 is higher - priority than 1). - - Classes may be set to the same priority, in which - case they will be serviced as equals. - - OPTIONS A comma-separated list of options including the - following: - - default - this is the default class for that - interface where all traffic should go, - that is not classified otherwise. - - NOTE: defining default for exactly one - class per interface is mandatory! - - tos=0x[/0x] (mask defaults to 0xff) - - this lets you define a classifier - for the given / - combination of the IP packet's - TOS/Precedence/DiffSrv octet (aka the - TOS byte). Please note, classifiers - override all mark settings, so if you - define a classifer for a class, all - traffic having that mark will go in it - regardless of any mark set on the - packet by a firewall/mangle filter. - - NOTE: multiple tos= statements may be - applied per class and per interface, - but a given value/mask pair is valid - for only ONE class per interface. - - tos- - aliases for the following TOS octet - value and mask encodings. TOS - encodings of the "TOS byte" have been - deprecated in favor of diffserve - classes, but programs like ssh, - rlogin, and ftp still use them. - - tos-minimize-delay 0x10/0x10 - tos-maximize-throughput 0x08/0x08 - tos-maximize-reliability 0x04/0x04 - tos-minimize-cost 0x02/0x02 - tos-normal-service 0x00/0x1e - - NOTE: each of this options is only - valid for ONE class per interface. - - tcp-ack - if defined causes an tc filter to - be created that puts all tcp ack - packets on that interface that have - an size of <=64 Bytes to go in this - class. This is useful for speeding up - downloads. Please note that the size - of the ack packets is limited to 64 - bytes as some applications (p2p for - example) use to make every packet an - ack packet which would cause them - all into here. We want only packets - WITHOUT payload to match, so the size - limit. - - NOTE: This option is only valid for - ONE class per interface. - - - - Example 1: Suppose you are using PPP over Ethernet (DSL) - and ppp0 is the interface for this. You have 4 classes - here, the first you can use for voice over IP - traffic, the second interactive traffic (e.g. - ssh/telnet but not scp), the third will be for all - unclassified traffic, and the forth is for low - priority traffic (e.g. peer-to-peer). - - The voice traffic in the first class will be - guaranteed a minimum of 100kbps and always be - serviced first (because of the low priority number, - giving less delay) and will be granted excess - bandwidth (up to 180kbps, the class ceiling) first, - before any other traffic. A single VOIP stream, - depending upon codecs, after encapsulation, can take - up to 80kbps on a PPOE/DSL link, so we pad a little - bit just in case. (TOS byte values 0xb8 and 0x68 - are DiffServ classes EF and AFF3-1 respectively and - are often used by VOIP devices). - - Interactive traffic (tos-minimum-delay) and - TCP acks (and ICMP echo traffic if you use the example - in tcrules) and any packet with a mark of 2 will be - guaranteed 1/4 of the link bandwidth, and may extend - up to full speed of the link. - - Unclassified traffic and packets marked as 3 will be - guaranteed 1/4th of the link bandwidth, and may extend - to the full speed of the link. - - Packets marked with 4 will be treated as low priority - packets. (The tcrules example marks p2p traffic as - such.) If the link is congested, they're only - guaranteed 1/8th of the speed, and even if the link is - empty, can only expand to 80% of link bandwidth just - as a precaution in case there are upstream queues we - didn't account for. This is the last class to get - additional bandwidth and the last to get serviced by - the scheduler because of the low priority. - - ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc - ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay - ppp0 3 full/4 full 3 default - ppp0 4 full/8 full*8/10 4 - - See http://shorewall.net/traffic_shaping.htm for additional information. - -################################################################################ - Based on tc4shorewall version 0.5 by Arne Bernin - - /etc/shorewall/tcdevices - - Entries in this file define the bandwidth for interfaces - on which you want traffic shaping to be enabled. - - If you do not plan to use traffic shaping for a device, - don't put it in here as it limits the troughput of that - device to the limits you set here. - - Columns are: - - - INTERFACE Name of interface. Each interface may be listed only - once in this file. You may NOT specify the name of - an alias (e.g., eth0:0) here; see - http://www.shorewall.net/FAQ.htm#faq18 - - You man NOT specify wildcards here, e.g. if you - have multiple ppp interfaces, you need to put - them all in here! - - If the device doesn't exist, a warning message will - be issued during "shorewall [re]start" and "shorewall - refresh" and traffic shaping configuration will be - skipped for that device. - - IN-BANDWIDTH The incoming Bandwidth of that interface. Please - note that you are not able to do traffic shaping - on incoming traffic, as the traffic is already - received before you could do so. But this allows - you to define the maximum traffic allowed for - this interface in total, if the rate is exceeded, - the packets are dropped. - You want this mainly if you have a DSL or Cable - connection to avoid queuing at your providers side. - - If you don't want any traffic to be dropped, set this - to a value to zero in which case Shorewall will not - create an ingress qdisc. - - Use kbit or kbps(for Kilobytes per second) for - speed, and make sure there is NO space between the - number and the unit. - - OUT-BANDWIDTH The outgoing Bandwidth of that interface. - This is the maximum speed you connection can handle. - It is also the speed you can refer as "full" if - you define the tc classes. - Outgoing traffic above this rate will be dropped. - - Use kbit or kbps(for Kilobytes per second) for - speed, and make sure there is NO space between the - number and the unit. - - Example 1: Suppose you are using PPP over Ethernet (DSL) - and ppp0 is the interface for this. The - device has an outgoing bandwidth of 500kbit and an - incoming bandwidth of 6000kbit - ppp0 6000kbit 500kbit - - See http://shorewall.net/traffic_shaping.htm for additional information. - -################################################################################ - /etc/shorewall/tcrules - - Entries in this file cause packets to be marked as a means of - classifying them for traffic control or policy routing. - - I M P O R T A N T ! ! ! ! - - Unlike rules in the /etc/shorewall/rules file, evaluation - of rules in this file will continue after a match. So the - final mark for each packet will be the one assigned by the - LAST tcrule that matches. - - If you use multiple internet providers with the 'track' option, - in /etc/shorewall/providers be sure to read the restrictions at - http://shorewall.net/MultiISP.html. - - Columns are: - - - MARK/ a) A mark value which is an integer in the range 1-255. - CLASSIFY - Normally will set the mark value. If preceded by - a vertical bar ("|"), the mark value will be - logically ORed with the current mark value to - produce a new mark value. If preceded by an - ampersand ("&"), will be logically ANDed with the - current mark value to produce a new mark value. - - Both "|" and "&" require Extended MARK Target - support in your kernel and iptables; neither may - be used with connection marks (see below). - - If HIGH_ROUTE_MARKS=Yes in shorewall.conf then - you may also specify a value in the range 0x0100- - 0xFF00 with the low-order byte being zero. Such - values may only be used in the PREROUTING chain - (value followed by :F or you have set - MARK_IN_FORWARD_CHAIN=Yes in shorewall conf and have - not followed the value with :P) or the OUTPUT chain - (SOURCE is $FW). - - May optionally be followed by ":P" or ":F" - where ":P" indicates that marking should occur in - the PREROUTING chain and ":F" indicates that marking - should occur in the FORWARD chain. If neither - ":P" nor ":F" follow the mark value then the chain - is determined by the setting of - MARK_IN_FORWARD_CHAIN in - /etc/shorewall/shorewall.conf. - - If your kernel and iptables include CONNMARK support - then you can also mark the connection rather than - the packet. - - The mark value may be optionally followed by "/" - and a mask value (used to determine those bits of - the connection mark to actually be set). The - mark and optional mask are then followed by one of: - - C - Mark the connection in the chain determined - by the setting of MARK_IN_FORWARD_CHAIN - - CF: Mark the connection in the FORWARD chain - - CP: Mark the connection in the PREROUTING - chain. - - b) A classification (classid) of the form - : where and are - integers. Corresponds to the 'class' specification - in these traffic shaping modules: - - - atm - - cbq - - dsmark - - pfifo_fast - - htb - - prio - - Classification occurs in the POSTROUTING chain except - when the SOURCE is $FW[:
] in which case - marking occurs in the OUTPUT chain. - - c) RESTORE[/mask] -- restore the packet's mark from the - connection's mark using the supplied mask if any. - Your kernel and iptables must include CONNMARK - support. - - As in a) above, may be followed by ":P" or ":F - - c) SAVE[/mask] -- save the packet's mark to the - connection's mark using the supplied mask if any. - Your kernel and iptables must include CONNMARK - support. - - As in a) above, may be followed by ":P" or ":F - - d) CONTINUE -- don't process any more marking rules in - the table. - - As in a) above, may be followed by ":P" or ":F". - - e) COMMENT -- the rest of the line will be attached as - a comment to the Netfilter rule(s) generated by the - following entries. The comment will appear delimited - by "/* ... */" in the output of "shorewall show - mangle" - - To stop the comment from being attached to further - rules, simply include COMMENT on a line by itself. - - SOURCE Source of the packet. A comma-separated list of - interface names, IP addresses, MAC addresses and/or - subnets for packets being routed through a common path. - List elements may also consist of an interface name - followed by ":" and an address - (e.g., eth1:192.168.1.0/24). For example, all packets - for connections masqueraded to eth0 from other - interfaces can be matched in a single rule with - several alternative SOURCE criteria. However, a - connection whose packets gets to eth0 in a - different way, e.g., direct from the firewall itself, - needs a different rule. - - Accordingly, use $FW in its own separate rule for - packets originating on the firewall. In such a rule, - the MARK column may NOT specify either ":P" or ":F" - because marking for firewall-originated packets - always occurs in the OUTPUT chain. - - MAC addresses must be prefixed with "~" and use - "-" as a separator. - - Example: ~00-A0-C9-15-39-78 - - DEST Destination of the packet. Comma separated list of - IP addresses and/or subnets. If your kernel and - iptables include iprange match support, IP address - ranges are also allowed. List elements may also - consist of an interface name followed by ":" and an - address (e.g., eth1:192.168.1.0/24). - If the MARK column specificies a classification of - the form : then this column may also - contain an interface name. - - PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p", - "ipp2p:udp", "ipp2p:all" a number, or "all". - "ipp2p" requires ipp2p match support in your kernel - and iptables. - - PORT(S) Destination Ports. A comma-separated list of Port - names (from /etc/services), port numbers or port - ranges; if the protocol is "icmp", this column is - interpreted as the destination icmp-type(s). - - If the protocol is ipp2p, this column is interpreted - as an ipp2p option without the leading "--" (example - "bit" for bit-torrent). If no PORT is given, "ipp2p" is - assumed. - - This column is ignored if PROTOCOL = all but must be - entered if any of the following field is supplied. - In that case, it is suggested that this field contain - "-" - - SOURCE PORT(S) (Optional) Source port(s). If omitted, - any source port is acceptable. Specified as a comma- - separated list of port names, port numbers or port - ranges. - - USER This column may only be non-empty if the SOURCE is - the firewall itself. - - When this column is non-empty, the rule applies only - if the program generating the output is running under - the effective user and/or group. - - It may contain : - - []:[][+] - - The colon is optionnal when specifying only a user - or a program name. - Examples : john: , john , :users , john:users , - +mozilla-bin (Support for program names - was removed from Netfilter in Kernel - version 2.6.14). - - TEST Defines a test on the existing packet or connection - mark. The rule will match only if the test returns - true. Tests have the format [!][/][:C] - - Where: - - ! Inverts the test (not equal) - Value of the packet or connection mark. - A mask to be applied to the mark before - testing - :C Designates a connection mark. If - omitted, the packet mark's value is - tested. - - If you don't want to define a test but need to specify - anything in the following columns, place a "-" in this - field. - - LENGTH (Optional) Packet Length. This field, if present - allow you to match the length of a packet against - a specific value or range of values. You must have - iptables length support for this to work. - A range is specified in the form : - where either or (but not both) may be - omitted. If is omitted, then 0 is assumed; if - is omitted, than any packet that is or - longer will match. - - Examples: 1024, 64:1500, :100 (packet of length - 100 bytes or less) - - If you don't want to define a test but need to specify - anything in the following columns, place a "-" in this - field. - - TOS Type of service. Either a standard name, or a numeric - value to match. - - Minimize-Delay (16) - Maximize-Throughput (8) - Maximize-Reliability (4) - Minimize-Cost (2) - Normal-Service (0) - - Example 1: - - Mark all ICMP echo traffic with packet mark 1. - Mark all peer to peer traffic with packet mark 4. - - This is a little more complex than otherwise expected. Since - the ipp2p module is unable to determine all packets in a - connection are P2P packets, we mark the entire connection as - P2P if any of the packets are determined to match. - - We assume packet/connection mark 0 to means unclassified. - - 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request - 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply - - RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 - CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 - 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all - SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 - - "If a packet hasn't been classifed (packet mark is 0), copy - the connection mark to the packet mark. If the packet mark - is set, we're done. If the packet is P2P, set the packet - mark to 4. If the packet mark has been set, save it to the - connection mark." - - See http://shorewall.net/traffic_shaping.htm for additional information. - For usage in selecting among multiple ISPs, see - http://shorewall.net/MultiISP.html - -################################################################################ - /etc/shorewall/tos - - This file defines rules for setting Type Of Service (TOS) - - Columns are: - - SOURCE Name of a zone declared in /etc/shorewall/zones, "all" - or $FW. - - If not "all" or $FW, may optionally be followed by - ":" and an IP address, a MAC address, a subnet - specification or the name of an interface. - - Example: loc:192.168.2.3 - - MAC addresses must be prefixed with "~" and use - "-" as a separator. - - Example: ~00-A0-C9-15-39-78 - - DEST Name of a zone declared in /etc/shorewall/zones, "all" - or $FW. - - If not "all" or $FW, may optionally be followed by - ":" and an IP address or a subnet specification - - Example: loc:192.168.2.3 - - PROTOCOL Protocol. - - SOURCE PORTS Source port or port range. If all ports, use "-". - - DEST PORTS Destination port or port range. If all ports, use "-" - - TOS Type of service. Must be one of the following: - - Minimize-Delay (16) - Maximize-Throughput (8) - Maximize-Reliability (4) - Minimize-Cost (2) - Normal-Service (0) - - See http://shorewall.net/Documentation.htm#TOS for additional - information. - -################################################################################ - /etc/shorewall/tunnels - - This file defines IPSEC, GRE, IPIP and OPENVPN tunnels. - - IPIP, GRE and OPENVPN tunnels must be configured on the - firewall/gateway itself. IPSEC endpoints may be defined - on the firewall/gateway or on an internal system. - - The columns are: - - TYPE -- must start in column 1 and be "ipsec", "ipsecnat", - "ipip", "gre", "6to4", "pptpclient", "pptpserver", - "openvpn", "openvpnclient", "openvpnserver" or - "generic" - - If the type is "ipsec" or "ipsecnat", it may be - followed by ":noah" to indicate that the Authentication - Header protocol (51) is not used by the tunnel. - - If type is "openvpn", "openvpnclient" or - "openvpnserver" it may optionally be followed by ":" - and "tcp" or "udp" to specify the protocol to be - used. If not specified, "udp" is assumed. - - If type is "openvpn", "openvpnclient" or - "openvpnserver" it may optionally be followed - by ":" and the port number used by the tunnel. if no - ":" and port number are included, then the default port - of 1194 will be used. . Where both the protocol and port - are specified, the protocol must be given first (e.g., - openvpn:tcp:4444). - - If type is "generic", it must be followed by ":" and - a protocol name (from /etc/protocols) or a protocol - number. If the protocol is "tcp" or "udp" (6 or 17), - then it may optionally be followed by ":" and a - port number. - - ZONE -- The zone of the physical interface through which - tunnel traffic passes. This is normally your internet - zone. - - GATEWAY -- The IP address of the remote tunnel gateway. If the - remote gateway has no fixed address (Road Warrior) - then specify the gateway as 0.0.0.0/0. May be - specified as a network address and if your kernel and - iptables include iprange match support then IP address - ranges are also allowed. - - GATEWAY - ZONES -- Optional. If the gateway system specified in the third - column is a standalone host then this column should - contain a comma-separated list of the names of the - zones that the host might be in. This column only - applies to IPSEC tunnels where it enables ISAKMP - traffic to flow through the tunnel to the remote - gateway. - - Example 1: - - IPSec tunnel. The remote gateway is 4.33.99.124 and - the remote subnet is 192.168.9.0/24. The tunnel does - not use the AH protocol - - ipsec:noah net 4.33.99.124 - - Example 2: - - Road Warrior (LapTop that may connect from anywhere) - where the "gw" zone is used to represent the remote - LapTop. - - ipsec net 0.0.0.0/0 gw - - Example 3: - - Host 4.33.99.124 is a standalone system connected - via an ipsec tunnel to the firewall system. The host - is in zone gw. - - ipsec net 4.33.99.124 gw - - Example 4: - - Road Warriors that may belong to zones vpn1, vpn2 or - vpn3. The FreeS/Wan _updown script will add the - host to the appropriate zone using the "shorewall add" - command on connect and will remove the host from the - zone at disconnect time. - - ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 - - Example 5: - - You run the Linux PPTP client on your firewall and - connect to server 192.0.2.221. - - pptpclient net 192.0.2.221 - - Example 6: - - You run a PPTP server on your firewall. - - pptpserver net - - Example 7: - - OPENVPN tunnel. The remote gateway is 4.33.99.124 and - openvpn uses port 7777. - - openvpn:7777 net 4.33.99.124 - - Example 8: - - You have a tunnel that is not one of the supported - types. Your tunnel uses UDP port 4444. The other end - of the tunnel is 4.3.99.124. - - generic:udp:4444 net 4.3.99.124 - - See http://shorewall.net/Documentation.htm#Tunnels for additional - information. - -################################################################################ - /etc/shorewall/zones - - This file declares your network zones. You specify the hosts in - each zone through entries in /etc/shorewall/interfaces or - /etc/shorewall/hosts. - - WARNING: The format of this file changed in Shorewall 3.0.0. You can - continue to use your old records provided that you set - IPSECFILE=ipsec in /etc/shorewall/shorewall.conf. This will - signal Shorewall that the IPSEC-related zone options are - still specified in /etc/shorewall/ipsec rather than in this - file. - - To use records in the format described below, you must have - IPSECFILE=zones specified in /etc/shorewall/shorewall.conf - AND YOU MUST NOT SET THE 'FW' VARIABLE IN THAT FILE!!!!! - - Columns are: - - ZONE Short name of the zone. The names "all" and "none" are reserved - and may not be used as zone names. The maximum length of a - zone name is determined by the setting of the LOGFORMAT option - in shorewall.conf. With the default LOGFORMAT, zone names can - be at most 5 characters long. - - Where a zone is nested in one or more other zones, - you may follow the (sub)zone name by ":" and a - comma-separated list of the parent zones. The parent - zones must have been defined in earlier records in this - file. - - Example: - - #ZONE TYPE OPTIONS - a ipv4 - b ipv4 - c:a,b ipv4 - - Currently, Shorewall uses this information to reorder the - zone list so that parent zones appear after their subzones in - the list. The IMPLICIT_CONTINUE option in shorewall.conf can - also create implicit CONTINUE policies to/from the subzone. - - In the future, Shorewall may make additional use - of nesting information. - - TYPE ipv4 - This is the standard Shorewall zone type and is the - default if you leave this column empty or if you enter - "-" in the column. Communication with some zone hosts - may be encrypted. Encrypted hosts are designated using - the 'ipsec'option in /etc/shorewall/hosts. - ipsec - Communication with all zone hosts is encrypted - Your kernel and iptables must include policy - match support. - firewall - - Designates the firewall itself. You must have - exactly one 'firewall' zone. No options are - permitted with a 'firewall' zone. The name that you - enter in the ZONE column will be stored in the shell - variable $FW which you may use in other configuration - files to designate the firewall zone. - - OPTIONS, A comma-separated list of options as follows: - IN OPTIONS, - OUT OPTIONS reqid= where is specified - using setkey(8) using the 'unique: - option for the SPD level. - - spi= where is the SPI of - the SA used to encrypt/decrypt packets. - - proto=ah|esp|ipcomp - - mss= (sets the MSS field in TCP packets) - - mode=transport|tunnel - - tunnel-src=
[/] (only - available with mode=tunnel) - - tunnel-dst=
[/] (only - available with mode=tunnel) - - strict Means that packets must match all rules. - - next Separates rules; can only be used with - strict - - Example: - mode=transport,reqid=44 - - The options in the OPTIONS column are applied to both incoming - and outgoing traffic. The IN OPTIONS are applied to incoming - traffic (in addition to OPTIONS) and the OUT OPTIONS are - applied to outgoing traffic. - - If you wish to leave a column empty but need to make an entry - in a following column, use "-". ------------------------------------------------------------------------------- - Example zones: - - You have a three interface firewall with internet, local and DMZ - interfaces. - - #ZONE TYPE OPTIONS IN OUT - # OPTIONS OPTIONS - fw firewall - net ipv4 - loc ipv4 - dmz ipv4 - - For more information, see http://www.shorewall.net/Documentation.htm#Zones - -################################################################################ diff --git a/Shorewall/changelog.txt b/Shorewall/changelog.txt index 773220a64..cc1273a61 100644 --- a/Shorewall/changelog.txt +++ b/Shorewall/changelog.txt @@ -1,5 +1,6 @@ Changes in 3.3.6 +1) Remove /etc/shorewall/Documentation. Changes in 3.3.5 diff --git a/Shorewall/releasenotes.txt b/Shorewall/releasenotes.txt index 453712121..cea86d57b 100644 --- a/Shorewall/releasenotes.txt +++ b/Shorewall/releasenotes.txt @@ -37,7 +37,8 @@ None. Other Changes in 3.3.6 -None. +1) Now that the manpages are in place, /etc/shorewall/Documentation + has been removed. Migration Considerations: @@ -96,6 +97,14 @@ New Features: - lib.actions. Must be available if you do not specify USE_ACTIONS=No in /etc/shorewall/shorewall.conf. + - lib.base. The base Shorewall library required by all programs. + + - lib.cli. Library containing the code common to /sbin/shorewall, + /sbin/shorewall-lite, and /usr/share/shorewall/firewall. + + - lib.config. Library containing the code that is common to + /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. + - lib.dynamiczones. Must be available if you specify DYNAMIC_ZONES=Yes in shorewall.conf. @@ -126,8 +135,6 @@ New Features: footprint by: - Omitting the macro files. - - Only including the 'modules' file appropriate for the kernel in - use. - Omitting all unused extension scripts. - Stripping the comments (except for copyright) from the various files. @@ -237,7 +244,7 @@ New Features: messages which must be 29 bytes or less in length. With the standard Shorewall LOGFORMAT, that leaves 11 characters for the chain name; given that many chain names are of the form - 2, that gives a maximum zone name length of 11. + 2, that gives a maximum zone name length of 5. Beginning with this release, the maximum length of a zone name is dependent on the LOGFORMAT (the maximum length may never be less @@ -425,12 +432,7 @@ New Features: 14) IP Address ranges are now allowed in the drop, reject, allow and logdrop shorewall[-lite] commands. -15) The lib.cli library has been added. It is distributed with - both Shorewall and Shorewall Lite and contains the - command-processing code that is common to both /sbin/shorewall and - /sbin/shorewall-lite. - -16) Previously, Shorewall has not attempted to undo the changes it has +15) Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/routes. Beginning with this release, Shorewall will attempt to undo these changes. @@ -451,37 +453,12 @@ New Features: the saved copy so that it will once again be captured at the next shorewall start or shorewall restore. -17) Shorewall no longer includes policy matches in its generated +16) Shorewall no longer includes policy matches in its generated ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC networks are defined using the 'ipsec' option in /etc/shorewall/hosts). -18) From the beginning, the Shorewall configuration files in - /etc/shorewall/ have contained documentary comments. While these - comments are useful, they present an upgrade problem. Beginning - with this release, these comments are removed from the - configuration files themselves and are gathered together in a - single file /etc/shorewall/Documentation. The documentation is in - alphabetical order by file name. - -19) The "shorewall [re]load" command now supports a "-c" option. - - Example: - - shorewall reload -c gateway - - When -c is given, Shorewall will capture the capabilities of the - remote system to a file named "capabilities" in the export - directory before compiling the configuration. - - If the file "capabilities" does not currently exist in the - export directory then "-c" is automatically assumed. - -20) If 0 (zero) is specified for the IN-BANDWIDTH in - /etc/shorewall/tcdevices then no ingress qdisc will be created for - the device. - -21) The Makefile installed in /usr/share/shorewall/configfiles/ is now +17) The Makefile installed in /usr/share/shorewall/configfiles/ is now the same one mentioned at http://www.shorewall.net/CompiledPrograms.html. @@ -496,7 +473,7 @@ New Features: generate the "capabilities" file if that file doesn't exist. "make save" will save the running configuration on the remote firewall. -22) Shorewall and Shorewall Lite now include the following manpages. +18) Shorewall and Shorewall Lite now include the following manpages. shorewall-accounting(5) shorewall-actions(5) @@ -524,3 +501,11 @@ New Features: shorewall-tunnels(5) shorewall(8) shorewall-zones(5) + +19) From the beginning, the Shorewall configuration files in + /etc/shorewall/ have contained documentary comments. While these + comments are useful, they present an upgrade problem. Beginning + with this release, these comments are removed from the + configuration files themselves and are replaced by the manpages + described in the preceding release note entry. + diff --git a/Shorewall/shorewall.conf b/Shorewall/shorewall.conf index 8c41ea5ab..c4d14cbdf 100644 --- a/Shorewall/shorewall.conf +++ b/Shorewall/shorewall.conf @@ -7,426 +7,69 @@ # This file should be placed in /etc/shorewall # # (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net) -# -# >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<< -# -# Most problems associated with upgrades come from two causes: -# -# - The user didn't read and follow the migration considerations in the -# release notes. -# -# - The user mis-handled the /etc/shorewall/shorewall.conf file during -# upgrade. Shorewall is designed to allow the default behavior of -# the product to evolve over time. To make this possible, the design -# assumes that you will not replace your current shorewall.conf file -# during upgrades. If you feel absolutely compelled to have the latest -# comments and options in your shorewall.conf then you must proceed -# carefully. -# -# The new/changed options in shorewall 3.0 are listed below. If you don't -# want to convert to the new 3.0 format for /etc/shorewall/zones and you -# don't want to replace your current rules that use 2.x builtin actions, -# then if you plan to use this copy of shorewall.conf file then you must -# change it as follows: -# -# - IPSECFILE -# -# This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec. -# This will indicate that your /etc/shorewall/zones file is in the -# pre-3.0 format. -# -# - FW -# -# This file has FW undefined. If you have named your firewall zone -# something other than 'fw' then you must set FW accordingly. -# -# - MAPOLDACTIONS -# -# This file has MAPOLDACTIONS=No. You want to set it to -# MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin -# actions such as AllowPing to continue to work. ############################################################################### # S T A R T U P E N A B L E D ############################################################################### -# -# Once you have configured Shorewall, you may change the setting of -# this variable to 'Yes' -# STARTUP_ENABLED=No ############################################################################### # V E R B O S I T Y ############################################################################### -# -# Shorewall has traditionally been very noisy. You may now set the default -# level of verbosity here. -# -# Values are: -# -# 0 -- Silent. You may make it more verbose using the -v option -# 1 -- Major progress messages displayed -# 2 -- All progress messages displayed (old default behavior) -# -# If not specified, then 2 is assumed VERBOSITY=1 ############################################################################### # L O G G I N G ############################################################################### -# -# General note about log levels. Log levels are a method of describing -# to syslog (8) the importance of a message and a number of parameters -# in this file have log levels as their value. -# -# These levels are defined by syslog and are used to determine the destination -# of the messages through entries in /etc/syslog.conf (5). The syslog -# documentation refers to these as "priorities"; Netfilter calls them "levels" -# and Shorewall also uses that term. -# -# Valid levels are: -# -# 7 debug -# 6 info -# 5 notice -# 4 warning -# 3 err -# 2 crit -# 1 alert -# 0 emerg -# -# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall -# log messages are generated by NetFilter and are logged using facility -# 'kern' and the level that you specifify. If you are unsure of the level -# to choose, 6 (info) is a safe bet. You may specify levels by name or by -# number. -# -# If you have built your kernel with ULOG target support, you may also -# specify a log level of ULOG (must be all caps). Rather than log its -# messages to syslogd, Shorewall will direct netfilter to log the messages -# via the ULOG target which will send them to a process called 'ulogd'. -# ulogd is available with most Linux distributions (although it probably isn't -# installed by default). Ulogd is also available from -# http://www.gnumonks.org/projects/ulogd and can be configured to log all -# Shorewall message to their own log file -############################################################################### -# -# LOG FILE LOCATION -# -# This variable tells the /sbin/shorewall program where to look for Shorewall -# log messages. If not set or set to an empty string (e.g., LOGFILE="") then -# /var/log/messages is assumed. -# -# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to -# look for Shorewall messages.It does NOT control the destination for -# these messages. For information about how to do that, see -# -# http://www.shorewall.net/shorewall_logging.html -# LOGFILE=/var/log/messages -# -# LOG FORMAT -# -# Shell 'printf' Formatting template for the --log-prefix value in log messages -# generated by Shorewall to identify Shorewall log messages. The supplied -# template is expected to accept either two or three arguments; the first is -# the chain name, the second (optional) is the logging rule number within that -# chain and the third is the ACTION specifying the disposition of the packet -# being logged. You must use the %d formatting type for the rule number; if -# your template does not contain %d then the rule number will not be included. -# -# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: -# -# LOGFORMAT="fp=%s:%d a=%s " -# -# If not specified or specified as empty (LOGFORMAT="") then the value -# "Shorewall:%s:%s:" is assumed. -# -# Beginning with Shorewall 3.3.3, The contents of LOGFORMAT determine the -# maximum length of a Shorewall zone name. LOGFORMAT must produce a string no -# longer than 29 bytes when passed the chain name, [rule number], and 'ACCEPT'. -# Using the default LOGFORMAT, the name of a chain must be 11 characters or -# less; since chain names are often of the form 2, zone names are -# limited to 5 characters using the default LOGFORMAT. In contrast, if -# LOGFORMAT="FW:%s:%s:", then zone names can be as long as 8 characters. - LOGFORMAT="Shorewall:%s:%s:" -# -# LOG FORMAT Continued -# -# Using the default LOGFORMAT, chain names may not exceed 11 characters or -# truncation of the log prefix may occur. Longer chain names may be used with -# log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is -# specified then the tag is included in the log prefix in place of the chain -# name. -# - LOGTAGONLY=No -# -# LOG RATE LIMITING -# -# The next two variables can be used to control the amount of log output -# generated. LOGRATE is expressed as a number followed by an optional -# `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum -# rate at which a particular message will occur. LOGBURST determines the -# maximum initial burst size that will be logged. If set empty, the default -# value of 5 will be used. -# -# If BOTH variables are set empty then logging will not be rate-limited. -# -# Example: -# -# LOGRATE=10/minute -# LOGBURST=5 -# -# For each logging rule, the first time the rule is reached, the packet -# will be logged; in fact, since the burst is 5, the first five packets -# will be logged. After this, it will be 6 seconds (1 minute divided by -# the rate of 10) before a message will be logged from the rule, regardless -# of how many packets reach it. Also, every 6 seconds which passes without -# matching a packet, one of the bursts will be regained; if no packets hit -# the rule for 30 seconds, the burst will be fully recharged; back where -# we started. -# - LOGRATE= -LOGBURST= -# -# LOG ALL NEW -# -# This option should only be used when you are trying to analyze a problem. -# It causes all packets in the Netfilter NEW state to be logged as the -# first rule in each builtin chain. To use this option, set LOGALLNEW to -# the log level that you want these packets logged at (e.g., -# LOGALLNEW=debug). -# +LOGBURST= LOGALLNEW= -# -# BLACKLIST LOG LEVEL -# -# Set this variable to the syslogd level that you want blacklist packets logged -# (beware of DOS attacks resulting from such logging). If not set, no logging -# of blacklist packets occurs. -# -# See the comment at the top of this section for a description of log levels -# - BLACKLIST_LOGLEVEL= -# -# MAC List Log Level -# -# Specifies the logging level for connection requests that fail MAC -# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then -# such connection requests will not be logged. -# -# See the comment at the top of this section for a description of log levels -# -# If you wish to filter messages logged under this option, then supply -# the /etc/shorewall/maclog extension script (you will have to create the -# file yourself). That script will be copied into the compiled firewall -# script at a point just before logging occurs. The shell variable CHAIN -# will be set to the name of the chain where the logging rule will be -# inserted. -# -# If you set MACLIST_TABLE=mangle later in this file, be sure that your -# 'run_iptables' commands include '-t mangle'. -# -# See http://www.shorewall.net/shorewall_extension_scripts.htm for more -# information about extension scripts. -# - MACLIST_LOG_LEVEL=info -# -# TCP FLAGS Log Level -# -# Specifies the logging level for packets that fail TCP Flags -# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then -# such packets will not be logged. -# -# See the comment at the top of this section for a description of log levels -# - TCP_FLAGS_LOG_LEVEL=info -# -# RFC1918 Log Level -# -# Specifies the logging level for packets that fail RFC 1918 -# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then -# RFC1918_LOG_LEVEL=info is assumed. -# -# See the comment at the top of this section for a description of log levels -# - RFC1918_LOG_LEVEL=info -# -# SMURF Log Level -# -# Specifies the logging level for smurf packets dropped by the -#'nosmurfs' interface option in /etc/shorewall/interfaces and in -# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL="" -# ) then dropped smurfs are not logged. -# -# See the comment at the top of this section for a description of log levels -# - SMURF_LOG_LEVEL=info -# -# MARTIAN LOGGING -# -# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets -# that have impossible source IP addresses. This logging may be enabled -# on individual interfaces by using the 'logmartians' option in -# /etc/shorewall/interfaces. -# - LOG_MARTIANS=No ############################################################################### # L O C A T I O N O F F I L E S A N D D I R E C T O R I E S ############################################################################### -# -# IPTABLES -# -# Full path to iptables executable Shorewall uses to build the firewall. If -# not specified or if specified with an empty value (e.g., IPTABLES="") then -# the iptables executable located via the PATH setting below is used. -# IPTABLES= -# -# PATH - Change this if you want to change the order in which Shorewall -# searches directories for executable files. -# - PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin -# -# SHELL -# -# The firewall script is normally interpreted by /bin/sh. If you wish to change -# the shell used to interpret that script, specify the shell here. -# - SHOREWALL_SHELL=/bin/sh -# SUBSYSTEM LOCK FILE -# -# Set this to the name of the lock file expected by your init scripts. For -# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't -# use lock files, set this to "". -# - SUBSYSLOCK=/var/lock/subsys/shorewall -# -# KERNEL MODULE DIRECTORY -# -# If your netfilter kernel modules are in a directory other than -# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that -# directory in this variable. Example: MODULESDIR=/etc/modules. -# - MODULESDIR= -# -# CONFIGURATION SEARCH PATH -# -# This option holds a list of directory names separated by colons -# (":"). Shorewall will search each directory in turn when looking for a -# configuration file. When processing a 'try' command or a command -# containing the "-c" option or that specifies a configuration directory, -# Shorewall will automatically add the directory specified in the command -# to the front of this list. -# -# If not specified or specified as null ("CONFIG_PATH=""), -# the default is distribution-defined. See the output of "shorewall show -# config" to find the default value on your distribution. -# - CONFIG_PATH=/etc/shorewall:/usr/share/shorewall -# -# RESTORE SCRIPT -# -# This option determines the script to be run in the following cases: -# -# shorewall -f start -# shorewall restore -# shorewall save -# shorewall forget -# Failure of shorewall start or shorewall restart -# -# The value of the option must be the name of an executable file in the -# directory /var/lib/shorewall. If this option is not set or if it is -# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is -# assumed. -# - RESTOREFILE= -# -# OLD ZONE FILE FORMAT -# -# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file. -# Beginning with 2.5.0, those files were combined. For users who haven't -# converted, we offer this variable that sets the name of the file for ipsec -# information. This option must take the value "zones" or "ipsec". If the -# option is not set or is set to the empty value (IPSECFILE="") then "ipsec" -# is assumed. -# - IPSECFILE=zones ############################################################################### # D E F A U L T A C T I O N S / M A C R O S ############################################################################### -# -# In earlier Shorewall versions, a "default action" for DROP and REJECT -# policies was specified in the file /usr/share/shorewall/actions.std. -# -# To allow for default rules to be applied when USE_ACTIONS=No, the -# DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT options have -# been added. -# -# DROP_DEFAULT describes the rules to be applied before a connection request -# is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be applied -# if a connection request is rejected by a REJECT policy. The other two are -# similar for ACCEPT and QUEUE policies. -# -# The value applied to these may be: -# -# a) The name of an action. -# b) The name of a macro -# c) 'None' or 'none' -# -# The default values are: -# -# DROP_DEFAULT="Drop" -# REJECT_DEFAULT="Reject" -# ACCEPT_DEFAULT="none" -# QUEUE_DEFAULT="none" -# -# If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject -# respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and -# macro.Reject. -# -# If you set the value of either option to "None" then no default action -# will be used and the default action or macro must be specified in -# /etc/shorewall/policy DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" @@ -436,569 +79,75 @@ QUEUE_DEFAULT="none" ############################################################################### # F I R E W A L L O P T I O N S ############################################################################### -# -# WARNING: THE 'FW' OPTION HAS BEEN REMOVED FROM THIS FILE -- The firewall -# zone is now declared in /etc/shorewall/zones. -# - -# -# ENABLE IP FORWARDING -# -# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you -# say "Off" or "off", packet forwarding will be disabled. You would only want -# to disable packet forwarding if you are installing Shorewall on a -# standalone system or if you want all traffic through the Shorewall system -# to be handled by proxies. -# -# If you set this variable to "Keep" or "keep", Shorewall will neither -# enable nor disable packet forwarding. -# IP_FORWARDING=On -# -# AUTOMATICALLY ADD NAT IP ADDRESSES -# -# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses -# for each NAT external address that you give in /etc/shorewall/nat. If you say -# "No" or "no", you must add these aliases youself. -# -# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added -# during processing of the "shorewall restart" command. As a consequence, -# connections using those addresses may be severed. -# - ADD_IP_ALIASES=Yes -# -# AUTOMATICALLY ADD SNAT IP ADDRESSES -# -# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses -# for each SNAT external address that you give in /etc/shorewall/masq. If you -# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" -# unless you are sure that you need it -- most people don't!!! -# -# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added -# during processing of the "shorewall restart" command. As a consequence, -# connections using those addresses may be severed. -# - ADD_SNAT_ALIASES=No -# -# RETAIN EXISTING ALIASES/IP ADDRESSES -# -# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall -# will first delete the address then re-add it. This is to ensure that the -# address is added with the specified label. Unfortunately, this can cause -# problems if it results in the deletion of the last IP address on an -# interface because then all routes through the interface are automatically -# removed. -# -# You can cause Shorewall to retain existing addresses by setting -# RETAIN_ALIASES=Yes. -# - RETAIN_ALIASES=No -# -# ENABLE TRAFFIC SHAPING -# -# If you say "Yes" or "yes" here, Shorewall will use a script that you -# supply to configure traffic shaping. The script must be named 'tcstart' -# and must be placed in a directory on your CONFIG_PATH. -# -# If you say "No" or "no" then traffic shaping is not enabled. -# -# If you set TC_ENABLED=Internal or internal or leave the option empty then -# Shorewall will use its builtin traffic shaper (tc4shorewall written by -# Arne Bernin). -# -# See http://shorewall.net/traffic_shaping.htm for more information. - TC_ENABLED=Internal -# -# TRAFFIC SHAPING EXPERT -# -# Normally, Shorewall tries to protect users from themselves by preventing -# PREROUTING and OUTPUT tcrules from being applied to packets that have -# been marked by the 'track' option in /etc/shorewall/providers. -# -# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall -# will not include these cautionary checks. - TC_EXPERT=No -# -# Clear Traffic Shaping/Control -# -# 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=No 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 omitted, CLEAR_TC=Yes is assumed. -# - CLEAR_TC=Yes -# -# Mark Packets in the forward chain -# -# When processing the tcrules file, Shorewall normally marks packets in the -# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set -# this to "Yes". If not specified or if set to the empty value (e.g., -# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. -# -# Marking packets in the FORWARD chain has the advantage that inbound -# packets destined for Masqueraded/SNATed local hosts have had their -# destination address rewritten so they can be marked based on their -# destination. When packets are marked in the PREROUTING chain, packets -# destined for Masqueraded/SNATed local hosts still have a destination address -# corresponding to the firewall's external interface. -# -# Note: Older kernels do not support marking packets in the FORWARD chain and -# setting this variable to Yes may cause startup problems. -# - MARK_IN_FORWARD_CHAIN=No -# -# MSS CLAMPING -# -# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU" -# option. This option is most commonly required when your internet -# interface is some variant of PPP (PPTP or PPPoE). Your kernel must -# have CONFIG_IP_NF_TARGET_TCPMSS set. -# -# [From the kernel help: -# -# This option adds a `TCPMSS' target, which allows you to alter the -# MSS value of TCP SYN packets, to control the maximum size for that -# connection (usually limiting it to your outgoing interface's MTU -# minus 40). -# -# This is used to overcome criminally braindead ISPs or servers which -# block ICMP Fragmentation Needed packets. The symptoms of this -# problem are that everything works fine from your Linux -# firewall/router, but machines behind it can never exchange large -# packets: -# 1) Web browsers connect, then hang with no data received. -# 2) Small mail works fine, but large emails hang. -# 3) ssh works fine, but scp hangs after initial handshaking. -# ] -# -# If left blank, or set to "No" or "no", the option is not enabled. -# -# You may also set this option to a numeric value in which case Shorewall will -# set up a rule to modify the MSS value in SYN packets to the value that -# you specify. -# -# Example: -# -# CLAMPMSS=1400 -# - CLAMPMSS=No -# -# ROUTE FILTERING -# -# Set this variable to "Yes" or "yes" if you want kernel route filtering on all -# interfaces started while Shorewall is started (anti-spoofing measure). -# -# If this variable is not set or is set to the empty value, "No" is assumed. -# Regardless of the setting of ROUTE_FILTER, you can still enable route -# filtering on individual interfaces using the 'routefilter' option in the -# /etc/shorewall/interfaces file. -# - ROUTE_FILTER=No -# -# DNAT IP ADDRESS DETECTION -# -# Normally when Shorewall encounters the following rule: -# -# DNAT net loc:192.168.1.3 tcp 80 -# -# it will forward TCP port 80 connections from the net to 192.168.1.3 -# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is -# convenient for two reasons: -# -# a) If the the network interface has a dynamic IP address, the -# firewall configuration will work even when the address -# changes. -# -# b) It saves having to configure the IP address in the rule -# while still allowing the firewall to be started before the -# internet interface is brought up. -# -# This default behavior can also have a negative effect. If the -# internet interface has more than one IP address then the above -# rule will forward connection requests on all of these addresses; -# that may not be what is desired. -# -# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply -# only if the original destination address is the primary IP address of -# one of the interfaces associated with the source zone. Note that this -# requires all interfaces to the source zone to be up when the firewall -# is [re]started. -# - DETECT_DNAT_IPADDRS=No -# -# MUTEX TIMEOUT -# -# The value of this variable determines the number of seconds that programs -# will wait for exclusive access to the Shorewall lock file. After the number -# of seconds corresponding to the value of this variable, programs will assume -# that the last program to hold the lock died without releasing the lock. -# -# If not set or set to the empty value, a value of 60 (60 seconds) is assumed. -# -# An appropriate value for this parameter would be twice the length of time -# that it takes your firewall system to process a "shorewall restart" command. -# - MUTEX_TIMEOUT=60 -# -# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT -# -# Normally, when a "shorewall stop" command is issued or an error occurs during -# the execution of another shorewall command, Shorewall puts the firewall into -# a state where only traffic to/from the hosts listed in -# /etc/shorewall/routestopped is accepted. -# -# When performing remote administration on a Shorewall firewall, it is -# therefore recommended that the IP address of the computer being used for -# administration be added to the firewall's /etc/shorewall/routestopped file. -# -# Some administrators have a hard time remembering to do this with the result -# that they get to drive across town in the middle of the night to restart -# a remote firewall (or worse, they have to get someone out of bed to drive -# across town to restart a very remote firewall). -# -# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this -# setting, when the firewall enters the 'stopped' state: -# -# All traffic that is part of or related to established connections is still -# allowed and all OUTPUT traffic is allowed. This is in addition to traffic -# to and from hosts listed in /etc/shorewall/routestopped. -# -# If this variable is not set or it is set to the null value then -# ADMINISABSENTMINDED=No is assumed. -# - ADMINISABSENTMINDED=Yes -# -# BLACKLIST Behavior -# -# Shorewall offers two types of blacklisting: -# -# - static blacklisting through the /etc/shorewall/blacklist file -# together with the 'blacklist' interface option. -# - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands. -# -# The following variable determines whether the blacklist is checked for each -# packet or for each new connection. -# -# BLACKLISTNEWONLY=Yes Only consult blacklists for new connection -# requests -# -# BLACKLISTNEWONLY=No Consult blacklists for all packets. -# -# If the BLACKLISTNEWONLY option is not set or is set to the empty value then -# BLACKLISTNEWONLY=No is assumed. -# - BLACKLISTNEWONLY=Yes -# -# Users with a large blacklist find that "shorwall [re]start" takes a long -# time and that new connections are disabled during that time. By setting -# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections -# before loading the blacklist. -# - DELAYBLACKLISTLOAD=No -# MODULE NAME SUFFIX -# -# When loading a module named in /etc/shorewall/modules, Shorewall normally -# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names -# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a -# different naming convention then you can specify the suffix (extension) for -# module names in this variable. -# -# To see what suffix is used by your distribution: -# -# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter -# -# All of the file names listed should have the same suffix (extension). Set -# MODULE_SUFFIX to that suffix. -# -# Examples: -# -# If all file names end with ".kzo" then set MODULE_SUFFIX="kzo" -# If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o" -# - MODULE_SUFFIX= -# -# DISABLE IPV6 -# -# Distributions (notably SUSE) are beginning to ship with IPV6 -# enabled. If you are not using IPV6, you are at risk of being -# exploited by users who do. Setting DISABLE_IPV6=Yes will cause -# Shorewall to disable IPV6 traffic to/from and through your -# firewall system. This requires that you have ip6tables installed. - DISABLE_IPV6=Yes -# -# BRIDGING -# -# If you wish to restrict connections through a bridge -# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have -# the physdev match option enabled; that option is available at the above URL -# for 2.4 kernels and is included as a standard part of the 2.6 series -# kernels. If not specified or specified as empty (BRIDGING="") then "No" is -# assumed. -# - BRIDGING=No -# -# DYNAMIC ZONES -# -# If you need to be able to add and delete hosts from zones dynamically then -# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No. - DYNAMIC_ZONES=No -# -# USE PKTTYPE MATCH -# -# Some users have reported problems with the PKTTYPE match extension not being -# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall -# will use IP addresses to detect broadcasts rather than pkttype. If not given -# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed. -# - PKTTYPE=Yes -# -# RFC 1918 BEHAVIOR -# -# 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: -# -# SUBNETS TARGET -# 192.168.1.0/24 RETURN -# -# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you -# also have: -# -# SUBNETS TARGET -# 10.0.0.0/8 logdrop -# -# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped -# since while the packet's source matches the RETURN rule, the packet's -# destination matches the 'logdrop' rule. -# -# If not specified or specified as empty (e.g., RFC1918_STRICT="") then -# RFC1918_STRICT=No is assumed. -# -# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support -# 'conntrack state' match. -# - RFC1918_STRICT=No -# -# MAC List Table -# -# Normally, MAC verification occurs in the filter table (INPUT and FORWARD) -# chains. When forwarding a packet from an interface with MAC verification -# to a bridge interface, that doesn't work. -# -# This problem can be worked around by setting MACLIST_TABLE=mangle which -# will cause Mac verification to occur out of the PREROUTING chain. Because -# REJECT isn't available in that environment, you may not specify -# MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle. - MACLIST_TABLE=filter -# -# MACLIST caching -# -# If your iptables and kernel support the "Recent Match" (see the output of -# "shorewall check" near the top), you can cache the results of a 'maclist' -# file lookup and thus reduce the overhead associated with MAC Verification -# (/etc/shorewall/maclist). -# -# When a new connection arrives from a 'maclist' interface, the packet passes -# through the list of entries for that interface in /etc/shorewall/maclist. If -# there is a match then the source IP address is added to the 'Recent' set for -# that interface. Subsequent connection attempts from that IP address occuring -# within $MACLIST_TTL seconds will be accepted without having to scan all of -# the entries. After $MACLIST_TTL from the first accepted connection request, -# the next connection request from that IP address will be checked against -# the entire list. -# -# If MACLIST_TTL is not specified or is specified as empty (e.g, -# MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not -# be cached. -# - MACLIST_TTL= -# -# Save/Restore IPSETS -# -# If SAVE_IPSETS=Yes then Shorewall will: -# -# Restore the last saved ipset contents during "shorewall [re]start" -# Save the current ipset contents during "shorewall save" -# -# Regardless of the setting of SAVE_IPSETS, if ipset contents were -# saved during a "shorewall save" then they will be restored during -# a subsequent "shorewall restore". -# - SAVE_IPSETS=No -# -# Map Old Actions -# -# Previously, Shorewall included a large number of standard actions (AllowPing, -# AllowFTP, ...). These have been replaced with parameterized macros. For -# compatibility, Shorewall can map the old names into invocations of the new -# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to -# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed -# - MAPOLDACTIONS=No -# -# Fast ESTABLISHED/RELATED handling -# -# Normally, Shorewall delays 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/RELATED 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 and -# RELATED sections of the rules file. - FASTACCEPT=No -# -# Implicit CONTINUE policy for sub-zones -# -# When a zone is declared to be a subzone of one or more other zones, it -# is typically the case that you want the rules for the parent zone(s) to -# be applied to connections to/from the subzone that don't match any -# subzone specific rules. That way, you don't have to duplicate the parent -# zone's rules in order for them to also apply to the subzone(s). That is -# the behavior with IMPLICIT_CONTINUE=Yes. If you don't want that behavior -# and want the policies for the sub-zone to be determined by the standard -# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=. -# -# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit -# CONTINUE policy by adding an explicit policy (one that does not contain -# "all" in either the SOURCE or DEST columns). - IMPLICIT_CONTINUE=Yes -# -# Use high mark values for policy routing -# -# Normally, Shorewall restricts the set of mark values to 1-255. If you set -# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing -# mark values (those specified in the /etc/shorewall/providers file) to -# a multiple of 256 (256 to 65280) or their hexadecimal equivalents -# (0x0100 to 0xff00, with the low-order byte of the value being zero). -# This allows connection marks to be shared between traffic shaping and -# policy routing. Traffic shaping marks are always restricted to 1-255. -# -# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support -# both the extended CONNMARK target and the extended connmark match -# capabilities (see the output of "shorewall show capabilities"). - HIGH_ROUTE_MARKS=No -# -# Use Actions -# -# While Shorewall Actions can be very useful, they also require a sizable -# amount of code to implement. By setting USE_ACTIONS=No, you can omit -# /usr/share/shorewall/lib/actions from your configuration. - USE_ACTIONS=Yes -# -# Optimize Ruleset -# -# Traditionally, Shorewall has created rules for the complete matrix of -# Networks defined by the zones, interfaces and hosts files. Any traffic that -# didn't correspond to an element of that matrix was rejected in one of the -# built-in changes. When the matrix is sparse, this results in lots of -# largely useless rules. -# -# These extra rules can be eliminated by setting OPTIMIZE=1 -# - OPTIMIZE=0 ############################################################################### # P A C K E T D I S P O S I T I O N ############################################################################### -# -# BLACKLIST DISPOSITION -# -# Set this variable to the action that you want to perform on packets from -# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty, -# DROP is assumed. -# BLACKLIST_DISPOSITION=DROP -# -# MAC List Disposition -# -# This variable determines the disposition of connection requests arriving -# on interfaces that have the 'maclist' option and that are from a device -# that is not listed for that interface in /etc/shorewall/maclist. Valid -# values are ACCEPT, DROP and REJECT. If not specified or specified as -# empty (MACLIST_DISPOSITION="") then REJECT is assumed -# - MACLIST_DISPOSITION=REJECT -# -# TCP FLAGS Disposition -# -# This variable determins the disposition of packets having an invalid -# combination of TCP flags that are received on interfaces having the -# 'tcpflags' option specified in /etc/shorewall/interfaces or in -# /etc/shorewall/hosts. If not specified or specified as empty -# (TCP_FLAGS_DISPOSITION="") then DROP is assumed. -# - TCP_FLAGS_DISPOSITION=DROP #LAST LINE -- DO NOT REMOVE