Messages

There is a GitHub issue about this topic: https://github.com/opnsense/core/issues/7649

[System: Log Files: General]

I might have the same issue after an upgrade to OPNsense 24.1.10_8 (and consecutive upgrade to 24.7 as well).

Previous version: 24.1.6
Issue appeared after upgrade to: 24.1.10_8

Issue: No access via web interface after boot (timeout).

Reloading the services via console (menu item 11) restores access via web interface until next reboot.

System: Log Files: General shows during boot:

2024-08-05T14:38:13   Error   opnsense   /usr/local/etc/rc.bootup: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2024-08-05 14:38:13: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [fe80::7802:45ff:fe40:c66d]:4433: Can't assign requested address'

I can confirm that setting the listening interface at System: Settings: Administration to "All (recommended)" by deselecting all interfaces solves the issue. When the listening interface is set manual, even if all interfaces are selected, the above error message gets thrown and access to the web interface is not possible after reboot.

All interfaces are configured for static IPv4. IPv6 configuration type is set to "None".
Unchecking "Allow IPv6" at Interfaces: Settings and two reboots in a row solves the issue as well.

Thank you for your quick and detailed reply with references to the certification.

In order to adapt to the change and take it as "it is what it is", a possible solution in our environment could be to use seperate user accounts for webinterface as well as shell access. This reflects our setup with two seperate management networks. The account with shell access can be created using the option "Generate a scrambled password to prevent local database logins for this user". Thus the user may be part of the admin group, but actually not be able to access the webinterface. For SSH, we've already used authorized keys. That way, we'll be able to keep our tooling and processes with only little adjustments without worsening our security footprint.

Just for curiosity, I've asked ChatGPT for an idiom regarding my initial post. The answer seems to be spot on:


In the context you've provided, a relevant phrase could be:

"Too secure for its own good."

This phrase is used to describe a situation where something is made overly secure or restrictive to the point where it becomes impractical or unusable. In the case of the ICT certification requiring OPNsense to be locked down and limited in functionality, it may indeed result in the product being extremely secure according to theoretical security threats. However, this excessive security measure could render OPNsense ineffective or dysfunctional for practical use cases.

In essence, "too secure for its own good" implies that while the intention may be to enhance security, the outcome is a product that is overly restrictive and ultimately less useful or valuable. It highlights the trade-off between security and usability, suggesting that an excessive focus on security measures can sometimes undermine the practicality or functionality of a product.

After testing the update to OPNsense 24.1.1, our tooling regarding shell login for non-admins got broken with the info message "The login shell for this non-admin user is not active for security reasons" on System: Access: Users. This is because of the following change "system: prevent activating shell for non-admins":
https://github.com/opnsense/core/commit/a0581ae0f62b1d3886e8dd5c6fb3c81e3afd8908

The suggested solution is: "This may cause custom tooling to stop working, but can easily be fixed by giving these required accounts the full administration rights."

For us, this increases the attack surface rather than strengthening security. In our environment, webinterface and shell access reside in two seperate management networks with a non-admin user granted very limited read access via shell. If this user has to be part of the admin group, this would extend the authorization via webinterface unnecessarily. This is because there are cases where "permissions(ssh) < permissions(admin)".

This change may have good intentions with unintended consequences. Following compliance requirements such as audits and certifications might actually decrease the overall security of some setups.

On the other hand, I can well understand the security concerns regarding a possible privilege escalation via shell access.

I've come up with the following constructive suggestions:

• Instead of blocking shell access for non-admin users, keep the infobox with a warning, e.g.:
  "The user has been granted shell access without being part of the admin group. This is a danger zone. Please be aware of unintended security implication. If no further steps are taken to limit the users shell permissions, the user might have broader access via shell than via webinterface."
• Introduce a dedicated predefined shell group for non-admin users. Users with shell access will have to be explicitly added to the shell group. This could be supplemented by a similar information about security implications.
• Introduce an opt-in-check-box per user explicitly enabling shell access. This again could be associated with a warning about unintended security implications.

One of these suggestions might be a more user-centered approach than the current change.