[ previous ] [ next ] [ threads ]
 
 From:  Adam Nellemann <adam at nellemann dot nu>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Suggestions
 Date:  Wed, 07 Apr 2004 23:11:03 +0200
Hi All,

Being a *NIX ignorant, probably-not-going-to-do-it-myself, lurking son 
of a bit, I somehow still have the nerve to comment on the suggestions 
and comments below :)

Dan Goscomb wrote:
> Hi Guys
> 
> 
>>> Interface Assignment -------------------- Not everyone has sis
>>> cards... the WAN and LAN should be automatically set to
>>> available interfaces so there is at least some chance that they
>>> can access the system on a default IP address by just booting
>>> up and plugging in a cable.
>> 
>> This would indeed be nice, but how do you know which one to make
>> into WAN and LAN?
> 
> I have thought about this point... and there is no simple answer.
> The only way to do this really is to take the cards in order, first
>  alphabetically and then numerically and set the first to LAN and
> second to LAN or vice versa. If people know what cards they have
> they should know where to plug the cable in... and anyways, the
> card assignments can always be changed. By getting them assigned in
> the first place just gives a realistic chance of "plug and play" if
> you catch my drift.

How about this (assuming an unconfigured m0n0wall): Allow access to 
the webGUI (possibly a simplified version, only showing about the same 
options as the console) from ALL detected interfaces. While this would 
of course leave such a "raw" m0n0wall installation completely open (at 
least for some WAN types), but I should think that a fair punishment 
for anyone who would even consider plugging in the WAN cable before 
setting up at least the propper interface assignments (which, when 
done the first time, should automatically take m0n0wall out of this 
"inital setup mode", and thus revert to the "normal" behaviour of only 
allowing webGUI access from the assigned LAN interface.)

For added security (paranoia option): When m0n0wall is first asked to 
serve a webGUI page while in this "initial setup mode", it could 
imidiatly disallow webGUI access on all interfaces but the one on 
which that inital page was served. This way one could (even if it is 
not very smart) have the WAN cable plugged in, knowing that either it 
would be closed when the webGUI was first shown on a LAN host, or one 
would instantly know that someone else (ie. a lucky hacker) had been / 
is accessing the webGUI from another interface, in which case a quick 
reset of the box should "solve the problem" (and teach you to rip out 
that WAN cable!)


>>> Config Wizard ------------- Should be run on first boot,
>>> similar to the SonicWall method. A step-by-step initial
>>> configuration of the system IP address, type, etc. As you
>>> connect to the admin interface, if no configuration has been
>>> set, it should not show the standard pages until the wizard has
>>> been completed.
>> 
>> I'm not a fan of wizards as I see all too often someone goes
>> through a wizard and then assumes everything will be just right,
>> and never pay attention to any of the details.  The devil is in
>> the details.  If there is a wizard, having the option to skip it
>> would be essential I think.
> 
> A bypass option is entirely reasonable and i thought would be
> assumed, sorry i didn't mention that :/  You may not be a fan of
> wizards, but home users generally are! As, believe it or not, are
> some corporate network admins... that are used to windows. A
> confirmation page at the end with a checklist of things they may
> still need to do may be a good idea. But with no wizard at all
> surely they may not even get as far as the wizard could take them!?

All this sound very reasonable to me, although I can understand it if 
Manuel doesn't want to put in all the hours needed to do a wizard in 
php/html (assuming he'd want it to look as nice as the rest of the 
webGUI). Perhaps someone with experience in web-design could do some 
kind of (possibly plain html) "mock up", that would make it easy for 
Manuel to put in the needed php code (our web-designers and scripters 
used to work this way!) This of course assuming that Manuel is with 
you on this wizard idea.

BTW. The abovementioned "initial setup mode" would be a perfect place 
to show the wizard, which should of course have a "Cancel" button 
beside the "Next >" button on all pages, including the first, allowing 
people to exit without any changes being done, at any time. (This, I 
think, is standard behaviour for most Wizards, albeit many MS 
applications will fail to work / install without the completion of the 
wizard, but that is another matter.)


>>> Auto-apply option ----------------- I find i keep forgetting to
>>> press the "Apply Changes" button and so keep wondering why its
>>> not working properly. Maybe an option so that changes are
>>> automatically applied rather than having to apply them
>>> manually.
>> 
>> That happened to me once.  I think the statement that "changes
>> haven't been applied yet" could perhaps stand out more.  Doing an
>> auto-apply might not be the best thing though, as when adding
>> multiple hosts to the dns forwarder or the dhcp server, that's a
>> lot of extra processing.  On a cdrom/floppy based system, this
>> would be painfully slow I think.  Perhaps making auto-applies be
>> an option in the general setup would help with both sets of
>> viewpoints.  Or perhaps just making the text more obvious.
> 
> 
> Fair point, and this is why i specified it as an auto-apply
> OPTION... i.e. not forced.

No comment, I'm happy either way (although I might very well choose to 
enable such an option.)


>>> Tools ----- Seeing as there is no shell on the system, some
>>> other tools are very important to check if the firewall is
>>> working properly. These are as follows: * Traceroute * ARP
>>> Cache * TCP connect * Packet Trace * nslookup
>> 
>> Traceroute would indeed be nice.  arp -a can be run via exec.php.
>> I think status.php gives much of the other useful stuff.  Perhaps
>> adding arp -a output to status.php would be useful.  nslookup was
>> deprecated a long time ago.
>> 
> 
> status.php is nice, but its not linked anywhere on the GUI.
> exec.php... again, not linked, and not everyone knows UNIX commands
> ;) nslookup does not neccessarily mean the nslookup tool, but an
> nslookup function.

As far as having a link to all those "hidden pages" goes, I'm with 
you. I'll leave it to you network gurus and admins to decide which 
tools are apropriate for a firewall? I'd suggest a "Tools" or 
"Utilities" page in the "Diagnostics" section for such links.

I will say this though: Any such tools already present on m0n0wall and 
which could concievably be of any use to a reasonable number of users, 
should IMHO be exposed in the webGUI (in due time of course, other 
things may well be more pressing to implement).


>>> Failover -------- A very important feature if you ever want it
>>> to become a proper appliance... all large companies require
>>> failover! This can be easily integrated with the use of
>>> FreeVRRPd
>> 
>> This would be a nice feature, although not a requirement for the
>> target of home and SOHO environments.  I personally like the
>> approach the openbsd people have taken to solve this problem
>> (which was recently discussed on this list).
> 
> m0n0wall is aimed at SOHO currently... but it has so much potential
> and is almost ready to rival commercial appliances. The fact that
> its engineered for embedded PCs really is a major factor here, it
> could become very successful in the corporate market if stuck in a
> 1U box.

While I don't have the knowledge to discuss this, I know of at least 
one person, working for a large server farm, who currently consider 
doing just that, putting m0n0wall in a rack unit and using it in 
various places in the data center.


>>> Attack rules ------------ Specific attacks should have
>>> individual log rules so they can be identified and reported...
>>> people want nice things to look at, not just raw logs! I think
>>> you were also looking for a function for another LED
>>> somewhere... welcome to your answer, this is what its used for
>>> on a SonicWall box!
>> 
>> I'm not clear how useful this would be.  It almost sounds like
>> snort type behavior... and that's already been hashed to death on
>> this list.
> 
> Not snort, thats not the job of a firewall. These are basic
> attacks, not complex ones, and not a large amount of them.

Being rather ignorant about the log format (although I think I've got 
it figured by now) and having had some trouble getting my syslog 
daemon to "parse" these into a suitable format for human reading, I'd 
love any work done to simplify and clarify the log entries and their 
possible "implications" (ie. It took me some time to figure out the 
reason for those entries caused by a dropped NAT connection, as these 
entries seem to indicate a configuration error to the untrained eye.)

Anyway such behaviour should be optional I think, as I'm sure some of 
you gurus wouldn't want to have your unadulterated view of "The 
Matrix" obscured by such unnecessary human-readable information :)

Personally though, I'd love to have a log (possibly alongside the 
"raw" one), which would tell me in large friendly letters what those 
nasty people on the net was trying to do with my poor firewall, even 
if I DO know how a NetBIOS attack looks (but that is about it!?!)


>>> Static Routes [cut]
> 
> 
>>> Firewall Rules -------------- The default rule for each
>>> interface should be shown... people MAY want to change it to
>>> allow, you never know! Even if not, its reassuring to have a
>>> red cross there at the bottom of your list! Also, all available
>>> interfaces, whether they have rules or not, should be shown in
>>> this list... its confusing to have to add a rule for the WAN
>>> interface by click the + button under the LAN interface area!
>> 
>> The current placement of the single '+' is indeed a bit
>> misleading.  I think it would be simple to clarify its purpose,
>> but I'm not a php person nor a UI design person
> 
> 
> Easily fixed, may even get around to it over the weekend.

Sounds good to me!


>>> NAT --- Server NAT is in the wrong place... this should be
>>> under the network configuration page on each interface as an
>>> alias option. Ideally it wouldn't be present at all, and would 
>>> automatically which interface the new IP should be bound to
>>> upon adding an incoming NAT rule. Make it easier for them to
>>> understand!
>>> 
>>> Instead of enabling advanced outbound NAT, just have it enabled
>>> already, but show the default rule in the list! This makes it
>>> very obvious as to exactly what will get NATTed and what won't.
>>> 
>> 
>> Interesting idea.  I'm used to things the way they are, but I see
>> merit in both approaches.
> 
> This is true... maybe make the name a little more obvious and also
> have autoadditions if one doesn't exist in the list?

I too think this particular part of the GUI could be somewhat 
clarified, even if I quickly got the gist of it. I seem to remember 
Manuel having some good arguments for leaving the things the way they 
are though?


>>> DHCP Server ----------- Should be able to support multiple
>>> address ranges. Some people (including me) use cisco routers on
>>> the LAN side to proxy DHCP requests so only one server is
>>> required instead of one on each subnet.
>> 
>> I would suggest that anyone with a network of that complexity is
>> able to run a dhcp server on something other than their firewall.
>> I would love to see more access to the underlying DHCP features,
>> but I plan to do that in a different machine than my firewall
>> when I need those features.
>> 
>> One thing smoothwall let me do that I do miss in m0n0wall is
>> having multiple MAC addresses for one IP.  This let me keep the
>> same IP on my laptop as I switched between wireless and wired
>> access, without any disruption of current TCP connections.
> 
> Granted networks like this are large and complex, however i have
> seen them in smaller environments such as schools where m0n0wall is
> aimed. And if it gets in to corporate markets it wouldn't be a bad
> thing to have for the effort required!

I'm all for this. Being a home user, even I could use the ability to 
narrow down the DHCP ranges to only those IP's I plan on using, 
instead of having to include everything inbetween (should also be more 
secure in a wireless setup, but again, I'm no expert?)


>>> Password Reset -------------- On the GUI this should need you
>>> to first enter your old password. The htaccess method has no
>>> sessions and potentially a user stumbling accross it on someone
>>> elses machine could reset the password without having to first
>>> log in with the old one.
>> 
>> This seems quite reasonable.

No argument from me on this one.


>>> Logs ---- Should have an option to email the logs after a
>>> certain size is reached. Also potentially an option to
>>> automatically send logs to dshield.org
>> 
>> That's an interesting idea.  I know my father would love such a
>> feature. Personally, I'm sending my logs to another machine that
>> can summarize them and email me the reports.
> 
> Not everyone has other machines, hence email is a nice way to get
> the logs off for reporting. Another idea (lightbulb!) is maybe to
> have an option to download logs from a page?

I can't comment on the need for this, nor the ease of implementation. 
But it sounds reasonable to have another host do this after 
summarizing or digesting the syslog output, this would certainly be my 
choice (although some people might not have an always-on host to do 
this on, dunno if they'd then be the kind of users wanting the e-mail 
feature though?)

Personally I'd rather see some more options on the syslog 
configuration page (such as some kind of filters or at least a few 
more checkboxes for selecting what gets syslogged, not that my syslog 
daemon can't do this, but it would keep the log traffic down, and 
might be easier and simpler to do and configure at the source?)


>>> VPN --- Multiple destination subnets, and of course multiple
>>> local subnets!
>> 
>> If I understand this correctly, a single tunnel handling multiple
>> network on either end.  I don't see why this isn't possible with
>> correct routing rules in the current software, although I haven't
>> tried it so I might be missing something.
> 
> Not with IPSec, its rather more complicated!

I've not used VPN (yet!) so no comment here.


>>> PHP --- I hate to say it... but PHP in itself shouts
>>> insecurity. Every white/gray hat i've spoken to has said they
>>> would not use m0n0wall because it has PHP on it.
>> 
>> I think I said enough on this one.  *grin*
> 
> Yeah, there are arguments both ways, and to be honest i never
> expected it to change. Enough said on both sides i think.

Without wanting to start the argument all over, I must admit that I 
too can't see the problem here. Actually I find this exclusive use of 
php for all scripting (including boot) a rather elegant and simple 
approach (simple often being synonymous with secure).


Well, that was my two cents anyway. I Hope it wasn't all total nonsense :)


Regards,

Adam.