Solution to Integrate with IPS/IDS

Ziti Overlay
1

While using OpenZiti Overlay Network for Enterprise, Is there a way to integrate with IPS/IDS?

Architecture:

Client → Ziti Edge Tunneler → Ziti Overlay Network → Ziti Edge Tunneler → Service
Application traffics are TLS encrypted while traversal the Ziti Overlay Network, is it possible to capture the original unencrypted traffics and send to the IDS/IPS for inspections?

  • Can it be done at Ziti Router?
  • Can it be done at Tunneler?

What is the suggestion for this use case?

2

Others may have better responses, but I will take a punt.

Yes, there are many ways in which you can integrate with IPS/IDS, the best pattern depends on your environment, requirements, and various tradeoffs your prefer. I would generally avoid trying to inspect “inside” the encrypted overlay itself, mTLS/E2EE makes this hard/impossible (without breaking the strong privacy and security principles inherent to OpenZiti).

A cleaner approach is to inspect at the identity enforcement edge, before traffic enters the mTLS/E2EE path, or after it exits it.

In practice, there are 3 sensible patterns:

  1. Host / client-side inspection: Capture close to the workload, most likely via EDR (which probably uses eBPF/host telemetry). This is usually a great place for process-aware context and avoids weakening the overlay design just to regain visibility.
  2. Pre-encryption replication / local inspection: Inspect or replicate traffic at the Ziti enforcement point before it is wrapped in overlay mTLS/E2EE — for example at a Ziti Edge Router / 1. NF Firewall style enforcement layer. From there you can either:
    1. send telemetry / metadata / alerts to a central system, or
    2. where policy requires it, send replicated packets out-of-band to IDS/IPS.
  3. Post-overlay inspection at egress / mediation point: If a service must traverse a designated inspection boundary, inspect after the overlay exit point or at an intermediate service hop / broker between Ziti-connected segments.

So to your specific questions:

  • At Ziti Router? Yes - that is probably the cleanest current architectural answer for local inspection/replication near the enforcement point.

  • At Tunneler? Potentially yes, especially for host-local telemetry and future deeper inspection patterns, but I’d treat that more as a host-side / endpoint-side model than the primary answer today.

My recommendation would be: keep mTLS/E2EE as the default, use host telemetry where possible, inspect/replicate before encryption when needed, and only use centralized packet inspection selectively by policy.

In other words, don’t break the overlay to regain visibility - move visibility to the right edge.

3

Hi @cao,

Let's break this into two distinct questions (IPS / IDS) and two distinct locations (tunneler/router).

IPS

In general, third-party IPS with OpenZiti is never possible. Anything that breaks the e2ee or mTLS of the overlay will fundamentally break OpenZiti communication entirely. IPS (as far as my understanding goes) relies on decrypting the traffic to inspect payloads and that doesn't work with OpenZiti.

  • can IPS be at the router: no
  • can IPS be done at the tunneler: maybe but the traffic must somehow be inspected before it gets to the tunneler. In practice that seems pretty hard maybe even impossible based on how OpenZiti works. I would doubt it would work.

IDS

Thrid party IDS for "anything not OpenZiti" seems like it should work fine to me. The tunneler traffic would noticed and need to be allow-listed as safe, you should be able to do IDS for non-OpenZiti traffic at the router just fine as well.

However, any OpenZiti traffic will be 100% opaque to the IDS system because of the above mentioned mTLS/e2ee. Any traffic offloading from a tunneler or router back to the regular underlay would all be subject to "regular" third-party IDS inspection just like it can be now.

  • can IDS work at the router: yes but not for OpenZiti-based traffic
  • can ID work at the tunneler: yes but not for OpenZiti-based traffic

What is the suggestion for this use case?

I assume you want OpenZiti in this mix now, so to me, the proper answer here seems to be metrics and an IDS/IPS that can act on that stream of data. Every time an identity dials a service you can emit an event from the controller. If abnormal traffic is being monitored then you would automate the controller to disable the identity and thus cut that identity off from the overlay. That would be how I'd do it and -- that'd be a super cool add-on to OpenZiti! :slight_smile:

As a side note, as Philip notes above we have also been developing zfw and zLAN. zLAN is capable of doing some interesting stuff and might be what you're looking for?

4

@PhilipGriffiths @TheLumberjack ,

Thanks you so much for the detailed reply.

As what @PhilipGriffiths,

generally we should avoid trying to inspect “inside” the encrypted overlay itself, a cleaner approach is to inspect at the identity enforcement edge, before traffic enters the mTLS/E2EE path, or after it exits it.

With this, i would assume a Ziti Tunneler would be a good endpoint to capture the original traffics((Before encryption by overlay network)) and forward the traffics to IDS., because Tunneler is where the traffics forward to the overlay network / where the traffics exits the overlay network.

I’m a bit confused on @TheLumberjack’s comments

    1. can IDS work at the Ziti router: yes but not for OpenZiti-based traffic
    2. can ID work at the Ziti tunneler: yes but not for OpenZiti-based traffic
  1. Ziti Router is for Overlay Network traffics, encrypted “opaque” traffics go through the Ziti Routers, it wouldn’t able to get the original unencrypted traffics , right?
  2. Ziti Tunneler, since Tunneler is the device which “brings” traffics from underlay network to overlay network, It would know the original traffics. Why here answer is yes but not for OpenZiti-based traffic?

Best Regards
Cao

5

Hey cao,

I would best describe the question by stating you need to ‘capture’ traffic pre-Ziti encryption.

This explains a few things:

  • yes, you would be able to apply it to the tunneler for Ziti based traffic, as long as its done BEFORE Ziti intercepts and applies mTLS/E2EE.
  • why I said it ‘could’ be done on a router. It cannot if you pre-encrypt from tunneler before the router. However, router can be run as a gateway where the intercept happens.
  • this is why I suggested zLAN as an option. It runs using eBPF in kernel for routers, so it ‘sees’ packets, giving you the option to replicate/other before Ziti intercepts and applies mTLS/E2EE (again, this will only work for routers running as a GW, not for connection using ZET as in your diagram, this would require our eBPF technology to be abled in ZET, which is possible but not under active development).
  • this is also why I suggested host/client-side inspection. Most EDR today uses eBPF so that it can see processes in kernel before Ziti intercepts and applies mTLS/E2EE.

I hope that helps clarify. If you would like to have a call to go deeper on your requirements and how NetFoundry can help achieve your outcomes, we would be happy to chat more. This is a problem space we are seeing more and more with some of our enterprise customers.

Regards, Philip