Beta 6 is now available for testing. Pay close attention to the
Blacklisting change in this release; static blacklisting is incompatible
with blacklisting in Beta 5.
Problems corrected:
1) ''shorewall clear'' (and ''shorewall6
clear'') now work again (broken
in Beta 5).
2) To work around an issue in Netfilter/iptables, Shorewall now uses
state match rather than conntrack match for UNTRACKED state
matching.
New Features:
1) Blacklisting has undergone considerable change in Shorewall 4.4.13.
a) Blacklisting is now based on zones rather than on interfaces and
host groups.
b) Near compatibility with earlier releases is maintained.
c) The keywords ''src'' and ''dst'' are now
preferred in the OPTIONS
column in /etc/shoreawll/blacklist, replacing ''from''
and ''to''
respectively. The old keywords are still supported.
d) The ''blacklist'' keyword may now appear in the OPTIONS,
IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.
i) In the IN_OPTIONS column, it indicates that packets received
on the interface are checked against the ''src''
entries in
/etc/shorewall/blacklist.
ii) In the OUT_OPTIONS column, it indicates that packets being
sent to the interface are checked against the ''dst''
entries.
iii) Placing ''blacklist'' in the OPTIONS column is
equivalent to
placing in in both the IN_OPTIONS and OUT_OPTIONS columns.
e) The ''blacklist'' option in the OPTIONS column of
/etc/shorewall/interfaces or /etc/shorewall/hosts is now
equivalent to placing it in the IN_OPTIONS column of the
associates record in /etc/shorewall/zones. If no zone is given
in the ZONE column of /etc/shorewall/interfaces, the
''blacklist''
option is ignored with a warning (it was previously ignored
silently).
f) The ''blacklist'' option in the /etc/shorewall/interfaces
and
/etc/shorewall/hosts files is now deprecated but will continue
to be supported for several releases. A warning will be added at
least one release before support is removed.
--
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 \________________________________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
> 1) Blacklisting has undergone considerable change in Shorewall 4.4.13. > > a) Blacklisting is now based on zones rather than on interfaces and > host groups. > > b) Near compatibility with earlier releases is maintained. > > c) The keywords ''src'' and ''dst'' are now preferred in the OPTIONS > column in /etc/shoreawll/blacklist, replacing ''from'' and ''to'' > respectively. The old keywords are still supported. >The template ''blacklist'' file does not have OPTIONS column.> d) The ''blacklist'' keyword may now appear in the OPTIONS, > IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones. > > i) In the IN_OPTIONS column, it indicates that packets received > on the interface are checked against the ''src'' entries in > /etc/shorewall/blacklist. > > ii) In the OUT_OPTIONS column, it indicates that packets being > sent to the interface are checked against the ''dst'' entries. > > iii) Placing ''blacklist'' in the OPTIONS column is equivalent to > placing in in both the IN_OPTIONS and OUT_OPTIONS columns. >1. Am I allowed to specify ''blacklist'' in the fw (firewall) zone? I did that, and when specified it on its own (with no other zones set with the blacklist option) I get the 2 ''blank'' (i.e. with no references) chains - blacklst and blackout and no warnings. This, though has a knock-on effect on the other interfaces (see 6 below). 2. During compile I am getting this warning: Use of uninitialized value in addition (+) at /usr/share/shorewall/Shorewall/Chains.pm line 712. Use of uninitialized value in addition (+) at /usr/share/shorewall/Shorewall/Chains.pm line 712. 3. I don''t know whether it is meant to be this way but Forward chain on lo is named lo_fwd, while ethX is ethX_frwd. 4. I don''t know whether this would be treated as syntax error, but specifying ''blacklist'' in OPTIONS as well as in any of the other columns (IN_OPTIONS and/or OUT_OPTIONS) should at least produce a warning (no harm in doing that). 5. I have both src,dst specified in the blacklist file, but when I specify ''net - - blacklist'' (i.e. OUT only) I am getting both blacklst and blackout chains with matching ipsets (it should be only the OUT part) and do not have a warning. 6. When I specify ''net - blacklist'' (i.e. IN only) I am getting the right result - blacklist chain with 2 references (net2fw and ethx_frwd), blacklist is missing and I get a warning as well, however if I have put the ''blacklist'' option in the fw zone (in the OPTIONS column) I get a ''blank'' blackout and NO warnings. I suspect I would get similar results when I am using other similar permutations on fw and the net zones. The new layout of the chains is good and I see blacklst and blackout are the first in it, which is great. That is what I found within an hour or so. Tomorrow will continue. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/17/10 9:10 AM, Tom Eastep wrote:> Beta 6 is now available for testing. Pay close attention to the > Blacklisting change in this release; static blacklisting is incompatible > with blacklisting in Beta 5.There are a couple of known problems. a) Mr Dash 4 has reported that a perl diagnostic is produced: Use of uninitialized value in addition (+) at /usr/share/shorewall/Shorewall/Chains.pm line 712. The attached FROZEN.patch corrects that. b) I''ve found an optimization bug that crazily reorders the rules in a chain that contains a jump to one of the blacklist chains. The attached CRAZY.patch corrects that problem. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/17/10 9:10 AM, Tom Eastep wrote:> Beta 6 is now available for testing. Pay close attention to the > Blacklisting change in this release; static blacklisting is incompatible > with blacklisting in Beta 5. > > Problems corrected: > > 1) ''shorewall clear'' (and ''shorewall6 clear'') now work again (broken > in Beta 5). > > 2) To work around an issue in Netfilter/iptables, Shorewall now uses > state match rather than conntrack match for UNTRACKED state > matching. > > New Features: > > 1) Blacklisting has undergone considerable change in Shorewall 4.4.13. > > a) Blacklisting is now based on zones rather than on interfaces and > host groups. > > b) Near compatibility with earlier releases is maintained. >I''ve found a case where interface-related filtering like ''nosmurfs'' and ''dhcp'' is done before incoming blacklist filtering. gateway:/etc/shorewall# cat zones fw firewall loc ip #Local Zone net ipv4 blacklist #Internet drct ipv4:loc gateway:/etc/shorewall# c gateway:/etc/shorewall# cat interfaces #ZONE INTERFACE BROADCAST OPTIONS drct INT_IF detect nets=dynamic,physical=... net COM_IF detect dhcp,optional,nosmurfs,physical=... ... gateway:/etc/shorewall# cat hosts #ZONE HOST(S) OPTIONS loc INT_IF:0.0.0.0/0 loc COM_IF:10.1.10.0/24 The ''net'' zone and ''loc'' zones share COM_IF. The generated ruleset: Shorewall 4.4.13-Beta6 Chain COM_IF_in at gateway - Fri Sep 17 16:24:08 PDT 2010 Counters reset Fri Sep 17 15:16:00 PDT 2010 Chain COM_IF_in (1 references) pkts bytes target prot opt in out source destination 1580 110K smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW,UNTRACKED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68 0 0 loc-dmz all -- * * 10.1.10.0/24 70.90.191.124/31 1 69 loc-fw all -- * * 10.1.10.0/24 0.0.0.0/0 98 6109 net-fw all -- * * 0.0.0.0/0 0.0.0.0/0 gateway:/etc/shorewall# Chain net-fw (1 references) pkts bytes target prot opt in out source destination 102 6353 blacklst all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW,UNTRACKED COM_IF_fwd is similar. I''m not sure whether or not I''ll be able to do anything about this in the short term. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Tom When routestopped contains: eth3 192.168.0.0/29,10.1.1.1 notrack After ''shorewall start'' and ''shorewall clear'' commands have been executed, iptables-save shows the following rules are still active: raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -s 192.168.0.0/29 -i br1 -m physdev --physdev-in eth3 -j NOTRACK -A PREROUTING -s 10.1.1.1/32 -i br1 -m physdev --physdev-in eth3 -j NOTRACK -A OUTPUT -d 192.168.0.0/29 -o br1 -m physdev --physdev-out eth3 --physdev-is-bridged -j NOTRACK -A OUTPUT -d 10.1.1.1/32 -o br1 -m physdev --physdev-out eth3 --physdev-is-bridged -j NOTRACK COMMIT Is this correct? Steven. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/17/10 4:35 PM, Steven Jan Springl wrote:> Tom > > When routestopped contains: > > eth3 192.168.0.0/29,10.1.1.1 notrack > > After ''shorewall start'' and ''shorewall clear'' commands have been executed, > iptables-save shows the following rules are still active: > > raw > :PREROUTING ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > -A PREROUTING -s 192.168.0.0/29 -i br1 -m physdev --physdev-in eth3 -j NOTRACK > -A PREROUTING -s 10.1.1.1/32 -i br1 -m physdev --physdev-in eth3 -j NOTRACK > -A OUTPUT -d 192.168.0.0/29 -o br1 -m physdev --physdev-out > eth3 --physdev-is-bridged -j NOTRACK > -A OUTPUT -d 10.1.1.1/32 -o br1 -m physdev --physdev-out > eth3 --physdev-is-bridged -j NOTRACK > COMMIT > > Is this correct?No. I''ll work on a fix... Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/17/10 4:41 PM, Tom Eastep wrote:> On 9/17/10 4:35 PM, Steven Jan Springl wrote: >> Tom >> >> When routestopped contains: >> >> eth3 192.168.0.0/29,10.1.1.1 notrack >> >> After ''shorewall start'' and ''shorewall clear'' commands have been executed, >> iptables-save shows the following rules are still active: >> >> raw >> :PREROUTING ACCEPT [0:0] >> :OUTPUT ACCEPT [0:0] >> -A PREROUTING -s 192.168.0.0/29 -i br1 -m physdev --physdev-in eth3 -j NOTRACK >> -A PREROUTING -s 10.1.1.1/32 -i br1 -m physdev --physdev-in eth3 -j NOTRACK >> -A OUTPUT -d 192.168.0.0/29 -o br1 -m physdev --physdev-out >> eth3 --physdev-is-bridged -j NOTRACK >> -A OUTPUT -d 10.1.1.1/32 -o br1 -m physdev --physdev-out >> eth3 --physdev-is-bridged -j NOTRACK >> COMMIT >> >> Is this correct? > > No. > > I''ll work on a fix... >This should fix it. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On Saturday 18 September 2010 01:12:09 Tom Eastep wrote:> On 9/17/10 4:41 PM, Tom Eastep wrote: > > On 9/17/10 4:35 PM, Steven Jan Springl wrote: > >> Tom > >> > >> When routestopped contains: > >> > >> eth3 192.168.0.0/29,10.1.1.1 notrack > >> > >> After ''shorewall start'' and ''shorewall clear'' commands have been > >> executed, iptables-save shows the following rules are still active: > >> > >> raw > >> > >> :PREROUTING ACCEPT [0:0] > >> :OUTPUT ACCEPT [0:0] > >> > >> -A PREROUTING -s 192.168.0.0/29 -i br1 -m physdev --physdev-in eth3 -j > >> NOTRACK -A PREROUTING -s 10.1.1.1/32 -i br1 -m physdev --physdev-in eth3 > >> -j NOTRACK -A OUTPUT -d 192.168.0.0/29 -o br1 -m physdev --physdev-out > >> eth3 --physdev-is-bridged -j NOTRACK > >> -A OUTPUT -d 10.1.1.1/32 -o br1 -m physdev --physdev-out > >> eth3 --physdev-is-bridged -j NOTRACK > >> COMMIT > >> > >> Is this correct? > > > > No. > > > > I''ll work on a fix... > > This should fix it. > > Thanks, > -TomTom That''s fixed it. Thanks. Steven. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/17/10 4:31 PM, Tom Eastep wrote:> > COM_IF_fwd is similar. > > I''m not sure whether or not I''ll be able to do anything about this in > the short term. >This is a natural consequence of making blacklisting a zone-related attribute rather than an interface-related attribute. Interface-oriented filtering comes first; so if more than one zone shares an Internet-facing interface then interface-related filtering can occur prior to zone-related filtering. C''est la vie... -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 09/17/2010 08:22 PM, Tom Eastep wrote:> On 9/17/10 4:31 PM, Tom Eastep wrote: > >> >> COM_IF_fwd is similar. >> >> I''m not sure whether or not I''ll be able to do anything about this in >> the short term. >> > > This is a natural consequence of making blacklisting a zone-related > attribute rather than an interface-related attribute. Interface-oriented > filtering comes first; so if more than one zone shares an > Internet-facing interface then interface-related filtering can occur > prior to zone-related filtering.I have added logic to promote jumps to ''blacklst'' ahead of interface-specific filtering rules. See the attached output. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Tom Tcfilters entry: eth0:33 2.2.2.2 1.1.1.1 tcp :22 produces the following message: ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters (line 13) Steven. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 09/18/2010 08:58 AM, Tom Eastep wrote:> On 09/17/2010 08:22 PM, Tom Eastep wrote: >> On 9/17/10 4:31 PM, Tom Eastep wrote: >> >>> >>> COM_IF_fwd is similar. >>> >>> I''m not sure whether or not I''ll be able to do anything about this in >>> the short term. >>> >> >> This is a natural consequence of making blacklisting a zone-related >> attribute rather than an interface-related attribute. Interface-oriented >> filtering comes first; so if more than one zone shares an >> Internet-facing interface then interface-related filtering can occur >> prior to zone-related filtering. > > I have added logic to promote jumps to ''blacklst'' ahead of > interface-specific filtering rules. See the attached output.For those of you who may be curious about COM_IF_in, the ''dmz'' zone is a *vserver* zone with vservers 172.20.1.124 and 172.20.1.125. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/18/10 9:01 AM, Steven Jan Springl wrote:> Tcfilters entry: > > eth0:33 2.2.2.2 1.1.1.1 tcp :22 > > produces the following message: > > ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters (line > 13)Thanks, Steven This should fix it. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On Saturday 18 September 2010 17:13:03 Tom Eastep wrote:> On 9/18/10 9:01 AM, Steven Jan Springl wrote: > > Tcfilters entry: > > > > eth0:33 2.2.2.2 1.1.1.1 tcp :22 > > > > produces the following message: > > > > ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters > > (line 13) > > Thanks, Steven > > This should fix it. > > -TomTom That''s fixed it. Thanks. Steven. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
>> 2. During compile I am getting this warning: >> >> Use of uninitialized value in addition (+) at >> /usr/share/shorewall/Shorewall/Chains.pm line 712. >> Use of uninitialized value in addition (+) at >> /usr/share/shorewall/Shorewall/Chains.pm line 712. >> > > The attached FROZEN.patch is a big hammer fix: > > patch /usr/share/shorewall/Shorewall/Chains.pm < FROZEN.patch >I see there are few other patches posted later - should I apply them all (including this one) or is there a ready-made rpm with all the patches (will save me the time)?> My description of what I intended to do specifically mentioned that no > warning would be issued in that case. >Read your post which just arrived - placing warning is better.> >> 5. I have both src,dst specified in the blacklist file, but when I >> specify ''net - - blacklist'' (i.e. OUT only) I am getting both blacklst >> and blackout chains with matching ipsets (it should be only the OUT >> part) and do not have a warning. >> > > Hmmm -- there is code to issue a warning; I''ll investigate further. >Apologies, I tried to reproduce this again, but I must have had a ''blacklist'' left on one of my interfaces when I tested this. Tried it again this morning and I do get the warnings and all chains are in perfect order.> >> 6. When I specify ''net - blacklist'' (i.e. IN only) I am getting the >> right result - blacklist chain with 2 references (net2fw and ethx_frwd), >> blacklist is missing and I get a warning as well, however if I have put >> the ''blacklist'' option in the fw zone (in the OPTIONS column) I get a >> ''blank'' blackout and NO warnings. I suspect I would get similar results >> when I am using other similar permutations on fw and the net zones. >> > > Again -- neither firewall nor vserver zones should be allowed the > blacklist option. >Has this been addressed? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
>> This is a natural consequence of making blacklisting a zone-related >> attribute rather than an interface-related attribute. Interface-oriented >> filtering comes first; so if more than one zone shares an >> Internet-facing interface then interface-related filtering can occur >> prior to zone-related filtering. >> > > I have added logic to promote jumps to ''blacklst'' ahead of > interface-specific filtering rules. See the attached output. >That''s good. I also tested multi-interface setup and all is well - inter-zone blacklisting works, no problem (that is something I wasn''t sure how it will pan out). SECMARKS also works - I tested it thoroughly, the only thing which I would aim to find out in the coming week or so is secmark numbers to context mapping as at present I am only guessing by looking at those numbers. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev