Sun RPC services differ from other services in terms of matching criteria. Where other services can match against transport level protocol and the port information of a connection, RPC service matching is based on an RPC program number and (optionally) a program version. This means the transport level protocol and port(s), which are specified and constant in other services, are unspecified and variable in any RPC service.
The Next Generation Firewall RPC support is implemented by the following five components:
- Sun Portmapper Protocol Agents (PAs) - in both UDP and TCP versions
- Node RPC Cache
- RPC Query Daemon (RPCQD)
- Packet Filter
The Sun Portmapper PAs collect information about RPC services by interpreting the GET PORT
and DUMP PORTS
requests and their respective answers. All collected information is stored in the RPC Cache.
Note This Protocol Agent is not a requirement to allow RPC traffic to pass through the firewall, if external Portmappers are using standard port 111. Its purpose is to improve the RPC program number matching performance. Portmapper PAs support only RPC version 2.
When the Packet Filter needs to evaluate RPC matches, it consults the RPC Cache to check if the packet destination lists the appropriate service defined in the packet filter rule. If the RPC Cache does not have the requested information available, the packet under evaluation is not allowed through, and a query is sent to the RPC Query Daemon. The daemon in turn queries the destination host for the required RPC information and stores the results in the RPC Cache. Configuring Next Generation Firewall for RPC Traffic:
When a security policy contains a rule referring to an RPC program number, it is essential you pay attention to the structure of the rule base. To configure your Next Generation Firewall to use RPC services properly, always follow these considerations:
- Attach Portmapper Protocol Agent only to Portmapper connections passing through the firewall.
- Allow the firewall node to send RPC queries.
- Optimize the structure of your rule base.
Complying with the following guidelines is vital; failing to do so may result in problems ranging from a significant performance slowdown to outright failure in forwarding any RPC traffic. Ensure that you match only the intended traffic to rules with RPC program number services, as other non-RPC traffic matching to these rules may be discarded or experience packet drops or latency.
- Allow the firewall nodes to send RPC queries if the Portmapper PA cannot collect enough information to evaluate rules referring to RPC services. RPC queries are sent within a TCP connection opened from an NDI address to port 111 of the external host. Using Protocol Agents for such connections is not recommended. The firewall nodes only need to be allowed to talk to port 111 of all hosts running Sun RPC services. To do this, you can use either the Sun RPC services configured for TCP and UPD, or the Portmapper combined service, with both Sun RPC services.
- Forcepoint recommends you insert the following rule that allows connections from NDI to port 111 without any PA before any rule matching other Portmapper connections. Create custom services with destination port match and without Protocol.
Source| Destination | Services | Action
Node IP | Any | sunrpc (TCP), sunrpc (UDP) | Allow
- Use Portmapper Protocol Agents only in rules that do not match local connections to RPC Query Daemon. This is required for optimization purposes because everything must operate properly without using PAs. For any connection not originating from the firewall nodes and destined to port 111, you should use Sun RPC (TCP) or Sun RPC (UDP) with Pas.
- If the destination port does not vary, use normal services instead of RPC program number-based services. Most of the standard services register the same port to a Portmapper table to control such connections in a firewall using destination port and protocol.
- Adjust the order of RPC program number rules to the order in which the RPC client uses services in a Portmapper. In addition, it is recommended to insert a single RPC program number service per rule to optimize the matching performance (see example below).
- Try to use RPC matches with Sun RPC services for the smallest portions of the traffic possible. For instance, use RPC matches only for the traffic directed to a host running RPC services and then filter out ports that do not have RPC services (for example, all well- known ports).
- Isolate RPC program number rules (with RPC program number-based services) into separate sub-policies to minimize the number of RPC queries sent by nodes (see example below). The matching order of criteria (like addresses, ports and protocol) is not fully optimized. Therefore, a node may send an RPC query while matching against an RPC program number rule, even if the source or destination addresses of the rule do not match the connection. Any rule referring to an RPC program number must be located after rules referring to normal services. This ensures that connections opening to constant destination port never try to match against an RPC program number.
Example of a policy and a sub-policy containing RPC program number services: Main Policy
Source | Destination | Service | Action
< other rules >...
NDI | Any | Portmapper TCP (to port 111, no PA) | Allow
Non-NDI | Any | Portmapper TCP (to port 111, use PA) | Allow
Non-NDI | Any | Portmapper UDP (to port 111, use PA) | Allow
< other rules >...
Network X | Network Y | Any | Jump to sub-policy Sub-Policy
Source | Destination | Service | Action
< rules using constant ports >...
Any | Any | NFS TCP or UDP (to port 2049) | Allow
Any | Any | Mountd (RPC program number 100005) | Allow
Any | Any | Nlockmgr (RPC program number 100003) | Allow
< rules using RPC program numbers >...