Airlock Implementation Guide

The Airlock Implementation Guide summarizes the most important steps to successfully install and integrate Airlock into a given environment. As a checklist and reference guide it helps the administrator to identify critical tasks early before the integration process. This way, all required preparations can be made and the needed information for the Airlock configuration can be gathered.

Airlock Implementation Guide and Checklist

The implementation guide presents an ordered checklist for an Airlock administrator. It is recommended to be used as a reference when installing and integrating Airlock. Even for experienced administrators it is a helpful tool to make sure that all aspects of the Airlock deployment are considered. The following checklist should be verified in the listed order before installing an Airlock. Please refer to the Airlock Administrator’s Online Manual regarding configuration and installation details.

Hardware Requirements

A technical description of the hardware requirements can be found in in the OnlineHelp manual chapter System and hardware requirements.

The hardware requirements depend partly on the characteristics of the Web application environment to be protected and on how many people access the application in parallel. An application that transfers huge amounts of data with very high request frequencies needs more powerful hardware than a less used standard Web application. Please contact Airlock support for a detailed hardware recommendation based on the Web environment specificaton.

Any Airlock hardware always requires at least one network interface and a CD/DVD-ROM drive to install from CD. Alternatively, Airlock can be installed from a network boot image. In that case, no CD-ROM drive is required.

Airlock automatically supports disk mirroring if two disks are installed in the system. Ergon strongly recommends taking advantage of the disk mirroring feature.

Scaling to High Traffic Sites

To handle more than several thousand concurrent sessions it is recommended to use multiple Airlock instances in a load-balanced network environment with a network load balancing device. One single Airlock can be scaled up to approx. 10'000 concurrent sessions on the appropriate hardware. Typically it is more efficient to implement a load balanced scenario with multiple instances that also offers failover clustering. Please contact Ergon for discussing Airlock configurations for very high traffic volumes.

Airlock Software Installation Requirements

• Make sure to have the latest Airlock installation CD.
• Download the latest Airlock update from the Airlock Techzone update section techzone.ergon.ch/airlock-releases
• Set up the Sun Solaris Jumpstart network boot image if desired. Follow the established procedure recommendend by Sun for setting up the Jumspstart server.

SSL Server Certificate Requirements

If it is not intended to use SSL communications this section may be skipped. Airlock provides internal example certificates to start installing and using Airlock right away. Custom SSL server certificates should be installed on Airlock for productive usage. The custom SSL server certificate has to be obtained independent of Airlock. Airlock does not provide SSL server certificate generation tools. Please visit the SSL server certificate issuer’s Web site for information on how to create your own SSL server certificate.

Web Application Compatibility Requirements

Airlock is independent from application servers and protects any Web application that complies with standard Web environment requirements. To be successfully protected by Airlock, an application should comply with the following standards and best practices in Web application environments. Specifically, a Web application

• should not use absolute HTML links (HREFs) including protocol and host name in its responses. This is a basic reverse proxy requirement, especially when the reverse proxy terminates SSL. The HTML rewriting in Airlock makes it possible to convert non-compatible applications to be reverse proxy compatible with Airlock. If possible it is still recommended to use and develop reverse-proxy compatible applications with relative URLs in order to save the HTML rewriting configuration and computation effort.
• should not generate dynamic cookies on the client using JavaScript or other client side functionality. If it does, cookie protection will not be possible for these cookies.
• should not generate dynamic URLs on the client using JavaScript or other client side functionality. If it does, the URL encryption feature will not work with these dynamically created URLs and they will have to be listed as exceptions.
• should not generate or change HTML form contents dynamically on the client using JavaScript or other client side functionality. If it does, the smart form protection cannot be used for those forms.
• should separate sensitive and authenticated business logic from public parts to allow Airlock to address them differently
• should comply with the standard HTTP specification and use only HTTP communication (no proprietary protocols on other communication channels)

There are ways to still protect Web applications with Airlock that violate some or all of these equirements. However, Airlock may not deliver full protection for those or the flexibility in the configuration may be restricted.

Authentication Enforcement

Please skip this section if the Airlock installation will not use the authentication enforcement mechanism to handle authenticated sessions on Airlock. There are several issues to be considered when integrating Airlock to an authentication service and using Airlock to perform the authentication enforcement. Authentication enforcement specifically involves the following tasks that need to be handled correctly depending on specific customer requirements:

• Authentication process (performing the authentication with a user directory)
• Login and Logout propagation into backend applications
• Secure session termination
• Account editing by user (e.g. password change)

Authentication Process

The most important component involved with authentication verification is the Web based authentication service. The Web authentication service is not included in the  Airlock Application Security Gateway itself. It is a special backend application that is responsible to authenticate the user by performing the needed authentication verification with the user directory. The Web authentication service performs the authentication and uses the backend control API of Airlock to modify the user’s session attributes according to the authentication result.
Airlock makes it possible to decide on the authentication method independent of the backend applications and independent of Airlock. Especially, there are different authentication services possible in parallel. Please refer to the Airlock Authentication Service Manual and the Airlock Administrator’s Online Manual for more details on the Web authentication service. The authentication service can either run on Airlock itself or within a servlet container on a backend server behind Airlock.
Best practice is to use a dedicated Authentication Service independent from the applications. We provide such an Authentication Service to Airlock customers, the Airlock Authentication Service. It supports standard authentication mechanisms such as LDAP, MSAD, RADIUS or ACE. It is easily possible to add customized authentication support to the Authentication Service for special authentication mechanisms like a customer specific TAN verification or an OCSP PKI service. It is also possible to use an existing Authentication Service of an application and integrate it with Airlock so that it uses the backend Airlock Control API.

The following questions must be answered to define the login process with Airlock:

• Where and how are users authenticated (LDAP, RADIUS, ACE, Access Manager, Identity Mgt. Server, etc.)?
• Which Authentication Service will perform the authentication with the above user directory (Airlock Authentication Service or custom Authentication Service) and use the Airlock backend control API?
• What kind of information does the Authentication Service need to provide to the backend application with either cookies or in the Airlock Login Assertion (typically the user ID)?
• Where should the Authentication Service run (on Airlock or on one of the backend servers)?

Login Propagation into Backend Applications

Once the user is authenticated, the login information has to be propagated into the backend application so that the user does not need to authenticate again. There are three possibilities to propagate the user login to backend applications. Depending on the application, not all of them may be used. The list represents the recommended order of preference when integrating Airlock with backend applications:

• Airlock Trusted Cookie / Airlock Assertion
  The backend application interprets the Trusted Airlock Cookie or the Airlock Login Assertion to implicitly accept the user. This is the most efficient and flexible way of integration. It requires a minimal change in the application. The needed code changes are absolutely minimal and can be done within a few hours.

• HTTP Basic Authentication On-behalf Login
  If the Web application can be switched to use HTTP Basic Authentication to identify the users, Airlock can provide the appropriate HTTP Basic Authentication header and perform an implicit on-behalf login. The HTTP Basic Authentication credentials to be used need to be set dynamically by the authentication service using the Control-API.

• Form Based On-behalf Login
  If the application cannot be enhanced to interpret the Airlock Assertion and if the application cannot use HTTP Basic Authentication, the Authentication Service can perform a form based on-behalf login. The Authentication Service will perform the appropriate login request to the application and transfer the ession cookie of the application to the secure cookie store of Airlock. Because this solution offers less flexibility and does restrict the error handling in timeout or failover scenarios, it is only recommended if 1) or 2) are absolutely not possible. Most Web environments implement the first recommendation.

Successfully deployed examples are:

• IBM Websphere Trusted Association Interceptor (TAI) that interprets the Airlock Assertion
• Microsoft IIS API filter that interprets the Airlock Assertion (e.g. for SAP Enterprise Portal)
• Bea WebLogic J2EE Interceptor that interprets the Airlock Assertion

Secure Logout

Performing a secure logout is as important as the authentication of the user itself. The authentication service must provide a logout command that uses the backend control API of Airlock to terminate the session. There are three possibilities to enable secure logout mechanisms with Airlock:

• Airlock recognizes logout request and terminates session
  By using virtual host request rewrites to the logout service or the intelligent logout request recognition of Airlock it is possible to recognize an application logout request and terminate the session on Airlock. No application changes are required.
• Global Logout Link in Master Frame (Portal Logout)
  The authentication service can set up HTML frames to show the applications and always provide a global logout link in a side or header bar. The application does not need to know about this logout in any way. The logout link points to the logout command of the authentication service.
• Application Logout points or redirects to logout service
  The application logout link can point to the logout command of the authentication service or the application can redirect to the logout command after performing its own logout.

Account Editing by User

Any additional account editing functionality such as password change needs to be provided in a corresponding Web service or by the application.

Airlock Installation Preparations

After verifying all above items the following Airlock installation preparations should be made:

• Install the hardware physically into the network (no operating system installation required)
• Make an Airlock CD or network boot image available. If not available, get a copy of the installation media from here.
• Make the latest Airlock update file available (download from techzone.ergon.ch/airlock-releases)
• Make SSL server certificate and private key information available (if not using Airlock’s internal example certificate)
• Make productive or evaluation license for Airlock available. The license needs to be issued by Ergon based on one of the MAC addresses of one of the ethernet interfaces installed on the server hardware.
• Make all necessary network information available (IP addresses, routing, netmasks, log host, mail host, NTP server, gateway, etc.)

Initial Airlock Installation

Follow the instructions in the Quick Start Guide (PDF) to install Airlock on the desired hardware plattform. No operating system is necessary prior to install Airlock.

Initial Airlock Configuration

After installing Airlock it is recommended to configure Airlock the following way:

1. Configure the following items first and activate them before continuing:
   • Server Settings
   • Basic Network
   • Routing
   • Netmasks
   • Alert Channels and Notifications
2. Verify SSH/SCP access to the log files and other alert channels and check the log for correct Airlock initialization confirmation messages
3. Add the configurations for the virtual hosts and application mappings
4. Choose the default filter settings for the initial testing and make sure to monitor the Log Viewer to recognize blocked requests or any other important messages

Virtual Hosts & Application Mappings

The most important configuration part includes setting up virtual hosts and application mappings to enable access to applications through Airlock. Airlock makes it possible to present an application through a virtual host and a virtual URL mapping completely independent of the internal network architecture. The required roles/credentials specify if a user needs to be authenticated to access the application.
An application mapping defines which URL on which virtual host is mapped to which backend host and URL. The internal network topology is not exposed to the external network. Additional virtual hosts or application mappings can be added easily in the Web based Configuration Center of Airlock.

Airlock supports name-based virtual hosts including SNI for virtual hosts using SSL. This means that several different hostnames can share the same IP address.

Be aware that not all browsers and operating systems support SNI. Therefore it is recommended using separate IP addresses for different virtual hosts using SSL.Please refer to the Administrator’s Online Manual on your Airlock for further details on configuring virtual hosts and application mappings in Airlock.

Secure Cookies

Make sure to configure the cookie protection settings according to the application requirements. As a default, all cookies are stored in the secure cookie store of Airlock. Airlock also provides encrypted cookies or plaintext cookies if desired.

Airlock provides complete cookie protection for backend applications. By default, all cookies created by an application are stored in the secure cookie store of Airlock and they are not sent to the client browser. This default setting provides the highest level of cookie protection. If the application needs certain cookies to be transferred to the client because they are valid throughout the user’s session on Airlock, those cookies can be encrypted. Please refer to the cookie settings page in the Airlock Administrator’s Online Manual for detail on passing cookies to the client browser.

Filter Configuration

Unfiltered HTTP traffic causes dangerous threats to Web applications. The HTTP protocol as well as the Web application server, its components and the business logic are too complex and versatile. A specific Web application only requires a small set of valid HTTP requests and data being sent. Many attack and manipulation methods can be successfully prevented if the HTTP traffic is filtered before it gets to the server.

In order to successfully filter the HTTP traffic, the filter rules need to be configured for each application. This section explains the filter engine and how to configure it successfully.

Airlock provides a powerful 2-stage filter engine to successfully filter invalid and malicious requests to protect the applications.

Stage 1: Whitelist Filter (Mandatory Allow Rules)

The first filter stage consists of whitelist filter rules that describe what kind of requests is valid for a specific application. A request must satisfy at least one whitelist filter rule with corresponding path pattern to pass. It is possible to increase the security of an application significantly by specifying appropriate whitelist filter rules with minimum effort. An authentication service must be accessible for anonymous users. Using the whitelist filter rules, it is possible to strictly define the acceptable authentication requests – and nothing else. In case of the authentication service which is typically a very small and simple Web application, the definition of these whitelist rules is straight forward.
The following examples illustrate what can be defined by whitelist filter rules:

• Source IP restriction example Coming from 192.168.1.0/24 is allowed, all other source IPs are not allowed
• URL restriction example requests in the path/myapp for *.gif, *.jpg, *.jsp and *.html are allowed, everything else is not allowed
• Request parameter restriction example for Authentication Service. For the POST request URL/auth/login.jsp only the parameters „username“, „password“ and „token“ are allowed, they must contain alphanumeric characters and must not exceed the lengths of thirty characters each
• Restrict the number of parameters for requests to parameter "username", "password" and "token".

Stage 1 can only be configured with knowledge of the application’s business logic to define the valid request range. It is similar to firewalls network connections are configured that are allowed between two IP addresses or networks. The Airlock filter provides more filter conditions than shown in these examples. Please refer to the Airlock Administrator’s Online Manual for detailed configuration options.

Stage 2: Blacklist Filter (Forbidden Deny Rules)

The second filter stage compares the request data against denied filter patterns. If one of the deny filter rules matches, the request is blocked.

Typical examples for blacklist filter patterns are the following:

• Prevent directory traversals
• Prevent SQL injections
• Prevent Cross Site Scripting
• Prevent non-printable characters
• Prevent illegal UTF sequences

The Airlock filter provides more filter conditions than shown in these examples. Please refer to the Airlock Administrator’s Online Manual for detailed configuration options.

Both Airlock filter stages allow defining filter patterns on various HTTP request components such as the source IP address, HTTP content type, HTTP method, HTTP Headers, URL and the parameter names and values. Regular expression based filter patterns offer the most powerful, flexible and efficient way to build such filter rules.

Filter Configuration Process

To successfully configure the powerful filters of Airlock, the following steps are needed for each application. Depending on the complexity of the application it may take between 20 minutes and 3 – 4 hours to configure the filters in all details. With only a small amount of work the security of the application can be significantly increased.

1. Make sure that the application is up and running to be tested through Airlock.
2. Monitor the Log Viewer for blocked requests when working on the filter configuration.
3. Configure filter exceptions for parameters that need to be able to accept free text which may include cross site scripting or SQL injection patterns.
   If configuring exceptions or disabling certain deny filters make sure that the application can handle the data correctly.
4. Now test the application through Airlock with the activated attack filters. If Airlock blocks a request because of an attack filter, the corresponding log message appears immediately in the Log Viewer. It gives all the information about what request was blocked and because of what. Make sure that the application is not vulnerable on the specific requests/parameter combination before deciding to disable a filter or create an exception to a filter.
5. To configure the allow rules, the HTTP interface of the Web application has to be known:
   What requests take what kind of parameters? If there is no interface description available the application should be tested and all requests recorded with a recording proxy software (e.g. OpenSTA or Paros). Based on the Web application interface it is easily possible to configure the allow rules for a Web application. One of the most important things is to restrict the type of requests (e.g. *.jsp, *.html, *.gif and *.jpg) for an application. Everything else should not be sent to the server. That kind of allow filter is typically created in a few minutes.
6. The allow rules also contain length restrictions for URLs, parameter names and values.
   Define meaningful length restrictions and test the application to verify that the filters do not block valid requests.
7. It is recommended to create several allow rules that describe the different parts of an application.
   For example:
   • Authentication Service allow rule (only accept login request and parameters)
   • PDF repository allow rule (only accept PDF request in a certain directory)
   • Image folder allow rule (accept all image types for the image folder)
8. Make sure to thoroughly test the application through Airlock with the filter settings planned to use for the productive installation.

Monitoring & Operating Airlock

To operate and monitor Airlock, the log messages need to be analysed and processed on one of the alert notification channels using SMTP, Syslog or HTTP. Please refer to the Administrator’s Online Manual for the detailed description of alerting channels, log levels and message formats.

While developing filter rules, testing and integrating Airlock, it is helpful to use the log mode "Integration" on the appropriate mapping. This will produce additional log messages about the backend application behavior, state of cookie store and URLs transformed in URL Encryption and Form Protection.

To perform other troubleshooting tasks it is also possible to activate the systems root account and use low level system tools to trace the traffic from and to Airlock (e.g. using snoop, telnet, curl, netstat, route and ifconfig commands).

Next steps

After having installed Airlock and applied the first and initial configuration, the next steps could be

• Integration of an Authentication Service, either the Airlock Authentication Service, an OEM Authentication Service or an own development of an Authentication Service.
• Integration of the Application Portal to show the available backend application to the anonymous or authenticated user.
• Integration of the Airlock SSL-VPN to use role-based access control for providing non-HTTP channels to the Internet user.

Technical Support & Implementation Help

Please contact Ergon for technical support on certain implementation details:

• Airlock Support

Ergon or one of our premium partners also offer technical consulting during an Airlock deployment project.