NetDoc automatycznie odkrywa urządzenia w sieci, identyfikuje podatności i zbiera dane — bez agentów, bez konfiguracji per-urządzenie.
Wystarczy znać zakres sieci — resztą zajmuje się NetDoc.
Podaj CIDR (np. 192.168.1.0/24) lub zostaw puste — auto-detect wykryje lokalne podsieci.
ARP scan + nmap wykrywa aktywne hosty, fingerprinting identyfikuje system operacyjny i otwarte porty.
SNMP, SSH i dedykowane drivery (UniFi, Cisco, MikroTik) pobierają szczegółowe dane o urządzeniach.
33+ kontroli podatności, testowanie 10 protokołów credentials. Wyniki w Grafanie i panelu web z CVSS. Suppresja false positive bezpośrednio z UI.
Ping co 18s, SNMP enrichment co 5 min, vulnerability scan co 2 min — niezależne workery działają równolegle. Alert Telegram przy każdej zmianie statusu.
NetDoc sprawdza się wszędzie tam, gdzie sieć jest większa niż jeden router i ważniejsza niż arkusz Excel.
Masz sieć z setkami urządzeń — komputery, drukarki, kamery IP, access pointy, może jakiś stary switch bez dokumentacji. NetDoc skanuje automatycznie i buduje aktualny inwentarz: co jest podłączone, jaki producent, jakie porty otwarte. Koniec z arkuszami Excel aktualizowanymi raz na rok.
Obsługujesz wielu klientów. Każdy ma inną sieć, inny sprzęt, inne hasła. NetDoc pozwala w kilka minut zinwentaryzować nieznaną sieć, wykryć urządzenia z domyślnymi hasłami i mieć gotowy raport zanim wyjdziesz od klienta. Szczególnie przydatny przy przejęciu nowego kontraktu.
Chcesz wiedzieć czy w sieci nie ma "zapomnianych" urządzeń dostępnych bez hasła — starego NVR z domyślnym admin/admin, kamery z otwartym RTSP, przemysłowego PLC dostępnego przez Modbus bez autoryzacji. NetDoc wykrywa takie przypadki automatycznie i klasyfikuje je według poziomu ryzyka.
Inwertery, liczniki energii, sterowniki PLC, panele HMI — urządzenia które "zawsze działały" i nikt nie sprawdzał czy są bezpieczne. NetDoc wykrywa ekspozycję protokołów przemysłowych (Modbus TCP) i urządzeń bez uwierzytelnienia w sieci produkcyjnej.
Nowy klient, nieznana sieć. NetDoc w ciągu kilku minut daje odpowiedź: ile urządzeń, jakie typy, które reagują na SSH lub SNMP, które mają otwarte porty zarządzające. Dobry punkt startowy do każdego wdrożenia.
Podłącz laptopa do sieci klienta podczas spotkania i pokaż w czasie rzeczywistym co NetDoc znajduje. Działa bez agentów, bez instalacji po stronie klienta — wystarczy docker compose up na Twoim laptopie.
Niezależny od producenta. Działa z Cisco, MikroTik, Ubiquiti, Fortinet, kamerami IP, przemysłowymi PLC i każdym urządzeniem sieciowym.
ARP scan + nmap fingerprinting — 7 metod wykrywania: ARP, mDNS, NetBIOS, WSD, SSDP, reverse DNS, APIPA. Identyfikacja OS i producenta z bazy IEEE OUI (39k+ wpisów).
33+ kontrole podatności z oceną CVSS. Redis, MongoDB, Docker API, MQTT, IPMI bez auth, DVR XMEye/Dahua, ONVIF kamery, Modbus PLC, RTSP, VNC, SSL expired i wiele więcej.
170+ fabrycznych par login/hasło dla Cisco, Ubiquiti, MikroTik, kamer IP, DVR, drukarek, baz danych, polskich ERP. Testowane przez 10 protokołów — SSH, HTTP, FTP, VNC, RDP, Telnet, SNMP, MySQL, MSSQL, PostgreSQL.
Pobiera hostname, opis, lokalizację i tablice ARP z urządzeń SNMP v2c. Community string wykrywany automatycznie — bez konfiguracji per-urządzenie.
Ładują się automatycznie przy starcie — zero konfiguracji. Community: Przegląd sieci, Bezpieczeństwo (CVSS), Workerzy, Internet/WAN, Logi (Loki). Pro: +Syslog dashboard (ClickHouse — severity timeline, top urządzenia, top programy).
Powiadomienia w czasie rzeczywistym gdy urządzenie zniknie z sieci, pojawi się nowe lub wykryta zostanie podatność. Działa przez bota Telegram — bez potrzeby publicznego IP.
Modbus TCP — wykrywanie inwerterów, liczników energii i PLC dostępnych bez autoryzacji (odczyt rejestrów FC0x11). Kluczowe przy audytach sieci OT/ICS i środowisk produkcyjnych.
ICMP + próby TCP na kluczowe porty (SSH, HTTP, RDP, RTSP). Panel live-status odświeżany automatycznie. Alert Telegram przy zmianie dostępności — wykrycie awarii w ciągu sekund.
Test prędkości (download/upload), publiczne IP, ISP i geolokalizacja WAN, latencja TCP i jitter HTTP do Cloudflare/Google DNS. Dane historyczne w Grafanie.
Automatyczne zrzuty paneli webowych urządzeń (routery, kamery, NVR, switche) przez Selenium headless Chrome oraz miniaturki ze strumieni RTSP — podgląd bez otwierania przeglądarki.
Jedno polecenie docker compose up uruchamia 17 kontenerów: PostgreSQL, API FastAPI, panel Flask, nginx, Grafana, Prometheus, Loki, ClickHouse, rsyslog, Vector i workery (ping, SNMP, cred, vuln, community, internet).
Wirtualne środowisko testowe z symulowanymi urządzeniami: Cisco IOS, MikroTik RouterOS, kamera RTSP, Modbus PLC, serwer SSH — bez potrzeby fizycznego sprzętu.
S/N, asset tag, cena zakupu, dostawca, faktura, koniec gwarancji i koniec wsparcia (EoS). Alarm gdy wsparcie wygasa w ciągu 90 dni. Eksport całego inwentarza do CSV.
Zrzut bazy jako .sql.gz jednym kliknięciem (pg_dump z panelu). Przywrócenie przez wgranie pliku — bez linii komend. Prosta migracja między instalacjami lub maszynami.
Skanuj równolegle dowolną liczbę podsieci CIDR. Nowa podsieć po zmianie lokalizacji lub podłączeniu segmentu jest wykrywana automatycznie bez edycji konfiguracji.
Kolorowe flagi na kartach urządzeń (zaufane, monitorowane, niestandardowe kolory). Oznaczenie Static vs DHCP — widoczne bezpośrednio w liście. Licznik zablokowanych prób logowania SSH — widoczny po najechaniu na adres MAC. Filtrowanie po statusie, typie, producencie i podatnościach. Wyszukiwanie po IP, hostname lub notatce.
Logi sieciowe z routerów, switchy i AP trafiają przez rsyslog → Vector do ClickHouse. Filtrowanie po severity, urządzeniu, programie i zakresie czasu. Auto-refresh co 30s. Retencja 12 miesięcy — gotowe pod NIS2/DORA jako dowód monitorowania dla audytorów.
Zapytaj o dowolne urządzenie lub o całą sieć — AI odczyta dane w czasie rzeczywistym (vendor, model, OS, porty, podatności) i powie co to za sprzęt, jakie niesie ryzyko i co z tym zrobić. Globalna analiza sieci wykrywa podejrzane wzorce i sugeruje segmentację VLAN. Historia rozmów. Żadne prywatne dane nie trafiają do modelu bez Twojej wiedzy.
Wiele urządzeń ma SNMP włączone fabrycznie z community string public. NetDoc automatycznie je wykrywa i odczytuje dane bez konfiguracji — a otwarte community flaguje jako podatność. Jeśli wpiszesz własne community, dostęp do danych rośnie: uptime, statystyki interfejsów, temperatura, stan zasilania.
publicNetDoc sprawdza wyłącznie dokumentowane fabryczne hasła — bez brute-force, cicho, z minimalnym ruchem. Baza jest samorozwijająca się: credential znaleziony w jednej sieci trafia do puli i jest testowany na kolejnych urządzeniach tego samego typu.
Konkretne scenariusze z życia — jak NetDoc skraca czas diagnozy i zmniejsza koszty.
Na obiekcie biurowym przez kilka nocy dochodziło do dziwnych incydentów: kamery traciły konfigurację, switche wymagały ponownego wgrania ustawień, część urządzeń BMS wracała do wartości fabrycznych. Usterki wyglądały jak losowe — nikt ich nie łączył ze sobą. Każda zgłaszana oddzielnie, każda leczona objawowo.
Monitoring pokazał wzorzec który gołym okiem był niewidoczny: dziesiątki urządzeń znikały z sieci i wracały w tej samej chwili — o 2:15, 3:42, 4:08 w nocy. Nie jedno urządzenie z błędem, nie awaria switcha — cały segment sieci gasł i wstawał jednocześnie. To nie był problem IT. Analiza historii alarmów wskazała na układ przełączania źródeł zasilania, który w godzinach nocnych (mniejsze obciążenie budynku) generował serie krótkich zaników. Finalnie wymiana uszkodzonej aparatury elektrycznej zakończyła tygodnie "tajemniczych awarii".
Każda usterka leczona osobno — reset urządzenia, wgranie konfiguracji, wizyta serwisu. Tygodnie objawowego leczenia skutków bez znalezienia przyczyny. Koszty serwisowe rosną, problem wraca.
Historia alarmów pokazuje wzorzec: dziesiątki urządzeń w tym samym segmencie, w tych samych godzinach. Diagnoza wskazuje zasilanie — nie IT. Elektryk zamiast kolejnego resetu urządzeń.
Switch zarządzalny z domyślnym hasłem admin/admin lub router z cisco/cisco
to nie tylko „słabe zabezpieczenie" — to pełna kontrola nad siecią.
Osoba z dostępem do przełącznika może: włączyć port mirroring i podsłuchiwać cały ruch w sieci,
zmienić tablice routingu i przekierować ruch przez własną maszynę, wyłączyć porty kluczowych
urządzeń, otworzyć backdoor VPN lub po prostu wyeksportować konfigurację z hasłami innych urządzeń.
W realnych przypadkach do naruszenia bezpieczeństwa wystarczył dostęp do jednego urządzenia
z domyślnym hasłem — pracownik, podwykonawca z dostępem do sieci WiFi, a nawet fizyczny dostęp do gniazda sieciowego.
Kamery z admin/admin to nie tylko podgląd obrazu — często mają dostęp do dalszej części sieci i serwują jako punkt wejścia.
Nie wiesz że urządzenie ma domyślne hasło. Nikt tego nie sprawdzał. Problem zostaje odkryty dopiero po incydencie — albo wcale.
Automatyczne testy 170+ par fabrycznych przy każdym cyklu skanowania. Przy odkryciu: alert z dokładnym IP, protokołem i parą login/hasło. Możesz zareagować zanim pojawi się problem.
Pracownik podłącza do sieci firmowej własny router WiFi (np. TP-Link w trybie routera, nie AP)
— albo technik chwilowo zostawia urządzenie testowe z aktywnym DHCP. Router zaczyna
rozgłaszać własne oferty DHCP w całej sieci LAN.
Część urządzeń odbiera ofertę od obcego serwera i dostaje adresację z zupełnie innego zakresu
— np. 192.168.0.x zamiast firmowego 10.1.0.x.
Komputery tracą połączenie z serwerami plików, drukarkami, systemem ERP.
Inne urządzenia — szczególnie IoT i kamery — nie mogą się dogadać z nową podsiecią
i praktycznie wypadają z sieci.
Diagnoza bez narzędzi zajmuje długo — problem jest niewidoczny, losowy i wygląda jak „coś się samo zepsuło". Sprawdzasz kable, restartujesz switche, dzwonisz do dostawcy internetu.
Nie wiesz że w sieci jest drugi serwer DHCP. Logujesz się na każdy komputer, porównujesz adresy IP ręcznie, szukasz igły w stogu. Diagnoza: kilka godzin, najczęściej sprowadza się do restart-u routera głównego.
NetDoc widzi: nagłe pojawienie się nowej podsieci (192.168.0.x) — ostrzeżenie o nieznanej adresacji w sieci. W logu: nowy host z adresem MAC — identyfikujesz rogue router w ciągu minut po MAC OUI (np. TP-Link Technologies).
Sobotni poranek. Ekipa sprzątająca podłącza odkurzacz do gniazdka w korytarzu przy serwerowni. Przeciążenie wyrzuca różnicówkę — i cała szafa: serwer, router, switch, NAS, wyłącza się. Biuro martwe. Nikt nie wie. Sprzątaczki kończą pracę i wychodzą.
Bez monitoringu ten scenariusz kończy się w poniedziałek rano: 8:00, pracownicy przychodzą, nic nie działa — serwer plików, poczta, ERP, VPN. Panika, telefony do IT, technik jedzie w trybie awaryjnym. Przestój całego biura od rana. Z monitoringiem alert przychodzi w sobotę o 9:23 — jest jeszcze cały weekend na spokojną reakcję.
Problem wykryty w poniedziałek rano przez pracowników. Przestój całego biura od otwarcia. Technik jedzie w trybie awaryjnym. Wznowienie pracy po kilku godzinach — straty wizerunkowe i finansowe.
Alert w ciągu sekund od zdarzenia. Technik reaguje w weekend, spokojnie przywraca zasilanie. Poniedziałkowy poranek przebiega normalnie. Zero przestoju, zero nerwów w biurze.
Problem między operatorami internetowymi — routing BGP, awaria peering, awaria łącza tranzytowego. Niezależnie od przyczyny efekt jest ten sam: kilkanaście minut przerwy, podczas których ~300 firm traci dostęp do usługi. Serwery działają, datacenter działa, wina leży poza infrastrukturą operatora — ale klienci tego nie wiedzą. Widzą tylko: "nie działa".
Bez monitoringu przez pierwsze kilkanaście minut nikt po stronie operatora nic nie wie. Klienci dzwonią jeden po drugim. Helpdesk jest zaskoczony, nie ma informacji, nie może potwierdzić ani zaprzeczyć. Frustracja rośnie. Pierwsze "dlaczego was nie stać na porządne łącze" pojawia się po 3 minutach. Z monitoringiem cały łańcuch komunikacji uruchamia się automatycznie — zanim którykolwiek klient zdąży podnieść słuchawkę.
Helpdesk zasypany telefonami z których nic nie wynika. Inżynierowie diagnozują w pośpiechu. Klienci słyszą "sprawdzamy" przez 20 minut. Wrażenie chaosu — nawet jeśli awaria trwała chwilę. Pierwsze negatywne opinie w mediach społecznościowych.
Helpdesk odbiera telefony z gotową odpowiedzią. Klienci którzy zobaczyli status page — nie dzwonią w ogóle. Inżynierowie dostają alert z kontekstem, nie z paniki. Awaria 17 minut — komunikacja profesjonalna od pierwszej sekundy.
Latem, w piątek po południu, w serwerowni uszkodził się agregat klimatyzacyjny. Temperatura w pomieszczeniu zaczęła rosnąć. Serwery, switche i zasilacze UPS pracują dalej — nie sygnalizują żadnego problemu w sieci. Nikt nic nie wie. Budynek pustoszeje na weekend.
Bez monitoringu temperatury scenariusz jest przewidywalny: w sobotę rano temperatura przekracza próg bezpiecznej pracy, procesory zaczynają throttling, dyski zwalniają, serwery wyłączają się awaryjnie lub — co gorsza — pracują w przeciążeniu termicznym aż do uszkodzenia. Wymiana spalonego sprzętu to tysiące złotych i dni przestoju. Z czujnikiem temperatury i monitoringiem alert wychodzi już przy pierwszym wzroście — wskazane osoby reagują zanim temperatura osiągnie poziom krytyczny.
Nikt nie wie. Temperatura rośnie przez cały weekend. W poniedziałek serwery nie odpowiadają lub są uszkodzone. Wymiana sprzętu, odtwarzanie danych z backupu, kilka dni przestoju firmy.
Alert przy pierwszym wzroście temperatury. Eskalacja do kolejnych osób jeśli nikt nie reaguje. Technik interweniuje w ciągu godziny. Sprzęt bez uszkodzeń, firma nie wie że cokolwiek się stało.
Operator internetu radiowego obsługuje kilkadziesiąt lokalizacji — maszty, nadajniki na dachach, szafy teletechniczne. W jednej z lokalizacji monitoring traci kontakt z całym sprzętem naraz: routerem, switchem, access pointami. Wszystko jednocześnie — klasyczny objaw braku zasilania. Kilkudziesięciu abonentów w promieniu nadajnika właśnie straciło internet.
Bez automatyzacji scenariusz jest zawsze taki sam: klienci próbują połączenia, nie ma internetu, dzwonią do BOK jeden po drugim. Konsultant nie wie co się stało, odsyła do technika, technik jedzie bez kontekstu. Przez pierwsze 30 minut firma wygląda jak ktoś kto sam nie wie co się dzieje we własnej sieci. Z monitoringiem i automatyczną notyfikacją — zanim którykolwiek klient zdąży wybrać numer, ma już e-mail z informacją że operator wie o problemie i technicy są w drodze.
Klienci odkrywają awarię sami. BOK zasypany telefonami od osób które nie wiedzą dlaczego nie ma internetu. Konsultant nie ma informacji. Wrażenie chaosu i braku kontroli nad własną siecią. Opinie w stylu "nie wiedzą co się u nich dzieje".
Klienci dostają e-mail zanim odkryją awarię. BOK odbiera telefony z gotową odpowiedzią. Technik jedzie ze znajomością sytuacji. Awaria ta sama — odbiór klientów zupełnie inny.
Więcej scenariuszy — wkrótce. Masz własny case study? Opisz go na GitHub Discussions.
Pytaj o sieć w języku naturalnym, analizuj całą infrastrukturę jednym kliknięciem, śledź historię ocen i zawsze wiesz co dokładnie trafia do modelu.
Zadaj dowolne pytanie: „Które urządzenia nie pingują od godziny?", „Podsumuj krytyczne podatności", „Co to za urządzenie pod .45?". AI pobiera dane z bazy na żywo i odpowiada po polsku.
Kliknij „Oceń przez AI" przy dowolnym urządzeniu. Dostaniesz: opis co to za sprzęt, analizę ryzyka (podatności + porty), ocenę czy jest przestarzały oraz trzy propozycje zamienników w różnych przedziałach cenowych.
Jednym wywołaniem AI analizuje całą infrastrukturę naraz: identyfikuje sprzęt wymagający wymiany, sugeruje segmentację VLAN, wskazuje urządzenia, które powinny być odizolowane, i generuje ogólne podsumowanie stanu sieci.
Dostępny w wersji Community — wymaga własnego klucza Anthropic API. Jak skonfigurować →
Panel administracyjny Flask + dashboardy Grafana — działające na prawdziwej sieci testowej.
Zrzuty z rzeczywistej instalacji na sieci testowej (Docker + host Windows). Dane anonimizowane.
Community jest i pozostanie darmowe. Pro to rozszerzenia dla firm i MSP.
Skanowanie sieci może powodować niezamierzone skutki uboczne: drukarki mogą wykonać niechciany wydruk (skan portu 9100/JetDirect), starsze przełączniki i urządzenia IoT mogą zawiesić się lub zrestartować pod wpływem intensywnego ruchu, skanowanie pełnych portów (1–65535) generuje duży ruch i może wyzwolić systemy IDS/IPS.
Zalecane środowisko startowe: sieć testowa, laboratorium lub środowisko demo (dostępne w repo). Przed wdrożeniem produkcyjnym zapoznaj się z dokumentacją i przetestuj na własnym sprzęcie. Projekt jest aktywnie rozwijany — niektóre funkcje mogą być niestabilne.
False positive w wynikach skanowania: baza wzorców urządzeń jest budowana na bieżąco — na sprzęcie, który nie był jeszcze testowany, skaner może błędnie sklasyfikować typ urządzenia lub oznaczyć podatność której faktycznie nie ma. Jeśli widzisz taki przypadek, zgłoś go na GitHub Issues — podaj producenta, model i co zostało błędnie wykryte. Każde zgłoszenie trafia bezpośrednio do bazy i poprawia działanie dla wszystkich.
Działa na Linux, Windows (WSL2), macOS. Wymagania: Docker + Docker Compose + Python 3.9+ + nmap.
Aktywnie rozwijany projekt. Pełna mapa rozwoju dostępna na GitHub.
W trakcie Planowane Długoterminowe
Pytania o NetDoc, wdrożenie, wersję Pro lub współpracę — napisz przez LinkedIn.
Instalacja, konfiguracja, integracja z istniejącą infrastrukturą. Możliwe wdrożenie SaaS (u mnie) lub on-site (na Twoich serwerach).
Inwentaryzacja urządzeń, wykrywanie podatności, domyślne hasła, ekspozycja protokołów IoT/OT. Raport z priorytetami działań.
Inwentaryzacja szaf rack, opisywanie portów i kabli, porządkowanie patchpaneli. Dobór i wymiana przestarzałego sprzętu (switche, routery, Wi-Fi, zasilanie UPS). Zabezpieczenia fizyczne portów (Smart Keeper).
Projektowanie i wdrożenie środowisk wirtualnych, dobór i dostawa sprzętu serwerowego, migracja do nowej infrastruktury.
Stała opieka nad siecią i infrastrukturą — jako zewnętrzny IT. Monitoring, reakcja na awarie, planowanie rozwoju. Dla firm, które nie mają własnego działu IT lub chcą go odciążyć.
Projekt jest świeży — na sprzęcie który nie był jeszcze testowany mogą pojawić się false positive (błędna klasyfikacja, podatność której nie ma) lub false negative (przeoczona podatność). Jeśli masz takie urządzenie, zgłoś producenta i model na GitHub Issues — każde zgłoszenie trafia do bazy wzorców i poprawia działanie skanera dla wszystkich użytkowników.