elastic / elastic/integrations

[Juniper SRX] Parse login and sshd authentication events into ECS fields

Open
#17,462 1 comment 0 reactions 0 assignees View on GitHub
enhancement Integration:juniper_srx Team:Integration-Experience
Dominant language
Handlebars
Stars
333
Forks
647
Avg merge
3d 4h
Merged PRs (30d)
209

Description

### Integration Name

Juniper SRX [juniper_srx]

### Dataset Name

juniper_srx.log

### Integration Version

1.26.0

### Agent Version

8.19.10

### OS Version and Architecture

JunOS devices (SRX) sending syslog to agents on CentOS 8.

### User Goal

We want to build detection rules in Elastic Security that alert on privileged account logins (root, admin) across network devices using ECS fields like `user.name`, `event.category: authentication`, `event.outcome`, and `source.ip`.
The logs come from Juniper SRX firewalls and EX switches via syslog. Currently none of these authentication events are parsed into ECS fields, so they can't be used in threshold or ES|QL detection rules without a custom ingest pipeline workaround.

### Existing Features

The integration currently only parses SSHD_LOGIN_FAILED structured syslog messages into ECS authentication fields (added in #11946 / v1.21.3). Successful logins, console logins, and unstructured sshd messages are not parsed at all — they land in the generic message field with no ECS enrichment. This means we can only detect failed SSH logins via ECS fields, not successful ones, which is an important signal for security monitoring.

### What did you see?

Feb 19 14:56:28 dc1-core-sw-001 login[15758]: Login attempt for user root from host [unknown]
Feb 19 14:56:57 dc1-core-sw-001 login[15758]: LOGIN_INFORMATION: User root logged in from host [unknown] on device ttyu0
Feb 19 14:56:57 dc1-core-sw-001 login[15758]: LOGIN_ROOT: User root logged in as root from host [unknown] on device ttyu0
Feb 19 13:42:54 dc2-core-sw-002 sshd[43845]: Accepted publickey for jdoe from 10.0.1.50 port 18631 ssh2: RSA SHA256:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

### Anything else?

We have a working @custom pipeline as a workaround that demonstrates the grok patterns and ECS mappings needed, but we'd like a proper fix, not just another addition to the (already) big pipeline.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.