1. Administrator's Guide
  2. Firewall Security Option
  3. Frequently Asked Questions

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).