Admin Access Tab¶
The options found on the Admin Access tab govern the various methods for administering the firewall, including via the web interface, SSH, serial, and physical console.
The WebGUI Protocol may be set to either HTTP or HTTPS. The best practice is to use HTTPS so that traffic to and from the WebGUI is encrypted.
If HTTPS is chosen, a certificate must also be chosen from the SSL Certificate drop-down list. The default certificate is an automatically-generated self-signed certificate. That is not an ideal situation, but is better than no encryption at all.
To use an externally signed SSL certificate and key, import them using the Certificate Manager, then select the certificate here.
The main downside to using a custom self-generated 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 have been cracking down on how they are handled. Firefox, for example, gives a warning screen and forces the user to import the certificate and allow a permanent exception. Internet Explorer will show a warning screen with a link to continue, as does Chrome. Opera will show a warning dialog.
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
Moving the WebGUI to an alternate port is preferred by some administrators for
security by obscurity reasons, though such practices should not be considered as
offering any security benefit. Moving the GUI to another port will free up the
standard web ports for use with port forwards or other services such as a
HAproxy. By default the WebGUI uses HTTPS on port
443 with a redirect from
80 for the best compatibility and ease of initial configuration. To
change the port, enter a new port number into the TCP Port field.
If multiple administrators view the GUI at the same time and pages are taking
too long to load, or failing to load, then increase the Max Processes value. By
default it is set to
2, so the firewall runs two web server worker
By default, for ease of access and compatibility, 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 HTTPS on port 443. This redirect can be disabled by checking Disable webConfigurator redirect rule. Disabling the redirect also allows another daemon to bind to port 80.
WebGUI Login Autocomplete¶
For convenience, the login form allows autocomplete so browsers can save the login credentials. In high-security environments, such as those that must adhere to specific security compliance standards, this behavior is not acceptable. It can be disabled by checking Disable webConfigurator login autocomplete. This only controls autocomplete on the login form.
Few browsers respect this option. Many of them will still offer to save passwords even when the form specifies that it should not be allowed. This behavior must be controlled or changed using browser options.
WebGUI login messages¶
Successful logins result in a message being printed to the console, and on some hardware these console messages cause a “beep” to be heard from the device. To stop this log message (and the resulting beep), check Disable logging of webConfigurator successful logins.
Access to the WebGUI port and SSH port on the LAN interface is permitted by default regardless of user-defined filter rules, due to the anti-lockout rule. When two or more interfaces are present, the anti-lockout rule is active on the LAN interface; If only one interface is configured, the anti-lockout rule will be active on that interface instead.
Checking Disable webConfigurator anti-lockout Rule removes the automatic lockout prevention rule. With that rule disabled, it is possible to control which LAN IP addresses may access the WebGUI using firewall rules.
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 system console also resets
the anti-lockout rule. If administrative access is locked out after enabling
this, 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¶
The firewall blocks private IP address responses from configured DNS servers by default, to prevent DNS rebinding attacks. Check this box to disable DNS rebinding protection if it interferes with webConfigurator access or name resolution.
More detail on DNS rebinding attacks may be found on Wikipedia.
The most common case for disabling this would be when the firewall is set to use an internal DNS server which will return private (RFC1918) answers for hostnames. When accessing the firewall by IP address, these checks are not enforced because the attack is only relevant when using a hostname.
Browser HTTP_REFERER enforcement¶
The GUI checks the referring URL when it is accessed to prevent 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 desirable convenience behavior, such as having a page that links to various firewall devices. To disable this behavior, check Disable HTTP_REFERER enforcement check.
To keep DNS Rebind Checks and HTTP_REFERER Enforcement active, but control their behavior slightly, fill in Alternate Hostnames in the box. By default the system will allow access to the hostname configured on the firewall and all IP addresses configured on the firewall. Adding hostnames in this field will allow those hostnames to be used for GUI access and for referring URL purposes.
If a browser attempts to access the GUI using an IP address that is not configured on the firewall, such as a port forward from another firewall, a message will be printed that indicating that access to the firewall may be compromised due to a Man-In-The-Middle (MITM) attack.
If such a forwarding was deliberately configured on the firewall or on a firewall ahead of this one, the message may be safely ignored. If access to the firewall should have been direct, then take great care before logging in to ensure the login credentials are not being routed through an untrusted system. Access is not disabled in this case, only a warning, so there is no option to disable this behavior.
Browser Tab Text¶
By default, the firewall 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 tend to prefer having the page name first.
Secure Shell (SSH)¶
The Secure Shell (SSH) server can be enabled which allows 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 iTerm. To login to the
admin account, either the
admin username or
root account may be used,
and both accept the admin WebGUI password for login.
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.
To grant users additional shell privileges, use the
File transfers to and from the pfSense firewall are also possible by using a
Secure Copy (SCP) client such as OpenSSH’s command line
WinSCP or Fugu. To use SCP, connect as the
root user, not
admin. If a
custom user has the
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 pfSense will change.
Outdated clients may not be able to connect using the strong security keys
and algorithms required by
sshd on pfSense. 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.
SSH can be configured to only allow key-based logins and not a password. Key-based logins are a much more secure practice, though it does take more preparation to configure.
To force key-based authentication, check Disable Password login for Secure Shell.
User keys for key-based login are added 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 their account.
Moving the SSH server to an alternate port provides a negligible security improvement, and frees up the port for other uses. To change the port, type the new port into the SSH Port box.
Brute force SSH scanners focus on hitting TCP port 22 but if the daemon is open to the Internet on another port, it will eventually 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, we strongly recommended moving the SSH service to an alternate random port and forcing key-based authentication. Moving to an alternate port will prevent log noise from many, but not all, brute-force SSH login attempts and casual scans. It can still be found with a port scan, so switching to key-based authentication must always be done on every publicly accessible SSH server to eliminate the possibility of successful brute force attacks.
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.
If pfSense is running on hardware without a monitor or if it will be running “headless” (without keyboard and video attached), then the serial console can be enabled to maintain physical control, so long as the hardware has a serial port (not USB).
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 console is enabled on the first serial port. This console will receive the 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.
Serial Console Speed¶
The default serial console speed is 115200bps 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 VGA port available, the Primary Console selector chooses which is the preferred console, so it will receive the boot log messages from pfSense. 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.