🚀 Open Source · v0.1.9 Beta

Twoja sieć odkryta,
udokumentowana, chroniona

NetDoc automatycznie odkrywa urządzenia w sieci, identyfikuje podatności i zbiera dane — bez agentów, bez konfiguracji per-urządzenie.

Zacznij w 2 minuty Zobacz na GitHub
33+
typów podatności
10
protokołów credentials
39k+
wpisów OUI (IEEE)
18s
cykl ping monitoring

Zero agentów, zero konfiguracji per-urządzenie

Wystarczy znać zakres sieci — resztą zajmuje się NetDoc.

1

Skonfiguruj zakres

Podaj CIDR (np. 192.168.1.0/24) lub zostaw puste — auto-detect wykryje lokalne podsieci.

2

Discovery

ARP scan + nmap wykrywa aktywne hosty, fingerprinting identyfikuje system operacyjny i otwarte porty.

3

Enrichment

SNMP, SSH i dedykowane drivery (UniFi, Cisco, MikroTik) pobierają szczegółowe dane o urządzeniach.

4

Analiza bezpieczeństwa

33+ kontroli podatności, testowanie 10 protokołów credentials. Wyniki w Grafanie i panelu web z CVSS. Suppresja false positive bezpośrednio z UI.

5

Ciągły monitoring

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.

Kto korzysta z NetDoc?

NetDoc sprawdza się wszędzie tam, gdzie sieć jest większa niż jeden router i ważniejsza niż arkusz Excel.

🏢

Administrator sieci firmowej

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.

🔧

Firma MSP / IT outsourcing

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.

🛡️

Audyt bezpieczeństwa sieci

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.

🏭

Środowisko przemysłowe OT/ICS

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.

🤝

Przejęcie nowej infrastruktury

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.

🎯

Prezentacja i demo na żywo

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.

Wszystko czego potrzebuje administrator sieci

Niezależny od producenta. Działa z Cisco, MikroTik, Ubiquiti, Fortinet, kamerami IP, przemysłowymi PLC i każdym urządzeniem sieciowym.

🔍

Automatyczne Discovery

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).

🛡️

Skanowanie podatności

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.

🔑

Baza domyślnych haseł

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.

📡

SNMP Enrichment

Pobiera hostname, opis, lokalizację i tablice ARP z urządzeń SNMP v2c. Community string wykrywany automatycznie — bez konfiguracji per-urządzenie.

📊

5+1 dashboardów Grafana

Ł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).

🔔

Alerty Telegram

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.

🏭

Protokoły przemysłowe

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.

🟢

Ping monitoring co 18s

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.

🌐

Monitoring łącza WAN

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.

📷

Screenshoty interfejsów

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.

🐳

Instalacja Docker

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).

🔬

Demo Lab

Wirtualne środowisko testowe z symulowanymi urządzeniami: Cisco IOS, MikroTik RouterOS, kamera RTSP, Modbus PLC, serwer SSH — bez potrzeby fizycznego sprzętu.

📦

Inwentarz urządzeń

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.

💾

Backup i restore bazy

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.

🗺️

Wiele sieci jednocześnie

Skanuj równolegle dowolną liczbę podsieci CIDR. Nowa podsieć po zmianie lokalizacji lub podłączeniu segmentu jest wykrywana automatycznie bez edycji konfiguracji.

🏷️

Karta urządzenia — szczegóły na wyciągnięcie ręki

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.

📋

Syslog — archiwizacja logów Pro

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.

🤖

AI Asystent sieci Pro

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.

📡 SNMP — co kryje Twoja sieć?

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.

Co NetDoc odczytuje przez SNMP
Identyfikacja
Hostname
Opis systemu
Wersja firmware
Lokalizacja
Kontakt admin
Status
Czas pracy (uptime)
Lista interfejsów
Statystyki ruchu
Temperatura (jeśli wspierana)
Stan zasilania (UPS)
Topologia
Tablica ARP
Tablica routingu
Sąsiedzi LLDP/CDP
Tablice przełączania (switch)
Bezpieczeństwo
Wykrycie community public
Autodiscovery string
Alert gdy SNMP exposes dane
Zalecenie zmiany na v3
🔑 170+ domyślnych haseł — gotowych przy instalacji

NetDoc 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.

Testowane protokoły
SSH HTTP / HTTPS FTP VNC RDP SNMP Telnet RTSP Modbus TCP MSSQL / MySQL / PostgreSQL
Przykłady vendorów
Cisco IOS  cisco / cisco
Ubiquiti UniFi  ubnt / ubnt
MikroTik  admin / (puste)
Raspberry Pi  pi / raspberry
Kamery IP  admin / admin
DVR/NVR  admin / 12345
MSSQL SA  sa / Wapro3000
HP iLO  Administrator / (puste)
+ 160 kolejnych par…
Pełna lista 33+ typów podatności (CRITICAL / HIGH / MEDIUM) pokaż ▾
🔴 CRITICAL
  • Domyślne hasła (SSH/HTTP/FTP)
  • Redis bez autoryzacji
  • MongoDB bez autoryzacji
  • Elasticsearch bez auth
  • Docker API otwarty (port 2375)
  • MQTT bez hasła (port 1883)
  • IPMI/BMC otwarty (port 623)
  • DVR XMEye (port 34567)
  • DVR Dahua (port 37777)
  • ONVIF kamera bez auth
  • MJPEG stream bez auth
  • Niezabezpieczony reboot CGI
🟡 HIGH / MEDIUM
  • RDP otwarty na zewnątrz
  • Telnet bez szyfrowania
  • FTP bez szyfrowania
  • SNMP community "public"
  • RTSP bez autoryzacji
  • VNC bez hasła / słabe hasło
  • Cassandra bez auth
  • CouchDB bez auth
  • InfluxDB bez auth
  • Memcached bez auth
  • RTMP stream dostępny
  • TFTP bez auth (port 69)
🔵 MEDIUM / INFO
  • MySQL bez hasła / słabe
  • PostgreSQL słabe auth
  • MSSQL słabe auth
  • Modbus TCP bez auth
  • HTTP zamiast HTTPS (mgmt)
  • SSL certyfikat wygasły
  • SSL self-signed
  • DNS information disclosure
  • Firewall misconfiguration
Każdy wynik zawiera wynik CVSS (3.7–9.8), możliwość suppresji false positive i śledzenia czy problem został rozwiązany.

NetDoc w praktyce

Konkretne scenariusze z życia — jak NetDoc skraca czas diagnozy i zmniejsza koszty.

Dla kogo: 🏢 Biura i firmy 🖥️ Serwerownie i datacenters 📡 Operatorzy ISP / WISP 🏭 Przemysł / OT / BMS 🔧 MSP i działy IT
Nocne restarty dziesiątek urządzeń — winowajca: aparatura elektryczna
Obiekt biurowy / budynek z monitorowaną infrastrukturą sieciową

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".

Jak wyglądały alarmy w monitoringu
02:15 ↓ DOWN 31 urządzeń jednocześnie (kamery, switche, sterowniki BMS)
02:15 ↑ UP   31 urządzeń — powrót po ~8 sekundach
03:42 ↓ DOWN 29 urządzeń jednocześnie
04:08 ↓ DOWN 34 urządzenia jednocześnie
❌ Bez monitoringu

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.

✓ Z monitoringiem

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ń.

💡 Kluczowa zasada: monitoring IT nie musi "widzieć" usterki elektrycznej bezpośrednio. Wystarczy że rejestruje korelację zdarzeń — wiele urządzeń w tym samym czasie, regularny wzorzec nocny, brak indywidualnej przyczyny technicznej. To punkt zaczepienia, który kieruje diagnozę we właściwą stronę i oszczędza tygodnie szukania w złym miejscu.
⏱ Tygodnie objawowego leczenia → jedna rozmowa z elektrykiem.
🔓
Przejęcie sieci przez jedno domyślne hasło
Firma produkcyjna / biuro / dowolna sieć z niezmienionym hasłem fabrycznym

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.

Typowy łańcuch eskalacji
1 urządzenie z domyślnym hasłem dostęp do konfiguracji sieci podsłuch / przekierowanie ruchu hasła innych systemów pełne przejęcie infrastruktury
❌ Bez NetDoc

Nie wiesz że urządzenie ma domyślne hasło. Nikt tego nie sprawdzał. Problem zostaje odkryty dopiero po incydencie — albo wcale.

✓ Z NetDoc

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.

🔑 Domyślne hasła to #1 wektor wejścia w audytach sieci SMB i przemysłowych.
📡
Tajemnicze awarie sieci — winowajca: obcy serwer DHCP
Biuro / sieć z urządzeniami DHCP / każda sieć z nieznanym sprzętem

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.

❌ Bez NetDoc

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.

✓ Z NetDoc

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).

💡 Jak NetDoc pomaga w tym scenariuszu: wykrycie nowej nieznanej podsieci z alertem w logach, OUI lookup po MAC adresie wskazuje producenta i typ podejrzanego urządzenia, historia skanów pokazuje dokładnie kiedy nieznany host pojawił się w sieci — co pozwala powiązać incydent z konkretną osobą lub zdarzeniem.
📡 Rogue DHCP to jeden z częstszych problemów w sieciach biurowych bez segmentacji.
🧹
Sobotnie sprzątanie wyłączyło całe biuro — technik zdążył przed poniedziałkiem
Biuro z serwerownią / firma bez całodobowego dyżuru IT

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ę.

Jak wyglądała oś czasu
Sob. 09:23 ↓ DOWN serwer, router, switch, NAS — wszystko jednocześnie
Sob. 09:23 🔔 ALERT Telegram: "4 hosty niedostępne — prawdopodobna awaria zasilania"
Sob. 11:45 ✓ FIX  technik na miejscu, różnicówka przywrócona, systemy wstają
Pon. 08:00 ✓ OK   pracownicy przychodzą — wszystko działa, nikt nic nie wie
❌ Bez monitoringu

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.

✓ Z monitoringiem

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.

💡 Kluczowa wartość: monitoring nie zapobiegł awarii zasilania — tego nie zrobi żadne oprogramowanie. Ale skrócił czas od zdarzenia do reakcji z ~47 godzin do ~2 godzin. Różnica między "nikt nie wiedział przez weekend" a "technik zdążył przed poniedziałkiem" to dokładnie tyle, ile wart jest alert w odpowiednim momencie.
⏱ 47 godzin nieświadomości → 2 godziny do naprawy.
🌐
Awaria między operatorami — Helpdesk uprzedzony, klienci poinformowani, zanim zadzwonili
Operator / dostawca usług / datacenter obsługujący wielu klientów

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ę.

Automatyczny łańcuch reakcji — pierwsze 3 minuty
T+0s ↓ DOWN monitoring wykrywa utratę connectivity — 300 endpointów niedostępnych
T+15s 🔔 ALERT Helpdesk otrzymuje: "awaria łącza, ~300 klientów odciętych, przyczyna zewnętrzna"
T+30s 📋 PAGE status page aktualizuje się automatycznie: "Prowadzimy prace — śledzimy incydent"
T+45s 📢 POST social media: "Jesteśmy świadomi problemu, pracujemy nad rozwiązaniem"
T+3min 📞 ——  pierwsze telefony od klientów — Helpdesk już wie, status page już aktywny
T+17min ✓ UP   routing przywrócony przez operatora upstream — status page: "Rozwiązano"
❌ Bez monitoringu

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.

✓ Z monitoringiem

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.

💡 Kluczowa zasada: klientów nie irytuje awaria — irytuje brak informacji o awarii. Monitoring zintegrowany z komunikacją (status page, social media, Helpdesk) zmienia reakcję z "co się dzieje, dlaczego nikt nic nie wie" na "widzę że wiedzą i pracują nad tym". To różnica między utratą zaufania a budowaniem go w trudnym momencie.
🌐 Awaria 17 minut — komunikacja profesjonalna od pierwszej sekundy.
🌡️
Klimatyzacja w serwerowni przestała działać — alert zanim sprzęt się uszkodził
Serwerownia / szafa rack / każde pomieszczenie z czułym sprzętem

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.

Jak wygląda eskalacja alertów temperaturowych
15:40 ⚠ WARN temperatura serwerowni: 28°C (próg ostrzegawczy) — SMS + Telegram do administratora
16:05 🔴 CRIT temperatura: 34°C (próg krytyczny) — alert e-mail + SMS do managera i serwisu AC
16:05 📈 TREND wykres: +6°C w 25 minutach — prognoza przekroczenia 40°C za ~35 minut
16:30 ✓ ACT technik na miejscu — klimatyzacja przywrócona awaryjnie, temperatura spada
Weekend ✓ OK serwery pracują normalnie — sprzęt bez uszkodzeń
❌ Bez monitoringu temperatury

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.

✓ Z monitoringiem temperatury

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.

💡 Koszt czujnika temperatury vs koszt przegrzania: czujnik środowiskowy z integracją monitoringu to wydatek rzędu kilkuset złotych. Wymiana uszkodzonych termicznie serwerów, dysków i przełączników — to dziesiątki tysięcy złotych i kilka dni przestoju. Monitoring nie naprawia klimatyzacji — ale daje czas żeby to zrobić zanim będzie za późno.
🌡️ Kilkaset złotych na czujnik — vs dziesiątki tysięcy na wymianę sprzętu.
📡
Brak zasilania na nadajniku — klienci poinformowani zanim zaczęli dzwonić
Operator internetu radiowego / WISP / dostawca usług do wielu lokalizacji

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.

Automatyczny e-mail do klientów — wysyłany w ciągu 60 sekund od wykrycia
Temat: Informacja o przerwie w usłudze — lokalizacja Kowalew
Szanowni Państwo,
nasz system monitoringu wykrył brak kontaktu ze sprzętem sieciowym obsługującym Państwa lokalizację. Prawdopodobną przyczyną jest brak zasilania na obiekcie. Technicy zostali już powiadomieni i udają się na miejsce w celu sprawdzenia i przywrócenia usługi.
Będziemy informować o postępach. Przepraszamy za utrudnienia.
— wysłano automatycznie przez system monitoringu | godz. 14:07
Oś czasu
14:06 ↓ DOWN monitoring: brak kontaktu z 4 urządzeniami w lokalizacji — prawdopodobne zasilanie
14:07 📧 MAIL automatyczny e-mail do 47 abonentów w zasięgu nadajnika
14:07 🔔 SMS alert do technika dyżurnego z lokalizacją i listą urządzeń bez kontaktu
14:15 📞 —— pierwsze telefony od klientów — BOK: "tak, wiemy, technicy w drodze"
15:40 ✓ UP zasilanie przywrócone — monitoring potwierdza powrót urządzeń
15:41 📧 INFO automatyczny e-mail do klientów: "usługa przywrócona, dziękujemy za cierpliwość"
❌ Bez monitoringu i automatyzacji

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".

✓ Z monitoringiem i automatyzacją

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.

💡 Wizerunek buduje się w trudnych momentach: każdy operator ma awarie. Różnica między tym który traci klientów a tym który buduje lojalność leży w jednym: czy klient dowiaduje się od Ciebie czy od swojego braku internetu. Automatyczna notyfikacja przy awarii kosztuje zero — a zmienia całkowicie postrzeganie firmy.
📡 Klient dowiaduje się od Ciebie — nie od braku internetu.

Więcej scenariuszy — wkrótce. Masz własny case study? Opisz go na GitHub Discussions.

AI, który zna każde urządzenie w Twojej sieci

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.

💬
Chat asystent

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.

🔬
Ocena pojedynczego urządzenia

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.

🌐
Globalna ocena sieci

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.

🕐 Historia rozmów i ocen
  • ✓ Wszystkie sesje czatu zapisywane w bazie danych
  • ✓ Historia przeglądana w panelu — sesja po sesji
  • ✓ Każda globalna ocena sieci archiwizowana z datą
  • ✓ Oceny per-urządzenie: pełna historia zmian w czasie
  • ✓ Możliwość porównania: „Czy coś się poprawiło od ostatniego miesiąca?"
🔒 Prywatność i transparentność
  • ✓ Do modelu AI trafiają: IP, hostnamy, vendory, porty, typy podatności
  • ✗ Do modelu NIE trafiają: hasła, dane logowania, dane osobowe użytkowników
  • ✓ Pełny podgląd co dokładnie wysłano do AI — widoczne w panelu przy każdej odpowiedzi
  • ✓ Konfigurowalny kontekst AI (ai_context.md) — widoczny i edytowalny przez admina
  • ✓ Brak zewnętrznego telemetrii — tylko Twój klucz API, Twoje zapytania

Dostępny w wersji Community — wymaga własnego klucza Anthropic API. Jak skonfigurować →

Jak to wygląda w praktyce

Panel administracyjny Flask + dashboardy Grafana — działające na prawdziwej sieci testowej.

Lista urządzeń — NetDoc Admin
Lista urządzeń — 35 hostów, statusy UP/DOWN, typy, vendor z OUI
Panel bezpieczeństwa — NetDoc Admin
Bezpieczeństwo — 4 krytyczne, 7 wysokich, 14 średnich podatności wykrytych automatycznie
Asystent AI — analiza bezpieczeństwa
AI Chat — odpowiedź na pytanie o krytyczne podatności, z tabelą IP/port/opis
AI ocena urządzenia MOXA
AI Ocena urządzenia — analiza MOXA NPort, poziom ryzyka, proponowane zamienniki
Zarządzanie sieciami — NetDoc Admin
Zarządzanie sieciami — auto-detekcja podsieci, kalkulator CIDR, lookup MAC → producent (39k+ OUI)
Inwentarz urządzeń — NetDoc Admin
Inwentarz — S/N, asset tag, cena, gwarancja, koniec wsparcia (EoS), eksport CSV
Monitoring łącza Internet / WAN — NetDoc Admin
Internet / WAN — publiczne IP, kraj/ISP, latencja DNS, jitter HTTP
Testowanie domyślnych haseł — NetDoc Admin
Credentials — automatyczne testy 170+ fabrycznych haseł (SSH, HTTP, SNMP, FTP, VNC, RDP…)
AI Asystent sieci
AI Chat — pytaj o podatności, urządzenia, segmentację — AI odpowiada na podstawie danych sieci w czasie rzeczywistym

Zrzuty z rzeczywistej instalacji na sieci testowej (Docker + host Windows). Dane anonimizowane.

Community i Pro

Community jest i pozostanie darmowe. Pro to rozszerzenia dla firm i MSP.

Community
Darmowe / open source
  • Discovery + nmap + OUI (39k+)
  • Skanowanie podatności (33+ typów)
  • Testowanie credentials (10 protokołów)
  • Ping monitoring co 18s
  • Monitoring łącza internetowego
  • Alerty Telegram
  • SNMP enrichment + Modbus TCP
  • Screenshoty interfejsów urządzeń
  • Grafana dashboardy (6 szt.)
  • Demo Lab
  • Syslog ClickHouse (archiwizacja logów)
  • AI Chat + analiza urządzeń (własny klucz API)
  • Raporty PDF + NIS2/DORA Compliance
  • Integracja Zabbix
WKRÓTCE
Pro
/ do ustalenia
  • Wszystko z Community
  • NIS2/DORA Compliance Pack (retencja 12 mies., raporty)
  • Raporty PDF (auto)
  • Integracja Zabbix
  • Alerty email / webhook
  • SNMP Walk (ARP, routing, LLDP)
  • Wsparcie techniczne
  • Bez limitu urządzeń
⚠️
Projekt w fazie beta — nie uruchamiaj w sieciach produkcyjnych bez przygotowania

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.

Uruchom w 2 minuty

Działa na Linux, Windows (WSL2), macOS. Wymagania: Docker + Docker Compose + Python 3.9+ + nmap.

Opcja A — Windows: automatyczny instalator (zalecane)

Pobierz repozytorium, a następnie kliknij dwukrotnie netdoc-setup.bat. Skrypt sprawdzi i zainstaluje wszystkie wymagania (WSL2, Docker Desktop, git, Python), skopiuje konfigurację, uruchomi kontenery i wykona pierwsze skanowanie sieci — na końcu otworzy Panel Admin w przeglądarce z już wykrytymi urządzeniami.

# Pobierz repozytorium
git clone https://github.com/NetPlusRS/netdoc.git
cd netdoc

# Uruchom instalator — resztą zajmie się sam
netdoc-setup.bat

Wymagania systemowe: Windows 10 v2004 (Build 19041) lub nowszy, 8 GB RAM. Pierwsze uruchomienie trwa 5–15 minut (pobieranie obrazów Docker).

🐧 Opcja B — Linux / macOS: automatyczny instalator

Skrypt netdoc-setup.sh sprawdza i instaluje wymagania (Docker, nmap, Python), kopiuje konfigurację, uruchamia kontenery, wykonuje pierwsze skanowanie i dodaje autostart skanera do crontab.

# Pobierz repozytorium
git clone https://github.com/NetPlusRS/netdoc.git
cd netdoc

# Uruchom instalator — resztą zajmie się sam
chmod +x netdoc-setup.sh
./netdoc-setup.sh

Wymagania: Docker + Docker Compose v2, Python 3.10+, nmap (skrypt zainstaluje brakujące pakiety). Ubuntu/Debian, Fedora, macOS (Homebrew). Pierwsze uruchomienie trwa 5–15 minut.

⚙️ Opcja C — instalacja ręczna (wszystkie systemy)
git clone https://github.com/NetPlusRS/netdoc.git
cd netdoc

# Konfiguracja
cp .env.example .env      # Linux / macOS
# copy .env.example .env  # Windows (cmd)

# Kontenery
docker compose up -d

# Panel Web
http://localhost         # NetDoc Admin
http://localhost/grafana # Grafana  (admin / netdoc)
Wymagane na hoście (skaner discovery):
  • nmapsudo apt install nmap / brew install nmap / nmap.org
  • Python 3.10+ + pip install -r requirements.txt
# Zainstaluj zależności i uruchom pierwsze skanowanie
pip install -r requirements.txt
python run_scanner.py --once

Autostart skanera: crontab (Linux/macOS) lub install_autostart.ps1 (Windows Task Scheduler).

🖥️ Jak zainstalować WSL2, Docker i git na Windows — krok po kroku

Jeśli wolisz instalować ręcznie lub chcesz wiedzieć co robi netdoc-setup.bat — poniżej kompletna instrukcja krok po kroku. Wymagania: Windows 10 v2004+ (Build 19041), 8 GB RAM, 64-bit.

Krok 1 — Windows Package Manager (winget)

winget to menedżer pakietów wbudowany w Windows 10/11. Sprawdź czy jest dostępny:

winget --version

Jeśli nie działa — zainstaluj App Installer z Microsoft Store lub zaktualizuj Windows.

Krok 2 — WSL2 (Windows Subsystem for Linux)

Docker Desktop na Windows wymaga WSL2. Otwórz PowerShell jako Administrator (prawy klik na menu Start → Terminal (Administrator)) i wpisz:

wsl --install

Po zakończeniu zrestartuj komputer — WSL2 wymaga restartu przy pierwszej instalacji.

Krok 3 — Docker Desktop

Zainstaluj Docker Desktop przez winget (lub pobierz ręcznie z docker.com):

winget install -e --id Docker.DockerDesktop

Po instalacji uruchom Docker Desktop z menu Start. Poczekaj aż ikonka wieloryba w zasobniku przestanie się animować — Docker jest gotowy gdy pokazuje "Engine running".

Krok 4 — git
winget install -e --id Git.Git

Po instalacji otwórz nowe okno terminala (git jest dodawany do PATH).

Krok 5 — Python 3 (dla skanera działającego na hoście)
winget install -e --id Python.Python.3.12
Krok 6 — nmap (wymagany przez skaner portów)

NetDoc używa nmap do skanowania portów i wykrywania systemu operacyjnego urządzeń. Musi być zainstalowany na hoście (nie wewnątrz Dockera).

# Windows:
winget install -e --id Insecure.Nmap
# Ubuntu / Debian:
# sudo apt install nmap
# macOS:
# brew install nmap

Windows: nmap instaluje się domyślnie w C:\Program Files (x86)\Nmap\ i powinien być dodany do PATH automatycznie. Weryfikacja: nmap --version

Weryfikacja — sprawdź czy wszystko działa
docker --version    # Docker version 27.x lub nowszy
docker compose version
git --version
python --version   # Python 3.9 lub nowszy
nmap --version     # Nmap 7.x lub nowszy
🗑️ Jak zatrzymać lub odinstalować NetDoc

Jeśli chcesz zatrzymać NetDoc (np. na czas nieużywania) lub całkowicie go usunąć — dołączony skrypt przeprowadzi Cię przez cały proces bez pozostawiania śmieci w systemie.

Opcja A — Automatycznie (zalecane)

Uruchom dołączony instalator — wyświetli menu z trzema opcjami:

# Dwukrotne kliknięcie lub z terminala:
netdoc-uninstall.bat
[1] Zatrzymaj kontenery  — dane zachowane, można wznowić w każdej chwili
[2] Pełne odinstalowanie  — usuwa kontenery, voluminy, zadania Task Scheduler
[3] Anuluj

Skrypt wymaga potwierdzenia tekstowego przed usunięciem danych i informuje co zostało zachowane po zakończeniu. Log debugowania zapisywany automatycznie (netdoc-uninstall-debug-*.log).

Opcja B — Ręcznie (terminal)
# Tylko zatrzymanie (dane w bazie zachowane):
docker compose stop

# Wznowienie po zatrzymaniu:
docker compose start

# Usunięcie kontenerów i danych (nieodwracalne!):
docker compose down --volumes --remove-orphans

# Usunięcie zadań Task Scheduler (PowerShell jako Admin):
Unregister-ScheduledTask -TaskName "NetDocScanner" -Confirm:$false
Unregister-ScheduledTask -TaskName "NetDoc Watchdog" -Confirm:$false
ℹ️ Co pozostaje po odinstalowaniu

Skrypt nie usuwa Docker Desktop, Pythona, gita ani katalogu projektu (pobrany przez git clone). Są to narzędzia systemowe — możesz je usunąć ręcznie przez Ustawienia → Aplikacje jeśli nie są Ci potrzebne.

Co jest w planie

Aktywnie rozwijany projekt. Pełna mapa rozwoju dostępna na GitHub.

Mapa topologii sieci W trakcie
Wizualny graf połączeń L2/L3 generowany automatycznie z danych LLDP/CDP i tablic ARP. Zobaczysz które switch łączy się z którym routerem i gdzie są urządzenia końcowe — bez ręcznego rysowania.
SNMP Walk — pełny odczyt W trakcie
Pobieranie tablic ARP, routingu i listy sąsiadów LLDP bezpośrednio z routerów i switchy przez SNMP. Uzupełnia topologię o dane których nmap nie widzi.
Threat Intelligence Planowane
Automatyczne sprawdzanie adresów IP i domen z czarnymi listami (AbuseIPDB, Spamhaus DROP/EDROP, URLhaus, abuse.ch). Alert gdy urządzenie w sieci nawiąże połączenie z infrastrukturą malware, ransomware lub C2 — zanim użytkownik zauważy problem.
NetFlow / sFlow — analiza ruchu Planowane
Zbieranie i analiza przepływów sieciowych z routerów obsługujących NetFlow/sFlow. Wykrywanie anomalii ruchu: eksfiltracja danych, lateral movement, nieautoryzowane połączenia między segmentami sieci.
NIS2 / DORA Compliance Pack Planowane
Gotowe raporty dla audytorów: retencja logów 12 miesięcy, rejestr incydentów, inwentarz aktywów, historia zmian. Odpowiedź na wymagania NIS2 Art. 21 i DORA bez zatrudniania zewnętrznego konsultanta.
Raporty PDF Planowane
Eksport stanu sieci, podatności i inwentarza do PDF — gotowy do wysłania do zarządu lub klienta. Automatyczne raporty cykliczne (tygodniowy, miesięczny) wysyłane emailem.
Alerty email / webhook Planowane
Powiadomienia SMTP gdy urządzenie przestaje odpowiadać, wykryto nową podatność krytyczną lub credential testing znalazł domyślne hasło. Webhook do integracji z Teams, Slack lub własnym systemem.
CVE per model urządzenia Planowane
Automatyczne przypisywanie znanych podatności CVE do wykrytych modeli urządzeń na podstawie bazy NVD (NIST). Dowiesz się że Twój router ma CVE-XXXX-YYYY bez ręcznego przeszukiwania bazy.
AI Anomaly Detection — offline Długoterminowe
Lokalny model AI (bez wysyłania danych na zewnątrz, bez dodatkowych kosztów API) analizujący logi syslog w poszukiwaniu anomalii: nagły wzrost liczby błędów, nowe nieznane urządzenia, sekwencje zdarzeń typowe dla ataku (failed login → skan portów → udane logowanie). Dane zostają w Twojej sieci.
DNS Monitoring Długoterminowe
Integracja z Pi-hole lub Unbound — zbieranie historii zapytań DNS z sieci per urządzenie. Wykrywanie zapytań do złośliwych domen, tunelowania DNS i komunikacji C2 ukrytej w ruchu DNS. Wymagane przez NIS2 Art. 21 jako element monitorowania.
Integracje SIEM / IDS Długoterminowe
Korelacja alertów z systemami bezpieczeństwa z konkretnymi urządzeniami w NetDoc: Wazuh (SIEM — który asset jest atakowany), Suricata/Zeek (IDS/IPS — logi połączeń per host), CrowdSec (community threat intel), Elastic/Splunk (forward logów).
EoL / EoS baza urządzeń Długoterminowe
Automatyczne oznaczanie urządzeń które osiągnęły End-of-Life lub End-of-Support u producenta. Dowiesz się że Twój switch nie dostaje już aktualizacji bezpieczeństwa — zanim zrobi to audytor.
Integracja z GNS3 Długoterminowe
Połączenie NetDoc z symulatorem sieci GNS3 — skanowanie wirtualnych topologii złożonych z prawdziwych obrazów Cisco IOS, Juniper, MikroTik. Idealne do testowania przed wdrożeniem w produkcji: mapowanie topologii L2/L3, weryfikacja wykrywalności podatności i testowanie reguł firewall w kontrolowanym środowisku bez ryzyka dla sieci produkcyjnej.

W trakcie    Planowane    Długoterminowe

Porozmawiajmy

Pytania o NetDoc, wdrożenie, wersję Pro lub współpracę — napisz przez LinkedIn.

Dane firmy

🏢
Nazwa
Net Plus Radosław Skonieczny
📋
NIP/VAT
PL 9511958766
📍
Adres
Warszawska 2H/37
05-825 Grodzisk Mazowiecki
📞
Telefon

W czym mogę pomóc?

🚀
Wdrożenie NetDoc

Instalacja, konfiguracja, integracja z istniejącą infrastrukturą. Możliwe wdrożenie SaaS (u mnie) lub on-site (na Twoich serwerach).

🔍
Audyt i bezpieczeństwo sieci

Inwentaryzacja urządzeń, wykrywanie podatności, domyślne hasła, ekspozycja protokołów IoT/OT. Raport z priorytetami działań.

🏗️
Modernizacja i porządkowanie sieci

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).

🖥️
Wirtualizacja i infrastruktura

Projektowanie i wdrożenie środowisk wirtualnych, dobór i dostawa sprzętu serwerowego, migracja do nowej infrastruktury.

🤝
Opieka IT dla firm bez działu IT

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ć.

Pełna oferta usług IT dostępna na monitoringit.network
Kanały kontaktu
💼 Kontakt biznesowyLinkedIn
🐛 Błędy i pytania techniczneGitHub Issues
💬 Dyskusje o projekcieGitHub Discussions
🧪 Pomóż ulepszyć bazę urządzeń

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.