Monitoring doesn't physically "stop" the agent in real-time like a door slamming shut. It's more like a security camera combined with an alarm. The goal is to catch the attempt, trigger a response, and then you or your automated systems do the stopping.

Think of it in three layers:

* **Baselining:** First, you learn what "normal" looks like. You document all the legitimate destinations your servers are allowed to talk to. For example, your patch servers, your internal repositories, your monitoring system.
* **Anomaly Detection:** You set up rules to flag anything outside that baseline. If a server that only ever talks to `yum.internal.corp` suddenly starts sending large volumes of data to a new IP in a foreign country, that's your alarm bell.
* **Log Analysis & Alerting:** The monitoring system logs the event and sends you an alert. You then act.

Here's a practical, network-level example using a simple tool like `tcpdump` for ad-hoc checking, but you'd use something like Suricata or Zeek for production. The key is knowing your expected destinations.

```bash
# Capture outbound connections on port 443 (common for exfil)
# Filter OUT known-good IPs of your patch management and monitoring systems
sudo tcpdump -i eth0 'dst port 443 and not dst net 10.10.10.0/24 and not dst host 52.1.2.3'
```

In a real setup, you'd feed this data to your SIEM and create dashboards and alerts. For instance, in your log aggregation, you'd look for:
* New outbound connections not on an approved list.
* Unusual data volume to a single destination.
* Connections to known malicious IPs (threat intel feeds).

The actual "stopping" happens after detection. You get the alert, you isolate the compromised host from the network, and you begin your incident response. The monitoring is what gives you the chance to do that before all the data is gone. Without it, the exfiltration happens silently.