Application Identification (AppID)

How Snort 3’s AppID inspector identifies applications from network traffic, integrates with the detection pipeline, and enables application-aware IPS rules.

Network administrators need to know which applications are on their network in order to write meaningful security policies. AppID provides that visibility by identifying applications from live traffic and making those identities available to IPS rules.

What AppID does

The appid inspector provides:

• Network control: Exposes application identifiers (AppIds) as a matching condition in IPS rules. Rules can block, allow, or alert based on the application — not just port and protocol.
• Application usage statistics: Periodically writes application usage counts to the Snort log directory in unified2 format.
• Custom detectors: Administrators can write Lua detectors for proprietary or internal applications using a well-defined C-Lua API.
• Open Detector Package (ODP): A package of pre-built Lua detectors maintained by the Snort team, available from snort.org.

How it integrates with the detection pipeline

AppID is a passive inspector (IT_PASSIVE). It does not modify packets. Instead, it subscribes to inspection events published by other inspectors:

• HTTP inspector — provides URL, host, User-Agent, and response data for web application identification.
• SSL inspector — provides SNI and certificate fields for encrypted traffic identification.
• SIP inspector — provides call metadata for VoIP application identification.
• DCE/RPC inspector — provides interface UUIDs for Windows service identification.

This subscription model means AppID receives only the data it needs, and only when that data is available. No polling or repeated checking.

(pkt) -> [decode] -> [stream] -> [service] -> [detect] -> [log] -> (verdict)
                 ----------------------------------------
                      [appid]   [firewall]   [other]

AppID identifies flows continuously as more data becomes available. Early in a session it may only know the transport protocol; as the session progresses it refines the identification to an application and potentially a specific host (payload AppID).

Session application identifiers

AppID stores up to four identifiers per session:

Identifier	Description	Example
serviceAppId	Application on the server side	HTTP server
clientAppId	Application on the client side	Firefox
payloadAppId	For services like HTTP: the web application being accessed	Facebook
miscAppId	For encapsulated protocols: the highest encapsulated application	—

When a rule with appids fires, the AppIds are matched in this order for client-originating packets: payloadAppId, miscAppId, clientAppId, serviceAppId. For server-originating packets the order changes to place serviceAppId before clientAppId.

Dependency requirements

AppID requires stream tracking to be enabled at minimum. To identify specific transport protocol applications, the corresponding stream inspector must also be active:

stream     = { }
stream_tcp = { }   -- for TCP-based applications
stream_udp = { }   -- for UDP-based applications

To identify HTTP-based applications, http_inspect must be configured. Without it, only non-HTTP applications are identified.

Configuration

Enable AppID with default settings:

appid = { }

To load application detectors from a specific directory:

appid =
{
    app_detector_dir = '/usr/local/lib/openappid',
}

This directory is expected to contain the ODP layout:

/usr/local/lib/openappid/
    odp/
        lua/     -- Cisco/Snort team Lua detectors
        libs/    -- Cisco/Snort team Lua modules
    custom/
        lua/     -- user-created Lua detectors
        libs/    -- user-created Lua modules

Using AppID in rules

The appids keyword

Use the appids keyword in an IPS rule body to restrict the rule to specific applications:

block tcp any any -> 192.168.0.1 any (
    msg:"Block malicious HTTP header";
    appids:"HTTP";
    content:"X-Header: malicious";
    sid:18000;
)

Multiple applications can be listed; the rule matches if any of them is detected on the flow:

alert tcp any any -> 192.168.0.1 any (
    msg:"Alert on common remote access protocols";
    appids:"telnet,ssh,smtp,http";
    sid:18001;
)

Protocol in the rule header

When AppID has identified the service on a flow, the service name can be used in place of the transport protocol in the rule header:

block http (
    msg:"Block malicious HTTP header";
    content:"X-Header: malicious";
    sid:18000;
)

This rule does not require specifying IP addresses or ports. AppID sets the service on the flow when it is identified, and service-based rules use that information instead of the header.

Minimal working configuration

This is a complete snort.lua configuration sufficient to block flows based on a detected HTTP header:

stream     = { }
stream_tcp = { }

binder =
{
    {
        when = { proto = 'tcp', ports = [[ 80 8080 ]] },
        use  = { type = 'http_inspect' },
    },
}

http_inspect = { }

appid = { }

local_rules =
[[
block http (
    msg:"openAppId: block malicious header";
    content:"X-Header: malicious";
    sid:18760; rev:4;
)
]]

ips =
{
    rules = local_rules,
}

Open Detector Package (ODP)

The ODP is a collection of Lua-based application detectors maintained by the Snort team. It can be downloaded from snort.org and installed in any directory.

1. Download ODP

   Download the Open Detector Package from snort.org.

2. Install the package

   Extract the package to a directory of your choice. ODP creates:

   <install_dir>/
       odp/lua/     -- Lua detectors
       odp/libs/    -- Lua library modules
   

   Installing ODP will not modify any existing custom/ subdirectory.

3. Configure the detector directory

   Point AppID at the installation directory:

   appid =
   {
       app_detector_dir = '/usr/local/lib/openappid',
   }
   
4. Reload detectors at runtime

   After updating detector files, reload them without restarting Snort:

   # Via command interface
   appid.reload_detectors()
   

   Detectors must be updated in app_detector_dir before issuing this command.

User-created application detectors

Custom detectors are Lua scripts placed in the custom/lua/ directory under app_detector_dir:

/usr/local/lib/openappid/custom/lua/myapp.lua

Using the detector creation tool

A helper script, appid_detector_builder.sh, generates Lua detector skeletons interactively:

bash /path/to/appid_detector_builder.sh

The script prompts for:

1. An application name (becomes the AppId and file name).
2. An optional description (placed in comments).
3. The protocol, port, and detection pattern.

You can add multiple patterns for the same application. The resulting .lua file must be placed in custom/lua/.

You can also copy an existing ODP detector as a starting point and modify it. The Lua detector API is documented on the Snort website.

Application usage statistics

AppID periodically writes application network usage to the Snort log directory in unified2 format. The file name, reporting interval, and rollover behavior are controlled by AppID configuration options. Use u2spewfoo to read unified2 output files:

u2spewfoo snort.log.unified2