Linux host active early warning intelligent defense method and system based on multi-agent cooperation

Abstract

The application discloses a Linux host active early warning intelligent defense method and system based on multi-agent cooperation, which is driven by an intelligent agent coordinator to drive an active early warning intelligent agent, an analysis and decision intelligent agent and an active defense intelligent agent to work in cooperation according to a six-stage defense cycle; comprising: data collection: collecting multi-source security data of a Linux host, mixed anomaly detection: performing statistical baseline learning and machine learning anomaly detection, early warning generation and aggregation: generating early warning information according to the anomaly detection result; structured AI threat analysis: the analysis and decision intelligent agent calling a large language model to perform structured threat analysis on the aggregated alarm, context attack chain identification: generating an attack chain report; cascading defense execution: the active defense intelligent agent executing a cascading defense decision according to the risk level of the analysis result. The technical scheme provided by the application can reduce the false positive rate, improve the zero-day attack detection capability, realize a full-automatic defense closed loop, and the defense decision is auditable and traceable.

Description

Technical Field

[0001] This invention relates to the field of computer host security technology, specifically to a proactive early warning intelligent defense method and system for Linux hosts based on multi-agent collaboration. Background Technology

[0002] Traditional Linux host security defense systems mainly rely on the following technical approaches: (1) Intrusion Detection System (IDS / IPS) Based on Signature Rules Software like Snort and Suricata detect threats by matching predefined attack signatures with network traffic or system logs. Their core weaknesses include: It can only detect known attack patterns, and its recognition rate for zero-day attacks and variant attacks is extremely low. The rule base is costly to maintain and requires continuous updates; This generates a large number of false positives, leading to alarm fatigue among security operations personnel.

[0003] (2) Security analysis system based on single-agent Some solutions attempt to use a single AI agent for security threat analysis, but these have the following limitations: A single agent has a limited context window and cannot handle multiple types of tasks such as data collection, threat analysis, and defense execution simultaneously. The lack of modular division of labor means that decision-making errors by a single agent cannot be corrected by other modules; It is not possible to identify multi-stage attack chains that span across time windows.

[0004] (3) Traditional Security Information and Event Management (SIEM) System Software like Splunk and ELK Stack manage security incidents through centralized log collection and correlation rules. However, their shortcomings include: Passive alarms lack proactive defense and automatic response capabilities; Association rules rely on manual writing, making it difficult to cope with complex attack scenarios; The response delay is high, and manual intervention is usually required from alarm to handling.

[0005] (4) Anomaly detection method based on fixed threshold Existing systems mostly use fixed thresholds (such as CPU utilization exceeding 90% or network connections exceeding 200) for alarms: It cannot adapt to the differences in the basic operating environment of different hosts; Unable to detect periodic changes in the system (such as normal resource usage during peak business periods); It is easy to miss or falsely report. Summary of the Invention

[0006] The technical problem this invention aims to solve is as follows: Addressing the aforementioned problems of existing technologies, this invention provides a proactive early warning intelligent defense method for Linux hosts based on multi-agent collaboration. This method overcomes the limitations of existing methods, which can only detect known attack patterns and have extremely low recognition rates for zero-day and variant attacks; high rule base maintenance costs requiring continuous updates; lack of modular division of labor; inability to correct decision-making errors by a single agent; passive alerting; lack of proactive defense and automatic response capabilities; reliance on manually written association rules, making it difficult to handle complex attack scenarios; high response latency, often requiring manual intervention from alert to resolution; inability to adapt to differences in the basic operating environments of different hosts; and inability to achieve multi-stage attack chain identification across time windows.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention includes the following steps: Driven by the agent coordinator, the proactive early warning agent, the analysis and decision-making agent, and the proactive defense agent work collaboratively according to a six-stage defense cycle. The six-stage defense cycle includes: Data acquisition phase: Collect multi-source security data from the Linux host; Hybrid anomaly detection stage: Statistical baseline learning and machine learning anomaly detection are performed in parallel, and the results of the two are combined to generate anomaly detection results; Early warning generation and aggregation stage: Based on the anomaly detection results, early warning information is generated, and similar early warning information within the time window is aggregated based on similarity to generate aggregated alarms; Structured AI Threat Analysis Phase: The analysis and decision-making agent calls a large language model to perform structured threat analysis on the aggregated alarms, and outputs analysis results including threat type, risk level and handling suggestions; Context attack chain identification phase: Match predefined multi-stage attack patterns within a sliding window and generate an attack chain report; Cascaded defense execution phase: The proactive defense agent executes cascaded defense decisions based on the risk level of the analysis results. High-risk operations are pushed to the user interface for manual confirmation, while low-risk operations are executed automatically. The proactive defense agent executes defense instructions by calling Linux system commands, including using the kill -9 command to terminate malicious processes, using the iptables DROP command to block malicious IPs, using / etc / hosts.deny to configure permanent blocking, using the chmod command to restore file permissions, and using the rm -f command to delete malicious files.

[0008] Furthermore, during the data acquisition phase, the multi-source security data collected includes six categories: logs, network connections, process lists, file changes, Falco events, and CrowdSec decisions. These data are then standardized into a unified format security dataset by a unified data collector.

[0009] Furthermore, in the hybrid anomaly detection stage, the statistical baseline learning maintains the mean and standard deviation of the eight-dimensional feature vector based on a sliding window. When the cumulative number of samples reaches a preset threshold, the normal operating range of each dimension is set according to the 3σ rule. Feature values ​​exceeding this range are judged as abnormal. The preset threshold is when the cumulative number of samples reaches more than 10. The machine learning anomaly detection uses a pre-trained isolated forest model to output a normalized anomaly score for the eight-dimensional feature vector. The anomaly judgment result of the statistical baseline learning and the anomaly score of the machine learning anomaly detection are fused to generate a hybrid anomaly detection result.

[0010] Furthermore, the eight-dimensional feature vector includes process count, peak CPU usage, peak memory usage, number of connections, number of listening ports, number of failed logins, total CPU usage, and total memory usage.

[0011] Furthermore, the isolated forest model requires at least X samples for initial training, and then retraining is automatically triggered every Y new samples accumulated or at Z o'clock every day to continuously adapt to the operating characteristics of the current Linux host, where X can be set to 50, Y can be set to 500, and Z can be set to 2 o'clock in the morning.

[0012] Furthermore, in the early warning generation and aggregation stage, the early warning information is generated by the proactive early warning agent executing multiple detection rules. These detection rules cover suspicious processes, sensitive port listening, connection limit exceeding limits, sensitive file changes, abnormal permissions, brute-force attacks, and privilege escalation, persistence, lateral movement, and data leakage mapped by the MITRE ATT&CK framework.

[0013] Furthermore, in the warning generation and aggregation stage, the similarity is a three-factor weighted similarity, obtained by weighting the warning type matching weight (0.4), the data field overlap rate (0.4), and the description Jaccard similarity (0.2). Each warning type is independently configured with a time window, a similarity threshold, and a maximum number of aggregations. Specifically, the time window for brute-force warnings is 15 minutes, the similarity threshold is 0.9, and the maximum number of aggregations is 3. The time window for suspicious process warnings is 5 minutes, the similarity threshold is 0.8, and the maximum number of aggregations is 10.

[0014] Furthermore, in the structured AI threat analysis phase, the analysis and decision-making agent routes the aggregated alarm to the corresponding hierarchical prompt template according to the warning type, fills the template placeholders, and sends it to the large language model. It then parses the returned structured JSON result and outputs a structured analysis result containing threat category, risk level, confidence level, MITRE ATT&CK mapping, threat indicators, and handling suggestions. The hierarchical prompt template includes six categories: suspicious process template, brute-force attack template, network intrusion template, file tampering template, privilege escalation template, and general template.

[0015] Furthermore, in the context attack chain identification phase, the predefined multi-stage attack pattern includes: Lateral movement mode, its threat type sequence is brute force attack → network intrusion → privilege escalation, with a time window of 60 minutes; The persistent establishment mode has a threat type sequence of suspicious process → file tampering → privilege escalation, with a time window of 30 minutes. The data breach pattern has a threat type sequence of network intrusion → suspicious process → network intrusion, with a time window of 45 minutes. The complete APT chain pattern consists of the following threat type sequence: brute-force attack → suspicious process → privilege escalation → file tampering, with a time window of 120 minutes. Weighted similarity is used to associate alarms across time periods. The formula for calculating the weighted similarity is: 0.33 × alarm type matching + 0.25 × threat indicator Jaccard similarity + 0.25 × IP matching + 0.17 × port or directory matching. When the weighted similarity is ≥0.5, it is determined to be an associated alarm.

[0016] This invention also provides a Linux host proactive early warning intelligent defense system based on multi-agent collaboration, comprising: The data acquisition layer is configured to aggregate multi-source security data from process collectors, network collectors, log collectors, file collectors, CrowdSec integrated collectors, and Falco integrated collectors through a unified data collector, and standardize the multi-source security data into a unified format security dataset; The agent layer consists of three specialized agents: an active early warning agent, an analytical decision-making agent, and an active defense agent. The engine layer includes a statistical baseline learning module, a machine learning anomaly detection module, and a large language model threat analysis module. The presentation layer provides the user interface; The core scheduling layer is equipped with an agent coordinator, which is configured to drive the three specialized agents. The history manager is configured to persist the warning information, structured analysis results, attack chain reports, defense commands and execution results of the current defense cycle as audit logs.

[0017] Compared with the prior art, the advantages of the present invention are as follows: Reduce false alarm rate: The triple mechanism of statistical baseline (3σ adaptive threshold) + Isolation Forest (anomaly score) + alarm aggregation deduplication (three-factor weighted similarity) can significantly reduce the false alarm rate.

[0018] Enhance zero-day attack detection capabilities: Behavioral anomaly detection based on non-signature rules (12 detection rules covering suspicious processes, privilege escalation, lateral movement, data leakage, etc.) + ML anomaly detection + large language model structured analysis, capable of detecting unknown threat patterns.

[0019] Achieve a fully automated defense closed loop: from data collection, anomaly detection, AI analysis, policy generation to defense execution, a six-stage fully automated closed loop is implemented, with only high-risk operations requiring manual confirmation, reducing the workload of security operations personnel.

[0020] Defense decisions are auditable and traceable: Each defense cycle generates a complete audit record (including early warning information, AI analysis results, defense instructions, and execution results), supporting multi-dimensional audit queries by time and risk level.

[0021] Attack chain awareness capability: Through context association mechanism and time window sliding matching, it can identify multi-stage attacks across time windows (lateral movement, persistence establishment, data leakage, APT attack chain) and reconstruct the attack path.

[0022] Adaptive operating environment: The baseline manager continuously learns the normal operating mode of the host and adapts to different host environments and business cycle changes without the need for manual configuration of threshold parameters. Attached Figure Description

[0023] Figure 1 This is an overview diagram of the overall hierarchical architecture of the system in this invention.

[0024] Figure 2 This is a diagram of the overall system architecture in this invention.

[0025] Figure 3 This is a timing diagram of multi-agent collaborative defense in this invention.

[0026] Figure 4 This is a diagram of the 6-stage defense cycle activity in this invention.

[0027] Figure 5 This is a diagram of the hybrid anomaly detection activity in this invention.

[0028] Figure 6 This is an activity diagram of structured AI threat analysis in this invention.

[0029] Figure 7 This is a diagram illustrating the alarm aggregation and cascading defense decision-making activities in this invention.

[0030] Figure 8 This is an activity graph for attack chain context recognition in this invention. Detailed Implementation

[0031] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0032] The technical solution adopted in this embodiment is as follows: Figure 1 As shown, it includes the following steps: The solution employs a four-layer system architecture—from top to bottom: the Web presentation layer, the core scheduling layer, the analysis engine layer, and the data acquisition layer. The AgentCoordinator acts as the central coordinator, driving three specialized agents—ProactiveWarningAgent, AnalysisDecisionAgent, and ProactiveDefenseAgent—to work collaboratively in a six-stage defense cycle. Closed-loop control is achieved between layers through bidirectional data flow: Upstream (bottom-up), the data acquisition layer aggregates multi-source security data and feeds it back to the analysis engine layer. After AI analysis generates defense strategies, these are reported to the core scheduling layer and finally pushed to the Web presentation layer for operations personnel to interact with. Downstream (top-down), user commands are sent from the Web layer to the core scheduling layer. The scheduling layer then drives the analysis engine layer and the defense agents to initiate data acquisition requests to the data acquisition layer or issue defense commands to the target host. Seamless information transmission between intelligent agents is achieved through a standardized data model (WarningInfo → AnalysisResult → DefenseCommand). Combined with functional modules such as statistical baseline learning, isolated forest anomaly detection, hierarchical structured AI threat analysis, alarm aggregation deduplication and cascaded defense decision-making, and context-related attack chain identification, a complete proactive early warning intelligent defense closed loop is constructed from data collection to defense execution.

[0033] This embodiment also employs the following technical solutions: Figure 2 As shown, the Linux host intelligent defense solution employs a four-layer architecture, achieving a complete security defense closed loop through the collaborative work of three specialized intelligent agents. This includes the following steps: The system is structured from bottom to top into four layers: the data acquisition layer, the agent layer, the engine layer, and the presentation layer. The bottom-layer data acquisition layer aggregates six data collectors (process collector, network collector, log collector, file collector, CrowdSec integrated collector, and Falco integrated collector) and an independent threat intelligence collector through a unified DataCollector, shielding the heterogeneity of different data sources and uniformly outputting standardized security datasets to the upper-layer agents. The core layer deploys the AgentCoordinator as the scheduling hub, directly driving three specialized agents in the agent layer: ProactiveWarningAgent, responsible for calling the data acquisition layer to obtain system status and identifying anomalies through 12 detection rules; AnalysisDecisionAgent, which calls the KylinSecAnalyzer in the analysis engine layer to perform six-template structured AI threat analysis; and ProactiveDefenseAgent, which executes four defense responses—alarm, isolation, blocking, and remediation—through ResponseHandler. The web presentation layer provides dashboards, agent pages, defense decision pages, skill management pages, and history pages, fully covering security monitoring and operational interaction. Data transfer between layers follows a standardized model path: collected data flows from the collection layer to the early warning agent; early warning information is deduplicated by the alarm aggregator and then flows to the analysis and decision-making agent; AI analysis results are generated by the strategy and then flow to the defense agent for execution; and finally, complete audit records are persisted by HistoryManager.

[0034] Table 1 Description of System Core Components Components Duties Key technical features ProactiveWarningAgent Multi-source data acquisition and 12 anomaly detection methods Regular expression matching, keyword detection, port scanning, threshold detection, MITRE ATT&CK mapping detection AnalysisDecisionAgent Threat classification, risk assessment, and strategy generation Rule-based and AI-driven structured threat analysis, confidence assessment, and automated defense strategy orchestration. ProactiveDefenseAgent Defense execution and pending decision management Asynchronous execution via thread pool, four-level defense commands (Alert / Isolate / Block / Remediate), and human-machine collaborative decision-making. AgentCoordinator 6-stage defense cycle scheduling A fully closed-loop orchestration engine, providing lifecycle management, state persistence, and fault recovery. HistoryManager Full-process audit records JSON persistence, query by time / risk level / pagination AsyncAnalysisManager Asynchronous AI analysis Thread pool submission, file-level result caching (automatically expires after 24 hours) to avoid blocking the main loop. ContextManager Contextual association and attack chain identification Weighted similarity calculation and multi-stage attack pattern matching (4 known attack patterns) AlertAggregator Alert deduplication aggregation Three-factor weighted similarity calculation, time window aggregation, and prevention of alarm storms. Based on the above four-layer architecture, each component achieves cross-agent data transfer and collaborative defense through the AgentCoordinator in accordance with a standardized workflow.

[0035] This embodiment also employs the following technical solutions: Figure 3As shown, seamless data transfer between the three agents is achieved through a standardized data model. The complete defense workflow includes the following steps: The execution process of a complete defense cycle is divided into seven phases. Phase 1: Data Acquisition Phase. The AgentCoordinator notifies the ProactiveWarningAgent to call the DataCollector to execute collect_all_data(), returning six types of security data at once, including logs, network connections, process lists, file changes, Falco events, and CrowdSec decisions. Phase 1.5: Baseline Learning and ML Prediction Phase. Two detection channels are executed in parallel: BaselineManager updates the normal baseline parameters with a 3σ rule after every 10 rounds of sampling based on statistical learning using a sliding window, and MLBaselineManager calls the pre-trained IsolationForest model to output a 0-1 normalized anomaly score for the current eight-dimensional feature vector. Phase 1.6: Threat Intelligence Scanning Phase. IOC matching is performed on IPs, domain names, ports, etc. in the collected data. Phase 2, the anomaly detection phase, executes 15 detection rules covering security threats such as suspicious keywords in processes, sensitive port listening, connection limit exceeding limits, sensitive file modifications, abnormal permissions, brute-force attacks, privilege escalation (MITRE T1548), persistence (MITRE T1053 / T1546), lateral movement (MITRE T1021 / T1077), and data leakage (MITRE T1041 / T1048). Phase 2.5, the alarm aggregation and deduplication phase, uses AlertAggregator's three-factor weighted similarity calculation to merge similar alarms within a time window. Phase 3, the asynchronous threat analysis phase, uses the AsyncAnalysisManager thread pool (max_workers=3) to asynchronously call the KylinSecAnalyzer large language model for structured analysis, prioritizing results cached within 24 hours to reduce duplicate API calls. Phase 3.5, the context attack chain analysis phase, sends the analysis results to ContextManager for sliding window matching detection according to four predefined attack patterns. Phase 4, the strategy generation phase, generates corresponding DefenseCommands based on the analysis results and risk levels (HIGH → Block, MEDIUM → Isolate, LOW → Alarm). Phase 5, the defense execution phase, distributes traffic according to cascading decision rules—high-risk operations are pushed to the user via the WebUI for confirmation before execution, while low-risk operations are automatically executed by directly calling the ResponseHandler.Phase 6, the audit logging phase, involves HistoryManager recording the complete audit chain from alerts to analysis to defense to results.

[0036] Table 2 Standardized Data Model Transfer Mechanism Data phase Data Model Key fields Direction of transmission Data collection Original dictionary logs, network, processes, files, falco, crowdsec Collector → ProactiveWarningAgent Anomaly detection WarningInfo warning_type, risk_level, data, description, timestamp PWA → AlertAggregator →AsyncAnalysisManager Threat Analysis StructuredAnalysisResult threat_category, risk_level, confidence, mitre_attack_mapping, iocs, recommendations KylinSecAnalyzer →AnalysisDecisionAgent Defense Command Defense Command command_type, target, priority, auto_execute,requires_confirmation AnalysisDecisionAgent →ProactiveDefenseAgent Audit Records Audit Dictionary Complete nesting of all the above data AgentCoordinator → HistoryManager In the above collaborative defense workflow, AgentCoordinator, as the scheduling hub, refines the above seven-stage process into the following six-stage defense loop, and uses a unified activity graph model to precisely control the execution logic and branch conditions of each stage.

[0037] This embodiment also employs the following technical solutions: Figure 4As shown, AgentCoordinator implements a complete six-stage defense loop scheduling engine, serving as the core scheduling hub of the system. It includes the following steps: The first stage (multi-source data acquisition) calls DataCollector.collect_all_data() to acquire six data sources at once: logs, network, processes, files, Falco, and CrowdSec. The second stage performs baseline learning and ML prediction in parallel using a fork approach—the statistical baseline channel updates the normal baseline parameters on an 8-dimensional feature vector (process count, peak CPU, peak memory, number of connections, number of listening ports, number of failed logins, total CPU usage, total memory usage) using a 3σ sliding window (at least 10 samples are required, updated every 10 rounds); the ML baseline channel, after standardization using StandardScaler, calls IsolationForest(n_estimators=100, contamination=0.1) to output a 0-1 normalized anomaly score using the decision_function. The third stage performs threat intelligence scanning, annotating IOC indicators in the data and persisting them to files. The fourth phase performs 15 anomaly detections, categorized as follows: suspicious processes (regular expression matching of keywords such as trojan / backdoor / nc), network anomalies (detection of sensitive ports 21 / 22 / 3389 / 4444, connection limit exceeding detection), file and log anomalies (sensitive file changes, 777 / 666 permission anomalies, error logs / brute-force attacks), MITRE ATT&CK mapping anomalies (privilege escalation T1548, persistence T1053 / T1546, lateral movement T1021 / T1077, data leakage T1041 / T1048), and Falco / CrowdSec event correlation and baseline anomaly detection. The fifth phase performs alarm aggregation and deduplication, aggregating alarms within a time window configured independently for each alarm type (brute_force 15 minutes, lateral_movement 10 minutes, default 5 minutes) using a three-factor weighted similarity. When the max_alerts limit is reached, the alarm is flushed to generate AggregatedAlerts. The sixth stage involves conditional branching at the highest level—when a valid alert exists, it sequentially proceeds to asynchronous AI analysis (Phase 3: cache hit / thread pool submission), policy generation (Phase 4: HIGH→block / MEDIUM→isolate / LOW→alert), defense execution (Phase 5: high risk pending confirmation / low risk automatic execution), and audit logging (Phase 6: complete cycle writing to HistoryManager and coordinator_audit.log); if no alert is detected, the loop ends directly.

[0038] Table 3 AgentCoordinator Lifecycle Management method Function illustrate run_defense_cycle() Execute a single-round complete defense cycle The return value includes the status of each stage, the list of warnings, the analysis results, and the defense execution results. start_all_agents() Start all three agents Create a daemon thread, set its start_time, and persist its running state. stop_all_agents() Safely stop all intelligent agents Setting `running=False` will time out after 5 seconds, then join the thread and clear its state. start_continuous_monitoring(interval) Start continuous monitoring thread The `run_defense_cycle()` function is executed repeatedly at intervals of a specified number of seconds. get_system_status() Get the overall system status Returns the three-agent state, loop statistics, security score, audit count, and threat distribution. In the above six-stage cycle, the second stage, baseline detection, is the core entry point for anomaly detection—the following details the specific implementation of the hybrid anomaly baseline detection method that integrates statistical learning and isolated forest.

[0039] This embodiment also employs the following technical solutions: Figure 5 As shown, the hybrid anomaly detection mechanism integrates a statistical baseline with a machine learning isolation forest to achieve adaptive anomaly detection with a low false positive rate. It includes the following steps: The hybrid anomaly detection process takes the raw system data as input and first standardizes it into an eight-dimensional feature vector: process_count (total number of processes), cpu_top1 (percentage of processes with the highest CPU usage), mem_top1 (percentage of processes with the highest memory usage), connection_count (total number of active TCP / UDP connections), listen_ports (number of ports in the LISTEN state), failed_logins (number of authentication failure log entries), cpu_total (overall CPU utilization of the system), and mem_total (overall memory utilization of the system). The feature vector simultaneously enters two parallel detection channels: the statistical baseline channel maintains the mean and standard deviation of each dimension in a sliding window, and sets the normal operation range of each dimension according to the 3σ rule ([μ-3σ, μ+3σ]) after the cumulative number of samples reaches 10. The count_range is used for process count anomaly detection, connection_count_range is used for network connection anomaly detection, cpu_normal_range is used for CPU anomaly detection, memory_normal_range is used for memory anomaly detection, and failed_login_threshold is used for authentication brute force detection. The ML baseline channel feeds the feature vector into the pre-trained IsolationForest model (n_estimators=100, contamination=0.1, random_state=42) after standardization by StandardScaler. The score is mapped to a 0-1 normalized ML anomaly score by decision_function→ score = max(0, min(1, 0.5 - decision_score)) and the score is written to 288 deque history records (24-hour rolling window). The model requires at least 50 samples for initial training. Retraining is automatically triggered when 500 new samples have been accumulated or when the daily scheduling time of 2:00 AM is reached. The outputs of the two channels are weighted and summed according to configurable weights during the fusion phase to obtain the final anomaly score. When the score exceeds the warning threshold, a baseline anomaly warning (WarningInfo(baseline_anomaly)) is generated.

[0040] Table 4 Data Model of Baseline Manager Baseline Dimensions Data types Key fields process_baseline Process baseline count_range [min, max], cpu_threshold, mem_threshold, common_processes [list] network_baseline Network baseline connection_count_range, normal_ports [list], syn_rate_threshold, established_rate_threshold auth_baseline Certification baseline normal_login_hours [range], failed_login_threshold, normal_users [list] file_baseline Document baseline sensitive_file_hashes [dict], watched_dirs [list], allowed_modification_hours, suid_files [list] resource_baseline Resource baseline cpu_normal_range [min, max], mem_normal_range, disk_io_threshold, net_io_threshold Table 5 Key Technical Parameters of MLBaselineManager Parameters / Configuration value illustrate Feature Dimension 8-dimensional process_count, cpu_top1, mem_top1, connection_count, listen_ports, failed_logins, cpu_total, mem_total algorithm IsolationForest Anomaly detection based on isolation trees is suitable for high-dimensional data and has a linear time complexity. n_estimators 100 Number of isolated trees contamination 0.1 Expected abnormality ratio random_state 42 Reproducibility Minimum number of training samples 50 At least 50 samples are required for the first training session. Automatic retraining trigger 500 new samples / 2 AM daily Model adaptive update Historical record capacity 288 items 24 hours (5-minute intervals) Once the hybrid anomaly detection generates a WarningInfo alert, the alert data enters the following structured AI threat analysis pipeline, completing the intelligent transformation from the original alert to actionable defense recommendations.

[0041] This embodiment also employs the following technical solutions: Figure 6 As shown, in structured AI threat analysis, a large language model (LLM) is deeply integrated with security domain knowledge. Through hierarchical prompt templates, MITRE ATT&CK framework mapping, and structured output parsing, the AI ​​analysis results are transformed into executable security defense instructions. This includes the following steps: Structured AI threat analysis takes WarningInfo alerts as input. First, the THREAT_TYPE_MAPPING routing layer maps 21 types of internal threats to one of six analysis templates: malware / intrusion is routed to the suspicious_process template (MITRE Execution T1059), brute_force is routed to the brute_force_attack template (Credential Access T1110), network_intrusion is routed to the network_intrusion template (Command and Control), file_tampering is routed to the file_tampering template (Persistence T1098 / T1546), privilege_escalation is routed to the privilege_escalation template (Privilege Escalation T1548), and general alerts (Falco / CrowdSec / baseline_anomaly, etc.) are routed to the general template. If batch analysis mode is enabled, BatchAnalyzer groups and merges similar alerts by type (maximum 5 alerts per batch, maximum 3 alerts per prompt, forced processing after a 10-second timeout) to reduce the number of API calls to the large language model. During the population phase, corresponding fields ({process_snapshot} / {keyword} / {failed_login_count} / {port} / {connection_snapshot} / {directory} / {escalation_data}, etc.) are extracted from the threat data according to a placeholder matching strategy and truncated to 300-500 characters. If a specific placeholder is not matched, it falls back to the general placeholder {data}. The populated prompt is then sent to the large language model (hunyuan-turbos, temperature=0.3, stream=False, timeout 60s) via an OpenAI-compatible client.After the response is returned, the JSON is parsed—on success, it is deserialized into a complete StructuredAnalysisResult (including threat_type / threat_category / risk_level / confidence / summary / indicators[] / MitreAttackMapping / IOCs[] / recommendations[] / immediate_actions[] / false_positive_probability); on failure, it enters the regular expression fallback path to determine the risk level through keyword matching and generates a downgrade analysis result with confidence=0.3. After the analysis is completed, ContextManager.add_context() is called to update threat statistics and IP statistics and detect multi-stage attack patterns. Finally, a standardized AnalysisResult is output to AnalysisDecisionAgent to provide a decision-making basis for subsequent policy generation.

[0042] Table 6. Six-tiered prompt template system Template Name Applicable threats MITRE Focus Key Placeholder System prompt length suspicious_process Malware / Suspicious Processes Execution (T1059) {process_snapshot}, {keyword}, ​​{affected_processes},{detection_time} Approximately 300 words brute_force_attack Brute force Credential Access (T1110) {failed_login_count}, {login_details}, {time_range} Approximately 250 words network_intrusion Network intrusion / C2 communication Command and Control {port}, {connection_snapshot}, {connections} Approximately 280 words file_tampering File tampering / persistence Persistence (T1098 / T1546) {directory}, {change_count}, {file_snapshot} Approximately 260 words privilege_escalation Privilege Escalation Privilege Escalation (T1548) {escalation_data}, {related_info} Approximately 270 words general Unknown / Other Threats — {data} Approximately 150 words Table 7 Performance optimization of the batch analyzer index value illustrate max_batch_size 5 Maximum number of batches to be merged batch_timeout 10 seconds Forced processing after timeout max_single_prompt_warnings 3 Maximum number of alarms per alert Grouping criteria warning_type Merging alarms of the same type Single Analysis → Batch Analysis API call count decreased by (N-1) / N When N≥2, savings ≥50% Before entering the defense execution phase, the StructuredAnalysisResult generated by AI analysis is first processed by the following alarm aggregation and cascading defense decision module. Through deduplication and aggregation of similar alarms and cascading and diverting high and low risk alarms, an efficient and controllable defense response is achieved.

[0043] This embodiment also employs the following technical solutions: Figure 7 As shown, the alarm aggregation and cascading defense decision-making mechanism aggregates high-frequency, similar alarms within a time window using a three-factor weighted similarity calculation, and implements cascading decisions based on both automatic execution and manual confirmation according to the risk assessment results. This includes the following steps: The complete alarm aggregation process begins with the original WarningInfo input. `AlertAggregator.add_alert(alert)` generates an aggregation_key based on the alarm type and grouping configuration—different alarm types use independent grouping fields (suspicious processes by type + keyword, port-sensitive by type + port, brute-force attacks by type only, lateral movement by type + port, etc.) to ensure that similar alarms are accurately grouped into the same aggregation group. Then, expired alarms exceeding the configured time window are cleaned from the group pool, and existing alarms in the same group are iterated to calculate a three-factor weighted similarity score: Score = 0.4 × Alarm Type Matching + 0.4 × Data Field Overlap Rate + 0.2 × Description Jaccard Similarity. Each alarm type has an independently configured threshold (brute-force attacks 0.9, port-sensitive by 0.9, log errors 0.7, etc.). If the score is below the threshold, a new group is created and output directly with should_process=true; if the score is above the threshold, it is appended to an existing group. When the cumulative number of groups reaches the max_alerts limit for this type (3 brute-force attacks, 3 data leaks, 10 suspicious processes, etc.), aggregated output is triggered—an AggregatedAlert is created (including UUID identifier, alarm type, time span from first to last alarm, alarm count, highest severity within the group, representative alarm, and source alarm list), and the group is cleared to prepare for the next round of aggregation.

[0044] The aggregated alerts enter the cascaded defense decision generation stage: AnalysisDecisionAgent generates DefenseCommand defense instructions based on risk level and threat type (command_type is alert / isolate / block / remediate / quarantine, target is the target process PID / IP / file path / port, priority is 1-5). At the traffic distribution node, if the risk level is determined to be "HIGH" or command_type ∈ {isolate, block, quarantine}, a decision to be confirmed (including UUID, associated warning_id / threat type / risk level, target information, and AI suggestions) is generated and pushed to the Web / decisions interface for manual confirmation / rejection / modification before execution. If the condition is not met, confirmation is automatically bypassed and the ResponseHandler is called directly for execution. `send_alert()` records system logs and sends SMTP email notifications, `isolate_threat()` calls `kill -9` to isolate the process or `iptables DROP` to isolate the IP, `block_threat()` calls `iptables DROP + / etc / hosts.deny` to permanently block, and `remediate_threat()` calls `chmod` to restore permissions or `rm -f` to remove malicious files. After the defense execution is complete, the HistoryManager records the complete defense chain data. For complete configuration parameters of aggregation rules and cascading decisions, please refer to the relevant tables below.

[0045] Table 8 Aggregation Rule Configuration Table (Each WarningType is configured independently) Warning type Time window (minutes) Similarity threshold Maximum number of aggregates Grouping field suspicious_process 5 0.8 10 warning_type, keyword sensitive_port_connection 10 0.9 20 warning_type, port excessive_connections 5 0.7 5 warning_type potential_brute_force 15 0.9 3 warning_type log_error 10 0.7 20 warning_type, log_path sensitive_file_modification 10 0.8 10 warning_type, directory privilege_escalation 15 0.9 5 warning_type persistence 15 0.8 5 warning_type lateral_movement 10 0.8 5 warning_type, port data_exfiltration 10 0.8 3 warning_type default 5 0.7 10 warning_type Table 9. Cascade Rules for Defense Decisions Risk level Command type Confirmation Requirements Response measures HIGH alert, isolate, block, remediate, quarantine All need to be confirmed. Generate a decision to be confirmed and push it to the web interface. MEDIUM alert Automatic execution Log alerts + optional email notifications MEDIUM isolate, block Confirmation required Generate decisions to be confirmed LOW alert Automatic execution Log recording only In addition to aggregating and cascading decisions for single alarms, the system also performs cross-time window correlation analysis on continuous analysis results through the following context association modules, identifies multi-stage attack patterns hidden in the time dimension, and reconstructs the complete attack chain.

[0046] This embodiment also employs the following technical solutions: Figure 8 As shown, the context-dependent multi-stage attack chain identification method uses ContextManager to calculate the correlation of continuous analysis results and match time windows to identify covert multi-stage attack patterns. It includes the following steps: Attack chain context identification takes the StructuredAnalysisResult output by AnalysisDecisionAgent as input. ContextManager.add_context(result) first generates a unique context_id (format: threat_type_YYYYMMDDHHMMSS) and appends it to the AnalysisContext sliding window with a capacity limit of 50 entries. At the same time, it updates the threat type statistics and IP statistics (extracting IPs with regular expressions and maintaining the count / first_seen / last_seen / threat_types[] for each IP). The core analysis component employs sliding window detection for four predefined multi-stage attack patterns: Lateral movement (60-minute window, sequence: brute_force_attack → network_intrusion → privilege_escalation, triggered by hitting at least two nodes); persistence establishment (30-minute window, sequence: suspicious_process → file_tampering → privilege_escalation); data exfiltration (45-minute window, sequence: network_intrusion → suspicious_process → network_intrusion); and APT attack patterns (apt_stages) (120-minute window, sequence: brute_force_attack → suspicious_process → privilege_escalation → file_tampering). A ThreatPattern instance is created or updated when two or more threats appear sequentially within the window and the time difference is within the window's range. Then, a weighted similarity association is performed—similarity = 0.33 × threat type matching + 0.25 × Jaccard similarity + 0.25 × IP matching + 0.17 × port / directory matching. A threshold greater than or equal to 0.5 is used to determine an associated context. All associated contexts are sorted in ascending order by timestamp to reconstruct the complete attack chain—listing threat information for each stage in chronological order, verifying the consistency of the attack source IP, calculating the time interval between stages to assess urgency, and finally generating an attack chain report containing a complete overview of the attack path, pattern hit statistics, and repeat attack flags. The analysis results are persisted to the data / analysis_context.json file.

[0047] Table 10 Definitions of 4 Known Attack Modes Mode Name attack sequence Time window Minimum matching node describe lateral_movement brute_force_attack → network_intrusion →privilege_escalation 60 minutes 2 The attacker first brute-forces, then moves laterally, and finally escalates privileges. persistence_establishment suspicious_process → file_tampering → privilege_escalation 30 minutes 2 The suspicious process tampered with the file and escalated privileges to establish persistence after running. data_exfiltration network_intrusion → suspicious_process → network_intrusion 45 minutes 2 After a network intrusion, a malicious process runs and connects to external networks again to steal data. apt_stages brute_force_attack → suspicious_process →privilege_escalation → file_tampering 120 minutes 2 Complete APT chain: Breakthrough → Implantation → Privilege Escalation → Persistence Table 11 ThreatPattern Data Model Fields type illustrate pattern_type str Mode name (lateral_movement / persistence / data_exfiltration / apt) threat_sequence List[str] Threat type sequence time_window_minutes int Time window (minutes) occurrence_count int Number of hits first_seen datetime First matching time last_seen datetime Last match time Weighted similarity calculation method: similarity(A, B) = W1 × type_match + W2 × indicators_jaccard + W3 × ip_match + W4 × extra_match in: W1 = 0.33 (Threat type matching weight) type_match = 1 if A.threat_type == B.threat_type else 0 W2 = 0.25 (intersection weight of indicators) indicators_jaccard = |A.indicators ∩ B.indicators| / |A.indicators∪ B.indicators| W3 = 0.25 (IP matching weight) ip_match = 1 if same_ip else 0 W4 = 0.17 (Additional field matching weight) extra_match = 1 if same_port or same_directory else 0 Threshold: Similarity ≥ 0.5 is considered a correlation. Upper limit: max(similarity) = 1.0.

[0048] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0049] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A proactive early warning intelligent defense method for Linux hosts based on multi-agent collaboration, characterized in that, Includes the following steps: Driven by the agent coordinator, the proactive early warning agent, the analysis and decision-making agent, and the proactive defense agent work collaboratively according to a six-stage defense cycle. The six-stage defense cycle includes: Data acquisition phase: Collect multi-source security data from the Linux host; Hybrid anomaly detection stage: Statistical baseline learning and machine learning anomaly detection are performed in parallel, and the results of the two are combined to generate anomaly detection results; Early warning generation and aggregation stage: Based on the anomaly detection results, early warning information is generated, and similar early warning information within the time window is aggregated based on similarity to generate aggregated alarms; Structured AI Threat Analysis Phase: The analysis and decision-making agent calls a large language model to perform structured threat analysis on the aggregated alarms, and outputs analysis results including threat type, risk level and handling suggestions; Contextual attack chain identification phase: Match predefined multi-stage attack patterns within a sliding window and generate an attack chain report; Cascaded defense execution phase: The proactive defense agent executes cascaded defense decisions based on the risk level of the analysis results. High-risk operations are pushed to the user interface for manual confirmation, while low-risk operations are executed automatically. The proactive defense agent executes defense instructions by calling Linux system commands, including using the kill -9 command to terminate malicious processes, using the iptables DROP command to block malicious IPs, using / etc / hosts.deny to configure permanent blocking, using the chmod command to restore file permissions, and using the rm -f command to delete malicious files.

2. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, During the data acquisition phase, the multi-source security data collected includes six categories: logs, network connections, process lists, file changes, Falco events, and CrowdSec decisions. These data are then standardized into a unified format security dataset by a unified data collector.

3. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, In the hybrid anomaly detection stage, the statistical baseline learning maintains the mean and standard deviation of the eight-dimensional feature vector based on a sliding window. When the cumulative number of samples reaches a preset threshold, the normal operating range of each dimension is set according to the 3σ rule. Feature values ​​exceeding this range are judged as abnormal. The preset threshold is when the cumulative number of samples reaches more than 10. The machine learning anomaly detection uses a pre-trained isolated forest model to output a normalized anomaly score for the eight-dimensional feature vector. The anomaly judgment results of the statistical baseline learning and the anomaly scores of the machine learning anomaly detection are fused to generate a hybrid anomaly detection result.

4. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 3, characterized in that, The eight-dimensional feature vector includes process count, peak CPU usage, peak memory usage, number of connections, number of listening ports, number of failed logins, total CPU usage, and total memory usage.

5. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 3, characterized in that, The isolated forest model requires at least X samples for initial training. Thereafter, retraining is automatically triggered every Y new samples or at Z o'clock every day to continuously adapt to the operating characteristics of the current Linux host. X can be set to 50, Y can be set to 500, and Z can be set to 2 o'clock in the morning.

6. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, In the early warning generation and aggregation stage, the early warning information is generated by the proactive early warning agent executing multiple detection rules. The detection rules cover suspicious processes, sensitive port listening, connection limit exceeding, sensitive file changes, abnormal permissions, brute force attacks, and privilege escalation, persistence, lateral movement, and data leakage mapped by the MITRE ATT&CK framework.

7. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, In the early warning generation and aggregation stage, the similarity is a three-factor weighted similarity, which is obtained by weighting the early warning type matching weight (0.4), the data field overlap rate (0.4), and the description Jaccard similarity (0.2). Each early warning type is independently configured with a time window, a similarity threshold, and a maximum number of aggregations. The time window for brute-force attack type early warnings is 15 minutes, the similarity threshold is 0.9, and the maximum number of aggregations is 3. The time window for suspicious process type early warnings is 5 minutes, the similarity threshold is 0.8, and the maximum number of aggregations is 10.

8. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, In the structured AI threat analysis phase, the analysis and decision-making agent routes the aggregated alarm to the corresponding hierarchical prompt template according to the warning type, fills the template placeholders, and sends it to the large language model. It parses the returned structured JSON result and outputs a structured analysis result containing threat category, risk level, confidence level, MITRE ATT&CK mapping, threat indicators, and handling suggestions. The layered prompt templates include six categories: suspicious process templates, brute-force attack templates, network intrusion templates, file tampering templates, privilege escalation templates, and general templates.

9. The Linux host proactive early warning intelligent defense method based on multi-agent collaboration according to claim 1, characterized in that, In the context attack chain identification phase, the predefined multi-stage attack patterns include: Lateral movement mode, its threat type sequence is brute force attack → network intrusion → privilege escalation, with a time window of 60 minutes; The persistent establishment mode has a threat type sequence of suspicious process → file tampering → privilege escalation, with a time window of 30 minutes. The data breach pattern has a threat type sequence of network intrusion → suspicious process → network intrusion, with a time window of 45 minutes. The complete APT chain pattern consists of the following threat type sequence: brute-force attack → suspicious process → privilege escalation → file tampering, with a time window of 120 minutes. Weighted similarity is used to associate alarms across time periods. The formula for calculating the weighted similarity is: 0.33 × alarm type matching + 0.25 × threat indicator Jaccard similarity + 0.25 × IP matching + 0.17 × port or directory matching. When the weighted similarity is ≥0.5, it is determined to be an associated alarm.

10. A Linux host proactive early warning intelligent defense system based on multi-agent collaboration, characterized in that, include: The data acquisition layer is configured to aggregate multi-source security data from process collectors, network collectors, log collectors, file collectors, CrowdSec integrated collectors, and Falco integrated collectors through a unified data collector, and standardize the multi-source security data into a unified format security dataset; The agent layer consists of three specialized agents: an active early warning agent, an analytical decision-making agent, and an active defense agent. The engine layer includes a statistical baseline learning module, a machine learning anomaly detection module, and a large language model threat analysis module. The presentation layer provides the user interface; The core scheduling layer is equipped with an agent coordinator, which is configured to drive the three specialized agents to perform the method as described in any one of claims 1 to 9. The history manager is configured to persist the warning information, structured analysis results, attack chain reports, defense commands and execution results of the current defense cycle as audit logs.

Images