yaf deep packet inspection
yaf(1) can examine packet payloads, capture useful information for a specific protocol, and export it in a protocol-specific template within yaf's SubTemplateMultiList if yaf is built with plugin support enabled (using the --enable-plugins option to ./configure). It may be necessary to set the LTDL_LIBRARY_PATH environment variable if the plugins were installed in a nonstandard location.
The DPI plugin requires payload capture to be enabled with the --max-payload option. A minimum payload capture length of 384 octets is recommended for best results. --applabel is also required, as the application label determines how the inspection will execute.
DPI in yaf is directly related to application labeling as it will only perform DPI if a match was found during the application labeling phase, and it will only execute an inspection specific to the protocol denoted by the application label.
In order to enable DPI in yaf the following should be added to the command line:
--plugin-name=/usr/local/lib/yaf/dpacketplugin.la
You can also add the option switch to specify which protocols to perform DPI:
--plugin-opts="53 80 21"
The above will perform DPI for DNS, HTTP, and FTP.
DPI operates differently depending on whether the protocol is plugin-based or regex-based in the yafApplabelRules.conf file. If the protocol uses a regex rule for application labeling, it will have a list of regular expressions in the yafDPIRules.conf file that are compared against the captured payload. Any matches are stored and later exported in an IPFIX information element. If the protocol is based on a plugin rule, it will store important information while it is decoding the payload using the dynamically loaded plugin listed in the yafApplabelRules.conf file. See the source code to the plugins included with yaf for details on the specific protocol implementations. Some plugins will allow configurable deep packet inspection from the yafDPIRules.conf file, such as DNP 3.0, Ethernet/IP, and SCADA. See below for specific information on these particular protocols.
In order to perform DPI on DNSSEC resource records, add "DNSSEC" to the --plugin-opts option:
--plugin-opts=DNSSEC
--plugin-opts="DNSSEC 53"
The yafDPIRules.conf file should be in the same location as the yafApplabelRules.conf file. The file follows a similar format to yafApplabelRules.conf (see applabel(1)). The file is a list of label, element pair statements. A label statement begins with the keyword 'label', and has the following form:
label <N> element <N2> <element-rule>
where <N> is the application label (usually the well-known port) found in the yafApplabelRules.conf file (an unsigned 16-bit decimal integer in the range 0 to 65535), <N2> is the Information Element ID found in the CERT IPFIX Registry and below, and <element-rule> is a PCRE regular expression and will be stored and associated with the ID number preceding it. There can be multiple lines for a single application label, however each should have a different <N2>. There should be parentheses around the substring you want to capture and store. If there is more than 1 set of parentheses in the regular expression, the most outer set is the substring captured. (See PCRE documentation for details on regular expressions and substring matching.)
To define your own information elements, use the following form:
label <N> user <E> name <element-name> <element-rule>
where <N> is the application label found in yafApplabelRules.conf file. <E> is the Information Element ID in the range of 0 to 65535 to be given to the element upon export. This number should be unique to this file and should NOT be defined in the CERT IPFIX Registry. This element will be added to the template upon processing of this file, and must be added to the yaf collecting process in order to properly decode the IPFIX message. <element-name> is the name you want to give to this IPFIX Information Element. This name can consist of letters and numbers and underscores; it can not contain special characters or spaces. <label-rule> is the PCRE regular expression and will be stored and associated with the Information Element ID and name preceding it. There is a limit of 30 additional fields per protocol that YAF will store and execute. To find out if yaf accepted your elements, run yaf with --verbose. All user elements will be exported using the CERT Private Enterprise Number (PEN) 6871. ONLY user labels for protocols FTP, HTTP, IMAP, SMTP, RTSP, SSH, and SIP will be added. Elements will be added to the template in the order they are listed in the yafDPIRules.conf file in the form of an fbBasicList_t. By default, HTTP exports 20 basicLists, FTP exports 5 basicLists, IMAP exports 7 basicLists, RTSP exports 12 basicLists, SIP exports 7 basicLists, SMTP exports 11 basicLists, and 1 basicList is exported for SSH.
A "#" smybol starts a comment for the entire line. If a rule is not properly formatted, all subsequent rules may not be processed. It is acceptable to comment out any yaf DPI rules. yaf rules commented out will not be executed against the payload but they will still exist in the template and record. User-defined information elements are added based on the configuration file at run time.
Optionally, this file may contain two limit statements to configure the DPI plugin. A limit statement begins with the keyword 'limit', and has the following form:
limit [field|total] <limit-value>
If the "field" label is present, the <limit-value> will be the number of bytes yaf will export for any given field in this file. This does not affect the DNS Deep Packet Inspection or SSL Certificate Capture. FOr DNS, a domain name can have a maximum of 255 characters, so the limit is not configurable.
If the "total" field is present, the <limit-value> will be the total number of bytes yaf may export from the DPI plugin. Obviously, this number will not be larger than the --max-payload value yaf is given at run time.
Both the field and total limits have a maximum value of 65535. If they are larger, they will revert back to the defaults of 200 for per-field limit and 1000 for total limit.
There are also 2 configuration parameters related to SSL export. By default, yaf parses the X.509 certificates and exports the information described below under SSL/TLS. If the following line is present:
cert_export_enabled = 1
yaf will export the full X.509 certificate in the format described below under Full Certificate Export. Setting this variable to 1 disables the traditional SSL certificate decode and export. If the second configuration variable is present:
cert_hash_enabled = 1
yaf will export the hash of the X.509 certificate as found in the certificate. This is typically the SHA-256 hash of the binary certificate but it can vary on the hashing algorithm used. The hashing algorithm can be identified by the sslCertSignature field. If both cert_export_enabled and cert_hash_enabled are set to 1, yaf will export both the full X.509 certificate and perform the traditional decode of the X.509 certificate. It is not recommended to do both. If cert_export_enabled is set to 1, super_mediator(1) can perform the extraction of relevant fields as is done by yaf, plus it provides the option to perform SHA-1 or MD5 hashes of the certificate.
Upon yaf startup and capture, you will be able to see if the rule files and their regular expressions were accepted using the --verbose flag.
[2013-05-03 19:39:25] DPI Running for ALL Protocols
[2013-05-03 19:39:25] Reading packets from packets.pcap
[2013-05-03 19:39:25] Initializing Rules from DPI File /usr/local/etc/yafDPIRules.conf
[2013-05-03 19:39:25] DPI rule scanner accepted 63 rules from the DPI Rule File
An unacceptable regular expression will be brought to your attention with the above statements. If you choose certain protocols for inspection using the --plugin-opts
flag, only the appropriate rule statements will be loaded into the DPI Rule Scanner.
The following options can be given to ./configure when yaf is built to export DNS authoritative and NXDomain Responses only.
Enable export of DNS Authoritative Responses only. The default is to capture and export all DNS Responses. This flag can be used in conjunction with --enable-exportDNSNXDomain. It is only recognized if --plugin-name is set to the DPI plugin, application labeling is enabled, and --max-payload is set.
Enable export of DNS NXDomain Responses only. The default is to capture and export all DNS Responses. This flag can be used in conjunction with --enable-exportDNSAuth. It is only recognized if --plugin-name is set to the DPI plugin, application labeling is enabled, and --max-payload is set.
yaf's output consists of an IPFIX message stream. yaf uses a variety of templates for IPFIX data records; As of yaf 2.0, yaf uses a subTemplateMultiList to export optional information elements, such as Deep Packet Inspection fields, relating to the flow. Below are templates that may appear in this subTemplateMultiList depending on the application label of the flow. For more information on yaf information elements see yaf(1). For more information on IPFIX Structured lists, see the Internet Draft, Export of Structured Data in IPFIX, <RFC 6313>. Most of the elements are exported as a basicList. An IPFIX basicList represents a list of zero or more instances of any Information Element (IE 291).
File Transfer Protocol (FTP) Deep Packet Inspection is based on RFC 959. The following information elements are exported as a template in the subTemplateMultiList as basicLists of variable length elements in the order they are listed in the yafDPIRules.conf file. YAF will always export at least 5 basicLists for FTP, even if not all of the following are enabled. By default, they will be in the following order:
FTP Commands or Replies.
FTP User Command Argument. This command will normally be the first command transmitted by the user.
FTP Password Command Argument. This command must be preceded by the user name command, and is usually required to complete authentication.
FTP Data Representation Type.
FTP Reply. This consists of a three digit number followed by some text.
HTTP Deep Packet Inspection is based on RFC 2616. The following information elements are exported as a template in the subTemplateMultiList as basicLists of variable length elements in the order they are listed in the yafDPIRules.conf file. Some elements are not enabled by default. The template will always contain at least 20 information elements even if less elements are enabled in the configuration file. By default, the following 20 information elements are exported in the following order:
HTTP Server Response-header field. Contains information about the software used to handle the HTTP Request.
HTTP User-Agent Request-header field. Contains information about the user agent originating the request.
HTTP Method Command. Retrieves information identified by the following Request-URI.
HTTP Connection header fields. Contains options that are desired for a particular connection.
HTTP Referer request-header field. Address (URI) of the resource which the Request-URI was obtained.
HTTP Location response-header field. Used to redirect the recipient to a location to complete a request or identify a new resource.
HTTP Host Request-header. The Internet host and port number of the resource being requested.
HTTP Content-Length header. Indicates the size of the entity-body.
HTTP Age response-header. Argument is the sender's estimate of the time elapsed since the response.
HTTP Response Status Code. Usually a three-digit number followed by text.
HTTP Accept-Language Request-Header field. Restricts the set of natural languages that preferred.
HTTP Accept request-header field. Used to specify certain media types that are acceptable for the response.
HTTP Content Type entity-header field. Indicates the media type of the entity-body.
HTTP Version Number.
HTTP Cookie Header Field.
HTTP Set Cookie Header Field.
HTTP Authorization Header Field.
HTTP Via Header Field.
HTTP X-Forwarded-For Header Field.
HTTP Refresh Header Field.
The following information elements are defined but not enabled by default. To enable any of the following fields, uncomment the line in the yafDPIRules.conf file.
HTTP Expires Header Field.
HTTP International Mobile Station Equipment Identity ID.
HTTP International Mobile Subscriber Identity
HTTP MSISDN number, a telephone number for the SIM card in a mobile/cellular phone.
HTTP Mobile Subscriber Information
HTTP Accept Charset Header Field.
HTTP Accept Encoding Header Field.
HTTP Date Header Field.
HTTP Expect Header Field.
HTTP From Header Field.
HTTP Proxy Authentication Field.
HTTP Upgrade Header Field.
HTTP Warning Header Field.
HTTP DNT Header Field.
HTTP X-Forwarded-Proto Header Field.
HTTP X-Forwarded-Host Header Field.
HTTP X-Forwarded-Server Header Field.
HTTP X-Device ID Header Field.
HTTP X-Profile Header Field.
HTTP Last Modified Header Field.
HTTP Content Encoding Header Field.
HTTP Content Language Header Field.
HTTP Content Location Header Field.
HTTP X-UA-Compatible Header Field.
IMAP Deep Packet Inspection is based on RFC 3501. The following information elements are exported as a template in the subTemplateMultiList as basicLists of variable length elements in the order they are listed in the yafDPIRules.conf file. yaf will always export at least 7 fields in the IMAP template and data record. By default, yaf exports the following fields in order:
IMAP Capability Command and Response. Captures the listing of capabilities that the server supports.
IMAP Login Command. Arguments are user name and password.
IMAP STARTTLS Command. Captures this command only as no arguments or responses are related.
IMAP Authenticate Command. Captures the authentication mechanism name of the server following this command.
Captures a variety of IMAP Commands and their arguments.
IMAP Exists Response. Reports the number of messages in the mailbox.
IMAP Recent Response. Reports the number of message with the Recent flag set.
Real Time Streaming Protocol (RTSP) Deep Packet Inspection is based on RFC 2326. The following information elements are exported as a template in the subTemplateMultiList as basicLists of variable length elements in the order they are listed in the yafDPIRules.conf file. yaf will always export at least 12 information elements in the RTSP template and data record. By default, the following information elements are exported in order:
RTSP URL. Captures the address of the network resources requested.
RTSP Version Number.
RTSP Status-Line. Captures the RTSP Protocol version, numeric status code, and the textual phrase associated with the numeric code.
RTSP Content-Length Header Field. Contains the length of the content of the method.
RTSP Command. Captures the method to be performed and the Request-URI associated with the method.
RTSP Content Type.
RTSP Transport request header field. Captures the transport protocol used and the parameters that follow.
RTSP CSeq field. Contains the sequence number for an RTSP request-response pair.
RTSP Location header field.
RTSP Packets Received header field.
RTSP User Agent field. Contains information about the user agent originating the request.
RTSP Jitter Value.
Session Initiation Protocol (SIP) Deep Packet Inspection is based on RFC 3261. The following information elements are exported as a template in the subTemplateMultiList as basicLists of variable length elements in the order listed in yafDPIRules.conf. yaf will always export at least 7 information elements in the SIP template and data record. By default, the following information elements are exported in order:
SIP Invite Method. Contains the SIP address and SIP Version Number.
SIP Command. Contains a SIP Method, SIP address, and SIP Version Number.
SIP Via contains the SIP Version Number and the address the sender is expecting to receive responses.
SIP Max Forwards contains the limit of number of hops a request can make on the way to its destination.
SIP Address contains the argument of the To, From, or Contact Header Fields.
SIP Content Length header field. Contains the byte count of the message byte.
SIP User Agent Header Field. Contains information about the User Agent Client originating the request.
Simple Mail Transfer Protocol (SMTP) Deep Packet Inspection is based on RFC 2821. Note: The templates used for SMTP DPI changed in YAF 2.12.0.
An SMTP conversation is exported as a nested set of templates in subTemplateMultiList. The outer template (yaf_smtp) includes the following elements.
SMTP Hello or Extend Hello command. Captures the command and the domain name of the SMTP client.
Enhanced SMTP. Contains the ESMTP command with the following argument.
SMTP Message Size
START TLS. Element indicating whether or not the SMTP session sent the START TLS command.
A basicList of SMTP Replies, represented by smtpResponse (IE CERT/169, variable length, string) elements. Each smtpResponse contains of a three digit number followed by text.
A subTemplateList containing zero (but usually at least one) or more records described by the yaf_smtp_message template. Each record represents a single email message sent during the SMTP conversation. That template contains the following elements:
The subject of the message.
The SMTP Recipient (RCPT) Command. A basicList containing smtpTo (IE CERT/164, variable length, string) elements. Each smtpTo captures the command and the forward-path of the recipient of the mail data.
SMTP Mail Command. A basicList containing smtpFrom (IE CERT/163, variable length, string) elements. Each stmpFrom contains the reverse-path of the sender mailbox.
SMTP Filename. A basicList containing smtpFilename (IE CERT/167, variable length, string) elements. Each smtpFilename contains the name of a file attached to the mail message, if any.
SMTP URL. A basicList containing smtpURL (IE CERT/329, variable length, string) elements. Each smtpURL contains a URL captured in the SMTP message body, if any.
A subTemplateList containing zero or more records described by the yaf_smtp_header template. Each record represents a single header (SMTP field name and body) in the email DATA. That template contains the following elements:
SMTP Header key string. The name of the header (for example, "To", "From").
SMTP Header value string. The value of that header.
By default, yaf exports 14 information element's in the SSH template and data record.
SSH Client Version Number
The version string from an SSH server.
The negotiated key exchange algorithm used for an SSH session.
The negotiated host key algorithm used for an SSH session.
The MD5 hash of the public key of the SSH server.
The negotiated symmetric encryption algorithm used for an SSH session.
The negotiated MAC algorithm used for an SSH session.
The negotiated compression algorithm used for an SSH session.
The client HASSH MD5 hash of the sshHasshAlgorithms (CERT/469) fingerprint for an SSH client.
The server HASSH MD5 hash (hasshServer) of the sshServerHasshAlgorithms (CERT/471) fingerprint for an SSH server.
The SSH client hasshAlgorithms: the concatenated name-lists of the client-to-server algorithms delimited by a semicolon. Element sshHassh (CERT/468) holds the MD5 of this.
The SSH server hasshServerAlgoritms: the concatenated name-lists of the server-to-client algorithms delimited by a semicolon. Element sshServerHassh (CERT/470) holds the MD5 of this.
Domain Name System (DNS) Deep Packet Inspection is based on RFC 1035. DNS Information is exported in the yaf subTemplateMultiList as a subTemplateList of Resource Record Templates. Each resource record entry contains generic resource record information such as type, TTL, and name. There is also one element (subTemplateList) that contains resource record specific information based on the type of resource record (A Record vs NS Record, for example). The subTemplateList will contain one entry for each resource record in the packet. Due to alignment issues, the resource record specific element is the first element in the template and is therefore the first item listed below. DNSSEC information is not exported by default. To export DNSSEC information, run yaf with --plugin-opts=DNSSEC. The following information elements exist in the DNS resource record subTemplateList:
The following elements (in order) are contained in the DNS Resource Record Template.
An IPFIX subTemplateList. This list contains a "DNS Resource Record Type" Template. The type of this template depends on the type (dnsQRType) of resource record. See the DNS Resource Record Types listed below.
A DNS Query or Response Name. This field corresponds with the QNAME field in the DNS Question Section or the NAME field in the DNS Resource Record Section.
DNS Time To Live. This is an unsigned integer that specifies the time interval, in seconds, that the resource record may be cached for. This will contain a value of zero for DNS Queries.
DNS Query/Response Type. This corresponds with the QTYPE field in the DNS Question Section or the TYPE field in the DNS Resource Record Section. This field determines the type of subTemplateList found in this record.
DNS Query/Response header field. This corresponds with the DNS header one bit field, QR. If the message is a query (0), or a response (1).
DNS Authoritative header field. This corresponds with the DNS header one bit field, AA. This bit is only valid in responses (when dnsQueryResponse is 1), and specifies that the responding name server is an authority for the domain name in the question section.
DNS NXDomain or Response Code (RCODE). This corresponds with the DNS RCODE header field. This field will be set to 3 for a Name Error, 2 for a Server Failure, 1 for a Format Error, and 0 for No Error. See http://www.iana.org/assignments/dns-parameters for other valid values.
DNS Resource Record Section Field. This field will be set to 0 if the information is from the Question Section, 1 for the Answer Section, 2 for the Name Server Section, and 3 for the Additional Section.
DNS Transaction ID. This identifier is used by the requester to match up replies to outstanding queries.
DNS A Resource Record
This entry will exist if dnsQRType is 1 and the A Record contains an IP address.
IPv4 address of the host.
DNS NS Resource Record
This entry will exist if dnsQRType is 2 and the NS Record contains an NSDNAME.
An authoritative name server domain-name.
DNS CNAME Resource Record
This entry will exist if dnsQRType is 5 and the CNAME Record contains an CNAME.
A domain-name which specificies the canonical or primary name for the owner.
DNS SOA Resource Record
This entry will exist if dnsQRType is 6 and the SOA Record contains at least 1 of the following elements:
Corresponds to DNS SOA MNAME Field.
Corresponds to DNS SOA RNAME Field.
Corresponds to DNS SOA SERIAL Field.
Corresponds to DNS SOA REFRESH Field.
Corresponds to DNS SOA RETRY Field.
Corresponds to DNS SOA EXPIRE Field.
Corresponds to DNS SOA MINIMUM Field.
DNS PTR Resource Record
This entry will exist if dnsQRType is set to 12 and PTRDNAME exists.
Corresponds to DNS PTR PTRDNAME Field.
DNS MX Resource Record
This entry will exist if dnsQRType is set to 15 and MXExchange exists
Corresponds to the DNS MX Exchange field.
Corresponds to the DNS MX Preference field.
DNS TXT Resource Record
This entry will exist if dnsQRType is set to 16 and TXT-DATA exists.
Corresponds to DNS TXT TXT-DATA field.
DNS AAAA Record
This entry will exist if dnsQRType is set to 28 and the IPv6 Address exists. See RFC 3596.
An IPv6 Address found in the data portion of an AAAA Resource Record.
DNS SRV Record
This entry will exist if dnsQRType is set to 33 and at least 1 of the following elements exist. See RFC 2782.
Corresponds to the Target Field in the DNS SRV Resource Record.
Corresponds to the Priority Field in the DNS SRV Resource Record.
Corresponds to the Weight Field in the DNS SRV Resource Record.
Corresponds to the Port Field in the DNS SRV Resource Record.
DNSSEC DNSKEY Record
This entry will exist if dnsQRType is set to 48 and at least 1 of the following elements exist. See RFC 4034.
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets. This field holds the public key. The format depends on the algorithm of the key.
The flags field in the DNSKey Resource Record. Certain bits determine if the key is a zone key or should be used for a secure entry point.
The protocol field in the DNSKEY RR. This should be 3 or treated as invalid.
Identifies the public key's cryptographic algorithm, which determines it's format.
DNSSEC DS Record
This entry will exist if dnsQRType is set to 43, yaf was enabled to export DNSSEC information, and at least 1 of the following elements exist. See RFC 4034.
The digest of the DNSKEY RR.
The Key Tag field in the DS RR.
The Algorithm number of the DNSKEY RR referred to by the DS Record.
The Digest Type field which identifes the algorithm used to construct the digest.
DNSSEC NSEC Record
This entry will exist if dnsQRType is set to 47, yaf was enabled to export DNSSEC information, and the following field exists. See RFC 4034.
This item contains the Next Domain Name in the NSEC RR.
DNSSEC NSEC3 or NSEC3PARAM Record
This entry will exist if dnsQRType is set to 50 or 51, yaf was enabled to export DNSSEC information, and at least one of the following fields exists. See RFC 5155.
The Salt Field in the DNSSEC NSEC3 or NSEC3PARAM RR.
The Next Hashed Owner Name in the DNSSEC NSEC3 RR. This will be empty for NSEC3PARAM records.
The Iterations field in the DNSSEC NSEC3 or NSEC3PARAM RR.
The Hash Algorithm field in the DNSSEC NSEC3 or NSEC3PARAM RR. Values are described in RFC 5155.
DNSSEC RRSIG Record
This entry will exist if dnsQRType is set to 46, yaf was enabled to export DNSSEC information, and at least one of the following fields exists. See RFC 4034.
The Signer's Name field in the RRSIG RR.
The Signature field in the RRSIG RR. Contains the cryptographic signature that covers the dnsQName field.
The Signature Inception field in a RRSIG RR. The Expiration and Inception fields specify a validity period for the signature.
The Signature Expiration field in a RRSIG RR. The Expiration and Inception fields specify a validity period for the signature.
The Original TTL Field in the RRSIG RR.
The Key Tag field in a RRSIG RR.
The Type Covered field in a RRSIG RR.
The Algorithm Number field in a RRSIG RR. Identifies the algorithm used to create the signature.
The Labels field in a RRSIG RR. Specifies the number of labels in the original RRSIG resource record owner name.
Secure Socket Layer (SSL)/Transport Layer Security (TLS) Deep Packet Inspection can identify and export handshake and certificate information if it is contained in the payload of the flow. Each certificate identified by yaf is exported as an entry in the subTemplateList field below. Each entry in the subTemplateList has three nested subTemplateLists, one for issuer fields, one for subject fields, and one for extension fields, along with other basic handshake elements such as serial numbers and validity timestamps. Each of the nested subTemplateLists contain an ID and a value. The IDs correspond to the attributes associated with X.509 Certificates, object identifiers id-ce and id-at.
sslCipher is exported by yaf as a basicList that contains the list of CipherSuites suggested by the client in the ClientHello Message.
sslServerCipher is the CipherSuite chosen by the server in the ServerHello message.
sslClientVersion is the version it supports contained in the initial ClientHello message.
sslCompressionMethod is the compression method chosen by the server in the ServerHello message.
sslRecordVersion is the version of ssl or tls that was used in the flow.
The JA3 MD5 hash of the sslClientJA3Fingerprint (CERT/464) calculated on the client-side TLS/SSL fingerprint string.
The JA3 fingerprint string enumerated from the TLS/SSL ClientHello packet. Element sslClientJA3 (CERT/463) holds the MD5 of this.
The JA3S MD5 hash of the sslServerJA3SFingerprint (CERT/466) calculated on the server-side TLS/SSL fingerprint string.
The JA3S fingerprint string enumerated from the TLS/SSL ServerHello packet. Element sslServerJA3S (CERT/465) holds the MD5 of this.
This contains 0 or more X.509 Certificates as available to yaf in the captured payload. Note that most certificate chains are about 3000 bytes. In order to capture the entire certificate chain, --max-payload should be set appropriately.
The Issuer field identifies the entity that has signed and issued the certificate. It is encoded as a sequence of Relative Distinguished Names, which are basically type, value pairs. This list will contains zero or more occurences of the RelativeDistinguishedName id, value pairs pulled from the X.509 Certificate Issuer RDNSequence. There will be one entry in the list for each pair. See below for a common list of attributes.
The Subject field identifies the entity associated with the public key stored in the subject public key field. It is encoded as a sequence of Relative Distinguished Names, which are basically type, value pairs. This list will contains zero or more occurences of the RelativeDistinguishedName id, value pairs pulled from the X.509 Certificate Subject RDNSequence. There will be one entry in the list for each pair. See below for a common list of attributes.
Extensions are only defined for X.509 v3 certificates and provide methods for associating additional attributes with the Issuer and Subject information. Each extension includes an object identifier and an ASN.1 structure. This list will contain zero or more occurences of the object ids and ASN.1 values. yaf will not parse the ASN.1 values for the string objects, it includes the entire ASN.1 structure in the value field. However, it does not contain the entire Extension ID. yaf only parses extensions that are members of the id-ce arc and only exports information about the following objects:
The signature contained in a SSL certificate. This is typically the hashing algorithm identifier.
The Serial Number from the X.509 certificate.
The notBefore field in the Validity Sequence of the X.509 Certificate.
The notAfter field in the Validity Sequence of the X.509 Certificate.
The algorithm, encoded in ASN.1, in the SubjectPublicKeyInfo Sequence of the X.509 Certificate.
The length of the public key in the X.509 Certificate.
The Certificate Version. This is the value contained in the certificate v1(0), v2(1), v3(2).
The hash of the X.509 certificate. This field is only populated if the cert_hash_enabled is present and set to 1.
The server name from the SSL/TLS Client Hello. This is typically the name of the server that the client is connecting to.
Each subtemplateList for the above issuer, subject, and extension sequences will contain zero or more entries of the below elements.
sslObjectValue CERT (PEN 6871) IE 246, variable length
The bit strings associated with the below attribute types.
sslObjectType CERT (PEN 6871) IE 245, 1 octet, unsigned
Above lists the extension types that yaf will export. For the Issuer and Subject subTemplateLists, yaf only parses objects that are members of the id-at arc {joint-iso-ccitt(2) ds(5) 4}, pkcs-9 {iso(1) member-body (2) us(840) rsadsi(113459) pkcs(1) 9}, and LDAP dc 0.9.2342.19200300.100.1.25. This field will not contain the full object identfier, it will just contain the member id. For example, for an issuer common name, sslObjectType will contain 3. Below is a list of common objects in an X.509 RelativeDistinguishedName Sequence for X.509 Certificates:
yaf will export the full X.509 certificate if the cert_export_enabled variable is present and set to 1 in the configuration file. The following information is exported as an extra entry in the subTemplateMultiList as a basicList:
Internet Relay Chat (IRC) Deep Packet Inspection is based on RFC 2812. The following information element is exported as a template in the subTemplateMultiList as a basicList of variable length elements in the following order:
IRC Chat or Join Message. This field contains any IRC Command and the following arguments.
Network News Transfer Protocol (NNTP) Deep Packet Inspection is based on RFC 977. The following information elements are exported as a template in the subTemplateMultiList in the following order:
NNTP Reply. This consists of a three digit status code and text message.
NNTP Command. Contains an NNTP Command and following argument(s).
Post Office Protocol 3 (POP3) Deep Packet Inspection is based on RFC 1939. The following information element is exported as a template in the subTemplateMultiList as a basicList of variable length elements:
POP3 Command and Replies. Contains any command or reply message found in POP3 payload data.
Service Location Protocol (SLP) Deep Packet Inspection is based on RFC 2608. The following information elements are exported as a template in the subTemplateMultiList in the following order:
Contains the text elements found in an SLP Service Request.
SLP Version Number.
SLP Message Type. This value should be between 1 and 11 and describes the type of SLP message.
Trivial File Transfer Protocol (TFTP) Deep Packet Inspection is based on RFC 1350. The following information elements are exported as a template in the subTemplateMultiList in the following order:
TFTP Name of File being transferred.
Contains the mode of transfer. (Currently supported: netascii, octet, mail).
MySQL Deep Packet Inspection is based on information found at http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol. MySQL packet capture information is exported in the yaf subTemplateMultiList as a subTemplateList of Command Code, Command Text pairs.
An IPFIX SubTemplateList. This type represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. In this case, a list of MySQL Command Code, Command Text Pairs. There will be one element in the list for each MySQL Command found.
MySQL Command Text. For example, this can be a SELECT, INSERT, DELETE statement. This is the first element in the MySQL subTemplateList.
MySQL Command Code. This number should be between 0 and 28. This is the second element in the above MySQL subTemplateList.
MySQL Login User Name.
Distributed Network Protocol (DNP3) Deep Packet Inspection is slightly different than other plugin-based protocols. YAF will export the following information if the yafDPIRules.conf contain regular expressions with the label ID 20000. The regular expressions are compared against the payload of DNP3 packets starting with the function code in the DNP Application Layer header. YAF will loop through all the the available DNP3 packets contained in the captured payload. For each packet that matches one of the regular expressions listed in yafDPIRules.conf, YAF will include an entry in the exported subTemplateList. The subTemplateMultiList contains the following information elements in the following order:
An IPFIX SubTemplateList. This type represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. There will be one element in the list for each DNP3 packet that matches one of the DNP3 regular expressions found in the yafDPIRules.conf file.
The DNP3 Source Address found in the Data Link Layer of the DNP Header.
The DNP3 Destination Address found in the Data Link Layer of the DNP Header.
The DNP3 Function Code found in the first byte of the Application Layer.
The pattern captured from the DNP3 regular expression in yafDPIRules.conf
Modbus DPI is similar to DNP3 DPI. YAF will export any patterns matched by the regular expressions labeled with the ID 502 found in the yafDPIRules.conf file. The regular expressions are compared against the payload of all valid Modbus packets starting right after the MBAP header (offset 7), beginning with the Modbus function code. The information is exported as variable length fields in a single BasicList. All regular expressions for Modbus should use the label 502. No user-defined information elements will be accepted for Modbus.
Any patterns captured from the Modbus regular expressions in yafDPIRules.conf
Ethernet/IP DPI is similar to Modbus DPI. YAF will export any patterns matched by the regular expressions labeled with the ID 44818 in the yafDPIRules.conf file. The regular expressions are compared against the start of the payload of all valid Ethernet/IP packets (Command in the Encapsulation Header is the first byte). The matched patterns are exported as variable length fields in a single BasicList. All regular expressions for Ethernet/IP should use the label 44818. No user-defined information elements will be accepted for Ethernet/IP.
The pattern captured from the Ethernet/IP regular expressions in yafDPIRules.conf
YAF will export the Payload Type in the Real-time Transport Protocol (RTP) header if RTP DPI is enabled (yes by default). The Payload Type indicates the format of the payload and how it should be interpreted by the receiving application. The following two elements will be exported for each flow labeled as RTP. If the flow is a uniflow, the reverse element will be exported but will contain the value of 0.
The payload type in the RTP header of the first payload in the forward direction.
The payload type in the RTP header of the first payload in the reverse direction.
Emily Sarneso and the CERT Network Situational Awareness Group Engineering Team <netsa-help@cert.org>, http://www.cert.org/netsa
yaf(1), yafscii(1), applabel(1), super_mediator(1), PCRE Documentation