[ previous ] [ next ] [ threads ]
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] Nocatsplash
 Date:  Tue, 16 Mar 2004 05:16:13 -0800
Hi Hilton,

> It really is far from that simple.  I cannot see that installing a
> telnet server, ftp server, samba server, quake server, ident server,
> finger server, a coy of nmap, nessus, a c compiler, kismet, smokeping or
> nocatsplash and leaving them almost all disabled is a good idea for a
> firewall.  And before you start saying you didn't ask for a telnet or
> Samba server, others have asked for them.

But it SHOULD BE that simple. And like I said - don't install them. I'm not
proposing bloatware for the X% of users that don't want a feature - I'm
proposing an extendable web interface and the OPTION of adding components
that DO belong on SOME routers.

A simple addition to the web code might look something like this:

create a folder called "extensions".
In this folder, add ons to mono must create their own folder for php
scripts, and a file containing config data required to include the script in
a menu of extensions.
Extension maintainers could be responsible for rolling their own web
interface that way - and it would be independant of the main mono.
The only other change to the core mono would be a web interface to the
package support to allow simple download for those users depending on the

> Actually, as I suggested above, having Internet -> m0n0wall -> internal
> server -> LAN/WiFi network with the internal server running nocatsplash
> is inherently more secure and appropriate for the scenario you are
> describing.  The firewall is the security device, and the proxy/web
> server/nocatsplash/IDS/mail/whatever box provides the other
> (non-firewall specific) networking functionality.

This is totally impracticle in a world where real business has to compete
with commercial solutions available as an all in one - such as the dlink

The real world demands more cost effective solutions. In theory what you are
saying may be true, though abstraction of services doesn't seem to help some