Comments URL: https://news.ycombinator.com/item?id=45428111

Points: 15

# Comments: 0

As far as log sinks, we have stdout right now. We have been working on Fluentbit and will eventually add a bunch more. If you have a request, drop them here!

We also have a services concept which support an "event store" and "object store", where the object store handles artifacts that may contain sensitive data and don't need to be indexed for search/aggregation (this is an S3 compliant store). The event store handles all of the events from connection audit logs (these cover the ip protocol level) to individual http request/response pairs. The event store is a custom API we use and need to write some proper documentation for, stay tuned!

Our aim is to make Qtap extensible and via a plugin system. We have http1/2 streaming capabilities and a plugin engine to run these in what we call a stack. Our goal is to add more protocols, like gRPC in the near future.

We have a few example plugins that do things like report request/response's and push access information to standard out in a console or structure log format. Our Pro version has a few more plugins like the ability to report errors (eg. an AI agent is getting HTTP 429 errors). These can be pushed to a service or log aggregator.

To summarize, we do a lot of the same things that ecapture does. We'd like to be less of a tool and more of a "always running" that ops, opsec, and devs use to answer tough questions. We look forward to open sourcing more of plugins as they mature!

https://www.obdev.at/products/littlesnitch/index.html

To address your points:

1. In our testing, uprobes add a statistically insignificant amount of latency and in comparison to a MITM proxies it's nearly identical to native.

2. True, we're focused on Linux right now. I'm looking forward to exploring Microsoft's eBPF implementation and exploring how we can support the Windows ecosystem.

3. You're right that the technique we are using for OpenSSL will not work for other runtimes. That said, there are other techniques that we've implemented in our Pro offering for the JVM, Go, and NodeJS. Rust is in the works!

Edit: Another user posted a link to https://github.com/gojue/ecapture which looks like it supports android and has some overlapping functionality.

There are some important flags when spinning it up in docker: `--privileged`, `--cap-add CAP_BPF`, `--cap-add CAP_SYS_ADMIN`, and `--pid=host`. These provide access to load eBPF programs, and monitor traffic.

Many deployments use Kubernetes daemonsets where Qtap runs in a container, but monitors all of the traffic on the node. The Qpoint paid offering comes with a Control Plane that produces context specific dashboards so seeing what's happening from a specific container, or pod namespace can provide a lot of insights into your deployments.

Qtap can be locked down with local firewalls or perimeter firewalls like other applications running within a network. The TLS inspection can also be disabled with a `--tls-probes=none` flag on startup.

Even without inspection enabled, Qtap provides rich context when it comes to connections to processes. For example, source/destination information, bandwidth usage, SNI information, container meta, even Kubernetes pod and namespace meta. All of this can paint a thorough picture of what's happening with zero instrumentation.

When it comes down to it, some orgs may not be able to use the TLS inspection or require specific methods of persisting data. If we can't support this today, our goal is to address these as they come up and hopefully help devs and ops folks working in these constrained environments get what they need while maintaining compliance.

We've also added caching so frequently used bins don't require multiple scans. Shared libraries as well. This has proven effective with optimized binaries, especially bins that are optimized, start, make a super quick network call, then exit, which was the bane of our existence for a little while.

How can we remove the impact that proxies have on connections, AND see the content without having to manage a custom certificate authority, AND not have to instrument all of our code.

That said, the eBPF verifier has robust security guarantees and runs on every load. So arbitrary mem access for example isn't possible. Qtap runs exclusively on your nodes, so you control what it captures and where that data goes. Our paid offering provides more functionality with a Control Plane solutions that provides dashboards, alerting, and live config updates. However, all sensitive information, like captured http bodies, are uploaded to a S3 compliant bucket that you control. This could be S3, Minio, or anything else that supports the S3 API. We never see this information.

It's intentionally designed for deployment within your infra and abides by the security policies you set within your org.

This is the eBPF side: https://github.com/qpoint-io/qtap/blob/main/bpf/tap/openssl....

The Go side which indicates what we are scanning for is here: https://github.com/qpoint-io/qtap/blob/main/pkg/ebpf/tls/ope...

For more docs on the topic: - https://docs.ebpf.io/ is a must read - https://eunomia.dev/en/tutorials/30-sslsniff/ has a tutorial on cracking OpenSSL open and getting the content as well. The tutorials they have are fantastic in general

The team agreed that we had some gaps that needed to be filled, you will now see new plans:

Basic $40/month 4GB RAM & 2 Shared vCPUs

Pro $75/month 4GB RAM & 1 Dedicated vCPU

We've also increased the vCPU count on the Pro $50/month plan from 1 to 2 vCPUS so it's now:

Pro $50/month 4GB RAM & 2 Shared vCPUs