From 0bfeb860a9e134f79fd14418e725475de8980046 Mon Sep 17 00:00:00 2001 From: teastep Date: Sun, 1 May 2005 17:02:37 +0000 Subject: [PATCH] Web site udates git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2067 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/News.htm | 766 ++++++++++++++- Shorewall-Website/Shorewall_index_frame.htm | 5 +- Shorewall-Website/Shorewall_sfindex_frame.htm | 7 +- Shorewall-Website/download.htm | 7 +- Shorewall-Website/index.htm | 6 +- Shorewall-Website/shorewall_index.htm | 914 +++--------------- Shorewall-Website/useful_links.html | 4 +- 7 files changed, 910 insertions(+), 799 deletions(-) diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index ca8ceef97..2983efc12 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -18,11 +18,773 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2005-02-01
+

2005-04-14


-01/17/2005 - +02/15/2005 +Shorewall 2.2.1
+
+This release rolls up the fixes for bugs found in the first 2-3 +weeks of deployment of Shorewall 2.2.
+

+
    +
  1. The /etc/shorewall/policy file contained a misleading comment and +both that file and the /etc/shorewall/zones file lacked examples.
    2. +
  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. +
  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: ...
    +
    +
    4. +
  4. The comments regarding built-in actions in +/usr/share/shorewall/actions.std have been corrected.
    5. +
  5. The /etc/shorewall/policy file in the LRP package was missing the +'all->all' policy.
    +
    6. +
+02/05/2005 +End of Support for Shorewall 1.4
+
+Effective today, support for Shorewall 1.4 has been +discontinued. See the link at the top of this article for  upgrade +information.
+
+02/01/2005 +Shorewall 2.0.16
+
+This release back-ports the DROPINVALID shorewall.conf option from +2.2.0.
+
    +
  1. 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.
    2. +
+

02/01/2005 +Shorewall 2.2.0
+
+New Features:
+

+
    +
  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. +
  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. +
  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. +
  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. +
  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:
    6. + +
+
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"
+
+
+
+
    +
  1. 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:
    2. + +
  2. 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:
    3. +
      +
    1. 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 /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
      +
      +
      2. +
    2. 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,...
      3. +
    +
+
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:
+
+ +
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.
+
+
    +
  1. 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.
    2. +
  2. A new 'allowBcast' builtin action has been added -- it silently +allows broadcasts and multicasts.
    3. +
  3. 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   [ +<configuration-directory> ]
    +      shorewall restart [ +<configuration-directory> ]
    +      shorewall start   [ +<configuration-directory> ]
    +
    +
    4. +
  4. 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  <source +address>,<source port> 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 <low-port>-<high-port>. 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
    +
    +
    5. +
  5. 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.
    6. +
  6. Shorewall now verifies that your kernel and iptables have physdev +match support if BRIDGING=Yes in shorewall.conf.
    7. +
  7. 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 <low +address>-<high address> may also appear.
    8. +
  8. 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 +<major>:<minor> 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.
    9. +
  9. 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 they 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".
    10. +
  10. 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".
    11. +
  11. 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
    +
    +
    12. +
  12. 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.
    13. +
  13. 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)
    +
    +
    14. +
  14. 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.
    15. +
  15. 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
    +
    +
    16. +
  16. 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").
    17. +
  17. Shorewall now has support for the CONNMARK target from iptables. +See the /etc/shorewall/tcrules file for details.
    18. +
  18. 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.
    +
    +
    19. +
  19. 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.
    20. +
  20. The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
    21. +
  21. For consistency, the CLIENT PORT(S) column in the tcrules file +has been renamed SOURCE PORT(S).
    22. +
  22. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now +shown in the output of "shorewall status".
    23. +
  23. 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.
    24. +
  24. 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 #
    +
    +
    25. +
  25. Variable expansion may now be used with the INCLUDE directive.
    +
    +    Example:
    +
    +    /etc/shorewall/params
    +
    +        FILE=/etc/foo/bar
    +
    +        Any other config file:
    +
    +        INCLUDE $FILE
    +
    +
    26. +
  26. The output of "shorewall status" now includes the results of "ip +-stat link ls". This helps diagnose performance problems caused by link +errors.
    27. +
  27. 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.
    28. +
  28. 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.
    +
    +
    29. +
  29. 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
    +  
    +
    30. +
  30. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel +type. OpenVPN entries in /etc/shorewall/tunnels have this format:
    +
    +    openvpn[:{tcp|udp}][:<port>]    +<zone>        <gateway>
    +
    +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
    +
    +
    31. +
  31. 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:
    32. +
+ +
    +
  1. The output of "shorewall status" now lists the loaded netfilter +kernel modules.
    2. +
  2. The range of UDP ports opened by the AllowTrcrt action has been +increased to 33434:33524.
    3. +
  3. 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.
    4. +
+

01/17/2005 - Shorewall 2.2.0 RC5

Problems Corrected:
diff --git a/Shorewall-Website/Shorewall_index_frame.htm b/Shorewall-Website/Shorewall_index_frame.htm index 819fb8988..22f15783d 100644 --- a/Shorewall-Website/Shorewall_index_frame.htm +++ b/Shorewall-Website/Shorewall_index_frame.htm @@ -38,10 +38,7 @@ Repository
Errata
Features
-Mailing -Lists
+ color="#ffffff">
Mirrors
News Archive
Errata
Features
-Mailing -Lists
+ color="#ffffff">
Mirrors
News Archive
color="#ffffff">
What it Cannot Do - +

GNU Free Documentation License”.

-

2005-03-16
+

2005-03-22

I strongly urge you to read and print a copy of the .

  • Jack Coates provides RPMs taylored for Mandrake. You can download them from his site.
    • + href="http://www.monkeynoodle.org/comp/net/shorewall/">download them +from his site.
  • Marc Zonzon provides a package for OpenWRT (Open firmware for Linksys® WRT54G). You can Fedora RPMS provided by Simon Matter: http://www.invoca.ch/pub/packages/shorewall/

    Mandrake RPMS provided by Jack -Coates: http://www.monkeynoodle.org/tmp
    +Coates: http://www.monkeynoodle.org/comp/net/shorewall/

    OpenWRT package provided by Marc Zonzon: Shoreline Firewall - + + + diff --git a/Shorewall-Website/shorewall_index.htm b/Shorewall-Website/shorewall_index.htm index 7ecd3eb79..6b2da4583 100644 --- a/Shorewall-Website/shorewall_index.htm +++ b/Shorewall-Website/shorewall_index.htm @@ -9,7 +9,15 @@ -

    Shorewall 2.x

    +

    (Linuxfest NW 2005 Banner)

    +


    +

    +

    Shorewall 2.x
    +

    Tom Eastep

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

    target="_top">here.

    • -

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

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

    GNU Free Documentation License”.

    -

    2005-03-12

    -
    +

    2005-04-29

    +

    Table of Contents

    Introduction to Shorewall

    @@ -64,18 +72,17 @@ Shorewall on Mandrake® with a two-interface setup?
    License

    News

    Shorewall + style="text-decoration: underline;">Tom +will speak at LinuxFest NW 2005
    +Shorewall +2.2.3
    +Shorewall +2.0.17
    +Shorewall 2.2.2
    -Shorewall -2.2.1
    -    End of Support for Shorewall 1.4
    -Shorewall -2.0.16
    -Shorewall -2.2.0
    -

    -
    Leaf
    + @@ -120,7 +127,23 @@ Shorewall is not a daemon. Once Shorewall has configured Netfilter, it's job is complete. After that, there is no Shorewall code running although the /sbin/shorewall program -can be used at any time to monitor the Netfilter firewall.

    +can be used at any time to monitor the Netfilter firewall.
    +

    +

    Shorewall is not the easiest to use of +the available iptables configuration tools but I believe that it is the +most flexible and powerful. So if you are looking for a simple +point-and-click set-and-forget Linux firewall solution that requires a +minimum of networking knowledge, I would encourage you to check out the +following alternatives:

    + +

    On the other hand, if you are looking +for a Linux firewall solution that can handle complex and fast changing +network environments then Shorewall is a logical choice.
    +

    Getting Started with Shorewall

    New to Shorewall? Start by selecting the QuickStart Guide @@ -129,7 +152,7 @@ step instructions.

    Looking for Information?

    The Documentation Index is a good place to start as is the Site Search in the -frame above.

    +frame above. network

    Running Shorewall on Mandrake® with a two-interface setup?

    If so, the documentation on this site @@ -166,6 +189,96 @@ of the license is included in the section entitled "GNU Free Documentation License".

    News

    +04/25/2005 Tom +will Speak at LinuxFest NW 2005 -- Bellingham Technical College, +Bellingham Washington
    +
    +Tom's presentation is entitled "Shorewall and Native IPSEC" and is +available for download here (PDF Format). +The presentation will be given Saturday April 30 at 10:00 AM in Haskell +Hall, room 111.
    +
    +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

    @@ -241,768 +354,7 @@ WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support 'Connection Tracking' match.
    -02/15/2005 -Shorewall 2.2.1
    -
    -    This release rolls up the fixes for bugs found in the first 2-3 -weeks of deployment of Shorewall 2.2.
    -
      -
    1. The /etc/shorewall/policy file contained a misleading comment and -both that file and the /etc/shorewall/zones file lacked examples.
      2. -
    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. -
    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: ...
      -
      -
      4. -
    4. The comments regarding built-in actions in -/usr/share/shorewall/actions.std have been corrected.
      5. -
    5. The /etc/shorewall/policy file in the LRP package was missing the -'all->all' policy.
      -
      6. -
    -02/05/2005 -End of Support for Shorewall 1.4
    -
    -    Effective today, support for Shorewall 1.4 has been -discontinued. See the link at the top of this article for  upgrade -information.
    -
    -    02/01/2005 -Shorewall 2.0.16
    -
    -This release back-ports the DROPINVALID shorewall.conf option from -2.2.0.
    -
      -
    1. 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.
      -
      2. -
    -02/01/2005 -Shorewall 2.2.0
    -
    -    New Features:
    -
      -
    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. -
    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. -
    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. -
    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. -
    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:
      6. -
        -
      • 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
        -
        -
        • -
      • 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:
        -
        - Update: I've been -informed by Mandrake Development that this problem has been corrected -in Mandrake 10.0 Final (the problem still exists in the 10.0 -Community release).
        -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"
    -
    -
    -
    -
      -
    1. 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:
      2. -
        -
      • It prevents Shorewall from being started prematurely by the -user's initialization scripts.
        • -
      • It causes /etc/shorewall/shorewall.conf to be modified so that -it won't be replaced by upgrades using RPM.
        -
        -
        • -
      -
    2. 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:
      3. -
        -
      1. 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 /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
        -
        -
        2. -
      2. 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,...
        3. -
      -
    -
    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[!]=<number> where <number> is specified using -setkey(8) using the 'unique:<number>' option for the SPD level.
        • -
      • spi[!]=<number> where <number> 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=<number> (sets the MSS value in TCP SYN packets and -is not related to policy matching)
        • -
      • mode[!]=transport|tunnel
        • -
      • tunnel-src[!]=<address>[/<mask>] (only available -with mode=tunnel)
        • -
      • tunnel-dst[!]=<address>[/<mask>] (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.
    -
    -
      -
    1. 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.
      2. -
    2. A new 'allowBcast' builtin action has been added -- it silently -allows broadcasts and multicasts.
      3. -
    3. 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   [ -<configuration-directory> ]
      -      shorewall restart [ -<configuration-directory> ]
      -      shorewall start   [ -<configuration-directory> ]
      -
      -
      4. -
    4. 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  <source -address>,<source port> 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 <low-port>-<high-port>. 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
      -
      -
      5. -
    5. 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.
      6. -
    6. Shorewall now verifies that your kernel and iptables have physdev -match support if BRIDGING=Yes in shorewall.conf.
      7. -
    7. 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 <low -address>-<high address> may also appear.
      8. -
    8. 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 -<major>:<minor> 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.
      9. -
    9. 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 they 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".
      10. -
    10. 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".
      11. -
    11. 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
      -
      -
      12. -
    12. 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.
      13. -
    13. 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)
      -
      -
      14. -
    14. 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.
      15. -
    15. 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
      -
      -
      16. -
    16. 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").
      17. -
    17. Shorewall now has support for the CONNMARK target from iptables. -See the /etc/shorewall/tcrules file for details.
      18. -
    18. 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.
      -
      -
      19. -
    19. 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.
      20. -
    20. The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
      21. -
    21. For consistency, the CLIENT PORT(S) column in the tcrules file -has been renamed SOURCE PORT(S).
      22. -
    22. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now -shown in the output of "shorewall status".
      23. -
    23. 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.
      24. -
    24. 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 #
      -
      -
      25. -
    25. Variable expansion may now be used with the INCLUDE directive.
      -
      -    Example:
      -
      -    /etc/shorewall/params
      -
      -        FILE=/etc/foo/bar
      -
      -        Any other config file:
      -
      -        INCLUDE $FILE
      -
      -
      26. -
    26. The output of "shorewall status" now includes the results of "ip --stat link ls". This helps diagnose performance problems caused by link -errors.
      27. -
    27. 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.
      28. -
    28. 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.
      -
      -
      29. -
    29. 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
      -  
      -
      30. -
    30. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel -type. OpenVPN entries in /etc/shorewall/tunnels have this format:
      -
      -    openvpn[:{tcp|udp}][:<port>]    -<zone>        <gateway>
      -
      -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
      -
      -
      31. -
    31. 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:
      32. -
    -
      -
        -
      • 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.
        • -
      -
    -
      -
    1. The output of "shorewall status" now lists the loaded netfilter -kernel modules.
      2. -
    2. The range of UDP ports opened by the AllowTrcrt action has been -increased to 33434:33524.
      3. -
    3. 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.
      -
      4. -
    +

    More News

    Leaf

    diff --git a/Shorewall-Website/useful_links.html b/Shorewall-Website/useful_links.html index abb3200e1..825f7e322 100755 --- a/Shorewall-Website/useful_links.html +++ b/Shorewall-Website/useful_links.html @@ -33,7 +33,7 @@ Documentation License”.

    -

    2005-03-18

    +

    2005-03-22

    @@ -60,7 +60,7 @@ Traffic Control Howto: http://ds9a. Iproute Downloads: ftp://ftp.inr.ac.ru/ip-routing + href="http://developer.osdl.org/dev/iproute2/download/" target="_top">http://developer.osdl.org/dev/iproute2/download/ LEAF Site: