Most of the questions regarding the Security Servers are specific to each Security Server used. However, a few questions relate to the use of Security Servers in general. These FAQs cover such issues.
If you're familiar with FireWall-1 4.1 and earlier versions, you know that whenever the Security Servers were used, all connections through them appeared to come from the firewall. Some administrators designed their networks around this feature. In FireWall-1 NG, the firewall no longer appears to originate these connections, so designs that rely on packets originating from the firewall no longer hold true. To get the old behavior back, do one of two things:
Create NAT rules hiding the communications behind the firewall's IP address. (NAT is discussed in Chapter 10.)
Change a few parameters by using dbedit or by manually editing objects_5_0.C. (See FAQ 4.2 for details.) The parameters in question are in the firewall object properties: http_transparent_server_connection, ftp_transparent_server_connection, rlogin_transparent_server_connection, and telnet_transparent_server_connection. An example of how to edit these settings is shown below. Note that craig is the name of my firewall object.
dbedit> modify network_objects craig firewall_settings:http_transparent_server_connection false dbedit> update network_objects craig
The notable exception to all of this is the SMTP Security Server, which still functions as it did in FireWall-1 4.1 and earlier.
In this situation, a prior rule using the Security Servers needed evaluation by the Security Server in order to determine whether or not the rule applied. Refer to Figure 9.11 earlier in this chapter for an example.
If the connection originates from the internal network and requires HTTP, the Security Server becomes involved because it must determine whether or not the URL meets the criteria specified in the resource. If it does, the connection is rejected. If not, the HTTP is allowed by the second rule. However, because the packet required evaluation by the HTTP Security Server to determine that it did not meet the previous rule's criteria, the HTTP Security Server processes the connection even though the second rule does not explicitly use a resource.
If you want to ensure that the Security Server is not used in a particular case, you need to place a rule above any other rules that avoids using the Security Servers (i.e., no resources or User Authentication).
For HTTP and FTP, yes. Simply use an action of User Authentication where it is appropriate.
No, you cannot. The Security Servers are required for Content Security anyway, so it makes no sense to use the Session Authentication in conjunction with Content Security. You can certainly use Session Authentication for other services, just not the ones where Content Security is required.