Secure IT

Day 5

There is an optional product from Sterling Commerce called Connect:Direct Secure+. Secure+ will wrap your C:D connections with SSL (Secure Sockets Layer). This will encrypt the connection using any of several cyphers and authenticate the C:D nodes using digital certificates.

OK that sounds great, but why would you want to do that? The answer to that question is well it depends. SSL gives you confidentiality as the connection is encrypted. It gives you authentication as you can verify if the other node’s digital certificate was issued by someone you trust such as VeriSign etc.

Even if you believed that the information you were sending to another node was in the public domain such as your company’s share price, you would still like to be sure that the information had not been modified/falsified and that it came from the correct source and was being sent to whom you intended. This is even more important if the transfer is going over a network you do not control such as the internet.

Even in the case where the transfers are occurring on your internal network you might still use these measures. Some information is very sensitive that you do not want your IT support staff prying into such personal information like salaries etc. In this case you may want to encrypt the data on the file system using something like PGP (Pretty Good Privacy et al).

OK so you have sensitive information that is encrypted on the file system, so you might think you do not need to encrypt the connections between C:D nodes. Even in this case you might still employ Secure+ as you wouldn’t want to receive any PGP’d file from anywhere and forward it onward blindly.

PGP’d files are normally encrypted by the application that produced them and only intended for the target application to decrypt. This is done by exchanging the PGP public keys and adding them to the two endpoint’s “key rings”. That way the sender encrypts with the public key he was given earlier by the receiver, and the receiving application can decrypt with his secret key.

Once a connection between two C:D nodes has been set up, many files of differing data classifications (public, confidential, secret etc.) may flow over that connection. Some of the files will be PGP’d or encrypted prior to transfer, some of the files will not need to have the same level of protection.

You would hate to set up a connection with Secure+ using certificates for authentication and using a null cypher (no encryption) only to find that some time later someone started sending sensitive information in the clear which may be seen by someone monitoring the network.

In my view it is so easy to set up a secure connection between C:D nodes using Secure+ with authentication, encryption and the assurance the data hasn’t been modified, and know that you are not only protecting your data, and potentially your company’s reputation, but also complying with any information security standards or audit regulations you have to comply with.

You should protect your production data as a minimum, and always use Secure+ when using an un-secure network such as the internet or a network you do not have control over.

In short I always set up connections with Secure+.

Making a connection

Day 4

For a quick test of the connection you can double click on the “Send/Receive File” in the left hand pane of the C:D Requester. You should be presented with something that looks like this:

In the main tab here you can see the key information for the test transfer. The SNODE is the secondary node i.e. the other node called “CD.REMOTE” in my example. The location of the file to transfer is next, and then the destination file name. 

It would be a good idea to agree on the destination file name with your corresponding number in charge of the other Connect:Direct node. This is so there are no surprises, like overwriting an important file or accidentally having your file processed. Ideally the file being transferred should not contain any actual data, and the name of the file should make it clear that it is not a data file. The other node can be configured to have a default download directory that is separate from any real data directories if his system is a production machine.

The Connect:Direct administrator of the other node will need to know which user name you are using for the Connect:Direct process so he can configure his system to allow your transfer to go through. You will probably already know who you are logged on as, but it is also displayed in the bottom right hand corner of the Connect:Direct Requester application window.

For now press the “OK” button and you should see something like the next image on your display:

Here you can see that the bottom horizontal pane in the Requester is showing a Connect:Direct process called “SENDRECV” from a node called “NICKE” to another node called “CD.REMOTE”. The “Status” & “Queue” columns may change quickly. In this screen above you see the process is pending execution. When the process finishes the “Status” & “Queue” will be blank as the process is no longer running and therefore is not in a queue.

The question is though was it successful or not? Double click on the 'Select Statistics' in the left pane and select a time period and press enter. You will see a lot of horrible information. The good news is that you are only really interested in the column labelled 'CC' which stands for 'Condition Code' which should be 0 if everything is OK. 

The rows that you are interested in are those that have a RecID column of 'CTRC' which stands for Copy Termination ReCord. If you see the row that is associated with your process number when you submitted the process when you clicked 'OK' on the 'Send/Receive File' form, you can double click it to get all details of the transfer. 

You can scroll down to see source/destination file names bytes transferred etc. So hopefully now you have proved that you can send a file to the other side.

Configuring the Connect:Direct Netmap

Day 3

This might be a good time to point out to you that Connect:Direct uses two TCP ports; 1363 for API/command-line/C:D-Requester connections and port 1364 for Connect:Direct Server to Server connections. These are the port numbers by default and of course you can change those if you need to.

A Connect:Direct node keeps a list of other Connect:Direct nodes that it connects to. This list is called the “netmap”. It maps a Connect:Direct node name to an ip-address and port number. Connect:Direct can connect via other network protocols such as SNA and DECNET, but TCP/IP is by far the most common and I will assume its’ use throughout. This is so the node knows how to contact the other node when it needs to. The node being connected to also needs a corresponding entry in its’ “netmap” too. In the left hand panel of the Connect:Direct Requester double click on the “Netmap” entry under your node name. This will list the contents of the netmap. Right mouse click in the middle panel and select the “Insert...” menu item.

Essentially you only need to give the name of the remote node and the ip-address and port number, and select the only mode listed “Mode1”. All the other values can take the defaults. You will not have to fill in the tab labelled “APPC”, and on the “Communication Path” tab there is just one path to choose, so that’s easy!

Click “Ok” to exit the “Node Properties” dialog box and you should be presented with something like the following:

Right mouse click and select “Apply” to make your changes to your node’s configuration.

Now all you have to do is get your remote administrator to configure his netmap with your node.

In the next post I’ll describe how we test this connection.

Configuring the C:D Requester

Day 2

Before we get into the configuring of Lee’s Connect:Direct Windows, I’d like to just give few more details about testing the connectivity to the remote Connect:Direct node. The possible outcomes from the “telnet” test are “refused”; probably a firewall not configured appropriately. “failed” means that there was nothing listening on that port, probably because the remote Connect:Direct node was not running. “Timeout” means that no route to the remote address was found. If you get this then you will probably want to perform a “tracert” and see where the connection is being held up. It could be a router or even a routing rule on the server depending on where the “tracert” shows where the problem is. 

The outcome you are looking for is when the “telnet” program actually connects on the port you gave it. This shows that something at that address was listening on the said port and accepted your connection request. If this happens you won’t see anything useful in the “telnet” screen so just kill the command prompt window.

It was also be a good idea for someone at the remote node to perform a similar exercise to prove that the network connectivity is actually in place before troubleshooting the Connect:Direct configuration.

For configuring Connect:Direct Windows we will be using the Connect:Direct Requester program that you should be able to find after clicking the start menu button then “Programs” and then “Sterling Commerce Connect:Direct ...” and then click on “C:D Requester”. Hopefully you will see something similar to the image below:

 

If you installed Connect:Direct Windows or if you have previously configured the C:D Requester to point to your Connect:Direct node then you should see your node name in the left hand panel in the nodes tab. In the above picture you can see my node name NICKE. If you don’t have any nodes listed there then you will have to look in the “Node | Connection Settings | Insert Node” menu and configure your connection to your local node. 

When you have something like the left panel above then we can configure the connection to the remote node.

Connect:Direct in the family

Day 1

You have to help family and friends. So the scene was set on that Friday the 13th. I’m not superstitious by the way! I received an urgent email from my brother Lee in the United States asking if I could help him with a Connect:Direct (C:D) connection between his company and another. He didn’t know anything about C:D apart from that I knew a lot more than he did.

He had received some good information from his corresponding number in the other company that he was trying to connect to. The problem was that they had given him too much information, and that it didn't make much sense to him. Lee’s C:D was on a Windows machine, and the box he was trying to communicate with was running the UNIX version of C:D. My brother saw no correlation between the configuration items he had been given and the C:D for Windows that he had.

The fact that the two C:D’s were running on different platforms was also thought to be part of the problem. I reassured my brother that this was normal for C:D UNIX to communicate with C:D for Windows or C:D for mainframe etc.

Learning anything new can be daunting. The trick is to not try to take everything in at once. In this case Lee really didn’t need to worry about all the configuration parameters he had been given as most of them were defaults. The key thing he needed to think about was exchanging the right information with his 3^rd party in order to make the connection.

Lee had been given a node name, an ip-address, a port number, a user name and a destination directory to copy files to.

It is important to ensure that you have network connectivity before trying to configure C:D as you can spend a lot of time before realising that there is nothing wrong with the C:D configuration, and that you had a network issue from the start. There may be firewalls that have to be navigated that may perform NAT (Network Address Translation) etc. So you need to be sure that the ip-address being used for you to put in your configuration is an address that you can “see” from your C:D server. There is no point specifying an address that can not be routed to.

At my work we can test the connectivity using a perl script. Lee didn’t have perl on his Windows machine and wasn’t in the mood to install it at that time. I explained that he could use the “telnet” program to open the appropriate port on the remote server to just see if there is anything listening on that port. I told him to type in “telnet 192.168.9.9 1364” at the Windows command prompt.

There are 4 possible outcomes from running this command “failed”, “refused”, “timeout” & “connected”. I told him that we needed to be able to prove the connectivity to the remote node before continuing.

In the next post I help Lee configure his C:D for Windows using the Requester program.