implementation-methodology---version-1-reactive

The initial iteration of our system implements a Reactive Agent Architecture. In this model, the focus is on rapid detection and immediate, hard-coded mitigation of threats. The system consists of three specialized Java agents: LocalAgent, CentralAgent, and MobileAgent.

5.1. Local agent

The LocalAgent is deployed on every client node. Its primary responsibility is continuous resource monitoring without inducing significant overhead on the host.

Methodology: We implemented a TickerBehaviour that cycles every 5 seconds.

1. CPU Monitoring: It utilizes the Java Management Extensions (JMX), specifically OperatingSystemMXBean, to retrieve the system load average directly from the kernel.
2. Network Monitoring: It parses the Linux virtual filesystem /proc/net/dev. By reading the raw bytes transmitted (tx) and received (rx) and comparing them against the previous cycle, it calculates the real-time bandwidth usage in KB/s.

The Monitoring Cycle:

addBehaviour(new TickerBehaviour(this, 5000) {
    @Override
    protected void onTick() {
        double cpuLoad = getRealCpuLoad();
        double netLoad = getNetworkKBs();
        
        // Encapsulate metrics in an ACL Message
        sendMetrics(cpuLoad, netLoad);
        
        // Local console feedback for debugging
        System.out.printf("CLIENT: [Sent] CPU: %.2f%% | NET: %.2f KB/s%n", cpuLoad, netLoad);
    }
});

Figure 5.1: local agent reporting CPU and network stats.

5.2. Central agent

The CentralAgent acts as the orchestrator. It listens for ACLMessage.INFORM messages from all local agents.

Detection Logic: The agent compares telemetry against static thresholds (e.g., CPU > 80%). On violation, it deploys a MobileAgent.

The Threshold Logic:

if (cpuUsage > CPU_THRESHOLD) {
    System.out.println("ALERT: Anomaly detected on " + senderAgentName);
    deployMobileAgent(senderAgentName, "stress"); // Hardcoded target for V1
}

5.3. Mobile agent (code mobility)

This is the most critical component of our distributed system. Instead of sending a command string to be executed by the local agent (RPC style), we migrate the entire MobileAgent code to the infected node.

Mechanism:

1. Migration: The agent uses doMove() with a ContainerID to physically transport itself from the Server Container to the Client Container.
2. Execution: Upon arrival (afterMove()), it executes a system shell command (pkill) to terminate the malicious process.
3. Self-Destruction: Once the task is complete, it calls doDelete() to free resources on the client.

Migration Logic:

@Override
protected void setup() {
    // ... args parsing ...
    ContainerID destination = new ContainerID(destinationContainer, null);
    System.out.println("Mobilizing to " + destinationContainer);
    doMove(destination);
}

@Override
protected void afterMove() {
    // Logic executed ONLY after arriving at the destination
    Runtime.getRuntime().exec("pkill -9 " + processToKill);
    doDelete();
}

5.4. Advantages and limitations of version 1

Advantages:

• Extremely Lightweight: The use of JADE agents proved to be highly efficient. During our tests, the monitoring agents consumed less than 0.1% of the host CPU, ensuring the monitoring tool itself does not degrade system performance.
• Decentralized Execution: By moving the “killing” logic to the MobileAgent, we reduce the processing burden on the central server. The server only decides when to act, not how to execute the action locally.
• Scalability: The architecture easily supports adding new client nodes (AL-4, AL-5, etc.) without modifying the central server code.

Limitations:

• Lack of Intelligence: The system relies on a “blind kill” approach. It assumes any high CPU usage is malicious and targets a hardcoded process name (stress). It cannot distinguish between a legitimate high-load task (e.g., a database backup) and a malicious miner.
• Static Thresholds: Fixed thresholds (80%) are prone to false positives.
• Single Point of Failure: While execution is distributed, the decision-making is centralized.

To address these limitations, specifically the lack of context in decision-making, we introduced an evolved “Audit & Whitelist” approach in the next section.