Case Sensitivity with the Identify Document Task in Forum Sentry

Forum Sentry administrators using the Identify Document task to uniquely identify a request or response document may wish to make the comparison value of the XPath expression case insensitive. By default the comparison values are case sensitive.

To make the comparison in the Identify Document task case insensitive, set the lower-case function on the XPath expression and make the value lowercase.

Below is an example entry for matching the word "forum" regardless of case. With this entry the values: forum, Forum, FORUM, fORum, etc.. will all match.


Original:

Path: /soap:Envelope/soap:Body/tns:Echo/tns:Buf
Comparator: =
Value: "forum"

Case Insensitive Version:

Path: lower-case(/soap:Envelope/soap:Body/tns:Echo/tns:Buf)
Comparator: =
Value: "forum"

For more information on the Identify Document task please refer to the Task Management Guide available in the Help menu in the WebAdmin interface or contact Forum Systems Support.

Configuring a WSDL Policy within Forum Systems Sentry for use with MTOM

This article provides instructions for configuring a WSDL Policy within Forum Systems Sentry for use with MTOM attachment processing.

In order to use MTOM with WSDL Policies, you first need to create/add a new HTTP Request filter for MTOM on the WSDL Policy. When this HTTP Request Filter is triggered, the XOP Binary MIME is deserialized back into a standard SOAP message, processed, then re-serialized back into a binary XOP MIME sent to the back-end server.

Step 1: Open the WSDL Policy. On the Services Tab, click the link under PORT.

Step 2: Scroll down to the Request Filters and Press the NEW button:

Step 3: Enter information for a new MTOM Filter as follows:

Name: MTOM Filter

Format: MTOM

Description: MTOM Request Filter

Identification Expression: (Content-Type ==~ "(?i).*application/xop\\+xml.*") && (method == "POST")

Step 4: Save the request filter and the modifications to the WSDL Policy by clicking Save on each screen.

This WSDL policy should now be able to process MTOM attachments.

Gathering Diagnostic Information with the Forum Sentry XML Gateway

This article describes methods of reviewing and collecting various diagnostic information from the Forum Sentry XML Gateway. These methods are also applicable to the Forum Presidio FTP Security Gateway and the Forum Secure Token Service Gateway.

When reporting a technical issue to Forum Systems Support, please provide the version of the product as shown on the General Info page of the WebAdmin interface and the diagnostic information outlined below.

Diagnostic Information Available in the WebAdmin Interface:

With Forum Sentry version 7.3 there are three types of logs available through the WebAdmin interface on the Diagnostics>>Logging>>Internal Logs page: the Audit logs, the System logs, and the Access logs.

Audit Logs: Audit logs track the changes made to the Sentry configuration by an administrator. This log contains a comprehensive view of user activities and policy additions, modifications or deletions.

System Logs: System logs show information about the actual traffic going through the device. This log captures the changes that occur in the life of a document as well as changes in movement for
a document. As a request is received by the system and the document passes through various
processes, tracking messages are written to the System log.

Access Logs: The Access logs are primarily for the STS Gateway and track authenticated sessions.

Notes on the Internal Logs:

• Each log can be downloaded in the following formats: XML, Plain Text, and HTML.
• Each log can be downloaded with the following compression formats: ZIP and GNU ZIP.
• Additional logging settings including: max log file size, display preferences, and days to keep the logs can be found on the Diagnostics>>Logging>>Settings page of the WebAdmin interface.
• You can configure Sentry to always log specific error message based on specific error codes.
• The default logging level is INFO for both the Audit and System logs. This is the logging level recommended for the System log in production environments. Forum Systems only recommends using DEBUG logging when there are reported issues in need of troubleshooting.
• The internal logs can also be sent off of the system via a Remote Syslog Policy.
  

More information on the logging available with Sentry, including a listing of error codes and information on the Remote Syslog policies, can be found in the Sentry v7.3 Logging Guide.


Diagnostics Information Available in the Forum CLI:

To view the Internal Logs via the CLI run the "show log" command and follow the onscreen instructions.

The following CLI commands can also be useful in troubleshooting issues:

show general
show connections
show interfaces
show listeners
show max-threads
show routes
show arp

With Sentry version 7.3 there is a new CLI diagnostics command that can only be run from a CLI connection established with HyperTerminal or MiniCom (not available via SSH). This command "runDiagnostics" will typically only be used when there is no SSH or WebAdmin access to a device. This command will gather data and allow the administrator to transfer this data via ZModem. This data should then be sent to Forum Systems Support for review.


Troubleshooting Checklist:

The following are general troubleshooting questions and steps to take when reporting an issue to Forum Systems Support.

Troubleshooting questions:

1. What version of Sentry is being used? You can find this on the General Info page of the WebAdmin interface.

2. Please provide a detailed description of the issue, including as much information about reproducing the issue and the environment (load balancers, routing details, etc..) as possible.

3. When did the problems begin? Were there any recent changes to the Sentry configuration or to the environment that might have triggered the issue?

4. Are the issues occurring on multiple Sentry instances?

5. Is the issue reproducible or is this a sporadic issue?

6. When the failures were occurring, what information was being returned to the client? Or was the client simply timing out?

7. Were there any issues reported with the backend servers that Sentry is communicating with?

8. Is Sentry configured for any of the following: archiving, LDAP auth, SiteMinder auth, or WS Reports to a local database?

Gathering Diagnostics:

1. Please run the following CLI commands and send the output to Forum Support:

show general
show connections
show interfaces
show listeners
show max-threads
show routes
show arp

2. Download and send the Sentry Audit and System logs from any of the days the issues has occurred. If the problem is reproducible, please set the System log threshold to DEBUG mode and reproduce the problem, download the System log, and then set the threshold back to INFO or WARNING level.

3. If the issue might be network related, it may be beneficial to capture the packets using the Packet Capture feature on the Diagnostics>>Logging>>Packet Capture screen of the WebAdmin interface.


All diagnostic information should be sent to support@forumsys.com. If necessary this information can be FTP'd to Forum Systems, contact support@forumsys.com for the FTP site credentials.

Configuring the Forum Sentry XML Security Gateway to Communicate with IBM MQ via SSL

This article provides instructions for configuring the Forum Sentry XML Security Gateway to securely connect to an IBM MQ instance using SSL.

The procedures outlined below utilize Forum Sentry v7.3 and IBM MQ v7.0 (though the steps to configure MQ v6.0 should be similar). This article also assumes the reader is familiar with IBM MQ administration.

Configuring IBM MQ 7 for SSL
==============================

1. Use the IBM Key Management tool to create a self signed keypair, or import an existing SSL server keypair, using the label: "ibmwebspehermq(queue manager name in lowercase)". For example if your queue manager was "QM_TestMQ7_Server27" then your label would be "ibmwebspheremqqm_testmq7_server27". Note that the queue manager name has to be lower case.
2. Import any root CA/intermediary certificates necessary for client cert validation into the MQ keystore.
3. Save the keystore file under the ssl directory for the QM (On Windows: C:\Program Files\IBM\WebSphere MQ\qmgrs\QM_TestMQ7_Server27l\ssl\) as key.kdb in CMS format and then stash the password (File menu -> Stash password).
4. Within MQ Explorer, on your running Queue Manager, verify that the SSL key repository points to the key file (right click the QM, select properties, select SSL). Note that the extension is left off.
5. Under the Advanced/Channel folder on the QM, create a new Server-connection channel (Example name: S_TestMQ7_Server27).
6. Edit the SSL section of the newly created server connection channel's properties. Select the SSL CipherSpec you want to use. This must match the setting you use in Forum Sentry. The 'Authentication of parties initiation connection' is optional and can be set to 'required' if you plan to present client authentication certificates from Forum Sentry.
7. Apply the changes.

Note: It may be necessary to restart the QM, but only do this after you've configure Forum Sentry following the steps below and are unable to connect/retrieve messages.

Configuring Forum Sentry
==============================

1. Import any root CA/intermediary certificates necessary to verify the certificate installed on the IBM MQ instance. Note: If using a self signed certificate on MQ, then export the cert from the IBM Key Management tool and import this cert into Sentry as the root (CA) cert.
2. Create a Signer Group containing the root CA and intermediary certificates necessary to verify your MQ server's SSL certificate.
3. Create an SSL Initiation policy associating the Signer Group created in the previous step. Note: Enable the "Ignore Server Hostname Verification" option if the certificate is not issued for the correct hostname for the MQ server.
4. Create a new MQ Listener or Remote policy, enable SSL and associate the SSL Initiation policy created in the previous step. Note: Use the same SSL CipherSpec that the MQ channel is using.
5. Configure the remainder of the MQ Listener / Remote policy settings according to your environment.

The MQ Listener / Remote policy on Forum Sentry should now be able to communicate with the MQ instance using SSL. If there are problems, the first troubleshooting step should be to restart the QM.

New Podcast: Advantages of Certified XML Devices in your Application Security Lifecycle

An XML device or application that provides security functions does not mean that the solution itself is secure. A secure XML hardware device requires a properly designed architecture, precise algorithm implementation, secure key storage, encrypted policy data, and a secure API.

Download and hear from Jason Macy, the CTO at Forum Systems who has pioneered the field of XML testing and simulation with over 40,000 product installations worldwide. In this download we will discuss in more detail why the FIPS and DoD Certified Forum Sentry XML Gateway provides distinct advantages over non certified devices, including the following areas:

• XML device PKI private key compromise protection
• SSL ciphers and XML security
• Secure policy data storage
• X509 authentication with CRL and parent chain signature verification
• Physical hardware integrity

Click here to listen now

Understanding Group Remote Policies in Forum Sentry

As an XML Security Gateway, Forum Sentry sits in front of your SOAP/XML/REST Web services protecting your back-end services. For externally facing services (traffic comes in from outside your network), Sentry is responsible for handling all incoming XML traffic sent from your trading partner's client applications and destined for your services. Sentry processes these incoming requests and then sends them along to the back-end service (the remote server).

Often times the Forum Sentry gateway resides behind network load balancers which distribute the incoming requests among multiple Forum Sentry appliances. The load balancers ahead of Sentry allow for redundancy and increased throughput.

Forum Sentry, through the use of Group Remote Policies, also includes support for load balancing requests to multiple remote servers.

A Group Remote policy is a collection of Remote network policies that provides failover for redundancy in the case of a remote server failure and can optionally use one of several strategies for remote load balancing. A Group Remote Policy can be associated with a WSDL or XML policy.

There are several Load Balancing strategies available with the Group Remote Policies. The strategies are broken into two categories: Passive Load Balancing Strategies and Adaptive Load Balancing Strategies. Below is a quick summary of each.

Passive Load Balancing Strategies

Passive strategies choose a Remote policy without reference to the traffic passing through the system.

• Failover - Uses the order of the configured Remote policies in the group to signify priority. Always chooses the first Remote policy from the list of eligible Remote policies unless it is disabled or inaccessible, in which case it moves to the second, etc.
  
• Round Robin - Initially chooses an eligible Remote policy at random and then rotates through the list of eligible Remote policies in order, choosing the next eligible Remote policy for each new client request.
  
• Random - Chooses an eligible Remote policy at random for each new client request.
  
• Weighted Random - Chooses an eligible Remote policy at random for each new client
  request, using the relative weights configured for each Remote policy. The configured weights set the relative odds that each Remote policy will be selected if eligible.
  

Adaptive Load Balancing Strategies

Adaptive strategies gather statistics about current and past traffic passing through the system and choose a remote server based on the traffic patterns.

• Transfer Throughput - Chooses the highest performing eligible Remote policy. Performance is measured by the average transfer throughput of the last 100 requests, in bits per second.
  
• Active Requests - Chooses the eligible Remote policy which is the least busy, based on the
  number of concurrent requests the Remote policy is servicing.
  
• Response Time - Chooses the highest performing eligible Remote policy, measuring
  performance by the average response time of the last 100 requests. The Response Time strategy chooses the Remote policy with the lowest average response time.
  

Summary of Group Remote Failover Behavior

All Group Remote policies, regardless of the load balancing strategy selected, includes failover functionality that works as follows:

The list of policies available for a Group Remote policy to use initially includes all the Remote policies configured for the Group Remote policy. Removed from this list are all Remote policies which have been manually disabled via the WebAdmin and any Remote policies which are known to be inaccessible.

The Group Remote Policy discovers that a Remote policy is inaccessible only after the policy is chosen for use by a client request and cannot be reached. If the Remote policy is reachable but returns an error, it is still considered to be accessible - only an unreachable Remote policy is removed from consideration. Once a Remote policy is discovered to be inaccessible and removed from the list, the Group Remote policy will begin trying to connect to the remote server of the Remote policy in the background, with a retry delay as configured in the Group Remote policy. The Remote policy will be returned to the list once it can be reached to process requests.

For more information on the Group Remote policies please refer to the latest HTTP Network Policies Guide available in the Help section of the WebAdmin interface.

Maximize your Web Services Security with Forum Sentry

It is important to note that one of the main focuses of the Sentry XML appliance is, and has always been, security for your Web Services. Right out of the box there are many security features enabled by default, and the fact that your clients are accessing Sentry and not your back-end service directly is a major security benefit in itself. We take great pride in offering the only patented XML Security Gateway that is both FIPS 140-2 certified and DoD PKI certified.

For a good overview of Sentry's focus on security please visit: http://www.forumsys.com/security/index.php.

You can also find many whitepapers regarding security around XML and Web Services here. We recommend starting with the "Best Practices in Deploying SOA Gateways" and the "Attacking and Defending Web Services" papers for a good introduction.

There are many features of Sentry related to securing Web services that might not always be utilized. These features include: SSL (with or without Mutual Auth), XML Encryption/Decryption, XML Signature/Verification, Intrusion Detection and Prevention (IDP Rules), Pattern Matching, Anti Virus scanning, Identity and Access Control (many different ways to accomplish this), support for all WS Security standards, etc...

Below are some recommendations for utilizing common features in Sentry to further increase the security of your services:

1. Use SSL with all externally facing services. All network listeners should use SSL (HTTPS). Start by enable SSL, and then consider enabling SSL with Mutual Authentication. SSL with client/server auth allows you to verify the client cert (and tie it to a specific user). At the very least, the network listeners should be HTTPS (SSL). For FTP traffic, Sentry supports FTPS (TLS or SSL) and OpenPGP encryption/decryption/signatures/verification.
2. Use IP ACLs on your network listener policies to only allow incoming traffic from specific IP addresses or IP ranges. If a client tries to connect from an unknown IP range the connection will be rejected.
3. Tighten existing IDP rule thresholds or add new IDP rules depending on your specific criteria.
4. Enable Anti Virus Scanning.
5. Consider creating custom Pattern Match policies to catch specific text strings. This helps to ensure no confidential data is leaked out with the response messages and prevents any harmful XML attacks coming into the service.
6. Consider using XML encryption and XML decryption with your trading partners. The trading partners would encrypt the request data before sending to Sentry, the request data is then decrypted on Sentry. For response processing, Sentry would encrypt the response data before sending it back to the client.
7. Consider using Schema Tightening and advanced validation options with your WSDL policies.
8. Utilize Sentry's built in PKI infrastructure. Create, import, and store all keys related to the security of your services within Sentry. For added PKI security upgrade to the Sentry appliances that include the FIPS Level III HSM.
   

How to tell if your services are secure?

In addition to the recommendations above for tightening the security of your services with Sentry, we strongly recommend you perform some security/vulnerability/penetration testing of your services hosted on Sentry. You can use SOAPSonar from Crosscheck Networks to perform this testing. This is a great tool for functional and performance testing as well, but there is patented technology focused on security/vulnerability testing that you won't find with any other SOA test tools.

For instance, SOAPSonar includes a Vulnerability mode that enables the user to run scans against your services and report any potential issues - and explain how to fix them! In addition, if you configure SSL, encryption/decryption, or other WS Security features on Sentry, you can use this tool to test these features.

You can download a free evaluation of SOAPSonar here: http://www.crosschecknet.com/products/soapsonar.php.

Retrieving a WSDL from a Sentry WSDL Policy

A WSDL Policy in Sentry defines the URI endpoint that the client applications will use to communicate with the services you are protecting with Sentry.

As part of the security Sentry provides, the client will never have access to the application server hosting your web services - the client will access Sentry and Sentry will communicate with the application server. Therefore, the Sentry administrator will need to provide a WSDL that contains the Sentry endpoint to the clients. The WSDL file contains the IP, port number, and full path information that the client uses when sending a request.

This post will describe the multiple ways in which the Sentry administrator can provide the correct WSDL to the clients.

1. URI WSDL Retrieval: There is an option on the Virtual Directory page of the WSDL Policy in Sentry named "Enable WSDL Access". If this option is enabled, Sentry will serve the WSDL to any client that connects with an HTTP GET using the full request URI with the addition of the ?WSDL syntax.

For instance, to obtain the WSDL for a service with the virtual URI:
http://10.1.2.3:80/qaservice/qaservice.asmx

The following URI can be used:
http://10.1.2.3:80/qaservice/qaservice.asmx?WSDL

Note that a web browser can be used to retrieve the WSDL via URI or a web services testing client tool such as SOAPSonar can retrieve and parse a WSDL via URI or file.

2. Manual WSDL Export: When viewing a WSDL Policy, there is an "Export WSDL" button on the top right of the page. This feature allows the administrator to download a WSDL file manually, while choosing to include all operations or operations based on ACLs (access control lists). This allows the admin to provide different WSDL files (with different operations defined) to different clients.

3. Publish the WSDL: When viewing a WSDL Policy, there is a "Publish WSDL" button on the top right of the page. This feature allows the admin to publish the WSDL to a UDDI directory while adding specific information about the business and service. This feature also includes an option to publish all operations or operations based on ACLs.


No matter how the client retrieves the WSDL generated by Sentry, the endpoint will point to the Virtual URI as shown when viewing a WSDL Policy. The Virtual URI consists of the IP and port of the HTTP listener policy and the virtual path specified on the Virtual Directory page of the WSDL Policy.

Automatically Backup the Forum Configuration File

The Forum appliances (all products) provide a mechanism for automatically exporting and FTPing the configuration file (.FSX file) on a daily basis. This routine ensures that there is always a current configuration backed up for safe keeping.

The automated configuration backup routine is enabled in the Forum CLI. Here are the steps to configure, enable, and test this routine.

1. Access the Forum CLI via SSH or Serial Console. Enter enable mode, so that the ForumOS# prompt is displayed.

2. Run the "system config backup-wizard" command to configure the routine. You will now be prompted to enter the following items:

• time of day the backup takes place
• the IP address of the FTP server to post the file to
• the directory on the FTP server to post the file to
  
• the FTP transfer mode (active or passive)
• the FTP server username and password
• the configuration file password (the password used to encrypt the file and used when importing the file)

3. Run the "system config backup-test" command to test the settings entered during the wizard. This will export a configuration file (.fsx) and attempt to FTP the file to the server/directory indicated during the wizard.

4. If the test succeeds, run the "system config backup-enable" command to enable the daily backup routine.

To import a saved configuration, simply navigate to the System>>Configuration>>Import/Export screen of the WebAdmin interface and browse to the FSX file. The password to use with the import is the file password entered into the backup wizard. This screen also includes a feature to do a one time export of the configuration file.

FTPS Modes and Clients Supported by Forum Presidio and Forum Sentry

Forum Presidio supports FTPS for both SSL and TLS. Presidio supports FTPS explicit mode only.

A brief description of Explicit FTPS vs Implicit FTPS:

Explicit: This type of security requires that the FTP client issues a specific command (AUTH SSL or AUTH TLS) to the FTP server after a connection to establish the SSL link has been made. The default FTP server port is used.

Implicit: This is a mechanism by which security is automatically turned on as soon as the FTP client makes a connection to an FTP server. In this case, the FTP server defines a specific port for the client (990) to be used for secure connections. Implicit FTPS is not supported by Forum Presidio.

With FTPS, Forum Systems recommends using AUTH TLS (as opposed to AUTH SSL) whenever possible.

The following FTPS clients have been confirmed to work with the 7.3 release of Forum Presidio and Forum Sentry:

SmartFTP: TLS and SSL
FireFTP: TLS only
FileZilla: TLS only
CuteFTP: TLS and SSL
GoFTP: TLS only

If you have a question on or problem using FTPS with Presidio or Sentry please email the details to support@forumsys.com.