WAF - WAAP

WAF - WAAP (Web Application Firewall / Web Application and API Protection) is the security module of TR7 that works at the application layer. It opens a request coming to an HTTP vService before it reaches the Backend Service; it examines its path, its query parameters, its headers and its body separately; it searches for known attack patterns and catches the deviations that do not comply with the request shape expected by the application. The part of the body to be inspected is bounded by a processing limit and the static content requests are kept out of the inspection by default.

The inspection does not work like a "block or pass" switch: every violation detected is written to the attack score of the request, the request is inspected completely and when the score reaches or exceeds the defined threshold, the request is blocked and the blocking page is returned to the client.

The protection is not a single switch that is turned on and off across the device: it is enabled separately for each vService. The default host group that is created together with the enabling starts in Learning mode; that is, the traffic is not blocked from the first day, it is learned first. The Virtual Host Groups added later, on the other hand, are created with the Blocking mode default.

It works on the vService

WAF works on the vService that meets the traffic: after the request is met by the vService and TLS is terminated, it passes through the WAF inspection before the target is selected. For this reason, WAF is enabled only on the HTTP type vServices; since L7 TCP and Network (Layer 4) traffic is not parsed at the application layer, it cannot enter the WAF inspection.

TR7 Product

WAF - WAAP is TR7 WAAP (Web Application and API Protection), one of TR7's four separately licensed products. Products are licensed individually or in bundles; licensing details are available on tr7.com.

Bot management is also within the scope of the TR7 WAAP product; it is explained in the Bot/DDoS section in the documentation.

TR7 products: Load Balancer - ADC · WAF - WAAP · AGS - AAM · GTM (Global Traffic Manager)

10,000+

Active signatures

3,294 attack patterns, separately for every request part on which they are inspected

10/10

OWASP Top 10

All the items of the web and API lists are met

Hybrid

Security model

Signature scanning and the learned rule set are combined in a single attack score

7

Inspection scope

Path, Query, Header, JSON, XML, Form and the raw body are inspected separately

3

Operating mode

Learning · Monitor · Blocking: it is set per host group

5

Protection level

From the loosest Elementary to the tightest Aggressive; the default is Very Tight

32

Attack category

The classes that carry a signature, from SQL injection to LLM prompt injection

Uninterrupted

Rule update

The change takes effect without dropping connections; there is no separate deployment step

What Is WAF - WAAP?

A Web Application Firewall (WAF) is the security layer that examines the HTTP and HTTPS traffic coming to a web application at the application layer. It is positioned in front of the application: every request is opened before it reaches its target, its content is evaluated and the request found malicious is stopped.

This is a different job from the known form of the firewall concept. A classic network firewall looks at the envelope of the packet; WAF, on the other hand, reads the letter inside the envelope.

The Difference from the Network Firewall and IPS/IDS

	Network firewall	IPS / IDS	WAF
The layer it works at	The network and transport layer	Packet and flow content, from the network layer up to the application layer	The application layer
The information it looks at	Source and destination address, port, protocol	Packet content, flow patterns, protocol anomalies	The path, the parameters, the headers and the body of the request
The question it asks	"Can this address connect to this port?"	"Is there a known attack or malware pattern in this traffic?"	"Does this request harm this application?"
Application knowledge	None	None; it evaluates the traffic independently of the protected application	Yes; it knows the addresses, the parameters and the expected request shape of the application
What it catches	Unauthorized access, connection to a closed port, scans	Network worms, exploit attempts, malware traffic, brute force	SQL injection, XSS, command execution, directory traversal, file upload exploitation
Encrypted traffic	It cannot see the content	It cannot see the content unless it terminates the traffic	It examines the clear content after TLS is terminated

The difference between IDS and IPS is whether the inspection intervenes in the traffic or not: IDS monitors the traffic and reports what it finds suspicious, while IPS stands on the line and cuts off the traffic it finds malicious. The Monitor and Blocking modes of WAF are the counterpart of the same distinction at the application layer.

WAF and IPS are the pair that is most often confused, because both look at the content. The difference between them is the application context: IPS carries generic patterns for every protocol and knows nothing about the protected application. For this reason, an IPS cannot say "such a parameter has never been seen on this endpoint" or "this address accepts only GET". WAF, on the other hand, since it can map the application, can also catch a request that does not match any signature and looks completely valid, on the grounds that it does not comply with the expected shape.

Port 443 of an application is open to everyone by definition. Of two requests coming from the same port, one can be an ordinary form submission and the other a database injection; at the network layer both look like "valid HTTPS traffic". Only a layer that looks at the content of the request and the structure of the application together can make this distinction.

The layers do not replace one another

WAF does not replace the network firewall or the IPS; it answers a different question and works together with them. On TR7, volumetric attacks and automated bot traffic are also handled in separate layers: Bot/DDoS Protection and L4 DDoS Protection.

Two Security Models

WAF products are built on two different ways of recognizing an attack. Both are incomplete on their own:

Negative security Signature scanning

"Is there a known attack pattern in this request?" Known attack forms are defined as patterns and are searched for in every request. It is easy to set up and does not need to know the application; on the other hand, it can see only the attacks that have been defined before. A new attack form stays invisible until its signature is written.

Positive security Expected request shape

"Does this request comply with the shape the application expects?" For every address of the application, the methods allowed, the parameters that can be carried and the length and type limits are defined; every request that does not comply with this definition is suspicious. There is no need to know the form of the attack, but it requires the application to be known and it is laborious to set up manually.

The negative model recognizes the known attack but misses the unknown one; the positive model catches the unknown one as well but requires the application to be mapped. The hybrid approach runs the two together: known attacks are met with the signature, and every deviation that does not comply with the shape of the application is met with the rule set.

The cost of the positive model is how the application map will be produced. Writing this map manually means hundreds of addresses and thousands of parameters even in a medium-sized application; for this reason, modern WAFs produce the map by learning it from the live traffic.

WAF on TR7

TR7 applies the hybrid model as its default way of working and produces the map of the positive model by learning. The distinctive aspects of the product are the following:

The hybrid model is the default, not compulsory

The two layers can be turned off independently of each other; when it is wanted, the protection is reduced to a single model:

• Only negative security. When the Structure Checks and Argument Checks main switches on the Checks screen are turned off, the structural and field inspections are not produced at all; only the signature scanning remains. It is preferred when it is wanted to run it as a classic signature-based WAF without spending time on learning the application.
• Only positive security. When the OWASP scanning of the rules is turned off (including the Any Paths rule), signature scanning is not performed in those scopes; the requests are inspected only for compliance with the expected shape.

When the main switches are turned off, the values in the rules are not deleted; when the switch is turned on again, it takes effect with the same values.

Two models combined in a single score

Signature hits and structural violations are not reported separately; both are written to the same attack score and the blocking decision is made over this single score. In this way, situations such as "a signature was triggered but it is weak, whereas there are two structural deviations" are evaluated on a single scale (see The Hybrid Security Model).

The map is produced by learning, not manually

When the protection is turned on, the vService first works in learning mode: no request is blocked, the traffic is recorded and which addresses the application actually serves and which parameters it takes are derived from these records. That the learning has finished is understood not by estimation but by the measured coverage value.

Not a separate device, a link of the delivery chain

WAF is not a product positioned separately in front: since the request is already being met by TR7, the inspection settles naturally between the TLS termination and the target selection. An additional hop, a second certificate management and a separate management interface are not needed.

Protection per vService, behavior per host group

The protection is turned on separately for each vService, not with a single switch across the device. Within a vService, the traffic can also be divided according to the Host header: while a mature domain name works in blocking, a newly published domain name proceeds in learning mode on the same service.

Why Is It Needed?

• Application vulnerabilities are not visible at the network layer. The firewall rules cannot distinguish the injection in the body of a valid HTTP request coming to the correct port.
• The patch does not always arrive in time. In the period until the application is updated for a known vulnerability, WAF stops the attack pattern before it reaches the application.
• Zero-day attacks are caught by shape, not by pattern. An attack that has no signature is caught by the positive security layer when it carries a parameter the application does not expect or an unexpected length.
• Compliance and reporting are required. Which attack came when and from where and how it was met has to be documented as a log, a report and a SIEM record.
• The change is made not in the application but in front of it. Without touching the source code, the protection is adjusted at the level of rules and exemptions.

How Does It Work?

A request coming to a vService on which the WAF inspection is enabled passes through a fixed chain:

01 · ExemptionThe whitelist is checkedThe exempted traffic and, by default, the static content are left out of the inspection

02 · SourceThe reputation is queriedThe blacklist check is made at the very beginning; a hit is written as a 100 point violation

03 · MatchThe page type is foundThe path of the request is matched with the rules of the host group

04 · InspectionThe request is examinedFor every request part, first the structural and field inspections, then the signature scanning

05 · ScoreIt is compared with the thresholdThe total score of the violations is measured against the blocking threshold of the protection level

06 · DecisionIt is applied and recordedAccording to the mode, the request is blocked, monitored or learned; the result is written to the log

The decision is made at the end of the chain: every violation, including a blacklist hit, is first written to the score, the request is inspected completely and the blocking decision is applied only when the scanning has finished.

The decision at the end of the chain is determined by the operating mode. In the Monitor and Blocking modes all the inspections work in the same way; the only thing that changes is whether the result is reflected in the traffic or not. In the Learning mode, on the other hand, the structural and field inspections are not run at all; only the signature scanning is performed and this scanning is carried out on all the parts of the request, ignoring the rule exceptions.

The inspection time is limited and if the time runs out, the request is blocked

The time allocated for the WAF scanning of a request is limited. Ordinary scans take milliseconds; when the time runs out, the scanning is terminated and the request is blocked. This blocking does not recognize the operating mode: even if the host group is in the Learning or Monitor mode, the request that times out is blocked. The requests are counted as a separate category (timeouted) on the monitoring screens.

If the rules cannot be loaded, the traffic is not inspected

When the rule set cannot be loaded for some reason, the request is considered blocked and the warning "WAF rules are not loaded, traffic is not being inspected" is displayed in the interface. The security default is a closed door.

The Hybrid Security Model

On TR7, positive and negative security are not two separate engines. The violations produced by the two layers are written to the same hit table and are summed in a single attack score; the blocking decision is made over this single score. This combination covers the weak sides of the two models mutually: the signature scanning catches the known attacks, and the structural inspections catch the deviations that have no signature at all.

Violation Scores

Violation	Score	Its source
Signature hit	2 · 4 · 6 · 8	The risk level of the pattern. If there is more than one hit in the same request, the scores accumulate.
Structural violation	24	An unexpected parameter, an out-of-limit length, an undefined method, excessive depth, a content type that is not allowed.
Blacklist hit	100	A source address with a bad reputation.

The Blocking Threshold

The protection level selected is directly the numerical value of the blocking threshold. As the value gets smaller, the protection gets tighter:

Protection level	Threshold	What is sufficient for blocking
Elementary	24	The accumulation of a large number of signature hits
Normal	16	More than one high-risk hit
Tight	8	A single hit with the highest risk
Very Tight (default)	4	A single hit with medium or higher risk
Aggressive	2	A single hit with the lowest risk

This table produces two results. First, structural violations block on their own at every level: 24 points reaches even the threshold of the loosest level. Second, since the signatures with a low score cannot reach the threshold on their own at the levels other than Aggressive, they are not loaded at all; they do not produce false positives, but they take effect when Aggressive is selected.

The Three Situations That Do Not Enter the Score

• A signature in the Monitor state is recorded with its real score, it is not added to the blocking total. This is the way to try a new signature in the live environment without risk.
• In the Learning mode the score is not summed at all; the request goes to the learning record.
• In the Teacher traffic the threshold is pulled to a value that is mathematically unreachable; the request of the teacher cannot be blocked.

Zero-Day Defense

A request that has no signature can also be caught: when it carries a parameter the application does not expect, when it is of an out-of-limit length, when it uses an undefined HTTP method, when its body is of excessive depth or when it carries a content type that is not allowed, it produces a 24 point structural violation and is blocked without any need for pattern knowledge.

The classification counts the two layers together

Since a request can produce both a signature and a structural violation, the report and log classification works with intersection: the number of attacks of an OWASP item covers both the signature hits and the structural violations.

Operating Modes

Mode	Inspection	Record	Effect on the traffic	When it is used
Learning	Only signature scanning; the structural and field inspections do not work	The learning journal (no Event Logs record is produced)	No request is blocked	When the protection is turned on for the first time; while the site structure is being learned
Monitor	The rule set works at full capacity	An Event Logs record is produced	The request is passed	A rehearsal on real traffic before moving to blocking
Blocking	The rule set works at full capacity	An Event Logs record is produced	The request whose score reaches the threshold is blocked	Full protection

The Learning records are not a Blocking rehearsal

In the Learning mode, the signature scanning works by ignoring the rule exceptions and the scope limits. For this reason, the attack list produced is broader than the list the same request would produce in the Blocking mode; the Learning records must not be read directly as "what will happen in blocking".

The mode is assigned not to the whole of the vService but to the host group: while api.site.com published over the same vService is in the Blocking mode, beta.site.com can stay in the Learning mode.

Protection Strength

The library is not a raw pile of patterns: every signature is mapped to industry standard classification frameworks. This mapping is carried to every surface, from the log to the report; besides the question "how many attacks were blocked", the question "which OWASP item, which CWE, which MITRE technique" is also answered.

120

CWE vulnerability class

The unique CWE code used in the rules; direct correlation with vulnerability management

40

CAPEC attack pattern

The behavior pattern of the attacker is labeled with the threat modeling language

33

MITRE technique

29 ATT&CK techniques and 4 ATLAS techniques for artificial intelligence attacks

33

Protected platform

From the database to the template engine, from the LLM service to WebSocket

What Is the Classification Good For?

The numbers say nothing on their own; the real value is what every signature gains when it is bound to a framework:

Framework	What it provides
Attack category	Groups the signature according to the attack type: 32 signature categories, plus the 5 catalog categories of the structural inspections. It is the basis of the category breakdown in the panel and the report.
OWASP Top 10 (Web and API)	The common language that the compliance reports speak. All the items of both lists are met; the tenth item of the API list is closed not with a signature but with structural rules.
CWE	The vulnerability class code. It is mapped directly with the vulnerability scanning and management tools in the organization: the question "is the attack blocked by WAF the same as the vulnerability found by the scanner?" becomes answerable.
CAPEC	Defines the method the attacker follows; it is used in threat modeling and attack surface work.
MITRE ATT&CK / ATLAS	Binds the attack to a known technique. The ATLAS mapping covers the techniques aimed at artificial intelligence systems.
Protected Target Types	Says which technology the attack caught by the signature targets: SQL and NoSQL databases, Java/Python/PHP/.NET/Node runtimes, XML parsers, LDAP directories, template engines, cloud metadata services, LLM services and RAG lines. In this way, to what extent the library covers the stack used by the organization is seen.

The signatures specific to the artificial intelligence age

The library meets the attacks aimed at LLM and artificial intelligence services in a separate category (LLM Prompt Injection): direct instruction override, jailbreak patterns, system prompt extraction and data exfiltration over the LLM. These signatures are labeled with the MITRE ATLAS techniques.

Performance

The signatures are compiled into a single combined database and a single scan is performed per request; as the number of rules increases, the latency does not increase linearly. The time WAF spends on every request is measured and written to the log line; it is presented in the report as a distribution extending from <0.1 ms to >1 s. That is, the question "how much does WAF slow it down?" is answered not by estimation but by the measurement of the product itself.

The library can grow up to 10,000 rules; the current set is 3,294 patterns. The own rules of the organization are added within this share.

Core Building Blocks

WAF-protected vService The protection unit

The protection is enabled on a vService of the HTTP type. Every protected vService carries its own default mode (new host groups are opened with this mode), its rule set, the protection level valid across the vService, its learning setup and its logs.

Virtual Host Group The division of the traffic

Divides the traffic of the vService according to the Host header of the request. Every group keeps its own operating mode and its own rule list. The default group, which cannot be deleted, meets the requests that do not comply with any pattern; if the request has no Host header, the matching is made over the destination address and port and the request falls to the default group again.

Page type (WAF rule) Positive security

It is the combination of a path pattern and the inspections to be applied to that path: the methods allowed, the path length and depth limits, the OWASP scanning and the field inspections. This rule stands at the center of the blocking decision. The structural and field inspections can be turned on and off collectively with the two main switches across the vService (Structure Checks and Argument Checks).

Signature library Negative security

Every rule defines an attack pattern and in which request parts that pattern will be searched for. The library consists of three layers: the built-in library, the global layer across the device and the layer specific to the vService.

Attack score and threshold The decision mechanism

Every violation is added to the attack score of the request; the OWASP Protection Level determines the threshold at which this score turns into blocking. The level determines not only the threshold but also whether the signatures with a low score will be loaded or not. Structural violations are 24 points; since the threshold of the loosest level is also 24, a single structural violation is enough for blocking at every level (in the Monitor and Blocking modes, where the structural inspections work).

Learning The source of the rule set

The rule set is not written manually, it is learned from the traffic: the Learning mode and the selective learning methods accumulate records, and the offline analysis produces page type and rule suggestions from these records.

How Is the Rule Set Formed?

A vService's rule set is fed from four sources:

Source	How it works
Analysis & Learning	Examines the past traffic in the learning journal collectively and produces page type and rule suggestions. It is started manually; when the result is examined and approved, it is written to the rule list.
Learning Methods	Conditional Learning and Teacher process the requests coming from the defined sources (IP, header or cookie) in the learning mode even while the host group is in the Blocking or Monitor mode. AI Learning has no source selection: it evaluates the event records that meet the statistical thresholds collectively, and for this the host group has to be in the Blocking or Monitor mode. Both methods apply automatically the rule change they produce in the defined period; there is no separate approval step.
Event Logs	The requests evaluated as false positives are selected and written to the rule list with a single teaching operation. The name of the operation changes according to the selection: Allow for the blocked requests, Teach for the requests that were only detected, Allow / Teach in a selection where the two are mixed.
Manual definition and import	The rule is written directly with Add; it is produced from a file with Import and Import (OpenAPI).

When Is the Learning Finished?

Deciding that the learning has finished is not left to estimation; two metrics answer this question numerically:

Metric	What it shows
Learning Coverage	Gives as a percentage how much of the traffic within the learning scope is now familiar. Its rising and flattening shows that the site has been learned.
Learning Discovery Rate	Shows how many request shapes that have never been seen before arrive per second. Its approaching zero is a sign of saturation.

The learning cannot be deceived

A single counter is not enough for a rule suggestion to be accepted: the minimum number of requests required, the number of different clients, the number of different countries and different ASN networks and the time interval diversity thresholds are sought together, and the progress is calculated according to the weakest of these criteria. In this way, nothing wrong can be taught to WAF with requests poured from a single source.

The learning record is kept with smart sampling by default: only the first few examples of every request shape are written completely, the rest are thinned out. The learned result does not change, the disk consumption drops noticeably.

The rules produced by the learning can be reverted: the settings written by a learning record are reverted with Revert Learning (steps); if there is a conflict or an irreversible situation, it is also notified.

Reporting and Visibility

The data produced by WAF is collected on three separate surfaces: instant monitoring, event-based examination and periodic reporting.

Report

The periodic WAF report is presented in six tabs (Overview · Attacks · Classification · Traffic · Client · Geography) and carries 22 separate breakdowns: besides the path, method, User-Agent, visitor, body size, WAF processing time, client address, hour, country, city, rule, scope, score and argument distributions, the OWASP Web, OWASP API, CWE, CAPEC, MITRE, category and target platform breakdowns are also included.

The report is displayed in the interface and downloaded as PDF and XLSX; it is sent automatically by e-mail in daily, weekly, monthly or yearly periods. All the protected vServices across the device can be combined in a single report.

Log and SIEM

Capability	Detail
Log line format	It is selected among nine formats; the CEF and JSON formats carry the attack information as a structured field.
Attack-only feed	A log profile can be selected in such a way that it sends only the attack record; clean traffic does not flow to the SIEM.
Field selection	The fields to be sent per attack (score, severity, scope, rule name, category, CWE, MITRE, CAPEC, OWASP Web/API, target) are selected one by one; the content language is determined separately.
Sampling per destination	A separate sampling value is defined for every syslog destination.
Log suppression	The WAF log of the requests that comply with a certain condition is not written at all; health check or probe traffic does not inflate the record.

Examination

The log screen is not a text interface but a query surface: filtering is done over dozens of fields in the network, request, WAF and taxonomy categories; CIDR matching and free expression queries are supported. The Learn status filter calculates whether a record has already been learned with the current rule set; the work remaining in the false positive cleanup is seen with a single filtering.

The scanning across the device scans the log trees of all the vServices in parallel; if the time budget runs out, instead of a half-finished result, a clean partial result and the information up to which date it is complete are returned.

Notification

A threshold is defined for the number of blockings and detections per second. Beyond this, the advanced notifications monitor the number of events accumulated within a time window in eight separate scopes (global, source address, source network, country, ASN, network type group, network type category, host header): targeted alarms such as "two hundred blockings in five minutes from a single country" are set up. A report filtered by the key that triggers the alarm can be attached to the alarm e-mail. The notifications go through four channels as e-mail, SMS, SNMP trap and interface notification.

Management and Operation

The whole of WAF is managed from the web interface; at no stage is it necessary to connect to the server with SSH, edit files or run commands. The components that carry the traffic have been deliberately kept thin for this purpose.

Rules without writing code Learning · OpenAPI · ready set

The rule set is learned from the traffic, similar paths are reduced to automatic patterns, it is produced from an OpenAPI document or a ready header rule set is applied with a single operation. A regular expression is needed only while an optional custom signature is being written; and that too is compiled with the engine in production and tried on a sample input before it is saved.

Uninterrupted application The connection is not dropped

Rule and setting changes do not require a separate deployment step; the configuration is reloaded without interruption, the open connections are not dropped. If a rule cannot be compiled, the protection continues to work with the last successful rule set and the problematic rules are marked in the interface.

Separation of authorization RBAC

Three separate roles are defined for WAF: full authorization, changing only on certain vServices and view only. Changing the signature layer across the device requires full authorization; the change authorization is enough for the vService layer. In this way, the authorizations of the security team and the application team are separated.

API and bulk operation Automation

Every screen has a REST and CLI counterpart; the settings, the host groups, the rules and the signature overrides are managed programmatically. With bulk operations, the setting of dozens of vServices, the mode of the host groups or the resetting of the rule set is done with a single call.

Reversibility Safe trial

The learned settings are reverted, the signature changes are returned to the default, the rule set of the host group is reset. The configuration can be exported and carried to another device and it is included in the backup per vService.

Audit trail Compliance

Every WAF operation, including adding, editing, deleting and merging a rule, applying and reverting learning, overriding a signature, bulk status change and import/export, is written to the user journal.

Behavior in the cluster

The WAF configuration and the rule set are synchronized automatically between the cluster members. The compiled signature database, on the other hand, is not synchronized: every device compiles the database suitable for its own processor itself. The learning runs on a single device but combines the records of both devices; the reports are also collected across the cluster.

Key Features

A comprehensive signature libraryMore than 10,000 signatures in 32 attack categories; with CWE, CAPEC, MITRE ATT&CK and OWASP mappings.

Full OWASP Top 10 coverageEvery item of the web and API lists is met with a signature or a structural rule.

Automatic learningThe site structure is learned from the live traffic; the rules do not have to be written manually.

Measurable learningLearning Coverage and Discovery Rate say with a number when blocking will be moved to.

Gradual deploymentLearning → Monitor → Blocking; the protection is matured without cutting the traffic.

An adjustable thresholdFive protection levels determine both the blocking threshold and which signatures will be loaded.

Host-based separationDifferent domain names on the same vService work in their own mode and rule set.

Field-based inspectionPath, Query, Header, JSON, XML, Form and the raw body are configured separately.

File upload inspectionThe content of the uploaded file is scanned, its real type is determined from the content; extension deception does not work.

Evasion-resistant parsingThe filter bypass ways with an encoded separator and a corrupted body are closed architecturally.

Setup with OpenAPIThe rule set is produced from the API definition or exported as a standard OpenAPI document.

IP reputation integrationThe categorized global blacklist and the lists specific to the vService are evaluated together.

Action-bound log examinationTeaching from the log line (Allow / Teach) and blacklisting are done in the same window.

Reporting with 22 breakdownsA report with six tabs; PDF and XLSX output, periodic e-mail sending.

SIEM-ready outputCEF and JSON log formats, attack detail selectable field by field, sampling per destination.

Targeted notificationWindowed thresholds on a country, ASN, source network or host basis; a filtered report attached to the alarm.

Uninterrupted applicationA rule change takes effect without dropping connections; in a compilation error the last working set remains.

Management that does not require SSHEverything from the web interface; file editing, command running or script knowledge is not needed.

Role-based authorization and audit trailThree WAF roles; every change is written to the user journal.

A customizable blocking pageThe content, the content type and the status code; different pages according to the condition.

A view across the deviceTwo separate screens that combine the logs and the reports of all the protected vServices.

Use Cases

Corporate web application protection Learning → Blocking

The protection is taken in front of an application in production without cutting the traffic: first it is learned, then it is monitored in a rehearsal, and afterwards blocking is moved to.

API security OpenAPI

By importing the API's own OpenAPI definition, the positive security model is set up directly from the document, without waiting for the traffic to be learned.

Publishing with multiple domain names Virtual Host Groups

Different domain names published over the same vService are divided into separate groups; while the mature application stays in blocking, the newly published domain name proceeds in the learning mode.

Intervention during an attack Event Logs · Notifications

When the number of blockings or detections per second exceeds the defined threshold, a notification is produced; the source, the category and the payload of the attack are examined from the log screen and the source address is added from the same window either only to the list of that vService or to the IP reputation list across the device.

Artificial intelligence service protection LLM Prompt Injection

The vService in front of an LLM-based application is protected against prompt injection, jailbreak patterns and system prompt extraction attempts with a separate signature category; these signatures are labeled with the MITRE ATLAS techniques and appear as a separate breakdown in the report.

A response specific to the attack Condition · Action

The triggering of a certain signature or signature group is used as a condition at the load balancing layer: that request can be redirected, marked or dropped to a separate page instead of being blocked. The WAF decision becomes the input of the traffic rule.

Compliance and reporting WAF Report · SIEM

The periodic reports are produced automatically and sent to the management by e-mail; the attack records are carried to the corporate SIEM system.

Terminology

Term	Description
WAF Mode	The operating mode of the host group: Learning, Monitor or Blocking.
Virtual Host Group	The group that divides the vService traffic according to the Host header and has its own mode and rule list.
Page Type	The combination of a path pattern and the inspections to be applied to that path; in the background it is a WAF rule.
Any Paths	The base rule applied to every request in the host group. When no page type matches, it is valid on its own; when a page type matches, it is combined with it. When it is removed from the list, it does not disappear, it is created again with its default definition; that is, the delete operation is a reset.
Check Fields	The inspections that a rule applies to the seven parts of the request (Path, Query, Header, JSON, XML, Form, RAW).
Signature	The counterpart of an attack pattern in a single request part on which it is inspected. If the same pattern works in more than one scope, it counts as more than one signature.
Attack score	The total risk score of the violations detected in the request.
OWASP Protection Level	The five-level setting that determines the threshold at which the attack score turns into blocking.
Learning log	The record to which the requests processed in the learning mode are written and which forms the source for the analysis.
Teacher	The source whose traffic is accepted as trusted. The requests of the teacher are never blocked even if the host group is in the Blocking mode; the shape of the request is taught to the rule set.
Disposition	The exit decision of a request from the WAF inspection. It appears as the Verdict column (Teacher, Monitor, Blocking) on the log screen and as seven categories on the monitoring screens.

Sections

Getting Started

How to Enable WAF?

Enabling the protection on a vService, the defaults that are created, the recommended first steps and the removal of the protection.

→

Monitoring and Management on a vService Basis

WAF-Protected vServices

The panel of a protected vService, all its WAF configuration, its logs, its live statistics and its learning monitoring.

→

Screens Across the Device

WAF-Protected vService List

The list of the protected vServices; turning the protection on and off collectively.

→

Signature & Rule Library

The signature and rule library; the rule layers, adding a custom rule and the compilation of the signature database.

→

Global WAF Event Log

The view in which the logs of all the protected vServices are collected in a single table.

→

Global WAF Report

A single WAF report across the device; the vService breakdown and the scheduled global sending.

→

Typical Deployment Flow

1

Step 1 Enable the protection

The WAF protection is turned on on the vService of the HTTP type; the default host group starts in the Learning mode, with the built-in rule set. The protection level comes as Very Tight, the blocking status code as 418, the structural and field inspections on and the static content skipping on (see How to Enable WAF?).

2

Step 2 Learn the traffic

Enough traffic to cover the ordinary usage cycle of the application is accumulated. In the Learning mode no request is blocked; the requests are written to the learning journal. The journal is kept with smart sampling by default: only the first few examples of the same request shape are recorded completely.

3

Step 3 Produce and apply the rule suggestions

Analysis & Learning is run; the page type and rule suggestions produced are examined and applied.

4

Step 4 Do a rehearsal in the Monitor mode

The host group is taken to the Monitor mode. The rule set works at full capacity but the request is not blocked; over Event Logs the false positives are cleaned with the teaching operation (Allow / Teach).

5

Step 5 Adjust the threshold and the exemptions

OWASP Protection Level is selected; the traffic that must stay out of the inspection and the sources to be blocked are defined with Whitelist & Blacklist. The blacklist exceptions are not a WAF exemption: they only cancel the blacklist hit, they do not leave the request out of the inspection. When the protection level Aggressive is selected, the default rule set is also produced with its tight attributes: a shorter path limit, a shallower path depth and permission only for the read methods.

6

Step 6 Move to blocking

When the log flow is cleaned, the host group is taken to the Blocking mode; the response that will return to the blocked client is arranged with Blocking Page.

7

Step 7 Set up the monitoring and the reporting

The notification thresholds for the number of blockings and detections per second, the periodic reports and the SIEM sending are configured; the protection is monitored continuously over Dashboard and Live Stats.