M Firewall Security Option

The firewall-secure option enables the running of ACSLS behind a firewall while the client software makes requests across that firewall.

Firewall security is also offered to ACSLS clients, allowing them to operate behind their own respective firewalls. This is made available by Oracle to its Independent Software Vendor (ISV) partners. Contact the ISV for your client software component to find out the latest status for each specific client.

Running ACSLS behind a Firewall

This Firewall-Secure solution provides the following benefits:

• Enables ACSLS to run behind a firewall (that is, ACSLS on the secure side of firewall, client on opposite side).

• Enables ACSLS client(s) to run behind their own firewall(s) (that is, client(s) on secure side, ACSLS on the opposite side of firewall).

  Note:

  The ISV must have implemented the supplied changes within their client-side software component.

• Preserves compatibility with current ACSLS client implementations, allowing those clients to continue to run with ACSLS in the firewall solution.

• Preserves current ACSAPI/Client functionality and performance. This includes all functionality that is available in a non-firewall environment.

A complete solution would include combining the first two capabilities above. This enables ACSLS and the ACSLS client(s) to each run behind their own respective firewalls (that is, two firewalls between ACSLS and the client(s)), and still have the same communications performance as within a non-firewall environment.

Addressing Security Areas

ACSLS has addressed the following security concerns:

RPC

The use of RPC within ACSLS is a concern for some sites in trying to run within a firewall environment. Preserving compatibility with the current installed client base precludes the ability to remove RPC completely from the ACSLS.

The ACSLS firewall-secure feature has addressed the concerns inherent in RPC, which are:

• The need to allow outside (untrusted) parties to initiate connections to the trusted host across an unrestricted range of ports (1024-65535).

• The exposure of the mapping of available services on a platform through the portmap (or rpcbind) daemon running on well-known port 111.

Security

In a firewall solution, the fundamental security comes from restricting access from the non-secure side into the trusted (secure) side. In all cases, some limited and controlled access must be allowed in order to perform communications and allow data exchange. The goal is to allow that data exchange within a well-defined and restricted set of entry points, allowing you to control those access points and their corresponding communications. This goal is met by this solution.

Note:

If you have an IPv4-based edge firewall, it should be configured to drop all outbound IPv4 protocol 41 packets and UDP port 3544 packets to prevent Internet hosts from using any IPv6-over-IPv4 tunnelled traffic to reach internal hosts.

Communications Components

ACSLS/Client communications rely on two network interface components to handle network communications between client platforms and the ACSLS platform. Software acting as a client or proxy-server for ACSLS implements one of these two components in order to be compatible with ACSLS platforms and existing clients. The component residing on the client platform is known as the SSI; the component residing on the ACSLS platform is known as the CSI. While it would be desirable to implement all changes within one side (such as the ACSLS platform), in order to maintain client compatibility and to provide all of the firewall-secure features, it is necessary that corresponding changes be made to each side to get the benefits. The positive, is that each side can independently implement the features and achieve the firewall-secure benefits on its own side (such as, changes to the ACSLS allow the ACSLS platform to run behind a secured firewall).

Benefits of the Firewall-Secure Option

This section describes the benefits of the Firewall-Secure option.

ACSLS Server-Side

With changes to just the server-side component, as provided within this Firewall-Secure solution, the benefits include:

• Restricting incoming connections for ACSLS communications to a single TCP port for all registered program numbers (there are two registered program numbers for the ACSLS CSI, both of which will be serviced by one single port).

• Allowing users to specify the identity of that port, and configure their firewall in a corresponding fashion.

• Allowing users to turn-off ACSLS communications to UDP ports.

• Allowing users to disable any communication by the ACSLS server to the client-side portmapper(s)* (UDP/TCP port 111). The portmapper must still remain running on client platforms to preserve compatibility with client side code. However, it will not be used for network communications initiated by the server, and therefore, the clients' firewall(s) can be configured to disallow access to it.

• Outgoing connections from the ACSLS server side to the client(s) are unrestricted, for the server-side ports used to preserve current performance. This follows the widely accepted practice by the security community.

ACSLS Server Port Restriction

This firewall solution restricts the number of incoming ports through which an outside party can initiate network communication. The ports are limited to either one or three: the single customer-specified port for ACSLS incoming requests, plus, possibly, the two portmapper ports (TCP and UDP port 111).

Note:

To disallow client access to the ACSLS server portmapper, thus, disallow access to UDP and TCP ports 111, changes must be made to the client software component. See the client-side discussion below.

The server-side of the solution, above, is implemented completely within ACSLS.

Client-Side (CSC)

The changes made to the CSC place identical restrictions on the client-side platform to those described above. This gives the CSC an identical capability to reside behind its own secure firewall. This solution provides the following benefits:

• Restricts incoming connections for communications (response) to the CSC to a single TCP port for each registered program number. There is one registered program number for the ACSLS SSI.

• End-users can specify the identity of the TCP port and configure their firewall similarly.

• Turns-off client-side communications to UDP ports.

• Disables any communication by the client to the ACSLS server portmapper (UDP/TCP port 111). The portmapper must still remain running on the ACSLS platform to preserve compatibility with ACSLS code. However, client network communications are not initiated through the portmapper. Therefore, the ACSLS server firewall can be configured to disallow access to it.

• Outgoing connections from the client side to the ACSLS server are unrestricted for the client-side ports used to preserve current performance.

Client Port Restriction

This solution restricts the number of incoming ports through which an outside party can initiate network communication. The ports are limited to either one or three: the single customer-specified port for client incoming responses, and possibly the two portmapper ports (TCP and UDP port 111).

Note:

To disallow ACSLS server access to the client's portmapper (and thus disallow access to UDP and TCP ports 111), the changes must be made to the ACSLS server software component (see ACSLS server-side discussion above).

This solution has a two-step implementation:

• Oracle StorageTek has made the needed code changes to the CSC Developer's Toolkit 2.3 (or later) source code.

• Clients of ACSLS wanting to provide this security for their client platform must integrate these changes into their client-side SSI code, rebuild the product, and again certify their Client System Component (CSC) with ACSLS.

Advantages

The client-side and server-side parts of the solution are independent. Therefore, if only one of the two sides is behind a firewall, with respect to the other side, the software changes need to be implemented only on that side. In addition, changing only one side maintains compatibility with all current client and server implementations which already exist and compatibility with other software components which use the CSI/SSI interface.

Note:

This includes compatibility with current Oracle StorageTek products.

This solution does not impact current performance for client/server communications.

Turning on Firewall Secure Features and Setting Variables

To run the ACSLS server behind a firewall, and, optionally, the ACSLS Client behind a firewall, set variables on both of the ACSLS server and the Client system when they are behind a firewall. These variables enable you to restrict incoming communication to a single port, and optionally, disable the portmapper.

ACSLS Variables

CSI_TCP_RPCSERVICE - Enable CSI support for RPC using the TCP protocol.

• Function: Enables the CSI to operate as a TCP RPC Server. If any clients want to communicate with ACSLS over TCP, set this option to TRUE.

• Valid Options: TRUE or FALSE (TRUE is the default.)

  • TRUE enables TCP access for clients to the CSI.

  • FALSE disables TCP access for clients to the CSI.

• Other Details: The ACSLS product must be restarted for this option to take effect.

CSI_UDP_RPCSERVICE - Enable CSI support for RPC using the UDP protocol.

• Function: Selecting this option enables the CSI to operate as a UDP RPC Server. If any clients want to communicate with ACSLS over UDP, set this option to TRUE.

• Valid Options: TRUE or FALSE (FALSE is recommended.)

  • TRUE enables UDP access for clients to the CSI.

  • FALSE disables UDP access for clients to the CSI.

• Other Details: The ACSLS product must be restarted for this option to take effect. The firewall-secure CSI is only supported for TCP communications. Set CSI_UDP_RPCSERVICE to FALSE, unless you have legacy client applications inside the firewall with the ACSLS server.

CSI_USE_PORTMAPPER – Enable the portmapper.

• Function: Selecting this option causes the CSI to interrogate the portmapper when it cannot send a response to a client. If you do not want to allow access to the portmapper on the client, set this option to ALWAYS.

• Valid Options: ALWAYS, NEVER, or IF_DUAL_LAN_NOT_ENABLED

  • ALWAYS means that the portmapper should always be interrogated when the CSI cannot send a response to a client.

  • NEVER means that the portmapper should never be interrogated when the CSI cannot send a response to a client. This option should be selected if clients do not support a port mapper.

  • IF_DUAL_LAN_NOT_ENABLED specifies that the portmapper should be interrogated only if dual LAN support has not been enabled. If dual LAN support has been enabled, then it is assumed that clients do not support a port mapper. IF_DUAL_LAN_NOT_ENABLED is the default for backward compatibility.

• Other Details: The ACSLS product must be restarted for this option to take effect.

CSI_FIREWALL_SECURE - Enable the CSI to be used behind a firewall (with a user-defined inbound port).

• Function: This option enables the ACSLS server to operate behind a secured firewall. Specify the inbound port used by the ACSLS and limit access to a single port. Configure the firewall to reject incoming ACSLS traffic on all but that port. This ensures that only that port is exposed for use by those outside clients wanting to initiate communications with ACSLS.

  To restrict port access, complete the following steps to set up the secure firewall for a specified port:

  • Set this option to TRUE.

  • Specify the port to be used by the CSI on which incoming ACSLS requests are allowed. (Specified by CSI_INET_PORT.)

  • For some legacy client applications that do not support fixed port RPC, opening UDP/TCP port 111 in the firewall may be required to support portmapper query requests from the client.

  • The firewall-secure CSI is only supported for TCP communications.

    Set CSI_UDP_RPCSERVICE to FALSE unless you have legacy client applications inside the firewall with the ACSLS server.

  • Configure the firewall behind which the ACSLS server resides to allow external clients to initiate and receive communications on the previously specified port. Do not forget to set up fixed port on the client application with the same port to minimize open firewall ports.

  • Restart ACSLS.

• Valid Options: TRUE or FALSE (Default is TRUE)

  • TRUE – Restrict access to the ACSLS server to only use a single port for incoming requests from clients.

  • FALSE – Do not restrict ports used for client requests to the ACSLS server.

• Other Details: The ACSLS product must be restarted for this option to take effect.

CSI_INET_PORT - Port number used by the CSI to receive incoming ACSLS requests.

• Function: This option specifies the port used by the CSI for incoming TCP requests from clients.

• Valid Options: A number between 1024 and 65535, but not 50003. (Default is 30031)

• Other Details: The ACSLS product must be restarted for this option to take effect. This variable is only used when firewall-secure CSI is enabled with CSI_FIREWALL_SECURE and is set to TRUE.

Displaying and Setting ACSLS Variables

Use the ACSLS acsss_config utility or the dv_config utility to display, and set the ACSLS static and dynamic variables:

• dv_config –d

  Displays all of the ACSLS static and dynamic variables and their settings.

• dv_config -p <variable_name>  -u

  Prompts you to change a variable, and, if it is a dynamic variable, update ACSLS global shared memory. Enter ? at the prompt to see a full description of the variable. After the full description is displayed, you will be prompted again.

ACSAPI Client System Variables

The ACSLS client system must be built with the ACSLS CSC Toolkit 2.3 (or later) or a later release for Firewall-Secure Operation to be enabled for the client system.

There are four environment variables to enable for firewall secure operation on the ACSLS Client. You must set these variables to specific values. Each of these variables must be set and exported to the SSI's environment before the SSI process is started. They are then interpreted and used by the SSI, as indicated below.

If your CSC uses a script to start up the SSI, it is recommended that you set and export these variables from within that script. Additionally, Client developers may have provided a method for the end-customer to configure them appropriately, based on the CSC and the environment in which it runs.

CSI_UDP_RPCSERVICE –Determines whether UDP is used for network communications.

• Function: Enables/disables use of UDP as the underlying network transport layer for SSI network communications.

• Valid Options: TRUE or FALSE

• Other Details: This environmental variable must be set to FALSE for the firewall-secure CSC. The firewall-secure ACSLS applications packets are all sent using the TCP network transport.

CSI_TCP_RPCSERVICE – Determines whether TCP is used for network communications.

• Function: Enables/disables use of TCP as the underlying network transport layer for SSI network communications.

• Valid Options: TRUE or FALSE

• Other Details: This environmental variable must be set to TRUE for the firewall-secure CSC. The firewall-secure ACSLS applications packets are all sent using the TCP network transport.

New Variables in CSC Toolkit 2.3

SSI_INET_PORT – Fixed port number for incoming responses.

• Function: Specifies the port the SSI will use for incoming ACSLS responses.

• Valid Options: 0 or 1024–65535, except 50001 and 50004.

  • 0 indicates that the previous behavior of allowing the port to be dynamically allocated should remain in effect.

  • 1024 –65535 indicates that number should be used as the TCP port on which the SSI will accept ACSLS responses.

  • DO NOT specify 50001 or 50004, as they are used by the mini_el and SSI.

• Other Details: Setting this environmental variable to a nonzero value makes the SSI use this port for incoming ACSLS responses. This means that the firewall needs to allow incoming requests on that port in order for the ACSLS responses to be received by the SSI. This is the only port on which the ACSLS will initiate connections with the CSCs' SSI.

  Note:

  This value must match the value configured in the firewall which protects the CSC platform, allowing incoming requests for connections on this port.

CSI_HOSTPORT –Eliminates queries to the portmapper on the ACSLS server. Instead, send requests to this port on the ACSLS server.

• Function: Specifies the port to which the SSI will send its ACSLS requests on the ACSLS server. The ACSLS CSI must be using this port (that is, with firewall-secure fixed port set to this same value) for accepting inbound ACSLS requests from CSCs.

• Valid Options: 1024 –65535, except 50003, and 0 (this value must match the value set on the ACSLS server for the port used by the CSI for inbound packets)

  • 0 indicates that the previous behavior of querying the portmapper on the ACSLS server will continue to be used.

  • 1024 –65535 indicates the value used by the CSI for incoming requests.

  • DO NOT specify 50003, as it is used by acslm.

• Other Details: Setting this environmental variable eliminates queries from the SSI to the ACSLS servers' portmapper. The value of this variable specifies the port number on the ACSLS server to which the SSI should send its outgoing ACSLS requests. This permits a firewall-protected ACSLS server to disallow access to the portmapper at its firewall. The portmapper query previously provided the port number to which the SSI should direct its ACSLS requests.

  Note:

  This value must match the value of the port used by the CSI for accepting and servicing incoming requests. The firewall-secure feature must be applied to ACSLS for this port to remain reliably fixed at a specifiable value. If there is a mismatch, there will be no communication between the CSC and ACSLS.

Displaying and Setting Environmental Variables on the Client

On the client, the commands used to set environment variables depend on your shell and OS.

• On UNIX and Linux, display an environment variable by using the following command:

  echo $<variable-name>

• With the ksh and bash shells, you can set an environment variable by using the following command:

  <environment_variable> = <value>

  export <environment_variable>

Firewall Secure Solution Scenarios

The following diagrams show possible scenarios of the operation, port usage, and relationship of the ACSLS components when used across a firewall. They are intended to be understood in with the text just presented (above). The ”SSI” in the following diagrams is the network interface component of ACSLS that runs on the client-side of the communications. The CSI is the network interface component of ACSLS that runs on the ACSLS platform.

Note:

The ACSLS CSC Developer's Toolkit 2.3 (or later) and the new environment variables are required to support these scenarios.

Firewall Security on ACSLS Server-Side Only

In this example, firewall security is implemented on the ACSLS server-side (CSI) only. The CSC Toolkit 2.3 (or later) and the new environment variables are not required to support this scenario.

Figure M-1 Firewall security on ACSLS Server-Side only

In this example, dynamic means that the port is selected by the SSI at startup from the range 1024-65535. The port is not designated by the user, nor is it typically the same port across new executions of the SSI (that is, from one instance of an SSI running process to the next).

The portmapper 111 port(s) on the SSI-side is only rarely queried by the CSI. It is only accessed by the CSI in the case where the return port number provided by the SSI in its request packet does not function (that is, results in a network interface failure) for sending the response packets back to the SSI. In this case, as a retry mechanism, the CSI queries the SSI-side portmapper for the port to use, which is registered with the portmapper under the SSI's program number.

To secure ACSLS behind a firewall, you need the following settings:

• ACSLS:  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    (However, this must be TRUE if you have any clients who use UDP to communicate with ACSLS)

  • CSI_USE_PORTMAPPER = ALWAYS (This could be IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Client SSI Settings  - Environment variables that allow the client to run behind a firewall.

  • CSI_TCP_RPCSERVICE  = TRUE

  • CSI_UDP_RPCSERVICE  = TRUE (could be FALSE)

  • SSI_INET_PORT = 0

    This is a new environment variable with ACSLS CSC Developer's Toolkit 2.3 and not required for this scenario.

  • CSI_HOSTPORT  = 0 or <1024-65535, not 50003> default 30031

    It is not needed if you are using a portmapper on the ACSLS server. If defined and not zero, this must match CSI_INET_PORT on the ACSLS Server. This is a new environment variable with ACSLS CSC Developer's Toolkit 2.3 (or later) and not required for this scenario.

Configure your firewall to allow the client to send requests to the ACSLS server using the port specified by CSI_INET_PORT (on the ACSLS server) and CSI_HOSTPORT (on the client). Allow the client to access the portmapper (port 111) on the ACSLS server and ACSLS to access the portmapper (111) on the client.

Firewall Security on Client-Side Only

In this example, firewall security is implemented on the client-side (SSI) only. The CSC Toolkit 2.3 (or later) and the new environment variables are required to support this scenario.

Figure M-2 Firewall Security on Client-Side Only

In this example, dynamic means that the port is selected by the CSI at startup from the range 1024-65535, and the port is not designated by the user, nor is it typically the same port across new executions of the CSI (from one instance of an CSI running process to the next).

The portmapper 111 port(s) on the SSI-side is only rarely queried by the CSI. It is only accessed by the CSI, in the case, where the return port number provided by the SSI in its request packet does not function (that is, it results in a network interface failure) for sending the response packets back to the SSI. In this case, as a retry mechanism, the CSI queries the SSI-side portmapper for the port to use, which is registered with the portmapper under the SSIs' program number.

To secure the client system behind a firewall, you need the following settings:

• ACSLS:  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    If you have any clients using UDP to communicate with ACSLS, this must be TRUE.

  • CSI_USE_PORTMAPPER = ALWAYS  (This could be IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = FALSE

  • CSI_INET_PORT = 0

• Client SSI Settings  - Environment variables that allow the client to run behind a firewall.

  • CSI_TCP_RPCSERVICE  = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE (could be TRUE)

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

    This is a new environment variable with ACSLS CSC Developer's Toolkit 2.3 (or later) and not required for this scenario.

  • CSI_HOSTPORT  = 0 or <1024-65535, not 50003> default 30031

    Not needed if you are using a portmapper on the ACSLS server. If defined and not zero, this must match CSI_INET_PORT on the ACSLS Server. This is a new environment variable with ACSLS CSC Developer's Toolkit 2.3 (or later) and not required for this scenario.

You must configure your firewall(s) to allow:

• The client to send requests to the ACSLS server using the port specified by CSI_INET_PORT (on the ACSLS server) and CSI_HOSTPORT (on the client).

• The client to access the portmapper (port 111) on the ACSLS serer.

• The ACSLS server to send responses to the client using the port specified by SSI_INET_PORT on the client.

• The ACSLS server to query the portmapper on the client using port 111.

Firewall Security on Both ACSLS Server and Client-Side with Portmapper

In this example, both the client (SSI) and the ACSLS server (CSI) are implementing Firewall-Secure APIs. The client and server are still relying on the portmapper for port identification. The CSC Toolkit 2.3 (or later) and the new environment variables are required to support this scenario.

Figure M-3 Firewall Security on both ACSLS Server and Client-Side with Portmapper

The portmapper 111 that port(s) on the SSI-side is only rarely queried by the CSI. It is only accessed by the CSI, in the case, where the return port number provided by the SSI in its request packet does not function (that is, it results in a network interface failure) for sending the response packets back to the SSI. In this case, as a retry mechanism, the CSI queries the SSI-side portmapper for the port to use, which is registered with the portmapper under the SSI's program number.

For firewalls protecting both the ACSLS server and the Client, you need the following settings:

• ACSLS:  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

    However, this must be TRUE if you have any clients who use UDP to communicate with ACSLS.

  • CSI_USE_PORTMAPPER = ALWAYS  (This could be IF_DUAL_LAN_NOT_ENABLED)

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Client SSI Settings  - Environment variables that allow the client to run behind a firewall.

  • CSI_TCP_RPCSERVICE  = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

  • CSI_HOSTPORT  = <1024-65535, not 50003> default 30031

    This must match CSI_INET_PORT on the ACSLS Server.

You must configure your firewall(s) to allow:

• The client to send requests to the ACSLS server using the port specified by CSI_INET_PORT (on the ACSLS server) and CSI_HOSTPORT (on the client).

• The client to access the portmapper (port 111) on the ACSLS serer.

• The ACSLS server to send responses to the client using the port specified by SSI_INET_PORT on the client.

• The ACSLS server to query the portmapper on the client using port 111.

Firewall Security on Both ACSLS Server and Client-Side without Portmapper

In this example, both Client (SSI) and ACSLS Server (CSI) have implemented the firewall-secure features. The client and server have enabled the ”No Portmapper” feature. The CSC Toolkit 2.3 (or later) and the new environment variables are required to support this scenario.

Figure M-4 Firewall Security on both ACSLS Server and Client-Side without Portmapper

For the most secure configuration, you need the following settings:

• ACSLS:  ACSLS must be restarted after any changes.

  • CSI_TCP_RPCSERVICE = TRUE

  • CSI_UDP_RPCSERVICE = FALSE

  • CSI_USE_PORTMAPPER = NEVER

  • CSI_FIREWALL_SECURE = TRUE

  • CSI_INET_PORT = <1024-65535, not 50003> default 30031

• Client SSI Settings  - Environment variables that allow the client to run behind a firewall.

  • CSI_TCP_RPCSERVICE  = TRUE

  • CSI_UDP_RPCSERVICE  = FALSE

  • SSI_INET_PORT = <1024 –65535, except 50001 and 50004>

  • CSI_HOSTPORT  = <1024-65535, not 50003> default 30031

    This must match CSI_INET_PORT on the ACSLS Server.

You must configure your firewall(s) to allow:

• The client to send requests to the ACSLS server using the port specified by CSI_INET_PORT (on the ACSLS server) and CSI_HOSTPORT (on the client).

• The ACSLS server to send responses to the client using the port specified by SSI_INET_PORT on the client.

Turning On the Firewall Security on ACSLS Servers

To turn on the firewall-secure option, you must set several variables using the acsss_config utility.

1. Log in as acsss.

2. Stop the ACSLS server

   Note:

   You must bring down the ACSLS server for the new firewall-secure variables to take effect.

   acsss disable

3. To run the configuration script, enter the following command:

   acsss_config

   The ACSLS feature configuration screen appears.

4. Select option 1 - Set CSI tuning variables

   Accept the default for all variables, except for the following.

   1. Set the value to TRUE at the following prompt:

      Changes to alter use of the TCP protocol will not take effect until the product is restarted. CSI support for RPC using the TCP protocol is enabled [TRUE].

      Variable: CSI_TCP_RPCSERVICE

      Turning on TCP insures that the TCP protocol is available for use by clients of ACSLS for network communications. The firewall-secure feature of ACSLS supports TCP only, so clients should perform network communications using this protocol.

   2. Set the value to FALSE at the following prompt:

      Changes to alter the use of the UDP protocol will not take effect until the product is restarted. CSI support for RPC using the UDP protocol is enabled [TRUE].

      Variable: CSI_UDP_RPCSERVICE

      Caution:

      Ensure that no ACSLS clients are depending on this UDP protocol. The firewall-secure ACSLS runs on TCP only.

      Turning off UDP insures that no clients will access the server using this protocol. This enables you to disallow all general UDP access to the ACSLS platform at the firewall, allowing only those accesses which are specifically required in your environment.

      Allow clients access to the UDP and TCP port 111 for portmapper access, unless those clients implement the firewall-secure feature, and specifically turn-off their queries to the ACSLS portmapper.

   3. Set the value to NEVER at the following prompt:

      Changes to alter use of the port mapper will not take effect until the product is restarted. Enable port mapper: (ALWAYS / NEVER /IF_DUAL_LAN_NOT_ENABLED) [IF_DUAL_LAN_NOT_ENABLED].

      Variable: CSI_USE_PORTMAPPER

      NEVER enables clients of ACSLS to disallow external access to the portmapper on those client platforms.

      Important: This does not allow you to turn-off external access to the portmapper on the ACSLS platform; to do that, the client(s) of ACSLS must have adopted the firewall-secure changes in the client software component(s), and this feature must be turned on in the client software component.

      This feature ensures that the ACSLS server will not make any queries of the portmapper on the client platform. This enables any firewall which is protecting the client to disallow access to the portmapper.

   4. Set the value to TRUE at the following prompt:

      Enable CSI to be used behind a firewall (user-defined inbound port) (TRUE/FALSE) [FALSE]:

      Variable: CSI_FIREWALL_SECURE

      TRUE enables you to specify the single port that ACSLS will use for accepting inbound client communications (TCP connections). This variable simply enables this feature. The specific port will be specified in the next variable.

   5. Set the value to an available fixed port on the ACSLS server, at the following prompt:

      Port number used by the CSI to receive incoming ACSLS requests.

      Variable: CSI_INET_PORT

      This is the port which will be used by the ACSLS CSI component for accepting incoming network connections. Specify a port in the range of 1024-65535, excluding port 50003.

      IMPORTANT: Configure your firewall to allow incoming connections on this port. This ensures that only that port is exposed for use by those outside clients wanting to initiate communications with ACSLS. You may disallow connections on all other incoming ports except this one, and UDP/TCP port 111 (unless clients have implemented the feature to eliminate their queries to the ACSLS portmapper; in that case, port 111 may also be disallowed at the firewall). The recommended default value for this port is 30031. It is unlikely (but not impossible) that this port will be used by other processes on most systems. See "Troubleshooting" for steps to take if there is a port conflict.

5. Select E to exit acsss_config.

   Your changes are saved.

6. Restart ACSLS by entering the following command:

   acsss enable

Turning Off Firewall Security on ACSLS Servers

Some variables used above for turning on the firewall-secure feature are also related to turning off that feature. To turn off the firewall-secure behavior, it is only necessary to perform the steps below, but a specific site may want to make modifications to other variables as well.

1. Log in as acsss.

2. Stop the ACSLS server

   Note:

   Bring down the ACSLS server for the new firewall-secure variables to take effect.

   acsss disable

3. To run the configuration script, enter the following command:

   acsss_config

4. Select option 1 - Set CSI tuning variables

   Change the following values that were set when you configured the firewall-secure feature. Change the following variables:

   1. Set the value to ALWAYS at the following prompt:

      Changes to alter use of the port mapper will not take effect until the product is restarted. Enable port mapper: (ALWAYS / NEVER /IF_DUAL_LAN_NOT_ENABLED) [IF_DUAL_LAN_NOT_ENABLED].

      Variable: CSI_USE_PORTMAPPER

   2. Set the value to FALSE at the following prompt:

      Enable CSI to be used behind a firewall (user-defined inbound port) (TRUE/FALSE) [FALSE]:

      Variable: CSI_FIREWALL_SECURE

5. Select E to exit acsss_config.

   Your changes are saved.

6. Restart ACSLS by entering the following command:

   acsss enable

Firewall-Secure Configuration

The following requires that you are knowledgeable regarding configuring the network firewall behind which ACSLS resides. ALL firewalls are ”third-party” software, and will have varying details regarding setting them up correctly for protecting your network environment. The following is not meant to be a recommendation of firewall security policy, but rather, a set of helpful instructions for what the firewall must / can do regarding the ACSLS product, only. See your System Administrator for other security details.

Here is a list of details for setting up your firewall for the ACSLS platform:

• Put in place an overall rule to disallow UDP incoming and outgoing connections.

• Put in place an overall rule to disallow TCP incoming connections (TCP outgoing connections must remain open).

• Put in place a specific rule to allow incoming TCP connections on the port which you specified for the ACSLS usage. IMPORTANT: This port must match the one you configured under acsss_config, or you will receive no client communications at the ACSLS server.

If all of your clients have implemented the firewall-secure feature and make no queries to the ACSLS platform's portmapper, you are done. If the clients still make use of that portmapper on the ACSLS platform, you must add the following:

• Put in place a specific rule to allow incoming and outgoing connections on the well-known portmapper TCP and UDP port 111.

Example:

The following is an example of the rules which were put in place for an iptables-based firewall in order to put all of the above rules in place.

Note:

These are in addition to other rules configured for the specific firewall.

echo " - FWD: Allow all connections OUT and only existing/related IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state \
ESTABLISHED,RELATED -j ACCEPT
# These rules allow client access to the portmapper
$IPTABLES -A FORWARD -p tcp -i $EXTIF --dport 111 -j ACCEPT
$IPTABLES -A FORWARD -p udp -i $EXTIF --dport 111    -j ACCEPT
# These rules allow client access to the ACSLS CSI for network communication
# Note: This assumes that the CSI firewall-secure port was specified as 30031
$IPTABLES -A FORWARD -p tcp -i $EXTIF --dport 30031 -j ACCEPT
# Catch all rule, all other forwarding is denied and logged.
$IPTABLES -A FORWARD -j drop-and-log-it

Troubleshooting Firewall-Secure Communications

Troubleshooting a network communications interface which includes the ACSLS platform and clients, and now includes intervening firewall(s), may involve multiple steps. By introducing the firewall(s) into the path between ACSLS and its clients, there are more potential causes for network communications failures. Additionally, there are more components that must be configured in a way that corresponds with the settings in other components, and if these settings do not match, the network communications will be impacted. Here is a list of things to check and try if you have done all the configuration work on ACSLS, its client(s), the firewall(s), and network communications are not working.

1. Checking the ACSLS platform:

   • Is the ACSLS up and running? If not, check the acsss_event.log for possible reasons, or for pointers to a possible culprit.

   • Is the CSI being brought up successfully by ACSLS? If not, there should be informative messages in the acsss_event.log which point towards the cause. Bad values for some configuration parameters or a port conflict are likely possible causes.

   • Is there a port conflict being reported in the acsss_event.log which causes the CSI to fail? If so, you should use the ”netstat” or similar system utility to tell you which ports are in use on the system, and configure the ACSLS to use an available port. Remember to reconfigure the firewall to match.

   • Is the CSI registering for the port you expect? Use the command 'rpcinfo -p' to look at the portmap table. The CSI is registered under program number 300031. Check to make sure that the port registered under that program number is the one you expect (the default port is 30031, with one less zero than the program number).

2. If ACSLS and the CSI are up and running and are correctly registered, the next step would be to check access to the ACSLS platform across the firewall:

   • Is the ACSLS reachable through basic RPC? Use the ”rpcinfo -t <hostname> <program-number> <version-number>” command to send a simple RPC request to the CSI. (Use ”man rpcinfo” on your system to get more information on the rpcinfo command and its use.) Do this from a machine on the inside of the firewall with ACSLS (such as, from the ACSLS platform itself), and from outside the firewall. If it works from inside but not from outside, then the firewall is intercepting your ACSLS requests. Double-check the configuration of the firewall and the ACSLS port. Check to be sure that the portmapper is accessible through the firewall (this test cannot be used from outside the firewall if access to the portmapper is disallowed).

   • Do the ports configured for ACSLS and for the firewall, match? Double-check these parameters. This is a likely cause of failure in network communications. Aside from the configured values, perform the 'rpcinfo -p' command mentioned above, to insure that the CSI is indeed registering with the expected portnumber. If it is not, look in the acsss_event.log for information about the cause.

   • Is the ACSLS receiving requests, but unable to send back responses? If you check the acsss_event.log and find that the CSI reports many dropped network packets or failures to communicate with network clients, then the client requests are getting in, but the responses are not getting out. Again, this is an indication that they are being blocked by a firewall.

3. If your problems are still not resolved.

   The above addresses several levels of things to look for. If these yield no specific answer, it is time to do some lower-level checking to find out where communications are being broken-down. The best way is through the use of a network packet sniffer facility, such as 'snoop' under Solaris. Use ”man snoop” on your Solaris-based system to get more information on the snoop command and its use.

   Similar packet tracing facilities are available on other network-connected systems.

   • To use this, you have to do your packet sniffing from locations that show you where the packets are getting to, and where they are being lost. This may be from both inside and outside of the firewall.

   • Additionally, looking at the packet data will be informative. If either side is allowing use of the portmapper, it is likely that you will see some PORTMAP packets.

   • Also, you should see RPC packets passing between the ACSLS and its clients.

   • Finally, looking at the transport-level TCP connection will inform you of the specific ports being used on each side for the connection. This is often critical information to find out where the communications are being stopped.

More detail on performing these operations is beyond the scope of this manual, but your System Administrator should be able to provide some help in this area.

Frequently Asked Questions

• Why do I need the Firewall-Secure solution for ACSLS?

  The Firewall-Secure solution enables you to effectively run the ACSLS behind a firewall, and enables you to restrict ports on that firewall so that security is significantly enhanced.

• What releases of ACSLS will support the Firewall-Secure feature?

  Only ACSLS 7.0.0 and above supports this feature.

• What is the maximum number of ports I will have to leave open if I use this firewall-secure feature?

  The maximum number of ports on which you might have to allow incoming network connections is three: one for the ACSLS network interface, and two for the portmapper (UDP and TCP 111). Outgoing ports are unrestricted, in accord with accepted industry security practices.

• What is the minimum number of ports I can leave open?

  The minimum number is one. This is possible if your clients (ISV software) have also implemented the Firewall-Secure features in their client, and make no queries to the portmapper which resides on the ACSLS platform. When that is the case, the only port that need be open for incoming connections is the one user-specified TCP port used by the ACSLS network interface.

• Why doesn't the feature use a range of ports?

  There is no architectural advantage to using a range of ports, and there are some security disadvantages. The non-firewall-secure ACSLS uses a range of ports which consists of the full range of dynamic ports available on any given platform. This is correctly perceived as a potential compromise to the security of a site. Restricting this as much as possible, without adversely affecting ACSLS performance, is the goal in order to eliminate that compromise. Since the ACSLS network interface uses only one incoming port at any given time, there is no reason to extend the range beyond one port, provided that port is dedicated to ACSLS use for the ACSLS platform.

• What if the port I choose conflicts with another usage of that port on my system?

  This is one of the reasons that the port is made user-specifiable. The specific ports available will vary from one customer site to another. The user is not allowed to use one of the well-known reserved ports from 0-1023. The default port of 30031 falls within the range of registered ports, which makes it less likely (though not impossible) that another application which uses dynamic ports use it. Although it is in the range of registered ports, there is no application registered to use it, which makes it a reasonable default selection.

• Does this feature allow me to protect my ACSLS server with a firewall?

  Yes, with this feature in place, your ACSLS server can be put on the trusted side of a firewall, with clients accessing it from the opposite (untrusted) side or from the same side.

• Does this feature allow me to protect my ACSLS clients (ISV components) with a firewall?

  Potentially, yes, but not by itself. In order to realize this scenario, your client software components (clients of the ACSLS) must have adopted the Firewall-Secure feature, which has been made available using the StorageTek ACSLS Client System Component Developer Toolkit. Contact your client software provider for a current update on their status.

• If I want to be able to protect my clients with a firewall, what should I do?

  You should contact your client software provider. They can tell you whether they have adopted any Firewall-Secure changes in their CSC (client software component).

• What about the portmapper? Can I completely disallow access to the portmapper?

  If your clients have adopted the Firewall-Secure changes, they may allow you to shut off the client's queries to the ACSLS platform's portmapper. In that case, you may disallow access to the portmapper on the firewall which protects the ACSLS platform. In any other case, the clients will depend on the ACSLS server side portmapper to help them make a connection with the ACSLS network interface, and it must be available for their use.

• Why must the client implement some changes in order for my ACSLS server firewall to shut down access to the ACSLS platform portmapper?

  Because it is the client that is making these queries of the ACSLS platform. If the client continues to make these queries, the ACSLS platform must continue to provide the portmappers' services in order for those queries to succeed.

• I think the portmapper is bad. Why didn't you remove it completely?

  The portmapper provides an important service to legacy clients. Removing it completely would invalidate the interface on which those clients depend. In short, no legacy clients would work without recoding, retesting, and again certifying with the new non-portmapper interface. In this firewall-secure solution, we have provided the capability to remove the queries to the portmapper from both the ACSLS to the client, and from the client to the ACSLS, but we cannot force client software to conform to this. Thus, the portmapper must remain available at least as an optional service until a site's clients have adopted the Firewall-Secure features and no longer make use of the portmapper service.

• Some of my clients have adopted the Firewall-Secure features and some have not. How can I take advantage of this?

  Those clients which have adopted these features may be protected behind their own respective firewalls. In addition, access to the portmapper's well-known ports may be restricted at the firewall, and then configured to allow access to the portmapper only by those clients who require it. The details and ability varies based on the specific firewall in use at the site.

• I think RPC is bad. Why didn't you remove it completely?

  The ACSLS network interface has been RPC-based since the first release of ACSLS. It has proven to be an effective, stable, and reliable mechanism, offering various advantages at the network communications layer. However, it can also be more difficult to secure a platform which uses RPC due to its common dynamic allocation of ports and use of the portmapper. In this Firewall-Secure solution, both of these areas are addressed, which enables the customer to effectively configure a firewall in a restricted fashion, yielding the security benefits for which they have the firewall in place.

  Additionally, complete removal of RPC from the ACSLS network interface would invalidate all current (legacy) ACSLS clients, making it impossible for any of them to communicate with ACSLS without recoding, retesting, and again certifying their CSCs (client software components).

• How will the Firewall-Secure feature affect network communications performance and timing between my ACSLS clients and the ACSLS server?

  There is no effect on performance due to the new Firewall-Secure features. The usage of a firewall may have performance implications, but this will be based on the operational characteristics of each specific customers' firewall implementation. With a firewall which has negligible impact on performance, the ACSLS and its clients will continue to perform as they did before installing the Firewall-Secure feature. Also, the ACSLS network interface tolerances can be configured, so that delays imposed by the firewall could be handled gracefully.

• How does the Firewall-Secure feature affect the rest of my ACSLS operations?

  There is no effect or impact on other parts of the ACSLS operations due to the installation of the Firewall-Secure solution.

• How does the Firewall-Secure feature affect the ACSLS functionality that my clients use (through the ACSAPI)?

  The full set of functionality that is provided through the ACSAPI (and which our ACSLS clients use today to interface with ACSLS) will operate the same under the Firewall-Secure feature as it does without the feature installed. In particular, this Firewall-Secure feature supports access control, and also all of the newer features that have been added to the ACSLS product. The full functionality of the ACSAPI will continue to be supported by this feature.

• Does the Firewall-Secure feature work with the ACSLS HA (High Availability) solution?

  The Firewall-Secure feature does not adversely affect HA operation. However, the HA solution is not designed to be run across a firewall (that is, with each HA server on opposites sides of a firewall). The HA solution requires remote access to the portmapper, so the firewall could not disallow that access if an attempt were made to run each server on opposing sides of a firewall. There are other details of running across a firewall that could adversely affect an HA setup; it is highly recommended that this not be done.

  If the HA servers are set up on the same secured side of the firewall, that set of HA servers could be set up with the Firewall-Secure feature, and clients on the opposite side of the firewall would be able to interact across the firewall with those servers with the same performance and behavior as they would against a non-firewall-secure HA solution.

• Does this Firewall-Secure feature work with other StorageTek software products?

  Inter-operability with other StorageTek products and partner products (that is, client software components which communicate with ACSLS) has been completely preserved. Those products can continue to operate without modification, communicating with the ACSLS server, with the ACSLS server running behind a secured firewall, or in the same environment with those products (as it does today).

• Do other StorageTek software products have the same Firewall-Secure features?

  Other StorageTek products do not gain the Firewall-Secure benefit simply by being used in the same environment with the Firewall-Secure ACSLS. Each product can work with a firewall secured ACSLS (see previous question), but putting each of those products behind its own respective firewall is a question that the specific product itself must address. Some StorageTek products already have built-in policies which allow some restriction at a firewall used to protect the platforms where those products run. Additionally, any product which acts as a client to ACSLS has the option of adopting the Firewall-Secure changes which were made to ACSLS, and which are provided as part of the ACSLS CSC Developer's Toolkit 2.3 (or later).