_ _ ____ _ ___ / \ ___| |_ _ __ ___ | _ \ ___ _ __ ___ __ _ / \ |_ _| / _ \ / __| __| '__/ _ \| |_) / _ \ '_ ` _ \ / _` | / _ \ | | / ___ \\__ \ |_| | | (_) | __/ __/ | | | | | (_| |/ ___ \ | | /_/ \_\___/\__|_| \___/|_| \___|_| |_| |_|\__,_/_/ \_\___|

Autonomous Host-Level Application Defense

Operating under ISO/IEC 27001 principles, with ISO/IEC 27001 certification in progress.
Technical verification report (PDF)

Astro Pema AI WAF demonstrates deterministic separation of benign and suspicious traffic on observed workloads using a CNN-GRU behavioral neural network architecture combined with a custom-tuned ruleset and ML scoring pipeline. The system integrates directly with ipset for kernel-level IP enforcement, applying time-bounded expiration to prevent list growth while preserving iptables performance, predictability, and auditability.

While modern WAF platforms emphasize edge-based traffic filtering and policy management, this system operates inside the application trust boundary. It uses behavioral sequence modeling and deterministic enforcement to identify and stop attacks that routinely bypass perimeter defenses.

Most commercial IDS and WAF platforms stop at decisions, not proof. They generate alerts, scores, and dashboards that imply action, but rarely expose a verifiable chain from detection to enforcement. In this system, the ground truth is not a UI state or agent report — it is ipset, a binary, inspectable fact enforced by the kernel. That distinction matters: it shifts security from interpretation to verification.

This level of auditability is something large, well-funded vendors typically avoid. A system that can be examined end-to-end — log → rule → expected action → enforced state — makes false positives and missed blocks provable rather than disputable. That is uncomfortable for marketing narratives and risky at scale, but invaluable for operators responsible for real systems.

What this system replaces is “the AI decided” with a closed, repeatable loop that can be independently verified. It aligns more closely with forensic rigor than with conventional security analytics, which is precisely why it stands apart.

This system improves with use, on your traffic, under your control — and every enforcement decision can be proven. That is not merely differentiation; it is operational trust, and very few systems in this space can honestly claim it.


Decision path Deterministic regex / policy pipeline with ML classifier as secondary gating (TRACE → SUSPICIOUS escalation)
Latency (typical) sub-millisecond to low-millisecond per request (host, load, and rule density dependent)
Memory (typical) tens of MB RSS (Rust service, loaded patterns, optional ML model; workload dependent)
Runtime footprint single host-level service with versioned rule set; ipset/nftables used for enforcement
Dependencies self-contained Rust binary with local model/artifacts; no external cloud services required
Notes: All performance characteristics are environment-dependent and vary based on hardware (CPU, memory, storage), traffic volume, log density, and configuration. Values shown reflect observed behavior in controlled deployments and are not presented as universal guarantees.

Deliverables

Status: Active development system with verified operational outputs. Formal packaging and certification artifacts are in progress.
  • Production-grade Linux service (Rust-based IDS / WAF engine)
  • Trained ML model artifacts for local inference (no cloud dependency)
  • Deterministic detection ruleset (pattern-based + policy logic)
  • Host-level enforcement integration (ipset / nftables compatible)
  • Systemd service definitions and operational control scripts
  • Structured logging (for audit, forensics, and verification)
  • Evaluation notebooks and reproducible verification reports (PDF)
  • Designed to operate alongside existing controls (rate limits, ModSecurity, fail2ban, etc.)

Architecture

Signals - Web access logs (Apache; Nginx-compatible) - Optional: error logs, authentication logs, application logs - Time-windowed event aggregation (host-local) Decision Pipeline - Deterministic policy and pattern matching (high-specificity rules) - Optional ML classifier scoring (local inference, ONNX-compatible) - Explicit decision states (e.g., TRACE, SUSPICIOUS, BLOCK-ELIGIBLE) - Conservative escalation logic to minimize false positives Enforcement Layer - ipset + iptables: * Offending IPs are added to a managed ipset * iptables DROP rules reference the set * Time-based expiration prevents rule-set bloat - nftables (alternative backend): * Offending IPs added to named sets * Input/filter chains reference those sets Operational Characteristics - Host-local execution (no external services required) - Deterministic behavior with auditable logs - Designed for coexistence with existing controls

Example workflow

# Log-driven ingestion (example) # The detector consumes local web logs in real time. tail -n0 -F /var/log/apache2/access.log | \ /opt/astropema-waf/astropema-waf --config /opt/astropema-waf/config.toml # Example detection log lines (format varies by configuration) [TRACE] verdict=trace reason=low_signal ip=66.249.74.41 path=/plantdb [SUSPICIOUS] verdict=suspicious reason=ml_suspicious ip=203.0.113.10 path=/wp-login.php score=0.98 [ALLOW] verdict=benign reason=allowlist ip=66.249.74.41 path=/robots.txt # Enforcement (performed by a separate enforcer stage) # Host firewall references a managed set rather than per-IP rules ipset add bad_ips 203.0.113.10 -exist
Scope and limitations

This system is designed to reduce exposure to automated scanning, credential-stuffing, and commodity exploit traffic by combining deterministic detection rules with optional machine-learning scoring and fast host-level enforcement.

It operates as a compensating and complementary control. It does not replace secure configuration, timely patching, least-privilege access, network segmentation, authentication hardening, or comprehensive logging and monitoring. It is not represented as a complete solution for targeted intrusions or advanced persistent threats.

Licensing & Deployment Model (Reference)

The following section is provided for informational and positioning purposes only. AstroPema AI is not currently offering this system for sale. No pricing, licensing, or commercial terms are active at this time.

This outline reflects an intended future deployment model should the system be productized, and is included to provide context regarding scope, operational expectations, and market positioning.

Self-Managed Deployment (Reference)

Indicative only
  • Compiled binary and local model artifacts
  • Deterministic rule set and configuration templates
  • Deployment and operations runbook
  • Single-host deployment scope

Intended for experienced Linux administrators operating self-hosted infrastructure.

Assisted Deployment (Reference)

Indicative only
  • All self-managed components
  • Remote deployment guidance (time-boxed)
  • Baseline tuning against observed traffic patterns
  • Short stabilization window for configuration adjustments

Intended for production environments requiring initial validation and tuning.

This system is currently operated internally as part of AstroPema AI’s security research and production infrastructure. Any future commercial availability would be subject to separate legal, contractual, and compliance review.
This comparison is provided for architectural context only. No claims of superiority, replacement, or equivalence are made. astropema-waf is designed to operate alongside conventional security controls where appropriate.

Request access

Access requests are intended for technical review, collaboration, or research discussion. This does not constitute an offer of sale or a commitment to provide services.

Messages are reviewed directly by the project maintainer at oba@astropema.ai. No mailing lists or automated follow-ups.

About

astropema-waf is developed for self-managed Linux environments where operators require direct visibility into traffic behavior and deterministic, host-level enforcement. All detection, decision, and enforcement logic executes locally, using the same logs and firewall primitives already present on the system.

The system is intended to complement—not replace—existing controls such as upstream CDNs, managed WAF services, rate limiting, or application-level protections where those are appropriate. It is designed to operate independently of external services and without reliance on cloud-based decision paths.

Development emphasizes explainability, repeatability, and operational accountability, with tooling and documentation suitable for technical review, audit preparation, and long-term maintenance in regulated or security-sensitive environments.