Introduction

• Netfilter - the packet filter facility built into the 2.4 and later Linux kernels.
• ipchains - the packet filter facility built into the 2.2 Linux kernels. Also the name of the utility program used to configure and control that facility. Netfilter can be used in ipchains compatibility mode.
  
• iptables - the utility program used to configure and control Netfilter. The term 'iptables' is often used to refer to the combination of iptables+Netfilter (with Netfilter not in ipchains compatibility mode).
  

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

Copyright 2001, 2002, 2003 Thomas M. Eastep

This is the Shorewall 1.4 Web Site

• The 1.3 site is here.
• The 1.2 site is here.
  

Getting Started with Shorewall

Looking for Information?

Running Shorewall on Mandrake with a two-interface setup?

News

10/21/2003 - Shorewall 1.4.7a

This is a bugfix rollup of the following problem corrections:

1. Tuomo Soini has supplied a correction to a problem that occurs using some versions of 'ash'. The symptom is that "shorewall start" fails with:
    
      local: --limit: bad variable name
      iptables v1.2.8: Couldn't load match `-j':/lib/iptables/libipt_-j.so:
      cannot open shared object file: No such file or directory
      Try `iptables -h' or 'iptables --help' for more information.
   
   
2. Andres Zhoglo has supplied a correction that avoids trying to use the multiport match iptables facility on ICMP rules.
    
      Example of rule that previously caused "shorewall start" to fail:
    
              ACCEPT      loc  $FW  icmp    0,8,11,12
   
   
3. Previously, if the following error message was issued, Shorewall was left in an inconsistent state.
    
      Error: Unable to determine the routes routes through interface xxx
   
   
4. Handling of the LOGUNCLEAN option in shorewall.conf has been corrected.
5. In Shorewall 1.4.2, an optimization was added. This optimization involved creating a chain named "<zone>_frwd" for most zones defined using the /etc/shorewall/hosts file. It has since been discovered that in many cases these new chains contain redundant rules and that the "optimization" turns out to be less than optimal. The implementation has now been corrected.
6. When the MARK value in a tcrules entry is followed by ":F" or ":P", the ":F" or ":P" was previously only applied to the first Netfilter rule generated by the entry. It is now applied to all entries.
   

10/06/2003 - Shorewall 1.4.7

1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set.
2. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.
3. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from shooting themselves in the foot prior to having configured Shorewall.
4. A change introduced in version 1.4.6 caused error messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP interface; the addresses were successfully added in spite of the messages.
      
   The firewall script has been modified to eliminate the error messages
5. Interface-specific dynamic blacklisting chains are now displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
7. The 'shorewall reject' and 'shorewall drop' commands now delete any existing rules for the subject IP address before adding a new DROP or REJECT rule. Previously, there could be many rules for the same IP address in the dynamic chain so that multiple 'allow' commands were required to re-enable traffic to/from the address.
8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in /etc/shorewall/masq resulted in a startup error:
    
      eth0 eth1     206.124.146.20-206.124.146.24
   
   
9. Shorewall previously choked over IPV6 addresses configured on interfaces in contexts where Shorewall needed to detect something about the interface (such as when "detect" appears in the BROADCAST column of the /etc/shorewall/interfaces file).
10. Shorewall will now load module files that are formed from the module name by appending ".o.gz".
11. When Shorewall adds a route to a proxy ARP host and such a route already exists, two routes resulted previously. This has been corrected so that the existing route is replaced if it already exists.
12. The rfc1918 file has been updated to reflect recent allocations.
13. The documentation of the USER SET column in the rules file has been corrected.
14. If there is no policy defined for the zones specified in a rule, the firewall script previously encountered a shell syntax error:
                                                                                                                                                                                       
            [: NONE: unexpected operator
                                                                                                                                                                                       
    Now, the absence of a policy generates an error message and the firewall is stopped:
                                                                                                                                                                                       
            No policy defined from zone <source> to zone <dest>
    
    
15. Previously, if neither /etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall would fail to start and would not remove the lock file. Failure to remove the lock file resulted in the following during subsequent attempts to start:
                                                                                                                                                                                       
        Loading /usr/share/shorewall/functions...
        Processing /etc/shorewall/params ...
        Processing /etc/shorewall/shorewall.conf...
        Giving up on lock file /var/lib/shorewall/lock
        Shorewall Not Started
    
    Shorewall now reports a fatal error if neither of these two files exist and correctly removes the lock fille.
16. The order of processing the various options has been changed such that blacklist entries now take precedence over the 'dhcp' interface setting.
17. The log message generated from the 'logunclean' interface option has been changed to reflect a disposition of LOG rather than DROP.
18. When a user name and/or a group name was specified in the USER SET column and the destination zone was qualified with a IP address, the user and/or group name was not being used to qualify the rule.
     
        Example:
     
        ACCEPT fw  net:192.0.2.12 tcp 23 - - - vladimir:
    
    
19. The /etc/shorewall/masq file has had the spurious "/" character at the front removed.

1. Shorewall IP Traffic Accounting has changed since snapshot 20030813 -- see the Accounting Page for details.
2. The Uset Set capability introduced in SnapShot 20030821 has changed -- see the User Set page for details.
3. The per-interface Dynamic Blacklisting facility introduced in the first post-1.4.6 Snapshot has been removed. The facility had too many idiosyncrasies for dial-up users to be a viable part of Shorewall.
   

1. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
2. A new option "ADMINISABSENTMINDED" has been added to /etc/shorewall/shorewall.conf. This option has a default value of "No" for existing users which causes Shorewall's 'stopped' state  to continue as it has been; namely, in the stopped state only traffic to/from hosts listed in /etc/shorewall/routestopped is accepted.
   
   With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
   
      a) All traffic originating from the firewall itself; and
      b) All traffic that is part of or related to an already-existing connection.
   
    In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" entered through an ssh session will not kill the session.
   
    Note though that even with ADMINISABSENTMINDED=Yes, it is still possible for people to shoot themselves in the foot.
   
    Example:
   
    /etc/shorewall/nat:
   
        206.124.146.178    eth0:0    192.168.1.5   
   
    /etc/shorewall/rules:
   
      ACCEPT    net    loc:192.168.1.5    tcp    22
      ACCEPT    loc    fw        tcp    22
   
   From a remote system, I ssh to 206.124.146.178 which establishes an SSH connection with local system 192.168.1.5. I then create a second SSH connection from that computer to the firewall and confidently type "shorewall stop". As part of its stop processing, Shorewall removes eth0:0 which kills my SSH connection to 192.168.1.5!!!
3. Given the wide range of VPN software, I can never hope to add specific support for all of it. I have therefore decided to add "generic" tunnel support.
    
   Generic tunnels work pretty much like any of the other tunnel types. You usually add a zone to represent the systems at the other end of the tunnel and you add the appropriate rules/policies to
   implement your security policy regarding traffic to/from those systems.
    
   In the /etc/shorewall/tunnels file, you can have entries of the form:
   
   generic:<protocol>[:<port>]  <zone>  <ip address>    <gateway zones>
    
   where:
    
          <protocol> is the protocol used by the tunnel
          <port>  if the protocol is 'udp' or 'tcp' then this is the destination port number used by the tunnel.
          <zone>  is the zone of the remote tunnel gateway
          <ip address> is the IP address of the remote tunnel gateway.
          <gateway zone>   Optional. A comma-separated list of zone names. If specified, the remote gateway is to be considered part of these zones.
4. An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the result that this interface will only answer ARP 'who-has' requests from hosts that are routed out through that interface. Setting this option facilitates testing of your firewall where multiple firewall interfaces are connected to the same HUB/Switch (all interfaces connected to the single HUB/Switch should have this option specified). Note that using such a configuration in a production environment is strongly recommended against.
5. The ADDRESS column in /etc/shorewall/masq may now include a comma-separated list of addresses and/or address ranges. Netfilter will use all listed addresses/ranges in round-robin fashion. \
6. An /etc/shorewall/accounting file has been added to allow for traffic accounting.  See the accounting documentation for a description of this facility.
7. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the corresponding ACCEPT rule in the filter table is not rate limited. If you want to limit the filter table rule, you will need o create two rules; a DNAT- rule and an ACCEPT rule which can be rate-limited separately.
    
   Warning: When rate limiting is specified on a rule with "all" in the SOURCE or DEST fields, the limit will apply to each pair of zones individually rather than as a single limit for all pairs of covered by the rule.
    
   To specify a rate limit,
   
   a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    
         < <rate>/<interval>[:<burst>] >
    
     where
    
         <rate> is the sustained rate per <interval>
         <interval> is "sec" or "min"
         <burst> is the largest burst accepted within an <interval>. If not given, the default of 5 is assumed.
    
   There may be no white space between the ACTION and "<" nor there may be any white space within the burst specification. If you want to specify logging of a rate-limited rule, the ":" and log level comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
   
   b) A new RATE LIMIT column has been added to the /etc/shorewall/rules file. You may specify the rate limit there in the format:
   
         <rate>/<interval>[:<burst>]
    
   Let's take an example:
    
            ACCEPT<2/sec:4>        net     dmz     tcp     80
      
   The first time this rule is reached, the packet will be accepted; in fact, since the burst is 4, the first four packets will be accepted. After this, it will be 500ms (1 second divided by the rate
   of 2) before a packet will be accepted from this rule, regardless of how many packets reach it. Also, every 500ms which passes without matching a packet, one of the bursts will be regained; if no packets hit the rule for 2 second, the burst will be fully recharged; back where we started.
   
9. Multiple chains may now be displayed in one "shorewall show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
10. Output rules (those with $FW as the SOURCE) may now be limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for details.
    

More News

Jacques Nilo and Eric Wolzak have a LEAF (router/firewall/gateway on a floppy, CD or compact flash) distribution called Bering that features Shorewall-1.4.2 and Kernel-2.4.20. You can find their work at: http://leaf.sourceforge.net/devel/jnilo

Donations

Extended Search