jonfriesen

Build a browser on top of an open standard, neglect that standard, then refer to that neglecting as the reason to kill it. This fits that spiderman pointing at spiderman meme perfectly. It's exhausting.

Yes, since NixOS runs on a standard Linux kernel, Qtap will work. I realized that we weren't scanning the nix store for shared libs (eg. OpenSSL) and added that this morning.

Thanks! We're really excited about Qcontrol and what it will be able to provide! The rules in that doc are powered by our Rulekit project https://github.com/qpoint-io/rulekit if you're curious about seeing more.

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!

`ecapture` has been around for a while and do a lot of great stuff and a lot of functionality overlaps.

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!

As of today, we don't output pcap or har files though these are additions I'd like to make in the future, they aren't currently on our near term roadmap.

I think the closest is an app with a full GUI called LittleSnitch. It's pretty impressive.

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

These are all great callouts. We've worked hard to address some of them, some are future endeavours.

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!

Not today, maybe one day!

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

Qtap does require root privileges to function as it uses eBPF to hook into kernel and userspace program functions. The good news is it can also be run within a container.

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.

You've definitely hit on a point that we've talked about at length and have come to terms that different organizations have different requirements, especially when it comes to regulatory and compliance.

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.

Fair point on -O2 and -O3 optimized bins. We've approached this by building custom bin utils that are optimized for blazingly fast symbol recognition. Traditional ELF tools that focus on providing comprehensive context for debugging, we are strip away everything that is not the symbol locations we need.

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.

That was one of our biggest motivators when dreaming up Qtap.

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.

This is a great point, and Qtap itself does need to be used with care. The company behind Qtap (Qpoint.io) provides full inventory and alerting for this sort of scenario.

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.

Qtap scans binaries of processes as well known locations for OpenSSL on startup, then passes the offsets to eBPF where it hooks into the SSL_read and SSL_write to get the content before or after it's been encrypted.

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

A small note, the DigitalOcean dev DBs do have daily backups though these are not accessible by the user and only come into play when there is a non-recoverable issue with the node they are on.

Hey futhey,

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