On 06/03/2011 08:00 AM, Mr Dash Four wrote:

>>   
> The way I see it, this should be the very first thing done by shorewall
> - both for incoming as well as outgoing packets.
> 
> OK, I understand the case for it to be optional (it may not be suitable
> in some rare circumstances - fair enough), but the option should be
> there without the need for me (i.e. the end-user) to add a pair of rules
> in every possible xx2fw and fw2xx combination. In other words, why not
> add it as an option in the interfaces - if it is there (say as part of
> the tunX line in interfaces) insert the appropriate dropInvalid rules -
> in both directions - at the very top of their corresponding chains?
> 
> Better still, make it as shorewall.conf option and insert just one rule
> - at the top of OUTPUT and/or INPUT chains and be done with it - no need
> for messing about with rules and permutations and ask end-users to do
> this and that to "fix" it.

A couple of points:

a) It is silly to do INVALID filtering in the OUTPUT chain. If any
   INVALID packets show up there, then either the IP stack or Netfilter
   connection tracking is broken. And given the history, I would bet
   that it is the latter which is broken and that the packet should be
   sent regardless of what Netfilter thinks.

b) It is hardly onerous to be required to place this rule at the top of
   the NEW section of your rules file when you want ingress INVALID
   filtering:

        dropInvalid             all-    all

   and you can log the dropped packets if you like:

        dropInvalid:info        all-    all

   and you can audit the dropped packets if you like:

        dropInvalid(audit)      all-    all

c)  If you want finer-grained control, it's available by changing
    'all-' (all zones except the firewall) to something finer ('net',
    'net:eth0', etc.).

So having any additional controls doesn't seem to buy anything and it
costs my time.

> 
> Unfortunately I am unable to properly verify your ":(N)I" patches as I
> discovered a serious flaw on my testing harness last night (thanks in no
> small part to your patch btw) and will have to spend the weekend to fix
> that before I get to your patches. They look good and *should* be OK as
> the only thing your patches change is the addition of the "INVALID"
> state in the chain statements, which isn't really something likely to
> cause any issues, but that's me thinking and I am no expert.

It should be pretty foolproof.

-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

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to