search

oxidecomputer / opte

packets go in, packets go out, you can't explain that
Mozilla Public License 2.0
37 stars 9 forks source link

Want anti-spoof enforcement #42

Closed rzezeski closed 2 years ago

rzezeski commented 2 years ago

Add anti-spoof protection to OPTE to make sure a guest can only send out frames/packets that match its prescribed MAC address + IP address for the given interface.

Along with this there should be a dedicated spoof stat(s). Also might want a dedicated SDT probe for this case as well.

rzezeski commented 2 years ago

This anti-spoof enforcement was addressed in 717aaf1283a84fe5797fb733a6448fac04dfe3a3. However, before marking this done we should

rzezeski commented 2 years ago

It turns out that having layer-specific stats like a "spoof stat" is harder than I thought.

First, I see no easy way to attach a new kstats structure to each layer. If we make it a generic on Layer, then that breaks the Vec<Layer> in Port. If we change the layers list to be Vec<dyn Layer>, then that means each layer impl could propose its own process method, which is not at all how opte was designed to work (the processing is generic, the customization comes in the form of rules and their associated actions). We could probably do something with raw pointers and casting, but that feels wrong. I just don't see the easy/right way to do this.

Second, the more I think about it the more I'm not sure such stats need to exist anyways. To implement a "spoof stat", the gateway layer impl somehow needs to know when no rule matched and hook into that. Then it needs to inspect the packet/flow to know if it didn't match any rules because it is spoofed or for some other reason. This seems a bit odd of a way to go about things, and perhaps a bit heavyweight in terms of code and runtime efficiency.

Instead, I think #207 gets us most of the benefit without having to do a bunch of remodeling. It tells us which rules are matching, and when no rules are matching at all (assuming we also add "default rule match" stats). With those stats in place, we can then use the more generic flow/packet-based probes to delve into the traffic to determine why it isn't matching. We wouldn't have historical counts of "this guest tried to spoof a packet X times", but I think that's a fine tradeoff for now given the complexity vibes I'm getting from trying to implement these stats.

With that said I'm going to pass on making specific "spoof stats" and a "spoof probe". I still want a test, but I'll make that a new issue to stand on its own.

rzezeski commented 2 years ago

See #298.