Products
ITCSECadmin consolidates DDoS protection, SIEM, NIS2 / KSC compliance, BGP management, AI network intelligence, traffic analysis, and peering optimization in one platform.
DDoS Protection
- Detection: 1–3 s on sFlow with dense sampling, 5–15 s on NetFlow with a 5–10 s active timeout — time-to-detect can never be shorter than the exporter's active timeout
- BGP blackholing, FlowSpec
- Integrations: FRR/BIRD and platforms from Cisco, Juniper, Huawei, EXOS, XOS, PICOS
SIEM & Compliance
- Real-time log parsing
- Alerting and incident workflows
- Correlates syslog events with NetFlow/sFlow data
NIS2 / KSC Compliance NIS2
- Art. 23-aligned incident reporting with automatic 24h / 72h / 1-month deadline tracking from detection
- Risk management with scoring and versioned security policies with staff acknowledgements
- Training registry with participant lists and a mandatory-training catalog
- Full audit trail of administrative actions — supports the Polish KSC act (national NIS2 implementation)
BGP Management
- Neighbor monitoring
- Routing table ingestion
- Automated routing policies
AI Network Intelligence
- Conversational assistant
- Trend detection
- MCP tool integration
Traffic Analysis
- NetFlow, sFlow, PCAP
- Advanced filtering & forensics
- TimescaleDB trending
Peering Optimization
- ASN analysis
- IXP intelligence
- PeeringDB integration
BGP FlowSpec
- Per-flow rules: drop or rate-limit
- Match by prefix, port, protocol, TCP flags, DSCP
- Automatic withdrawal and full rule history
BGP Traffic Diversion
- Divert attacked traffic without blackholing
- Auto-trigger on distributed attacks and auto-revert
- Selective advertisement via critical peers
Vulnerability Scanner
- Nmap-based CVE detection
- Monitoring of 55+ high-risk ports
- SIEM integration and email reports
Customer Portal
- Traffic charts and DDoS alerts for customers
- Downloadable PDF security reports
- Strict per-CIDR data isolation
Network Monitoring (NMS)
- SNMP interface monitoring with historical trends
- Service and uptime checks
- Time-series data in TimescaleDB
ITCare Carrier Routers — BGP, NAT/CGNAT, PPPoE/BNG
Linux routers with our own ITCbng dataplane that export exactly the telemetry DDoS detection needs and accept exactly the mitigation decisions it makes — absorbing the attack in the dataplane before it ever reaches NAT and your subscribers.
Shared hardware baseline
- Interfaces: 4× 10G (Base-T / SFP+), 2× 40G or 1× 40G (QSFP/QSFP+), 1× or 2× 100G (QSFP28)
- Mellanox ConnectX-6 Dx NICs — drop in NIC silicon (rte_flow/mlx5) before the packet ever touches the CPU
- Workers pinned CCD-locally to isolated cores out of the box — bad pinning costs 30% of throughput at 64 B, so we do not leave it to the customer
- No hard RIB/FIB or session-table ceiling — capacity follows RAM, not TCAM
- The telemetry detection actually needs: NetFlow/IPFIX and sFlow at a short active timeout, advertised sampling rate, ingress interface and source MAC in the record, 64-bit SNMP, remote syslog
- CoPP — BGP sessions and management access stay alive under attack
- OOB management, text configuration pullable over SSH with no agent
Why the router decides whether protection works
Most anti-DDoS deployments at regional operators fail not because the detection algorithm is weak, but because the router does not surrender the data detection needs and does not accept the mitigation result. We close that loop: the forwarding layer (the router) and the control layer (ITCSECadmin) are designed together.
The symptoms we find in operator networks
- flow export at a 1800 s active timeout — the attack shows up half an hour later, not in seconds
- the exporter does not advertise its sampling rate — counters are off by an order of magnitude
- no ingress interface and no source MAC in the record — you cannot point at the port emitting spoofed traffic
- the only available response is a blackhole — finishing the attack on the attacker's behalf
- no NAT translation logs — when law enforcement asks, you cannot identify the subscriber
- 32-bit SNMP counters — they wrap every ~34 seconds on a 10G link
Our answer — measured on the ITCbng router
- 40.2 Mpps at 64-byte packets — with NAT enabled (address translation in the path), 8 worker cores
- 98.57 Gbit/s at 1500 B — line rate on a 100 G link, also with NAT in the path
- A ~10.3 Mpps attack absorbed while forwarding normal traffic — the router did both at once, and subscribers lost 0.0% of their packets
- ~40 CPU cycles to drop an attack packet versus ~350 cycles to traverse NAT — which is why the attack never reaches subscribers
- 21.5 µs of dataplane latency, 2,000,000 NAT sessions in the test configuration
BGP / border router
The boundary with transit and peering, and the enforcement point for mitigation.
- Full BGP table, IPv4 and IPv6 over one MP-BGP session, no hard FIB ceiling
- RTBH — cutting off traffic to a single address, IPv4 and IPv6, plus BGP FlowSpec (RFC 8955 / 8956) — drop and rate-limit in kbps
- Selective prefix advertisement: withdraw from chosen neighbors while staying advertised to critical peers
- uRPF / BCP38 per interface in both address families, RPKI ROV, prefix limits, BFD
- Mitigation rules accepted directly from ITCSECadmin, with automatic withdrawal when the threat expires
NAT / CGNAT router
Conserving IPv4 space and identifying a subscriber on a law-enforcement request.
- 2,000,000 NAT sessions in the test configuration — more sessions means more RAM, not replacing silicon
- Deterministic NAT / Port Block Allocation (PBA) — the log becomes one line per subscriber instead of one per session
- Translation logging for retention, and reverse lookup: public address + port + timestamp → subscriber
- EIM/EIF and hairpinning (RFC 4787), per-subscriber port limits, exclusions and static 1:1 NAT
- The attack filter sits in front of NAT — measured 40.2 Mpps @ 64 B with NAT in the path
PPPoE concentrator / BNG
Subscriber session termination, policy enforcement, billing-grade accounting.
- RADIUS: authentication, accounting with interim updates, CoA and Disconnect (RFC 5176) — change a tariff without touching the router
- Per-session QoS from RADIUS attributes, hierarchical queueing, shaping in both directions
- IPv6 IA-NA + IA-PD over PPPoE, DHCPv6 and RA — prefix delegation to the CPE
- 500 VLANs in the test configuration, QinQ, PADI rate limiting and per-port session limits
- Per-session anti-spoofing, MSS clamping and a correct 1492 MTU, LCP echo tuning
- We measure session establishment rate for your configuration — ask for sessions per second during recovery from a power outage
Each of the three routers works on its own. The active DDoS protection layer described below is an option you can add to any of them.
Active DDoS protection layer
Two layers with different properties and different operating conditions. We separate them because the stateful layer's precondition is something you need to know before you buy, not after an incident.
Stateless layer — always available
Works regardless of traffic symmetry; it does not need to see both directions of a session. It drops by signature and by limit, at the WAN ingress, ahead of NAT. This is the layer that stops a volumetric attack.
- BCP38 / uRPF — per-interface anti-spoofing, full IPv4 and IPv6
- TCP flag policer (SYN
0x02, SYN+ACK0x12) with a kbps and burst limit — the answer to SYN+ACK carpet bombing - Fragment dropping — fragment-0 with a truncated L4 header and orphan fragments, with reassembly-table tuning
- DNS amplification dropping — UDP from source port 53 above 768 B, with a permit class for trusted resolvers
- Drop in NIC silicon (mlx5 rte_flow) — surgical, by address and attack characteristic, instead of blackholing a whole subnet
- RTBH and FlowSpec at the edge, with rate-limiting in kbps, not only dropping
- CoPP and rate-limited ingress filters
Honestly: the stateless layer does not understand sessions — without state it cannot tell a single legitimate SYN-ACK from a reflected one, so it defends by limit and signature. Thresholds always need tuning to the customer's traffic volume. We do that at deployment, using the method: baseline phase → attack → recovery, sampled every second.
Stateful layer — proven, measured
This is a scrubbing centre running inside your own device. Connection tracking admits only packets belonging to an established session — precisely the work you would otherwise pay an external scrubbing centre to do. A reflected SYN+ACK carpet bomb is rejected outright here, because there never was an outbound SYN.
- No traffic redirected through someone else's network, no round-trip latency penalty, no per-Gbps fees
- Reflexive ACL / connection tracking at line rate — the decision needs no signature and no threshold tuning
- Legitimate traffic passes uninterrupted; a packet outside any session goes nowhere
- Sessionless vectors — UDP fragments, DNS amplification — are handled by the stateless layer in front of it; together they give full coverage
Stateful protection must see the entire session, in both directions. It works on a single device that both directions traverse, or on 2–3 of our devices kept in sync.
On an asymmetric multi-homed edge — where traffic leaves via one router and returns via another — stateful protection without synchronization would drop legitimate traffic. At a real customer we measured 97% asymmetry on such an edge. There, the stateless layer defends. We tell you which case is yours before you buy.
Why your subscribers never notice the attack
An attack does not need to fill your link to bring the network down — it only needs to force the router into expensive work on every single packet. What matters is how early the router gets rid of it. We do that right at the start, before the packet reaches the most expensive stage of processing.
| What the router does with the packet | Cost | Effect |
|---|---|---|
| Dropping the attack in our filter, ahead of NAT ingress classifying filter | ~40 CPU cycles | the attack disappears almost for free |
| Letting the packet through NAT address translation | ~350 CPU cycles | ~9× more expensive — this is where an attack flattens a router |
That near-ninefold difference decides everything. We drop the attack at the door, so instead of choking on it the router simply discards it: 7.8 Mpps of SYN+ACK attack vanishes and your subscribers keep watching their film. In testing, 5 Mpps of attack leaves roughly 21 thousand packets per second behind the filter — the rest gets nowhere.
Where does that headroom come from? Our routers are software on a standard server, so performance grows with the core count — need more, add cores. Devices built around a fixed chip have their ceiling cast into silicon, and those running on an ordinary processor without our optimisation choke on exactly the small packets an attack is made of. In practice: the equipment behind our border — Cisco ASR, MikroTik, any customer router — survives the attack because we stop it earlier. At the attack profile we measured, and subject to the condition stated above.
Performance — measured numbers
We do not sell Gbps; we sell pps at the attack profile. A 10 Gbit/s SYN flood is as many packets as 45 Gbit/s of production traffic (64 B versus ~390 B) — a box benchmarked on large packets can fall over under a ten-gigabit attack.
| Packet size | Mpps | Throughput |
|---|---|---|
| 64 B (attack profile) | 40.2 | 27.0 Gbit/s |
| 512 B | 19.94 | 84.88 Gbit/s |
| 1500 B (bulk transfer) | 8.11 | 98.57 Gbit/s ≈ 100 G line rate |
Every figure was measured with NAT in the path — this is not bare forwarding but the full work the router does in production. 8 worker cores, AMD EPYC 4564P, 2× 100 G NICs. Measured end to end: every packet counted on the way out and again on the way back in, with not one lost. The design requirement at 64 B was 15 Mpps — the result is 2.7× higher.
- You scale with cores, not by replacing hardware. At the router's egress we measured 38 Mpps on 4 cores, 48 on 6 and up to 60 on 8. You pick the core count for your volume — the S, M and L variants differ in cores, memory and NICs.
- At 1500 B we saturate a 100 G link with NAT in the path — 98.57 Gbit/s measured.
- 21.5 µs of latency through the router, against a requirement of under 100 µs.
- Under a ~10.3 Mpps attack, subscriber traffic was delivered without any disruption — 0.0% subscriber packet loss, with no drop in forwarding.
- Correct pinning is part of the product, not the customer's job. A badly pinned worker costs 30% of throughput at 64 B — our routers handle it out of the box.
The signatures we handle — from production, not from a lab
Attacks measured in production, on live ISP traffic, on 10–11 August 2026. For testing we replay them 1:1 with TRex profiles, using the method: baseline phase with subscriber traffic, attack overlay, recovery phase — sampled every second.
| Vector | Signature | Production peak | Our response |
|---|---|---|---|
| SYN+ACK reflection carpet bomb | TCP flags 0x12, 59 B, 33,964 sources, 256 addresses per /24 | 7.8 Mpps 3.6 Gbit/s | TCP flag policer ahead of NAT, stateful layer (drop with no preceding SYN), drop in NIC silicon |
| UDP fragments "port 0" | fragment offset ≠ 0, ~1240 B | 137,870 pps 1.4 Gbit/s | orphan-fragment dropping and reassembly tuning ahead of NAT |
| DNS amplification | UDP from source port 53, 1488 B | 74,476 pps 887 Mbit/s | drop UDP/53 above 768 B, permit for trusted resolvers |
| UDP flood | UDP to destination port 80, ~1400 B | 87,306 pps 997 Mbit/s | hard drop by ACL class ahead of NAT |
All four vectors were filtered with no measurable CPU load and with no disruption whatsoever to subscriber traffic. The filter discards an attack packet at ~40 CPU cycles, ahead of NAT — which is why router load barely moved and subscribers never felt the attack was happening.
A metric measured during an attack says nothing about legitimate traffic — we always compare it against the baseline phase.
How to buy a router — and how to hold these questions against us
A datasheet settles less than the answers to a few specific questions. We put together a list of twelve worth sending with any RFQ, to every vendor — ourselves included. Here are the seven that matter most:
- How many pps at 64-byte packets, with NAT, queueing and flow export enabled?
- What is the lowest supported flow-export active timeout, and what does setting it to 5 seconds cost?
- Does the exporter advertise its sampling rate, and does the flow record carry the ingress interface and source MAC?
- What is the FIB limit — not the RIB — and is it shared between IPv4 and IPv6?
- What happens to BGP sessions under 10 Mpps addressed to the router itself?
- How many concurrent NAT sessions, and at what establishment rate in conn/s?
- How many PPPoE sessions per second during recovery from a power outage?
We answer every one of them with a number or a measurement. Ask for a demonstration — we will show you pps at 64 B and sessions per second on the bench.
Ask about configuration and measurements