Menu
Modern Applications can use a lot of external services, some of those interactions are expected, others not so much.
There could be many reasons for those unexpected interactions, ranging from security vulnerabilities and various malware to outdated code and various reporting and statistics software may report to its creator or a third party. These unexpected interactions can be a security risk, and may also raise privacy concerns.
Conventionally discovering all these interactions may not be easy, especially discovering what software specifically is responsible for those external connections and where exactly information is reported – with common use of CDN solutions like Cloudflare single IP may be used by many different services.
It all changes with Coroot – with sophisticated use of eBPF advanced powers Coroot is able to identify specific services and external endpoints they connect to, including the actual DNS name software used for connection.
One of the key benefits of using eBPF is achieving 100% visibility without any blind spots. This ensures that all network connections are tracked at the OS kernel level, making it impossible for an application to hide its communications with other services.
When Coroot’s agent captures TCP connections, it only identifies their destination IP addresses. However, it’s not very useful to only see that an app communicates with 1.2.3.4. What would you do next to understand the situation better? Most likely, you’d try to identify the relevant DNS name for this IP. The most obvious way to do this is to perform reverse DNS resolution.
Let’s imagine that our app communicates with api.openai.com. In this case, we’d see communications with 104.18.6.192. Now, let’s check if this IP has a domain associated with it
% host 104.18.6.192 Host 192.6.18.104.in-addr.arpa. not found: 3(NXDOMAIN)
Nothing:(
On the other hand, our application initially tried to connect to api.openai.com, not to 104.18.6.192. So, we just need to capture the DNS request and remember the IP address to DNS name mapping. Since Coroot’s agent already tracks DNS queries at the eBPF level, this was easy to implement.
When our app calls api.openai.com it performs a DNS request, like the following
% dig api.openai.com ;; ANSWER SECTION: api.openai.com. 14 IN A 104.18.7.192 api.openai.com. 14 IN A 104.18.6.192
Coroot captures the DNS response and remembers that 104.18.7.192 and 104.18.6.192 refer to api.openai.com. That’s it. Now we can show meaningful endpoint names instead of IP addresses.
Agree that google.com is much more informative than 2a00:1450:4017:812::200e.
At Coroot, we have several test environments running a wide variety of applications in all popular programming languages and various open-source databases. We use them to ensure that Coroot delivers 100% visibility as promised to our users. We thought we knew everything about our clusters, but when we enabled global connection tracing, we discovered that our MongoDB was reporting some data to Segment
At first glance, this seems normal: MongoDB collects analytics and sends them to a third-party service. Surely, this is mentioned in the documentation. But to me, being able to see everything happening in my system feels like a superpower.
Install Coroot today to see what you can discover about your application! Discovered something interesting? Let us know!
