ITCSECadmin

BGP FlowSpec

Surgical mitigation without blackholing — BGP FlowSpec rules (RFC 5575) injected directly to upstream peers. Drop or rate-limit only the attack traffic, while legitimate traffic to the same IP continues uninterrupted.

• Per-flow rules — match by destination/source prefix, protocol, port, TCP flags, DSCP, and fragmentation
• Drop / rate-limit actions — null-route only matching flows or limit kbps per BGP neighbor
• Per-threshold mitigation mode — blackhole, flowspec, both, or none
• Non-blocking injection queue — the detection pipeline never waits for BGP announcements
• Automatic withdrawal — rules expire after a configurable lifetime once the threat subsides
• Full per-neighbor, per-rule status — pending / active / withdrawn / failed, with manual inject/withdraw controls
• Configuration generator — one-click config preview and write, plus a real-time CLI connectivity test
• No scrubbing center — no extra fees or third-party licensing

BGP Traffic Diversion

Redirect attacked prefixes to a scrubbing path or alternative path without complete blackholing. Support for multiple routing platforms.

• Three ways to redirect traffic — from fully withdrawing the attacked network to selectively holding it back from chosen providers
• Audited SSH — execution of SSH commands with live output preview
• Auto-Trigger — automatic diversion policy activation upon distributed attack detection
• Auto-Revert — automatic policy rollback after a configurable time window
• CIDR Confirmation — mandatory CIDR range confirmation gate
• Per-peer selection — select from which eBGP peers to withdraw the prefix
• One-click Divert — direct button in the Distributed Alerts dashboard
• Policy duplication — copy a policy to multiple routers with one click
• Event history — full audit trail with SSH output
• Intelligent selective advertisement — the attacked prefix stays reachable through critical peers (Google, Meta, Akamai, Amazon, Cloudflare) via a maintainable ASN allowlist, and is withdrawn only from everyone else
• Multi-vendor — Linux FRR, Huawei NE8000 (VRP), and Cisco ASR (IOS-XE)

Bunker Mode

Attacks no longer target a single address — they come at entire address ranges at once. A /32 blackhole achieves nothing then, and withdrawing the whole prefix means your subscribers lose the internet. Bunker mode answers that scenario: you deliberately cut the network off from the BGP world while customers keep their internet over a backup link. That is the difference between a bunker and switching your own network off. It is a joint capability: ITCSECadmin makes the decision, the routers carry it out.

Three legs that have to work together

• Outbound to the world — decided per BGP session. For each peer separately you pick one of three routes: keep (the session advertises as normal, we leave it alone), tag it (we add a marker to the advertisement that makes the upstream provider cut the traffic itself — taken from a catalogue of verified policies, never guessed) or stop advertising (the attacked network disappears from that one session while every other session stays untouched). The choice has to be per peer: a transit provider only needs the withdrawal, whereas at an exchange you cannot force the withdrawal from your own side — there, only tagging the advertisement works.
• Cutting the import — this is the actual switch. A rule rejecting routes arriving from that provider is added to the peer's inbound policy, and the table is then refreshed. The router stops accepting world routes from the upstream. Without this step the router still holds a full BGP table, traffic never falls back to the default route and NAT never engages at all — which is why the system refuses to activate if this element has not been prepared in advance. We never guess where to place it in the policy — landing on an occupied slot would overwrite existing configuration.
• Emergency exit through NAT. A static route at preference 254 to the last-resort link, plus NAT to a small public pool. You disconnect from the world in BGP terms while customer traffic leaves over the backup link.

Arming is not activation

You arm it in peacetime: the NAT instance, ACL, address pool, static route and the ready-made rejection rule are all created ahead of time and stay inert — preference 254 loses to any BGP route, so not a single packet reaches NAT. You activate it under attack: the import cut first, then the outbound actions. The order is enforced in code rather than left to the operator, and it is reversed on the way back so that visibility from the world returns before the routes do.

Safeguards

• An unarmed profile cannot be activated
• Starting is blocked while another event is already running on the same router — a diversion, an advertisement tagging action or a bunker — because they compete for the same slots in the policies
• The automatic revert never disarms the router when a timer expires; it withdraws only what it switched on itself
• Automatic activation on link saturation is off by default and requires an explicitly configured revert window

Limits worth knowing before deployment

• Supported platforms: Huawei NE8000 and FRR. Cisco ASR and Juniper MX are not supported — you get a clear message rather than an error in the middle of an attack
• FRR does not support the NAT leg, and that is deliberate. On Linux, address translation lives outside the routing layer; a router reporting itself as armed with no working translation would be worse than not having the feature. FRR does handle both routing legs, which makes it suitable for rehearsing the switchover itself — and it is the only place where that can be done safely
• NAT is IPv4 only
• One profile covers one router

SIEM and NIS2 / KSC Compliance

NIS2 is the directive; the Polish KSC Act (uKSC) is the law that implements it — and it is the Act, not the directive, that binds a Polish operator. The scope is the same but nationally specified: reports go to the relevant CSIRT through the national system, entities must be entered in the register of essential and important entities, training is mandatory and the management body is accountable. Providers of public electronic communications networks and services are covered regardless of the size thresholds that exempt parts of other sectors — a small operator is in scope too.

Compliance is an organisational process and no system can deliver it for you. What audits usually catch, however, is missing evidence and missed deadlines — and that part we take off your hands.

Compliance module and SIEM — features

• Incident reporting — compliant with Art. 23 NIS2, tracking 24h / 72h / 1 month deadlines
• Policy management — versioned security policies
• Risk management — risk assessment framework with a scoring system
• Training log — security training tracking
• Audit logs — tamper-evident logging of all security actions
• Log collection — Syslog collector (RFC 3164/5424) for multi-vendor devices
• Multi-vendor parsers — dedicated parsers for Juniper JunOS (UI_COMMIT, UI_AUTH, BGP session states, link up/down), Cisco IOS/IOS-XE, and Linux syslog, with a generic RFC 3164 fallback
• Correlation — link syslog events with NetFlow/sFlow traffic data
• Rule engine — PCRE pattern matching with severity levels
• Notifications — real-time alerts via email and webhook

BGP and Peering Management

• Configuration sync — agentless — direct SSH config pull from Huawei NE8000, Cisco ASR, and Juniper MX routers, plus agent-based sync for Linux FRR
• Dynamic peer mapping — automatic BGP neighbor to physical interface matching
• Diagnostics — automatic ARP, interface connectivity checks
• Bandwidth monitoring — per-interface bandwidth charts with VLAN-tagged flow support
• Routing policy analysis — a readable view of rules, priorities and deliberate path lengthening across FRR, NE8000, ASR and Juniper MX, separating rules that always apply from those switched on conditionally
• Billing and bandwidth — 95th percentile, CIR, and PIR tracking per peer
• SSH Terminal — secure, audited web access to routers
• Configuration backup — versioned backups with unified diff
• Routing table — efficient full table (1M+ routes) handling

Network Monitoring (NMS)

• SNMP interface monitoring — per-interface counter polling (bits/packets, errors, utilization) with historical trend charts
• Per-device dashboards — interface tables and link status at a glance
• Service & uptime checks — track availability of monitored services with full result history
• Time-series storage — interface counters and check results persisted in TimescaleDB for long-term trending

Network Vulnerability Scanner

• CVE Detection — Nmap-based scanning with vulnerability detection
• Port scanning — monitoring of 55+ high-risk ports
• Parallel processing — batch engine for large network ranges
• SIEM integration — vulnerabilities automatically generate security events
• Reports — automated email reports grouped by severity

Customer Portal (ISP/IXP Edition)

• Traffic visibility — customers see their own network traffic charts and stats
• DDoS alerts — attack history on customer prefixes
• PDF Reports — downloadable security reports
• Data isolation — strict data separation based on assigned CIDRs

Network Traffic Analysis

• Multi-protocol support — NetFlow v5/v9/IPFIX, sFlow, PCAP
• Advanced search — filtering by IP (CIDR), port, protocol, ASN, geolocation, and time range
• Top talkers — identification of largest traffic sources
• Interactive visualization — Grafana-style zoom
• Sankey diagrams — network traffic distribution visualization
• Forensic analysis — on-disk flow log searching (nfdump)
• CGNAT Lookup — reverse-lookup of NAT translations
• Data export — CSV, JSON, PDF

AI Assistant

• Natural language queries — questions about network status, historical analysis, trend identification
• Automated troubleshooting — diagnostic and operational support
• MCP integration — extensible tool system: Traffic Search, CGNAT Lookup, BGP Status, Vulnerability Analysis
• Full natural-language router management — for ITCbng routers — diagnostics and troubleshooting, BGP, NAT and PPPoE configuration, creating and changing subscriber services, inspecting sessions, policies and neighbour state. Instead of writing configuration you describe what should happen; changes take effect only once an operator approves them.
• Supported AI backends — ITCare AI API and internal secure network AI servers