**Environment** - Cloudera CFM 2.1.7 / Apache NiFi 1.26.0 - Cloudera CDP 7.3.1 - Flow source: Cisco ASA Firewall (IPFIX export)   **Issue**   The `ListenNetFlow` processor successfully decodes standard IPFIX/NetFlow v9 fields but produces a WARN for every packet that contains Cisco ASA enterprise fields:   ``` WARN com.cloudera.nifi.netflow.ListenNetFlow: Sender [/x.x.x.x] Field Type [33002] Length [2] Field Decoder not found WARN com.cloudera.nifi.netflow.ListenNetFlow: Sender [/x.x.x.x] Field Type [33001] Length [12] Field Decoder not found WARN com.cloudera.nifi.netflow.ListenNetFlow: Sender [/x.x.x.x] Field Type [33000] Length [12] Field Decoder not found WARN com.cloudera.nifi.netflow.ListenNetFlow: Sender [/x.x.x.x] Field Type [40000] Length [12] Field Decoder not found   ```   At production NetFlow volume, this generates thousands of WARN lines per second, making `nifi-app.log` effectively unusable for monitoring other issues.   More critically, the data in these fields is silently dropped:   | Field ID | Cisco Name | Description | |---|---|---| | 33000 | INGRESS_ACL_ID | ACL that matched the flow on ingress | | 33001 | EGRESS_ACL_ID | ACL that matched the flow on egress | | 33002 | FW_EVENT | Firewall event type (allow / deny / teardown) |   These are Cisco Private Enterprise Number (PEN 9) fields. They are documented in Cisco's IPFIX implementation guide and are present in every flow exported by Cisco ASA firewalls. For security operations use cases, `FW_EVENT` (33002) in particular is essential — it identifies whether a connection was permitted or denied.   **Expected behavior**   `ListenNetFlow` should support registering enterprise IPFIX field decoders via configuration (PEN + field ID mapping), so operators can define custom fields without modifying processor source code. As a baseline, well-known Cisco PEN 9 fields (33000, 33001, 33002) should be included in the default field registry. Unknown enterprise fields should be logged at DEBUG, not WARN, since encountering undefined vendor fields is expected behavior in production IPFIX environments.   **Impact**   - Log files roll too fast to monitor other issues - ACL and firewall event data is lost from every flow record - Security teams lose visibility into deny/allow decisions at the firewall level     Happy to provide packet captures or field mapping documentation if useful. ... View more

Hello eveyone   we’re experiencing with consuming Kafka from a third-party (Qradar) system outside of CDP. In their configuration, the only SASL mechanisms available for configuration are: PLAIN SCRAM-SHA-256 SCRAM-SHA-512 However, all of these mechanisms are resulting in authentication errors. how we can connect Qradar to kafa to be able to consume the data from kafka  Thanks in advance    ... View more

Hello, I need your guidance on the following scenario: We have a SIEM (QRadar) infrastructure where Event Collectors receive logs from various data sources. These logs are correlated based on SIEM rules and use cases. we plan to send logs to the SIEM while also storing a copy in a Data Lake. Current Approach: We have structured the workflow as follows: DATA SOURCES → NiFi → Store in DATA LAKE & Forward to SIEM (using PUTTCP processor) Questions: Does NiFi allow segregation of data sources? Handling LEEF logs: logs reach NiFi with the original source IP but leave NiFi with NiFi’s source IP. Since QRadar first looks for the hostname in the payload (and if absent, uses the source IP), this could cause misidentification. Can NiFi be configured to retain the original source IP while forwarding logs, without modifying the original log (to comply with legal requirements)? Log Integrity & Authenticity: Does NiFi ensure log integrity and authenticity for legal and compliance purposes? LEEF Parsing: Is there a NiFi processor available to parse LEEF logs before storing them in HDFS? thanks in advance   ... View more