AS2 Communications Balancing Act

Successful AS2 communications require a balancing act between two conflicting demands: your infrastructure has to be open enough to talk with your trading partners, but secure enough to keep out intruders and repel attacks. The familiar firewall is the tool of choice to resolve this, but it still requires that you tell your trading partner which ports are open. This could expose your network to security lapses on their end. Fortunately, there are several options available to minimize or eliminate this risk.

An obvious solution is to restrict incoming traffic only to the known IP addresses of your trading partners. While this is a good start, some other problems present themselves. Smaller companies may not have static IP addresses, and even larger ones sometimes have to change addresses due to network maintenance or server migrations. Adjusting the firewall to these changes requires the intervention of network security staff, who may not always be able to operate on your timetable. Furthermore, it still leaves you vulnerable to malicious traffic that is actually originating from your trading partner’s network, or someone else who has spoofed their address.

A more thorough solution is to obscure what ports are open on your firewall even to your trading partners. This can be done by adding specialized screening software, like a proxy server, to a machine outside the firewall in the so-called ‘Demilitarized Zone’, or DMZ.  This software could be set to listen to the port your trading partners are sending to and forward it to the different address and ports open on your firewall while keeping them anonymous.

This set up can also protect against malicious traffic that’s actually coming from your partner by filtering the connections to make sure they’re legitimate. For example, it could check not just the originating IP, but restrict all non-AS2 traffic by looking for AS2 header information. If that information is missing or doesn’t match the filter criteria, the connection is refused. Another advantage of such an application is that you can usually monitor activity and make changes in the filtering criteria without having to involve your IT staff.

To protect against spoofing, consider using two-way SSL authentication for your transactions. In this format, the server (receiver) not only verifies its identity to the client (sender), but the client has to prove its identity to the server. This can be combined with the steps above, but be aware that two-way SSL is not as widely supported yet and some of your trading partners might not be able to handle it.

Finally, a word of caution: it can be tempting to multiply your network security with redundant filters and firewalls-within-firewalls, but this can be dangerous. At some point you’ll hit a plateau where security improvement becomes negligible and the smallest changes can cause massive headaches for both your trading partners and your IT department. It’s better to consider the situation of your company and the requirements of your partners and work from there than to drown your b2b communications in overly complex and inflexible security protocols.

3 thoughts on “AS2 Communications Balancing Act

  1. Pingback: Tweets that mention AS2 Communications Balancing Act | EXTOL Technology Blog -- Topsy.com

  2. Babelabout

    I would not make such a “big” case about security when setting an AS2 receiver module. I would say that you simply need to apply the same rules when setting up a web server. And, I would imagine that a company who wants to setup an AS2 receiver module has already a web site.

    Of course, I would recommend the usage of a reserve proxy within the DMZ, or at least not to put the AS2 receiver module (which accesses the private key in order to signed the MDN) directly on the “public” web server. Personally, I have written a simple little script – see http://code.google.com/p/babelas2/source/browse/trunk/Proxy/Proxy.asp?spec=svn55&r=55 – running on my public web server that acts as a reverse proxy. Then, I can install the AS2 receiver module on an internal web server, not listening on any public IP address.

  3. Mike DiBaggio

    @Babelabout: It’s my experience that many businesses have chosen to treat their security concerns in exactly the way you describe, but I’ve also seen many others require substantially more robust and redundant security settings on their AS2 connections. Sometimes this is because they’ve been bitten by some security lapse in the past, other times because of requirements by their trading partners or the organizations they operate under.

Leave a Reply

Your email address will not be published. Required fields are marked *


*