Packetless Application layer interface

[cvontela_microsoft (chaitravontela)]

Hi Developers,

I am evaluating Suricata to provide IDPS for traffic from L3-L7 and I see the drawback is it only accepts packet level input. In our scenario where TLS termination happens later after L3/4 inspection and proxy receives already reassembled data, the original IP/TCP packet level info is no longer available.

Does Suricata or libsuricata currently provide or plan to provide an interface where an application can submit byte streams or transactions for L7 IDPS inspection? We would like Suricata to perform its normal application protocol detection, L7 parsing, transaction tracking and signature evaluation without requiring raw IP packets or Suricata’s TCP reassembly path.

Thank you in advance for your time and guidance!

[cvontela_microsoft (chaitravontela)]

Tagging @vjulien for help and guidance.

[ish (Jason Ish)]

Currently, the approach used by some users is to reconstruct packets. See this discussion, which links to an open-source implementation that does this, I think: Update on ICAP integration proposal: Working implementation of SSLproxy (icap branch) & icapsuricata (libsuricata service) - #3 by Soner_Tari.

This has come up a few times in the past, so I was surprised we didn’t have a specific feature request for it. I created one here: Feature #9150: libsuricata: support stream input without synthetic packets - Suricata - Open Information Security Foundation

Note that this isn’t on the near-term roadmap.

[cvontela_microsoft (chaitravontela)]

thank you @ish, this is very helpful. IIUC, there is currently no supported byte-stream/transaction-oriented input API; the available workaround is to reconstruct synthetic IP/TCP packets around the application byte streams and inject those through libsuricata. Thanks for creating feature request in queue. I think another way could also be introducing a plain text hop to after the decrypted byte streams are available to make the packet level input available to Kernel and use NFQUEUE integration into Suricata process running in a container?

I see the above shared icapsuricata implementation as only an experimental proof of concept rather than a production ready integration pattern?

[ish (Jason Ish)]

@cvontela_microsoft

thank you @ish, this is very helpful. IIUC, there is currently no supported byte-stream/transaction-oriented input API; the available workaround is to reconstruct synthetic IP/TCP packets around the application byte streams and inject those through libsuricata. Thanks for creating feature request in queue. I think another way could also be introducing a plain text hop to after the decrypted byte streams are available to make the packet level input available to Kernel and use NFQUEUE integration into Suricata process running in a container?

Unfortunately, I don’t know enough about NFQUEUE to comment.

@cvontela_microsoft

I see the above shared icapsuricata implementation as only an experimental proof of concept rather than a production ready integration pattern?

Yes, I believe that project is just experimental. We’ve heard of others using this pattern in production; however, they are not open source, so I can’t point to them. We’ll always support the packet pattern as a first-class pattern, so I wouldn’t exactly call it not production-ready.