Bug #7651
openRegular PPPOE packets are getting dropped as decoder.ppp.unsup_proto
Description
After upgrading from suricata 7.0.6 to 7.0.8, we found that PPP packets were getting dropped.
The packets were getting marked as PPP_UNSUP_PROTO in DecodePPPOESession. If rules are configured as drop then the packets now get dropped.
I tracked down the change in behaviour to this commit https://github.com/OISF/suricata/commit/b23fa51e331141a2743ef7ded4ec01db951ec697 ("detect: fix decoder only events" for #7414 ).
I made a suricata-verify test using the pcap from https://www.cloudshark.org/captures/9ee1fd7ca29e with the ppp(oe) rules from suricata/rules/decoder-events.rules and all the PPPoES packets get alerted. I haven't made a pull request as I'm not sure about the licensing requirements for that file (it was first google result for pppoe pcap) - I can look into generating a pcap myself if needed. With the patch reverted, the packets do not get alerted.
I am guessing this is a result of ENGINE_SET_EVENT being called on the packet - but should that result in the packet being detected compared to ENGINE_SET_INVALID_EVENT?Perhaps DecodePPPOESession and DecodePPPUncompressedProto should not be setting the PPP_UNSUP_PROTO on various proto values including:
- PPP_IPCP
- PPP_IPV6CP
- PPP_LCP
- PPP_PAP
- PPP_CHAP
- PPP_CCP
The previously mentioned pcap also contains a proto that suricata doesn't know, 0x8207 CDPCP, that instead gets marked as PPP_WRONG_TYPE as it's not in the switch statement.
Updated by Thomas Winter 13 days ago
Locally I have made DecodePPPUncompressedProto and DecodePPPOESession just return TM_ECODE_OK for the following protocols IDs which should be expected in a PPP connection:
+ case PPP_IPCP:
+ case PPP_IPV6CP:
+ case PPP_LCP:
+ case PPP_PAP:
+ case PPP_CHAP:
+ case PPP_CCP:
+ case PPP_LQM:
+ case PPP_CBCP:
+ case PPP_COMP_DGRAM:
+ /* Valid types to be in PPP but don't inspect validity. */
+ return TM_ECODE_OK;
+