The network system or simply networking is an area that has improved security over the years. It is also the area that is exploited the most since through it, potential attackers could gain access to unauthorized resources from a remote location. However, there are a few points that should be highlighted. Whenever possible, do not enable any of the following services/protocols and 'siblings'.
Connectivity services: There are several protocols (communication services) that were popular in the early days of the Internet. Those protocols are very weak in terms of security as they are 'clear text' protocols; that is, user IDs and passwords are transmitted without encryption. Among them, the following are the most common:
File sharing services: Another area in which production servers may be compromised is that of file sharing. The two most popular are shown next. They are application level protocols that lack the use of encryption, thus open to be a point of exploit of a system.
- nfs
- smb
Many corporations struggle with the decision of what technology to use when a technical solution requires file sharing. In WAS ND7 environments, the use of shared file systems could be avoided. However, if an unavoidable requirement calls for file sharing, there are other more secure alternatives such as AFS and its derivative, DFS.
Miscellaneous services: There are a couple of services/protocols that have been used for multiple purposes. In a WAS ND7 environment, there is no need for them and they should be at least disabled, or better yet uninstalled if they reside on your production systems. The most common of them in this area are the following two:
- rpc-based services
- nis services
For additional network services specific to your platform, the Center for Internet Security website is a great resource (http://cisecurity.org/). Specifically, look for the corresponding Security Configuration Benchmark for your specific OS.
In the event that any of the aforementioned services or protocols must be enabled due to a business reason and not a technical solution, the following trick could be used to mask your WAS ND7 network configuration and usage.
In the first place, ensure that the weak service or protocol can be bound to a specific IP address and not use a wildcard '*' configuration. This is the prerequisite for this trick. In addition, create an IP alias (or if you can afford it, add an extra network card to your system). Only one of the IP addresses will be returned by the command hostname. Let's call the IP associated with the result of the hostname command, the principal IP. The IP alias, which must resolve to a different host name than that returned by hostname, will be denoted as a secondary IP. Moreover, the procedure is to configure the weak service so it binds to the principal IP. All of the TCP/UDP ports required for the WAS ND7 environment and any of its support technologies running on the same host must be configured to bind to the secondary IP address. In that way, if the weak protocol is discovered, no other services are offered through that IP and it would make it harder to find a relation between the principal and the secondary IPs through the weak protocol.
In order to wrap up this section and the chapter, let's look at two categories of network security possibilities.
WAS ND7 is fully dependent on network connectivity, that is, the capability to establish communication channels to both the front-end and the back-end of the infrastructure architecture.
If the native protocol used by the WAS ND7 environment offers the use of encryption, make sure it is enabled. If, on the other hand, the native protocol does not offer encryption but it accepts the use of SSL communication, make sure to use it. This will require the exchange of SSL certificates and update the key stores and trust stores accordingly. Lastly, should the target protocol not offer either data encryption or support for SSL, then it may be necessary to use SSH tunneling between the WAS ND7 host and the remote host, such as a database server.
Using any of the three methods mentioned can help you comply with any business requirement that calls for a secure channel for data transmission.
The second category is that of inter process communication; that is, communication channels between processes executing on the same OS host. In order to secure the channel, the preferred method, if the processes involved are flexible enough, is to configure the processes to bind to the OS host private IP address, 127.0.0.1. Using this port prevents the OS to expose the data communication flowing between the processes.
If one of the processes to be involved in the communication does not allow to bind to the OS host private IP address, then the same approaches that were used between network connections can be used between process-to-process communication.
Again, if there is a business requirement that calls for an encrypted (or secured) transfer of data between processes running in the same OS host, you can deliver that type of solution.