This chapter is useful only if you have made a distributed installation and created the SSH channels that will enable isba to launch remote commands on target hosts.

You will be able to do the following things from your management station:

To be able to perform the various remote management tasks, isba needs to know certain information on each target host a ruleset is made for:

1. the target hostname or IP address
2. the SSH user on this target
3. should this user run sudo for launching ipf commands ?
4. the ipfilter configuration directory on this target (e.g. /etc/opt/ipf)
5. the ipfilter filtering rules filename on this target (e.g. ipf.conf)
6. the ipfilter translating rules filename on this target (e.g. ipnat.conf)

This information is placed in the 'Ruleset targets' table in the Properties tab. Each ruleset has its own target definitions. For example:

A few remarks about the columns of this table:

Column 1: in the event that the target has several interfaces, you must place here the IP address that may be reached from the management station. If you put a hostname instead of an IP address, isba tries to resolve the name to an IP address first using the internal objects. It then looks in /etc/hosts if not found. In both cases the same remark applies: the resolved IP address must be reachable from the management station.

Column 2: this is the user that isba uses to run commands on the target host through SSH ("ssh user@target command"). It can either be root or an unpriviledged user, or it can be left empty: in this case, remote SSH commands are run under the user isba runs as.

Column 3: if the SSH user is set to root, the 'use sudo' flag is probably useless (uncheck it).

Columns 4, 5, 6: if you kept the default locations for ipfilter configuration files when you compiled ipfilter, you can quickly set the columns 4, 5 and 6 by using the default paths menu and selecting the OS of the target. For example, if your target runs Solaris, the default configuration directory and filenames are /etc/opt/ipf, ipf.conf and ipnat.conf.

Remote management features are found in the Target menu. The latter allows you to get or to send information from/to one of the ruleset targets (or even any other host). You can:

• see the ipf.conf/ipnat.conf files of a remote target
• see the current kernel rules of a remote target
• see the ipfilter logs in real time
• see the state table in real time
• revert to previous ruleset
• cancel a ruleset autorollback countdown
• immediately change the kernel rules to a "pass all" firewall
• immediately change the kernel rules to a "block all" firewall

The target menu

You can change the default target either from the Target menu, or from the 'Default target: xxxx' popup menu just above the rules. This menu appears only if your ruleset has more than one target. For example:

From the Target menu, you can also perform remote management tasks on machines other than the targets of your current ruleset. You select Target > [any remote mgt task] > other target ..., and a window pops up for you to specify the other-target information isba needs (name, IP address, SSH user, sudo flag, ipfilter config files).

Once these parameters are entered, isba remembers them (in your Preferences file) so that you may access them quickly: if you right-click the 'Target name' entry, you find here a menu with all machines you have already defined.

As you have already entered the above information for the targets of your rulesets, you don't have to enter it again: it show up automatically in the popup menu.

Remote managing other targets than your ruleset ones

We describe here the actions that may change the kernel ruleset on a target host.

The first action is the compilation-and-installation of an isba ruleset on a target. You do this from the Compile menu (see Installing on target).

Alternately, if the ruleset you just installed on your target behaves badly, you can instantly change it to a "pass all" or a "block all" ruleset ("Emergency pass all" and "Emergency block all" features). A popup window lets you confirm or cancel the operation.

Imagine you install a ruleset on a non-firewall machine (e.g. a server in a DMZ, that must be protected from its neighbours), and you realize it cuts an important data flow (e.g. it stops a running backup) ... "Emergency pass all" is your friend.

Or, you install a ruleset on a firewall, you're being probed and you realize you left a hole as big as a house ... "Emergency block all" is a fast means of filling the breach.

"Emergency block all" removes the ipf and ipnat rules and also cuts all current connections (it flushes the state table).

The "Emergency block all" ruleset is in fact a "block all but SSH from the management station": packets with source or destination port 22 between target and the management host are let through. So you can go on managing it.

• download the current ipfilter configuration files (ipf.conf and ipnat.conf)
• download the current kernel ipf and ipnat rules