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, available with a pfSense Gold Subscription, 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 wget.

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 config.xml:

    $ 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. Using scp to push a one-time backup by hand can be useful, but using it in an automated fashion carries some risks. The command line for 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.

A chrooted scp environment may be desirable in this case. The scponly 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 root@192.168.1.1 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.)