Subsections

2.7 Host Attribute Table

Snort can use information from an external source(s) to more accurately inspect network traffic. This information saved to a file is known as a host attributes table. Host attributes are used in IPS rule evalution, IP fragment (see section )/TCP stream (see section ) reassembly policy selection, and by the application preprocessors. Host attribute table is loaded during initialization and supports runtime reloads; Snort reloads the host attributes table when it receives the signal SIGNAL_SNORT_READ_ATTR_TBL (See to learn more).

Note: To use a host attribute table and service information, Snort must be configured with the -enable-targetbased flag.

2.7.1 Rule evaluation

In rule evaluation, service information can be used instead of the ports when the metadata service(s) in the rule matches the service corresponding to the traffic. If the rule does not have metadata service(s), or the packet service was not matched then the port checks are used exclusively.

2.7.2 Snort Configuration

attribute_table filename <PATH/TO/HOSTS.XML>

2.7.3 Host Attribute Table File Format

The attribute table uses an XML format and consists of two sections, a mapping section, used to reduce the size of the file for common data elements, and the host attribute section. The mapping section is optional.

Provided below is an example attribute table

<SNORT_ATTRIBUTES>
    <ATTRIBUTE_MAP>
        <ENTRY>
            <ID>1</ID>
            <VALUE>Linux</VALUE>
        </ENTRY>
        <ENTRY>
            <ID>2</ID>
            <VALUE>ssh</VALUE>
        </ENTRY>
    </ATTRIBUTE_MAP>
    <ATTRIBUTE_TABLE>
        <HOST>
            <IP>192.168.1.234</IP>
            <OPERATING_SYSTEM>
                <NAME>
                    <ATTRIBUTE_ID>1</ATTRIBUTE_ID>
                    <CONFIDENCE>100</CONFIDENCE>
                </NAME>
                <VENDOR>
                    <ATTRIBUTE_VALUE>Red Hat</ATTRIBUTE_VALUE>
                    <CONFIDENCE>99</CONFIDENCE>
                </VENDOR>
                <VERSION>
                    <ATTRIBUTE_VALUE>2.6</ATTRIBUTE_VALUE>
                    <CONFIDENCE>98</CONFIDENCE>
                </VERSION>
                <FRAG_POLICY>linux</FRAG_POLICY>
                <STREAM_POLICY>linux</STREAM_POLICY>
            </OPERATING_SYSTEM>
            <SERVICES>
                <SERVICE>
                    <PORT>
                        <ATTRIBUTE_VALUE>22</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </PORT>
                    <IPPROTO>
                        <ATTRIBUTE_VALUE>tcp</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </IPPROTO>
                    <PROTOCOL>
                        <ATTRIBUTE_ID>2</ATTRIBUTE_ID>
                        <CONFIDENCE>100</CONFIDENCE>
                    </PROTOCOL>
                    <APPLICATION>
                        <ATTRIBUTE_VALUE>OpenSSH</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                        <VERSION>
                            <ATTRIBUTE_VALUE>3.9p1</ATTRIBUTE_VALUE>
                            <CONFIDENCE>93</CONFIDENCE>
                        </VERSION>
                    </APPLICATION>
                </SERVICE>
                <SERVICE>
                    <PORT>
                        <ATTRIBUTE_VALUE>2300</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </PORT>
                    <IPPROTO>
                        <ATTRIBUTE_VALUE>tcp</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </IPPROTO>
                    <PROTOCOL>
                        <ATTRIBUTE_VALUE>telnet</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </PROTOCOL>
                    <APPLICATION>
                        <ATTRIBUTE_VALUE>telnet</ATTRIBUTE_VALUE>
                        <CONFIDENCE>50</CONFIDENCE>
                    </APPLICATION>
                </SERVICE>
            </SERVICES>
            <CLIENTS>
                <CLIENT>
                    <IPPROTO>
                        <ATTRIBUTE_VALUE>tcp</ATTRIBUTE_VALUE>
                        <CONFIDENCE>100</CONFIDENCE>
                    </IPPROTO>
                    <PROTOCOL>
                        <ATTRIBUTE_VALUE>http</ATTRIBUTE_VALUE>
                        <CONFIDENCE>91</CONFIDENCE>
                    </PROTOCOL>
                    <APPLICATION>
                        <ATTRIBUTE_VALUE>IE Http Browser</ATTRIBUTE_VALUE>
                        <CONFIDENCE>90</CONFIDENCE>
                        <VERSION>
                            <ATTRIBUTE_VALUE>6.0</ATTRIBUTE_VALUE>
                            <CONFIDENCE>89</CONFIDENCE>
                        </VERSION>
                    </APPLICATION>
                </CLIENT>
            </CLIENTS>
        </HOST>
    </ATTRIBUTE_TABLE>
</SNORT_ATTRIBUTES>

A DTD for verification of the Host Attribute Table XML file is provided with the snort packages.

The confidence metric may be used to indicate the validity of a given service or client application and its respective elements. That field is not currently used by Snort, but may be in future releases.

Note:
Snort requires that the file be a properly formatted schema of the format defined above. Empty or incorrectly formatted files will likely cause a Fatal Error.

2.7.4 Attribute Table Example

In the example above, a host running Red Hat 2.6 is described. This host has an IP address of 192.168.1.234. On that host, TCP port 22 is ssh (running Open SSH), and TCP port 2300 is telnet.

The IP fragmentation and TCP stream reassembly is mimicked by the "linux" configuration (see sections and ).

2.7.5 Attribute Table Affect on preprocessors

Network Layer Preprocessors
Each of the network layer preprocessors (frag3 and stream5) make use of the respective FRAG_POLICY and STREAM_POLICY in terms of how data is handled for reassembly for packets being received by that host.
Application Layer Preprocessors
The application layer preprocessors (HTTP, SMTP, FTP, Telnet, etc) make use of the SERVICE information for connections destined to that host on that port.
For example, even if the telnet portion of the FTP/Telnet preprocessor is only configured to inspect port 23, Snort will inspect packets for a connection to 192.168.1.234 port 2300 as telnet.
Conversely, if, for example, HTTP Inspect is configured to inspect traffic on port 2300, HTTP Inspect will NOT process the packets on a connection to 192.168.1.234 port 2300 because it is identified as telnet.

Below is a list of the common services used by Snort's application layer preprocessors and Snort rules (see below).

http	ftp	ftp-data	telnet	smtp	ssh	tftp
dcerpc	netbios-dgm	netbios-ns	netbios-ssn	nntp	finger	sunrpc
dns	isakmp	mysql	oracle	cvs	shell	x11
imap	pop2	pop3	snmp

2.7.5.1 Attribute Table Affect on rules

Snort uses service information in two ways; initialization of detection engine and as a detection criteria. To take advantage of this, Snort rules must contain the metadata: service SERVICE convention specified. During rule evaluation the default behavior will check first that the packet has been matched to a service, and then check that the packet's service matches the service(s) specified in the rule; if both these checks passed then Snort will disable source and destination port checks for the rule.

Snort 2.9.8 provides new functionality to control how rules use service information known as "service overrides". Service overrides are specified in the same way that services are specified in the rule, or more simply as a "reserved" SERVICE. The table below defines the new reserved service override names.

Metadata Description

service and-ports

Packet service must be set.

Packet service must match one of the rule services.

Packet must match the ports specified in the rule header.

service or-ports

Packet service is set and it matches one of the rule services (skipping port checks).

Packet service is set but it DOES NOT match one of the rule services; packet must match the ports specified in the rule header.

Packet service is NOT set, only perform port checks.

service else-ports

Packet service is set, packet must match one of the rule services.

Packet service is NOT set; then packet must match the ports specified in the rule header.

This is the default behavior of a rule containing metadata service information.

service unknown
The keyword "unknown" is an alias for "service else-ports" above. It is intended for use in rules that do not contain metadata service information (port only rules). When used in a rule that doesn't otherwise contain metadata (rule only specifies ports), the evaluation is:

Packet service must NOT be set; then match ports.

Metadata	Description
service and-ports	Packet service must be set. Packet service must match one of the rule services. Packet must match the ports specified in the rule header.
service or-ports	Packet service is set and it matches one of the rule services (skipping port checks). Packet service is set but it DOES NOT match one of the rule services; packet must match the ports specified in the rule header. Packet service is NOT set, only perform port checks.
service else-ports	Packet service is set, packet must match one of the rule services. Packet service is NOT set; then packet must match the ports specified in the rule header. This is the default behavior of a rule containing metadata service information.
service unknown	The keyword "unknown" is an alias for "service else-ports" above. It is intended for use in rules that do not contain metadata service information (port only rules). When used in a rule that doesn't otherwise contain metadata (rule only specifies ports), the evaluation is: Packet service must NOT be set; then match ports.