Jak zapobiec fałszowaniu tożsamości w grze wieloosobowej?


9

Myślę o klientach fałszujących adresy IP, oszukujących innych klientów, że są oni serwerami; tego rodzaju rzeczy. (Nie wiem za dużo o tym, więc jeśli to całkowicie nie tak, popraw mnie).

Co powinienem zrobić, aby temu zapobiec? Ponieważ jest to gra w czasie rzeczywistym, gdybym miał używać szyfrowania, użyłbym czegoś szybkiego i bezpiecznego, takiego jak RC4. Czy powinienem szyfrować dane pakietu kluczem, który serwer przekazuje klientowi?

Jeśli robi to jakąkolwiek różnicę, używam UDP.

Odpowiedzi:


8

Jednym z możliwych rozwiązań jest uwierzytelnienie użytkownika za pomocą protokołu TCP + TLS; następnie w tym samym kanale użyj czegoś takiego jak Diffie-Hellman, aby wynegocjować klucz symetryczny. Na koniec zaszyfruj każdy pakiet UDP przy użyciu symetrycznego algorytmu, takiego jak RC4.

Technicznie nie musisz używać TCP + TLS do negocjowania klucza symetrycznego, jeśli używasz czegoś takiego jak SRP - pamiętaj tylko, że czysty Diffie-Hellman jest podatny na atak MITM .

Możesz pójść jeszcze dalej i użyć niestandardowego pola SEQ w pakietach UDP (jeśli korzystasz z pewnej formy niezawodnego UDP), aby zaimplementować formę szyfrowania w trybie przeciwnym - w którym dodajesz numer SEQ do negocjowanego klucza dla każdego pakietu; znacznie trudniej jest przeprowadzić atak znanym tekstem.

Nie pozwól, aby serwer rozdawał klucze do woli - serwer „sfałszowany” mógłby równie łatwo wydać własny klucz; pokonanie celu całego systemu szyfrowania. Jedynym zapewnionym sposobem jest skorzystanie z TLS lub wzajemnej wiedzy (np. Hasło / skrót).


Czy mógłbyś dokładnie opisać, jakie luki by to zamknęło? Słyszałem o fałszowaniu adresów IP i tym podobnych, ale nie jestem wykształcony na ten temat
liamzebedee,

@ LiamE-p GameDev nie jest miejscem awaryjnego kursu bezpieczeństwa; nie mam też czasu na rozdanie. Zasadniczo SRP i TLS (oba) powinny być tak bezpieczne, jak witryna bankowości internetowej - SRP bardziej w trybie CTR. Jeśli potrzebujesz więcej wyjaśnień, zapytaj na stronie Security SE.
Jonathan Dickinson,

To zdecydowanie byłoby na temat bezpieczeństwa SE. Zgłaszam mod, aby go tam przenieść.
Rory Alsop,

8

Mam odległe (2 lata temu) doświadczenie w hakowaniu, najtwardsze pakiety, jakie kiedykolwiek złamałem (i to, co sugeruję, że używasz), używa symetrycznej metody szyfrowania klucza, którą w skrócie opisał Jonathan Dickinson. Powinieneś używać TCP + TLS, jak również wspomniał. Powiedział jednak sekwencję przeciwną.

Wpadłem w czasy, kiedy programista „odporny na włamanie” system był łatwo sfałszowany, ponieważ mają wystarczająco dziwny system liczenia, że ​​mógłbym go złamać bez wiedzy programistycznej i logiki algebraicznej z pierwszego roku. Tak długo, jak wybierzesz odpowiednią metodę sekwencyjną, twój cel powinien otrzymywać dane dokładnie zgodnie z oczekiwaniami, co oznacza również, że powinieneś używać TCP do najbezpieczniejszych operacji.

Wracając do „moich doświadczeń”, jeden system, który znalazłem, działa fantastycznie. Metoda sekwencyjna oparta na wysyłanym czasie i oczekiwanym czasie. Ponieważ pakiety muszą zawsze być odbierane w odpowiedniej kolejności, sfałszowanie pakietu było prawie niemożliwe, ponieważ nigdy nie mogłem przewidzieć, kiedy pakiet zostanie wysłany i kiedy jest oczekiwany (między jednym pakietem a drugim) bez uprzedniego włamania się do programu klienckiego.

Krótka odpowiedź

W skrócie: Każda struktura pakietu będzie miała także znacznik czasu, tak jak wtedy, gdy był wysyłany do milisekundy. To cholernie proste i bardzo łatwo jest sprawdzić, czy czas jest przed / po innym czasie. Powodem, dla którego ma to tak dobry sens, jest to, że serwer może nadal odbierać pakiety w celu sfałszowania, bez czasu na uwierzytelnienie.

To oczywiście nie jest jedyna metoda sekwencyjna ani nawet najlepsza z dowolnej metody. Odkryłem, że działa bardzo dobrze. W połączeniu z TCP + TLS nie powinieneś mieć zbyt wielu problemów.


Problem z grami polega na tym, że rzeczy dzieją się na poziomach poniżej milisekund.
Jonathan Dickinson

@JathanathanDickinson To całkowicie prawda. Ale używając UDP, a zwłaszcza TCP, należy stosować algorytmy martwego obliczania dla operacji poniżej milisekundy, a nawet wielu milisekund. Ma to oczywiście na celu przyspieszenie, oprawę graficzną i niektóre elementy zza kulis. (głównie związane z prędkością)
Joshua Hedges

6
Wydaje mi się, że pod koniec dnia jest to gra, a nie system kontroli satelitarnej z promieniem śmierci. +1
Jonathan Dickinson

4

Osobiście nie przesadziłbym zbyt wcześnie. Nawet jeśli szyfrujesz swoje pakiety, jak zaleca Jonathan, hakerzy tacy jak mój brat będą mieli dostęp do danych pakietu, zanim zostaną zaszyfrowane. Jeśli złośliwi użytkownicy chcą wejść, znajdą sposób na wejście.

Teraz, gdy jest to niemożliwe, programiści niezależni mogą zminimalizować szkody wyrządzone przez szkodliwych użytkowników. Prawdopodobnie powinieneś zaszyfrować pakiety wychodzące, ale to powstrzyma tylko niektóre rodzaje ataków, nie daj się zwieść, że teraz jest to „dowód na hack”. Aby naprawdę wyłączyć hakerów, daj klientom możliwie najmniejszą kontrolę nad grą. Jedna z tych wielkich gier MMO pozwalała klientom powiedzieć serwerowi, ile XP zdobyli. Zgadnij, co się tam stało? Nie rób tego Pozwól klientowi powiedzieć serwerowi, że chce rzucić jakieś super-zaklęcie na stworzenie, a następnie pozwól serwerowi rozpatrzyć akcję, a następnie dodać XP, gdy stworzenie nie żyje. Klienci powinni być cienkimi, głupimi terminalami, które mogą wysyłać i odbierać polecenia oraz wykonywać pewne prognozy (jeśli to konieczne).gra i reagować na polecenia wysyłane przez klientów.

Duże firmy produkujące gry wykorzystują powyższe elementy oprócz VAC lub PunkBuster, aby uniemożliwić znanym hakerom zakłócanie płacenia klientom. Sposób działania tych środków bezpieczeństwa jest utrzymywany w tajemnicy, ale znam jedną metodę, z której korzystają: skanują obecnie uruchomione aplikacje i porównują je z listami znanych hacków. Gdy zostaniesz przyłapany na oszustwie, nie będziesz mógł dołączyć do zabezpieczonych serwerów VAC / PunkBuster.

Związane z: Logika gry na serwerze! Dobry czy zły?

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.