Project

General

Profile

Actions

Bug #7406

open

eve: Alerts with app_proto=tls no longer logs the tls app data

Added by tug tugtug 1 day ago. Updated about 20 hours ago.

Status:
New
Priority:
High
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
C

Description

Prior to change of fixes to ticket #6846, the application data is reported in almost every alerts, now the application data is barely included in the alert events.

Upon reviewing the recent updates, I've identified two significant changes that compromise the consistency and accuracy of application data reporting:
1. Inconsistent reporting for multiple alerts that belong to a single packet.
With PACKET_ALERT_FLAG_TX, a UDP DNS packet will no longer include the DNS section in the connection alert, while the DNS alert will. Although this change may seem logical, it constitutes a breaking change in a minor version update.

2. Missing reporting of application data in TLS Alerts
The application data for TLS (and potentially other protocols) is no longer reported in the TLS alert. As one can see from the below code, the sslsession is the alstate set to the flow, but it would never translates to PACKET_ALERT_FLAG_TX.

        uint64_t txid = PACKET_ALERT_NOTX;
        if ((alert_flags & PACKET_ALERT_FLAG_STREAM_MATCH) ||
                (s->alproto != ALPROTO_UNKNOWN && pflow->proto == IPPROTO_UDP)) {
            // if there is a stream match (TCP), or
            // a UDP specific app-layer signature,
            // try to use the last tx
            if (pflow->alstate) {
                txid = AppLayerParserGetTxCnt(pflow, pflow->alstate) - 1;
                alert_flags |= PACKET_ALERT_FLAG_TX;
            }
        }

Related issues 1 (1 open0 closed)

Related to Suricata - Bug #7199: Suricata 7 no longer logging app-layer metadata in alertsNewOISF DevActions
Actions

Also available in: Atom PDF