Add OpenSSH TCP forwarding channel activity detection

[marvalous123]

Summary

This draft PR adds a Linux/OpenSSH sshd rule for SSH TCP forwarding channel activity visible in OpenSSH DEBUG logs.

The rule looks for debug log strings related to local/dynamic forwarding via direct-tcpip and remote forwarding via tcpip-forward / forwarded-tcpip channels.

Linked rule idea issue: #6117

Important review question

The main review question is whether SigmaHQ wants coverage that depends on OpenSSH LogLevel DEBUG.

In my testing:

• LogLevel VERBOSE showed authentication/disconnect activity, but not useful forwarding channel details.
• LogLevel DEBUG exposed the forwarding channel strings used by this rule.

This may be most useful for monitored bastions, jump hosts, deception systems, high-risk SSH servers, or controlled monitoring labs where DEBUG logging is intentionally enabled.

Detection strings

Examples covered by the rule:

server_request_direct_tcpip
ctype direct-tcpip
new direct-tcpip
server_input_global_request: rtype tcpip-forward
tcpip-forward listen
new forwarded-tcpip

Validation

Local validation completed:

sigma check --fail-on-error --fail-on-issues rules/linux/builtin/sshd/lnx_sshd_openssh_tcp_forwarding_debug.yml

Result:

0 errors, 0 condition errors, 0 issues

Repository tests also passed locally:

python tests/test_logsource.py
python tests/test_rules.py

Note: running sigma check with tests/sigma_cli_conf.yml failed locally before rule validation because my installed Sigma CLI validator set did not include sigmahq_fieldname_cast, which the repo config attempts to remove. Plain Sigma validation and the repo Python checks passed.

False positives

Expected false positives include legitimate administrator use of SSH local, dynamic SOCKS, or remote forwarding, especially on bastion/jump hosts and developer workflows.

[github-actions]

Welcome @marvalous123 👋

It looks like this is your first pull request on the Sigma rules repository!

Please read the SigmaHQ conventions to ensure your contribution adheres to best practices and includes all the necessary elements for a successful review.

Also check CONTRIBUTING.md for more information on how to contribute to the Sigma rules repository, specifically proper testing and validation of your rules.

Thanks again, and welcome to the Sigma community! 😃

If you want to engage more with the community for official support, general discussions or announcements:

👉 Join our Discord server

[marvalous123]

Hi maintainers, just checking whether this rule is in the right direction for SigmaHQ.

The main review question is whether the LogLevel DEBUG requirement makes this too niche for an upstream rule. Happy to adjust the wording, scope, level, or close it if this is better kept as a local/lab detection.

[nasbench]

Hi maintainers, just checking whether this rule is in the right direction for SigmaHQ.

The main review question is whether the LogLevel DEBUG requirement makes this too niche for an upstream rule. Happy to adjust the wording, scope, level, or close it if this is better kept as a local/lab detection.

This might be useful to some, but DEBUG is practically never enabled so I think the use for this will be very limited. Usually systems might allow specific messages ID from debug but to my knowledge SSH doesn't (but I could be wrong).

We don't currently have a dedicated category we can put this. Hence I will mark this as not possible for now. And revisit it at a later date.

If you think has value or argue for keeping it feel free to comment and we can reevaluate the decision.

Thanks for the contribution.

[marvalous123]

Thanks for reviewing it — that makes sense.

I agree the LogLevel DEBUG requirement limits how broadly useful this is in normal production environments. I’ll keep it as a local/lab detection for now, and if I find a more widely logged OpenSSH event source or a better category for this behaviour, I’ll revisit it.

Thanks again for taking the time to look at it.