OpenLDAP

Overview

OpenLDAP (Lightweight Directory Access Protocol) is an open-source implementation of a directory service protocol. It helps organizations to maintain and manage a centralized directory of user information, such as names, addresses, and other attributes.

• Vendor: OpenLDAP Foundation
• Supported environment: On prem
• Version compatibility: 2.6
• Detection based on: Telemetry
• Supported application or feature: Web logs

Configure

As of now, the main solution to collect OpenLDAP logs leverages the Rsyslog recipe. Please share your experiences with other recipes by editing this documentation.

Collect the logs

Below is a couple of suggestions you can follow to configure your system to collect openLDAP logs with rsyslog:

1. Local slapd.conf or slapd.d/cn=config.ldif and modify loglvl setting there. For example:

   loglevel 256
   

2. Modify your rsyslog.conf or /etc/rsyslog.d/*.conf to specify log destination. For example:

   local4.* /var/log/openldap.log
   

3. Restart rsyslog services. For example:

   sudo systemctl restart slapd
   sudo systemctl restart rsyslog
   

4. Check that logs are being written to the destination file. For example:

   tail -f /var/log/openldap.log
   

Forward logs to SEKOIA.IO

Please consult the Rsyslog Transport documentation to forward these logs to Sekoia.io.

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

Related Built-in Rules

The following Sekoia.io built-in rules match the intake OpenLDAP. This documentation is updated automatically and is based solely on the fields used by the intake which are checked against our rules. This means that some rules will be listed but might not be relevant with the intake.

SEKOIA.IO x OpenLDAP on ATT&CK Navigator

Cryptomining

Detection of domain names potentially related to cryptomining activities.

• Effort: master

Dynamic DNS Contacted

Detect communication with dynamic dns domain. This kind of domain is often used by attackers. This rule can trigger false positive in non-controlled environment because dynamic dns is not always malicious.

• Effort: master

Exfiltration Domain

Detects traffic toward a domain flagged as a possible exfiltration vector.

• Effort: master

Remote Access Tool Domain

Detects traffic toward a domain flagged as a Remote Administration Tool (RAT).

• Effort: master

SEKOIA.IO Intelligence Feed

Detect threats based on indicators of compromise (IOCs) collected by SEKOIA's Threat and Detection Research team.

• Effort: elementary

Sekoia.io EICAR Detection

Detects observables in Sekoia.io CTI tagged as EICAR, which are fake samples meant to test detection.

• Effort: master

TOR Usage Generic Rule

Detects TOR usage globally, whether the IP is a destination or source. TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

• Effort: master

Event Categories

The following table lists the data source offered by this integration.

Data Source	Description
Web logs	OpenLDAP provide information like the connected client, the requested resource, the user agent or the response status.

In details, the following table denotes the type of events produced by this integration.

Name	Values
Kind	``
Category	authentication, configuration, network
Type	change, connection, end, info, start

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

test_accept.jsontest_bind_1.jsontest_bind_2.jsontest_miscellaneous_1.jsontest_miscellaneous_2.jsontest_miscellaneous_3.jsontest_miscellaneous_4.jsontest_miscellaneous_5.jsontest_miscellaneous_6.jsontest_mod_1.jsontest_mod_2.jsontest_search_1.jsontest_search_2.jsontest_search_3.jsontest_search_4.jsontest_search_5.json

{
    "message": "conn=11 fd=31 ACCEPT from IP=1.2.3.4:45181 (IP=5.6.7.8:389)",
    "event": {
        "action": "accept",
        "category": [
            "network"
        ],
        "type": [
            "connection",
            "info"
        ]
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 389
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 45181
    }
}

{
    "message": "conn=11 op=1 BIND dn=\"uid=user1,ou=people,dc=example,dc=com\" method=128",
    "event": {
        "action": "bind",
        "category": [
            "authentication"
        ],
        "type": [
            "start"
        ]
    },
    "related": {
        "user": [
            "user1"
        ]
    },
    "user": {
        "domain": "people.example.com",
        "name": "user1"
    }
}

{
    "message": "conn=11 op=1 BIND dn=\"uid=user1,ou=People,dc=example,dc=com\" mech=SIMPLE ssf=0",
    "event": {
        "action": "bind",
        "category": [
            "authentication"
        ],
        "type": [
            "start"
        ]
    },
    "related": {
        "user": [
            "user1"
        ]
    },
    "user": {
        "domain": "People.example.com",
        "name": "user1"
    }
}

{
    "message": "conn=11 op=0 STARTTLS",
    "event": {
        "action": "starttls",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    }
}

{
    "message": "conn=11 op=0 RESULT oid= err=0 text=",
    "event": {
        "action": "result",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    }
}

{
    "message": "conn=11 fd=31 TLS established tls_ssf=256 ssf=256",
    "event": {
        "action": "tls",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    }
}

{
    "message": "conn=11 op=1 RESULT tag=97 err=0 text=",
    "event": {
        "action": "result",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    }
}

{
    "message": "conn=11 op=3 UNBIND",
    "event": {
        "action": "unbind",
        "category": [
            "authentication"
        ],
        "type": [
            "end"
        ]
    }
}

{
    "message": "conn=11 fd=31 closed",
    "event": {
        "action": "closed",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    }
}

{
    "message": "conn=11 op=2 MOD dn=\"uid=user1,ou=People,dc=example,dc=com\"",
    "event": {
        "action": "mod",
        "category": [
            "configuration"
        ],
        "type": [
            "change"
        ]
    },
    "related": {
        "user": [
            "user1"
        ]
    },
    "user": {
        "domain": "People.example.com",
        "name": "user1"
    }
}

{
    "message": "conn=11 op=2 MOD attr=mail",
    "event": {
        "action": "mod",
        "category": [
            "configuration"
        ],
        "type": [
            "change"
        ]
    },
    "openldap": {
        "attribute": "mail"
    }
}

{
    "message": "\" conn=6521 op=3 SRCH base=\"\"ou=people,ou=IN,o=example\"\" scope=2 deref=0 filter=\"\"(&(exampleRole=example_admin)(uid=mhs))\"\"\"",
    "event": {
        "action": "srch",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "user": {
        "domain": "people.IN.example"
    }
}

{
    "message": "conn=6521 op=3 SRCH attr=uid cn",
    "event": {
        "action": "srch",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "openldap": {
        "attribute": "uid cn"
    }
}

{
    "message": " conn=6521 op=2 SRCH attr=examplerole",
    "event": {
        "action": "srch",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "openldap": {
        "attribute": "examplerole"
    }
}

{
    "message": "\" conn=6521 op=2 SRCH base=\"\"o=example\"\" scope=2 deref=0 filter=\"\"(uid=mhs)\"\"\"",
    "event": {
        "action": "srch",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "user": {
        "domain": "example"
    }
}

{
    "message": " conn=6521 op=1 SRCH attr=mail telephonenumber cn uid l givenname sn title department",
    "event": {
        "action": "srch",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "openldap": {
        "attribute": "mail telephonenumber cn uid l givenname sn title department"
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name	Type	Description
destination.ip	ip	IP address of the destination.
destination.port	long	Port of the destination.
event.action	keyword	The action captured by the event.
event.category	keyword	Event category. The second categorization field in the hierarchy.
event.type	keyword	Event type. The third categorization field in the hierarchy.
openldap.attribute	keyword	OpenLDAP attribute
source.ip	ip	IP address of the source.
source.port	long	Port of the source.
user.domain	keyword	Name of the directory the user is a member of.
user.name	keyword	Short name or login of the user.

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.

Further Readings

• OpenLDAP Official Website
• OpenLDAP Quickstart Guide