Mikiri WAF is an on-premises WAAP platform. The same agents prevent an attack, detect it, respond to it, discover a flaw, verify the event and mitigate a vulnerability that is still in the application. This page is those three views. The agent boxes and the minimum number of servers are in Introduction.
A visitor or an API client reaches Filter. Filter is the WAF: signatures, the API Firewall, anti-bot mode, response analysis and virtual patching. MLC builds behavioral models and reports brute-force, flood and DDoS. Scanner finds vulnerabilities and rechecks recorded events. API stores events and delivers settings. WMC is the Web Management Interface on top of API.
API and WMC are the control path. WMC reads attacks and writes settings through API. API delivers those settings to Filter, MLC, Scanner and writes events to PostgreSQL. Each agent runs on its own server. The hardware is in Clustering and fault tolerance. The boxes above are the agents.
| Capability | Where it runs | Page |
|---|---|---|
| WAF, signatures, request rules | Filter | Filter |
| API Firewall | Filter, configured in WMC | API Firewall |
| Bot protection and CAPTCHA | Filter | Anti-bot mode, CAPTCHA |
| WebSocket and gRPC | Filter | Filter |
| Behavioral models, brute-force, flood, DDoS | MLC, with MLA on the Filter | MLC, Activating AI protection |
| Mikiri IPG API used in threat analysis | Agents ask the API. The API fetches the data from the geolocation server, caches a successful answer and returns it | Introduction |
| Response analysis | Filter | Response processing rules |
| Blocking and the block list | Filter, synchronized through API | Request processing statuses |
| Vulnerability discovery and recheck | Scanner | Scanner |
| Virtual patching | A request processing rule on Filter | Virtual patching |
Filter accepts the request. A legitimate request is proxied to the protected application and Filter analyzes the response when one is available. A request blocked by signatures, or a request that needs an anomaly check, is sent to MLC. MLC reports blocked requests to API.
A blocked visitor can be sent a CAPTCHA page. Filter keeps the browser on the address of the protected site and unblocks the address after a correct answer. That exchange is in Integrating with CAPTCHA.
While the host is listed in waf_host_dm, Filter records the attack and does not block it. Removing the host turns blocking on. The option is in Detection mode.
The work repeats. Scanner finds a flaw. Recheck confirms that an event is a real attack. Filter and MLC prevent and detect the next attempt. A request processing rule mitigates a vulnerability that the application still contains. The test signature mikiri-waf-test is the check that blocking is on.
| Stage | What happens | Page |
|---|---|---|
| Discover | Scanner looks for flaws in the protected application | Discover, verify and mitigate |
| Verify | Recheck repeats a recorded event against the application | Re-checking events |
| Prevent | Filter applies signatures, the API Firewall and anti-bot mode before the request reaches the application | Filter |
| Detect | Signatures, MLA and MLC behavioral models mark brute-force, flood, DDoS and other anomalies. Agents ask the API for IPG API data. The API fetches it from the geolocation server, caches a successful answer and returns it | MLC |
| Respond | Filter blocks the request, can require a CAPTCHA and writes the event through API. Response rules match the answer of the application | Blocking statuses, CAPTCHA |
| Mitigate | A request processing rule blocks attempts to exploit a vulnerability that is still in the application | Virtual patching |
| Verify again | https://<site> is answered with 403 and the event is on the attacks page |
Deploy your first protected application |
Placing Filter in front of a site, an API, or a legacy application, behind a load balancer, or behind a Kubernetes Ingress, is in Deployment scenarios. The ports those placements use are in Access and license.