| 10.3. HTTP Server configuration | ||
|---|---|---|
 | Chapter 10. System Services |  |
| 10.3. HTTP Server configuration | ||
|---|---|---|
| | Chapter 10. System Services | |
The HTTP server's purpose is to serve the HTML and supporting files that implement the web-based user-interface for the FB9000. It is not a general-purpose web server that can be used to serve user documents, and so there is little to configure.
Access can be restricted using allow and local-only controls as with any service.
If this allows access, then a user can try and login. However, access can also be restricted on a per user basis to IP addresses and using profiles, which block the login even if the password is correct.
By default, the FB9000 will only allow access from local interfaces. This is locked down by the
local-only setting defaulting to true. If you change this, it will allow access from anywhere
and you may want to set up IP ranges or groups in the allow setting to control access.
Note that a subnet can be marked as wan to indicate that even though directly connected, it is not considered
local. This is mainly for cases where the external interface is a wide DHCP subnet spanning other users
of the same ISP, and so should not be considered local.
Additionally, access to the HTTP server can be completely restricted (to all clients) under the control of a profile. This can be used, for example, to allow access only during certain time periods.
There are a number of security related headers with sensible defaults. These can be changed in the config. If you wish to remove a header simply make it an empty string to override the default.
Trusted addresses are those from which additional access to certain functions is available. They are specified by setting the
trusted attribute using address ranges or IP address group names.
This trusted access allows visibility of graphs without the need for a password, and is mandatory for packet dump access.
The trusted access list also has priority over local-only and allow, i.e. if the source IP is in the trusted access list, it is always allowed.
The FireBrick provides a means to access the control pages using HTTPS rather than HTTP. When you first use a FireBrick, if you access using HTTPS to its IP address or my.firebrick.uk you will get a warning about the certificate being self signed. You can bypass the warning or use HTTP as you prefer, though HTTPS (even with a warning) prevents passive snooping, so is preferable. Ideally you want to set up HTTPS properly for your normal access to your FireBrick in the long term.
You will need to install a key pair, and a certificate using the host name you have chosen as its name. A proper signed certificate from a recognised CA will avoid any browser warnings when using HTTPS.
self-sign. Self signed certificates have limited life, are removed on reboot or expiry, and only a small number are retained in the certificate store at one time. If no SNI is provided, a self signed certificate matching the IP address literal is used on the assumption that this is what was used with the https:// protocol.
By default access is permitted using HTTP and HTTPS (directing to HTTPS if an ACME certificate has been set up), but you can lock down to HTTP only, HTTPS only, or redirection from HTTP to HTTPS. It is recommended that HTTPS is used for security reasons. FireBrick HTTPS works with all modern browsers (e.g. IE 10 and above, chrome, firefox, safari). It uses TLS1.2 only with TLS1.3 planned when appropriate.
log-acme-debug setting to allow more detailed logging of the process. It is recommended you set log-acme to email you so that you are made aware of any problems automatically renewing certificates.
| |  | |
| 10.2. Common settings |  | 10.4. Telnet Server configuration |