I think all of your additional development sounds appropriate to the goals
of the project. I hope that Manuel considers adding all of your additional
features.
While your at it, could you fix that pesky non-routable outside address from
the inside of the NAT problem? I'm still offering $200 to anyone who can
fix it. :)
--Chris
-----Original Message-----
From: Paul Taylor [mailto:PaulTaylor at winn dash dixie dot com]
Sent: Wednesday, August 24, 2005 10:31 AM
To: m0n0wall dash dev at lists dot m0n0 dot ch
Subject: [m0n0wall-dev] ssh & other additions
In order to speed up our development, we've added ssh to our installation of
Monowall (based on the latest beta).
Our implementation of SSH adds an "Enable SSH" checkbox and an "Authorized
Keys" field to the Advanced page. The data here must be entered in the
format of an authorized key file. Trying to log in as root with a simple
password doesn't work...
I know that Manuel has historically specifically avoided adding SSH access
to public distributions of Monowall... Is there any hope that he might
allow a modification such as this to make its way into a public release?
Requiring keys secures it far more than a simple password and would ensure
that people who really didn't know what they were doing wouldn't be able to
leave themselves wide open.
I'm asking this because I know it has been a sticking point in the past, and
there's another reason... We've added several other new features to
Monowall and our boss has suggested that we contribute them back to the
community in the hopes that they would all be added to the base version of
Monowall... So, if a new version of Monowall came out that fixes a security
issue, etc., we could simply load it and be up-to-date. If our features
can't fit into the base Monowall distribution, we would need to determine
the differences between the versions and merge the code changes, which would
obviously be a time consuming process...
The other features we've added:
A Captive Portal Administrator user (can only access the Captive Portal
related pages and Local User admin pages)
A Network Operations user (can only access the Status and Diagnostics pages)
[Note: We have plans to make this generic so that you could specify your own
usernames, passwords, and the specific pages they could view. We don't
expect the user features to be implemented as is. Our company has
separations for the security department (to admin captive portal users),
network operations (to perform troubleshooting with specific users), and
network design (everything else)..]
ARP table page (which looks up the hostname out of the DHCP DB, if known,
and converts the Interface to the Monowall name for the interface.)
Traceroute page
NS Lookup page (Server is auto-populated from the configured DNS server,
Query type dropdown contains MX, CNAME, etc.)
Whois page
The ability to disable Concurrent logins via the Captive Portal.
A Firewall states page for advanced troubleshooting... It shows the Source
IP, Port, Destination IP, Port, Protocol, Packets, Bytes, and Time-to-live.
(I had images throughout the message, but it was too large for the list.)
This is perhaps the best feature for troubleshooting an individual user
problem... Here you can see all connections live (as fast as you refresh
the page), sort by whichever column you want, ascending or descending,
filter on source or destination IP Address by clicking the desired IP
Address, and take Statistics Snapshots to view Delta packet and byte info.
On our production box, it is not unusual to see a few hundred states open...
We have added a setting on the advanced page to set the maximum number of
states to view via this screen... (If set very high on a machine with a
slow processor, this takes time, but at the default setting of 300 on a
net4801, it's very fast.)
In addition to the above, we have modified the captive portal index page to
allow specific page elements to be served directly from the server and have
added them to our image. I am planning to write another addition to allow
these page elements to be uploaded via the webGUI and stored encoded in the
config, then written out to the captive portal directory at boot up time
under the appropriate names...
At any rate, if all of this could be included in the base Monowall image,
including the SSH access, we'd happily donate all our work on this. If,
however, this doesn't fit the long term goals of the project, we understand
completely...
Thanks,
Paul Taylor
Winn-Dixie Stores, Inc.