Admin Access¶

The options on System > Advanced, Admin Access tab govern various methods for administering the firewall, including via the web interface, SSH, serial, and physical console.

webConfigurator (GUI)¶

Protocol¶

The protocol for connections between web browsers and the GUI. May be one of:

HTTP:: Plain unencrypted HTTP. Insecure and basic, but widely compatible. Should not be used in most cases, and should never be exposed to insecure networks.
HTTPS (SSL/TLS):: Encrypted (“Secure”) HTTP. Protects communication between the client browser and the firewall GUI. Requires an SSL/TLS certificate to function. Depending on the browser and certificate configuration, there may be compatibility issues, but typically these are easily overcome, such as by clicking through warnings about self-signed certificates.

Note

The best practice is to use HTTPS so only encrypted traffic is exchanged between the GUI and clients.

SSL/TLS Certificate¶

The SSL/TLS Certificate to be used by the GUI in HTTPS (SSL/TLS) mode.

The firewall automatically generates a default self-signed certificate on the first boot and again if a referenced certificate is missing. A self-signed certificate is not ideal, but it does still encrypt traffic and is better than communicating without encryption.

The primary disadvantage of a self-signed certificate is the lack of assurance of the identity of the host, since the certificate is not signed by a Certificate Authority trusted by the browser. Additionally, because for the bulk of Internet users such an invalid certificate should be considered a risk, modern browsers may restrict how such certificates are handled. Firefox, for example, displays a warning screen and forces the user to import the certificate and allow a permanent exception. Chrome shows a warning screen with a link to continue.

Tip

To use an externally signed SSL certificate and key, import them using the Certificate Manager, then select the certificate here.

Tip

The ACME Package can utilize the free Let’s Encrypt service to automatically obtain and update a signed certificate for the GUI or for other purposes on the firewall.

Tip

Another alternate technique is to generate a self-signed CA and then generate a GUI certificate from that CA. Export the CA from the firewall and then import that CA into client browsers manually. Using this method, all certificates signed by that CA will be trusted by browsers. Specifics vary by client platform.

Tip

To generate a new self-signed certificate for the GUI, connect using the console or ssh and from a shell prompt, run the following command:

# pfSsh.php playback generateguicert

TCP Port¶

The port upon which the GUI listens for incoming connections from browsers. By default the GUI uses HTTPS on port 443 with a redirect from port 80 for the best compatibility and ease of initial configuration. To change the port, enter a new port number into the TCP Port field.

Danger

Do not expose the GUI to untrusted networks such as the Internet even on non-default ports.

Some administrators move the GUI to an alternate port for security by obscurity reasons. Such practices should not be considered as offering any security benefit. It is trivial for port scanners to locate the service on any open port.

Tip

Moving the GUI to another port will free up the standard web ports for use with port forwards or other services such as HAProxy.

Max Processes¶

The number of web server worker processes used by the GUI when listening for client browser connections. The default value is 2.

If multiple administrators view the GUI at the same time and pages take too long to load, or are failing to load, then increase the Max Processes value.

WebGUI Redirect¶

Controls whether or not the firewall runs a redirect on port 80 so that if a browser attempts to access the firewall with HTTP, the firewall will accept the request and then redirect the browser to the TCP Port used by the GUI (e.g. HTTPS on port 443).

The redirect is enabled by default for ease of access and compatibility.

Disabling the redirect allows another daemon to bind to port 80.

HSTS¶

Controls whether the GUI web server sends the Strict-Transport-Security HTTPS response header (HSTS) to the browser. Check this box to disable the behavior.

HSTS forces the browser to use only HTTPS for any future requests to the firewall FQDN to ensure it does not accidentally downgrade to an unencrypted connection.

Warning

When disabling HSTS, clients which visited the GUI when HSTS was enabled must perform browser-specific steps for the change to take effect. Consult browser documentation for information on clearing cached HSTS behavior.

OCSP Must-Staple¶

Controls whether or not the GUI web server forcefully enables OCSP Stapling.

If the GUI SSL/TLS Certificate requires OCSP Stapling, this behavior is automatically enabled by the GUI web server. If the certificate property cannot be automatically determined by the firewall, this option can force the behavior.

Tip

Import the full CA and certificate chain or this option will be ignored by the GUI web server.

WebGUI Login Autocomplete¶

Controls whether or not the login form allows autocomplete so browsers can save login credentials locally, for convenience.

In high-security environments, such as those that must adhere to specific security compliance standards, that behavior is not acceptable.

Note

This only controls autocomplete on the login form.

Warning

Few modern browsers respect this option. Many still offer to save passwords even when the form specifies that the browser must not allow the behavior. This behavior must be controlled or changed using browser options.

GUI login messages¶

Lowers the system log level for successful GUI login events.

By default, login events are logged at an emergency level and on hardware with a PC speaker, these emergency console messages generate a beep from the speaker.

When this is checked, successful logins to the GUI will be logged as a lower non-emergency level. This lower level will not trigger console bells and may help with processing log events on remote syslog servers.

Note

Changing this option is not necessary if the only goal is suppressing speaker beeps. The console bell behavior can be controlled independently on the Notifications tab.

Anti-lockout¶

Controls whether or not the firewall adds special rules to permit access to the GUI port and SSH port on the LAN interface by default.

These special rules override user-defined filter rules and prevent the user from accidentally locking themselves out of the firewall GUI or SSH. To control which LAN IP addresses may access the GUI and SSH using firewall rules, disable the anti-lockout rules.

When two or more interfaces are present, the firewall puts anti-lockout rules on the LAN interface; If only one interface is configured, the firewall places rules on that interface instead.

Warning

Filter rules must be in place to allow GUI access before enabling this option! If the LAN rules do not allow access to the GUI, removing the anti-lockout rule will block access to the GUI, potentially leaving the administrator without a means to reach the firewall.

Note

Resetting the LAN IP address from the console also resets the anti-lockout rule. If administrative access is unavailable after enabling this option, choose the console menu option 2, then choose to set the LAN IP address, and enter in the exact same IP address and accompanying information.

DNS Rebind Check¶

Controls whether or not the DNS resolver or forwarder performs DNS rebinding checks. These checks prevent the firewall from receiving DNS responses containing private IP addresses from DNS servers to prevent DNS rebinding attacks.

Note

When accessing the firewall by IP address, these checks are not enforced because the attack is only relevant when using a hostname.

Check this box to disable DNS rebinding protection if it interferes with GUI access or name resolution.

Browser HTTP_REFERER enforcement¶

Controls whether or not the GUI checks and enforces HTTP_REFERER request header contents.

The GUI checks the referring URL sent by a client browser to ensure that the form was submitted from this firewall. This check prevents a form on another site from submitting a request to the firewall, changing an option when the administrator did not intend for that to happen.

This also breaks some convenience behaviors, such as having a page that links to various firewall devices, though the benefits of the check typically outweigh the advantage of those behaviors.

Alternate Hostnames¶

A list of Alternate Hostnames for the firewall allowed by DNS Rebind Checks and HTTP_REFERER Enforcement. To keep these features active, but alter their behavior slightly, add Alternate Hostnames.

By default the GUI allows access to the hostname configured on the firewall and all IP addresses configured on the firewall. Hostnames in this field are allowed by the firewall for GUI access and for referring URL purposes.

Browser Tab Text¶

By default the GUI prints the firewall hostname first in the page/tab title, followed by the page name. To reverse this behavior and show the page name first and hostname second, check Display page name first in browser tab.

Administrators who access many firewalls at the same time in separate tabs tend to prefer having the hostname first (default). Administrators who access one firewall with many pages in separate tabs may prefer having the page name first.

Secure Shell (SSH)¶

The Secure Shell (SSH) server provides remote console access and file management. A user can connect with any standard SSH client, such as the OpenSSH command line ssh client, PuTTY, SecureCRT, or iTerm2.

When using SSH, both the admin username and root username are accessible using the admin account credentials.

Users in the User Manager that have the User - System - Shell account access privilege are also allowed to login over SSH. These users do not have root access privileges, and do not print the menu when they login because many of the options require root privileges.

Tip

To grant users additional shell privileges, use the sudo package.

File transfers to and from the firewall are also possible by using a Secure Copy (SCP) client such as the OpenSSH command line scp, FileZilla, WinSCP or Fugu. To use SCP, connect as the root or admin user. If a custom user has the User - System - Copy files permission, or all access, then they may also utilize SCP.

Tip

SSH clients must be kept up-to-date. As time goes on, security standards evolve and the SSH server settings utilized by SSH servers will change. Outdated clients may not be able to connect using the strong security keys and algorithms required by sshd. If a client will not connect, check for an update from the vendor.

Enable Secure Shell¶

To enable the SSH daemon, check Enable Secure Shell. After saving with this option enabled, the firewall will generate SSH keys if they are not already present and then start the SSH daemon.

SSHd Key Only¶

This option controls which authentication methods the SSH daemon allows for clients. It can be set to one of the following values:

Password or Public Key:: Allows a user to authenticate with either a valid password or valid key. This is the default behavior.
Public Key Only:: Restricts authentication to only valid keys, passwords are not allowed.
Require Both Password and Public Key:: Requires a valid password and a valid key.

Key-based logins are a much more secure practice, though it does take more preparation to configure.

Add user keys for key-based login by editing users in the User Manager (User Management and Authentication). When editing a user, paste the allowed public keys into the Authorized Keys text field for the account.

Allow Agent Forwarding¶

Controls whether or not the SSH daemon allows agent forwarding for clients.

Agent forwarding allows a user to run an SSH agent on their client system and connect to the firewall, and then to other remote SSH servers using the key from their agent. In this case, the user does not need to have their private keys on the firewall but can still use key-based authentication to remote servers.

Use of an SSH agent can be considered a security issue in certain cases. Additionally, the firewall is not intended to be a general purpose SSH client or intermediate system, thus this feature is disabled by default.

SSH Port¶

Controls the port used by the SSH daemon to accept client connections. To change the port, type the new port into the SSH Port box.

Moving the SSH server to an alternate port provides a negligible security improvement, and frees up the port for other uses.

Tip

Brute force SSH scanners focus on hitting TCP port 22 but if the daemon is open to the Internet on another port, it will still be found and hit by scanners.

Best Practices for SSH¶

If this firewall is installed in an environment that requires leaving SSH access unrestricted by firewall rules, which is dangerous, the best practice is to take one of the following actions:

Change the SSH Port:: Moving to a random alternate port prevents log noise from many, but not all, brute-force SSH login attempts and casual scans. It can still be found with a port scan, however.
Force Key-Based Authentication:: Key-based authentication must always be used by publicly accessible SSH servers to eliminate the possibility of successful brute force attacks. Set SSHd Key Only to either Public Key Only or Require Both Password and Public Key.

Multiple unsuccessful logins from the same IP address will result in locking out the IP address trying to authenticate, but that alone is not considered sufficient protection.

Login Protection¶

pfSense software utilizes the sshguard daemon to protect against brute force logins for both the GUI and SSH connections. The options in this section fine-tune the behavior of this protection.

Threshold:

The total score value above which sshguard will block clients. Most attacks have a score of 10, the default threshold value is 30.

Blocktime:

The initial minimum number of seconds to block attackers who have exceeded the Threshold value. The default value is 120 seconds. Repeat offenders are blocked for increasingly longer amounts of time (1.5x for each repetition).

Note

Attackers are unblocked at random intervals so actual block time will be longer than stated. This prevents clients from predicting the timing to optimize targeted attacks.

Detection Time:

The amount of time, in seconds, attackers are remembered by sshguard since their last offense before it resets their score. Default is 1800 seconds.

Pass list:

A list of subnets which are excluded from login protection. This lowers security but is generally acceptable from specific secure management networks.

For example, it may be necessary to add entries for network monitoring systems which probe the SSH port but do not login. Otherwise such systems may be flagged as attackers.

Click fa-plus Add address to display additional form field lines for pass list entries.

Serial Communications¶

If the firewall hardware contains a hardware serial port, it can be used for a console connection. This is useful for running on hardware without video hardware or if it will be running “headless” (without keyboard and video attached). In these cases, the serial console can be enabled to maintain physical control, so long as the hardware has a viable serial port. The hardware visible to the operating system for such serial ports cannot be USB. Though some devices expose an external physical USB port dedicated to the console, typically such devices are wired to appear to the OS as a traditional non-USB serial port internally.

If hardware is detected which has no VGA port, the serial console is forced on and cannot be disabled, and the serial options are all hidden except for the speed.

Serial Terminal¶

When Serial Terminal is set, the operating system enables the console on the first serial port. This console will receive kernel boot messages and a menu after the firewall has finished booting. This will not disable the onboard keyboard and video console.

To connect to the serial console, use a null modem cable connected to a serial port or adapter on another PC or serial device.

Serial Console Speed¶

The default serial console speed is 115200 bps and almost all hardware works well at that speed. In rare cases, a slower speed may be required which can be set here by picking the desired speed from the Serial Speed drop-down.

When upgrading from an older version, this may remain at an older value such as 9600 or 38400 to match the BIOS on older hardware. Increasing the speed to 115200 is almost always safe and more useful than slower speeds.

Primary Console¶

On hardware with both the serial console enabled and a video port available, the Primary Console selector chooses which is the preferred console, so it will receive the boot log messages. Other OS kernel messages will show up on all console connections, and both consoles will have a usable menu.

In cases where the boot cannot complete, the preferred console must be used to resolve the problem, such as reassigning interfaces.

Console Menu¶

Normally the firewall always presents the menu on the console, and the menu will be available as long as someone has physical access to the console. In high-security environments this is not desirable.

This option adds password protection to the console. The console accepts the same usernames and passwords used to access the GUI. After setting this option, the firewall must be rebooted before it takes effect.

Note

While this will stop accidental key presses and keep out casual users, this is by no means a perfect security method. A knowledgeable person with physical access can still reset the passwords (see Forgotten Password with a Locked Console). Consider other physical security methods if console security is a requirement.