IDMEF Service Zoom¶

Whole Diagram

Alert

• Time
• Analyzer
  • Node/Address
  • Process
• Source/Target
  • Node/Address
  • Process
  • User/UserId
  • Service
  • File
• Assessment
• Classification
• Additional Data

---

---

The Service Class¶

The Service class describes network services on sources and targets. It can identify services by name, port, and protocol. When Service occurs as an aggregate class of Source, it is understood that the service is one from which activity of interest is originating; and that the service is "attached" to the Node, Process, and User information also contained in Source. Likewise, when Service occurs as an aggregate class of Target, it is understood that the service is one to which activity of interest is being directed; and that the service is "attached" to the Node, Process, and User information also contained in Target. If Service occurs in both Source and Target, then information in both locations should be the same. If information is the same in both locations and implementers wish to carry it in only one location, they should specify it as an aggregate of the Target class.

The Service class is composed of four aggregate classes:¶

• name

Zero or one. STRING. The name of the service. Whenever possible, the name from the IANA list of well-known ports SHOULD be used.

• port

Zero or one. INTEGER. The port number being used.

• portlist

Zero or one. PORTLIST. A list of port numbers being used. If a portlist is given, the iana_protocol_number and iana_protocol_name MUST apply to all the elements of the list.

• protocol

Zero or one. STRING. Additional information about the protocol being used. The intent of the protocol field is to carry additional information related to the protocol being used when the <Service> attributes iana_protocol_number or/and iana_protocol_name are filed.

A Service MUST be specified as either (a) a name or a port or (b) a portlist. The protocol is optional in all cases, but no other combinations are permitted.

The Service class has four attributes:¶

• ident

Optional. A unique identifier for the service.

• ip_version

Optional. INTEGER. The IP version number.

• iana_protocol_number

Optional. INTEGER. The IANA protocol number.

• iana_protocol_name

Optional. STRING. The IANA protocol name.

The WebService Class¶

The WebService class carries additional information related to web traffic.

The WebService class is composed of four aggregate classes.¶

• url

Exactly one. STRING. The URL in the request.

• cgi

Zero or one. STRING. The CGI script in the request, without arguments.

• http-method

Zero or one. STRING. The HTTP method (PUT, GET) used in the request.

• arg

Zero or more. STRING. The arguments to the CGI script.

The SNMPService Class¶

The SNMPService class carries additional information related to SNMP traffic. The aggregate classes composing SNMPService must be interpreted as described in RFC 3411 [15] and RFC 3584 [16].

The SNMPService class is composed of eight aggregate classes:¶

• oid

Zero or one. STRING. The object identifier in the request.

• messageProcessingModel

Zero or one. INTEGER. The SNMP version, typically 0 for SNMPv1, 1 for SNMPv2c, 2 for SNMPv2u and SNMPv2*, and 3 for SNMPv3; see RFC 3411 [15] Section 5 for appropriate values.

• securityModel

Zero or one. INTEGER. The identification of the security model in use, typically 0 for any, 1 for SNMPv1, 2 for SNMPv2c, and 3 for USM; see RFC 3411 [15] Section 5 for appropriate values.

• securityName

Zero or one. STRING. The object's security name; see RFC 3411 [15] Section 3.2.2.

• securityLevel

Zero or one. INTEGER. The security level of the SNMP request; see RFC 3411 [15] Section 3.4.3.

• contextName

Zero or one. STRING. The object's context name; see RFC 3411 [15] Section 3.3.3.

• contextEngineID

Zero or one. STRING. The object's context engine identifier; see RFC 3411 [15] Section 3.3.2.

• command

Zero or one. STRING. The command sent to the SNMP server (GET, SET, etc.).