14.3. HTTP Server configuration
Prev Chapter 14. System Services Next

14.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 FB2900. It is not a general-purpose web server that can be used to serve user documents, and so there is little to configure.

14.3.1. Access control

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 FB2900 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.

14.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 access list, it is always allowed.

14.3.2. HTTPS access

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.

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.

Note

By putting your email address in the 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. Renewal happens automatically, but you can lock down when this happens (e.g. time of day) by setting an acme-profile.

Tip

The ACME based certificate can also be used for IPsec, and so automatically renewed.

Note

You do not need to allow port 80 (HTTP) access in your network, but you can lock down HTTP and HTTPS access using the 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 the 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. In addition, if a profile is set up as a control switch, and named as fb- followed by the certificate authority, e.g. fb-letsencrypt.org then this profile is activated at the start of the validation phase, and deactivated at the end. This can be used (with care) to allow specific firewall rules during certificate renewal.

Note

If you wish to load your own private keys, and allow ACME renewal of certificates, you can do so. The keys need to have a name in the same way as the automatically generated keys, i.e. one for the account with the CA, e.g. letsencrypt.org and one matching the hostname for the certificate name. If such keys exist 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. 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 subject alt 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, if no certificate can be found for HTTPS, one is created, self signed (which will give a browser warning). This can be turned off in the web config settings for 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 possibly even HTTP access altogether.

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.

Tip

There are many things that could stop ACME working. The status page (config/certificates) shows the progress of the process. There is also a 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. As per the recommendations for setting up firewall rules, it is generally not needed to firewall traffic to the FireBrick itself, but instead use the allow and local-only type controls on various FireBrick services. If you do firewall (on the FireBrick or externally) you will need to ensure port 80 access to the FireBrick's public IP is possible even with the services set to HTTPS only so as to allow the ACME process to validate your FireBrick.
Prev Up Next
14.2. Common settings Home 14.4. Telnet Server configuration