Earlier this chapter noted that IP Filter firewalls restrict network traffic based on IP address and port number. BusinessObjects Enterprise works well with IP Filter firewalls with the proviso that the IP address and TCP port number used by the servers are predetermined. This section discusses a scenario where the BusinessObjects Enterprise WC/Web server and WCS has one IP Filter between the two of them and the WCS is separated from the rest of the BusinessObjects Enterprise servers by a second firewall. In other words, it's the common firewall scenario you looked at in the previous section. This is illustrated in Figure 36.5. Figure 36.5. IP Filteringfirewall definition.
Let's look at two distinct parts of communication across the networks: first, the most external portion (that is, between Network C and Network B), and second, the communication between the WCS and the other BusinessObjects Enterprise serversthe internal portion between Network B and Network A (see Figure 36.6). Figure 36.6. Configuration with IP Filteringexternal firewall.
An External Packet Filtering Firewall ScenarioAny requests of the WC machine would follow the same steps as described in the previous section. Initially, the WC would have to establish a TCP connection to the WCS. The WC would initiate this handshake communication. The IP Filter firewall would certainly stand to convolute this communication:
The network rules of this side of the firewall will quickly determine that the destination IP of this request will have to go through the firewall. Therefore, the network forwards this TCP connection request to the firewall. The firewall then evaluates the information within the requestthe destination port and IP address, as well as the source IP and source port. The firewall must have rules that allow this connection to go throughit must accept requests for the WCS's IP from the WC's IP and the request must be on the specified port. At this point in the request, the firewall will have to allow traffic through it that follows this configuration:
When the WCS receives this request, it must respond to it. It garners the information about where to respond from the information within the request. It takes the Source IP and Port and makes this the destination. Because this is a random port, the firewall must be configured to allow any ports to leave Network B and go to Network C. This is a generally accepted practicestrict port enforcement is done at the bastion host. Therefore, the firewall rules to complete this request should resemble the following:
When the connection request gets through the firewall, the network resolution will determine that the destination is in Network C. The request will hit the Web server/WC. At this point, there is a TCP connection between the two machines, going through the firewall. The WCS will send the WC its IOR and the WC will close this TCP connection. The IOR contains the IP and port on which the second connection will be made. The port number in the IOR will be one of many values depending on the existence or nonexistence of the -requestport xxxx directive on the WCS's command line. If there is a -requestport, this is the value that will be in the IOR. If there isn't, it will be a random port as chosen by the WCS's operating system. Generally, a random port is not acceptable because administrators won't enable their firewall rules to accept any ports from a specific IP. Note The BusinessObjects Enterprise Administrator's Guide suggests that the use of the -requestport option is required with IP Filter firewalls. When this second connection is made, the -requestport directive should be set to a fixed port number and this port number should be accepted if the IP is from the Web server/Connector machine. This second TCP connection information will look like this:
The firewall will evaluate this request and the port will have to be open. As an example, if the -requestport directive uses port 3333, the firewall rules will have to look like this:
The WCS will respond to this request on whichever port the Web server/WC found to be available. This will be allowed through the firewall because any port is allowed from the internal network to the external. There will then be an established connection between the WCS and the WC, and IP packets will be sent on this channel. The configuration of the firewall rules for an IP Filter firewall between a WCS and WC are summarized in Table 36.1.
Note When the WCS is started with the -requestport switch, this port will have to be open going from Network B to Network C for the IP of the WCS. An Internal Packet Filtering Firewall ScenarioThere are several servers in the BusinessObjects Enterprise environment with which the WCS communicates. It must communicate with the CMS as part of logon/security procedures, while the Cache Server will also be involved in a communication with the WCS for report viewing requests. (Additionally, the WCS will communicate with the Input File Repository Server, where the report objects are maintained when the thumbnail of a report is displayed on the web page.) Obviously, traffic to each of these servers from the WCS will have to be allowed by the IP Filter firewall (see Figure 36.7). Figure 36.7. Configuring an IP Filteringinternal firewall.
First and foremost, the WCS will have to communicate with the CMS. The CMS provides the Name Service in the BusinessObjects Enterprise environment. Without this service, the WCS will not be able to communicate with any of the servers. The CMS listens for requests on the port designated, shown in Figure 36.8 under the configuration tab in the Crystal Configuration Manager (the default value for this port is 6400). Figure 36.8. This screen shows CMS port configuration.Whenever the WCS needs to communicate with the Name Service of the CMS, it does so on port 6400 by default. The first time the WCS has to communicate with the Name Service is when it starts. When the WCS starts, it must register itself with the Name Service as part of its initialization process. This communication occurs on port 6400. A TCP connection occurs between the WCS and CMS for this to happen. The request will have the following information in it:
After the CMS receives this TCP connection request, it responds back to the WCS to complete the initial connection. This connection response contains the following information:
After this initial connection is complete, the CMS sends the WCS its IOR. The WCS then closes the initial connection and establishes a connection to the CMS using the IP and port that is in the IOR. If the CMS is using the -requestport directive, this is the port that the WCS will use to initiate communication with the CMS. This second connection request will contain this information:
The CMS responds to this request to complete the connection. This response contains the following information:
When this connection is complete, the WCS and CMS will hold it open and use it whenever communication between the two is required. From a firewall configuration perspective, two ports are involved in the communication between the CMS and the WCS: first, the port the CMS listens onthis is port 6400 by defaultand second, the port that is established as the main communication channel between these two processesthis should be the value as defined by the -requestport directive. The "rules" for the firewall configuration can be defined as shown in Table 36.2.
Note When the CMS is started with the -requestport switch, this port will have to be open going from Network B to Network A for the IP of the WCS. However, this is only one of three servers with which the WCS would need to communicate. Requests to the Input FRS and Cache Server would still need to be allowed through the firewall. The standard practice is when servers need to communicate with one another, they ask the Name Service for a copy of the IOR of the server they need to contact. To communicate with either the Input FRS or the Cache Server, therefore, the WCS needs to ask the CMS for information about the server to which it needs access. When these servers start, they give the Name Service portion of the CMS a copy of their IOR. As the other servers require access to it, they ask the CMS for a copy of the IOR of the server they need information about. To determine the IOR of a given server, the WCS and CMS collaborate. When the WCS has a copy of the IOR of the particular server, it attempts to make a connection to the server using the information in the IOR. The information in the IOR contains both the IP address and the port to be used for communication and security information. If the -requestport directive is used, the port will be that defined port; otherwise, it's a random port. When working with firewalls, the preferred method is to use -requestport so you can control on which port traffic will be allowed in. As a conclusion, therefore, the firewall rules between Network B and Network A would need to be set up as shown in Table 36.3.
The use of NAT within the IP Filtering firewall adds an additional level of complexity, something explored in the next section. |