Feature #3453
closed
Management GUI (lighttpd) interface binding control
0%
Description
Add configuration option to allow/prevent lighttpd from binding to certain interfaces.
In a highly secure environment it's especially important to control access to the configuration mechanisms for the security devices themselves. It is therefor highly undesirable to allow such configuration mechanisms to be exposed to the open, public, side of a security device. Further, it is highly desirable to make this access control "intrinsically safe" given the grave consequences.
While it is currently possible to control the lighttpd port binding - security by obscurity - and through the use of filter rules, this is not intrinsically safe. Rule misconfiguration and crashed 3rd party modules can result in the inadvertent and unintended exposure of a security sensitive mechanism.
I would suggest either adding a list of interfaces that lighttpd would explicitly bind to, or possibly add a check box to the interface detail page that determines if that interface should have the management binding or not. Further, I would default the management interface binding to the LAN interface only, so that a system administrator needs to explicitly and knowingly expose management on other interfaces. It would also be necessary to make provisions for access through VPN tunnels since from the outside it would be desirable to tunnel into the device to access management rather than exposing management directly. I would rather tunnel into another device on the network that has access to the network management segment but that's personal preference.
Updated by Ted Lum over 9 years ago
Well, just had to do another pfSense update, and then had to go through the ritual of patching files to make it work... including...
[system.inc]
$lighty_config .= "server.bind = \"192.168.2.250\"\n";
$lighty_config .= "\$SERVER[\"socket\"] == \"192.168.2.250:{$lighty_port}\" { }\n";
...sure would be nice if this were persistent and configurable.
Updated by Stéphane Lapie over 9 years ago
+1, also needing this here.
This makes it impossible to create any redundant cluster with userland-based services such as Apache or HAProxy running on port 80 or 443, seeing as upon booting, lighttpd will catch these ports for itself.
Updated by Stéphane Lapie over 9 years ago
I have personally opted for using the following patch, as a burn-in procedure, once the LAN interface has been defined and set up :
--- /tmp/system.inc.old 2015-01-14 15:56:54.674828464 +0900
+++ /tmp/system.inc.new 2015-01-14 15:56:49.418798307 +0900
@@ -1063,9 +1063,9 @@
EOD;
- $lighty_config .= "server.bind = \"0.0.0.0\"\n";
+ $lighty_config .= "server.bind = \"{$config['interfaces']['lan']['ipaddr']}\"\n";
$lighty_config .= "server.port = {$lighty_port}\n";
- $lighty_config .= "\$SERVER[\"socket\"] == \"0.0.0.0:{$lighty_port}\" { }\n";
+ $lighty_config .= "\$SERVER[\"socket\"] == \"{$config['interfaces']['lan']['ipaddr']}:{$lighty_port}\" { }\n";
$lighty_config .= "\$SERVER[\"socket\"] == \"[::]:{$lighty_port}\" { \n";
if($cert <> "" and $key <> "") {
$lighty_config .= "\n";
Of course, this takes one more reboot to be applied.
Updated by