As I announced yesterday on the Development List, I''ve concluded that
the direction in which blacklisting has been going since 4.4.12 is not
appropriate. The current plan for 4.4.13 is to return blacklisting to
the way it was in 4.4.11; basically, support for the OPTIONS column will
be removed.
As I''ve thought more about this issue, I have realized that the
fundamental problem with extending the 4.4.11 support is that while
blacklisting is a security-related concept, in 4.4.11 and earlier
blacklisting support has been associated with interfaces or host groups.
A much more natural approach is to associate blacklisting with zones.
I have prototyped the following proposal and it seems to work correctly.
1) The OPTIONS column of the blacklist file will be restored to the way
that it has been in the recent 4.4.13 Betas. The preferred keywords
are ''src'' and ''dst'' rather than
''from'' and ''to'' although the latter
would also be supported. Duplicates ignored with a warning.
1) Allow ''blacklist'' in the OPTIONS, IN_OPTIONS and
OUT_OPTIONS columns
of the zones file.
Specifying ''blacklist'' in OPTIONS, is equivalent to
specifying
it in both IN_OPTIONS and OUT_OPTIONS.
No warning if ''blacklist'' appears in OPTIONS as well as in
one
of the other columns.
2) ''blacklist'' in the IN_OPTIONS column indicates that all
traffic from
this zone should be passed against the ''src'' entries in
the
blacklist file.
3) ''blacklist'' in the OUT_OPTIONS column indicates that
traffic to this
zone should be passed against the ''dst'' entries in the
blacklist
file.
4) In the interfaces file:
If ''blacklist'' is specified with no ZONE, a warning is given
and the option is ignored.
If ''blacklist'' is specified with a ZONE, it is equivalent to
specifying ''blacklist'' in the IN_OPTIONS column of the
corresponding entry in the zones file.
Currently, incoming blacklisting is performed as a first step
on incoming packets on those interfaces having the
''blacklist''
option. With the new approach, blacklisting would occur after
the packet has been processed against the interface-related
options such as ''nosmurfs'', ''tcpflags'',
etc.
5) In the hosts file, the ''blacklist'' option will be ignored
with a
warning.
Comments and suggestions are welcome.
-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
As I announced yesterday on the Development List, I''ve concluded that
the direction in which blacklisting has been going since 4.4.12 is not
appropriate. The current plan for 4.4.13 is to return blacklisting to
the way it was in 4.4.11; basically, support for the OPTIONS column will
be removed.
As I''ve thought more about this issue, I have realized that the
fundamental problem with extending the 4.4.11 support is that while
blacklisting is a security-related concept, in 4.4.11 and earlier
blacklisting support has been associated with interfaces or host groups.
A much more natural approach is to associate blacklisting with zones.
I have prototyped the following proposal and it seems to work correctly.
1) The OPTIONS column of the blacklist file will be restored to the way
that it has been in the recent 4.4.13 Betas. The preferred keywords
are ''src'' and ''dst'' rather than
''from'' and ''to'' although the latter
would also be supported. Duplicates ignored with a warning.
1) Allow ''blacklist'' in the OPTIONS, IN_OPTIONS and
OUT_OPTIONS columns
of the zones file.
Specifying ''blacklist'' in OPTIONS, is equivalent to
specifying
it in both IN_OPTIONS and OUT_OPTIONS.
No warning if ''blacklist'' appears in OPTIONS as well as in
one
of the other columns.
2) ''blacklist'' in the IN_OPTIONS column indicates that all
traffic from
this zone should be passed against the ''src'' entries in
the
blacklist file.
3) ''blacklist'' in the OUT_OPTIONS column indicates that
traffic to this
zone should be passed against the ''dst'' entries in the
blacklist
file.
4) In the interfaces file:
If ''blacklist'' is specified with no ZONE, a warning is given
and the option is ignored.
If ''blacklist'' is specified with a ZONE, it is equivalent to
specifying ''blacklist'' in the IN_OPTIONS column of the
corresponding entry in the zones file.
Currently, incoming blacklisting is performed as a first step
on incoming packets on those interfaces having the
''blacklist''
option. With the new approach, blacklisting would occur after
the packet has been processed against the interface-related
options such as ''nosmurfs'', ''tcpflags'',
etc.
5) In the hosts file, the ''blacklist'' option will be ignored
with a
warning.
Comments and suggestions are welcome.
-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
Somewhat related, I''d like to see a much more lightweight combination of blacklisting and the "drop" feature. Here''s why... As the day(s) go(es) on I will see activity in my logs which I just don''t like and I will typically just log onto the shorewall-lite machine and do a "shorewall drop ..." on the host. The problem is of course that that''s only temporary -- until the next rule load/reload/restore, etc. The other option is to add to the blacklist and then "shorewall reload gateway". That''s permanent, but a "heavy" operation (compared to just shorewall-lite drop ...), but also, it''s only valid until the gateway does a reload/restore, etc., unless I also issue a shorewall-lite save on the gateway. So either way I have to log into the gateway, which I''d like to avoid and I''d also like to avoid the heavy operation of editing a file and a full reload just to blacklist. What I think would be nice is a "shorewall blacklist <ip>" command that simply populates a table on a running shorewall[-lite] system (like drop does currently) but also stores that IP (on the the shorewall-lite system if that''s the case) where a restore/restart reads the list and applies them to the blacklist. This way I get permanence, light-weight additions and additions that can be done without visiting the shorewall-lite machine. Thots? b. ------------------------------------------------------------------------------ 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/16/10 9:42 AM, Brian J. Murrell wrote:> What I think would be nice is a "shorewall blacklist <ip>" command that > simply populates a table on a running shorewall[-lite] system (like drop > does currently) but also stores that IP (on the the shorewall-lite > system if that''s the case) where a restore/restart reads the list and > applies them to the blacklist. > > This way I get permanence, light-weight additions and additions that can > be done without visiting the shorewall-lite machine. > > Thots?The dynamic blacklist has been preserved across stop/start and restart since 4.4.11. -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/16/10 10:17 AM, Tom Eastep wrote:> On 9/16/10 9:42 AM, Brian J. Murrell wrote: > >> What I think would be nice is a "shorewall blacklist <ip>" command that >> simply populates a table on a running shorewall[-lite] system (like drop >> does currently) but also stores that IP (on the the shorewall-lite >> system if that''s the case) where a restore/restart reads the list and >> applies them to the blacklist. >> >> This way I get permanence, light-weight additions and additions that can >> be done without visiting the shorewall-lite machine. >> >> Thots? > > The dynamic blacklist has been preserved across stop/start and restart > since 4.4.11.My bad -- it''s only preserved across restart. But it is easy to extend it to stop as well. -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 Thu, 2010-09-16 at 10:17 -0700, Tom Eastep wrote:> > The dynamic blacklist has been preserved across stop/start and restart > since 4.4.11.Is the importance of 4.4.11 here on the master or the shorewall-lite machine, or both? b. ------------------------------------------------------------------------------ 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/16/2010 10:57 AM, Brian J. Murrell wrote:> On Thu, 2010-09-16 at 10:17 -0700, Tom Eastep wrote: >> >> The dynamic blacklist has been preserved across stop/start and restart >> since 4.4.11. > > Is the importance of 4.4.11 here on the master or the shorewall-lite > machine, or both? > > b.The administrative machine. But again, the dynamic blacklist is currently only preserved across ''restart'' and ''refresh''. -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/16/10 11:22 AM, Tom Eastep wrote:> On 09/16/2010 10:57 AM, Brian J. Murrell wrote: >> On Thu, 2010-09-16 at 10:17 -0700, Tom Eastep wrote: >>> >>> The dynamic blacklist has been preserved across stop/start and restart >>> since 4.4.11. >> >> Is the importance of 4.4.11 here on the master or the shorewall-lite >> machine, or both? >> >> b. > > The administrative machine. But again, the dynamic blacklist is currently > only preserved across ''restart'' and ''refresh''.This patchlet seems to allow the blacklist to be preserved over start/stop. -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/16/10 11:51 AM, Tom Eastep wrote:> On 9/16/10 11:22 AM, Tom Eastep wrote: >> On 09/16/2010 10:57 AM, Brian J. Murrell wrote: >>> On Thu, 2010-09-16 at 10:17 -0700, Tom Eastep wrote: >>>> >>>> The dynamic blacklist has been preserved across stop/start and restart >>>> since 4.4.11. >>> >>> Is the importance of 4.4.11 here on the master or the shorewall-lite >>> machine, or both? >>> >>> b. >> >> The administrative machine. But again, the dynamic blacklist is currently >> only preserved across ''restart'' and ''refresh''. > > This patchlet seems to allow the blacklist to be preserved over start/stop.There''s an obvious problem with the patchlet and IPV6 -- the ''else'' part should have ''IP6TABLES'' rather than ''IPTABLES''. -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 Would it be possible/practical to implement blacklisting using ipset, if it is available. This should enable people to have a large number of entries in their blacklist without causing performance issues. 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/16/10 3:07 PM, Steven Jan Springl wrote:> Tom > > Would it be possible/practical to implement blacklisting using ipset, if it is > available. > This should enable people to have a large number of entries in their blacklist > without causing performance issues.Steven, It''s already supported. Just put +<ipset name> in the first column. Regards, -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 Thursday 16 September 2010 23:15:11 Tom Eastep wrote:> On 9/16/10 3:07 PM, Steven Jan Springl wrote: > > Tom > > > > Would it be possible/practical to implement blacklisting using ipset, if > > it is available. > > This should enable people to have a large number of entries in their > > blacklist without causing performance issues. > > Steven, > > It''s already supported. Just put +<ipset name> in the first column. > > Regards, > -TomTom I was thinking of automatically loading any IP addresses that are specified in the first column into an ipset, but with the existing ipset implementation it''s probably not worth the effort. 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/16/2010 03:23 PM, Steven Jan Springl wrote:> > I was thinking of automatically loading any IP addresses that are specified in > the first column into an ipset, but with the existing ipset implementation > it''s probably not worth the effort.I don''t think that it is. Note, though, since ADD and DEL rules are now supported in /etc/shorewall/rules, it is possible to write rules that add an IP address to a blacklisting ipset before dropping or rejecting the connection request. I could add to my list of things to do to allow ADD and DEL in Actions; that would make such multi-step operations involving ADD or DEL more efficient. -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/16/10 9:20 AM, Tom Eastep wrote:> > 5) In the hosts file, the ''blacklist'' option will be ignored with a > warning.In looking over sample user configurations, I think that it is more appropriate to handle ''blacklist'' the same in the hosts file as it is handled in the interfaces file. Any opinions? -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
> As I announced yesterday on the Development List, I''ve concluded that > the direction in which blacklisting has been going since 4.4.12 is not > appropriate. The current plan for 4.4.13 is to return blacklisting to > the way it was in 4.4.11; basically, support for the OPTIONS column will > be removed. > > As I''ve thought more about this issue, I have realized that the > fundamental problem with extending the 4.4.11 support is that while > blacklisting is a security-related concept, in 4.4.11 and earlier > blacklisting support has been associated with interfaces or host groups. > A much more natural approach is to associate blacklisting with zones. >I concur! Also, you could always add support (if it doesn''t already exist - I am no Shorewall expert) to include individual interfaces from each zone, like "net:eth1" for example.> I have prototyped the following proposal and it seems to work correctly. > > 1) The OPTIONS column of the blacklist file will be restored to the way > that it has been in the recent 4.4.13 Betas. The preferred keywords > are ''src'' and ''dst'' rather than ''from'' and ''to'' although the latter > would also be supported. Duplicates ignored with a warning. >Makes sense and it was the way I preferred - it makes it consistent with the rest (rules etc).> 1) Allow ''blacklist'' in the OPTIONS, IN_OPTIONS and OUT_OPTIONS columns > of the zones file. > > Specifying ''blacklist'' in OPTIONS, is equivalent to specifying > it in both IN_OPTIONS and OUT_OPTIONS. >So, if I specify ''blacklist'' in my net zone then it would automatically be bidirectional provided I have "+backlist-nets src,dst" in my blacklist file, right? If so, that would be perfect.> 4) In the interfaces file: > > If ''blacklist'' is specified with no ZONE, a warning is given > and the option is ignored. > > If ''blacklist'' is specified with a ZONE, it is equivalent to > specifying ''blacklist'' in the IN_OPTIONS column of the > corresponding entry in the zones file. > > Currently, incoming blacklisting is performed as a first step > on incoming packets on those interfaces having the ''blacklist'' > option. With the new approach, blacklisting would occur after > the packet has been processed against the interface-related > options such as ''nosmurfs'', ''tcpflags'', etc. >Is there any reason for this? For me it would not make sense to do ANY processing (ddos etc) if this packet is/has failed the blacklist test. ------------------------------------------------------------------------------ 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 > > I was thinking of automatically loading any IP addresses that are specified in > the first column into an ipset, but with the existing ipset implementation > it''s probably not worth the effort. >If you look through some of my earlier posts in shorewall-users you will find my init script, which, when executed (it does so automatically when Shorewall starts/stops/reloads etc) loads up my ipsets from a resource files. I would have posted the script here, but do not have it handy (away from my testing machine today). ------------------------------------------------------------------------------ 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
>> 5) In the hosts file, the ''blacklist'' option will be ignored with a >> warning. >> > > In looking over sample user configurations, I think that it is more > appropriate to handle ''blacklist'' the same in the hosts file as it is > handled in the interfaces file. > > Any opinions? >In other words - ignored? ------------------------------------------------------------------------------ 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/16/10 4:30 PM, Mr Dash Four wrote:> >>> 5) In the hosts file, the ''blacklist'' option will be ignored with a >>> warning. >>> >> >> In looking over sample user configurations, I think that it is more >> appropriate to handle ''blacklist'' the same in the hosts file as it is >> handled in the interfaces file. >> >> Any opinions? >> > In other words - ignored?No -- treat it as if ''blacklist'' had been specified in the IN_OPTIONS column in the associated entry in /etc/shorewall/zones. -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/16/10 4:24 PM, Mr Dash Four wrote:> >> As I announced yesterday on the Development List, I''ve concluded that >> the direction in which blacklisting has been going since 4.4.12 is not >> appropriate. The current plan for 4.4.13 is to return blacklisting to >> the way it was in 4.4.11; basically, support for the OPTIONS column will >> be removed. >> >> As I''ve thought more about this issue, I have realized that the >> fundamental problem with extending the 4.4.11 support is that while >> blacklisting is a security-related concept, in 4.4.11 and earlier >> blacklisting support has been associated with interfaces or host groups. >> A much more natural approach is to associate blacklisting with zones. >> > I concur! Also, you could always add support (if it doesn''t already > exist - I am no Shorewall expert) to include individual interfaces from > each zone, like "net:eth1" for example. > >> I have prototyped the following proposal and it seems to work correctly. >> >> 1) The OPTIONS column of the blacklist file will be restored to the way >> that it has been in the recent 4.4.13 Betas. The preferred keywords >> are ''src'' and ''dst'' rather than ''from'' and ''to'' although the latter >> would also be supported. Duplicates ignored with a warning. >> > Makes sense and it was the way I preferred - it makes it consistent with > the rest (rules etc). > >> 1) Allow ''blacklist'' in the OPTIONS, IN_OPTIONS and OUT_OPTIONS columns >> of the zones file. >> >> Specifying ''blacklist'' in OPTIONS, is equivalent to specifying >> it in both IN_OPTIONS and OUT_OPTIONS. >> > So, if I specify ''blacklist'' in my net zone then it would automatically > be bidirectional provided I have "+backlist-nets src,dst" in my > blacklist file, right? If so, that would be perfect.That''s the plan.> >> 4) In the interfaces file: >> >> If ''blacklist'' is specified with no ZONE, a warning is given >> and the option is ignored. >> >> If ''blacklist'' is specified with a ZONE, it is equivalent to >> specifying ''blacklist'' in the IN_OPTIONS column of the >> corresponding entry in the zones file. >> >> Currently, incoming blacklisting is performed as a first step >> on incoming packets on those interfaces having the ''blacklist'' >> option. With the new approach, blacklisting would occur after >> the packet has been processed against the interface-related >> options such as ''nosmurfs'', ''tcpflags'', etc. >> > Is there any reason for this? For me it would not make sense to do ANY > processing (ddos etc) if this packet is/has failed the blacklist test.It''s a consequence of the order in which the ruleset is constructed. Interface-oriented filtering is generated well before zone-oriented filtering. During optimization, interface-oriented filtering can be moved to the front of a zone-oriented chain. It''s something that could be overcome but it''s not trivial. -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
>>> 4) In the interfaces file: >>> >>> If ''blacklist'' is specified with no ZONE, a warning is given >>> and the option is ignored. >>> >>> If ''blacklist'' is specified with a ZONE, it is equivalent to >>> specifying ''blacklist'' in the IN_OPTIONS column of the >>> corresponding entry in the zones file. >>> >>> Currently, incoming blacklisting is performed as a first step >>> on incoming packets on those interfaces having the ''blacklist'' >>> option. With the new approach, blacklisting would occur after >>> the packet has been processed against the interface-related >>> options such as ''nosmurfs'', ''tcpflags'', etc. >>> >>> >> Is there any reason for this? For me it would not make sense to do ANY >> processing (ddos etc) if this packet is/has failed the blacklist test. >> > > It''s a consequence of the order in which the ruleset is constructed. > Interface-oriented filtering is generated well before zone-oriented > filtering. During optimization, interface-oriented filtering can be > moved to the front of a zone-oriented chain. It''s something that could > be overcome but it''s not trivial. >Bugger! I can see a potential for some really nasty stuff coming from this. Is there absolutely no chance that the blacklist processing could be moved forward, somehow? ------------------------------------------------------------------------------ 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 Eastep wrote:> On 9/16/10 4:30 PM, Mr Dash Four wrote: > >>>> 5) In the hosts file, the ''blacklist'' option will be ignored with a >>>> warning. >>>> >>>> >>> In looking over sample user configurations, I think that it is more >>> appropriate to handle ''blacklist'' the same in the hosts file as it is >>> handled in the interfaces file. >>> >>> Any opinions? >>> >>> >> In other words - ignored? >> > > No -- treat it as if ''blacklist'' had been specified in the IN_OPTIONS > column in the associated entry in /etc/shorewall/zones. >Makes sense. ------------------------------------------------------------------------------ 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/16/10 4:53 PM, Mr Dash Four wrote:> >>>> 4) In the interfaces file: >>>> >>>> If ''blacklist'' is specified with no ZONE, a warning is given >>>> and the option is ignored. >>>> >>>> If ''blacklist'' is specified with a ZONE, it is equivalent to >>>> specifying ''blacklist'' in the IN_OPTIONS column of the >>>> corresponding entry in the zones file. >>>> >>>> Currently, incoming blacklisting is performed as a first step >>>> on incoming packets on those interfaces having the ''blacklist'' >>>> option. With the new approach, blacklisting would occur after >>>> the packet has been processed against the interface-related >>>> options such as ''nosmurfs'', ''tcpflags'', etc. >>>> >>>> >>> Is there any reason for this? For me it would not make sense to do ANY >>> processing (ddos etc) if this packet is/has failed the blacklist test. >>> >> >> It''s a consequence of the order in which the ruleset is constructed. >> Interface-oriented filtering is generated well before zone-oriented >> filtering. During optimization, interface-oriented filtering can be >> moved to the front of a zone-oriented chain. It''s something that could >> be overcome but it''s not trivial. >> > Bugger! I can see a potential for some really nasty stuff coming from > this. Is there absolutely no chance that the blacklist processing could > be moved forward, somehow?I don''t think that the consequences could be that dire (a blacklisted host could renew its DHCP lease is the only hole I can see), but it is not horribly difficult to remove this restriction. -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/16/10 5:58 PM, Tom Eastep wrote:> On 9/16/10 4:53 PM, Mr Dash Four wrote: >> >>>>> 4) In the interfaces file: >>>>> >>>>> If ''blacklist'' is specified with no ZONE, a warning is given >>>>> and the option is ignored. >>>>> >>>>> If ''blacklist'' is specified with a ZONE, it is equivalent to >>>>> specifying ''blacklist'' in the IN_OPTIONS column of the >>>>> corresponding entry in the zones file. >>>>> >>>>> Currently, incoming blacklisting is performed as a first step >>>>> on incoming packets on those interfaces having the ''blacklist'' >>>>> option. With the new approach, blacklisting would occur after >>>>> the packet has been processed against the interface-related >>>>> options such as ''nosmurfs'', ''tcpflags'', etc. >>>>> >>>>> >>>> Is there any reason for this? For me it would not make sense to do ANY >>>> processing (ddos etc) if this packet is/has failed the blacklist test. >>>> >>> >>> It''s a consequence of the order in which the ruleset is constructed. >>> Interface-oriented filtering is generated well before zone-oriented >>> filtering. During optimization, interface-oriented filtering can be >>> moved to the front of a zone-oriented chain. It''s something that could >>> be overcome but it''s not trivial. >>> >> Bugger! I can see a potential for some really nasty stuff coming from >> this. Is there absolutely no chance that the blacklist processing could >> be moved forward, somehow? > > I don''t think that the consequences could be that dire (a blacklisted > host could renew its DHCP lease is the only hole I can see), but it is > not horribly difficult to remove this restriction.Okay -- I think I have this working. I propose that we have one more 4.4.13 Beta that includes this new blacklisting implementation, and then I''ll produce 4.4.13 RC 1. Any objections? -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
>> Bugger! I can see a potential for some really nasty stuff coming from >> this. Is there absolutely no chance that the blacklist processing could >> be moved forward, somehow? >> > > I don''t think that the consequences could be that dire (a blacklisted > host could renew its DHCP lease is the only hole I can see), but it is > not horribly difficult to remove this restriction. >If there is ''processing'' before ''checking'' this could potentially be exploited (dos and ddos attacks is what I am thinking of). If you could, somehow, manage to put ''checking'' before ''processing'' that would be ideal, but if you can''t you need to clearly explain this (in a note possibly) in one of the man pages so that everybody is clear what is happening. ------------------------------------------------------------------------------ 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 7:04 AM, Mr Dash Four wrote:> >>> Bugger! I can see a potential for some really nasty stuff coming from >>> this. Is there absolutely no chance that the blacklist processing could >>> be moved forward, somehow? >>> >> >> I don''t think that the consequences could be that dire (a blacklisted >> host could renew its DHCP lease is the only hole I can see), but it is >> not horribly difficult to remove this restriction. >> > If there is ''processing'' before ''checking'' this could potentially be > exploited (dos and ddos attacks is what I am thinking of). If you could, > somehow, manage to put ''checking'' before ''processing'' that would be > ideal, but if you can''t you need to clearly explain this (in a note > possibly) in one of the man pages so that everybody is clear what is > happening. >Please see my later email. -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
> Okay -- I think I have this working. > > I propose that we have one more 4.4.13 Beta that includes this new > blacklisting implementation, and then I''ll produce 4.4.13 RC 1. > > Any objections? >No objections from me as the blacklist issue is the only thing which needs to be tested - I''ve tested the SELinux context features and they work as they were supposed to (I might have something on deciphering the number behind secmark=xxx next week - will post it here). Just a note of caution which you may put against the explanation for SAVE and RESTORE, particularly if there are additional restrictions in place (like IP addresses, port numbers etc) or multiple SAVE/RESTORE statements in any particular chains - it is very easy when SAVE xx.xx.xx.xx 22 and then RESTORE is issued to assume that the correct context has been restored. The SAVE and RESTORE will only be activated (executed) if the additional parameters after those statements match, otherwise nothing happens (and the correct SELinux context might not be saved/restored). I know it may be blatantly obvious for some, but I''ve made these mistakes until I learned the right way, so it is better to point these things out to save others (pun intended). That is one of the reasons I use a ''blank'' SAVE and a ''blank'' RESTORE at the end of each chain, so that no matter what SELinux context has been set it is always saved (even if it is not set it does NO harm whatsoever for it to be ''saved'') and then restored. Just thought that needs to be emphasised when SAVE/RESTORE are explained in the man page file. Another little note for a minor annoyance - in almost all of your man pages your left alignment is off - every so often when you list parameters/columns the left margin gets bigger and bigger, fitting less information on a line - though you may want to know that. ------------------------------------------------------------------------------ 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
>> If there is ''processing'' before ''checking'' this could potentially be >> exploited (dos and ddos attacks is what I am thinking of). If you could, >> somehow, manage to put ''checking'' before ''processing'' that would be >> ideal, but if you can''t you need to clearly explain this (in a note >> possibly) in one of the man pages so that everybody is clear what is >> happening. >> >> > > Please see my later email. >So this is fixed then for the new Beta? ------------------------------------------------------------------------------ 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 7:29 AM, Mr Dash Four wrote:> >>> If there is ''processing'' before ''checking'' this could potentially be >>> exploited (dos and ddos attacks is what I am thinking of). If you could, >>> somehow, manage to put ''checking'' before ''processing'' that would be >>> ideal, but if you can''t you need to clearly explain this (in a note >>> possibly) in one of the man pages so that everybody is clear what is >>> happening. >>> >>> >> >> Please see my later email. >> > So this is fixed then for the new Beta?Yes. -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 7:25 AM, Mr Dash Four wrote:> >> Okay -- I think I have this working. >> >> I propose that we have one more 4.4.13 Beta that includes this new >> blacklisting implementation, and then I''ll produce 4.4.13 RC 1. >> >> Any objections? >> > No objections from me as the blacklist issue is the only thing which > needs to be tested - I''ve tested the SELinux context features and they > work as they were supposed to (I might have something on deciphering the > number behind secmark=xxx next week - will post it here). > > Just a note of caution which you may put against the explanation for > SAVE and RESTORE, particularly if there are additional restrictions in > place (like IP addresses, port numbers etc) or multiple SAVE/RESTORE > statements in any particular chains - it is very easy when SAVE > xx.xx.xx.xx 22 and then RESTORE is issued to assume that the correct > context has been restored. The SAVE and RESTORE will only be activated > (executed) if the additional parameters after those statements match, > otherwise nothing happens (and the correct SELinux context might not be > saved/restored). I know it may be blatantly obvious for some, but I''ve > made these mistakes until I learned the right way, so it is better to > point these things out to save others (pun intended). > > That is one of the reasons I use a ''blank'' SAVE and a ''blank'' RESTORE at > the end of each chain, so that no matter what SELinux context has been > set it is always saved (even if it is not set it does NO harm whatsoever > for it to be ''saved'') and then restored. > > Just thought that needs to be emphasised when SAVE/RESTORE are explained > in the man page file. > > Another little note for a minor annoyance - in almost all of your man > pages your left alignment is off - every so often when you list > parameters/columns the left margin gets bigger and bigger, fitting less > information on a line - though you may want to know that.The manpages (like all of the Shorewall documentation) are maintained in XML Docbook; the available xml to manpage translators suck. -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
> The manpages (like all of the Shorewall documentation) are maintained in > XML Docbook; the available xml to manpage translators suck. >What translator have you been using? ------------------------------------------------------------------------------ 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 8:01 AM, Mr Dash Four wrote:> >> The manpages (like all of the Shorewall documentation) are maintained in >> XML Docbook; the available xml to manpage translators suck. >> > What translator have you been using?I''m currently using xmlto 0.23. -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 8:20 AM, Tom Eastep wrote:> On 9/17/10 8:01 AM, Mr Dash Four wrote: >> >>> The manpages (like all of the Shorewall documentation) are maintained in >>> XML Docbook; the available xml to manpage translators suck. >>> >> What translator have you been using? > > I''m currently using xmlto 0.23.Hmm -- I have been building Shorewall recently on my MacBook; if I build it on a system running Lenny (xmlto 0.0.20-5), the margins look better. -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 8:34 AM, Tom Eastep wrote:> On 9/17/10 8:20 AM, Tom Eastep wrote: >> On 9/17/10 8:01 AM, Mr Dash Four wrote: >>> >>>> The manpages (like all of the Shorewall documentation) are maintained in >>>> XML Docbook; the available xml to manpage translators suck. >>>> >>> What translator have you been using? >> >> I''m currently using xmlto 0.23. > > Hmm -- I have been building Shorewall recently on my MacBook; if I build > it on a system running Lenny (xmlto 0.0.20-5), the margins look better.Although xmlto is just a front-end for xsltproc and friends; that''s were the issue probably lies. -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
> I''m currently using xmlto 0.23. >I am in no way an expert, but quick look on Google suggests "docbook2x-man - Convert DocBook to man pages" (http://manpages.ubuntu.com/manpages/lucid/man1/docbook2x-man.1.html) - it seems highly customisable and you could define your own xslt style sheet. Don''t know whether you have tried it or whether it is any good... ------------------------------------------------------------------------------ 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 09:53 AM, Mr Dash Four wrote:> >> I''m currently using xmlto 0.23. >> > I am in no way an expert, but quick look on Google suggests > "docbook2x-man - Convert DocBook to man pages" > (http://manpages.ubuntu.com/manpages/lucid/man1/docbook2x-man.1.html) - > it seems highly customisable and you could define your own xslt style > sheet. Don''t know whether you have tried it or whether it is any good...I used docbook2x before switching to xmlto -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
>> Hmm -- I have been building Shorewall recently on my MacBook; if I build >> it on a system running Lenny (xmlto 0.0.20-5), the margins look better. >> > > Although xmlto is just a front-end for xsltproc and friends; that''s were > the issue probably lies. >I am not familiar with the man page format, but in the xml/xslt world you are king - you can twist and turn every single aspect of the xml document tree. I also see that Docbook uses the FOP library, which even though is a bit tedious to work with, it gives you great control over the format and layout of a page, but I guess at the end it all depends on how all this is translated into a man page... ------------------------------------------------------------------------------ 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
> I used docbook2x before switching to xmlto >So, it was crap I take it then? ------------------------------------------------------------------------------ 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 10:11 AM, Mr Dash Four wrote:> >> I used docbook2x before switching to xmlto >> > So, it was crap I take it then?Yes -- it had a similar 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:59 AM, Mr Dash Four wrote:> >>> Hmm -- I have been building Shorewall recently on my MacBook; if I build >>> it on a system running Lenny (xmlto 0.0.20-5), the margins look better. >>> >> >> Although xmlto is just a front-end for xsltproc and friends; that''s were >> the issue probably lies. >> > I am not familiar with the man page format, but in the xml/xslt world > you are king - you can twist and turn every single aspect of the xml > document tree. I also see that Docbook uses the FOP library, which even > though is a bit tedious to work with, it gives you great control over > the format and layout of a page, but I guess at the end it all depends > on how all this is translated into a man page...I''ll just build releases on a linux box for the time being; I''ve been using the MacBook because it is fast and quiet (My Lenny box is a 3.4Gz P4 and during XML->man/html conversions, the CPU fan sounds like a B-29). -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
> I''ll just build releases on a linux box for the time being; I''ve been > using the MacBook because it is fast and quiet (My Lenny box is a 3.4Gz > P4 and during XML->man/html conversions, the CPU fan sounds like a B-29). >This is what my Thinkpad 600E (one of my dmz machines) does when loading all of my banned ipsets (I prepare these by a weekly cron job from the ip-to-country database and distribute them to all my machines). Anyway, Beta6 bugs coming up... ------------------------------------------------------------------------------ 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