Zainfekowane hosty i źródła ataków w Twojej sieci

Ustalenia i poziom pewności

Ustalenie to jedno zagrożenie na jednym adresie w ciągu jednego dnia. Każde ma poziom pewności, wysoki albo średni, i listę wystąpień. Rodzaje ustaleń w panelu

Jak rozpoznajemy ruch do serwerów C2, reflektory i źródła ataków

Duże natężenie także nie wystarcza: abonent, który wysyła plik na atakowany serwer, bywa jednym z nadawców o największym natężeniu. Reflektory i źródła ataków ustalamy wyłącznie na podstawie ataków, dla których system wykrywania uruchomił mitygację i które NOC potwierdził albo jeszcze nie ocenił. Gdy NOC później uzna atak na przykład za fałszywy alarm, ustalenia oparte na nim znikają. Ruch do serwera C2 widzimy tylko wtedy, gdy przechodzi przez naszą sieć.

Odnalezienie abonenta za CGNAT

Za adresem z puli CGNAT pracuje wielu abonentów, więc sam adres nie wskazuje hosta. Wskazuje go wystąpienie: czas i port lokalny.

Adres i port zdalny pokazujemy przy ruchu do serwera C2, bo wynikają z przepływów zarejestrowanych na naszych routerach. Przy reflektorze wystąpienie ma port usługi, która odbijała ruch, a przy źródle ataku czas.

1. Rozwiń ustalenie w Centrum bezpieczeństwa i odczytaj wystąpienia, od najnowszego.
2. Przelicz czas na strefę dziennika NAT. Panel podaje czas w strefie Twojej przeglądarki, a API w UTC.
3. Szukaj translacji adresu i portu lokalnego aktywnej w tej minucie, bo wystąpienie ma dokładność do minuty. Przy przydziale portów blokami szukasz bloku, który obejmuje port lokalny.
4. Gdy dziennik zapisuje także adres docelowy, adres i port zdalny potwierdzają trafienie.
5. Przy źródle ataku, bez portu, czas zawęża wybór do abonentów korzystających z adresu w tej minucie.

Przepływy pochodzą z próbek sFlow, więc lista wystąpień nie obejmuje każdego połączenia hosta. Ustalenie przechowuje do 500 wystąpień.

Ustalenia i wystąpienia pobierzesz też przez API, kluczem z zakresem events:read. GET /security zwraca ustalenia, a GET /security/findings/{id}/samples wystąpienia jednego ustalenia.

# źródła ataków z ostatnich 7 dni
curl -s "https://api.nera.pl/api/v1/security?days=7&kind=attack_source" \
  -H "X-Api-Key: nera_live_xxxxxxxxxxxxxxxxxxxx"

# wystąpienia jednego ustalenia, czas w UTC
curl -s https://api.nera.pl/api/v1/security/findings/$FINDING_ID/samples \
  -H "X-Api-Key: nera_live_xxxxxxxxxxxxxxxxxxxx"

[
  {
    "at": "2026-10-03T14:07:00Z",
    "local_port": 51234,
    "remote": "198.51.100.7",
    "remote_port": 443,
    "protocol": 6
  }
]

Stan monitorowania

Pusta lista przy stanie innym niż aktywne nie oznacza braku zagrożeń. Kafel „Monitorowanie” podaje też czas ostatniego udanego sprawdzenia.

Co zrobić z ustaleniem

• Host, który łączy się z serwerem C2: odizoluj go albo zawiadom abonenta.
• Reflektor: zamknij otwartą usługę. Zasady korzystania z usługi dają na to 3 dni robocze od naszego zgłoszenia.
• Źródło ataku: sprawdź host i jego ruch wychodzący w czasie wystąpień.
• Eksport CSV przeniesie ustalenia do Twojego systemu zgłoszeń. Plik ma kolumny: rodzaj, adres, zagrożenie, serwer i port C2, pewność, pierwsze i ostatnie wystąpienie oraz liczbę wystąpień, z czasem w UTC.

Ustalenie w Centrum bezpieczeństwa samo niczego w usłudze nie zmienia.

Zamknięcie otwartej usługi UDP

Za odbicie uznajemy odpowiedź UDP z portu usługi, która wzmacnia ruch, na inny port. Najczęstsze z tych usług i sposób ich zamknięcia:

Do tych usług należą też porty 69 (TFTP), 111 (rpcbind), 137 (NetBIOS), 427 (SLP), 520 (RIPv1), 1434 (MSSQL), 1701 (L2TP), 3283 (ARMS), 5353 (mDNS), 5683 (CoAP) i 10001 (wykrywanie urządzeń Ubiquiti). Klasy amplifikacji i ich porty źródłowe podaje artykuł o rodzajach ataków. Amplifikacja: porty usług odbijających