Hi SigmaHQ maintainers,
I wanted to ask whether this detection idea would be suitable for SigmaHQ before opening a pull request.
Detection idea
Detect OpenSSH sshd DEBUG log messages that show SSH TCP forwarding channel activity, including:
server_request_direct_tcpipctype direct-tcpipnew direct-tcpipserver_input_global_request: rtype tcpip-forwardtcpip-forward listennew forwarded-tcpip
This maps to SSH tunnelling / proxying behaviour and may be useful for monitored bastions, jump hosts, deception systems, high-risk SSH servers, or controlled monitoring labs.
Important caveat
The useful OpenSSH forwarding channel messages appear to require:
LogLevel VERBOSE showed authentication/disconnect events, but did not expose the useful forwarding channel details in my testing.
Candidate logsource
logsource:
product: linux
service: sshd
Candidate detection logic
detection:
keywords_direct_tcpip:
- 'server_request_direct_tcpip'
- 'ctype direct-tcpip'
- 'new direct-tcpip'
keywords_remote_forward:
- 'server_input_global_request: rtype tcpip-forward'
- 'tcpip-forward listen'
- 'new forwarded-tcpip'
condition: 1 of keywords_*Validation done
I tested this against sanitized positive OpenSSH DEBUG log samples for local, dynamic, and remote SSH forwarding.
Positive samples matched.
Normal SSH authentication/disconnect samples did not match.
sigma check returned:
0 errors, 0 condition errors, 0 issues
Duplicate check
I found related SigmaHQ coverage for Windows SSH/Plink/Netsh port forwarding and Linux SSH ProxyCommand process creation, but I did not find an existing Linux/OpenSSH sshd DEBUG-log rule for these forwarding channel strings.
Question
Would SigmaHQ consider a Linux/OpenSSH sshd rule acceptable if it clearly documents the LogLevel DEBUG requirement and likely false positives from legitimate admin SSH forwarding?
If yes, I can open a PR with the candidate rule.
Hi SigmaHQ maintainers,
I wanted to ask whether this detection idea would be suitable for SigmaHQ before opening a pull request.
Detection idea
Detect OpenSSH
sshdDEBUG log messages that show SSH TCP forwarding channel activity, including:server_request_direct_tcpipctype direct-tcpipnew direct-tcpipserver_input_global_request: rtype tcpip-forwardtcpip-forward listennew forwarded-tcpipThis maps to SSH tunnelling / proxying behaviour and may be useful for monitored bastions, jump hosts, deception systems, high-risk SSH servers, or controlled monitoring labs.
Important caveat
The useful OpenSSH forwarding channel messages appear to require:
LogLevel VERBOSEshowed authentication/disconnect events, but did not expose the useful forwarding channel details in my testing.Candidate logsource
Candidate detection logic
Validation done
I tested this against sanitized positive OpenSSH DEBUG log samples for local, dynamic, and remote SSH forwarding.
Positive samples matched.
Normal SSH authentication/disconnect samples did not match.
sigma checkreturned:Duplicate check
I found related SigmaHQ coverage for Windows SSH/Plink/Netsh port forwarding and Linux SSH
ProxyCommandprocess creation, but I did not find an existing Linux/OpenSSHsshdDEBUG-log rule for these forwarding channel strings.Question
Would SigmaHQ consider a Linux/OpenSSH
sshdrule acceptable if it clearly documents theLogLevel DEBUGrequirement and likely false positives from legitimate admin SSH forwarding?If yes, I can open a PR with the candidate rule.