Setting up and configuring the Emerson Smart Firewall

Understanding communications rules

Understanding how the firewall creates and manages communications is helpful when setting up the rules. This topic presents an overview of how the rules work and helps you to understand how a firewall uses these rules as it manages the communications.

The main function of the firewall is to manage network communications between applications that are running on either side of the firewall to ensure that only specific applications (as defined by the ports and protocol parameters in the firewall rules) are allowed access to the computers on the internal side of the firewall - also called the trusted side of the firewall. The firewall also manages network communications from internal computers to external computers. Managing external communications is important to ensure users cannot make connections to unauthorized computers or make unauthorized internet connections that can lead to serious security breaches.

An inbound rule allows internal access to applications that instantiate or initiate communications from applications located on external computers. Most of the applications used with the DeltaV system initiate communications from external applications. This is indicated by the longer list of incoming applications in the firewall.

An outbound rule allows external access to applications that instantiate or initiate communications from applications located on the DeltaV workstations. Making an internet connection from a web browser is an example of an outgoing communications application.

Some applications can have both an inbound and outbound rule as they can initiate communications in either direction. For example ICMP Pings can originate from either inside or outside of the firewall depending upon which computer starts the pinging process. Rules for both directions can exist at the same time.

The firewall is capable of tracking the communications and allowing two-way communications to be created with a single rule. This means that when communications is initiated from one direction the application on the other end can reply without a corresponding rule. One rule allows the complete bi-directional communications to be initiated.

An exception occurs when an application requests that data is sent in a separate communication such as when an OPC data subscription is created. In this case, a rule must be created to allow the subscribed data to be sent to the workstation that requested it. An inbound rule allows the subscription to be created and an outbound rule allows the DeltaV workstation to send the data.

How does the firewall manage communications

A rule gives the firewall permission to allow communications to be created between applications. The firewall checks the communications packets and if the source, destination, port and protocol information match the rule, the communication is allowed and a conversation is created between the applications. The first time a valid packet is received, a conversation is added to the table of watched conversations called a state table and the state of each conversation is monitored. These conversations are called sessions.

The firewall uses the state table information to validate the source, destination, and port and protocol information in each message coming to the firewall and rejects any communication packets that do not match all of the parameters in the state table. Once the session is started, the firewall uses the information in the table to validate the packets. It does not use the rule for validation at this point as there can be several concurrent sessions flowing based on the same rule. Each conversation is handled independently as the ports used in the sessions are assigned dynamically by the applications as they create the session. The firewall discovers these dynamic ports and uses them to monitor the packets in the session.

Once the session ends, the information is removed from the state table. The next time communications is initiated, the rules are applied to validate the communications and a new session is created. Sessions can be very short or very long depending upon the way the applications communicate.

The rule does not create the path for the communications it simply allows the communications to be created. Each independent session is the path for the communications. One rule can allow many simultaneous communications to be created between the applications as necessary for the applications to function.

This information is important to know for several reasons:

  1. As you create the rules you do not have to be concerned with knowing how the application works as it creates communications; the firewall only needs the rule(s) that allow the application to communicate.
  2. You do not have to create matching inbound and outbound rules for the same session. The firewall manages the communications and allows the session to work correctly.
  3. When you modify, delete or disable a rule or a time based rule expires any current communications do not stop immediately. Removing the rule prevents future communications from being allowed and created. When you remove a rule (as you might do during some setup or troubleshooting activity) you also need to disconnect any existing communications through the firewall.
  4. The applications listed in the firewall's Application List are not rules. These applications simply provide the parameters required to create a communications rule. Think of them as templates that are used to create a rule. In DeltaV terms these are similar to control modules you select and then fill in with the specific data required to create the module. When you create and apply the rule you are filling in the module information and instantiating the rule into the firewall to allow communications.