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 | 