Mikiri WAF is an application-level firewall designed to protect websites, online stores, personal accounts, portals, marketplaces, APIs and other web applications from compromise attacks, L7 DDoS, password matching, parasitic bots and other OWASP threats.
Using Mikiri WAF means agreeing in full to all the terms and conditions the EULA.
The domain names presented on the website (
example.com,example.org,example.us, etc.) and subdomains as well as IP addresses are used as an example.Mikiri WAF uses service headers in the format
x-waf-*(for example,x-waf-oa-request-id). The use of headers with similar names in web applications is not allowed in order to avoid possible errors in operation.
Mikiri IPG API data is loaded through the API. Agents ask the API. The API fetches the data from the geolocation server, caches a successful answer and returns it. The accuracy of the data obtained is not guaranteed due to the specifics of the collection of such data.
Modified copies of some functions of the Nginx web server are used in the Filter.
Mikiri WAF keeps a rolling support window for the operating system. For each operating system below, the window holds the two latest releases, beginning with the version in the table.
A newly published release enters the window immediately. The window then contains that release and the one before it, while the earlier release is still at or above the listed minimum. The release that falls out of these two leaves the plan.
The Nginx window is in Filter.
The same window applies to every Mikiri WAF agent. It shifts the same way when a new operating-system release is published.
| Operating system | Window starts at |
|---|---|
| Debian | 13 (trixie) |
| Ubuntu | 26.04 (resolute) |
| RHEL | 10 |
Main:
Filter (mikiri-waf-filter) - designed to analyze requests and responses, decides whether to block them or transfer them to other subsystems. The analysis is performed using processing rules, the signature database, the MLA machine learning agent, as well as the API Firewall and third-party antivirus systems;
MLC (mikiri-waf-mlc) - designed to build behavioral models and identify other anomalies (for example, brute-force attacks, flood, DDoS and parasitic bot activity);
API (mikiri-waf-api) - designed to handle events and incidents, manage settings and enable the interaction of Mikiri WAF agents.
Auxiliary:
WMC (mikiri-waf-wmc) - designed to visualize events and incidents, as well as manage settings for Mikiri WAF agents;
Scanner (mikiri-waf-scanner) - designed to identify flaws in a secure web application.
The agents implement one lifecycle: prevent, detect, respond, discover, verify and mitigate. The product view, the path of one request and that lifecycle are in Architecture.
Filter accepts a request from a visitor or an API client. It proxies a legitimate request to the protected application and analyzes the response when one is available. Filter sends the request to MLC when signature analysis has blocked it, or when the request needs an additional check for anomalies. MLC passes information about blocked requests to API and the API writes that information to PostgreSQL.
WMC reads the current settings and the information about attacks from the API and sends setting changes back. The API delivers those settings to Filter, including the Nginx settings of that server, to MLC, including the behavioral models and to Scanner. The API also starts a scan. Scanner sends its requests to the protected application and returns the scan result, including the result of Recheck, to API.
A solid arrow is a request or an event. A dashed arrow is a delivery of settings. The boxes are the agents, not a separate physical server for each agent.
When deploying agents (with the exception of using Docker images), each agent runs on its own server:
To ensure fault-tolerant operation, the Mikiri WAF agents are combined into a single cluster, which uses the CID (Cluster ID) identifier as its identifier.
Clustering in Mikiri WAF provides automatic synchronization of settings, a list of blocked IP addresses and other parameters between agents, including those located on geographically distributed sites (for example, remote data centers).
Before creating the infrastructure, it is necessary to familiarize yourself with the diagram that reflects the minimum number of servers for each agent and the technical requirements for them:
Minimum servers in one cluster
One license key belongs to one installed Filter, and the keys of one cluster select its CID. A second Filter with its own key is the minimum for fault tolerance.
Requirements are approximate for loads up to 10k RPS. In a distributed MLC cluster the master node needs at least 24 GB of RAM and each auxiliary node at least 8 GB. A single MLC server needs 32 GB.
When several agents run as Docker images on one server, give that server the sum of the resources on the cards above.
Filter. Requests are not processed. Services proxied through the Filter are unavailable.
MLC. Brute-force, flood and DDoS attacks are not detected. Learning and retraining of the behavioral model stop. Sending blocked attacks to the API stops. Building the OpenAPI specification stops. The machine learning module on the Filter continues to use a behavioral model that was already created and applied.
PostgreSQL. All Mikiri WAF agents malfunction.
API. Other agents do not receive settings. Recording of detected anomalies stops.
WMC. The web-console is unavailable.
Scanner. Scanning the protected application stops. Recheck cannot be used.
During the operation of the Mikiri WAF agents, information about events can be contained:
/var/log/mikiri-waf/filter/, /var/log/mikiri-waf/mla/, /var/log/mikiri-waf/af/ (Filter);/var/log/mikiri-waf/mlc/ (MLC);/var/log/mikiri-waf/api/ (API);/var/log/mikiri-waf/wmc/ (WMC);/var/log/mikiri-waf/scanner/ (Scanner).If you have any questions related to the work of Mikiri WAF, you can find the answer in the knowledge base.