Why We Built It #

The motivation was straightforward: we didn’t have time to review logs.

BESTNET-CLOUD runs multiple firewalls, L2/L3 switches, Windows AD, load balancers, and web servers. Each generates syslog output, but it’s unrealistic for humans to manually review all logs daily. We use Zabbix for resource monitoring, but the task of reading syslog content and deciding whether an attack pattern should be ignored or addressed remained human work.

Services like AWS DevOps Agent (GA March 2026) and Azure Security Copilot now offer AI-powered log analysis on the public cloud side. However, these primarily target cloud resources and lack functionality to directly parse and analyze syslog from on-premises physical equipment. Moreover, since log data is transmitted to the cloud vendor’s AI infrastructure, these solutions cannot be used in closed-network environments.

That left us with building it ourselves. Fortunately, local LLM performance has reached practical levels, and all necessary components are available as open source.

System Architecture #

The system is called BASTION—a term meaning fortress or final stronghold, reflecting the vision of protecting infrastructure in closed-network environments.

The architecture is straightforward.

The components used are as follows—all open source or free tier:

Data Flow Details #

1. Log Collection (rsyslog) #

Syslog is received from each device on UDP/TCP port 514 and stored in directories organized by hostname, year, month, and program name.

/var/log/remote/
  fw-primary/2026/04/filterlog.log
  ad-server/2026/04/Security-Auditing.log
  lb-server/2026/04/loadbalancer.log
  ...

2. Log Summarization (summarize.sh) #

Every 15 minutes, cron executes summarize.sh, which extracts events from the past 30 minutes for each device and generates a structured text summary.

Because each device’s log format differs entirely, parsing is written per-device. For example, firewall filterlog uses comma-delimited fields with source IP at position 19 and destination port at position 22. Windows AD logs contain binary data, requiring grep -a. This device-specific knowledge embedded in scripts is the core work of this system.

3. AI Analysis (analyze.sh) #

The summary text is fed to a local LLM (Qwen2.5-14B) via OpenClaw. The prompt instructs: “Determine severity and return detected anomalies and recommended remediation in JSON format.”

Two critical design decisions apply here.

Session isolation: A dynamic session ID is generated for each analysis, preventing past conversation history from contaminating the context. LLMs can be influenced by prior results and drift in judgment, so we ensure fresh context for each analysis.

False positive control: Normal operation patterns (Nextcloud LDAP periodic authentication, Kerberos automatic authentication, firewall external scan blocking, etc.) are defined in the system prompt, providing the LLM with exclusion criteria to treat these as noise. We add patterns iteratively during operations.

4. Notification (notify.sh) #

LLM analysis results are sent to Slack with color coding by severity (critical=red, high=orange, medium=yellow, low=green).

For medium and above, a second detailed analysis is automatically sent. This second message includes the top 50 lines of raw logs, allowing operators to confirm both “what happened” and the raw data from the notification alone.

5. Interactive Analysis (Slack bidirectional) #

Apart from scheduled analysis, mentioning @OpenClaw-Monitor firewall analysis in Slack triggers immediate detailed analysis of the specified device. Natural language queries like “Are there signs of VPN authentication?” or “Check if a single IP is attempting multiple attack methods” are supported.

Since OpenClaw can execute bash commands, future expansion to automated remediation—dynamically adding firewall rules, isolating services, etc.—is possible.

GPU Requirements #

Resource consumption is surprisingly modest.

Supported Devices #

Any device that outputs syslog can be added to the monitored fleet by adding a parse script. FortiGate, Cisco, Palo Alto, and others are all supported the same way.

Operational Insights #

Future Plans #

Currently, the flow is “detect → notify.” We plan to extend to “detect → AI judge → auto-remediate.”

Specifically, we will implement automatic blocking of attack source IPs (calling firewall APIs directly), auto-blocking on brute force detection, and auto-throttling on anomalous resource use. We are also exploring a hybrid configuration where BASTION receives alerts from existing monitoring systems (Zabbix, AWS CloudWatch, Azure Monitor) via webhook, performs cross-system AI analysis, and executes automated remediation.

Summary #

We realized automated infrastructure log analysis using local LLM (Qwen2.5-14B) + GPUStack + OpenClaw + rsyslog + shell scripts. It runs on one V100 16GB GPU, log data never leaves the environment, and monthly operating cost is GPU electricity alone.

All components are open source, so anyone can reproduce the architecture. However, achieving full operation requires device-specific log parsing, accumulating false positive patterns, and tuning system prompts—non-trivial work and operational knowledge.

BASTION is currently running 24/7 in production on BESTNET LLC’s own infrastructure (BESTNET-CLOUD).