Shorewall 2.3.3 ----------------------------------------------------------------------- Problems corrected in version 2.3.2 None. ----------------------------------------------------------------------- New Features in version 2.3.2 1) Shorewall 2.3.2 can now configure routing if your kernel and iptables support the ROUTE target extension. This extension is available in Patch-O-Matic-ng. Routing is configured using the /etc/shorewall/routes file. Columns in the file are as follows: SOURCE Source of the packet. May be any of the following: - A host or network address - A network interface name. - The name of an ipset prefaced with "+" - $FW (for packets originating on the firewall) - A MAC address in Shorewall format - A range of IP addresses (assuming that your kernel and iptables support range match) - A network interface name followed by ":" and an address or address range. DEST Destination of the packet. May be any of the following: - A host or network address - A network interface name (determined from routing table(s)) - The name of an ipset prefaced with "+" - A network interface name followed by ":" and an address or address range. PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p", 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. INTERFACE The interface that the packet is to be routed out of. If you do not specify this field then you must place "-" in this column and enter an IP address in the GATEWAY column. GATEWAY The gateway that the packet is to be forewarded through. ----------------------------------------------------------------------- Problems corrected in version 2.3.1 1) A typo in the 'tunnel' script has been corrected (thanks to Patrik Varmecký). 2) Previously, if "shorewall save" was done with SAVE_IPSETS=Yes then Shorewall would fail fast start on reboot because the ipset modules were not loaded. ----------------------------------------------------------------------- New Features in version 2.3.0 1) Shorewall 2.3.0 supports the 'cmd-owner' option of the owner match facility in Netfilter. Like all owner match options, 'cmd-owner' may only be applied to traffic that originates on the firewall. The syntax of the USER/GROUP column in the following files has been extended: /etc/shorewall/accounting /etc/shorewall/rules /etc/shorewall/tcrules /usr/share/shorewall/action.template To specify a command, prefix the command name with "+". Examples: +mozilla-bin #The program is named "mozilla-bin" joe+mozilla-bin #The program is named "mozilla-bin" and #is being run by user "joe" joe:users+mozilla-bin #The program is named "mozilla-bin" and #is being run by user "joe" with #effective group "users". Note that this is not a particularly robust feature and I would never advertise it as a "Personal Firewall" equivalent. Using symbolic links, it's easy to alias command names to be anything you want. 2) Support has been added for ipsets (see http://people.netfilter.org/kadlec/ipset/). In most places where a host or network address may be used, you may also use the name of an ipset prefaced by "+". Example: "+Mirrors" The name of the set may be optionally followed by: a) a number from 1 to 6 enclosed in square brackets ([]) -- this number indicates the maximum number of ipset binding levels that are to be matched. Depending on the context where the ipset name is used, either all "src" or all "dst" matches will be used. Example: "+Mirrors[4]" b) a series of "src" and "dst" options separated by commas and inclosed in square brackets ([]). These will be passed directly to iptables in the generated --set clause. See the ipset documentation for details. Example: "+Mirrors[src,dst,src]" Note that "+Mirrors[4]" used in the SOURCE column of the rules file is equivalent to "+Mirrors[src,src,src,src]". To generate a negative match, prefix the "+" with "!" as in "!+Mirrors". Example 1: Blacklist all hosts in an ipset named "blacklist" /etc/shorewall/blacklist #ADDRESS/SUBNET PROTOCOL PORT +blacklist Example 2: Allow SSH from all hosts in an ipset named "sshok: /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT +sshok fw tcp 22 Shorewall can automatically capture the contents of your ipsets for you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf then "shorewall save" will save the contents of your ipsets. The file where the sets are saved is formed by taking the name where the Shorewall configuration is stored and appending "-ipsets". So if you enter the command "shorewall save standard" then your Shorewall configuration will be saved in /var/lib/shorewall/standard and your ipset contents will be saved in /var/lib/shorewall/standard-ipsets. Assuming the default RESTOREFILE setting, if you just enter "shorewall save" then your Shorewall configuration will be saved in /var/lib/shorewall/restore and your ipset contents will be saved in /var/lib/shorewall/restore-ipsets. Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and "shorewall restore" commands will restore the ipset contents corresponding to the Shorewall configuration restored provided that the saved Shorewall configuration specified exists. For example, "shorewall restore standard" would restore the ipset contents from /var/lib/shorewall/standard-ipsets provided that /var/lib/shorewall/standard exists and is executable and that /var/lib/shorewall/standard-ipsets exists and is executable. Also regardless of the setting of SAVE_IPSETS, the "shorewall forget" command will purge the saved ipset information (if any) associated with the saved shorewall configuration being removed. You can also associate ipset contents with Shorewall configuration directories using the following command: ipset -S > /ipsets Example: ipset -S > /etc/shorewall/ipsets When you start or restart Shorewall (including using the 'try' command) from the configuration directory, your ipsets will be configured from the saved ipsets file. Once again, this behavior is independent of the setting of SAVE_IPSETS. Ipsets are well suited for large blacklists. You can maintain your blacklist using the 'ipset' utility without ever having to restart or refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure to "shorewall save" after altering the blacklist ipset(s). Example /etc/shorewall/blacklist: #ADDRESS/SUBNET PROTOCOL PORT +Blacklist[src,dst] +Blacklistnets[src,dst] Create the blacklist ipsets using: ipset -N Blacklist iphash ipset -N Blacklistnets nethash Add entries ipset -A Blacklist 206.124.146.177 ipset -A Blacklistnets 206.124.146.0/24 To allow entries for individual ports ipset -N SMTP portmap --from 1 --to 31 ipset -A SMTP 25 ipset -A Blacklist 206.124.146.177 ipset -B Blacklist 206.124.146.177 -b SMTP Now only port 25 will be blocked from 206.124.146.177.