Ext Request SC uses wrong any service protocol 0 (HOPOPT)#4920
Ext Request SC uses wrong any service protocol 0 (HOPOPT)#4920tpurschke wants to merge 7 commits into
Conversation
tpurschke
changed the title
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 19955ad4ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| { | ||
| return FillNwObjGroupTemplate(template, svc.GroupName, mgtName ?? ""); | ||
| } | ||
| if (svc.ProtoId <= 0) // no protocol (e.g. rule service "Any"): must not be resolved as ip protocol 0 (HOPOPT) |
There was a problem hiding this comment.
When a request really contains IP protocol 0, this branch now serializes it as ANY instead of using the IP-protocol template. Protocol 0 is a seeded valid protocol (roles/database/files/csv/ip-protocol-list.csv:1 is HOPOPT), while WfReqTask.GetServiceElements() also maps a missing protocol to 0, so the conversion needs to distinguish null/missing from an explicit ip_proto_id = 0; otherwise an access or rule-delete ticket for a real HOPOPT service is broadened to all services.
Useful? React with 👍 / 👎.
|
1 participant
Diagnosis
The rule was not implemented with "Any" — but it also wasn't implemented with two separate service objects. FWO reports flatten service groups into their members (RuleDisplayBase.cs:257-279), so the tcp_1-65535 / udp_1-65535 you see in the report is consistent with the rule referencing a single service group containing those two services. That explains why the ticket had exactly one faulty service entry:
You can verify against the DB: the rule's rule_services should contain one group object whose svcgrp_flats are the two port-range services.
Fix
The rule was not implemented with "Any" — but it also wasn't implemented with two separate service objects. FWO reports flatten service groups into their members (RuleDisplayBase.cs:257-279), so the tcp_1-65535 / udp_1-65535 you see in the report is consistent with the rule referencing a single service group containing those two services. That explains why the ticket had exactly one faulty service entry:
GetElementsFromRule creates one element for the group with GroupName set and ProtoId = null (groups have no protocol).
GetServiceElements() coerces the null ProtoId to 0.
ConvertServiceElems ignored GroupName entirely (unlike the network-object conversion) and rendered protocol 0 through the IP-protocol template — and protocol 0 is HOPOPT in the IANA table. Hence {"@type": "PREDEFINED", "protocol": "OTHER", "predefined_name": "HOPOPT"}.
You can verify against the DB: the rule's rule_services should contain one group object whose svcgrp_flats are the two port-range services.
The fix (uncommitted, on feat/redhat-support)
SCAccessRequestTicketTask.cs — service conversion now handles two previously broken cases, with duplicates suppressed:
Element with GroupName → rendered as an object reference ({"@type": "Object", "object_name": "", "management_name": ""}), reusing the existing group template and the external management name, exactly like sources/destinations. This is the documented Tufin way to reference existing service objects.
Element without protocol (ProtoId <= 0) → rendered as {"@type": "ANY"} (covers rules using a genuine "Any" service).
SCConstants.cs — new constant SCAnyServiceJson for the fixed API construct.
SCTicketTest.cs — two new tests: a rule-delete task with protocol-less services produces a single ANY entry, and one with a service-group element produces the object reference with management name.
Related ticket
https://support.cactus.de/scp/tickets.php?id=129