From 4305dd4b2b929f2ceb82d9521bf2b8f29082072d Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 3 May 2005 01:18:53 +0000 Subject: [PATCH] Shorewall 2.2.4 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2076 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/News.htm | 394 +++++++++++++++++- Shorewall-Website/Shorewall_index_frame.htm | 38 +- Shorewall-Website/Shorewall_sfindex_frame.htm | 4 + Shorewall-Website/shorewall_index.htm | 192 +-------- 4 files changed, 422 insertions(+), 206 deletions(-) diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index 2983efc12..b848f0394 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -6,7 +6,8 @@ Shorewall News -

Shorewall News Archive

+

Shorewall News and Announcements
+

Tom Eastep

Copyright © 2001-2005 Thomas M. Eastep
@@ -18,11 +19,398 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2005-04-14
+

2005-05-02


-02/15/2005 +05/02/2005 Shorewall 2.2.4
+

+

Problems Corrected:
+

+
    +
  1. The error message:
    +
    +       Error: No appropriate chain for +zone <z1> to zone <z2>
    +
    +has been changed to one that is more self-explanatory:
    +
    +       Error: No policy defined for zone +<z1> to zone <z2>
    2. +
  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: <column contents>
    3. +
+New Features:
+
    +
  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.
    2. +
+
WARNING:
+
From a security architecture viewpoint, +UPnP is a disaster. It assumes that:
+
    +
  1. All local systems and their users are completely trustworthy.
    2. +
  2. No local system is infected with any worm or trojan.
    3. +
+
+
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.
+In short: USE UPnP AT YOUR OWN RISK.
+
+

+
+
+
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.
+
+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).
+
+
+
+
Configuring linux-igd:
+
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 you internal (local) interface.
+
+
    +
  1. 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.
    +
    +
    2. +
  2. 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 or the other.
    +
    +Example: If you want Shorewall to always use the config files even if +there is a saved configuration, then specify:
    +
    +      OPTIONS=""
    +
    +
    3. +
  3. 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 +ranges 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.
    +
    +
    4. +
  4. 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:~#
    +
    +
    5. +
  5. 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.
    +
    +
    6. +
  6. 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.
    +
    +
    7. +
  7. The installer now detects that it is running on a Slackware +system and adjusts the DEST and INIT variables accordingly.
    +
    8. +
+

05/01/2005 Tom +spoke at LinuxFest NW 2005 -- Bellingham Technical College, +Bellingham Washington
+
+Tom's presentation was entitled "Shorewall and Native IPSEC" and is +available for download here +(PDF Format). +
+
+04/07/2005 +Shorewall 2.2.3
+
+Problems Corrected:
+

+
    +
  1. If a zone is defined in /etc/shorewall/hosts using +<interface>:!<network> in the HOSTS column then startup +errors occur on "shorewall [re]start".
    2. +
  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.
    3. +
+New Features:
+
    +
  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. +
  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. +
  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. +
  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.
    +
    5. +
+03/31/2005 +Shorewall 2.0.17
+
+Problems Corrected:
+
    +
  1. Invoking the 'rejNotSyn' action results in an error at startup.
    2. +
  2. The UDP and TCP port numbers in +/usr/share/shorewall/action.AllowPCA were reversed.
    3. +
  3. If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column +then startup errors occur on "shorewall [re]start".
    +
    4. +
+03/12/2005 +Shorewall 2.2.2
+
+Problems Corrected:
+
    +
  1. The SOURCE column in the /etc/shorewall/tcrules file now +correctly allows IP ranges (assuming that your iptables and kernel +support ranges).
    +
    2. +
  2. If A is a user-defined action and you have file /etc/shorewall/A +then when that file is invoked by Shorewall during [re]start, the $TAG +value may be incorrect.
    3. +
  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. +
  4. The port numbers for UDP and TCP were previously reversed in the +/usr/share/shorewall/action.AllowPCA file.
    5. +
  5. Previously, the 'install.sh' script did not update the +/usr/share/shorewall/action.* files.
    6. +
  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.
    +
    7. +
+New Features:
+
    +
  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. +
  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. +
  3. The output from 'arp -na' has been added to the 'shorewall +status' display.
    4. +
  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. +
  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.
    +
    6. +
+ +

02/15/2005 Shorewall 2.2.1

This release rolls up the fixes for bugs found in the first 2-3 diff --git a/Shorewall-Website/Shorewall_index_frame.htm b/Shorewall-Website/Shorewall_index_frame.htm index 9136d8d99..b0ff0c0bb 100644 --- a/Shorewall-Website/Shorewall_index_frame.htm +++ b/Shorewall-Website/Shorewall_index_frame.htm @@ -9,9 +9,11 @@ Home
-Introduction
+ color="#ffffff">Home
+News +and Announcements
+Introduction
Download
Troubleshooting
Support (Read this before -asking for help)
+ style="font-weight: bold;">Getting Help

About the Author
@@ -39,12 +40,10 @@ Repository
color="#ffffff">
Features
-LinuxFest NW 2005 Presentation
+LinuxFest NW 2005 +Presentation
Mirrors
-News Archive
+ color="#ffffff">
Quotes from Users
Requirements
color="#ffffff">
What it Cannot Do - +

color="#ffffff">Copyright © + color="#ffffff">Copyright © 2001-2004
Thomas M. Eastep.
-

+


color="#ffffff">(Protected by Shorewall)
+ src="images/ProtectedBy.png" alt="(Protected by Shorewall)">


color="#ffffff">Please report errors  on this site + color="#ffffff">Please report errors  on this site to the Webmaster.
-

+

diff --git a/Shorewall-Website/Shorewall_sfindex_frame.htm b/Shorewall-Website/Shorewall_sfindex_frame.htm index 588c181e6..ec7850fdc 100644 --- a/Shorewall-Website/Shorewall_sfindex_frame.htm +++ b/Shorewall-Website/Shorewall_sfindex_frame.htm @@ -10,6 +10,8 @@ alink="#0000ee" link="#0000ee" vlink="#551a8b"> Home
+News +and Announcements
Introduction
Download
color="#ffffff">
Features
+LinuxFest NW 2005 +Presentation
Mirrors
News Archive -

Shorewall 2.x

+

Shorewall 2.x

Tom Eastep

The information on this site applies only @@ -28,12 +28,12 @@ to 2.x releases of Shorewall. For older versions:

target="_top">here.

-

The current 2.2 Stable Release is 2.2.3 -- Here are the release +

The current 2.2 Stable Release is 2.2.4 -- Here are the release notes and here are the known + href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.4/known_problems.txt">known problems and updates.
+ href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.4/errata/">updates.

GNU Free Documentation License”.

-

2005-05-01

+

2005-05-02

Table of Contents

Introduction @@ -61,17 +61,7 @@ Shorewall
Looking for Information?
Running Shorewall on Mandrake® with a two-interface setup?
-License

-

News

-

Tom -spoke at LinuxFest NW 2005
-Shorewall -2.2.3
-Shorewall -2.0.17
-Shorewall -2.2.2
+License


Leaf
@@ -180,174 +170,6 @@ Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

-

News

-05/01/2005 Tom -spoke at LinuxFest NW 2005 -- Bellingham Technical College, -Bellingham Washington
-
-Tom's presentation was entitled "Shorewall and Native IPSEC" and is -available for download here (PDF Format). -
-
-04/07/2005 -Shorewall 2.2.3
-
-Problems Corrected:
-
    -
  1. If a zone is defined in /etc/shorewall/hosts using -<interface>:!<network> in the HOSTS column then startup -errors occur on "shorewall [re]start".
    2. -
  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.
    3. -
-New Features:
-
    -
  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. -
  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. -
  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. -
  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.
    -
    5. -
-03/31/2005 -Shorewall 2.0.17
-
-Problems Corrected:
-
    -
  1. Invoking the 'rejNotSyn' action results in an error at startup.
    2. -
  2. The UDP and TCP port numbers in -/usr/share/shorewall/action.AllowPCA were reversed.
    3. -
  3. If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column -then startup errors occur on "shorewall [re]start".
    -
    4. -
-03/12/2005 -Shorewall 2.2.2
-
-Problems Corrected:
-
    -
  1. The SOURCE column in the /etc/shorewall/tcrules file now -correctly allows IP ranges (assuming that your iptables and kernel -support ranges).
    -
    2. -
  2. If A is a user-defined action and you have file /etc/shorewall/A -then when that file is invoked by Shorewall during [re]start, the $TAG -value may be incorrect.
    3. -
  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. -
  4. The port numbers for UDP and TCP were previously reversed in the -/usr/share/shorewall/action.AllowPCA file.
    5. -
  5. Previously, the 'install.sh' script did not update the -/usr/share/shorewall/action.* files.
    6. -
  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.
    -
    7. -
-New Features:
-
    -
  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. -
  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. -
  3. The output from 'arp -na' has been added to the 'shorewall -status' display.
    4. -
  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. -
  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.
    -
    6. -
- -

More News

-

Leaf