[ 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 18:11:14 +0100
Thanks for being more detailed, but I feel our visions are opposite.

Falcor ha scritto:
> 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.
The reference for me is always the firewall itself.
Any connection incoming is inbound, so of course any connection is 
outbound when it exits.
I've been told monowall uses ipfilter, so it's easy to think all actual 
ipf commands used for allowing access to a single address on we4 from 
other interfaces, actually:

    pass in on we0 proto tcp from any to
    pass in on we1 proto tcp from any to
    pass in on we2 proto tcp from any to
    pass in on we3 proto tcp from any to

Could be easily changed to:

    pass out on we4 proto tcp from any to

I don't see any way of making this in monowall, with the actual 
logic.For this reason I'm asking the possibility of change the logic.

> 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.
This is a good point, I cannot evaluate how strong it is. Probably an 
additional check can avoid this.
> 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; 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 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.
All this is extremely clear.
Before writing my post we (more people, not me only) evaluated the situation
Here we have also a commercial firewall, which let us detail rules as we 

    allow/deny  protocol input_interface input_network input_ports 
output_interface output_network output_ports state

We have realized monowall is using ipfilter so cannot use in the same 
statement both input_interface and output_interface. So we ask to be 
able to decide with direction we want to use.

This would make more simple a lot of things.


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

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