What can we do with the 'unknown' applications?

What is the unknown-tcp or unknown-udp that sometimes shows up in traffic logs? In terms of App-ID, these are connections where not enough data, or data that did not match any known applications's behavior, were transferred and App-ID was unable to identify a known application. When this type of application is seen inside the organization, there's a good chance this is benign traffic: maybe a homebrew backup or a scripted maintenance task. If these show up on sessions going out to, or coming in from the internet, they should be a reason for concern.

As a rule of thumb, best practice is to block all unknown-udp/unknown-tcp as you are not sure what kind of sessions these are and they could be malicious.

Blindly blocking all unknown traffic, however, may be a little drastic as some of it may be legitimate and may be required for operational purposes. The best solution is to start identifying traffic by creating custom applications, so security policies can be created to better control which flows are allowed and which ones should be blocked.

The quickest way to go about this is to create a simple custom application and set an app override. This is helpful when the source and destination are internal and static, like a scripted connection from one server to the next inside a controlled environment:

1. Create a simplified custom application with no advanced attributes or signatures.
   
   I've set the risk factor to 5 because this method is applying an AppID to sessions without further inspection.
   
   
2. Creat an Application override policy to match the intended flow exactly (Application Override should only be used to identify flows that are known to the administrator).
   
3. The sessions will now be identified as the custom application and security policy can be created to control the session based on the application.
   

The best way to identify the application is by setting up a packetcapture to gain a good understanding of what the application looks like to the firewall and then create a signature to match the expected content. This way you can make absolutely sure the session is legitimate.

1. Set up packet capture and collect the pcap files after you've collected a full session. For more information on packet captures, please check out his article: Getting Started: Packet Capture
   
2. Analyze the packet capture for an appropriate signature.
   
   
   For the following example, I will use the HEX value of "2f69 6e66 6f3f 7478 7441 6972 506c 6179 2674 7874 5241 4f50" which is the clear text equivalent of "/info?txtAirPlay&txtRAOP" in my packetcapture.
   
   
3. Create a new custom application that matches the parameters of the session you are going to identify: In my example I have captured a custom AirPlay protocol which I've assigned a risk factor of 1 as it is deemed safe inside the organization.
   
   
   
   It will use TCP port 7000 as destination port from client to server.
   
   
   In the signature, you can use the HEX value from the pcap as seen in this example: (for HEX patterns, make sure to add a leading and trailing '\x' to let the engine know it needs to match the HEX and not for translated cleartext)
   
   
   Or a regex string as seen in this example: (for strings of cleartext, make sure to comment any special characters with a forward slash '\' to indicate this is a literal match for the character, else it could be identified as a wildcard).
   To further limit the location of the string, I have set a qualifier for http-method GET, as this is where the string should be found as opposed to further in the body. The context for this signature is the http request parameter as the custom AirPlay protocol uses http commands to communicate with the server, the context option will need to be set to the appropriate protocol, if any, used in the communication between client and server.
   
   For more examples, please check out Video Tutorial: Custom application and Getting Started: Custom applications and app override. Common contexts include 'unknown-req-tcp-payload', 'unknown-rsp-tcp-payload', 'http-req-host-headers' and several others where -req- stands for client requests, and -rsp- are server replies, allowing you to choose which side to intercept and identify.
   
   
4. After the custom application has been created and the configuration committed, the unknown-tcp sessions should be replaced by the new custom application in the logs:
5. Which means security policy can now be created to have more control over this specific application, allowing you to block unknown traffic without interfering with business-critical applications:
   

I hope you found this article informative, please feel free to leave a comment.

Reaper

For more ideas and examples on custom applications please visit the Palo Alto Networks Custom Signature discussion board.

See also--

Getting Started: Packet Capture

Video Tutorial: Custom application

Getting Started: Custom applications and app override