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.
Configuring installer if you use root account to manage the firewall
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:
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).