Part of my job is to work on the design of new products. Do the overall architecture and some product management. To be good at this, I have to listen to our customers, partners and consultants. Therefore I like to be involved in consulting, especially for larger and complicated installations, so I can stay close to the needs and demands of the customers.
In this role, I am often confronted with the same basic problem: how do we have to lay out our network landscape (firewalls, networks, servers and appliances) to ensure a reliable and secure operation, even if we have to communicate with external partners.
In this post I want specifically talk about ISDN connections to your partners, because they are not very common and many firewall admins or security officers try to approach the problem with common IP network knowledge, which is often not the best way to solve this. Let me apologize in advance: this covers a broad topic and will be quite technical, I haven’t explained all the backgrounds, it requires good understanding of networking, and some XI knowledge.
ISDN CommunicationFirst of all, let’s have a look why and how you would want to communicate with ISDN. This is an easy one, using traditional EDI communication protocols (Point-to-Point, like OFTP or Mailbox based, like X.400 P7) is good in industries, where you can reach all your major suppliers and customers. For example in German retail the X.400 based mailbox service of the German Telekom (Telebox) is heavily used. In the Automotive industry you can reach all the OEMs and suppliers over OFTP. It is so successful, that all major banks in Germany also accept communication with OFTP (the Odette File Transfer Protocol). Of course, those protocols are older than the Internet Boom. The reason why they are still used is the ease of set up, and the comparable low risk of those connections. (You can set up a new partner within minutes of configuration. If you try to do this with inter-company VPN connections you may need to occupy network staff on both sides for days and the security officers will call you anything you can imagine.
So, we assume you have a customer, which suggests you to do an ISDN based data interchange connection, and you decide to exchange XML Documents or EDI data formats (EDIFACT or ANSI X.12). In both cases you need a technical Adapter for the SAP Exchange Infrastructure (XI) to speak the traditional EDI protocol. SAP offers a J2EE based Adapter Engine. From SEEBURGER you get the OFTP or P7 Adapters, which are basically JCA standard based connectors to communication protocols.
ISDN HardwareBecause those adapters must be completely integrated into the adapter engine, and because the certification of the adapters requires vendors to support all platforms (on which XI is supported) there is a problem: how to access the ISDN hardware from within Java?
Well, in the non-java world there is a programming standard called CAPI, it is the Common ISDN API. Most of the hardware vendors who offer ISDN cards provide this dynamic library. However ISDN cards and the CAPI are not provided on all hardware architectures, and it is generally not a good idea to connect a mission critical server to a landline. So SEEBURGER has a wrapper to access the native shared libraries, but our preferred solution is the use of a TCP based network protocol called Virtual or Remote CAPI, which can access ISDN devices (router appliance, Line Servers) over the network. We have implemented this network protocol in pure Java (using simple Sockets). This allows separation of the ISDN Hardware and the server, it also allows to connect multiple servers to multiple routers. That way you can achieve redundancy: Software can switch the phone lines without line jacking. Since there is no native code executed in the Java VM no general protection fault can harm the operation of the adapter engine, and no buffer overflow can be exploited by intruders.
Generally we use Funkwerk Router (Bintec X- family) as the telemetric solution, which supports single BRI ISDN connections up to multiple PRI (60 channels). There is also PC Software which can turn a PC with ISDN cards into a Line Server. Current Software based PBX Systems (VoIP) sometimes also offer this functionality. We don’t recommend to use Cisco’s SoHo Line of routers, they don’t provide all the needed features.
LandscapeSo how does the landscape look like? Well, first of all you have your backend networks. You most likely know your setup better then me (after all I am not a BASIS guy).
The XI Installation uses NetWeaver ABAP and J2EE parts on at least one central server called the integration server. IS is then connected to the backend systems for doing A2A (application integration with XML message routing). Most likely the adapters of the IS will connect to the backend systems through a saprouter. The IS is critical for internal operations, it must be separated from the applications which handle the remote communication. This is mainly to minimize the impact of a security problem. However since the B2B adapters are implemented in Java, you are quite safe anyway: no nasty buffer overflows in this code. But nobody is perfect, so rather be safe than sorry: place a filter between IS and the Adapter Engine(s) used to host the B2B adapters. Usually this engine is placed on a network segment like DMZ or secure server network.
Ok, so finally we need to talk about the placement of the ISDN router(s). Actually router is a pretty misleading word here. Those boxes can do classical routing (IP over dial up connections by PPP), but this functionality is not used by the Remote CAPI client. So you don’t have to fear malicious IP packets coming from that device to your network. The data stream from possibly un-trusted external endpoints is terminated directly in the adapter code. The adapter thinks it is directly talking to the ISDN card and handling the public network signals and data streams. Since this connection is transparent it basically means that the Adapter Engine and the ISDN appliance are exposed to the same risk, therefore can be placed in one network segment. However it is no problem to place a filter between both (for example if this is general company policy and you are not able to get a exception even if there is no gain from this separation). The filter also makes sense, if you use the appliance for real routing in addition to the EDI usage. The Adapter Engine will connect on a single TCP port to the appliance (username/password protected). Unfortunately you won’t find a Firewall which can intercept that traffic, so you have to use a generic TCP forwarding.
Content SecurityA short note on content security: malicious data from your partners will be detected by the XML mapper of XI or by the EDI format converters of SEEBURGER. So there is really no need to run a malware scanner on that data. In fact: installing an on-access scanner on a production system is a big no-no IMHO. (Beware: if a file is rejected, because it is not valid syntax this data can contain malware, but system administrators are expected to delete it, it won’t be executed automatically, so it is harmless)
Wrap Up- Use dedicated Adapter Engines for those technical Adapters involved with external communication
- Offload ISDN Hardware to an appliance
- Firewall between Adapter Engine and Integration Server
- Optionally Firewall between ISDN appliance and Adapter Engine
- Firewall to Internet is not used in this scenario
For futher reading I strongly recommend you check out the SAP Security Guides on XI and NetWeaver from the Service Marketplace, as well as the SEEBURGER Adapters Master Installation Guide (from the Adapter CDs).
This has become a long post, sorry folks. (I warned you). Please let me know if this was too hardcore. Look out for the next post, it will be based on this one, and discuss the additional considerations for IP based Inter-Company communication (AS2, ebXML MS, RNIF or Web Services).
