The Context

If you’ve ever looked at your Koha server’s top or htop output and seen the CPU pegged at 100% while your library OPAC is essentially a brick, you’ve likely been hit by the “Scraper Plague.” Modern LLMs and AI crawlers are hungry for data, and a Library Integrated System (ILS) like Koha is a goldmine. But these bots don’t care about your server’s health. They open thousands of connections, ignore robots.txt, and leave your real human patrons staring at a loading spinner. This automated traffic frequently exhausts backend server resources, specifically CPU cycles, memory, and database connection pools. The result is severe latency, service degradation, and an effective Denial-of-Service (DoS) attack against legitimate human patrons using the library services.

Today, I’m walking you through Project AEGIS (Advanced Edge Gateway & Inspection Shield). This post provides an exhaustive, expert-level implementation strategy for protecting a Koha library server running on an Apache backend within an Ubuntu Linux environment. The architectural solution introduces a dedicated, open-source Web Application Firewall (WAF) deployed at the network edge to intercept, analyze, and filter internet-facing HTTPS traffic. It’s a multi-layered, open-source architecture that moves the fight to the network edge so your Koha backend can breathe again.

The Anatomy of Application-Layer Exhaustion

To engineer an effective defense, it is imperative to understand the mechanics of the attacks targeting the Koha infrastructure and precisely why current mitigation strategies are failing. Historically, network security focused on volumetric Distributed Denial of Service (DDoS) attacks operating at the network and transport layers, specifically OSI Layers 3 and 4. Modern scrapers and AI harvesters, however, operate entirely at the application layer, or OSI Layer 7.

Why is your Iron Dome falling?

Most of us start with the basics: we see a bad User-Agent or a weird IP, and we write a mod_rewrite rule in Apache to return a 403 Forbidden. The problem is that, A 403 response isn’t free. By the time Apache says “Forbidden,” your server has already done the heavy lifting:

• The TCP Handshake: Three packets back and forth.
• The TLS Handshake: This is the killer. Asymmetric cryptography (SSL/TLS) is CPU-intensive. Your server has to negotiate keys and ciphers before it even knows what URL the bot is asking for.
• Worker Allocation: Apache spins up a process or thread to handle the request.

If a botnet hits you with 2,000 requests per second, your CPU is busy doing math for the TLS handshakes. It’s like some annoying kid is repeatedly knocking on your door, and each time you go and open the door, the naughty kid runs away, and you just stare at the empty street, leaving all the important work you were doing. You aren’t being “hacked” in the traditional sense; you’re being exhausted.

The Architectural Blueprint

To win, we have to stop the bots before they reach the Koha server. We’re moving from a single server to a Three-Tier Topology:

1. The WAN (Public Internet): Where the bots live.
2. The Edge (SafeLine WAF): A dedicated Ubuntu box that acts as a “Bouncer.” It terminates SSL, scrubs traffic, and challenges bots.
3. The LAN (Private Backend): Your Koha server lives here, completely isolated from the direct internet.

The “Split-Horizon” Secret Sauce

We have a problem: If we put everything behind a WAF, library staff inside the building might face latency or get blocked by the firewall while doing cataloging.

We solve this with Split-Horizon DNS. We configure our internal DNS server (BIND9) to tell a “helpful lie”:

• Internet Users get the Public IP of our WAF.
• Internal Staff get the Private LAN IP of the Koha server directly.

This means staff bypasses the firewall entirely for zero-latency management, while the rest of the world has to pass the “Aegis” gauntlet.

Implementation Phase I: Engineering The DNS

To ensure that traffic coming from the internet hits the AEGIS WAF while the internal LAN traffic goes directly to the Koha server, we must configure a Split-Horizon DNS server using BIND9 on an internal Ubuntu machine. This DNS service can reside on the Koha server itself, on the local network router, or on a dedicated internal gateway.

Installing and Initializing BIND9 Infrastructure

BIND9 (Berkeley Internet Name Domain) is the de facto standard for DNS management on Linux systems. It supports complex Access Control Lists (ACLs) and view-based routing required for split-horizon architectures. To begin, access the internal Ubuntu server dedicated to DNS management and install the core BIND9 packages, along with the necessary utilities and documentation.

Implementation Step	Terminal Command	Purpose
Update Package Repositories	sudo apt update	Synchronizes local package indexes with upstream Canonical servers to ensure the latest security patches are available.
Install BIND9 Core Components	sudo apt install bind9 bind9utils bind9-doc -y	Deploys the BIND9 daemon, associated management utilities, and offline documentation.
Verify Daemon Status	sudo systemctl status bind9	Confirms the DNS service has successfully bound to UDP/TCP port 53 and is actively listening for queries.

Architecting Access Control Lists and DNS Views

The core mechanism of Split-Horizon DNS relies on defining an Access Control List that explicitly identifies the internal trusted network subnets, and subsequently establishing “views.” A view instructs BIND9 to serve entirely different zone files based on whether the source IP of the incoming query matches the predefined ACL.

The primary configuration file for defining these views is /etc/bind/named.conf.local. This file must be edited to establish the internal and external routing logic. The configuration begins by defining the internal_clients ACL, which encompasses the localhost interface and the specific private IP ranges utilized by the library’s physical network infrastructure.

Following the ACL definition, the internal view is constructed. This view utilizes the match-clients directive tied to the internal_clients ACL. It permits recursive queries, allowing internal workstations to resolve arbitrary external internet domains alongside the local Koha domain. Crucially, it defines a specific zone file path for the library’s domain that contains the private LAN IP address.

Conversely, the external view is configured to match any client not explicitly defined in the internal ACL. To prevent the DNS server from being exploited in DNS amplification attacks, recursion is strictly disabled for this view. The external view points to a secondary, distinct zone file that contains the public IP address of the WAF server.

Configuration Block	BIND9 Configuration Syntax (/etc/bind/named.conf.local)
ACL Definition	acl "internal_clients" { 127.0.0.1; 192.168.1.0/24; };
Internal View Setup	view "internal" { match-clients { internal_clients; }; recursion yes; allow-recursion { internal_clients; }; zone "library.com" { type master; file "/etc/bind/zones/internal/db.library.com"; allow-query { internal_clients; }; }; include "/etc/bind/named.conf.default-zones"; };
External View Setup	view "external" { match-clients { any; }; recursion no; zone "library.com" { type master; file "/etc/bind/zones/external/db.library.com"; allow-query { any; }; }; };

Constructing the Isolated Zone Files

With the routing logic established, the physical zone files must be created to hold the specific DNS records. The administrator must create the directory structures for both the internal and external zones to maintain organizational hygiene and prevent accidental record cross-contamination.

The internal zone file, located at /etc/bind/zones/internal/db.library.com, is crafted to point the primary domain directly to the Koha backend’s private LAN IP, such as 192.168.1.50. This file contains the Start of Authority (SOA) record, Name Server (NS) definitions, and the critical Address (A) record resolving the domain to the local network endpoint.

Simultaneously, the external zone file, located at /etc/bind/zones/external/db.library.com, is generated to point the identical domain name to the WAF’s public IP address, such as 203.0.113.100. It is important to note that if the domain’s public DNS is actively managed by a third-party provider like Cloudflare, AWS Route53, or GoDaddy, this external BIND view is only necessary if the local BIND server acts as the authoritative public name server for the entire domain. If external DNS is managed elsewhere, the administrator simply updates the public A record at the registrar’s portal to point to the WAF’s IP, and the local BIND server only requires the internal view to override local routing.

Following the creation of the zone files, the syntax must be rigorously validated using the named-checkconf and named-checkzone utilities to prevent catastrophic resolution failures upon restarting the daemon. Once validated, the BIND9 service is restarted via systemctl. Local workstations must then be configured via the local DHCP server to utilize this BIND9 instance as their primary DNS resolver. Consequently, internal traffic will flow seamlessly to the backend, completely bypassing the edge WAF proxy.

Implementation Phase II: Deploying SafeLine (AEGIS)

With this architectural foundation, the dedicated WAF server will operate as the perimeter defense. My server is freshly provisioned with Ubuntu 24.04 Long Term Support (LTS). Considering the computational requirements of semantic analysis and high-throughput traffic proxying, the server requires a minimum hardware specification of a dual-core processor, 4GB of RAM, and 20GB of solid-state disk space to efficiently process payloads and manage logging databases.

Why SafeLine is a Bot-Killer:

• SSL Offloading: The WAF handles the heavy TLS math. It forwards clean, unencrypted HTTP (port 80) to the Koha backend over the trusted LAN.
• HTML Obfuscation: It scrambles the DOM on the fly. A human browser renders it fine, but a Python scraper sees <div> tags full of encrypted gibberish.
• JS Challenges: It injects a silent JavaScript “PoW” (Proof of Work) challenge. Real browsers solve it in 10ms. A curl script or a low-resource bot fails and gets dropped instantly.

System Prerequisites and Docker Initialization

SafeLine is deployed utilizing Docker Compose. This containerized approach ensures environmental consistency, isolating its core components—the semantic detection engine, the PostgreSQL management database, and the high-performance proxy interface—from the underlying host operating system.

Before initiating the deployment, the system administrator must ensure the Ubuntu environment is fully updated and all requisite compilation dependencies are installed. This includes tools for fetching remote scripts, compiling modules, and managing cryptographic libraries.

Pre-Deployment Command Sequence	Operational Purpose
sudo apt update && sudo apt upgrade -y	Updates system package lists and applies all pending security upgrades to the Ubuntu kernel and userland utilities.
sudo apt install -y curl wget gcc make libpcre3 libssl-dev	Installs essential dependencies required for network fetching, source compilation, regex processing, and SSL/TLS cryptographic handling.
curl -fsSL https://get.docker.com -o get-docker.sh && sudo sh get-docker.sh	Downloads and executes the official Docker installation script to deploy the container engine.
sudo apt install docker-compose-plugin -y	Installs the Docker Compose V2 plugin required to orchestrate the multi-container SafeLine application.

Executing the SafeLine Installation Routine

Chaitin Tech provides a streamlined, automated bash script designed to orchestrate the entire deployment process, minimizing the potential for configuration errors. The administrator executes the remote installation script using elevated privileges.

The installation script automatically pulls the required Docker images from the upstream registry, generates secure default credentials for the management database, and installs the SafeLine application stack into the default directory path of /data/safeline. The process requires no manual intervention once initiated. Upon successful completion of the deployment script, the SafeLine administration console will become accessible over the network via HTTPS on port 9443. The administrator must navigate to this interface using a web browser and authenticate using the dynamically generated credentials provided at the end of the terminal output.

Architecting the HTTPS Reverse Proxy

The fundamental operational requirement for the WAF is to accept encrypted internet traffic, inspect it, and securely forward the legitimate requests to the internal Koha server. The administrator logs into the SafeLine web interface to configure the reverse proxy parameters. The primary objective is to define a “Site” that listens for HTTPS connections directed at the public domain, such as koha.library.com, and proxies the clean traffic to the internal backend IP address, such as 192.168.1.50.

Within the SafeLine management console, the administrator navigates to the Site Management section to add a new protected entity. The configuration requires specifying the public domain name to ensure the proxy only responds to valid host headers, preventing IP-based scanning attacks. The listening port is explicitly defined as HTTPS on port 443.

The Upstream Server parameter is defined as the internal IP address and Apache listening port of the Koha backend, formatted as http://192.168.1.50:80. It is highly efficient to terminate the SSL connection at the WAF and forward the traffic to the backend via unencrypted HTTP over the trusted, isolated LAN. This offloads the cryptographic burden entirely from the Apache server, resolving the CPU exhaustion issues associated with TLS handshakes discussed earlier.

Crucially, the administrator must upload the SSL/TLS private key and full chain PEM certificates for the domain into the SafeLine interface. If the library utilizes Let’s Encrypt for certificate generation, SafeLine includes integrated mechanisms to provision, install, and automatically renew certificates directly from the WAF dashboard, ensuring uninterrupted secure connectivity. By terminating the SSL connection at the edge, SafeLine gains the ability to decrypt the payload, meticulously inspect the HTTP headers, query parameters, and request body for malicious intent or automated bot signatures, and only then forward the sanitized traffic to the backend infrastructure.

Implementation Phase III: Tuning Semantic Analysis and Anti-Bot Challenges

With the proxy pathway firmly established and successfully routing traffic, the WAF must be explicitly tuned to target and neutralize the aggressive bot traffic paralyzing the backend database. Default configurations provide baseline security, but mitigating highly distributed scraper networks requires leveraging SafeLine’s advanced, dynamic defense mechanisms.

Activating the Semantic Detection Engine

Unlike traditional legacy WAFs that require administrators to manually compile and continually update exhaustive lists of malicious User-Agent strings or write complex regular expression patterns—both of which modern bots easily bypass by rotating headers and obfuscating payloads—SafeLine’s core protection relies entirely on semantic analysis.

The semantic engine parses the incoming HTTP request contextually, breaking down the payload into an Abstract Syntax Tree (AST) to understand its true intent. It identifies SQL injections, path traversals, remote code execution attempts, and business logic abuses without relying on a static database of known bad strings. This feature must be configured to the “Balance” or “Strict” operational mode within the global protection policies to ensure high-fidelity filtering. By understanding the semantics of the request, SafeLine drops sophisticated, obfuscated attacks before they consume application resources.

Deploying Dynamic HTML and JavaScript Protection

Web scrapers and AI harvesters traditionally operate by programmatically fetching the raw HTML source code of a target webpage and extracting specific Document Object Model (DOM) elements. They achieve this using libraries like BeautifulSoup in Python or by driving automated headless browsers such as Puppeteer or Selenium.

SafeLine elegantly mitigates this extraction process via its Dynamic Protection module. When this feature is enabled in the dashboard, the WAF actively intercepts the outbound HTML response generated by the Koha server. Before transmitting the response to the client, SafeLine dynamically obfuscates and encrypts the HTML structure and all associated inline JavaScript on every single request.

The result of this dynamic encryption is profoundly effective. When a legitimate human user’s standard web browser receives the payload, the embedded decryption routines execute seamlessly in the background, rendering the page normally without any noticeable delay. Conversely, when an automated scraper attempts to parse the source code looking for specific data tags, it receives highly randomized, encrypted gibberish. This mechanism successfully prevents systematic data harvesting, rendering the scraped data useless, without having to drop the TCP connection outright, which can sometimes trigger aggressive retry loops from the botnet.

Enforcing the Anti-Bot Verification Challenge

While dynamic encryption protects the data, it does not prevent the bots from making the initial requests, which can still cause volumetric strain. To handle aggressive volumetric scraping that causes server lag, SafeLine must prevent the bots from reaching the backend entirely.

The administrator navigates to the Bot Management module within the SafeLine dashboard and activates the Anti-Bot Challenge protocol. When the semantic engine or behavioral heuristics detect traffic patterns that suggest automation—such as abnormal request velocity from a single subnet, the absence of standard browser header sequences, or rigid, predictable navigation paths—SafeLine intercepts the request. Instead of passing it to the backend, it issues an intermediate challenge page back to the client.

The primary mechanism is an invisible JavaScript Challenge. The WAF sends a highly obfuscated JavaScript payload that the client browser must execute to calculate a response token, which is then returned to the WAF. Simple programmatic scraping tools, such as curl scripts or basic Python requests libraries, possess no JavaScript execution engine. Consequently, they fail to return the token and the WAF instantly drops the connection, shielding the backend.

If the attacking botnet utilizes a headless browser capable of executing JavaScript, the WAF analyzes secondary behavioral anomalies, such as mouse movement telemetry and execution timing. If suspicious, it escalates the mitigation to an interactive CAPTCHA challenge. This provides an absolute, insurmountable barrier against automated access. This tiered combination ensures that the Koha backend only processes requests that have been cryptographically and behaviorally verified as originating from genuine human users, thereby completely eliminating the CPU, memory, and database connection exhaustion previously experienced.

Implementation Phase IV: Backend Apache IP Transparency and Hardening

The deployment of a reverse proxy introduces a fundamental networking challenge for the backend application. Because the SafeLine WAF acts as an intermediary, establishing its own TCP connections to the backend, the Apache web server hosting Koha will perceive all incoming internet traffic as originating from the WAF’s internal LAN IP address. This obscures the true source IP address of the external client. The loss of client IP visibility breaks Koha’s internal access logs, geolocation plugins, integrated rate-limiting, and any internal access control mechanisms that rely on IP telemetry.

Preserving the Client IP with Proxy Forwarding Headers

When SafeLine successfully verifies and proxies a legitimate request, it is configured to automatically append specific HTTP headers to the payload, notably the X-Forwarded-For and X-Real-IP headers. These headers contain the original public IP address of the internet client. However, the backend Apache web server ignores these headers by default, preferring the network-layer socket IP. Apache must be explicitly configured to trust the WAF and to dynamically extract the real IP address from these headers, replacing the remote address variable internally.

Compiling and Configuring the mod_rpaf Module

To transparently rewrite the remote IP address variables across the entire Apache daemon based on the headers provided by the reverse proxy, administrators must utilize a specialized Apache module. The mod_rpaf (Reverse Proxy Add Forward) module is the standard solution for this architectural requirement.

Because the version of mod_rpaf available in default Ubuntu package repositories is frequently outdated or incompatible with modern Apache 2.4 worker models, the module must be compiled directly from source to ensure maximum stability and compatibility.

First, install the necessary compilation dependencies on the Koha backend server:

Bash

sudo apt update
sudo apt install unzip build-essential apache2-dev -y

Next, download the stable release from the official repository, extract the archive, and execute the compilation routine :

Bash

wget https://github.com/gnif/mod_rpaf/archive/stable.zip
unzip stable.zip
cd mod_rpaf-stable
make
sudo make install

With the shared object file (mod_rpaf.so) successfully compiled and installed into the Apache modules directory, the administrator must create the load directive to instruct Apache to initialize the module upon startup:

Bash

sudo nano /etc/apache2/mods-available/rpaf.load

Insert the following directive: LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so

Finally, the configuration file must be created to define the operational parameters of the module. This file dictates which proxy headers to inspect and, crucially, which IP addresses are trusted to send those headers. Without restricting the trusted proxy IP, a malicious user could spoof the X-Forwarded-For header and inject a fake IP address into the logs.

Bash

sudo nano /etc/apache2/mods-available/rpaf.conf

The configuration block is defined as follows, where 192.168.1.100 must be replaced with the actual internal IP address of the dedicated SafeLine WAF server :

Apache

<IfModule mod_rpaf.c>
    RPAF_Enable             On
    RPAF_Header             X-Real-Ip
    RPAF_ProxyIPs           192.168.1.100  
    RPAF_SetHostName        On
    RPAF_SetHTTPS           On
</IfModule>

The module is then enabled via the a2enmod utility, and the Apache service is restarted. Apache will now seamlessly and natively log the true public IP address of the internet client, preserving the integrity of Koha’s application logic and auditing capabilities.

Hardening the Apache VirtualHost and Firewall

To ensure that malicious actors cannot bypass the sophisticated WAF defenses by discovering the Koha server’s public IP and targeting it directly, the backend infrastructure must be strictly locked down. This requires a two-tiered approach: application-layer restrictions within Apache, and network-layer restrictions using the Uncomplicated Firewall (UFW).

First, the Apache Koha OPAC VirtualHost configuration file must be edited to deny all requests that do not originate from the trusted zones.

VirtualHost Security Directives	Purpose
<VirtualHost *:80>	Listens for the unencrypted traffic forwarded by the WAF over the internal LAN.
ServerName koha.cup.edu.in	Ensures the server only responds to requests intended for the correct domain.
<Location />	Applies access control directives to the entire web root.
Require ip 192.168.1.0/24	Explicitly permits direct connection from the internal LAN subnet for workstation bypass.
Require ip 192.168.1.100	Explicitly permits connections originating from the SafeLine WAF.
Require all denied	Implicitly drops any traffic from unauthorized IPs attempting to connect directly.

Second, the system administrator must configure UFW on the Koha server to enforce these restrictions at the kernel level, dropping unauthorized packets before they even reach the Apache daemon.

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp
sudo ufw allow from 192.168.1.100 to any port 80 proto tcp
sudo ufw enable

This strict, redundant access control ensures that any external traffic attempting to hit the Koha server directly without passing through the SafeLine verification gauntlet is instantly dropped at the network interface.

Defense in Depth: Integrating Anubis and CrowdSec Ecosystems

While the SafeLine WAF provides exceptional generalized anti-bot protection and semantic analysis, creating a truly impregnable architecture requires a defense-in-depth philosophy. This involves integrating highly specialized, domain-specific tools and global threat intelligence networks to mitigate attacks at multiple layers of the OSI model.

If you want to be truly untouchable, we add two more layers:

1. Anubis: This is a specialized tool used by the Koha community. It’s a “Soul Weigher.” It forces browsers to do heavy math challenges only when they look suspicious. It’s like a CAPTCHA that humans never see.
2. CrowdSec: This is “Waze for Firewalls.” If an IP is attacking another library in the US or Europe, CrowdSec shares that intel with your server in India. You block the bot at the kernel level (IPtables) before it even tries to connect.

Advanced Scraper Mitigation: The Anubis Architecture

The global Koha developer and support community has rallied around a highly specialized, open-source application named Anubis, engineered specifically for combating aggressive AI data harvesters targeting library catalogs. While SafeLine operates at the edge, Anubis can be deployed as a secondary filter proxy directly on the Koha backend to provide targeted mitigation.

Anubis is built on the premise that traditional visual CAPTCHAs severely degrade the user experience, particularly for library patrons who may be elderly or less technically proficient, or who rely on screen readers. Instead of a visual test, Anubis silently evaluates incoming connections using a unique methodology termed “Soul Weighing”.

When a client requests a Koha catalog page, Anubis intercepts the request. Based on configured heuristics, it issues an invisible JavaScript Proof-of-Work (PoW) computational challenge to the connecting browser. The client’s processor must compute a cryptographic hash that satisfies a specific mathematical difficulty threshold before it is granted a persistent verification cookie.

Legitimate patrons utilizing modern smartphone or desktop browsers can compute the required hash in mere milliseconds. The user experiences an imperceptible, microscopic delay, the verification cookie is silently set, and they browse the catalog freely without ever clicking a checkbox. Conversely, botnets are designed for maximum network efficiency, frequently attempting to open thousands of concurrent HTTP connections using absolute minimal CPU resources per thread. When confronted with the Anubis PoW challenge, the bot’s architecture lacks the necessary processing power to compute thousands of cryptographic hashes simultaneously. The script times out, fails the challenge, and the connection is dropped. Production trials of Anubis on library catalogs have demonstrated the ability to successfully filter and drop 98% of automated traffic without disrupting human access.

Administrators configure Anubis thresholds using Common Expression Language (CEL) rules to dictate the difficulty of the challenge based on the “suspicion level” of the request payload.

Threshold Name	Request Weight (Suspicion Level)	Mitigation Action	Algorithm Difficulty
trusted-network	weight < 0	ALLOW	None (Direct Bypass)
low-suspicion	weight >= 0 AND weight < 10	CHALLENGE	difficulty: 1 (Light computation)
moderate-suspicion	weight >= 10 AND weight < 20	CHALLENGE	difficulty: 2 (Moderate computation)
extreme-suspicion	weight >= 20	CHALLENGE	difficulty: 4 (Heavy computation)

Synergistic Threat Intelligence: Integrating CrowdSec

To further augment the defensive posture and fundamentally reduce the computational load on the SafeLine WAF itself, the deployment must integrate a collaborative, modern Intrusion Prevention System (IPS) such as CrowdSec.

As established during the analysis of the 403 Forbidden lag issue, to completely prevent server resource exhaustion, malicious traffic must be definitively dropped at the firewall layer (OSI Layer 3 or 4) via iptables or nftables before it ever reaches the application layer to be processed. CrowdSec represents the modern, highly scalable evolution of legacy tools like Fail2Ban. While Fail2Ban relies strictly on localized, computationally heavy regex parsing of single log files , CrowdSec utilizes optimized, YAML-based scenario detection engines and, crucially, connects to a massive, global threat intelligence network.

By installing the lightweight CrowdSec agent alongside the SafeLine WAF on the edge server, the local system automatically subscribes to community-driven blocklists. If thousands of other servers worldwide have flagged a specific IP subnet for aggressive LLM scraping, vulnerability probing, or brute-force behavior, CrowdSec proactively downloads this intelligence to the local server’s Local API (LAPI).

The operational flow of CrowdSec is highly efficient. The CrowdSec Security Engine continuously reads the SafeLine access logs, identifying aggressive local probing behavior, such as rapid directory traversal, repeated 404 errors, or failed SafeLine anti-bot challenges. When a threshold is breached or an IP matches the global blocklist, the engine signals the remediation component. A CrowdSec “Bouncer,”a specifically designed firewall integration module, intercepts the flagged IP addresses and applies an immediate DROP rule at the Linux kernel layer.

The result is devastatingly effective against botnets. The malicious IP address is disconnected at the TCP/IP network layer. The network packets never reach the SafeLine application layer to trigger a semantic analysis, they never initiate a TLS handshake, and they absolutely never reach the Koha Apache backend to consume a worker thread. This completely mitigates the processing overhead, CPU starvation, and resulting lag caused by high-volume scraper attacks, ensuring pristine performance for library patrons.

Final Words

The degradation and systemic lag experienced by the Koha library server due to aggressive automated bot traffic is a highly complex architectural challenge requiring a multi-layered, application-aware security topology. Relying on basic Apache rewrite rules or reactive, log-based IP banning is demonstrably insufficient against modern, highly distributed AI scrapers capable of mimicking human HTTP parameters and exhausting server resources simply through connection overhead.

By meticulously implementing the comprehensive architectural design detailed within this report, the infrastructure is transformed from a vulnerable, single-point-of-failure target into a highly resilient, dual-path, impenetrable system.

The implementation of Split-Horizon DNS via BIND9 ensures that legitimate internal traffic, such as library administrative workstations and self-checkout kiosks, communicates directly with the Koha server via its private, unroutable IP address. This elegantly satisfies the requirement for unobstructed, zero-latency local access without compromising external security.

By deploying the open-source SafeLine Web Application Firewall on a dedicated edge server, all internet-facing HTTPS traffic is securely intercepted and decrypted. SafeLine’s advanced machine-learning semantic engine replaces outdated, inefficient signature matching, while its dynamic HTML/JS encryption and rigorous Anti-Bot verification challenges fundamentally neutralize the capabilities of automated scrapers to parse data. Reconfiguring the Apache backend with mod_rpaf guarantees that the Koha application maintains transparent, accurate client IP telemetry from the proxy layer for auditing, while strict VirtualHost and UFW access controls prevent malicious bypass attacks.

Finally, the integration of targeted application-layer defenses like Anubis for cryptographic Proof-of-Work, combined with the preemptive, global network-layer blocking provided by CrowdSec’s threat intelligence, creates a synergistic defense-in-depth architecture. This ensures that valuable server CPU, memory, and database connection resources are preserved exclusively for serving legitimate human patrons, restoring optimal performance and securing the library’s digital assets against continuous automated exploitation.