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 \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
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
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to