| Chapter 4. System Administration | ||
|---|---|---|
 |  | |
| Chapter 4. System Administration | ||
|---|---|---|
| | | |
Table of Contents
You will have created your first user as part of the initial setup of your FB9000, as detailed in either the QuickStart Guide or in Chapter 2 in this manual.
To create, edit or delete users, browse to the config pages by clicking the "Edit" item in the sub-menu under the "Config" main-menu item, then click on the "Users" category icon. Click on the "Edit" link adjacent to the user you wish to edit, or click on the "Add" link to add a user.
To delete a user, click the appropriate "Edit" link, then click the "Erase" button in the navigation controls - see Figure 3.8. As with any such object erase operation, the object will not actually be erased until the configuration is saved.
Once you have added a new user, or are editing an existing user, the object editing page will appear, as shown in Figure 4.1 :-
The minimum attributes that must be specified are name, which is the username that you type in when logging in, and
password - passwords are mandatory on the FB9000.
You can optionally provide a full name for the specified username, and a general comment field value.
A user's login level is set with the level attribute, and determines what CLI commands the user can run.
The default, if the level attribute is not specified, is ADMIN - you may wish to downgrade the level for
users who are not classed as 'system administrators'.
Table 4.1. User login levels
| Level | Description |
NOBODY | No access to any menu items, but can access control switches for which the user has access. |
GUEST | Guest user, access to some menu items |
USER | Normal unprivileged user |
ADMIN | System administrator |
DEBUG | System debugging user |
The configuration access level determines whether a user has read-only or read-write access to the configuration,
as shown in Table 4.2 below. This mechanism can also be used to deny all access to the configuration using the
none level, but still allowing access to other menus and diagnostics.
Config access also requires at least admin level for their login level to access config via the web interface.
It is possible to test a new config, causing it to be applied but not saved to permament storage. This test config automatically reverts after a few minutes if not committed, or if the brick restarts, e.g. power cycle. It is recommended that you test a config first to ensure you have not locked yourself out, and there is a user level to force you to have to test configs first.
Table 4.2. Configuration access levels
| Level | Description |
none | No access unless explicitly listed |
view | View only access (no passwords or hashes) |
read | Read only access (with passwords and hashes) |
demo | Full view and edit access, but can only test new config, not save them. |
test | Full view and edit access, but must test new config before committing it. |
full | Full view and edit access. |
To improve security, login sessions to either the web user interface, or to the command-line interface (via telnet, see Chapter 13),
will time-out after a period of inactivity. This idle time-out defaults to 5 minutes, and can be changed by setting the timeout attribute
value.
The time-out value is specified using the syntax for the XML fb:duration data type. The syntax is hours, minutes and seconds, or minutes and seconds or just seconds. E.g. 5:00.
To set a user's time-out in the user interface, tick the checkbox next to
timeout, and enter a value in the format described above.
Setting a timeout to 0 means unlimited and should obviously be used with care.
You can restrict logins by a given user to be allowed only from specific IP addresses, using the allow attribute.
This restriction is per-user, and is distinct from, and applies in addition to, any restrictions specified on either the web or telnet (for command
line interface access) services (see Section 10.3 and Section 10.4), or any firewall rules that affect web or
telnet access to the FB9000 itself.
The FireBrick allows a general definition of IP groups which allow a name to be used in place of a range of IP addresses. This is a very general mechanism that can be used for single IP addresses or groups of ranges IPs, e.g. admin-machines may be a list or range of the IP addresses from which you want to allow some access. The feature can also be useful even where only one IP is in the group just to give the IP a meaningful name in an access list.
These named IP groups can be used in the allow list for a user login, along with specific IP addresses or ranges if needed.
However, IP groups can also list one or more user names and implicitely include the current IP address from which those users are logged in to the web interface. This can be useful for firewall rules where you may have to log in to the FireBrick, even as a NOBODY level user, just to get your IP address in an access list to allow further access to a network from that IP.
By specifying a profile name using the profile attribute, you can allow logins by the user only when the
profile is in the Active state (see Chapter 8). You can use this to, for example, restrict logins to be allowed only during
certain times of the day, or you can effectively suspend a user account by specifying an always-Inactive profile.
Normally, all config data is updated via the config edit process, and this allows a new password to be set for any user.
However, there is also a menu to allow a logged in user to change their own password. This does not require the user to have any config access permission. Simply enter the old password, and the new password twice and the password is updated.
If you have set up an OTP configuration for a user, then you cannot change the password simply using the configuration editor (unless also setting a new OTP configuration from scratch or removing it). In such cases the password should be set using the password change web page. This is also good practice as it avoids the administrator knowing people's passwords.
A login to the FireBrick normally requires only a username and password. However you can configure an additional security measure using a One Time Password (OTP) device. These are available as key fobs that show a code, but are more commonly done by use of a mobile phone application.
In order for the device to work you need a key which is known to the FireBrick and the device. However, this is very simple to set up. A user can access the Password / OTP menu where a random key is allocated and displayed within a QR 2D bar code. Most authenticator applications simply scan the QR code and start showing the 6 digit number on the display (which changes every 30 seconds). You then enter your password and a code from your device to complete the process.
It is possible for anyone with configuration access to edit your user settings and remove the OTP settings if you wish. This can be useful if you lose or break the phone, for example. You may want to keep a local configuration user as a backup as well, as OTP cannot be used if the clock is not set for any reason.
When you login, after you submit your username and password you are asked for a code from the authenticator to complete the login process.
It is also possible to enter the password as the authenticator code followed by the configured password. This is useful if using HTTP authentication to access a web page where there is no separate option for the authenticator input to be provided.
If OTP is configured you can leave the password blank (which is not normally allowed) and hence use the authenticator code as the entire password, though this is not recommended for security reasons as it also means the TOTP seed is recoverable from the config.
| | | |
| 3.7. Downloading/Uploading the configuration |  | 4.2. General System settings |
