[ previous ] [ next ] [ threads ]
 
 From:  "Tonix (Antonio Nati)" <tonix at interazioni dot it>
 To:  daniele dot guazzoni at gcomm dot ch
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Thu, 07 Feb 2008 19:10:13 +0100
Daniele Guazzoni ha scritto:
> Tonix (Antonio Nati) wrote:
>   
>>> Let assume this scenario:
>>> - you want to allow LAN and DMZ to freely access the WAN except SMTP.
>>> - you therefore apply an outbound filter:
>>>     - deny any --> SMTP --> any
>>>     - permit any --> any
>>> - without other inbound rules on LAN and DMZ those two interfaces will
>>> be unfiltered.
>>>       
>> Where is the problem?
>> The default for any interface is: nothing can pass unless explicitely
>> admitted.
>> So, except any (but not SMTP) from (LAN + DMZ) to WAN, nothing else will
>> be allowed to pass.
>>
>>     
> And where is the saving/advantage compared to the inbound filter ?
> The saving by applying general rules outbound will be eliminated by the
> need of explicit rules on the inbound interfaces to filter the LAN <-->
> DMZ traffic.
>   

Usual end line in all firewall configurations is: *deny all from all to 
all*.

So, there is no difference in basic protection between inbound or 
outbound, as anything not permitted will be denied.

Advantage about having outbound rules consists in less rules for 
outbound connections, because you don't have to enable a service for 
each allowed incoming interface, but only one service for one outbound 
interface.

*Forget the old classic, boring model of WAN, LAN, OPT1.*

We have a lot of places with three DMZ, ten LANS, three OPT for 
exchanging with other remote LANS, so rules saved using outbound 
connections are a lot!

If we could have mixed inbound and outbound, all on one page, with ten 
rules we could do what actually needs ten rules for each interface.


>>> Another issue is the mix of outbound and inbound rules on the same
>>> interface.
>>> Doing this will make the statefull feature pretty complex or useless
>>> as one filter will be forced to put "bypass" to the other to permit
>>> statefull replies to go through.
>>> In which case you want that ? Implicit ? Only if not explicit denied ?
>>>       
>> I think that "stateful" handling means full handling of directions.
>> A connection started as incoming has nothing to do with a a connection
>> started as outgoing.
>> ipfilter handles states both for outgoing and incoming, so I hope this
>> is not a problem.
>>     
>>> I'm working since many years as security engineer and although some
>>> firewall allows to create outbound rules I don't suggest to use it.
>>>       
>> There is no problem when some outbound rules are really for all. For
>> example, when you enable a port inside a DMZ interface, that port will
>> be usually available for all interfaces, so I don't see particular
>> security risks applying an "outbound" rule over the DMZ interface.
>> If some particular address is excluded from accessing that service, put
>> an explicit deny before in the rules list.
>>     
>
> I'm not talking about risks but more about behavior.
> Of course ipfilter handles statefull in both directions but the question
> is how it handles the interaction of dynamic statefull and static filter.
> What has priority statefull or filter ?
>   

This problem is the same for inbound or outbound. If there is a risk for 
one kind, the risk is also for the other.

> However, you can swap the logic from inbound to outbound filtering but in
> my opinion you will not get a real advantage out of it.
> You simplify on one side but you burden up on the other side...
>
> And beside all discussions, inbound filtering will also protect the
> firewall itself (webinterface, services, ...)
>   

This is a fake problem. You can protect it with the same outbound rules.

Tonino

-- 
------------------------------------------------------------
        Inter@zioni            Interazioni di Antonio Nati 
   http://www.interazioni.it      tonix at interazioni dot it           
------------------------------------------------------------