13.3. HTTP Server configuration

The HTTP server's purpose is to serve the HTML and supporting files that implement the web-based user-interface for the FB2500. It is not a general-purpose web server that can be used to serve user documents, and so there is little to configure.

13.3.1. Access control

By default, the FB2500 will allow access to the user interface from any machine, although obviously access to the user interface normally requires the correct login credentials to be provided. However, if you have no need for your FB2500 to be accessed from arbitrary machines, then you may wish to 'lock-down' access to the user interface to one or more client machines, thus removing an 'attack vector'.

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 passord is correct.

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.

13.3.1.1. Trusted addresses

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 priorty over local-only and allow, i.e. if the source IP is in the trusted it is always allowed.

13.3.2. HTTPS access

The FireBrick provides a means to access the control pages using https rather than http.

At this stage, to use this feature, you will need to install a key pair and certificate manually. This could be a self signed key/certificate or something signed by a certificate authority (CA) like Let's Encrypt. A proper signed certificate from a recognised CA will avoid any browser warnings when using https. The certificate generation / upload process is explained more in Section 12.1.4.

Note

The https server uses SNI to find the matching certificate against its common or alternate name. This must therefore exactly match the name used to access the FireBrick or be a wildcard for the first level and match the rest, as per normal https certificates. If no match is found then https will not work.

By default access is permitted using http and https, 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 soon.

Note

At present the default is to allow both, but this will change to redirect by default if a certificate exists to allow https (even if expired).

Note

The system will be updated to make this simpler over time, and allow automated configuration of keys and certificates using ACME (e.g. Let's Encrypt).