Network Vulnerabilities (CVE)

The Network Vulnerabilities (CVE) plugin replays network scenarios from the PTI library. Use it to test IDS/IPS, NGFW, WAF, NDR, and other detection systems. Run these scenarios only in an isolated test environment.

Before configuring a task, upload or update the database under Library → Network Vulnerabilities (PTI), or under Settings → Network Vulnerability Package (PTI), and synchronize the agents. CVE cards show the CVE ID, product, version, protocol, CVSS score, description, and available replay variants.

Figure 19 — Attack / FP mode and CVE selection in the constructor

Table 186 — CVE Replay settings in the constructor

Name	Description	Value
Attack emulation mode / False-positive test mode	attack generates exploit traffic; false_positive generates legitimate traffic that resembles an attack to test IPS/IDS false positives	Changing the mode clears the selected CVEs
First scenario / All scenarios	Coverage: one supported scenario for each CVE or all scenarios for every CVE	Radio
Select network vulnerabilities	Selection dialog backed by the PTI library	Shows CVEs selected and Scenarios to run
Step timeout	Terminates the connection if the current step makes no progress for longer than the configured period; classified as blocked_timeout. 0 disables the limit	0–300 seconds; default: 30
Session settings / TLS / Duration / Tunnels	Common stateful tabs	Same as for other L7 plugins

The plugin is available as both a client and a server for two-arm operation. The client replays the exploit/FP exchange; the server responds according to the scenario on the Peresvet ST side.

CVE dashboards by mode and coverage

The Metrics tab displays only the dashboard that matches the task's parameter combination:

Dashboard in the UI	Key	Condition
Network Vulnerabilities (CVE)	cve_replay	Attack + first scenario
Network Vulnerabilities (CVE, all scenarios)	cve_replay_all	Attack + all scenarios
Network Vulnerabilities (CVE, FP mode)	cve_replay_fp	False positive + first scenario
Network Vulnerabilities (CVE, FP mode, all scenarios)	cve_replay_fp_all	False positive + all scenarios

On attack dashboards, review the Passed / Blocked CVEs summary, the table of passed CVEs, and the client/server CVE Attempts panels. In FP mode, the same outcomes indicate whether the FP exchange completed or was interrupted.

Interpreting the result

CVE Replay uses the reverse polarity of Dynamic Applications:

Outcome	Meaning in an IPS/NGFW test
completed	The scenario reached the end (steps_done), meaning the exploit or exchange passed through the security device. In an IPS test, this is usually bad
blocked_*	The scenario was interrupted before completion, meaning the security device or network path prevented the exchange from completing. In an IPS test, this is usually good

Do not confuse a successful Peresvet ST scenario with successful protection. Base the final assessment on the selected CVE dashboard, DUT events, and task logs.

Attempt outcomes (outcome)

Every attempt receives one outcome. On the CVE Attempts panels, the same values may be labeled Successful / RST / SYN drop / Timeout / Incomplete CVE / orphan.

Table 187 — CVE Replay outcomes

Outcome	When it is assigned	Interpretation
completed	All scenario steps completed	The exchange was replayed to completion
blocked_rst	An RST arrived before steps_done	The path or DUT explicitly terminated the connection, typically by blocking with RST
blocked_syn	The TCP handshake timed out (SYN_TIMEOUT)	The connection was not established; the SYN or handshake was blocked or lost
blocked_timeout	A step timeout occurred: STEP_TIMEOUT for TCP or UDP_TIMEOUT for UDP	No progress was made at the current step for longer than the configured Step timeout
blocked_orphan	The scenario did not reach steps_done, but the closure was not caused by RST or a step/UDP timeout	Incomplete attempt: TCP retransmissions exhausted, a nominal close occurred before all steps completed, the socket closed without an explicit RST/timeout reason, or remaining connections were cleared at the end of the task

blocked_timeout and blocked_orphan with silent drops

Both outcomes often indicate that the path was interrupted without an RST, but they represent different mechanisms:

• blocked_timeout is the plugin's explicit per-step idle timer. The connection is still considered alive, but the current step makes no progress, such as no scenario advancement or response, until STEP_TIMEOUT or UDP_TIMEOUT fires.
• blocked_orphan means the scenario did not complete and the connection ended for another reason. In a typical IPS silent-drop case, the step was sent but no ACK or response arrived, TCP exhausted its retransmissions (RETX_CLOSE and similar), and the socket closed. This category also includes nominal FIN/closure before all steps complete, socket closure without an explicit RST/timeout, and cleanup of incomplete or unstarted connections at task shutdown.

Silent drop: orphan is not a step timeout

For an IPS silent drop, review both counters: orphan approximately means termination after TCP retransmissions, while timeout means the per-step timer configured by Step timeout. Do not combine them as if they represented the same signal, and do not treat orphan as simply another timeout.

Using the dashboards

• Attack mode: an increase in completed / Passed CVEs identifies scenarios allowed through by the security device. The sum of blocked_* / Blocked CVEs identifies scenarios that did not complete.
• CVE Attempts: breaks blocking outcomes down by cause (blocked_rst, blocked_syn, blocked_timeout, blocked_orphan) on the client and server sides.
• FP mode: completed means the legitimate FP exchange completed; blocked_* means the exchange was interrupted, which may indicate a false positive or a broken path. Interpret this together with the DUT policy.
• Correlate outcomes with DUT logs and events and, when necessary, with packet captures (PCAP) on the agents. An RST appears as blocked_rst, while a silent drop more commonly appears as blocked_timeout or blocked_orphan.