Alternate Remote Backup Techniques

The easiest method to make secure and encrypted remote backups of the pfSense® software configuration is the free Using the AutoConfigBackup Service service. Rest easy knowing it is taking care of handling remote backups automatically without needing to worry. Sit back, have a cup of coffee, and read on for alternate techniques.

The other techniques in this document perform backups remotely, but each method has its own security issues which may rule out their use. For starters, several of these techniques do not encrypt the configuration, which may contain sensitive information. This can result in the raw 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.

Pull

Pulling the configuration means to use a remote client to “pull” the configuration off of the firewall. The methods in this section accomplish the same goal using different utilities.

Pull with wget

The wget utility can retrieve the configuration from a remote firewall. This process can be scripted with cron or by other means to automate the process.

Warning

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.

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 commands are 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 (can’t reuse the same file) – now the script is logged in and can take action:

    $ 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
    
  • 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 "download=download&donotbackuprrd=yes&__csrf_magic=$(head -n 1 csrf2.txt)" \
      https://192.168.1.1/diag_backup.php -O config-router-`date +%Y%m%d%H%M%S`.xml
    

Note

The behavior of variable expansion and other aspects of the commands may vary by shell. This example uses bash for the client shell.

Replace the username and password with the credentials for the firewall, and the IP address is whichever IP address is reachable from the client performing the backup, and using HTTP or HTTPS to match the firewall GUI.

There are additional parameters which can control the contents of the backup in several ways:

  • To backup the RRD files, remove the &donotbackuprrd=yes parameter from the post data string on the last command.

  • To include extra data such as DHCP leases and captive portal databases, add &backupdata=yes to the post data string on the last command.

  • To include the SSH keys for the firewall, add &backupssh=yes to the post data string on the last command.

The client performing the backup will also need access to the GUI, so adjust the firewall rules accordingly. Performing this type of backup over an Internet-connected WAN is not secure. At a minimum, use HTTPS and restrict access to the GUI to a trusted set of public IP addresses. A better practice is to do this locally or over a VPN.

Using cURL

The same task can be accomplished using cURL instead of wget:

  • Fetch the login form and save the cookies and CSRF token:

    $ curl -L -k --cookie-jar cookies.txt \
         https://192.168.1.1/ \
         | grep "name='__csrf_magic'" \
         | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
    
  • Submit the login form to complete the login procedure:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \
         --data-urlencode "login=Login" \
         --data-urlencode "usernamefld=admin" \
         --data-urlencode "passwordfld=pfsense" \
         --data-urlencode "__csrf_magic=$(cat csrf.txt)" \
         https://192.168.1.1/ > /dev/null
    

    Now the script is logged in and can perform actions!

  • Fetch the target page to obtain a new CSRF token:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \
         https://192.168.1.1/diag_backup.php  \
         | grep "name='__csrf_magic'"   \
         | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
    
  • Download the backup:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \
         --data-urlencode "download=download" \
         --data-urlencode "donotbackuprrd=yes" \
         --data-urlencode "__csrf_magic=$(head -n 1 csrf.txt)" \
         https://192.168.1.1/diag_backup.php > config-router-`date +%Y%m%d%H%M%S`.xml
    

Note

The behavior of variable expansion and other aspects of the commands may vary by shell. This example uses bash for the client shell.

There are additional parameters which can control the contents of the backup in several ways:

  • To backup the RRD files, remove the --data-urlencode "donotbackuprrd=yes" \ parameter from the last command.

  • To include extra data such as DHCP leases and captive portal databases, add --data-urlencode "backupdata=yes" \ to the last command.

  • To include the SSH keys for the firewall, add --data-urlencode "backupssh=yes" \ to the last command.

Push with SCP

The scp command can push the configuration file from the firewall to another host. Using scp to push a one-time backup by hand can be useful, but using it in an automated fashion carries risks. The command line for scp varies 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

Pushing the configuration in an automated manner requires the firewall administrator to 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. 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 firewall to invoke scp.

A summary of the setup is as follows:

  • Generate an ssh key for the root user on the firewall without a passphrase. (Warning: dangerous!)

  • Add a user to a remote system, and add the new public key to its ~/.ssh/authorized_keys file

  • Create a cron job on the firewall that would copy /cf/conf/config.xml to the remote system with scp

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 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.)