[ previous ] [ next ] [ threads ]
 
 From:  Falcor <falcor at netassassin dot com>
 To:  "Tonix (Antonio Nati)" <tonix at interazioni dot it>
 Cc:  sai <sonicsai at gmail dot com>, m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Wed, 06 Feb 2008 08:06:18 -0600
KISS... the firewall already does inbound and outbound rules. Just as it 
does inbound and outbound NAT, PAT, etc. 

Why you would want to co mingle your inbound and outbound rules onto one 
page is beyond me.  Outbound rules are on the LAN.  These should be 
simple in most cases.  Either you are going to have a restrictive 
environment where you block all but a few ports.  E.g. write a few allow 
rules and then a catch-all of "block everything."  Or, you have a 
"business normal" outbound rule set where you block everything except 
port 80, and TCP high ports like most businesses do.  Or, allow 
everything out but only block a few specific things like SMB, IRC, etc 
that may be used in a worm or virus and only allow some systems to use 
those ports.  If you have something other than this, you are the one-off 
and the interface shouldn't be designed around you. 

The greater number of people will be able to logically track the rules 
if the interface is setup like it is.  E.g. If average Joe is trying to 
get his PPTP network to have SSH access only to his LAN network he can 
understand you have to make a rule on the PPTP interface permitting 
access to the LAN.  Combining things could very easily confuse people 
who don't understand state and ACLs in general.  You could end up with 
many superfluous rules allowing return packets and everything else thus 
adding lines of ACLs to the firewall and impacting its performance, 
opening you up to security issues, etc. 

Tonix (Antonio Nati) wrote:

> I do not agree. What I propose is more simple and more secure.
>
> You can have two ways of developing it:
>
> 1) add an option to change behaviour, from incoming to outgoing
> Very easy, all "incoming" is changed to "outgoing". Same architecture, 
> same screens, same forms, just one more flag in system setup.
> No security risks. More simple to manage for complex environments, so 
> even more secure than before.
>
> 2) add a mixed (incoming + outgoing) feature.
> In such a case you must have only one rule page for all interfaces 
> (instead of one rule page for each interface), where you put in the 
> order you need both "incoming" and "outgoing" rules.
> With such single page, you can easily manage all the firewall, 
> deciding where to apply incoming and where to apply outgoing.
> This would permit to have very few rules for all the system, where now 
> we are forced to have hundreds of rules replicated for every interface.
>
> I feel both of these two proposal improve security, and they transform 
> monowall in a firewall able to handle also complex corporate 
> environments with more easyness and less risks.
>
> Tonino
>
> sai ha scritto:
>
>> Security and simplicity go together. If your ruleset is very complex,
>> then you will have difficulties in managing it and debugging it.
>>
>> If you have incoming rules as well as outgoing rules, the ruleset will
>> become very complex (and we dont know what the impact on performance
>> will be).
>> The current system means that it is easy to understand the ruleset
>> applied to any interface. It may be administratively problematic with
>> lots of typing and duplication but from a security point of view it is
>> good.
>>
>> sai
>>
>>
>> On 2/5/08, Tonix (Antonio Nati) <tonix at interazioni dot it> wrote:
>>  
>>
>>> We are thinking how to extend/improve m0n0wall rules architecture.
>>> After an intense work done with rules, we finally realize we need
>>> something actual m0n0wall architecture cannot satisfy.
>>>
>>> Given our environment, with dozen of reserved VLAN and a few of servers
>>> VLAN, actual m0n0wall behaviour of applying rules to "incoming"
>>> interfaces forces us to apply same rules to dozens of VLAN, while rules
>>> eventually applied to "outgoing" interfaces could be a lot more easy to
>>> manage.
>>>
>>> Planning to put hands in code, we are thinking to add a system flag
>>> (enable rules on output interfaces) and change rules to outgoing
>>> interfaces if that flag is enabled.
>>>
>>> Obviouslly it would be better to have rules working both on "incoming
>>> interfaces" and "outgoing interfaces", but it looks not easy to make
>>> with ipfilter.
>>>
>>> Thanks for any comment/hint.
>>>
>>> Tonino
>>>
>>> -- 
>>> ------------------------------------------------------------
>>>         Inter@zioni            Interazioni di Antonio Nati
>>>    http://www.interazioni.it      tonix at interazioni dot it
>>> ------------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
>>> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch
>>>
>>>
>>>     
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
>> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch
>>
>>
>>   
>
>
>