Using Built-in Policy Installer in Firewall Builder - Page 2

Configuring installer to use regular user account to manage the firewall

Before v3.0.4 built-in installer could only use regular account to activate policy if this account was configured on the firewall to use sudo without password. Starting with v3.0.4 this is not necessary anymore because installer can recognize sudo password prompts and enter password when needed.

• Create an account on the firewall (say, "fwadmin"), create a group "fwadmin" and make this user a member of this group. Most modern Linux systems automatically create group with the name the same as the name of the user account.

  useradd fwadmin

• Create directory /etc/fw/ on the firewall, make it belong to group fwadmin, make it group writable

  mkdir /etc/fw
  chgrp fwadmin /etc/fw
  chmod g+w fwadmin /etc/fw

• Configure sudo to permit user fwadmin execute firewall script and a couple of other commands used by fwbuilder policy installer. Run visudo on the firewall to edit file /etc/sudoers as follows:

  Defaults:%fwbadmin   !lecture , passwd_timeout=1 , timestamp_timeout=1
  # User alias specification
  %fwbadmin  ALL = PASSWD: /etc/fw/<FWNAME>.fw , /usr/bin/pkill , /sbin/shutdown
   

  here <FWNAME> is the name of the firewall. Installer will log in to the firewall as user fwadmin, copy firewall script to file /etc/fw/<FWNAME>.fw and then use the following command to execute it:

  ssh fwadmin@firewall sudo -S /etc/fw/<FWNAME>.fw

  Installer needs to be able to run pkill shutdown to kill shutdown command that may be running if you tried to install policy in testing mode before. In testing mode installer copies firewall script to temporary directory /tmp then runs command shutdown -r timeout to schedule reboot in a few minutes and finally runs firewall script. To cancel scheduled reboot you need to install policy again, with test mode checkbox turned off. In this case installer will copy firewall script to its permanent place and use pkill to kill running shutdown command to cancel reboot.

• set up ssh access to the firewall. Make sure you can log in as user fwadmin using ssh from your management workstation:

  $ ssh -l fwadmin <FWNAME>

  You may use either password or public key authentication; the installer will work either way. Use putty.exe or plink.exe to test ssh access if you are on Windows (see above for the explanation how to do this on Windows).

• in the "installer" tab of the "firewall settings" dialog of the firewall object put user name you use to log in to the firewall (here it is "fwadmin"):

  

• if you need to use alternative name or IP address to communicate with the firewall, put it in the corresponding field in the same dialog page
• Make sure entry field "directory on the firewall where script should be installed" is set to /etc/fw. Firewall Builder is not going to create this directory, so you need to create it manually before you install firewall policy (see above).
• Leave "Policy install script" and "Command line options" fields blank.

Configuring installer if you use root account to manage the firewall

• Create directory /etc/fw/ on the firewall, make it belong to root, make it writable
• set up ssh access to the firewall. Make sure you can log in as root using ssh from your management workstation:

  $ ssh -l root <firewall_name>

  You may use either password or public key authentication; the installer will work either way.
• in the "installer" tab of the "firewall settings" dialog of the firewall object put "root" as the user name you use to log in to the firewall
• Make sure entry field "directory on the firewall where script should be installed" is set to /etc/fw
• Leave "Policy install script" and "Command line options" fields are blank

Configuring installer if you regularly switch between Unix and Windows workstations using the same .fwb file and want to manage the firewall from both

First of all, the .fwb file is portable and can be copied back and forth between Linux/BSD and windows machines. Even comments and object names entered in local language should be preserved since the GUI uses UTF-8 internally.

Built-in installer relies on path settings for ssh and scp in Edit/Preferences/SSH. Since preferences are stored outside of the .fwb file, the installer should work just fine when .fwb file is copied from Unix to Windows and back. Just configure path to ssh program in preferences on each system using default settings "ssh" on Linux and path to plink.exe on windows and give it a try.

Always permit SSH access from the management workstation to the firewall

One of the typical errors that even experienced administrators make sometimes is block ssh access to the firewall from the management workstation. You need your workstation to be able to communicate with the firewall in order to be able to make changes to the policy, so you always need to add a rule to permit this. Firewall Builder can simplify this and generate this rule automatically if you put an IP address of your workstation in the entry field on the first page of firewall settings dialog. Here is the screenshot that illustrates this setting for an iptables firewall; management station has an IP address 192.168.1.100

Using putty sessions on Windows

putty allows one to store destination host name or address, user name and bunch of other parameters in a session so that they all can be called up at once. If you wish to use sessions, do the following:

• Configure putty as usual, create and test session for the firewall, test it using putty outside of the Firewall Builder. When you use session, firewall host name and user name are stored in the session file. Firewall Builder allows you to enter session name in the entry field in the firewall settings dialog where you would normally enter alternative address of the firewall. Comment next to the entry field reminds you about this. Just type session name in that field, leave user name field blank and save the settings.
• Once you start the installer, do not enter user name in the "User name" field on the first page of installer wizard, however you need to enter the login and enable passwords. Configure the rest of installer options as usual, they do not change when you use putty sessions.

How to configure installer to use alternative ssh port number

If ssh daemon on your firewall is listening on an alternative port, then you need to configure built-installer so that it will run scp and ssh clients with command line parameters that would make them connect to this port. This is done in the "installer" tab of the firewall object "advanced" settings dialog as shown on the following screenshot (here we set the port to "2222"):

On Unix command line option that specifies port number is different for ssh and scp. It is lowercase -p for ssh and uppercase -P for scp. If you use putty tools plink.exe and pscp.exe on Windows, the option to specify alternative port number is -P (capital "P") for both.

You can use the same input fields in this dialog to add any other command line parameters for ssh and scp, for example this is where you can confiugre parameters to make it use alternative identity file (private keys). This information is saved with a firewall object rather than globally because you may need to use different parameters for different firewall machines, such as different key files or ports.

How to configure installer to use ssh private keys from a special file

You can use the same entry fields in this dialog to provide other additional command line parameters for ssh and scp, for example to use keys from a different identity file. Here is how it looks like:

Here I configure ssh and scp to use alternative port and alternative identity file ~/.ssh/fwadmin_identity. The command line parameter for the port is different for ssh and scp, but parameter for the identity file is the same -i for both utilities.

On Windows, the simplest way (or may be the only way) to use alternative keys is to use putty sessions.

Troubleshooting ssh access to the firewall

Built-in policy installer will not work if ssh access to the firewall is not working. Test it using this command on Linux if use you user "fwadmin" to manage firewall:

ssh -l fwadmin firewall

If you use root account to manage the firewall, the command becomes

ssh -l root firewall

On Windows use putty.exe or plink.exe to do this:

C:\Users\vadim>c:\PuTTY\plink.exe -l fwadmin firewall

C:\Users\vadim>c:\PuTTY\plink.exe -l root firewall

If you can not log in using ssh at this point, verify that ssh daemon is working on the firewall, that existing firewall policy does not block ssh access and ssh daemon configuration in /etc/ssh/sshd_config permits login for root (if you plan to use root account to manage the policy).