Shorewall 4.3.8 is now available for testing:
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 3 . 8
----------------------------------------------------------------------------
1) Tuomo Soini provided a workaround patch for a problem seen in some
kernel''s (see FAQ 82) that caused ''shorewall
start'' to fail when
USE_DEFAULT_RT=Yes .
2) The swping program was not purging the interface status files when
it first started.
3) When LOG_MARTIANS=Yes with Shorewall-perl, setting logmartians=0 in
an entry in /etc/shorewall/interface failed to suppress martian
logging on the interface.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 3 . 8
----------------------------------------------------------------------------
1) The generated program now attempts to detect all dynamic
information when it first starts. If any of those steps fail, an
error message is generated and the state of the firewall is not
changed.
2) Shorewall will now attempt to detect a dynamic gateway by reading
the dhclient lease file for the interface
(/var/run/dhcp/dhclient-<if>.lease).
3) To improve readability of the configuration files, Shorewall now
allows leading white space in continuation lines when the continued
line ends in ":" or ",".
Example (/etc/shorewall/rules):
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net:\
206.124.146.177,\
206.124.146.178,\
206.124.146.180\
dmz tcp 873
The leading white space on the lines that contain just an IP
address is ignored so the SOURCE column effectively contains
"net:206.124.146.177,206.124.147.178,206.124.146.180".
4) The generated script now uses iptables[6]-restore to instantiate
the Netfilter ruleset during processing of the ''stop''
command. As a
consequence, the ''critical'' option in
/etc/shorewall/route_stopped
is no longer needed and will result in a warning.
5) A new AUTOMAKE option has been added to shorewall.conf and
shorewall6.conf. When set to ''Yes'', this option causes new
behavior
during processing of the ''start'' and
''restart'' commands; if no
files in /etc/shorewall/ (/etc/shorewall6) have changed since the
last ''start'' or ''restart'', then the
compilation step is skipped and
the script used during the last ''start'' or
''restart'' is used to
start/restart the firewall.
Note that if a <directory> is specified in the start/restart
command (e.g., "shorewall restart /etc/shorewall.new") then the
setting of AUTOMAKE is ignored.
Note that the ''make'' utility must be installed on the
firewall
system in order for AUTOMAKE=Yes to work correctly.
6) The ''compile'' command now allows you to omit the
<pathname>. When
you do that, the <pathname> defaults to /var/lib/shorewall/firewall
(/var/lib/shorewall6/firewall) unless you have overridden VARDIR
using /etc/shorewall/vardir (/etc/shorewall6/vardir).
When combined with AUTOMAKE=Yes, it allows the following:
gateway:~ # shorewall compile
Compiling...
Shorewall configuration compiled to /root/shorewall/firewall
gateway:~ #
...
gateway:~ # shorewall restart
Restarting Shorewall....
done.
gateway:~ #
In other words, you can compile the current configuration then
install it at a later time.
7) Thanks to I. Buijs, it is now possible to rate-limit connections by
source IP or destination IP. The LIMIT:BURST column in
/etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT
column /etc/shorewall/rules (/etc/shorewall6/rules) have been
extended as follows:
[{s|d}:[[<name>]:]]<rate>/{sec|min}[:<burst>]
When s: is specified, the rate is per source IP address.
When d: is specified, the rate is per destination IP address.
The <name> specifies the name of a hash table -- you get to choose
the name. If you don''t specify a name, the name
''shorewall'' is
assumed. Rules with the same name have their connection counts
aggregated and the individual rates are applied to the aggregate.
Example:
ACCEPT net fw tcp 22 - - s:ssh:3/min
This will limit SSH connections from net->fw to 3 per minute.
ACCEPT net fw tcp 25 - - s:mail:3/min
ACCEPT net fw tcp 587 - - s:mail:3/min
Since the same hash table name is used in both rules, the above is
equivalent to this single rule:
ACCEPT net fw tcp 25,587 - - s:mail:3/min
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
Tom I have just been doing some testing of NOTRACK and have come across a discrepancy. The NOTRACK manual page states that only addresses are allowed in the DESTINATION column, while two shorewall compiler messages suggest that an interface is also allowed. Additionally Shorewall allows an interface to be coded, but then generates an invalid iptables rule. EG coding: lan:eth0 zzz produces the message: ERROR: Unknown interface (zzz) .... If I code both an interface and an IP address: lan:eth0 eth0:1.2.3.4 this produces the message: ERROR: DEST interface may not be specified with a destination IP address in the PREROUTING chain ... If I then code a valid interface: lan:eth0 eth0 the following invalid rule is generated: -A lan_notrk -i eth0 -d ETH0_NETWORKS -j NOTRACK Steven. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Steven Jan Springl wrote:> Tom > > I have just been doing some testing of NOTRACK and have come across a > discrepancy. > The NOTRACK manual page states that only addresses are allowed in the > DESTINATION column, while two shorewall compiler messages suggest that an > interface is also allowed. Additionally Shorewall allows an interface to be > coded, but then generates an invalid iptables rule. > > EG coding: > > lan:eth0 zzz > > produces the message: > > ERROR: Unknown interface (zzz) .... > > If I code both an interface and an IP address: > > lan:eth0 eth0:1.2.3.4 > > this produces the message: > > ERROR: DEST interface may not be specified with a destination IP address in > the PREROUTING chain ... > > If I then code a valid interface: > > lan:eth0 eth0 > > the following invalid rule is generated: > > -A lan_notrk -i eth0 -d ETH0_NETWORKS -j NOTRACKFixed by r9831. A destination interface name should actually work in the PREROUTING case but I despair of trying to explain the limitations to people. It is just easier to scare them off by telling them that it isn''t allowed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Tom Eastep wrote:> Steven Jan Springl wrote: >> Tom >> >> I have just been doing some testing of NOTRACK and have come across a >> discrepancy. >> The NOTRACK manual page states that only addresses are allowed in the >> DESTINATION column, while two shorewall compiler messages suggest that an >> interface is also allowed. Additionally Shorewall allows an interface to be >> coded, but then generates an invalid iptables rule. >> >> EG coding: >> >> lan:eth0 zzz >> >> produces the message: >> >> ERROR: Unknown interface (zzz) .... >> >> If I code both an interface and an IP address: >> >> lan:eth0 eth0:1.2.3.4 >> >> this produces the message: >> >> ERROR: DEST interface may not be specified with a destination IP address in >> the PREROUTING chain ... >> >> If I then code a valid interface: >> >> lan:eth0 eth0 >> >> the following invalid rule is generated: >> >> -A lan_notrk -i eth0 -d ETH0_NETWORKS -j NOTRACK > > Fixed by r9831. A destination interface name should actually work in the > PREROUTING case but I despair of trying to explain the limitations to > people. It is just easier to scare them off by telling them that it > isn''t allowed.I should add that correct handling of a destination interface in a PREROUTING rule is only available in 4.3 -- 4.2 rejects that usage. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
On Wednesday 08 April 2009 15:37:49 Tom Eastep wrote:> Tom Eastep wrote:> > > > Fixed by r9831. A destination interface name should actually work in the > > PREROUTING case but I despair of trying to explain the limitations to > > people. It is just easier to scare them off by telling them that it > > isn''t allowed. > > I should add that correct handling of a destination interface in a > PREROUTING rule is only available in 4.3 -- 4.2 rejects that usage. > > -TomTom I have applied r9831, and all is okay. Thanks. Steven. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Tom After the application of patches up to r9835, when Shorewall creates an iptables rule to branch to the new log chain, it does not allow for rules with more than 15 destination ports: Shorewall rule: ACCEPT;warn lan fw tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 generates iptables rule: -A lan2fw -p 6 -m multiport --dports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 -g log0 Steven. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Steven Jan Springl wrote:> Tom > > After the application of patches up to r9835, when Shorewall creates an > iptables rule to branch to the new log chain, it does not allow for rules > with more than 15 destination ports: > > Shorewall rule: > > ACCEPT;warn lan fw tcp 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 > > generates iptables rule: > > -A lan2fw -p 6 -m multiport --dports > 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 -g log0I know -- I just haven''t fixed it yet. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
On Tue, 2009-04-07 at 09:12 -0700, Tom Eastep wrote:> 7) Thanks to I. Buijs, it is now possible to rate-limit connections by > source IP or destination IP. The LIMIT:BURST column in > /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT > column /etc/shorewall/rules (/etc/shorewall6/rules) have been > extended as follows: > > [{s|d}:[[<name>]:]]<rate>/{sec|min}[:<burst>] > > When s: is specified, the rate is per source IP address.> ACCEPT net fw tcp 22 - - s:ssh:3/min > > This will limit SSH connections from net->fw to 3 per minute.Sweet! So this effectively supersedes the Limit [1] action? I assume it also uses the recent match -- does it actually generate the same iptables rules? Karsten [1] http://shorewall.net/Actions.html#Limit -- char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1: (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}} ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Karsten Bräckelmann wrote:> On Tue, 2009-04-07 at 09:12 -0700, Tom Eastep wrote: >> 7) Thanks to I. Buijs, it is now possible to rate-limit connections by >> source IP or destination IP. The LIMIT:BURST column in >> /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT >> column /etc/shorewall/rules (/etc/shorewall6/rules) have been >> extended as follows: >> >> [{s|d}:[[<name>]:]]<rate>/{sec|min}[:<burst>] >> >> When s: is specified, the rate is per source IP address. > >> ACCEPT net fw tcp 22 - - s:ssh:3/min >> >> This will limit SSH connections from net->fw to 3 per minute. > > Sweet! So this effectively supersedes the Limit [1] action? > > I assume it also uses the recent match -- does it actually generate the > same iptables rules?It uses hashlimit. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
On Sun, 2009-04-12 at 12:12 -0700, Tom Eastep wrote:> Karsten Bräckelmann wrote: > > On Tue, 2009-04-07 at 09:12 -0700, Tom Eastep wrote:> > > ACCEPT net fw tcp 22 - - s:ssh:3/min > > > > > > This will limit SSH connections from net->fw to 3 per minute. > > > > Sweet! So this effectively supersedes the Limit [1] action? > > > > I assume it also uses the recent match -- does it actually generate the > > same iptables rules? > > It uses hashlimit.Ah, you got me there -- could you elaborate? Does it actually supersede the Limit action? -- char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1: (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}} ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Karsten Bräckelmann wrote:> On Sun, 2009-04-12 at 12:12 -0700, Tom Eastep wrote: >> Karsten Bräckelmann wrote: >>> On Tue, 2009-04-07 at 09:12 -0700, Tom Eastep wrote: > >>>> ACCEPT net fw tcp 22 - - s:ssh:3/min >>>> >>>> This will limit SSH connections from net->fw to 3 per minute. >>> Sweet! So this effectively supersedes the Limit [1] action? >>> >>> I assume it also uses the recent match -- does it actually generate the >>> same iptables rules? >> It uses hashlimit. > > Ah, you got me there -- could you elaborate? Does it actually supersede > the Limit action? >Well, I''m not going to remove the Limit action, if that''s what you are asking. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
On Sun, 2009-04-12 at 12:21 -0700, Tom Eastep wrote:> Karsten Bräckelmann wrote:> > Ah, you got me there -- could you elaborate? Does it actually supersede > > the Limit action? > > Well, I'm not going to remove the Limit action, if that's what you are > asking.I didn't assume you would, for backward compatibility -- even if they'd result in the very same rules. I guess what I'm asking is, if they are equivalent in functionality and just a new/shorter/different way to write it. Up until 4.3.7 the LIMIT column was not even close to the Limit action when it comes to things like SSH brute-force limiting and still retaining the possibility to ssh yourself while under attack... So, are they functionally equivalent? Any advantage, any drawbacks? -- char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1: (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}} ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Karsten Bräckelmann wrote:> On Sun, 2009-04-12 at 12:21 -0700, Tom Eastep wrote: >> Karsten Bräckelmann wrote: > >>> Ah, you got me there -- could you elaborate? Does it actually supersede >>> the Limit action? >> Well, I'm not going to remove the Limit action, if that's what you are >> asking. > > I didn't assume you would, for backward compatibility -- even if they'd > result in the very same rules. > > I guess what I'm asking is, if they are equivalent in functionality and > just a new/shorter/different way to write it. Up until 4.3.7 the LIMIT > column was not even close to the Limit action when it comes to things > like SSH brute-force limiting and still retaining the possibility to ssh > yourself while under attack... > > So, are they functionally equivalent? Any advantage, any drawbacks? > >The new feature is more flexible than Limit. Limit is always terminating -- rules with the new RATE LIMIT syntax are not. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel