Jak złapać hakera na garnek miodu, czyli Veeam honeypot

Wiele w ostatnim czasie pisze się o cyberbezpieczeństwie, również w kontekście backupów – kopie immutable, reguła 3-2-1, szyfrowania itp. itd. etc. Ale jest też opcja, o której często zapominamy czyli honeypot lub „decoy server” lub też serwer przynęta. Czyli zastawiamy na hakera pułapkę w postaci „lewego” serwera Veeama którego „nie zabezpieczamy” 😁 i wystawiamy go jako przynętę. Oczywiście nie jest to prawdziwy VBR, lecz go udający – nasłuchuje na tych samych portach co prawdziwy serwer Veeama, więc skanery portów mogą się łatwo pomylić – i o to nam chodzi. Gdy haker będzie próbował przeskanować taki serwer, odpowiednie polityki powiadomią nas mailowo lub nasz system SIEMowy.

Żeby nie wymyślać koła na nowo, można skorzystać z gotowca Veeamowego.

Veeamowego honeypota można zainstalować na 2 sposoby – oba opisane szczegółowo na:

https://github.com/VeeamHub/veeam-decoy :

• ściągając gotowy obraz OVA
• na własnym RedHacie/Rockym

Ja wybrałem drugą opcję. Jeżeli korzystamy z własnej instalacji Linuxa, należy pamiętać o wyłączeniu firewall’a oraz SElinuxa – przecież nie chcemy utrudniać pracy hakerowi 😉

Gdy mamy już zainstalowanego Linuxa to „emulator” VBRa instalujemy jedną komendą z githuba

curl -s https://raw.githubusercontent.com/VeeamHub/veeam-decoy/master/install.sh | bash

Jeżeli mamy kilka kart sieciowych to możemy zasymulować różne role serwerów Veeama na różnych IPkach naszej przynęty, np. na jednym backup serwer i enterprise manager, a na innym hardened repozytorium. Można oczywiście odpalić symulacje all-in-one, chociaż tu też trzeba ostrożnie, jednoczesne odpalenie roli repozytorium windowsowego i hardened repo będzie próbować emulować te same porty (6160, 6162). Unikałbym też jednoczesnego emulowania na tej samej maszynie VBRa (windowsowego) i hardend repo. To może być podejrzane dla hakerów, że na jednym IP są role windowsowe (np. VBR serwer lub RDP) i linuxowe (np. SSH). Możliwe, że będziecie musieli też dopasować w pliku konfiguracyjnym nazwy interfejsów, na których mają się rozgłaszać usługi. Zwłaszcza jeżeli macie kilka kart sieciowych.

Sama przynęta to oczywiście za mało, musimy jeszcze kogoś powiadomić, gdy będzie pożar w … jeżeli ktoś będzie próbował go skanować. I tutaj mamy dwie opcje: powiadomienia mailowe oraz przesłanie logów do syslog serwera. Konfigurujemy zatem ustawienia poczty i/lub rsysloga. Pamiętajmy, że po skonfigurowaniu serwera na logi – musimy jeszcze zrestartować symulowane usługi, żeby przyjęły nowe ustawienia. Wynik wpadających (nieobrobionych danych) może wyglądać jak poniżej

Gdy już wszystko mamy już ustawione, jeszcze szybki test przeskanowania naszej spreparowanej „ofiary” np. nmapem, proponuje np.

nmap -sS -p 1-65535 -T4 -A -v -Pn <targetIP>

żeby zasymulować skanowanie portów i wyciągnąć pare innych informacji.

Po takim lub podobnym skanie haker będzie wiedział że jest tam coś Veeamowego, a my że mamy hakera w sieci.

Podsumowując: bezpieczeństwo, bezpieczeństwo i jeszcze raz bezpieczeństwo. Każda funkcjonalność, która w jakiś sposób podniesie nasze cyberbezpieczeństwo jest warta rozważenia i wdrożenia. Honeypot jest łatwym w zaimplementowaniu rozwiązaniem (wymagania na Linux są niewielkie) i może dać wymierne korzyści jako dodatkowy strażnik naszej infrastruktury.