How to use IDMEF¶

Introduction¶

This tutorial won't be considering the implementation of IDMEF, but rather the content of the format and what it means to use it.
Thus it can be viewed both as an indication on how to use the current implementation libprelude, which is described in the How to use LibPrelude section, and as a help on how to implement IDMEF format yourself.

IDMEF was originally written to be encoded in XML. That's why it is relatively easy to generate a class diagram out of the RFC. That has been done, naturally, you can find the complete diagram here, and will be used to illustrate this tutorial. However this diagram and the commented extracts are not official and can contain mistakes. If confronted with any doubt, please refer to the RFC.

IDMEF is a message format, as it's stated in its name. Thus, it allows to send both alerts and heartbeats. We will focus on the alerts in this tutorial.

I - IDMEF Global Information¶

IMDEF fields can be split into two categories :
- global information : information that should be available for every message, despite the context.
- specific information, that depends on the context.

We will first focus on the first category.

1) Mandatory fields¶

These fields are the most important. You can just skip the whole message if they are not filled.
Besides, these fields may or may not be considered mandatory in the RFC.
We chose each of these for a reason that will be described. Of course, as said earlier, this tutorial should only be considered as an advice on how to use IDMEF, and thus, you can decide that more fields are to be always filled or that one of them is not as important as it is seems.

Message class : version
The version of the IDMEF message

Alert class : messageid
It's an unique identifiant for the alert. It's the only attribute of the class Alert

Classification class : text
This field is the one that allows human operator to understand what a particular alerts stands for. It is a simple text description of the event that triggered the alert.
This field is required according to the RFC.

Analyzer class : name, model, version
The analyzer class is meant to describe the analyzer or probe that sent the message/alert. Except when using only one analyzer, which is very unlikely, being able to distinguish which analyzer sent the alert is essential.
These fields are not required in the RFC.

CreateTime class : ntpstamp
This field contains the date at which the message/alert was created. It is also necessary in order to correlate and order alerts.

2) Others¶

Some fields are not listed as mandatory because they can't be filled in very specific cases. They can, however, be necessary when available.

Target class : node.address.address
The target class is essential when dealing whith a wide network. It is usually best described with an IP address.

Assessment class : impact.completion
The completion field is extremely useful. It cannot be used in any case, but has to be filled whenever possible.

These where the global fields.

II - Specific fields¶

Some fields are more specific of a type of message. We won't list them all for you can find them both in the RFC and on the diagram. But we'll see a few examples of specific alerts and how to use these fields. These examples are all inspired of examples from the RFC for the only implementation of IDMEF, LibPrelude, does not totally comply with it.

1) Connection to a Disallowed Service¶

• messageid="abc123456789"
• Analyzer
  • analyzerid = "bc-sensor01"
  • name = "Sensor1"
  • manufacturer = "SensorManufacturer"
  • model = "Sensor01b"
  • version = "1.6.6"
• CreateTime
  • ntptamp = 2000-03-09T18:47:25+02:00
• Source
  • ident="a123"
  • Node
    • ident="a123-01"
    • category = "dns"
    • name = "sensor.example.com"
    • Address
      • ident="a123-02"
      • category = "ipv4-addr"
      • address =192.0.2.200
  • User
    • ident="q987-03"
    • category = "os-device"
    • Userid
      • ident="q987-04"
      • type = "target-user"
      • name = "badguy"
  • Service
    • ident="a123-03"
    • port = 31532
• Target
  • ident="z456"
  • Node
    • ident="z456-01"
    • category = "nis"
    • name = myhost
    • Address
      • ident="z456-02"
      • category = "ipv4-addr"
      • address = 192.0.2.50
  • Service
    • ident="z456-03"
    • name = finger
    • port = 79
• Classification
  • text = "Portscan"
  • Reference
    • origin = "vendor-specific"
    • meaning = "general documentation"
    • name = Distributed attack
    • url = http://www.vendor.com/distributed

2) File Modification¶

• messageid="abc123456789"
• Analyzer
  • analyzerid = "bids-192.0.2.1"
  • ostype = "Linux"
  • osversion = "2.2.16-3"
  • Node
    • category = "hosts"
    • name = etude
    • Address
      • category = "ipv4-addr"
      • address = 192.0.2.1
• CreateTime
  • CreateTime ntpstamp=2000-03-09T08:12:32-01:00
• Source
  • spoofed = "no"
  • Node
    • location = console
    • Address
      • category = "ipv4-addr"
      • address = 192.0.2.1
• Target
  • decoy = "no"
  • Node
    • location = local
    • Address
      • category = "ipv4-addr"
      • address = 192.0.2.1
  • User
    • UserId
      • type = "current-user"
      • name = Fred
      • number = 456
  • File
    • category = "current"
    • fstype = "tmpfs"
    • name = xxx000238483
    • path = /tmp/xxx000238483
    • FileAccess
      • UserId
        • type = "user-privs"
        • name = Alice
        • number = 777
      • permission = "read"
      • permission = "write"
      • permission = "delete"
      • permission = "changePermission"
    • FileAccess
      • UserId
        • type = "group-privs"
        • name = user
        • number = 42
      • permission = "read"
      • permission = "write"
      • permission = "delete"
    • Linkage
      • category = "symbolic_link"
      • name = passwd
      • path = /etc/passwd
• Classification
  • text = "DOM race condition"
  • Reference
    • origin = "vendor-specific"
    • name = DOM race condition
    • url = file://attack-info/race.html

3) Port scan correlated alert¶

• messageid="abc123456789"
• Analyzer
  • analyzerid = "bc-corr-01"
  • Node
    • category = "dns"
    • name = correlator01.example.com*
• CreateTime
  • CreateTime ntpstamp=2000-03-09T08:12:32-01:00
• Source
  • ident="a1"
  • Node
    • ident="a1-1"
    • Address
      • ident="a1-2"
      • category = "ipv4-addr"
      • address = 192.0.2.200
• Target
  • ident="a2"
  • Node
    • ident="a2-1"
    • category = "dns"
    • name = "www.example.com"
    • Address
      • ident="a2-2"
      • category = "ipv4-addr"
      • address = 192.0.2.50
  • Service
    • ident = "a2-3"
    • portlisr = 5-25,37,42,43,53,69-119,123-514
• Classification
  • text = "Portscan"
  • reference
    • origin = "vendor-specific"
    • name = "Portscan"
    • url = http://www.vendor.com/portscan
• CorrelationAlert
  • name = multiple ports in short time
  • alertident = 123456781
  • alertident = 123456782
  • alertident = 123456783
  • alertident = 123456784
  • alertident = 123456785
  • alertident = 123456786
  • alertident
    • analyzerid = a1b2c3d4
    • 987654321
  • alertident
    • analyzerid = a1b2c3d4
    • 987654322

4) Analyzer assessment¶

• messageid="abc123456789"
• Analyzer
  • analyzerid = "bids-192.0.2.1"
• CreateTime
  • CreateTime ntpstamp=2000-03-09T08:12:32-01:00
• Source
  • spoofed="no"
  • Node
    • location="console"
    • Address
      • category="ipv4-addr"
      • address="192.0.2.1"
• Target
  • decoy="no"
  • Node
    • location="local"
    • Address
      • category="ipv4-addr"
      • address="192.0.2.1"
    • User
      • category="os-device"
      • UserID
        • type="original-user"
        • number=456
      • UserID
        • type="current-user"
        • name=root
        • number=0
      • UserID
        • type="user-privs"
        • number=0
    • Process
      • name=eject
      • pid=32451
      • path=/user/bin/eject
      • arg=\x90\x80\x3f\xff...\x08/bin/sh
• Classification
  • text="Unauthorized administrative access"
  • Reference
    • origin="vendor-specific"
    • name="Unauthorized administrative access"
    • url="file://attack-info/u2s.html"
  • Assessment
    • Impact
      • severity="high"
      • completion="succeeded"
      • type="admin"
    • Action
      • category="block-installed"
      • disabled user (fred)
    • Action
      • category="taken-offline"
      • logout user (fred)
    • Confidence
      • rating="high"