From d8d1e96e0d814e10e3bc19fb3dc36600ff94d513 Mon Sep 17 00:00:00 2001 From: Tom Eastep Date: Mon, 3 Aug 2015 14:37:15 -0700 Subject: [PATCH] Delete manpages for files no longer supported Signed-off-by: Tom Eastep --- Shorewall/manpages/shorewall-blacklist.xml | 202 --- Shorewall/manpages/shorewall-tcrules.xml | 1344 -------------------- 2 files changed, 1546 deletions(-) delete mode 100644 Shorewall/manpages/shorewall-blacklist.xml delete mode 100644 Shorewall/manpages/shorewall-tcrules.xml diff --git a/Shorewall/manpages/shorewall-blacklist.xml b/Shorewall/manpages/shorewall-blacklist.xml deleted file mode 100644 index b7f6e4310..000000000 --- a/Shorewall/manpages/shorewall-blacklist.xml +++ /dev/null @@ -1,202 +0,0 @@ - - - - - shorewall-blacklist - - 5 - - Configuration Files - - - - blacklist - - Shorewall Blacklist file - - - - - /etc/shorewall/blacklist - - - - - Description - - The blacklist file is used to perform static blacklisting by source - address (IP or MAC), or by application. The use of this file is deprecated - and beginning with Shorewall 4.5.7, the file is no longer - installed. - - The columns in the file are as follows (where the column name is - followed by a different name in parentheses, the different name is used in - the alternate specification syntax). - - - - ADDRESS/SUBNET (networks) - - {-|~mac-address|ip-address|address-range|+ipset} - - - Host address, network address, 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). - Exclusion (shorewall-exclusion(5)) - is supported. - - 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 using entries in the PROTOCOL and PORTS columns. - - - - - PROTOCOL (proto) - {-|[!]protocol-number|[!]protocol-name} - - - Optional - If specified, must be a protocol number or a - protocol name from protocols(5). - - - - - PORTS - {-|[!]port-name-or-number[,port-name-or-number]...} - - - 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 services(5). - - - - - OPTIONS - {-|{dst|src|whitelist|audit}[,...]} - - - Optional - added in 4.4.12. If specified, indicates whether - traffic from ADDRESS/SUBNET (src) or traffic to - ADDRESS/SUBNET (dst) should be - blacklisted. The default is src. If - the ADDRESS/SUBNET column is empty, then this column has no effect - on the generated rule. - - - In Shorewall 4.4.12, the keywords from and to were used in - place of src and dst respectively. Blacklisting was still - restricted to traffic arriving on an - interface that has the 'blacklist' option set. So to block traffic - from your local network to an internet host, you had to specify - on your internal interface in shorewall-interfaces - (5). - - - - Beginning with Shorewall 4.4.13, entries are applied based - on the blacklist setting in - shorewall-zones(5): - - - - 'blacklist' in the OPTIONS or IN_OPTIONS column. Traffic - from this zone is passed against the entries in this file that - have the src option - (specified or defaulted). - - - - 'blacklist' in the OPTIONS or OUT_OPTIONS column. - Traffic to this zone is passed against the entries in this - file that have the dst - option. - - - - - In Shorewall 4.4.20, the whitelist option was added. When whitelist is specified, packets/connections - that match the entry are not matched against the remaining entries - in the file. - - The audit option was also - added in 4.4.20 and causes packets matching the entry to be audited. - The audit option may not be - specified in whitelist entries and require AUDIT_TARGET support in - the kernel and iptables. - - - - - - - - - Example - - - - Example 1: - - - To block DNS queries from address 192.0.2.126: - - #ADDRESS/SUBNET PROTOCOL PORT - 192.0.2.126 udp 53 - - - - - Example 2: - - - To block some of the nuisance applications: - - #ADDRESS/SUBNET PROTOCOL PORT - - udp 1024:1033,1434 - - tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898 - - - - - - - FILES - - /etc/shorewall/blacklist - - - - See ALSO - - http://www.shorewall.net/blacklisting_support.htm - - http://www.shorewall.net/configuration_file_basics.htm#Pairs - - shorewall(8), shorewall-accounting(5), shorewall-actions(5), - shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), - shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), - shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), - shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), - shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), - shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), - shorewall-mangle(5), shorewall-tos(5), shorewall-tunnels(5), - shorewall-zones(5) - - diff --git a/Shorewall/manpages/shorewall-tcrules.xml b/Shorewall/manpages/shorewall-tcrules.xml deleted file mode 100644 index c35ddbc92..000000000 --- a/Shorewall/manpages/shorewall-tcrules.xml +++ /dev/null @@ -1,1344 +0,0 @@ - - - - - shorewall-mangle - - 5 - - Configuration Files - - - - tcrules - - Shorewall Packet Marking rules file - - - - - /etc/shorewall/tcrules - - - - - Description - - Entries in this file cause packets to be marked as a means of - classifying them for traffic control or policy routing. - - - Unlike rules in the shorewall-rules(5) 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://www.shorewall.net/MultiISP.html. - - - Beginning with Shorewall 4.5.4, the tcrules file supports two - different formats: - - - - FORMAT 1 (default - deprecated) - - - The older limited-function version of TPROXY is - supported. - - - - - FORMAT 2 - - - The newer version of TPROXY is supported. - - - - - The format is specified by a line as follows: - -
- [?]FORMAT {1|2} -
- - The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is - the preferred form; the form without the '?' is deprecated. - - The columns in the file are as follows (where the column name is - followed by a different name in parentheses, the different name is used in - the alternate specification syntax). - - - - ACTION (mark) - - mark - - - Where mark may assume one of the - following values. - - - - A mark value which is an integer in - the range 1-255. - - 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). - - May optionally be followed by :P, :F,:T or - :I where - :P indicates that marking should occur in the - PREROUTING chain, :F indicates - that marking should occur in the FORWARD chain, :I indicates that marking should occur in - the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in - the POSTROUTING chain. If neither :P, :F - nor :T follow the mark value - then the chain is determined as follows: - - - If the SOURCE is $FW[:address-or-range[,address-or-range]...], - then the rule is inserted into the OUTPUT chain. When - HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned - there. Packet marking rules for traffic shaping of packets - originating on the firewall must be coded in the POSTROUTING - chain (see below). - - - Otherwise, the chain is determined by the setting of - MARK_IN_FORWARD_CHAIN in shorewall.conf(5). - - Please note that :I is - included for completeness and affects neither traffic shaping - nor policy routing. - - 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). When a mask is specified, the result of - logically ANDing the mark value with the mask must be the same - as the mark value. - - 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. - - - - - CT - - - Mark the connection in the POSTROUTING chain - - - - - CI - - - Mark the connection in the INPUT chain. This option - is included for completeness and has no applicability to - traffic shaping or policy routing. - - - - - - - A mark range which is a pair of integers separated by a - dash ("-"). Added in Shorewall 4.5.9. - - May be optionally followed by a slash ("/") and a mask and - requires the Statistics Match capability - in iptables and kernel. Marks in the specified range are - assigned to packets on a round-robin fashion. - - When a mask is specified, the result of logically ANDing - each mark value with the mask must be the same as the mark - value. The least significant bit in the mask is used as an - increment. For example, if '0x200-0x400/0xff00' is specified, - then the assigned mark values are 0x200, 0x300 and 0x400 in - equal proportions. If no mask is specified, then ( 2 ** - MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall.conf(5)). - - May optionally be followed by :P, :F,:T or - :I where - :P indicates that marking should occur in the - PREROUTING chain, :F indicates - that marking should occur in the FORWARD chain, :I indicates that marking should occur in - the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in - the POSTROUTING chain. If neither :P, :F - nor :T follow the mark value - then the chain is determined as follows: - - - If the SOURCE is $FW[:address-or-range[,address-or-range]...], - then the rule is inserted into the OUTPUT chain. When - HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned - there. Packet marking rules for traffic shaping of packets - originating on the firewall must be coded in the POSTROUTING - chain (see below). - - - Otherwise, the chain is determined by the setting of - MARK_IN_FORWARD_CHAIN in shorewall.conf(5). - - Please note that :I is - included for completeness and affects neither traffic shaping - nor policy routing. - - If your kernel and iptables include CONNMARK support then - you can also mark the connection rather than the packet. - - The mark range and optional mask can 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. - - - - - CT - - - Mark the connection in the POSTROUTING chain - - - - - CI - - - Mark the connection in the INPUT chain. This option - is included for completeness and has no applicability to - traffic shaping or policy routing. - - - - - - - A classification Id (classid) of the form - major:minor where - major and minor 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[:address] in - which case classification occurs in the OUTPUT chain. - - When using Shorewall's built-in traffic shaping tool, the - major class is the device number (the first - device in shorewall-tcdevices(5) - is major class 1, the second device is major class 2, and so on) - and the minor class is the class's MARK - value in shorewall-tcclasses(5) - preceded by the number 1 (MARK 1 corresponds to minor class 11, - MARK 5 corresponds to minor class 15, MARK 22 corresponds to - minor class 122, etc.). - - Beginning with Shorewall 4.4.27, the classid may be - optionally followed by ':' and a capital letter designating the - chain where classification is to occur. - - - - F - - - FORWARD chain. - - - - - T - - - POSTROUTING chain (default). - - - - - - - CHECKSUM - - Added in Shorewall 4.5.9. Compute and fill in the checksum - in a packet that lacks a checksum. This is particularly useful - if you need to work around old applications, such as dhcp - clients, that do not work well with checksum offloads, but you - don't want to disable checksum offload in your device. - - Requires 'Checksum Target' support in your kernel and - iptables. - - - - [?]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. - - - Beginning with Shorewall 4.5.11, ?COMMENT is a synonym - for COMMENT and is preferred. - - - - - CONTINUE Don't process - any more marking rules ‒in the table. - - As in 1) above, may be followed by :P or :F. Currently, CONTINUE may not be used - with exclusion (see the SOURCE and DEST - columns below); that restriction will be removed when - iptables/Netfilter provides the necessary support. - - - - DIVERT - - Added in Shorewall 4.5.4 and only available when FORMAT is - 2. Two DIVERT rule should precede the TPROXY rule and should - select DEST PORT tcp 80 and SOURCE PORT tcp 80 respectively - (assuming that tcp port 80 is being proxied). DIVERT avoids - sending packets to the TPROXY target once a socket connection to - Squid3 has been established by TPROXY. DIVERT marks the packet - with a unique mark and exempts it from any rules that - follow. - - - - DROP - - Added in Shorewall 4.5.21.4. Causes matching packets to be - discarded. - - - - DSCP(dscp) - - Added in Shorewall 4.5.1. Sets the - Differentiated Services Code Point field - in the IP header. The dscp value may - be given as an even number (hex or decimal) or as the name of a - DSCP class. Valid class names and their associated hex numeric - values are: - - CS0 => 0x00 - CS1 => 0x08 - CS2 => 0x10 - CS3 => 0x18 - CS4 => 0x20 - CS5 => 0x28 - CS6 => 0x30 - CS7 => 0x38 - BE => 0x00 - AF11 => 0x0a - AF12 => 0x0c - AF13 => 0x0e - AF21 => 0x12 - AF22 => 0x14 - AF23 => 0x16 - AF31 => 0x1a - AF32 => 0x1c - AF33 => 0x1e - AF41 => 0x22 - AF42 => 0x24 - AF43 => 0x26 - EF => 0x2e - - To indicate more than one class, add their hex values - together and specify the result. - - May be optionally followed by ':' and a capital letter - designating the chain where classification is to occur. - - - - F - - - FORWARD chain. - - - - - T - - - POSTROUTING chain (default). - - - - - - - IMQ(number) - - Added in Shorewall 4.5.1. Specifies that the packet should - be passed to the IMQ identified by - number. Requires IMQ Target support - in your kernel and iptables. - - - - INLINE[(action)] - - Added in Shorewall 4.6.0. Allows you to place your own - ip[6]tables matches at the end of the line following a semicolon - (";"). If an action is specified, the - compiler procedes as if that action - had been specified in this column. If no action is specified, - then you may include your own jump ("-j - target - [option] ...") after any matches - specified at the end of the rule. If the target is not one known - to Shorewall, then it must be defined as a builtin action in - shorewall-actions - (5). - - The following rules are equivalent: - - 2:P eth0 - tcp 22 -INLINE(2):P eth0 - tcp 22 -INLINE(2):P eth0 - ; -p tcp -INLINE eth0 - tcp 22 ; -j MARK --set-mark 2 -INLINE eth0 - ; -p tcp -j MARK --set-mark 2 - - - If INLINE_MATCHES=Yes in shorewall.conf(5) - then the third rule above can be specified as follows: - - 2:P eth0 - ; -p tcp - - - - IPMARK ‒ Assigns a mark - to each matching packet based on the either the source or - destination IP address. By default, it assigns a mark value - equal to the low-order 8 bits of the source address. Default - values are: - - - src - - mask1 = 0xFF - - mask2 = 0x00 - - shift = 0 - - - 'src' and 'dst' specify whether the mark is to be based on - the source or destination address respectively. The selected - address is first shifted to the right by - shift bits. The result is then LANDed with - mask1 then LORed with - mask2. - - In a sense, the IPMARK target is more like an IPCLASSIFY - target in that the mark value is later interpreted as a class - ID. A packet mark is 32 bits wide; so is a class ID. The - <major> class occupies the high-order 16 bits and the - <minor> class occupies the low-order 16 bits. So the class - ID 1:4ff (remember that class IDs are always in hex) is - equivalent to a mark value of 0x104ff. Remember that Shorewall - uses the interface number as the <major> number where the - first interface in tcdevices has <major> number 1, the - second has <major> number 2, and so on. - - The IPMARK target assigns a mark to each matching packet - based on the either the source or destination IP address. By - default, it assigns a mark value equal to the low-order 8 bits - of the source address. The syntax is as follows: - -
- [([{|}][,[mask1][,[mask2][,[shift]]]])] -
- - Default values are: - - - - - mask1 = 0xFF - - mask2 = 0x00 - - shift = 0 - - - and specify - whether the mark is to be based on the source or destination - address respectively. The selected address is first shifted - right by shift, then LANDed with - mask1 and then LORed with - mask2. The - shift argument is intended to be used - primarily with IPv6 addresses. - - Example: - -
- IPMARK(src,0xff,0x10100) - - - Suppose that the source IP address is 192.168.4.3 = - 0xc0a80403; then - - 0xc0a80403 >> 0 = 0xc0a80403 - - 0xc0a80403 LAND 0xFF = 0x03 - - 0x03 LOR 0x0x10100 = 0x10103 or class ID - 1:103 - -
- - It is important to realize that, while class IDs are - composed of a major and a - minor value, the set of values must - be unique. That is, the same numeric value cannot be used as - both a major and a - minor number for the same interface - unless class nesting occurs (which is not currently possible - with Shorewall). You should keep this in mind when deciding how - to map IP addresses to class IDs. - - For example, suppose that your internal network is - 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). - Your first notion might be to use IPMARK(src,0xFF,0x10000) so as - to produce class IDs 1:1 through 1:6. But 1:1 is an invalid - class ID since the major and - minor classes are equal. So you might - choose instead to use IPMARK(src,0xFF,0x10100) as in the example - above so that all of your minor - classes will have a value > 256. - - - - 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 1) above, may be followed by :P or :F - - - - SAME Some websites run - applications that require multiple connections from a client - browser. Where multiple 'balanced' providers are configured, - this can lead to problems when some of the connections are - routed through one provider and some through another. The SAME - target allows you to work around that problem. SAME may be used - in the PREROUTING and OUTPUT chains. When used in PREROUTING, it - causes matching connections from an individual local system to - all use the same provider. For example: #ACTION SOURCE DEST PROTO DEST -# PORT(S) -SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443 - If a host in 192.168.1.0/24 attempts a connection on TCP port 80 - or 443 and it has sent a packet on either of those ports in the - last five minutes then the new connection will use the same - provider as the connection over which that last packet was - sent. - - When used in the OUTPUT chain, it causes all matching - connections to an individual remote system to all use the same - provider. For example:#ACTION SOURCE DEST PROTO DEST -# PORT(S) -SAME $FW 0.0.0.0/0 tcp 80,443 - If the firewall attempts a connection on TCP port 80 or 443 and - it has sent a packet on either of those ports in the last five - minutes to the same remote system then the new connection will - use the same provider as the connection over which that last - packet was sent. - - - - 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 1) above, may be followed by :P or :F - - - - TOS(tos[/mask]) - - Added in Shorewall 4.5.1. Sets the Type of - Service field in the IP header. The - tos value may be given as an number - (hex or decimal) or as the name of a TOS type. Valid type names - and their associated hex numeric values are: - - Minimize-Delay => 0x10, -Maximize-Throughput => 0x08, -Maximize-Reliability => 0x04, -Minimize-Cost => 0x02, -Normal-Service => 0x00 - - To indicate more than one class, add their hex values - together and specify the result. - - When tos is given as a number, - it may be optionally followed by '/' and a - mask. When no - mask is given, the value 0xff is - assumed. When tos is given as a type - name, the mask 0x3f is - assumed. - - The action performed is to zero out the bits specified by - the mask, then set the bits specified - by tos. - - May be optionally followed by ':' and a capital letter - designating the chain where classification is to occur. - - - - F - - - FORWARD chain. - - - - - T - - - POSTROUTING chain. - - - - - - - TPROXY(mark[,[port][,[address]]]) - -- FORMAT 1 - - Transparently redirects a packet without altering the IP - header. Requires a local provider to be defined in shorewall-providers(5). - - There are three parameters to TPROXY - only the first - (mark) is required: - - - - mark - the MARK value - corresponding to the local provider in shorewall-providers(5). - - - - port - the port on which - the proxy server is listening. If omitted, the original - destination port. - - - - address - a local (to the - firewall) IP address on which the proxy server is listening. - If omitted, the IP address of the interface on which the - request arrives. - - - - - - TPROXY([port][,address]) - -- FORMAT 2 - - Transparently redirects a packet without altering the IP - header. Requires a tproxy provider to be defined in shorewall-providers(5). - - There are three parameters to TPROXY - neither is - required: - - - - port - the port on which - the proxy server is listening. If omitted, the original - destination port. - - - - address - a local (to the - firewall) IP address on which the proxy server is listening. - If omitted, the IP address of the interface on which the - request arrives. - - - - - - TTL([-|+]number) - - Added in Shorewall 4.4.24. - - Prior to Shorewall 4.5.7.2, may be optionally followed by - :F but the resulting rule is - always added to the FORWARD chain. Beginning with Shorewall - 4.5.7.s, it may be optionally followed by :P, in which case the rule is added to - the PREROUTING chain. - - If + is included, packets - matching the rule will have their TTL incremented by - number. Similarly, if - is included, matching packets have - their TTL decremented by number. If - neither + nor - is given, the TTL of matching packets - is set to number. The valid range of - values for number is 1-255. - - - - - - - SOURCE - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion] - - - May be: - - - - An interface name - matches traffic entering the firewall - on the specified interface. May not be used in classify rules or - in rules using the :T chain qualifier. - - - - A comma-separated list of host or network IP addresses or - MAC addresses. This form will not match - traffic that originates on the firewall itself unless either - <major><minor> or the :T chain qualifier is used in - the ACTION column. - - Examples: - 0.0.0.0/0 - - - - 192.168.1.0/24, 172.20.4.0/24 - - - - - An interface name followed by a colon (":") followed by a - comma-separated list of host or network IP addresses or MAC - addresses. May not be used in classify rules or in rules using - the :T chain qualifier. - - - - $FW optionally followed by a colon (":") and a - comma-separated list of host or network IP addresses. Matches - packets originating on the firewall. May not be used with a - chain qualifier (:P, :F, etc.) in the ACTION column. - - - - MAC addresses must be prefixed with "~" and use "-" as a - separator. - - Example: ~00-A0-C9-15-39-78 - - You may exclude certain hosts from the set already defined - through use of an exclusion (see shorewall-exclusion(5)). - - - - - DEST - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion] - - - May be: - - - - An interface name. May not be used in the PREROUTING chain - (:P in the mark column or no chain qualifier and - MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)). The - interface name may be optionally followed by a colon (":") and - an IP address list. - - - - A comma-separated list of host or network IP addresses. - The list may include ip address ranges if your kernel and - iptables include iprange support. - - - - Beginning with Shorewall 4.4.13, $FW may be specified by - itself or qualified by an address list. This causes marking to - occur in the INPUT chain. - - - - You may exclude certain hosts from the set already defined - through use of an exclusion (see shorewall-exclusion(5)). - - - - - PROTO - {-|{tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]} - - - Protocol - ipp2p requires - ipp2p match support in your kernel and iptables. - - Beginning with Shorewall 4.5.12, this column can accept a - comma-separated list of protocols. - - - - - PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...] - - - Optional destination Ports. A comma-separated list of Port - names (from services(5)), port numbers or - port ranges; if the protocol is icmp, this column is interpreted as the - destination icmp-type(s). ICMP types may be specified as a numeric - type, a numeric type and code separated by a slash (e.g., 3/4), or a - typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. - - 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. - - An entry in this field requires that the PROTO column specify - icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if - any of the following field is supplied. - - - - - SOURCE PORT(S) (sport) - - [-|port-name-number-or-range[,port-name-number-or-range]...] - - - 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. - - An entry in this field requires that the PROTO column specify - tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of - the following fields is supplied. - - Beginning with Shorewall 4.5.15, you may place '=' in this - column, provided that the DEST PORT(S) column is non-empty. This - causes the rule to match when either the source port or the - destination port in a packet matches one of the ports specified in - DEST PORTS(S). Use of '=' requires multi-port match in your iptables - and kernel. - - - - - USER - [!][user-name-or-number][:group-name-or-number][+program-name] - - - This optional 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 - 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 - - - The ability to specify a program name was removed from - Netfilter in kernel version 2.6.14. - - - - - - - - - TEST - [!]value[/mask][:C] - - - Optional - Defines a test on the existing packet or connection - mark. The rule will match only if the test returns true. - - If you don't want to define a test but need to specify - anything in the following columns, place a "-" in this field. - - - - ! - - - Inverts the test (not equal) - - - - - value - - - Value of the packet or connection mark. - - - - - mask - - - A mask to be applied to the mark before testing. - - - - - :C - - - Designates a connection mark. If omitted, the packet - mark's value is tested. - - - - - - - - LENGTH - - [length|[min]:[max]] - - - Optional - packet payload length. This field, if present allow - you to match the length of a packet payload (Layer 4 data ) 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 - min:max where either - min or max (but not both) - may be omitted. If min is omitted, then 0 is - assumed; if max is omitted, than any packet - that is min or longer will match. - - - - - TOS - - 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) - - - - - CONNBYTES - - [!]min:[max[:{O|R|B}[:{B|P|A}]]] - - - Optional connection Bytes; defines a byte or packet range that - the connection must fall within in order for the rule to - match. - - A packet matches if the the packet/byte count is within the - range defined by min and - max (unless ! is given in which case, a packet - matches if the packet/byte count is not within the range). - min is an integer which defines the beginning - of the byte/packet range. max is an integer - which defines the end of the byte/packet range; if omitted, only the - beginning of the range is checked. The first letter gives the - direction which the range refers to:
- O - The original - direction of the connection. - - - The opposite direction from the original - connection. - - B - The total of both - directions. -
- - If omitted, B is - assumed. - - The second letter determines what the range refers - to.
- B - Bytes - - P - Packets - - A - Average packet - size. -
If omitted, B is - assumed. - - - - - HELPER - - helper - - - Names a Netfilter protocol helper - module such as , , - , etc. A packet will match if it was accepted - by the named helper module. - - Example: Mark all FTP data connections with mark - 4:#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER -# PORT(S) -4:T 0.0.0.0/0 0.0.0.0/0 TCP - - - - - - - ftp - - - - - PROBABILITY - - [probability] - - - Added in Shorewall 4.5.0. When non-empty, requires the - Statistics Match capability in your kernel - and ip6tables and causes the rule to match randomly but with the - given probability. The - probability is a number 0 < - probability <= 1 and may be expressed - at up to 8 decimal points of precision. - - - - - DSCP - - [[!]dscp] - - - Added in Shorewall 4.5.1. When non-empty, match packets whose - Differentiated Service Code Point field - matches the supplied value (when '!' is given, the rule matches - packets whose DSCP field does not match the supplied value). The - dscp value may be given as an even number - (hex or decimal) or as the name of a DSCP class. Valid class names - and their associated hex numeric values are: - - CS0 => 0x00 - CS1 => 0x08 - CS2 => 0x10 - CS3 => 0x18 - CS4 => 0x20 - CS5 => 0x28 - CS6 => 0x30 - CS7 => 0x38 - BE => 0x00 - AF11 => 0x0a - AF12 => 0x0c - AF13 => 0x0e - AF21 => 0x12 - AF22 => 0x14 - AF23 => 0x16 - AF31 => 0x1a - AF32 => 0x1c - AF33 => 0x1e - AF41 => 0x22 - AF42 => 0x24 - AF43 => 0x26 - EF => 0x2e - - - - - STATE -- {NEW|RELATED|ESTABLISHED|INVALID} [,...] - - - Added in Shorewall 4.5.9. The rule will only match if the - packet's connection is in one of the listed states. - - - - - - - Example - - - - 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 means unclassified. - - #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST - # PORT(S) - 1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-request - 1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-reply - RESTORE:T 0.0.0.0/0 0.0.0.0/0 all - - - 0 - CONTINUE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0 - 4:T 0.0.0.0/0 0.0.0.0/0 ipp2p:all - SAVE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0 - - If a packet hasn't been classified (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. - - - - - Example 2: - - - SNAT outgoing connections on eth0 from 192.168.1.0/24 in - round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 - (Shorewall 4.5.9 and later). - - /etc/shorewall/tcrules: - - #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST - # PORT(S) - 1-3:CF 192.168.1.0/24 eth0 ; state=NEW - -/etc/shorewall/masq: - - #INTERFACE SOURCE ADDRESS ... - eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C - eth0 192.168.1.0/24 1.1.1.3 ; mark=2:C - eth0 192.168.1.0/24 1.1.1.4 ; mark=3:C - - - - - - - FILES - - /etc/shorewall/tcrules - - - - See ALSO - - http://www.shorewall.net/traffic_shaping.htm - - http://www.shorewall.net/MultiISP.html - - http://www.shorewall.net/PacketMarking.html - - http://www.shorewall.net/configuration_file_basics.htm#Pairs - - shorewall(8), shorewall-accounting(5), shorewall-actions(5), - shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5), - shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), - shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), - shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), - shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), - shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), - shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), - shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) - -