[Oisf-devel] Suricata and Open vSwitch integration

Ansis ansisatteka at gmail.com
Mon Sep 30 04:00:39 UTC 2019


Hi,

I am one of the Open vSwitch developers who are investigating how
Suricata could be integrated with Open vSwitch project. Open vSwitch
is a multi platform software switch that is used in, but not limited
to, network virtualization. I am mostly interested in IDS at this
stage.

I looked into various packet acquisition interfaces that Suricata
already supports. However, none of them seem to be able to achieve
what we want, because:
1. Open vSwitch is programmed through Open Flow rules and we would
like to retain ability to selectively steer some of the traffic for L7
inspection to Suricata by using them. While letting some other traffic
running on well know ports to bypass suricata. This eliminates NFQueue
and alike acquisition interfaces because they happen outside OpenFlow
packet pipeline stage.
2. Open vSwitch should be capable to deal with overlapping IP address
spaces where the same Open vSwitch+Suricata instance should be able to
differentiate traffic between two VMs that possibly could have exactly
the same IP addresses.
3. Performance considerations.


Having said that I am considering following designs:
1. link Suricata against libopenvswitch so that Suricata could act as
OpenFlow controller to which Open vSwitch process could connect. This
would solve #1 consideration. However, talking over Unix domain
sockets is expensive so #3 will probably fail.
2. decouple Suricata IDS logic into a shared library and let Open
vSwitch load it with dlopen(). This would solve #1 and #3 (as packet
inspection would happen in Open vSwitch process space and would avoid
copying packet and do a context switch). Currently Open vSwitch does
not allow to load *.so plugins, but there is a patch in progress
[https://patchwork.ozlabs.org/patch/1063736/] that I sent out and will
set the precedent how the v1 API for such plugins would have to look
like.

Depending on design we take now, it may enforce constraints on one or
both projects to implement certain APIs that we both projects would
have to agree upon.

Any other suggestions in case I am missing something?

Best regards,
Ansis Atteka


More information about the Oisf-devel mailing list