O panelu tym zaczęliśmy pisać w części piątej, gdzie wspomnieliśmy o niezbędnych mechanizmach od strony funkcjonalnej. Dzisiaj skupimy się na tym, jak taki panel zrealizować od strony stricte technicznej, zaś w części dziesiątej wrócimy do tematu raz jeszcze, aby opisać konkretne flowy związane z obsługą „klienta”, czyli wyceną okupu, indywidualnymi negocjacjami, przyjęciem płatności i przekazaniem dekryptora.

Zasady naczelne

Zanim przejdziesz do myślenia o którymś ze szczegółowych aspektów panelu, zapamiętaj dwie zasady naczelne, którymi powinieneś się kierować projektując taki panel:

1. Minimalizm

Zarówno w ilości zbieranych danych (nie zapominaj, że Twoim celem są pieniądze, a nie „trofea” związane z poszczególnymi „klientami”), jak i w formie – np.:

• zwykłe, proste, „surowe” zapytania GET są dużo lepsze od „ładnego” REST API
• zwykłe zapytania SQL są dużo lepsze od narzędzi ORM – a jeszcze lepsze jest zastosowanie zwykłych plików CSV lub tekstowych zamiast jakiejkolwiek bazy danych

2. Nie rób niczego tak, jak byś to zrobił w „dziennej” pracy.

Przede wszystkim dotyczy to stosowania narzędzi, technik i standardów wspomagających pracę zespołową nad dużymi projektami, np.:

• testy jednostkowe
• wzorce projektowe
• frameworki, serwery aplikacji, biblioteki ORM i inne mechanizmy typowe dla danego języka
• standardy formatowania i komentowania kodu
• nazewnictwo plików, katalogów, zmiennych czy czegokolwiek innego

To oczywiście nie oznacza, że musisz na siłę tworzyć źle wyglądający kod – natomiast zdecydowanie trzymaj się domyślnego sposobu formatowania kodu narzuconego przez jakiś edytor lub IDE. Najlepiej też aby edytor ten, jak i jego domyślny sposób formatowania kodu, były:

• inne od tych, których używasz w „dziennej” pracy
• w miarę popularne (nie używaj zbyt niszowych narzędzi)
• łatwe do uruchomienia, bez konieczności instalacji dodatkowych pluginów, słowników, czy innych dodatków – względnie dostępna jest wersja już wyposażona w komplet potrzebnych dodatków

Implementacja panelu

• Jaki język programowania?
• Jak dobrze sobie radzisz w tym języku?
• Czy w ramach dotychczasowego doświadczenia w tym języku używasz jakichś konkretnych bibliotek, frameworków lub innych narzędzi? A jak sobie radzisz bez ich użycia?
• Jak implementujesz połączenie z bazą danych, wykonywanie zapytań i wyświetlanie wyników? (nie chodzi o kwestie bezpieczeństwa, a o sposób implementowania charakterystycznych elementów – np. iterujesz po wyniku za pomocą funkcji mysql, czy mapując wynik na obiekt i działając na obiekcie?)

Stylometria

Poczytaj więcej o tej technice ustalania potencjalnego autora kodu na podstawie stylu tego kodu (albo tekstu).

• Czy jesteś autorem jakiegoś kodu open source?
• Odpowiadałeś komuś na forum typu StackOverflow, podając przykłady kodu?
• A może Twój kod napisany dla jakiejś firmy „wyciekł” i jest/był nielegalnie dostępny w Internecie?
• A co z projektami uczelnianymi? Mogły zostać wrzucone do systemów antyplagiatowych również po ukończeniu przez Ciebie studiów.

Jak zbierać dane?

Trzymanie na serwerze pełnej historii danych:

• to możliwość przejęcia jej w całości przez organy ścigania lub konkurencję
• to możliwość utraty jej w całości wskutek awarii sprzętu, o ile nie masz backupu danych (i jak taki backup zorganizować, aby niechcący się nie zdeanonimizować: do jakich miejsc, jakimi narzędziami, w jakich porach, unikając konwencji konfiguracyjnych typowych dla „dziennej pracy” itp.)
• wymaga przestrzeni dyskowej, która prawie na pewno będzie dużo droższa od przestrzeni lokalnej, niezależnie od tego, na jakich zasadach rozliczasz się za hosting

Skąd go hostować, aby był w miarę niezawodny?

• Powinien być połączony z endpointami do raportowania zdarzeń z komputerów?
• A może wprost przeciwnie, powinien być w całkiem innym miejscu?
  • Ale jak wtedy wymieniać dane pomiędzy serwerem sterującym a panelem? scp czy raczej https?
  • Jak podzielić dane na części, aby nie utrudniało to pracy, a jednocześnie aby nie pchać w kółko wielkich plików z tymi samymi danymi?
  • Która strona transmisji powinna być widoczna (publiczne IP lub przekierowanie portu)?
  • Która strona transmisji powinna posiadać klucz pozwalający na nawiązanie łączności?
• Czy powinien być ukrytą usługą, dostępną tylko w sieci Tor?
• Co z niezawodnością i sytuacjami, gdy panel nie działa? A co gdy nie działają endpointy do raportowania zdarzeń? Potrzebujesz jakiegoś mechanizmu „spróbuj ponownie” po stronie programu szyfrującego, czy wolisz po prostu zostawić takie przypadki samym sobie?
  • HA w większości przypadków nie rozwiązuje problemu, bo co jeśli problem z łącznością jest po stronie szyfrowanego komputera, a nie po stronie serwera?

Kolejne osoby do pomocy w „biznesie”

• Po co w ogóle chcesz i czy na pewno musisz brać do pomocy inne osoby? Ogólna zasada w kryminalistyce jest taka, że w grupie 2-osobowej ryzyko wpadki wzrasta o 50% z samego tylko powodu współpracy 2 osób, w grupie 3-osobowej o 75% itd.
• Jak chcesz zarządzać uprawnieniami do poszczególnych funkcji w panelu? Zwykłe http auth i potem operowanie na zmiennej z nazwą zalogowanego użytkownika? Czy może jakaś forma operowania na rolach/grupach dostępowych? (pamiętaj o zasadach naczelnych!)
• Na jakim etapie znajomości/współpracy/zaufania chcesz tworzyć nowych użytkowników?
• Jak chcesz weryfikować, czy nie są to podstawione osoby? Albo inaczej: jak chcesz minimalizować swoje straty, jeśli taka osoba okaże się być np. funkcjonariuszem policji?
• Czy chcesz implementować w panelu mechanizmy typu honeypot, weryfikujące uczciwość takich użytkowników wobec Ciebie i np. automatycznie blokujące im uprawnienia w przypadku zarejestrowania niepożądanych aktywności?
• Co z nazewnictwem kont? Zdajesz sobie sprawę, że szukanie powiązań pomiędzy nazwami użytkowników (w tym pomiędzy różnymi stronami) to jedna z podstawowych metod śledczych w IT?
• Jak ci użytkownicy mogą sobie bezpiecznie (aby tylko oni je znali) zmieniać hasła? Czy też potrzebują do tego Twojej pomocy?

Kopiowanie danych z szyfrowanych komputerów

• Potrzebujesz aktywnej łączności z poszczególnymi komputerami, czy wystarczą ci pasywne informacje o zdarzeniach na tych komputerach? Pamiętasz o tym, co pisaliśmy w części piątej? Jeśli mimo wszystko potrzebujesz więcej danych, to w jakim celu?
• Na ile istotna jest dla ciebie możliwość szybkiego podglądu wybranych komputerów i zdalnego skopiowania ich zawartości? Chcesz tą zawartość kopiować przed czy po zaszyfrowaniu (masz klucz, więc sobie rozszyfrujesz)? Przed czy po pokazaniu użytkownikowi komunikatu o infekcji?
• Gdzie te dane miałyby być kopiowane: na serwer sterujący, czy podany ad hoc inny serwer?
• Co z ograniczeniami prędkości łącza, łączami z płatnym transferem danych, czy wreszcie brakiem publicznego IP?
• Jakiego protokołu chciałbyś użyć? Czy wymaga on przekazania na komputer ofiary klucza pozwalającego na zdalny dostęp do Twojego serwera? Co jeśli z jakichś losowych przyczyn utracisz dostęp do tego komputera, zanim zdążysz trwale usunąć ten klucz?

W kolejnej części – informowanie użytkownika o infekcji.

Intencją autorów ani wydawcy treści prezentowanych w magazynie PAYLOAD nie jest namawianie bądź zachęcanie do łamania prawa. Jeśli popełniłeś lub masz zamiar popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeśli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.

Nie zezwala się na użycie treści prezentowanych w magazynie PAYLOAD, ani produktów dostępnych w sklepie PAYLOAD, do celów popełniania przestępstw lub przestępstw skarbowych.