[ previous ] [ next ] [ threads ]
 
 From:  Lee Sharp <leesharp at hal dash pc dot org>
 To:  Mono Dev List <m0n0wall dash dev at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Thu, 07 Feb 2008 13:20:55 -0600
Tonix (Antonio Nati) wrote:
> If monowall people is so closely bind to the WAN, LAN, OPT1 model, there 
> is very few to discuss. Then it's time to start a m1n1 project, with 
> wider views.

I am not sure where you got this, but it ain't from us.  Many of the 
core people on this list have at least one (or many more) firewall with 
10+ interfaces on it.  However we often support people that have 
multiple interfaces for absolutely no reason.  One guy wanted to bridge 
5 interfaces because he could not afford a switch!  So we teach the LAN 
WAN Opt1 model to beginners because they are beginners.  We also use the 
inbound model because it is simple to understand.  Complexity breads 
mistakes which lead to insecurity.  The Pix is a very secure firewall, 
but is often deployed insecurely by people who do not understand it. 
Not a surprise as the Pix is a lesson in user unfriendliness...

> But if you consider that this firewall is very used because of the 
> speed, and because of the speed is used in a lot of big configurations, 
> where people has:

[snip vlan party]

> than you may see that
> 
>    * ONE  outbound rule written in the server VLAN eliminates the need
>      for other 11 rules which should be written in each of the other
>      interfaces.

Only if all other interfaces are wide open inbound.  This is not what I 
do on any system I manage.

>    * ONE outbound rule written in the Internet VLAN solves the same problem

Unless you want the viruses infected guests in the lobby to have 
different internet access than the mail servers.  No, I don't see any 
problem here. :)  They could never get your company put into a spam 
block list. (Happened to a client last week, actually.  I may make a 
tidy sum from that.)

>    * TWO deny inbound and outbound rules on Wi-Fi eliminates ANY
>      security issues about Wi-Fi

http://www.cavebear.com/archive/cavebear/catalogue/firewall.html
:)

> With a few inbound and outbound rules you solve any problem. All in one 
> page, for a complex situation.

One page is a poor way to display any complex solution.  Unless you are 
doing some rule aggregation, which could still be done in the existing 
framework.

> Try to make the same only with inbounds rules!!!!!!

Now add some VPN tunnels.  These only filter inbound on the remote end. 
    And I see a lot more VPN here than vlan...  Of course that could be 
because people have more trouble with vpn than vlan... :)

> I hope monowall is ready to make the step to be a more complete firewall.

We have made a conscious decision to not make m0n0wall the HP 
All-In-One-Printer of firewalls.  m0n0wall is meant to be lean, mean, 
and above all secure.  So far what you have proposed gives some small 
convenience at a substantial cost in complexity and security.

However, the biggest problem is that you seem to not want to consider 
that there are other ways of doing this.  It would be easy to add a 
script on each interface page, "Create reciprocal inbound rules."  When 
you click that it gives all the usual fields but the interface field 
would allow you to ctl-click all or some of the interfaces.  As to 
management, I agree that a page that would allow you to view all 
interfaces filtered by a given parameter would be nice.  This only 
requires some php programming, and NO CHANGES TO THE CORE OF M0N0WALL. 
Also there is a m0n0wall management project that could allow you to 
write a firewall client to make rules however you want them. However, if 
you are dead set on core changes, then by all means fork it.  There are 
several forks of m0n0wall, and all have made a positive contribution. 
(FreeNAS, pfSense, AskoziaPBX)  You can even find the devs of those 
projects all over the m0n0wall lists.  You may have something a lot of 
other people want.  I, however, am not one of them.  And judging by the 
lack response here, neither are a lot of other developers.  However, (I 
seem to be using that word a lot) if you do fork the project, I would 
give you any information and help that I could.  I am sure that most of 
the other people here would as well, if you keep us on good terms.

			Lee