--------------------------------------- Profinet-IO-CM "UDP Connection" Problem --------------------------------------- Author: Brett Rasmussen Date: 11-18-2020 Normal 'UDP Connection' Port Assignments ---------------------------------------- In normal client server "UDP Connections", the following behavior is usually observed. The client will set the UDP packet SourcePort and DestPort according to the following rules: * The SourcPort will be set to a value to "Identify the client conversation" with the server (e.g. 65160) * The DestPort will be set to the port the "server" process is listening on. (These are often known as "IANA well-known" port numbers.) For example, the DestPort of a DNS server is set to 53. When a DNS client sends a request to a DNS server, it might set the UDP SourcePort to (say) 61160) and the DestPort to 53. * When the DNS server replies to the client, it will set the UDP packet SourcePort to 53 and the DestPort to 65160. (So basically, the "source port" and "destination port" are reversed, when the server responds to a client process.) * More about standard UDP based network "connections" can be found here: ( https://erg.abdn.ac.uk/users/gorry/course/inet-pages/udp.html ) When "normal" UDP connection port assignments are used, the Zeek "Network Security Monitor" (NSM) tool can successfully identify UDP based connections. However, the Profinet-IO-CM protocol does not always follow "standard UDP based connection" rules. (I believe this behavior is linked to the DCE/RPC Port-Mapper functionality, that is also used in the TCP/IP version of the DCE/RPC protocol. More about this port-mapper functionality in a bit.) In a Profinet-IO-CM connection, "some" of the message traffic might look like this: For Wireshark "pn_io_device" "display filtered" traffic, the following request/reply messages were observed. Profinet_Command SourceIP SourcePort DestIP DestPort ---------------- -------- ---------- ------ -------- "ConnectRequest" 192.168.1.3 65151 192.168.1.2 34964 "ConnectResponse" 192.168.1.2 49152 192.168.1.3 65151 "WriteRequest" 192.168.1.3 65151 192.168.1.2 49152 "WriteResponse" 192.168.1.2 49152 192.168.1.3 65151 "ReadRequest" 192.168.1.3 65151 192.168.1.2 49152 "ReadResponse" 192.168.1.2 49152 192.168.1.3 65151 "ReleaseRequest" 192.168.1.3 65151 192.168.1.2 34964 "ReleaseResponse" 192.168.1.2 49152 192.168.1.3 65151 For Wireshark "pn_io_controller" "display filtered" traffic, the following request/reply messages were observed. "ControlRequest" 192.168.1.3 1025 192.168.1.2 34964 "ControlResponse" 192.168.1.2 65151 192.168.1.3 1025 In the traffic examples above, port "34964" functions as a "port-mapper" type port. When responding to a request, the server packet's "SourcePort" is set to a "new value" instead of the (client DestPort) 34964 value. The client should use this "new source port" value, for future server requests. [The port-mapper service functions much like a telephone operator that provides directory assistance. The caller calls the 'operator' and requests a phone number (i.e. port) for a business associate. The operator then provides the 'phone number' (i.e. port) of the requested business person. In our case, the port-mapper provides the 'DestPort' for the requested service interface. From then on, the client should use the supplied "service interface" port number, for future requests. In the example above, the WriteRequest and ReadRequest commands use the specified "service interface" port number (i.e. 49152). (I'm not sure yet, why the "ReleaseRequest" command sends it's request to the port-mapper port (i.e. 34964). Perhaps the "Release" commands belong to a separate RPC "interface"? that uses the same service port number (i.e. 49152) When I talk to the "Profinet USA" tech., I'll ask him this question. :-) ] Some background information: In the "IANA well-known ports list file": See: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt The IANA 34964 port entry is described as follows: "profinet-cm 34964 tcp PROFInet Context Manager [Peter_Wenzel] ..." Ports 49152 (and 65151) fall into the IANA "Dynamic/Private" port range. The "IANA well-known ports list" document states the following: "Port numbers are assigned in various ways, based on three ranges: System Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private Ports (49152-65535);..." ---------------------------------------------------------------------------------------- So, how can Zeek be 'modified' to properly identify "UDP based DCE/RPC Profinet "connection traffic"? * Add a hueristic rule that detect the outer "DCE RPC" wrapper in the UDP packet. * If the Zeek "originator" (i.e. client) SrcPort and DestPort are not reversed in the server's response UDP packet, check to see if the server's (UDP packet) DestPort value matches the originator's SourcePort value. If they match -and- the response packet closely follows the 'request' packet (based on elapsed network time), then treat this UDP conversation as a 'connection'..and log it in the Zeek conn.log file. I will need to make some type of change to the Zeek sourc code, to get it to properly recognize these types of (port-mapper based) UDP connections. If not, I will not be able to properly parse the Profinet_IO_CM traffic, since Zeek cannot recognize the Profinet UDP based connections. (Note: When Zeek does not properly recognize the 'originator' host, it can send packet data (i.e. a PDU) to the wrong parsing routine. e.g. It will send a "Request PDU" to the "Response PDU" parsing routine. If the "Request" message has a different format than the "Response" message, things fall apart rather quickly..and Zeek will not log anything to the "Profinet protocol related" log files.) Thanks! -Brett R