Administrative users
NethSecurity allows local users to be granted administrative access to the web interface. Administrative users should be personal accounts assigned to individual operators so that actions can be attributed to a specific user in the logs.
Administrative account types
NethSecurity uses the following administrative account types:
root: local system account. It should be reserved for emergency or recovery operations whenever possible.- Administrative users: local users with the Administrator user option enabled. They can access the NethSecurity UI and perform administrative operations.
- Non-administrative users: local or remote users used for services such as VPN or authentication, without access to the NethSecurity UI.
Administrative access should be granted only to trusted operators.
Creating administrative users
Administrative users are created from the local users database.
To create an administrative user:
- Create a local user.
- Set a password for the user.
- Enable the Administrator user option.
- Save the configuration.
For general information about local and remote user databases, see Users databases.
NethSecurity UI 2FA
Protecting your NethSecurity administrator account is crucial. Two-Factor Authentication (2FA) adds an extra layer of security beyond just a password: instead of only a password, you also need a temporary code generated by a separate app on your smartphone or tablet. This significantly reduces the risk of unauthorized access even if your password is compromised.
Enabling 2FA on NethSecurity UI:
- Log in to your NethSecurity web interface.
- Click on the user icon in the top right corner and select Account settings.
- Find the Two-factor authentication option and click Configure 2FA.
Setting up your authenticator app:
- Download an authenticator app on your smartphone or tablet. Popular options include FreeOTP, Google Authenticator, and Microsoft Authenticator.
- Open the app and scan the QR code displayed on the NethSecurity web interface.
- Enter the 6-digit code displayed by your authenticator app in the One-Time Password (OTP) field.
The system also provides a set of backup codes. These can be used to log in if you lose your smartphone or authenticator app. Store them securely, preferably offline.
Disable 2FA via the web interface
If the administrator can still log in to the web interface:
- Click the user icon in the top-right corner and select Account settings.
- Scroll to the Two-factor authentication section.
- Click Revoke 2FA.
- A confirmation dialog appears warning that the security level will be reduced. Click Revoke 2FA to confirm.
- If prompted, enter your current password to authorize the change.
After confirmation the status badge changes to disabled and the next login will no longer require an OTP.
Disable 2FA from the command line (emergency recovery)
If an administrator has lost both the OTP device and the recovery codes and can no longer log in to the web interface, 2FA can be reset directly from the shell as root over SSH.
Run the following commands, replacing <username> with the administrator account name (use root for the default administrator):
SECRETS_DIR=/etc/ns-api-server
USERNAME=root # change to the affected username
rm -f "${SECRETS_DIR}/${USERNAME}/secret"
rm -f "${SECRETS_DIR}/${USERNAME}/codes"
printf '0' > "${SECRETS_DIR}/${USERNAME}/status"
After these commands the user can log in with just their password. 2FA can be re-enabled at any time from the web interface.
Only the root account has SSH access by default. Non-root administrators cannot be recovered from SSH by the affected user themselves; an existing root session is required to run the commands above on their behalf.
Root and emergency access
The root account is the main local system account. It should be treated as an emergency or recovery account and not used for ordinary administrative activity when personal administrative users are available. Use personal administrative accounts for daily operations so that actions can be attributed to individual users in the logs.
Administrative activity logging
NethSecurity logs administrative activity performed through the web interface in /var/log/messages. Administrative logs can support troubleshooting, incident analysis, and audit reconstruction.
Where to find administrative logs
Logs are written to /var/log/messages and rotated weekly. They are visible from the UI in their dedicated section. To see administrative UI events, use the filter nethsecurity-api.
For long-term retention and centralized audit, configure persistent log storage, remote syslog forwarding, Controller log forwarding, or Cloud Log Manager. For details, see Logs.
Reconstructing administrator actions
Administrative logs allow answering questions such as:
- who logged in;
- when the administrator accessed the firewall;
- which UI pages or API functions were used;
- which configuration areas were changed;
- which values were submitted;
- whether a change was committed;
- whether the action was followed by service errors or security events.
Example login event for user goofy:
Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:78: [INFO][AUTH] authentication success for user goofy
Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:186: [INFO][AUTH] login response success for user goofy
Example logout event for user goofy:
Jun 21 09:46:13 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:46:13 middleware.go:214: [INFO][AUTH] logout response success for user goofy
Example of an action performed by user goofy:
Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:170: [INFO][AUTH] authorization success for user goofy. POST /api/ubus/call {"path":"ns.dashboard","method":"service-status","payload":{"service":"internet"}}
Audit and compliance recommendations
For audit-oriented deployments:
- create a personal administrative account for each operator;
- avoid shared administrative accounts;
- enable MFA for all administrative users;
- reserve
rootfor emergency or recovery operations whenever possible; - use strong passwords and protect recovery codes;
- configure persistent log storage or remote log forwarding;
- forward logs to a remote syslog server, SIEM, Controller, or Cloud Log Manager;
- verify that log forwarding is working correctly;
- ensure that date, time, and timezone are correct, preferably using NTP;
- define log retention according to the organization security policy;
- protect remote logs from unauthorized access or deletion;
- periodically review administrative access and configuration change logs.
NethSecurity logs can support audit reconstruction and incident analysis. Organizational processes such as change approval, periodic review, incident classification, and evidence preservation remain the responsibility of the organization operating the firewall.
Current limitations
- NethSecurity does not currently provide a full local RBAC model for web administrators.
- A dedicated local read-only administrator role is not currently available.
- Administrative users should therefore be assigned only to trusted operators.
- Some log entries may require correlation with configuration commit logs or related service logs.
- An authorization event means that the API request was allowed, but related logs should be checked to confirm the final effect of the operation.
- Not every log entry necessarily contains the same fields.
- Local in-memory logs may be lost after reboot or rotation unless persistent storage or remote forwarding is configured.
For long-term audit requirements, use remote log forwarding or Cloud Log Manager in addition to local logs.