diff --git a/Shorewall2/accounting b/Shorewall2/accounting index 90fcfd673..3b8cbedfd 100644 --- a/Shorewall2/accounting +++ b/Shorewall2/accounting @@ -69,7 +69,7 @@ # # The column may contain: # -# [!][][:] +# [!][][:][/] # # When this column is non-empty, the rule applies only # if the program generating the output is running under @@ -83,6 +83,7 @@ # #the 'kids' group # !:kids #program must not be run by a member # #of the 'kids' group +# /upnpd #program named upnpd # # In all of the above columns except ACTION and CHAIN, the values "-", # "any" and "all" may be used as wildcards diff --git a/Shorewall2/action.template b/Shorewall2/action.template index c31b61f07..210b590c2 100644 --- a/Shorewall2/action.template +++ b/Shorewall2/action.template @@ -146,7 +146,7 @@ # # The column may contain: # -# [!][][:] +# [!][][:][/] # # When this column is non-empty, the rule applies only # if the program generating the output is running under @@ -160,6 +160,7 @@ # #the 'kids' group # !:kids #program must not be run by a member # #of the 'kids' group +# /upnpd #program named upnpd # ###################################################################################### #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ diff --git a/Shorewall2/changelog.txt b/Shorewall2/changelog.txt index 11288bc27..cfa2a7bdb 100644 --- a/Shorewall2/changelog.txt +++ b/Shorewall2/changelog.txt @@ -1,290 +1,3 @@ -Changes in 2.2.4 +Changes in 2.3.0 -1) Added support for UPnP - -2) Add 'started' hook. - -3) Make an error message more self-explanatory - -4) Report Owner Match capability - -5) Add Paul Traina's patch to install.sh. - -6) Allow startup options to be overridden in /etc/sysconfig/shorewall - or /etc/default/shorewall. - -7) Add support for SAME - -8) Add 'shorewall show capabilities' - -8) Add '-v' option - -9) Allow 'none' in /etc/shorewall/rules. - -10) Add error message for invalid HOST(S) column contents. - -11) Apply Christian Rodriguez's patch for Slackware install. - -Changes in 2.2.3 - -1) Added the 'continue' extension script. - -2) Obey 'routestopped' rules during [re]start. - -3) MACLIST_TTL added. - -4) Fix ! in hosts file - -5) Add QUEUE policy. - -6) Fix routing output when advanced routing support not in kernel. - -Changes in 2.2.2 - -1) The 'check' command disclaimer is toned down further and only - appears once in the 'check' output. - -2) Enhanced support in the SOURCE column of /etc/shorewall/tcrules. - -3) All calls to 'clear' are now conditional on the output device being - a terminal. - -4) Apply Juergen Kreileder's patch for logging. - -5) Add the output of 'arp -na' to the 'shorewall status' display. - -6) Provide support for the Extended multiport match available in - 2.6.11. - -7) Fix logging rule generation. - -8) Correct port numbers in action.AllowPCA. - -9) Fix installer's handling of action.* files. - -10) Implement RFC1918_STRICT - -11) Verify interface names in the DEST column of tcrules. - -Changes in 2.2.1 - -1) Add examples to the zones and policy files. - -2) Simon Matter's patch for umask. - -Changes since 2.0.3 - -1) Fix security vulnerability involving temporary files/directories. - -2) Hack security fix so that it works under Slackware. - -3) Correct mktempfile() for case where mktemp isn't installed. - -4) Implement 'dropInvalid' builtin action. - -5) Fix logging nat rules. - -6) Fix COMMAND typos. - -7) Add PKTTYPE option. - -8) Enhancements to /etc/shorewall/masq - -8) Allow overriding ADD_IP_ALIASES=Yes - -9) Fix syntax error in setup_nat() - -10) Port "shorewall status" changes from 2.0.7. - -11) All config files are now empty. - -12) Port blacklisting fix from 2.0.7 - -13) Pass rule chain and display chain separately to log_rule_limit. - Prep work for action logging. - -14) Show the iptables/ip/tc command that failed when failure is fatal. - -15) Implement STARTUP_ENABLED. - -16) Added DNAT ONLY column to /etc/shorewall/nat. - -17) Removed SNAT from ORIGINAL DESTINATION column. - -18) Removed DNAT ONLY column. - -19) Added IPSEC column to /etc/shorewall/masq. - -20) No longer enforce source port 500 for ISAKMP. - -21) Apply policy to interface/host options. - -22) Fix policy and maclist. - -23) Implement additional IPSEC options for zones and masq entries. - -24) Deprecate the -c option in /sbin/shorewall. - -25) Allow distinct input and output IPSEC parameters. - -26) Allow source port remapping in /etc/shorewall/masq. - -27) Include params file on 'restore' - -28) Apply Richard Musil's patch. - -29) Correct parsing of PROTO column in setup_tc1(). - -30) Verify Physdev match if BRIDGING=Yes - -31) Don't NAT tunnel traffic. - -32) Fix shorewall.spec to run chkconfig/insserv after initial install. - -33) Add iprange support. - -34) Add CLASSIFY support. - -35) Fix iprange support so that ranges in both source and destination - work. - -36) Remove logunclean and dropunclean - -37) Fixed proxy arp flag setting for complex configurations. - -38) Added RETAIN_ALIASES option. - -39) Relax OpenVPN source port restrictions. - -40) Implement DELAYBLACKLISTLOAD. - -41) Avoid double-setting proxy arp flags. - -42) Fix DELAYBLACKLISTLOAD=No. - -43) Merge 'brctl show' change from 2.0.9. - -44) Implememt LOGTAGONLY. - -45) Merge 'tcrules' clarification from 2.0.10. - -46) Implement 'sourceroute' interface option. - -47) Add 'AllowICMPs' action. - -48) Changed 'activate_rules' such that traffic from IPSEC hosts gets - handled before traffic from non-IPSEC zones. - -49) Correct logmartians handling. - -50) Add a clarification and fix a typo in the blacklist file. - -51) Allow setting a specify MSS value. - -52) Detect duplicate zone names. - -53) Add mss= option to the ipsec file. - -54) Added CONNMARK/ipp2p support. - -55) Added LOGALLNEW support. - -56) Fix typo in check_config() - -57) Allow outgoing NTP responses in action.AllowNTP. - -58) Clarification of the 'ipsec' hosts file option. - -59) Allow list in the SUBNET column of the rfc1918 file. - -60) Restore missing '#' in the rfc1918 file. - -61) Add note for Slackware users to INSTALL. - -62) Allow interface in DEST tcrules column. - -63) Remove 'ipt_unclean' from search expression in "log" commands. - -64) Remove nonsense from IPSEC description in masq file. - -65) Correct typo in rules file. - -66) Update bogons file. - -67) Add a rule for NNTPS to action.AllowNNTP - -68) Fix "shorewall add" - -69) Change CLIENT PORT(S) to SOURCE PORT(S) in tcrules file. - -70) Correct typo in shorewall.conf. - -71) Add the 'icmp_echo_ignore_all' file to the /proc display. - -72) Apply Tuomas Jormola's IPTABLES patch. - -73) Fixed some bugs in Tuomas's patch. - -74) Correct bug in "shorewall add" - -75) Correct bridge handling in "shorewall add" and "shorewall delete" - -76) Add "shorewall show zones" - -77) Remove dependency of "show zones" on dynamic zones. - -78) Implement variable expansion in INCLUDE directives - -79) More fixes for "shorewall delete" with bridging. - -80) Split restore-base into two files. - -81) Correct OUTPUT handling of dynamic zones. - -83) Add adapter statistics to the output of "shorewall status". - -84) Log drops due to policy rate limiting. - -85) Continue determining capabilities when fooX1234 already exists. - -86) Corrected typo in interfaces file. - -87) Add DROPINVALID option. - -88) Allow list of hosts in add and delete commands. Fix ipsec problem - with "add" and "delete" - -89) Clarify add/delete syntax in /sbin/shorewall usage summary. - -90) Implement OpenVPN TCP support. - -91) Simplify the absurdly over-engineered code that restores the - dynamic chain. - -92) Add OPENVPNPORT option. - -93) Remove OPENVPNPORT option and change default port to 1194. - -94) Avoid shell error during "shorewall stop/clear" - -95) Change encryption to blowfish in 'ipsecvpn' script. - -96) Correct rate limiting rule example. - -97) Fix :: handling in setup_masq(). - -98) Fix mis-leading typo in tunnels. - -99) Fix brain-dead ipsec option handling in setup_masq(). - -100) Reconcile ipsec masq file implementation with the documentation. - -101) Add netfilter module display to status output. - -102) Add 'allowInvalid' builtin action. - -103) Expand range of Traceroute ports. - -102) Correct uninitialized variable in setup_ecn() - -103) Allow DHCP to be IPSEC-encrypted. +1) Implement support for --cmd-owner diff --git a/Shorewall2/firewall b/Shorewall2/firewall index f6b44290d..830fdfcd6 100755 --- a/Shorewall2/firewall +++ b/Shorewall2/firewall @@ -2405,16 +2405,24 @@ process_tc_rule() [ "$chain" != tcout ] && \ fatal_error "Invalid use of a user/group: rule \"$rule\"" + r="$r-m owner" + + case "$user" in + */*) + r="$r --cmd-owner ${user#*/}" + user=${user%/*} + ;; + esac + case "$user" in *:*) - r="$r-m owner" temp="${user%:*}" [ -n "$temp" ] && r="$r --uid-owner $temp " temp="${user#*:}" [ -n "$temp" ] && r="$r --gid-owner $temp " ;; *) - r="$r-m owner --uid-owner $user " + r="$r--uid-owner $user " ;; esac fi @@ -2646,6 +2654,7 @@ process_accounting_rule() { rule= rule2= jumpchain= + user1= accounting_error() { error_message "Warning: Invalid Accounting rule" $action $chain $source $dest $proto $port $sport $user @@ -2670,6 +2679,7 @@ process_accounting_rule() { rule="$rule -j $jumpchain" } + case $source in *:*) accounting_interface_verify ${source%:*} @@ -2735,19 +2745,50 @@ process_accounting_rule() { [ -n "$user" ] && case $user in -|any|all) ;; - *:*) - [ "$chain" != OUTPUT ] && \ - fatal_error "Invalid use of a user/group: chain is not OUTPUT but $chain" - rule="$rule -m owner" - temp="${user%:*}" - [ -n "$temp" ] && rule="$rule --uid-owner $temp " - temp="${user#*:}" - [ -n "$temp" ] && rule="$rule --gid-owner $temp " - ;; *) [ "$chain" != OUTPUT ] && \ fatal_error "Invalid use of a user/group: chain is not OUTPUT but $chain" - rule="$rule -m owner --uid-owner $user " + rule="$rule -m owner" + user1="$user" + + case "$user" in + !*/*) + if [ "$user" != "!/" ]; then + rule="$rule ! --cmd-owner ${user#*/} " + user1=${user%/*} + fi + ;; + */*) + rule="$rule --cmd-owner ${user#*/} " + user1=${user%/*} + ;; + esac + + case "$user1" in + !*:*) + if [ "$user1" != "!:" ]; then + temp="${user1#!}" + temp="${temp%:*}" + [ -n "$temp" ] && rule="$rule ! --uid-owner $temp " + temp="${user1#*:}" + [ -n "$temp" ] && rule="$rule ! --gid-owner $temp " + fi + ;; + *:*) + if [ "$user1" != ":" ]; then + temp="${user1%:*}" + [ -n "$temp" ] && rule="$rule --uid-owner $temp " + temp="${user1#*:}" + [ -n "$temp" ] && rule="$rule --gid-owner $temp " + fi + ;; + !*) + [ "$user1" != "!" ] && rule="$rule ! --uid-owner ${user1#!} " + ;; + *) + [ -n "$user1" ] && rule="$rule --uid-owner $user1 " + ;; + esac ;; esac @@ -3136,10 +3177,26 @@ process_action() # $1 = chain (Chain to add the rules to) [ "x$userspec" = "x-" ] && userspec= if [ -n "$userspec" ]; then + userandgroup="-m owner" + + case "$userspec" in + !*/*) + if [ "$userspec" != "!/" ]; then + userandgroup="$userandgroup ! --cmd-owner ${userspec#*/}" + userspec=${userspec%/*} + fi + ;; + */*) + if [ "$userspec" != "/" ]; then + userandgroup="$userandgroup --cmd-owner ${userspec#*/}" + userspec=${userspec%/*} + fi + ;; + esac + case "$userspec" in !*:*) if [ "$userspec" != "!:" ]; then - userandgroup="-m owner" temp="${userspec#!}" temp="${temp%:*}" [ -n "$temp" ] && userandgroup="$userandgroup ! --uid-owner $temp" @@ -3149,7 +3206,6 @@ process_action() # $1 = chain (Chain to add the rules to) ;; *:*) if [ "$userspec" != ":" ]; then - userandgroup="-m owner" temp="${userspec%:*}" [ -n "$temp" ] && userandgroup="$userandgroup --uid-owner $temp" temp="${userspec#*:}" @@ -3157,12 +3213,14 @@ process_action() # $1 = chain (Chain to add the rules to) fi ;; !*) - userandgroup="-m owner ! --uid-owner ${userspec#!}" + [ "$userspec" != "!" ] && userandgroup="$userandgroup ! --uid-owner ${userspec#!}" ;; *) - userandgroup="-m owner --uid-owner $userspec" + [ -n "$userspec" ] && userandgroup="$userandgroup --uid-owner $userspec" ;; esac + + [ "$userandgroup" = "-m owner" ] && userandgroup= fi # Isolate log level @@ -4105,7 +4163,7 @@ add_a_rule() case "$logtarget" in ACCEPT|DROP|REJECT|CONTINUE) - if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" -a -z "$userspec" ] ; then + if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" -a -z "$userandgroup" ] ; then error_message "Warning -- Rule \"$rule\" is a POLICY" error_message " -- and should be moved to the policy file" fi @@ -4295,10 +4353,27 @@ process_rule() # $1 = target [ "x$address" = "x-" ] && address= if [ -n "$userspec" ]; then + + userandgroup="-m owner" + + case "$userspec" in + !*/*) + if [ "$userspec" != "!/" ]; then + userandgroup="$userandgroup ! --cmd-owner ${userspec#*/}" + userspec=${userspec%/*} + fi + ;; + */*) + if [ "$userspec" != "/" ]; then + userandgroup="$userandgroup --cmd-owner ${userspec#*/}" + userspec=${userspec%/*} + fi + ;; + esac + case "$userspec" in !*:*) if [ "$userspec" != "!:" ]; then - userandgroup="-m owner" temp="${userspec#!}" temp="${temp%:*}" [ -n "$temp" ] && userandgroup="$userandgroup ! --uid-owner $temp" @@ -4308,7 +4383,6 @@ process_rule() # $1 = target ;; *:*) if [ "$userspec" != ":" ]; then - userandgroup="-m owner" temp="${userspec%:*}" [ -n "$temp" ] && userandgroup="$userandgroup --uid-owner $temp" temp="${userspec#*:}" @@ -4316,12 +4390,14 @@ process_rule() # $1 = target fi ;; !*) - userandgroup="-m owner ! --uid-owner ${userspec#!}" + [ "$userspec" != "!" ] && userandgroup="$userandgroup ! --uid-owner ${userspec#!}" ;; *) - userandgroup="-m owner --uid-owner $userspec" + [ -n "$userspec" ] && userandgroup="$userandgroup --uid-owner $userspec" ;; esac + + [ "$userandgroup" = "-m owner" ] && userandgroup= fi case $target in diff --git a/Shorewall2/releasenotes.txt b/Shorewall2/releasenotes.txt index 19dc7e7d1..0ad140042 100755 --- a/Shorewall2/releasenotes.txt +++ b/Shorewall2/releasenotes.txt @@ -1,1029 +1,39 @@ -Shorewall 2.2.4 +Shorewall 2.3.0 ----------------------------------------------------------------------- -Problems corrected in version 2.2.4 +Problems corrected in version 2.3.0 -1) The error message: - - Error: No appropriate chain for zone to zone - - has been changed to one that is more self-explanatory: - - Error: No policy defined for zone to zone - -2) When only an interface name appeared in the HOST(S) column of an - /etc/shorewall/hosts file entry, a misleading iptables error message - resulted. Now the following message is generated: - - Error: Invalid HOST(S) column contents: +None. ----------------------------------------------------------------------- -New Features in version 2.2.4 +New Features in version 2.3.0 -1) Support has been added for UPnP using linux-igd - (http://linux-idg.sourceforge.net). UPnP is required by a number of - popular applications including MSN IM. +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. - WARNING: From a security architecture viewpoint, UPnP is a - disaster. It assumes that: + The syntax of the USER/GROUP column in the following files has been + extended: - a) All local systems and their users are completely - trustworthy. + /etc/shorewall/accounting + /etc/shorewall/rules + /etc/shorewall/tcrules + /usr/share/shorewall/action.template - b) No local system is infected with any worm or trojan. + To specify a command, prefix the command name with "/". - If either of these assumptions are not true then UPnP can - be used to totally defeat your firewall and to allow - incoming connections to arbitrary local systems on any port - whatsoever. + Examples: - In short: USE UPnP AT YOUR OWN RISK. + /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". - WARNING: The linux-igd project appears to be inactive and the web - site does not display correctly on any open source browser - that I've tried. + 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. - Building and installing linux-igd is not for the faint of - heart. You must download the source from CVS and be - prepared to do quite a bit of fiddling with the include - files from libupnp (which is required to build and/or run - linux-igd). - linux-idg Configuration: - - In /etc/upnpd.conf, you will want: - - insert_forward_rules = yes - prerouting_chain_name = UPnP - forward_chain_name = forwardUPnP - - Shorewall Configuration: - - In /etc/shorewall/interfaces, you need the 'upnp' option - on your external interface. - - If your fw->loc policy is not ACCEPT then you need this - rule: - - allowoutUPnP fw loc - - Note: To use 'allowoutUPnP', your iptables and kernel must - support the 'owner match' feature (see the output of - "shorewall check"). - - If your loc->fw policy is not ACCEPT then you need this - rule: - - allowinUPnP loc fw - - You MUST have this rule: - - forwardUPnP net loc - - You must also ensure that you have a route to 224.0.0.0/4 on your - internal (local) interface. - -2) A new 'started' extension script has been added. The difference - between this extension script and /etc/shorewall/start is that this - one is invoked after delayed loading of the blacklist - (DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been - created (thus signaling that the firewall is completely up. - - /etc/shorewall/started should not change the firewall configuration - directly but may do so indirectly by running /sbin/shorewall with - the 'nolock' option. - -3) By default, shorewall is started with the "-f" (fast) option when - your system boots. You can override that setting by setting the - OPTIONS variable in /etc/sysconfig/shorewall (SuSE/Redhat) or - /etc/default/shorewall (Debian/Bering). If neither file exists, feel - free to create one. - - Example: If you want Shorewall to always use the config files even - if there is a saved configuration, then specify: - - OPTIONS="" - -4) Shorewall now has support for the SAME target. This change affects - the /etc/shorewall/masq and /etc/shorewall/rules file. - - SAME is useful when you specify multiple target IP addresses (in the - ADDRESSES column of /etc/shorewall/masq or in the DEST column of - /etc/shorewall/rules). - - If you use normal SNAT then multiple connections from a given local - host to hosts on the internet can be assigned different source IP - addresses. This confuses some applications that use multiple - connections. To correct this problem, prefix the list of address - ranges in the ADDRESS column with "SAME:" - - Example: SAME:206.124.146.176-206.124.146.180 - - If you want each internal system to use the same IP address from the - list regardless of which internet host it is talking to then prefix - the rages with "SAME:nodst:". - - Example: SAME:nodst:206.124.146.176-206.124.146.180 - - Note that it is not possible to map port numbers when using SAME. - - In the rules file, when multiple connections from an internet host - match a SAME rule then all of the connections will be sent to the - same internal server. SAME rules are very similar to DNAT rules with - the keyword SAME replacing DNAT. As in the masq file, changing the - port number is not supported. - -5) A "shorewall show capabilities" command has been added to report the - capabilities of your kernel and iptables. - - Example: - - gateway:~# shorewall show capabilities - Loading /usr/share/shorewall/functions... - Processing /etc/shorewall/params ... - Processing /etc/shorewall/shorewall.conf... - Loading Modules... - Shorewall has detected the following iptables/netfilter capabilities: - NAT: Available - Packet Mangling: Available - Multi-port Match: Available - Extended Multi-port Match: Available - Connection Tracking Match: Available - Packet Type Match: Not available - Policy Match: Available - Physdev Match: Available - IP range Match: Available - Recent Match: Available - Owner Match: Available - gateway:~# - -6) A "-v" option has been added to /sbin/shorewall. Currently, this - option only affects the "show log" command (e.g., "shorewall -v show - log") and the "monitor" command. In these commands, it causes the - MAC address in the log message (if any) to be displayed. As - previously, when "-v" is omitted, the MAC address is suppressed. - -7) In /etc/shorewall/rules, a value of 'none' in either the SOURCE or - DEST columns now causes the rule to be ignored. This is most useful - when used with shell variables: - - Example: - - /etc/shorewall/rules: - - AllowFTP $FTP_CLIENTS fw - - When FTP_CLIENTS is set to 'none', the above rule is ignored. - Otherwise, the rule is evaluated and generates Netfilter rules. - -8) The installer now detects that it is running on a Slackware system - and adjusts the DEST and INIT variables accordingly. - ------------------------------------------------------------------------ -Problems corrected in version 2.2.3 - -1) If a zone is defined in /etc/shorewall/hosts using - :! in the HOSTS column then startup errors occur - on "shorewall [re]start". - -2) Previously, if "shorewall status" was run on a system whose kernel - lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER), then - no routing information was displayed. - ------------------------------------------------------------------------ -New Features in version 2.2.3 - -1) A new extension script "continue" has been added. This script is - invoked after Shorewall has set the built-in filter chains' - policy to DROP, deleted any existing Netfilter rules and user - chains and has enabled existing connections. - - It is useful for enabling certain communication while Shorewall is - being [re]started. Be sure to delete any rules that you add here in - your /etc/shorewall/start file. - -2) There has been ongoing confusion about how the - /etc/shorewall/routestopped file works. People understand how it - works with the 'shorewall stop' command but when they read that - 'shorewall restart' is logically equivalent to 'shorewall stop' - followed by 'shorewall start' then they erroneously conclude that - /etc/shorewall/routestopped can be used to enable new connections - during 'shorewall restart'. Up to now, it cannot -- that file is not - processed during either 'shorewall start' or 'shorewall restart'. - - Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped - will be processed TWICE during 'shorewall start' and during - 'shorewall restart'. It will be processed early in the command - execution to add rules allowing new connections while the command - is running and it will be processed again when the - command is complete to remove the rules added earlier. - - The result of this change will be that during most of [re]start, new - connections will be allowed in accordance with the contents of - /etc/shorewall/routestopped. - -3) The performance of configurations with a large numbers of entries in - /etc/shorewall/maclist can be improved by setting the new - MACLIST_TTL variable in /etc/shorewall/shorewall.conf. - - If your iptables and kernel support the "Recent Match" (see the - output of "shorewall check" near the top), you can cache the results - of a 'maclist' file lookup and thus reduce the overhead associated - with MAC Verification. - - When a new connection arrives from a 'maclist' interface, the packet - passes through then 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 from an IP address, 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. - -4) You can now specify QUEUE as a policy and you can designate a - common action for QUEUE policies in /etc/shorewall/actions. This is - useful for sending packets to something like Snort Inline. - ------------------------------------------------------------------------ -Problems corrected in version 2.2.2 - -1) The SOURCE column in the /etc/shorewall/tcrules file now allows IP - ranges (assuming that your iptables and kernel support ranges). - -2) If A is a user-defined action and you have file /etc/shorewall/A - then when that file is invoked, the $TAG value may be incorrect. - -3) Previously, if an iptables command generating a logging rule - failed, the Shorewall [re]start was still successful. This error - is now considered fatal and Shorewall will be either restored from - the last save (if any) or it will be stopped. - -4) The port numbers for UDP and TCP were previously reversed in the - /usr/share/shorewall/action.AllowPCA file. - -5) Previously, the 'install.sh' script did not update the - /usr/share/shorewall/action.* files. - -6) Previously, when an interface name appeared in the DEST column of - /etc/shorewall/tcrules, the name was not validated against the set - of defined interfaces and bridge ports. - ------------------------------------------------------------------------ -New Features in version 2.2.2 - -1) The SOURCE column in the /etc/shorewall/tcrules file now allows $FW - to be optionally followed by ":" and a host/network address or - address range. - -2) Shorewall now clears the output device only if it is a - terminal. This avoids ugly control sequences being placed in files - when /sbin/shorewall output is redirected. - -3) The output from 'arp -na' has been added to the 'shorewall status' - display. - -4) The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges - to appear in port lists handled by "multiport match". If Shorewall - detects this capability, it will use "multiport match" for port - lists containing port ranges. Be cautioned that each port range - counts for TWO ports and a port list handled with "multiport match" - can still specify a maximum of 15 ports. - - As always, if a port list in /etc/shorewall/rules is incompatible - with "multiport match", a separate iptables rule will be generated - for each element in the list. - -5) 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 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. - - 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 'Connection Tracking' match. ------------------------------------------------------------------------ -Problems corrected in version 2.2.1 - -1) The /etc/shorewall/policy file contained a misleading comment and - both that file and the /etc/shorewall/zones file lacked examples. - -2) Shorewall previously used root's default umask which could cause - files in /var/lib/shorewall to be world-readable. Shorewall now uses - umask 0177. - -3) In log messages produced by logging a built-in action, the packet - disposition was displayed incorrectly. - - Example: - - rejNotSyn:ULOG all all tcp - - produces the log message: - - Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ... - - rather than - - Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ... - -3) The comments regarding built-in actions in - /usr/share/shorewall/actions.std have been corrected. - -4) The /etc/shorewall/policy file in the LRP package was missing the - 'all->all' policy. - ------------------------------------------------------------------------ -Issues when migrating from Shorewall 2.0 to Shorewall 2.2: - -1) Shorewall configuration files except shorewall.conf are now empty - (they contain only comments). If you wish to retain the defaults - in any of the following files, you should copy these files before - upgrading them then restore them after the upgrade: - - /etc/shorewall/zones - /etc/shorewall/policy - /etc/shorewall/tos - -2) The following builtin actions have been removed and have been - replaced by the new action logging implementation described in the - new features below. - - logNotSyn - rLogNotSyn - dLogNotSyn - -3) If shorewall.conf is upgraded to the latest version, it needs to be - modified to set STARTUP_ENABLED=Yes - -4) The Leaf/Bering version of Shorewall was previously named: - - shorwall-.lrp - - Beginning with 2.2, that file will now be named: - - shorewall-lrp-.tgz - - Simply rename that file to 'shorwall.lrp' when installing it on your - LEAF/Bering system. - -5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no - longer contain a second (SNAT) address. You must use an entry in - /etc/shorewall/masq instead. - - Example from Shorewall FAQ #1: - - Prior to Shorewall 2.2: - - /etc/shorewall/interfaces - - loc eth1 detect routeback,... - - /etc/shorewall/rules - - DNAT loc loc:192.168.1.12 tcp 80 \ - - 130.252.100.69:192.168.1.254 - - Shorewall 2.2 and Later: - - /etc/shorewall/interfaces - - loc eth1 detect routeback,... - - /etc/shorewall/masq: - - eth1 eth1 192.168.1.254 tcp 80 - - - /etc/shorewall/rules: - - DNAT loc loc:192.168.1.12 tcp 80 \ - - 130.252.100.69 - -6) The 'logunclean' and 'dropunclean' options that were deprecated in - Shorewall 2.0 have now been removed completely. - -7) A new IPTABLES variable has been added to shorewall.conf. This - variable names the iptables executable that Shorewall will use. The - variable is set to "/sbin/iptables". If you use the new - shorewall.conf, you may need to change this setting to maintain - compabibility with your current setup (if you use your existing - shorewall.conf that does not set IPTABLES then you should - experience no change in behavior). - -8) The default port for OpenVPN tunnels has been changed from 5000 to - 1194 to reflect the recent IANA allocation of that port for - OpenVPN. - ------------------------------------------------------------------------ -New Features in Shorewall 2.2.0: - -1) ICMP packets that are in the INVALID state are now dropped by the - Reject and Drop default actions. They do so using the new - 'dropInvalid' builtin action. An 'allowInvalid' builtin action is - also provided which accepts packets in that state. - -2) The /etc/shorewall/masq file INTERFACE column now allows additional - options. - - Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT - rules defined in the /etc/shorewall/nat file. If you preceed the - interface name with a plus sign ("+") then the rule will be - evaluated before one-to-one NAT. - - Examples: - - +eth0 - +eth1:192.0.2.32/27 - - Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an - entry by following the interface name by ":" but no digit. - - Examples: - - eth0: - eth1::192.0.2.32/27 - +eth3: - -3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows - you to override the setting of ADD_IP_ALIASES=Yes by following the - interface name with ":" but no digit. - -4) All configuration files in the Shorewall distribution with the - exception of shorewall.conf are now empty. In particular, the - /etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos - files now have no active entries. Hopefully this will stop the - questions on the support and development lists regarding why the - default entries are the way they are. - -5) Previously, including a log level (and optionally a log tag) on a - rule that specified a user-defined (or Shorewall-defined) action - would log all traffic passed to the action. Beginning with this - release, specifying a log level in a rule that specifies a user- - or Shorewall-defined action will cause each rule in the action to - be logged with the specified level (and tag). - - The extent to which logging of action rules occurs is goverend by - the following: - - a) When you invoke an action and specify a log level, only those - rules in the action that have no log level will be changed to log - at the level specified at the action invocation. - - Example: - - /etc/shorewall/action.foo: - - ACCEPT - - tcp 22 - bar:info - - /etc/shorewall/rules: - - foo:debug fw net - - Logging in the invoked 'foo' action will be: - - ACCEPT:debug - - tcp 22 - bar:info - - b) If you follow the log level with "!" then logging will - be at that level for all rules recursively invoked by the action - - Example: - - /etc/shorewall/action.foo: - - ACCEPT - - tcp 22 - bar:info - - /etc/shorewall/rules: - - foo:debug! fw net - - Logging in the invoke 'foo' action will be: - - ACCEPT:debug - - tcp 22 - bar:debug! - - This change has an effect on extension scripts used with - user-defined actions. If you define an action 'acton' and you have - an /etc/shorewall/acton script then when that script is invoked, - the following three variables will be set for use by the script: - - $CHAIN = the name of the chain where your rules are to be - placed. When logging is used on an action invocation, - Shorewall creates a chain with a slightly different name from - the action itself. - - $LEVEL = Log level. If empty, no logging was specified. - - $TAG = Log Tag. - - Example: - - /etc/shorewall/rules: - - acton:info:test - - Your /etc/shorewall/acton file will be run with: - - $CHAIN="%acton1" - $LEVEL="info" - $TAG="test" - -6) The /etc/shorewall/startup_disabled file is no longer created when - Shorewall is first installed. Rather, the variable STARTUP_ENABLED - is set to 'No' in /etc/shorewall/shorewall.conf. In order to get - Shorewall to start, that variable's value must be set to - 'Yes'. This change accomplishes two things: - - a) It prevents Shorewall from being started prematurely by the - user's initialization scripts. - - b) It causes /etc/shorewall/shorewall.conf to be modified so that - it won't be replaced by upgrades using RPM. - -7) Some additional support has been added for the 2.6 Kernel IPSEC - implementation. To use this support, you must have installed the - IPSEC policy match patch and the four IPSEC/Netfilter patches - from Patch-0-Matic-ng. The policy match patch affects both your - kernel and iptables. - - There are two ways to specify that IPSEC is to be used when - communicating with a set of hosts; both methods involve the new - /etc/shorewall/ipsec file: - - a) If encrypted communication is used with all hosts in a zone, - then you can designate the zone as an "ipsec" zone by placing - 'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec: - - #ZONE IPSEC OPTIONS ... - # ONLY - vpn Yes - - The hosts in the zone (if any) must be specified in - /etc/shorewall/hosts but you do not need to specify the 'ipsec' - option on the entries in that file (see below). - - Dynamic zones involving IPSEC must use that technique. - - Example: - - Under 2.4 Kernel FreeS/Wan: - - /etc/shorewall/zones: - - net Net The big bad Internet - vpn VPN Remote Network - - /etc/shorewall/interfaces: - - net eth0 ... - vpn ipsec0 ... - - Under 2.6 Kernel with this new support: - - /etc/shorewall/zones: - - net Net The big bad Internet - vpn VPN Remote Network - - /etc/shorewall/interfaces: - - net eth0 ... - - /etc/shorewall/hosts: - - vpn eth0:0.0.0.0/0 - - /etc/shorewall/ipsec - - vpn Yes - - b) If only part of the hosts in a zone require encrypted - communication, you may use of the new 'ipsec' option in - /etc/shorewall/hosts to designate those hosts. - - Example: - - Under 2.4 Kernel FreeS/Wan: - - /etc/shorewall/zones: - - net Net The big bad Internet - loc Local Extended local zone - - /etc/shorewall/interfaces: - - net eth0 ... - loc eth1 ... - loc ipsec0 ... - - Under 2.6 Kernel with this new support: - - /etc/shorewall/zones: - - net Net The big bad Internet - vpn VPN Remote Network - - /etc/shorewall/interfaces: - - net eth0 ... - loc eth1 ... - - /etc/shorewall/hosts: - - vpn eth0:0.0.0.0/0 ipsec,... - - Regardless of which technique you choose, you can specify - additional SA options for the zone in the /etc/shorewall/ipsec - entry. - - The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the - input-output, input and output characteristics of the security - associations to be used to decrypt (input) or encrypt (output) traffic - to/from the zone. - - The available options are: - - reqid[!]= where is specified using setkey(8) using - the 'unique:' option for the SPD level. - - spi[!]= where is the SPI of the SA. Since - different SAs are used to encrypt and decrypt traffic, this - option should only be listed in the IN OPTIONS and OUT OPTIONS - columns. - - proto[!]=ah|esp|ipcomp - - mss= (sets the MSS value in TCP SYN packets and is not - related to policy matching) - - mode[!]=transport|tunnel - - tunnel-src[!]=
[/] (only available with mode=tunnel) - - tunnel-dst[!]=
[/] (only available with - mode=tunnel). Because tunnel source and destination are - dependent on the direction of the traffic, these options - should only appear in the IN OPTIONS and OUT OPTIONS columns. - - strict (if specified, packets must match all policies; - policies are delimited by 'next'). - - next (only available with strict) - - Examples: - - #ZONE IPSEC OPTIONS IN OUT... - # ONLY OPTIONS OPTIONS - vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001 - loc No reqid=44,mode=transport - - The /etc/shorewall/masq file has a new IPSEC column added. If you - specify Yes or yes in that column then the unencrypted packets will - have their source address changed. Otherwise, the unencrypted - packets will not have their source addresses changed. This column - may also contain a comma-separated list of the options specified - above in which case only those packets that will be encrypted - by an SA matching the given options will have their source address - changed. - -8) To improve interoperability, tunnels of type 'ipsec' no longer - enforce the use of source port 500 for ISAKMP and OpenVPN - tunnels no longer enforce use of the specified port as both the - source and destination ports. - -9) A new 'allowBcast' builtin action has been added -- it silently - allows broadcasts and multicasts. - -10) The -c option in /sbin/shorewall commands is now deprecated. The - commands where -c was previously allowed now permit you to specify - a configuration directory after the command: - - shorewall check [ ] - shorewall restart [ ] - shorewall start [ ] - -11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp - connection, Netfilter attempts to retain the source port - number. If it has to change to port number to avoid - , conflicts, it tries to do so - within port ranges ( < 512, 512-1023, and > 1023). You may - now specify an explicit range of source ports to be used - by following the address or address range (if any) in the - ADDRESS column with ":" and a port range in the format - -. You must specify either "tcp" or - "udp" in the PROTO column. - - Examples 1 -- MASQUERADE with tcp source ports 4000-5000: - - #INTERFACE SUBNET ADDRESS PROTO - eth0 192.168.1.0/24 :4000-5000 tcp - - Example 2 -- SNAT with udp source ports 7000-8000: - - #INTERFACE SUBNET ADDRESS PROTO - eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp - -12) You may now account by user/group ID for outbound traffic from the - firewall itself with entries in /etc/shorewall/accounting. Such - accounting rules must be placed in the OUTPUT chain. - - See the comments at the top of /etc/shorewall/accounting for - details. - -13) Shorewall now verifies that your kernel and iptables have physdev - match support if BRIDGING=Yes in shorewall.conf. - -14) Beginning with this release, if your kernel and iptables have - iprange match support (see the output from "shorewall check"), then - with the exception of the /etc/shorewall/netmap file, anywhere that - a network address may appear an IP address range of the form - may also appear. - -15) Support has been added for the iptables CLASSIFY target. That - target allows you to classify packets for traffic shaping directly - rather than indirectly through fwmark. Simply enter the - : classification in the first column of - /etc/shorewall/tcrules: - - Example: - - #MARK/ SOURCE DEST PROTO PORT(S) - #CLASSIFY - 1:30 - eth0 tcp 25 - - Note that when using this form of rule, it is acceptable to include - the name of an interface in the DEST column. - - Marking using the CLASSIFY target always occurs in the POSTROUTING - chain of the mangle table and is not affected by the setting of - MARK_IN_FORWARD_CHAIN in shorewall.conf. - -16) During "shorewall start", IP addresses to be added as a consequence - of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted - when /etc/shorewall/nat and /etc/shorewall/masq are processed then - the are re-added later. This is done to help ensure that the - addresses can be added with the specified labels but can have - the undesirable side effect of causing routes to be quietly - deleted. A new RETAIN_ALIASES option has been added to - shorewall.conf; when this option is set to Yes, existing addresses - will not be deleted. Regardless of the setting of RETAIN_ALIASES, - addresses added during "shorewall start" are still deleted at a - subsequent "shorewall stop" or "shorewall restart". - -17) Users with a large black list (from /etc/shorewall/blacklist) may - want to set the new DELAYBLACKLISTLOAD option in - shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will - enable new connections before loading the blacklist rules. While - this may allow connections from blacklisted hosts to slip by during - construction of the blacklist, it can substantially reduce the time - that all new connections are disabled during "shorewall [re]start". - -18) Using the default LOGFORMAT, chain names longer than 11 characters - (such as in user-defined actions) may result in log prefix - truncation. A new shorewall.conf action LOGTAGONLY has been added - to deal with this problem. When LOGTAGONLY=Yes, logging rules that - specify a log tag will substitute the tag for the chain name in the - log prefix. - - Example -- file /etc/shorewall/action.thisisaverylogactionname: - - Rule: - - DROP:info:ftp 0.0.0.0/0 0.0.0.0/0 tcp 21 - - Log prefix with LOGTAGONLY=No: - - Shorewall:thisisaverylongacti - - Log prefix with LOGTAGONLY=Yes: - - Shorewall:ftp:DROP - -19) Shorewall now resets the 'accept_source_route' flag for all - interfaces. If you wish to accept source routing on an interface, - you must specify the new 'sourceroute' interface option in - /etc/shorewall/interfaces. - -20) The default Drop and Reject actions now invoke the new standard - action 'AllowICMPs'. This new action accepts critical ICMP types: - - Type 3 code 4 (fragmentation needed) - Type 11 (TTL exceeded) - -21) Explicit control over the kernel's Martian logging is now provided - using the new 'logmartians' interface option. If you include - 'logmartians' in the interface option list then logging of Martian - packets on will be enabled on the specified interface. - If you wish to globally enable martian logging, you can set - LOG_MARTIANS=Yes in shorewall.conf. - -22) You may now cause Shorewall to use the '--set-mss' option of the - TCPMSS target. In other words, you can cause Shorewall to set the - MSS field of SYN packets passing through the firewall to the value - you specify. This feature extends the existing CLAMPMSS option in - /etc/shorewall/shorewall.conf by allowing that option to have a - numeric value as well as the values "Yes" and "No". - - Example: - - CLAMPMSS=1400 - -23) Shorewall now includes support for the ipp2p match facility. This - is a departure from my usual policy in that the ipp2p match - facility is included in Patch-O-Matic-NG and is unlikely to ever be - included in the kernel.org source tree. Questions about how to - install the patch or how to build your kernel and/or iptables - should not be posted on the Shorewall mailing lists. - - In the following files, the "PROTO" or "PROTOCOL" column may - contain "ipp2p": - - /etc/shorewall/rules - /etc/shorewall/tcrules - /etc/shorewall/accounting - - When the PROTO or PROTOCOL column contains "ipp2p" then the DEST - PORT(S) or PORT(S) column may contain a recognized ipp2p option; - for a list of the options and their meaning, at a root prompt: - - iptables -m ipp2p --help - - You must not include the leading "--" on the option; Shorewall will - supply those characters for you. If you do not include an option - then "ipp2p" is assumed (Shorewall will generate "-m ipp2p - --ipp2p"). - -24) Shorewall now has support for the CONNMARK target from iptables. - See the /etc/shorewall/tcrules file for details. - -25) A new debugging option LOGALLNEW has been added to - shorewall.conf. When set to a log level, this option causes - Shorewall to generaate a logging rule as the first rule in each - builtin chain. - - - The table name is used as the chain name in the log prefix. - - The chain name is used as the target in the log prefix. - - Example: Using the default LOGFORMAT, the log prefix for logging - from the nat table's PREROUTING chain is: - - Shorewall:nat:PREROUTING - - IMPORTANT: There is no rate limiting on these logging rules so - use LOGALLNEW at your own risk; it may cause high CPU and disk - utilization and you may not be able to control your firewall after - you enable this option. - - DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL - BE SENT TO ANOTHER SYSTEM. - -26) The SUBNET column in /etc/shorewall/rfc1918 has been renamed - SUBNETS and it is now possible to specify a list of addresses in - that column. - -27) The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS). - -28) For consistency, the CLIENT PORT(S) column in the tcrules file has - been renamed SOURCE PORT(S). - -29) The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown - in the output of "shorewall status". - -30) A new IPTABLES option has been added to shorewall.conf. IPTABLES - can be used to designate the iptables executable to be used by - Shorewall. If not specified, the iptables executable determined by - the PATH setting is used. - -31) You can now use the "shorewall show zones" command to display the - current contents of the zones. This is particularly useful if you - use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf). - - Example: - - ursa:/etc/shorewall # shorewall show zones - Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004 - - loc - eth0:192.168.1.0/24 - eth1:1.2.3.4 - net - eth0:0.0.0.0/0 - WiFi - eth1:0.0.0.0/0 - sec - eth1:0.0.0.0/0 - - ursa:/etc/shorewall # - -32) Variable expansion may now be used with the INCLUDE directive. - - Example: - - /etc/shorewall/params - - FILE=/etc/foo/bar - - Any other config file: - - INCLUDE $FILE - -33) The output of "shorewall status" now includes the results of "ip - -stat link ls". This helps diagnose performance problems caused by - link errors. - -34) Previously, when rate-limiting was specified in - /etc/shorewall/policy (LIMIT:BURST column), any traffic which - exceeded the specified rate was silently dropped. Now, if a log - level is given in the entry (LEVEL column) then drops are logged at - that level at a rate of 5/min with a burst of 5. - -35) Recent 2.6 kernels include code that evaluates TCP packets based on - TCP Window analysis. This can cause packets that were previously - classified as NEW or ESTABLISHED to be classified as INVALID. - - The new kernel code can be disabled by including this command in - your /etc/shorewall/init file: - - echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal - - Additional kernel logging about INVALID TCP packets may be - obtained by adding this command to /etc/shorewall/init: - - echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid - - Traditionally, Shorewall has dropped INVALID TCP packets early. The - new DROPINVALID option allows INVALID packets to be passed through - the normal rules chains by setting DROPINVALID=No. - - If not specified or if specified as empty (e.g., DROPINVALID="") - then DROPINVALID=Yes is assumed. - -36) The "shorewall add" and "shorewall delete" commands now accept a - list of hosts to add or delete. - - Examples: - - shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12 - shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12 - - The above commands may also be written: - - shorewall add eth1:1.2.3.4,2.3.4.5 z12 - shorewall delete eth1:1.2.3.4,2.3.4.5 z12 - -37) TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel - type. OpenVPN entries in /etc/shorewall/tunnels have this format: - - openvpn[:{tcp|udp}][:] - - Examples: - - openvpn:tcp net 1.2.3.4 # TCP tunnel on port 1194 - openvpn:3344 net 1.2.3.4 # UDP on port 3344 - openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455 - -38) A new 'ipsecvpn' script is included in the tarball and in the - RPM. The RPM installs the file in the Documentation directory - (/usr/share/doc/packages/shorewall-2.2.0-0RC1). - - This script is intended for use on Roadwarrior laptops for - establishing an IPSEC SA to/from remote networks. The script has - some limitations: - - - Only one instance of the script may be used at a time. - - Only the first SPD accessed will be instantiated at the remote - gateway. So while the script creates SPDs to/from the remote - gateway and each network listed in the NETWORKS setting at the - front of the script, only one of these may be used at a time. - -39) The IANA has recently registered port 1194 for use by OpenVPN. In - previous versions of Shorewall (and OpenVPN), the default port was - 5000 but has been changed to 1194 to conform to the new OpenVPN - default. - -40) The output of "shorewall status" now lists the loaded netfilter - kernel modules. - -41) The range of UDP ports opened by the AllowTrcrt action has been - increased to 33434:33524. diff --git a/Shorewall2/rules b/Shorewall2/rules index 79cccc9d6..73d675de6 100755 --- a/Shorewall2/rules +++ b/Shorewall2/rules @@ -285,7 +285,7 @@ # # The column may contain: # -# [!][][:] +# [!][][:][/] # # When this column is non-empty, the rule applies only # if the program generating the output is running under @@ -299,6 +299,7 @@ # #the 'kids' group # !:kids #program must not be run by a member # #of the 'kids' group +# /upnpd #program named 'upnpd' # # Example: Accept SMTP requests from the DMZ to the internet #