Suricata

Yes I can confirm the same ,was testing it a few weeks back, forgot to put in an issue.
Related to https://redmine.openinfosecfoundation.org/issues/5134 in terms of perf.

s-v test (needs updation): https://github.com/OISF/suricata-verify/pull/798

Some observations:

The alert dcerpc doesn't match because the app layer protocol of the traffic isn't dcerpc, its smb. However alert dcerpc locks the rule to the "pure" dcerpc.

{
  "raw": "alert dcerpc any any -> any any (msg:\"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request\"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:3; rev:1;)",
  "id": 3,
  "gid": 1,
  "rev": 1,
  "msg": "ET POLICY DCERPC  SVCCTL OpenSCManagerW Request",
  "app_proto": "dcerpc",
  "requirements": [
    "flow",
    "dcerpc" 
  ],
  "flags": [
    "src_any",
    "dst_any",
    "sp_any",
    "dp_any",
    "applayer",
    "toserver" 
  ],
  "pkt_engines": [
    {
      "name": "packet",
      "is_mpm": false
    }
  ],
  "frame_engines": [],
  "engines": [
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "dcerpc",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    }
  ],
  "lists": {
    "packet": {
      "matches": [
        {
          "name": "flow" 
        }
      ]
    }
  }
}

However if we don't specify the protocol, so use alert ip or alert tcp, it will do what you expect:

{
  "raw": "alert ip any any -> any any (msg:\"ET POLICY DCERPC  SVCCTL OpenSCManagerW Request\"; flow:established,to_server; dcerpc.iface:367abb81-9844-35f1-ad32-98f038001003; dcerpc.opnum:15; classtype:bad-unknown; sid:4; rev:1;)",
  "id": 4,
  "gid": 1,
  "rev": 1,
  "msg": "ET POLICY DCERPC  SVCCTL OpenSCManagerW Request",
  "requirements": [
    "flow",
    "dcerpc" 
  ],
  "flags": [
    "src_any",
    "dst_any",
    "sp_any",
    "dp_any",
    "toserver" 
  ],
  "pkt_engines": [
    {
      "name": "packet",
      "is_mpm": false
    }
  ],
  "frame_engines": [],
  "engines": [
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "dcerpc",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    },
    {
      "name": "dce_generic",
      "direction": "toserver",
      "is_mpm": false,
      "app_proto": "smb",
      "progress": 0,
      "matches": [
        {
          "name": "dcerpc.iface" 
        },
        {
          "name": "dcerpc.opnum" 
        }
      ]
    }
  ],
  "lists": {
    "packet": {
      "matches": [
        {
          "name": "flow" 
        }
      ]
    }
  }
}

This is because the keywords internally can handle both "pure" dcerpc and smb with dcerpc running over it, so the rule is setup to handle both.

So I guess the question is if the dcerpc app protocol specification in the rule should be overloaded to mean "either exact dcerpc or dcerpc over smb".

So I guess the question is if the dcerpc app protocol specification in the rule should be overloaded to mean "either exact dcerpc or dcerpc over smb".

I'm personally in favor of the rule being "overloaded". It makes sense from a rule writers perspective.