Produkty
ITCSECadmin konsoliduje ochronę przed DDoS, SIEM, zgodność NIS2 / KSC, zarządzanie BGP, inteligencję sieciową AI, analizę ruchu i optymalizację peeringu w jednej platformie.
Ochrona DDoS
- Detekcja: 1–3 s na sFlow z gęstym samplingiem, 5–15 s na NetFlow z aktywnym timeoutem 5–10 s — czas wykrycia nie może być krótszy niż aktywny timeout eksportera
- BGP blackholing, FlowSpec
- Integracje: FRR/BIRD oraz platformy Cisco, Juniper, Huawei, EXOS, XOS, PICOS
SIEM i Zgodność
- Parsowanie logów w czasie rzeczywistym
- Alerty i workflow incydentów
- Korelacja zdarzeń syslog z danymi NetFlow/sFlow
Zgodność NIS2 / KSC NIS2
- Raportowanie incydentów zgodne z Art. 23 NIS2 — automatyczne pilnowanie terminów 24h / 72h / 1 mies. od wykrycia
- Zarządzanie ryzykiem z oceną punktową i wersjonowane polityki bezpieczeństwa z potwierdzeniami pracowników
- Rejestr szkoleń z listą uczestników i katalogiem szkoleń obowiązkowych
- Pełny dziennik audytowy działań administracyjnych — wsparcie wymogów ustawy o KSC (polskiej implementacji NIS2)
Zarządzanie BGP
- Monitorowanie sąsiadów
- Ingestion tablicy routingu
- Automatyczne polityki routingu
Inteligencja sieciowa AI
- Asystent konwersacyjny
- Wykrywanie trendów
- Integracja narzędzi MCP
Analiza ruchu
- NetFlow, sFlow, PCAP
- Zaawansowane filtrowanie i forensics
- Trendy TimescaleDB
Optymalizacja peeringu
- Analiza ASN
- Inteligencja IXP
- Integracja PeeringDB
BGP FlowSpec
- Reguły per-flow: drop lub rate-limit
- Dopasowanie: prefiks, port, protokół, flagi TCP, DSCP
- Automatyczne wycofanie i pełna historia reguł
BGP Traffic Diversion
- Dywersja atakowanego ruchu bez blackholingu
- Auto-trigger przy atakach rozproszonych i auto-revert
- Selektywne rozgłaszanie przez peerów krytycznych
Skaner podatności
- Detekcja CVE oparta na Nmap
- Monitoring 55+ portów wysokiego ryzyka
- Integracja z SIEM i raporty e-mail
Portal klienta
- Wykresy ruchu i alerty DDoS dla klientów
- Raporty bezpieczeństwa PDF do pobrania
- Ścisła izolacja danych per CIDR
Monitoring sieci (NMS)
- Monitoring interfejsów SNMP z trendami historycznymi
- Kontrole usług i dostępności (uptime)
- Dane time-series w TimescaleDB
Routery operatorskie ITCare — BGP, NAT/CGNAT, PPPoE/BNG
Routery na Linuksie z własnym dataplane ITCbng, które eksportują dokładnie tę telemetrię, jakiej potrzebuje detekcja DDoS, i przyjmują dokładnie te decyzje mitygacji, które ona podejmuje — a atak pochłaniają w dataplane, zanim dojdzie do NAT-u i abonentów.
Wspólna baza sprzętowa
- Interfejsy: 4× 10G (Base-T / SFP+), 2× 40G lub 1× 40G (QSFP/QSFP+), 1× lub 2× 100G (QSFP28)
- Karty Mellanox ConnectX-6 Dx — drop w krzemie karty (rte_flow/mlx5), zanim pakiet dotknie CPU
- Workery przypięte CCD-lokalnie do izolowanych rdzeni z pudełka — złe przypięcie kosztuje 30% wydajności przy 64 B, więc nie zostawiamy tego klientowi
- Bez sztywnego limitu RIB/FIB i tablicy sesji — pojemność idzie za RAM, nie za TCAM
- Telemetria, której faktycznie potrzebuje detekcja: NetFlow/IPFIX i sFlow z krótkim aktywnym timeoutem, ogłaszany sampling rate, interfejs wejściowy i source MAC w rekordzie, SNMP 64-bit, syslog zdalny
- CoPP — sesje BGP i dostęp zarządczy żyją pod atakiem
- Zarządzanie OOB, konfiguracja tekstowa pobierana po SSH bez agenta
Dlaczego router decyduje o skuteczności ochrony
Większość wdrożeń anty-DDoS u regionalnych operatorów zawodzi nie przez słaby algorytm detekcji, tylko dlatego, że router nie oddaje danych potrzebnych do detekcji i nie przyjmuje wyniku mitygacji. Domykamy tę pętlę: warstwa przekazywania (router) i warstwa sterowania (ITCSECadmin) są projektowane razem.
Objawy, które widzimy w sieciach operatorów
- eksport flow z aktywnym timeoutem 1800 s — atak widoczny po pół godzinie, nie po sekundach
- eksporter nie ogłasza sampling rate — liczniki przeskalowane o rząd wielkości
- brak interfejsu wejściowego i source MAC w rekordzie — nie da się wskazać portu ze sfałszowanym źródłem
- jedyną dostępną reakcją jest blackhole — czyli dokończenie ataku za atakującego
- brak logów translacji NAT — po wniosku służb nie da się wskazać abonenta
- 32-bitowe liczniki SNMP — na łączu 10G przekręcają się co ~34 sekundy
Nasza odpowiedź — liczby zmierzone na routerze ITCbng
- 40,2 Mpps przy pakietach 64 B — z włączonym NAT (translacja adresów w ścieżce), 8 rdzeni workera
- 98,57 Gbit/s przy 1500 B — line-rate łącza 100 G, również z NAT-em w ścieżce
- Atak ~10,3 Mpps pochłonięty w trakcie normalnego przekazywania ruchu — router robił jedno i drugie naraz, a abonenci stracili 0,0% pakietów
- ~40 cykli CPU na odrzucenie pakietu ataku wobec ~350 cykli na przejście przez NAT — dlatego atak nie dochodzi do abonentów
- 21,5 µs opóźnienia przez dataplane, 2 000 000 sesji NAT w konfiguracji testowej
Router BGP / brzeg
Styk z tranzytem i peeringiem oraz punkt egzekwowania mitygacji.
- Pełna tablica BGP, IPv4 i IPv6 na jednej sesji MP-BGP, bez sztywnego limitu FIB
- RTBH — odcięcie ruchu do pojedynczego adresu, IPv4 i IPv6 oraz BGP FlowSpec (RFC 8955 / 8956) — drop i rate-limit w kbps
- Selektywne ogłaszanie prefiksu: wycofanie od wskazanych sąsiadów przy jednoczesnym utrzymaniu peerów krytycznych
- uRPF / BCP38 per interfejs w obu rodzinach adresów, RPKI ROV, limity prefiksów, BFD
- Reguły mitygacji przyjmowane wprost z ITCSECadmin, z automatycznym wycofaniem po wygaśnięciu zagrożenia
Router NAT / CGNAT
Oszczędzanie adresacji IPv4 i wskazanie abonenta na wniosek służb.
- 2 000 000 sesji NAT w konfiguracji testowej — więcej sesji to więcej RAM, nie wymiana krzemu
- Deterministyczny NAT / alokacja bloków portów (PBA) — dziennik to jedna linia na abonenta zamiast jednej na sesję
- Logowanie translacji na potrzeby retencji oraz odwrotny lookup: adres publiczny + port + czas → abonent
- EIM/EIF i hairpinning (RFC 4787), limit portów per abonent, wykluczenia i statyczny NAT 1:1
- Filtr ataku stoi przed NAT-em — zmierzone 40,2 Mpps @ 64 B z NAT-em w ścieżce
Koncentrator PPPoE / BNG
Terminacja sesji abonenckich, egzekwowanie polityki, accounting billingowy.
- RADIUS: uwierzytelnianie, accounting z aktualizacjami interim, CoA i Disconnect (RFC 5176) — zmiana taryfy bez dotykania routera
- QoS per sesja z atrybutów RADIUS, hierarchiczne kolejkowanie, kształtowanie w obu kierunkach
- IPv6 IA-NA + IA-PD po PPPoE, DHCPv6 i RA — delegacja prefiksu do CPE
- 500 VLAN w konfiguracji testowej, QinQ, rate-limit PADI i limit sesji na port
- Anty-spoofing per sesja, MSS clamping i MTU 1492, strojenie LCP echo
- Tempo zestawiania sesji mierzymy dla Twojej konfiguracji — pytaj o liczbę sesji na sekundę przy odtwarzaniu po zaniku zasilania
Każdy z trzech routerów działa samodzielnie. Warstwa aktywnej ochrony DDoS opisana niżej jest opcją, którą można dołożyć do dowolnego z nich.
Warstwa aktywnej ochrony DDoS
Dwie warstwy o różnych właściwościach i różnych warunkach działania. Rozdzielamy je, bo warunek warstwy stanowej trzeba znać przed zakupem, a nie po incydencie.
Warstwa stateless — zawsze dostępna
Działa niezależnie od symetrii ruchu, nie musi widzieć obu kierunków sesji. Odrzuca po sygnaturze i limicie, u wejścia WAN, przed NAT-em. To ona zatrzymuje atak wolumetryczny.
- BCP38 / uRPF — anty-spoofing per interfejs, pełny IPv4 i IPv6
- Policer TCP po flagach (SYN
0x02, SYN+ACK0x12) z limitem kbps i burst — odpowiedź na carpet-bomb SYN+ACK - Drop fragmentów — fragment-0 z uciętym nagłówkiem L4 i fragmenty-sieroty, ze strojeniem tablicy reassembly
- Drop amplifikacji DNS — UDP z portu źródłowego 53 powyżej 768 B, z klasą permit dla zaufanych resolwerów
- Drop w krzemie karty (mlx5 rte_flow) — chirurgiczny, po adresie i cesze ataku, zamiast blackhole’a całej podsieci
- RTBH i FlowSpec na brzegu, z rate-limitem w kbps, nie tylko dropem
- CoPP i filtry ingress z limitami
Uczciwie: warstwa stateless nie rozumie sesji — bez stanu nie odróżni pojedynczego legalnego SYN-ACK od zwrotnego z refleksji, więc broni się limitem i sygnaturą. Progi zawsze wymagają dostrojenia do wolumenu ruchu klienta. Robimy to przy wdrożeniu metodą: faza bazowa → atak → powrót, z pomiarem co sekundę.
Warstwa stateful — pewna, zmierzona
To jest scrubbing center działający w Twoim własnym urządzeniu. Śledzenie połączeń przepuszcza wyłącznie pakiety należące do ustanowionej sesji — czyli wykonuje dokładnie tę pracę, za którą płaci się zewnętrznemu centrum czyszczenia ruchu. Refleksyjny SYN+ACK carpet-bomb jest tu odrzucany definitywnie, bo nigdy nie było wychodzącego SYN.
- Bez przekierowywania ruchu przez cudzą sieć, bez opóźnienia na drodze tam i z powrotem, bez opłat za Gbps
- Reflexive-ACL / connection tracking przy prędkości łącza — decyzja zapada bez sygnatury i bez strojenia progów
- Ruch legalny idzie dalej nieprzerwanie, pakiet spoza sesji nie idzie nigdzie
- Wektory bezsesyjne — fragmenty UDP czy amplifikacja DNS — zdejmuje warstwa stateless stojąca przed nią; razem dają pełne pokrycie
Ochrona stanowa musi widzieć cały ruch sesji, w obu kierunkach. Działa na jednym urządzeniu, przez które przechodzą oba kierunki, albo na 2–3 naszych urządzeniach zsynchronizowanych.
Na asymetrycznym brzegu multi-homed — gdzie ruch wychodzi jednym routerem, a wraca innym — stateful bez synchronizacji odrzucałby ruch legalny. U realnego klienta zmierzyliśmy na takim brzegu 97% asymetrii. Tam broni warstwa stateless. Mówimy Ci, który to Twój przypadek, zanim kupisz.
Dlaczego Twoi abonenci nie zauważą ataku
Atak nie musi wysycić łącza, żeby położyć sieć — wystarczy, że zmusi router do kosztownej pracy nad każdym pakietem z osobna. Dlatego liczy się, jak wcześnie router pozbywa się ataku. My robimy to na samym początku, zanim pakiet trafi do najdroższego etapu przetwarzania.
| Co router robi z pakietem | Koszt | Efekt |
|---|---|---|
| Odrzucenie ataku naszym filtrem, przed NAT-em filtr klasyfikujący na wejściu | ~40 cykli CPU | atak znika niemal za darmo |
| Przepuszczenie pakietu przez NAT translacja adresów | ~350 cykli CPU | ~9× drożej — tutaj atak kładzie router |
Ta prawie dziewięciokrotna różnica decyduje o wszystkim. Odrzucamy atak już w drzwiach, więc router nie dławi się nim, tylko go wyrzuca: 7,8 Mpps ataku SYN+ACK znika, a Twoi abonenci dalej oglądają film. W teście z 5 Mpps ataku za filtr przechodzi około 21 tysięcy pakietów na sekundę — reszta nie dociera nigdzie.
Skąd ten zapas? Nasze routery to oprogramowanie na standardowym serwerze, więc wydajność rośnie razem z liczbą rdzeni — potrzebujesz więcej, dokładasz rdzenie. Urządzenia zbudowane wokół dedykowanego układu scalonego mają swój sufit wpisany na stałe w krzem, a te oparte na zwykłym procesorze bez naszej optymalizacji dławią się dokładnie przy tych małych pakietach, z których składa się atak. Praktyczny efekt: sprzęt stojący za naszym brzegiem — Cisco ASR, MikroTik, dowolny router abonencki — przeżywa atak, bo my zatrzymujemy go wcześniej. Przy profilu ataku, który zmierzyliśmy, i pod warunkiem opisanym wyżej.
Wydajność — liczby zmierzone
Nie sprzedajemy Gbps, tylko pps przy profilu ataku. Atak 10 Gbit/s SYN flood to tyle pakietów, co 45 Gbit/s ruchu produkcyjnego (64 B wobec ~390 B) — pudełko reklamowane przy dużych pakietach potrafi paść przy dziesięciogigabitowym ataku.
| Rozmiar pakietu | Mpps | Przepustowość |
|---|---|---|
| 64 B (profil ataku) | 40,2 | 27,0 Gbit/s |
| 512 B | 19,94 | 84,88 Gbit/s |
| 1500 B (transfer) | 8,11 | 98,57 Gbit/s ≈ line-rate 100 G |
Wszystkie liczby zmierzone z włączonym NAT w ścieżce — to nie jest gołe forwardowanie, tylko pełna praca, jaką router wykonuje w produkcji. 8 rdzeni workera, AMD EPYC 4564P, karty 2× 100 G. Pomiar end-to-end: każdy pakiet policzony na wyjściu i z powrotem na wejściu, bez ani jednego zgubionego. Wymaganie projektowe przy 64 B wynosiło 15 Mpps — wynik jest 2,7× wyższy.
- Skalujesz rdzeniami, nie wymianą sprzętu. Na wyjściu routera zmierzyliśmy 38 Mpps na 4 rdzeniach, 48 na 6 i do 60 na 8. Dobierasz liczbę rdzeni do swojego wolumenu — warianty S, M i L różnią się rdzeniami, pamięcią i kartami.
- Przy 1500 B wysycamy łącze 100 G z NAT-em w ścieżce — 98,57 Gbit/s zmierzone.
- 21,5 µs opóźnienia przez router, przy wymaganiu poniżej 100 µs.
- Pod atakiem ~10,3 Mpps ruch abonencki był dostarczany bez żadnych zakłóceń — strata pakietów abonenckich 0,0%, bez spadku przekazywania.
- Poprawny pinning jest częścią produktu, nie zadaniem klienta. Źle przypięty worker kosztuje 30% wydajności przy 64 B — nasze routery robią to z pudełka.
Sygnatury, które obsługujemy — z produkcji, nie z laboratorium
Ataki zmierzone w produkcji, na żywym ruchu sieci operatorskiej, 10–11 sierpnia 2026. Do testów odtwarzamy je 1:1 profilami TRex, metodą: faza bazowa z ruchem abonenckim, nakładka ataku, faza powrotu — z pomiarem co sekundę.
| Wektor | Sygnatura | Szczyt produkcyjny | Nasza odpowiedź |
|---|---|---|---|
| SYN+ACK reflection carpet bomb | flagi TCP 0x12, 59 B, 33 964 źródeł, po 256 adresów na /24 | 7,8 Mpps 3,6 Gbit/s | policer flag TCP przed NAT, warstwa stateful (drop bez wcześniejszego SYN), drop w krzemie karty |
| Fragmenty UDP „port 0” | offset fragmentu ≠ 0, ~1240 B | 137 870 pps 1,4 Gbit/s | drop fragmentów-sierot i strojenie reassembly przed NAT |
| Amplifikacja DNS | UDP z portu źródłowego 53, 1488 B | 74 476 pps 887 Mbit/s | drop UDP/53 powyżej 768 B, permit dla zaufanych resolwerów |
| UDP flood | UDP na port docelowy 80, ~1400 B | 87 306 pps 997 Mbit/s | twardy drop klasą ACL przed NAT |
Wszystkie cztery wektory zostały odfiltrowane bez zauważalnego obciążenia procesora i bez jakichkolwiek zakłóceń dla ruchu abonenckiego. Filtr odrzuca pakiet ataku kosztem ~40 cykli CPU, jeszcze przed NAT-em — dlatego obciążenie routera praktycznie nie drgnęło, a abonenci nie odczuli, że atak trwa.
Metryka zmierzona podczas ataku nie mówi nic o ruchu legalnym — zawsze porównujemy ją z fazą bazową.
Jak kupować router — i jak przyłożyć te pytania do nas
Karta katalogowa rozstrzyga mniej niż odpowiedzi na kilka konkretnych pytań. Przygotowaliśmy listę dwunastu, którą warto wysłać w zapytaniu ofertowym każdemu producentowi — nam również. Oto siedem najważniejszych:
- Ile pps przy pakietach 64 bajty, z włączonym NAT-em, kolejkowaniem i eksportem flow?
- Jaki jest najniższy obsługiwany aktywny timeout eksportu flow i ile kosztuje ustawienie go na 5 sekund?
- Czy eksporter ogłasza sampling rate, a rekord flow zawiera interfejs wejściowy i source MAC?
- Jaki jest limit FIB — nie RIB — i czy jest współdzielony między IPv4 a IPv6?
- Co się dzieje z sesjami BGP przy 10 Mpps ruchu skierowanego do adresu routera?
- Ile równoczesnych sesji NAT i przy jakim tempie zestawiania w conn/s?
- Ile sesji PPPoE na sekundę przy odtwarzaniu po zaniku zasilania?
Na każde z nich odpowiadamy liczbą albo pomiarem. Poproś o demonstrację — pps przy 64 B i sesje na sekundę pokazujemy na stanowisku.
Zapytaj o konfigurację i pomiar