Alternate Remote Backup Techniques¶
The following techniques may also be used to perform backups remotely, but each method has its own security issues which may rule out their use in many places. For starters, these techniques do not encrypt the configuration, which may contain sensitive information. This can result in the configuration being transmitted over an unencrypted, untrusted link. If one of these techniques must be used, it is best to do so from a non-WAN link (LAN, DMZ, etc.) or across a VPN. Access to the storage media holding the backup must also be controlled, if not encrypted. The AutoConfigBackup package is a much easier and more secure means of automating remote backups.
Pull with wget¶
The configuration may be retrieved from a remote system by using
wget , and
this process can be scripted with cron or by other means. Even when using HTTPS,
this is not a truly secure transport mode since certificate checking is disabled
to accommodate self-signed certificates, enabling man-in-the-middle attacks.
When running backups with
wget across untrusted networks, use HTTPS with a
certificate that can be verified by
On pfSense 2.2.6 and later, the wget command must be split into multiple steps to handle the login procedure and backup download while also accounting for CSRF verification.
For a firewall running HTTPS with a self-signed certificate, the command would be as follows:
Fetch the login form and save the cookies and CSRF token:
$ wget -qO- --keep-session-cookies --save-cookies cookies.txt \ --no-check-certificate https://192.168.1.1/diag_backup.php \ | grep "name='__csrf_magic'" | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
Submit the login form along with the first CSRF token and save the second CSRF token:
$ wget -qO- --keep-session-cookies --load-cookies cookies.txt \ --save-cookies cookies.txt --no-check-certificate \ --post-data "login=Login&usernamefld=admin&passwordfld=pfsense&__csrf_magic=$(cat csrf.txt)" \ https://192.168.1.1/diag_backup.php | grep "name='__csrf_magic'" \ | sed 's/.*value="\(.*\)".*/\1/' > csrf2.txt
Now the script is logged in and can take action. Submit the download form along with the second CSRF token to save a copy of
$ wget --keep-session-cookies --load-cookies cookies.txt --no-check-certificate \ --post-data "Submit=download&donotbackuprrd=yes&__csrf_magic=$(head -n 1 csrf2.txt)" \ https://192.168.1.1/diag_backup.php -O config-hostname-`date +%Y%m%d%H%M%S`.xml
Replace the username and password with the credentials for the firewall, and the
IP address would be whichever IP address is reachable from the system performing
the backup, and using HTTP or HTTPS to match the firewall GUI. To backup the
RRD files, omit the
&donotbackuprrd=yes parameter from the last command.
The system performing the backup will also need access to the WebGUI, so adjust the firewall rules accordingly. Performing this over the WAN is not recommended. At a minimum, use HTTPS and restrict access to the WebGUI to a trusted set of public IP addresses. It is preferable to do this locally or over a VPN.
Push with SCP¶
The configuration file can also be pushed from the pfSense firewall to another
UNIX system with
scp to push a one-time backup by hand can be
useful, but using it in an automated fashion carries some risks. The command
scp will vary depending on the system configuration, but will be
close to the following:
# scp /cf/conf/config.xml \ user@backuphost:backups/config-`hostname`-`date +%Y%m%d%H%M%S`.xml
In order to push the configuration in an automated manner, generate an SSH key without a passphrase. Due to the insecure nature of a key without a passphrase, generating such a key is left as an exercise for the reader. This adds risk due to the fact that anyone with access to that file has access to the designated account, though because the key is kept on the firewall where access is restricted, it isn’t a considerable risk in most scenarios. If this is done, ensure the remote user is isolated and has little to no privileges on the destination system.
scp environment may be desirable in this case. The
shell is available for most UNIX platforms which allows SCP file copies but
denies interactive login capabilities. Some versions of OpenSSH have chroot
support built in for sftp (Secure FTP). These steps greatly limit the risk of
compromise with respect to the remote server, but still leave the backed up data
at risk. Once access is configured, a cron entry could be added to the pfSense
system to invoke
scp. For more details visit the
pfSense Documentation Wiki or search on the forums.
Basic SSH backup¶
Similar to the
scp backup, there is another method that will work from one
UNIX system to another. This method does not invoke the SCP/SFTP layer, which in
some cases may not function properly if a system is already in a failing state:
$ ssh email@example.com cat /cf/conf/config.xml > backup.xml
When executed, that command will yield a file called
backup.xml in the
current working directory that contains the remote pfSense firewall
configuration. Automating this method using cron is also possible, but this
method requires an SSH key without as passphrase on the host performing the
backup. This key will enable administrative access to the firewall, so it must
be tightly controlled. (See Secure Shell (SSH) for details.)