A lightweight Rust-based Notion client sparks a critical discussion on supply-chain security and how seemingly harmless apps can expose a company to Command and Control (C2) attacks. Learn three practical defense strategies, from quick firewall rules to robust corporate egress filtering.

That Cool New App is a Trojan Horse Waiting to Happen

I remember this one time, maybe five years ago, a junior engineer on my team, super bright kid, found this awesome new ‘log-prettifier’ CLI tool on GitHub. It was all the rage on Hacker News. He installed it on one of our staging bastion hosts to make his life easier. Two days later, our monitoring alerts for `prod-bastion-01` started screaming about CPU usage pegging at 100% during off-hours. We dug in, and sure enough, that ‘helpful’ tool had a little side-hustle: mining Monero. It wasn’t even malicious in a data-stealing way, just parasitic. But it was a wake-up call. The fanciest firewall in the world doesn’t matter if your people are willingly carrying threats inside the perimeter. That’s exactly what this whole ‘lotion-rs’ and Notion C2 vector discussion reminds me of.

So, What’s the Real Problem Here?

Let’s be clear: `lotion-rs` itself isn’t the villain. The developer seems to have built a cool, lightweight tool. The real issue, the one that should keep us up at night, is the technique it highlights. This is a classic Command and Control (C2) vector problem hiding in plain sight.

In simple terms, a C2 vector is just a way for an attacker’s malware on your machine to phone home for instructions. Attackers love to disguise this communication as legitimate traffic that your firewalls are trained to allow. Think about it:

• Traffic to Google Drive API? Looks normal.
• Traffic to Slack’s API? Looks normal.
• Traffic to Notion’s API? Looks normal.

An attacker can embed a small agent in a seemingly useful application. That agent then uses the Notion API (or any other common cloud service) to fetch its “tasks” from a specific Notion page the attacker controls and posts its “results” back. To our network security tools, it just looks like the app is saving notes. In reality, it’s a covert channel for exfiltrating data or receiving commands like “encrypt_filesystem()“. That’s the nightmare scenario.

Fighting Back: Three Layers of Defense

You can’t just tell your team “don’t install stuff.” We’re engineers; we use tools. The solution is to build resilient systems that assume a breach will be attempted. Here are three ways to tackle this, from a quick fix to a real architectural solution.

Solution 1: The Quick Fix (Local Host Firewall)

This is the down-and-dirty, immediate-response approach. If you’ve identified a specific application on a Linux box that you don’t trust, you can use the host’s own firewall to cut off its network access. This is great for containing a potential issue on a single machine while you investigate.

Using Uncomplicated Firewall (ufw), you can block a specific application by its path. First, you’d need to ensure you have application rules enabled.

# First, find the full path of the application
which lotion-rs
# /home/darian/.local/bin/lotion-rs

# Then, add a UFW rule to deny all outbound traffic for this specific executable
sudo ufw deny out from any to any app /home/darian/.local/bin/lotion-rs

This is effective but brittle. If the user moves or renames the binary, the rule is useless. It’s a stop-gap, not a strategy.

Solution 2: The Permanent Fix (Corporate Egress Filtering)

This is how we handle it at TechResolve. We assume that any machine, especially developer workstations or servers, can get compromised. The real defense is controlling what can leave the network. All outbound HTTP/S traffic from our internal networks is forced through an explicit proxy that performs inspection and filtering.

We operate on an “allow-list” basis. By default, nothing can get out to the internet. We have rules that allow access to specific, vetted domains and APIs required for business, like api.github.com, our own cloud provider endpoints, and key software repos. An unknown app like `lotion-rs` trying to talk to api.notion.com would be blocked by default.

This is a much more robust solution. It doesn’t care what’s running on the box; if the destination isn’t on the allow-list, the connection fails.

Solution 3: The ‘Nuclear’ Option (Application Whitelisting)

If you’re in a high-security environment, you can’t just worry about network traffic; you have to worry about what’s running in the first place. This is where application whitelisting at the OS level comes in. Instead of blocking known bad things (blacklisting), you only allow known good things to execute.

On Linux, this can be achieved with frameworks like SELinux or AppArmor. You create strict policies that define exactly which binaries are allowed to run. For example, on a production web server like `prod-web-04`, the policy might state that only `nginx`, `node`, and a few system binaries can execute. Anything else—including a script a developer dropped there—is blocked by the kernel before it even gets a chance to run.

# This is a conceptual example of what an AppArmor profile might restrict
# /etc/apparmor.d/usr.bin.my-locked-down-app

profile my_locked_down_app /usr/bin/my-locked-down-app {
  # This app can't access the network at all.
  deny network,

  # It can only read its own config file.
  owner /etc/my-app/config.conf r,

  # And it can only write to its own log file.
  owner /var/log/my-app/app.log w,
}

A Word of Warning: Be careful with this approach. It is incredibly powerful but also incredibly easy to break things. Rolling out strict SELinux or AppArmor policies requires careful planning, extensive testing, and a deep understanding of your application’s behavior. It’s not something you do on a whim.

Ultimately, the existence of tools like `lotion-rs` is a good thing—it pushes us to have these conversations. It forces us to move beyond old-school perimeter security and build defenses that are layered, intelligent, and assume that the threat might already be inside.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions