While considering enhancements for the next version of EXTOL’s AS2 product a while ago, I was presented with what I initially thought was a curious, if not paranoid, enhancement request: a customer wanted to be able to restrict outgoing traffic to specific ports.
My first question was: “Why bother?” Indeed, the vast majority of our customers had no restrictions on their outgoing source, or egress, ports and the concern of network administrators has traditionally been on restricting who and what can come into the network from outside. While the threat from viruses, worms, denial-of-service attacks targeted at a company’s internet infrastructure from the outside is obvious, the perils from inside the network are not so readily apparent. Nevertheless, they are worthy of a security conscious IT professional’s close consideration.
So what can a company gain by restricting the traffic over its egress ports? For starters, being able to monitor and restrict outgoing transmissions means that malicious software or DOS type attacks are much less likely to propagate from your network. There are important legal and financial ramifications to such an oversight, and a company might be held liable for damages even if the malefactor wasn’t an employee or associate. An additional motivation for limiting outbound traffic is that some companies feel they can improve productivity and overall data security by limiting internal access to the internet or making it easier to monitor for suspicious activity.
Whatever reasons you might find compelling, it’s important for IT departments and application managers to consult with one another so that each clearly understands the new security procedures and the obstacles they present to B2B communications. Most importantly, IT needs to be able to assign a sufficient range of ports to handle a company’s most intensive outgoing volume requirements. But how can you arrive at this figure accurately?
Depending on the format of your outbound communications there are several factors to think about, but I’ll try to illustrate what to look for from the perspective of AS2. Since binding an outgoing message to a specific socket can be considerably more restrictive than setting up listening ports for inbound traffic, you’ll generally only be able to use a single port per outgoing message. On days and times that your outbound activity is the highest, take some time to count the number of both outbound AS2 messages and outbound asynchronous MDNs (we don’t need to consider synchronous MDNs since they’re occurring over the same connection as the initial transfer) sent over a short span of time, say five minutes. This should be the minimum number of ports set aside for use so as to avoid any failures in sending. Since you can still run into situations where the amount of outbound traffic is higher than anticipated, it’s also a good idea to make use of any sort of ‘retry’ options that your software supports just in case not enough egress ports are available the first time around.