| 12.3. HTTP Server configuration | ||
|---|---|---|
 | Chapter 12. System Services |  |
| 12.3. HTTP Server configuration | ||
|---|---|---|
| | Chapter 12. System Services | |
The HTTP server's purpose is to serve the HTML and supporting files that implement the web-based user-interface for the FB6000. It is not a general-purpose web server that can be used to serve user documents, and so there is little to configure.
By default, the FB6000 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 FB6000 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.
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.
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) provents passive snooping, so if better. Ideally you want to set up https properly for your normal access to your FireBrick in the long term.
In most cases, all that is needed to manage https access it to ensure the FireBrick can be accessed via port 80 on a public IP address using a proper public hostname. Once you have done this, simply add the hostname to the acme-hostname field, and your email address in the acme-terms-agreed-email field, in the system config. This will cause an automatic ACME certificate issue using Let's Encrypt, adding private key pairs for the letsencrypt.org account and the domain and then adding the certificate and any intermediate certificates for https to work.
acme-terms-agreed-email field you are indicating that you agree to the terms and conditions of the Certificate Authority being used.
This may include publishing a list of certified domain names, and sending emails for changes of terms, etc.
ACME is an automated system for the issuing of X.509 certificates for https (and other) use. The FireBrick can work as an ACME client to obtain certificates and is preset to use Let's Encrypt's free certificate issuing service, and automatically renew certificates. You can change settings to use an alternate ACME server if you pefer though you may have to upload root certificates for the alternate CA. Contact support if you have any issues.
allow and trusted settings as normal.
By default, during the ACME update process, port 80 is allowed generally at a TCP level (bypassing the allow settings) but only for the special URL for ACME validation and only for the few seconds needed to validate your device. This means access to to config pages always respects the allow and trusted settings at all times, even if accepting TCP port 80 briefly for one specific ACME URL. This can be disabled, but may stop the automatic certificate renewal process.
letsencrypt.org and one matching the hostname for the certificate name. If such keys exists then they are used instead of making new keys when requesting a certificate. At present these must be RSA keys.
If you do not load your own keys, the FireBrick makes keys internally. You can disable automatic key generation by setting acme-keygen false.
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.
Obviously the automated ACME process creates, and renews, a verified CA signed certificate with the correct name, so is recommended. Once set up, you may wish to turn off self signed certificates, and possible even http access at all.
By default access is permitted using http and https (directing to https if an ACME certificate is 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 ste log-acme to email you so that you are made aware of any problems automatically renewing certificates.
| |  | |
| 12.2. Common settings |  | 12.4. Telnet Server configuration |