[Shorewall-newbies] Shorewall 2.0.0 Beta2

Tom Eastep teastep at shorewall.net
Sat Feb 14 17:44:33 PST 2004


Please read the release notes carefully -- there are significant differences 
between Beta1 and Beta2.

If you are running Beta1, you will need to remove the INCLUDE from your 
/etc/shorewall/actions file (that I instructed you to add last time -- I 
know; I lied).

Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep at shorewall.net

-------------- next part --------------
Shorewall 2.0.0-Beta2

Problems Corrected since prior version.

	 None - this is the initial release.
Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:

1) The 'dropunclean' and 'logunclean' interface options are no longer
   supported. If either option is specified in
   /etc/shorewall/interfaces, an threatening message will be

2) The NAT_BEFORE_RULES option has been removed from
   shorewall.conf. The behavior of Shorewall is as if
   NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules
   now always take precidence over one-to-one NAT specifications.

3) The default value for the ALL INTERFACES column in
   /etc/shorewall/nat has changed. In Shorewall 1.*, if the column was
   left empty, a value of "Yes" was assumed. This has been changed so
   that a value of "No" is now assumed.

4) The following files don't exist in Shorewall 2.0:


   The /etc/shorewall/action file now allows an action to be
   designated as the "common" action for a particular policy type by
   following the action name with ":" and the policy (DROP, REJECT or

   The file /usr/share/shorewall/actions.std has been added to define those
   actions that are released as part of Shorewall. In that file are
   two actions as follows:


   The "Drop" action is the common action for DROP policies while the
   "Reject" action is the default action for "REJECT" policies. These
   actions will be performed on packets prior to applying the DROP or
   REJECT policy respectively. In the first release, the difference
   between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic
   while "Drop" silently drops such traffic.

   As described above, Shorewall allows a common action for ACCEPT
   policies but does not specify such an action in the default

   The file /usr/share/shorewall/actions.std catalogs the standard 
   actions and is processed prior to /etc/shorewall/actions. This
   causes a large number of actions to be defined. The files which
   define these aactions are also located in /usr/share/shorewall as
   is the he action template file (action.template).

   In the initial release, the following actions are defined:

      dropBcast       #Silently Drops Broadcast Traffic
      dropNonSyn      #Silently Drop Non-syn TCP packets

      DropSMB         #Silently Drops Microsoft SMB Traffic
      RejectSMB       #Silently Reject Microsoft SMB Traffic
      DropUPnP        #Silently Drop UPnP Probes
      RejectAuth      #Silently Reject Auth
      DropPing        #Silently Drop Ping
      DropDNSrep      #Silently Drop DNS Replies

      AllowPing       #Accept Ping
      AllowFTP        #Accept FTP
      AllowDNS        #Accept DNS
      AllowSSH        #Accept SSH
      AllowWeb        #Allow Web Browsing
      AllowSMB        #Allow MS Networking
      AllowAuth       #Allow Auth (identd)
      AllowSMTP       #Allow SMTP (Email)
      AllowPOP3       #Allow reading mail via POP3
      AllowIMAP       #Allow reading mail via IMAP
      AllowTelnet     #Allow Telnet Access (not recommended for use over the
      AllowVNC        #Allow VNC, Displays 0-9
      AllowVNCL	      #Allow access to VNC viewer in listen mode
      AllowNTP        #Allow Network Time Protocol (ntpd)
      AllowRdate      #Allow remote time (rdate).
      AllowNNTP       #Allow network news (Usenet).
      AllowTrcrt      #Allows Traceroute (20 hops)
      AllowSNMP	      #Allows SNMP (including traps)
      AllowPCA	      #Allows PCAnywhere (tm).

      Drop:DROP       #Common rules for DROP policy
      Reject:REJECT   #Common Action for Reject policy

   if you want to redefine any of the Shorewall-defined actions, 
   simply copy the appropriate action file from /usr/share/shorewall
   to /etc/shorewall and modify the copy as desired. Your modified
   copy will be used rather than the original one in

       Note: The 'dropBcast' and 'dropNonSyn' actions are built into
       Shorewall and may not be changed.

   Beginning with version 2.0.0-Beta2, Shorewall will only create a
   chain for those actions that are actually used.

5) The /etc/shorewall directory no longer contains a 'users' file or a
   'usersets' file. Similar functionality is now available using
   user-defined actions.

   Now, action files created by copying /etc/shorewall/action.template
   may now specify a USER and or GROUP name/id in the final column just
   like in the rules file (see below). It is thus possible to create
   actions that control traffic from a list of users and/or groups.

   The last column in /etc/shorewall/rules is now labeled USER/GROUP
   and may contain:

       [!]<user number>[:]
       [!]<user name>[:]
       [!]:<group number>
       [!]:<group name>
       [!]<user number>:<group number>
       [!]<user number>:<group name>
       [!]<user name>:<group number>
       [!]<user name>:<group name>

6) It is no longer possible to specify rate limiting in the ACTION
   column of /etc/shorewall/rules -- you must use the RATE LIMIT

New Features:

1) The INCLUDE directive now allows absolute file names.

2) A 'nosmurfs' interface option has been added to
   /etc/shorewall/interfaces. When specified for an interface, this
   option causes smurfs (packets with a broadcast address as their
   source) to be dropped and optionally logged (based on the setting of
   a new SMURF_LOG_LEVEL option in shorewall.conf).

3) fw->fw traffic may now be controlled by Shorewall. There is no need
   to define the loopback interface in /etc/shorewall/interfaces; you
   simply add a fw->fw policy and fw->fw rules. If you have neither a
   fw->fw policy nor fw->fw rules, all fw->fw traffic is allowed.

4) There is a new PERSISTENT column in the proxyarp file. A value of
   "Yes" in this column means that the route added by Shorewall for
   this host will remain after a "shorewall stop" or "shorewall clear".

5) "trace" is now a synonym for "debug" in /sbin/shorewall commands.
   So to trace the "start" command, you could enter:

      shorewall trace start 2> /tmp/trace

   The trace information would be written to the file /tmp/trace.

6) When defining an ipsec tunnel in /etc/shorewall/tunnels, if you
   follow the tunnel type ("ipsec" or "ipsecnet") with ":noah"
   (e.g., "ipsec:noah"), then Shorewall will only create rules for
   ESP (protocol 50) and will not create rules for AH (protocol 51).


More information about the Shorewall-newbies mailing list