[ previous ] [ next ] [ threads ]
 
 From:  "Tonix (Antonio Nati)" <tonix at interazioni dot it>
 To:  Falcor <falcor at netassassin dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Wed, 06 Feb 2008 16:34:22 +0100
I'm really surprised ... It looks like we are speaking of completely 
different products...

Falcor ha scritto:
> KISS... the firewall already does inbound and outbound rules. Just as 
> it does inbound and outbound NAT, PAT, etc.
In the page where you add/edit a rule, near the interface field, you can 
read:

*    "Choose on which interface packets must come in to match this rule."
*
This means monowall is going to handle only incoming connections (and is 
not handling connections outgoing from that interface).
So, why are you saying firewall does handle outbound?
If you don't now what I'm speaking about, please avoid! Don't think your 
limits are everyone limits!

> 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.
Please set up this filter with the minimum rules possible. This is a 
very simple network, so it is not a personal case.

    Interface A: sub-net, no NAT
    Interface B: sub-net, no NAT
    Interface C: sub-net, no NAT
    Interface D, sub-net, no NAT
    Interface E, sub-net, no NAT

None can access sub-lans in A,B,C,D.
Anyone can access any port 80 in interface E.

Actually you must add one inbound rule for every A, B, C, D interface. 
With outbound rules only one rule on Interface E would handle the situation.
I hope you now understand the big limits involved in the actual 
implementation of rules.

Tonino
> 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
>>>
>>>
>>>   
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>


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