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.
The protocol for connections between web browsers and the GUI. May be one of:
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.
The best practice is to use HTTPS so only encrypted traffic is exchanged between the GUI and clients.
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.
To use an externally signed SSL certificate and key, import them using the Certificate Manager, then select the certificate here.
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.
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
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
the best compatibility and ease of initial configuration. To change the port,
enter a new port number into the TCP Port field.
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.
Moving the GUI to another port will free up the standard web ports for use with port forwards or other services such as HAProxy.
The number of web server worker processes used by the GUI when listening for
client browser connections. The default value is
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.
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
The redirect is enabled by default for ease of access and compatibility.
Disabling the redirect allows another daemon to bind to port
Controls whether the GUI web server sends the
HTTPS response header (HSTS) to the browser. Check this box to disable the
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.
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.
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.
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.
This only controls autocomplete on the login form.
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.
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.
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.
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.
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.
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.
More detail on DNS rebinding attacks may be found on Wikipedia.
The most common case for disabling DNS rebinding checks is when the firewall is set to use an internal DNS server which will return private (RFC1918) answers for hostnames.
The DNS Resolver or Forwarder must be restarted after changing this option.
Browser HTTP_REFERER enforcement¶
Controls whether or not the GUI checks and enforces
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.
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
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
access privileges, and do not print the menu when they login because many of the
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
admin user. If a custom user
User - System - Copy files permission, or all access, then they may
also utilize SCP.
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.
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.
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
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.
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.
The total score value above which
sshguardwill block clients. Most attacks have a score of
10, the default threshold value is
The initial minimum number of seconds to block attackers who have exceeded the Threshold value. The default value is
120seconds. Repeat offenders are blocked for increasingly longer amounts of time (1.5x for each repetition).
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
sshguardsince their last offense before it resets their score. Default is
- 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 Add address to display additional form field lines for pass list entries.
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.
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.
When making any changes to the serial console, the firewall must be rebooted before they take effect.
In some systems booting via EFI, the serial console can be activated or deactivated without a reboot.
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.
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.