HabrJuly 21, 2026🇷🇺Translated from Russian

How Ideco Measures NGFW Performance Using TRex ASTF and RFC 9411 Methodology

Ideco has shared a comprehensive look at how its engineering team measures the performance of Ideco NGFW Novum on the Ideco EX platform. The article explains why raw performance numbers are meaningless without a clearly documented methodology and describes every parameter used in their lab tests.

Why Performance Numbers Vary Across Tests

The same NGFW device can produce very different results on two different test beds even when both tests are honest. Performance depends on packet size, enabled security functions, number of rules, test duration, and the acceptable loss threshold. Ideco therefore publishes its full methodology so that any reader can reproduce the measurements and understand exactly what each figure represents.

Traffic Generator and Test Modes

The team selected the open-source TRex generator running in ASTF (Advanced Stateful) mode. This choice enables realistic TCP session handling and L7 emulation, which is essential for testing stateful inspection engines. Stateless mode is used only for raw UDP throughput tests with 1518-byte frames. When TLS decryption is enabled on the firewall, the team switches to the hardware-based Keysight BreakingPoint system.

Test Bed Configuration

Both the device under test and the traffic generator use identical server hardware:

  • CPU: Xeon Gold 6338N
  • RAM: 128 GB
  • NICs: Intel E810 2xQSFP28 (100 Gbps)

The topology is a simple two-port setup with TRex port 0 connected to the DUT and TRex port 1 returning the traffic.

Key Metrics and Traffic Profiles

The methodology measures four primary metrics: throughput in Gbit/s, connections per second (CPS), concurrent connections (CC), and latency. Tests are performed with the following profiles:

  • UDP 1518-byte frames (raw L2/L3 ceiling)
  • TCP/HTTP with 64 KB objects
  • TCP/HTTP with 16 KB objects
  • EMIX mixed corporate traffic
  • TCP CPS and TCP CC specific tests

All tests run with a fixed set of firewall rules, IPS signatures, and application control profiles. TLS decryption remains disabled during these runs.

Loss Criterion and Test Duration

Loss is defined as dropped sessions rather than individual packets. The formula uses TRex counters for TCP connection drops, established session drops, and UDP keepalive drops. A test point passes only when session loss stays at or below 1 %. Each load point is held for 300 seconds after a 30-second ramp-up phase to reveal queue buildup, memory pressure, and thermal effects that short bursts would miss.

Results Summary

On the Ideco EX platform the measured maximums are:

  • UDP 1518 B: 200 Gbit/s
  • TCP/HTTP 64 KB: 100 Gbit/s
  • TCP/HTTP 16 KB: 62 Gbit/s
  • EMIX (firewall only): 92 Gbit/s
  • EMIX + IPS: 31 Gbit/s
  • Full NGFW stack: 15.5 Gbit/s
  • TCP CPS: 800 000 new sessions per second
  • TCP CC: 21 000 000 concurrent sessions

The article concludes that performance is always a range that depends on the actual traffic mix and enabled security functions. Full configuration files and commands are provided so the community can replicate the tests.

Related articles

SecuritylabOther

Why Automation Alone Fails to Improve SOC Efficiency: The Case for Managed Operational Models

Mature security infrastructure does not guarantee protection against cyber threats, as attacks can still cause downtime, crisis recovery, and financial damage even when key controls are deployed. Automation of routine tasks helps speed up responses but cannot raise SOC effectiveness without clear decision criteria, defined responsibilities, and repeatable incident-handling processes. Organizations using an average of 83 security tools from 29 vendors face fragmentation that automation alone cannot resolve. A managed SecOps model covering the full incident lifecycle—from detection and prioritization through investigation, response, closure, and post-incident improvement—is required. Positive Technologies highlights that SecOps platforms such as MaxPatrol 360 provide the unified environment needed to link context, processes, coordination, automation, metrics, and continuous improvement.

HabrOther

Building a Minimalist UI Test Framework with Playwright and Pytest

Vladislav Timashenkov from InfoWatch presents a practical approach to constructing a concise UI automation testing framework using Playwright. The article focuses on leveraging native Playwright features instead of creating additional abstraction layers. It covers launching a Chromium browser once per session, handling authentication via API calls to obtain cookies, and managing isolated BrowserContext instances for test independence. Readers learn how to implement Page Object models that rely on Playwright's built-in locators and auto-waiting mechanisms. The tutorial includes real code examples for fixtures, context factories, and a sample test for tag management functionality. This method reduces maintenance overhead while ensuring tests remain scalable across different environments.

AntiMalwareOther

Russia Develops Domestic ERA-GLONASS System for Public Transport Tracking During GPS and GLONASS Disruptions

AO GLONASS has created a national system that maintains real-time monitoring of buses and trolleybuses even when satellite navigation signals are jammed or lost. The solution relies on the state-run ERA-GLONASS platform, placing autonomous markers at stops and identifiers on vehicles to record exact positions without depending on GPS or GLONASS. Data is transmitted over a protected ERA-GLONASS communication channel that remains available during mobile internet restrictions thanks to inclusion in official white lists. The first deployment begins in Kaluga on 1 September, covering three trolleybus routes with live tracking for passengers, dispatchers, carriers, and mapping services. The battery-powered markers are designed for five years of maintenance-free operation in any weather and are built entirely with Russian components and encryption algorithms. Future plans include extending the technology to municipal vehicles and emergency services fleets.

HabrOther

OSINT for the Lazy Part 16: Discovering Hidden Corporate Infrastructure Through Shodan

The article explains how Shodan differs from traditional search engines by indexing internet-connected devices such as servers, routers, cameras, databases, and admin panels rather than web pages. It provides ten practical search techniques including hostname queries, SSL certificate searches, ASN lookups, IP range scans, and targeted queries for development environments, admin panels, and databases. Examples demonstrate how forgotten dev.company.com or staging.company.com hosts, open Jenkins or Grafana dashboards, and exposed MongoDB or Redis instances can be located with simple filters. The piece walks through a five-step real-world workflow that combines domain, SSL, organization, and service-title searches to map a target company’s infrastructure. It emphasizes that Shodan only reveals services already exposed to the internet and does not perform any exploitation. Common root causes listed include forgotten test servers, rushed DevOps configurations, and misconfigured firewalls. The article concludes with a reminder that many organizations remain unaware their internal systems are visible to anyone using the same techniques.