Feature #8334
openfirewall: allow matching on packet layers
Description
The firewall mode should be able to distinguish between "Ethernet/IP/TCP" and "Ethernet/VLAN/GRE/Ethernet/IP/TCP". A packet should somehow expose this to the detection engine.
Perhaps a field that holds a list of protocol id's, starting at the datalink:
DLT_EN10MB:IPV4:TCP
Perhaps this would just be string buffer, where we can match using content.
VJ Updated by Victor Julien 6 months ago
- Related to Task #8435: firewall: investigate handling of encapsulation/tunneling like GRE/VXLAN added
LS Updated by Lukas Sismis 3 months ago
- Status changed from Triaged to Assigned
- Assignee changed from OISF Dev to Lukas Sismis
- Target version changed from TBD to 9.0.0-beta1
LS Updated by Lukas Sismis 13 days ago
Intermediary questions:
Is the goal here to match only on layers itself or do we also want to match on fields of individual layers?
Also, is the goal here to match on the specific layers using a single rule?
VJ Updated by Victor Julien 12 days ago
Just the layers in the order on the wire as in the description.
LS Updated by Lukas Sismis 9 days ago
Would it be ok to have the format such as:
accept:hook eth/vlan/tcp:all ...
accept:hook eth/vlan/tcp/tls:request_started ...
where the last element is what is currently used in the rules?
The second idea, potentially available to IDS/IPS mode too, could be through a keyword:
accept:hook tcp:all any any -> any any (msg:"Only fire on gre"; protolist:"eth/gre/tcp")
And instead of literal string pattern matching, I would suggest to either store an extra array of protocol IDs (as an array of uint8s) within the packet or walk from the root to the leaf packet and verify if it conforms the condition.
Manipulating with the literal string itself for every packet could easily trigger 1KB writes (255 layers x 4 bytes as an average protocol length) if somebody wanted to exploit this.
Rules could be potentially grouped by this as well + MPM matching seems to be possible even if the protocol IDs are stored as uint8 to a separate array. The array could be either per packet or once per thread detection context (seems more sensible).
I am more fan of the first idea.