[ previous ] [ next ] [ threads ]
 
 From:  Falcor <falcor at netassassin dot com>
 To:  "Tonix (Antonio Nati)" <tonix at interazioni dot it>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Wed, 06 Feb 2008 10:19:41 -0600
Packets inbound to the internal interface are outbound packets.  E.g. 
going from your LAN to something else.  Likewise, so is OPT, PPTP, and 
WAN for that matter.  It all has to do with your reference point.  You 
see WAN traffic as inbound because you are thinking of being in the 
protected network.  Same rule applies for LAN traffic going to the WAN, 
for instance.  The packets are inbound from the LAN going to the WAN.  
E.g. "outbound" packets if your frame of reference is the LAN.

So if you have your LAN, WAN and OPT interfaces with rules on them, you 
are controlling traffic coming into that interface.  You never setup a 
firewall to control packets exiting an interface as that would tend to 
give opportunity to an obfuscated malformed packet to transverse your ACL.

The only thing to keep in mind is that m0n0wall reads rules from top to 
bottom.  Thus if you allow:
Protocol: *, Source LAN net; Port *; Destination Opt1 net; port * 
Protocol: TCP/UDP; Source 10.254.254.200; Port *; Destination *; Port 
6666-6667
Block Protocol: *; Source LAN net; Port *; Destination *; Port 6666-6667
Protocol: *; Source LAN net; Port *; Destination *; Port *

you just gave full access for clients on the LAN interface to access any 
client and port on the Opt interface.  You also specified that the 
client 10.254.254.200 can access any other IP on TCP/UDP ports 6666-6667 
(IRC)
You then block all other connectivity from the LAN to any other 
interface or IP in the world on those same ports.
You then allow anything not specified to work.  (Granted connectivity 
between interfaces will take specific rules like you see in the first rule.)

So in this example you granted access from the LAN to an OPT network.  
You restricted IRC connectivity to a single host, and explicitly denied 
it for any other host.  The idea is these are all "outbound" but of 
course the firewall implements the ACL at connection not transmission. 

I believe implicitly, to ease things for everyone, the LAN interface 
allows connectivity to any/all.  So creating the deny rule at the end of 
your rules would allow you to start being specific on the allows. 

Tonix (Antonio Nati) wrote:

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