Jak działa hack?

Jak wiadomo, serwery z przed ery SteamCMD są narażone na atak polegający na "wpychaniu" na serwer dodatkowych plików, które infekują serwer. Hack ten jednak nie potrafi bezpośrednio modyfikować plików, może tylko stworzyć nowe. Ale już stworzony przez niego plik, np plugin może dokonać całkowitego spustoszenia. Jednak jako zabezpieczenie przed hackiem wystarczy uniemożliwić tworzenie nowych plików.

Warunki

UWAGA!! Aby ten sposób zabezpieczenia serwera działał prawidłowo, hosting na którym mamy serwery musi spełnić co najmniej 2 warunki. Inaczej metoda ta nie zadziała.

Warunek 1: umożliwienie zmiany praw dostępu (CHMOD) na pliki i foldery w katalogu serwera.

Warunek 2: nie przywracanie domyślnych praw dostępu, gdy jest to niepotrzebne.

Dodatkowo jest jeszcze 1 warunek, bez którego się można obyć, ale wrzucanie nowych plików do zabezpieczonych folderów będzie mocno utrudnione.

Ten warunek to: oddzielne konto użytkownika dla uruchamiania serwera i dla użytkownika FTP, dodatkowo oba te konta muszą mieć wspólną, unikalną grupę.

Sprawdzanie warunków

No jakoś musimy sprawdzić, czy wszystko jest spełnione. W dalszej części poradnika będę posługiwał się WYŁĄCZNIE programem FileZilla, nie napiszę osobnego opisu dla Total Commandera (bo jest przestarzały i się do FTP nie nadaje) ani dla innych programów (bo ich nie znam... no prócz mc, ale kto go używa, ten sam sobie poradzi).

Wchodzimy więc przez FileZillę na serwer i przechodzimy do cstrike/addons/amxmodx/configs. Tworzymy tutaj nowy plik o dowolnej nazwie, teraz klikamy F5, aby widok katalogu się odświeżył i klikamy prawym przyciskiem myszy na nowo utworzony plik, z menu wybieramy Prawa pliku... (File Permissions...). Widzimy tutaj 9 "oczek" do zaznaczenia oraz wartość numeryczną. Krótki opis:

pierwszy wiersz dotyczy właściciela pliku, tj nas samych (użytkownik FTP), drugi wiersz dotyczy praw dostępu do pliku dla użytkowników, którzy należą do grupy do której należy również ten plik (plik posiada użytkownika, który jest jego właścicielem oraz ma przydzieloną grupę użytkowników). Trzeci wiersz dotyczy całej reszty użytkowników.

Prawo odczytu (pierwsza kolumna) to wiadomo, możliwość odczytu pliku.

Prawo zapisu (druga kolumna) to odpowiednio możliwość zapisu pliku (ale nie tworzenia lub usuwania!)

Prawo wykonania (trzecia kolumna) to możliwość uruchomienia pliku, np serwera HLDS.

Dla folderów prawa są troszkę inne

Prawo odczytu umożliwia zobaczenie jakie pliki są wewnątrz katalogu

Prawo zapisu pozwala na tworzenie, usuwanie oraz zmianę nazwy plików (prawa odczytu i zapisu dla pliku nie mają tu znaczenia!) wewnątrz katalogu

Prawo wykonania umożliwia przejście do katalogu (dla FTP jest wymagane do odczytu katalogu, tak jak prawo odczytu).

Te numerki na dole służą do szybkiej zmiany (jeśli wiesz co który oznacza lub ktoś dał Ci w postaci numerków jakie prawa ma mieć dany plik).

Jeśli we wszystkich oczkach masz prostokąt, a w polu na dole 3 litery x, prawdopodobnie na tym hostingu nie da się zmieniać praw dostępu. Zabezpieczenie więc nie zadziała. 2ga możliwość, nie wcisnąłeś F5 po utworzeniu pliku []

Teraz odznacz prawo zapisu dla wszystkich użytkowników (oczko ma być puste, ptaszek oznacza zaznaczony, prostokąt - zostaw poprzednią wartość, przydatne przy masowej zmianie praw dla wielu plików) i zanotuj jaką wartość numeryczną to daje. Kliknij OK i ponownie wciśnij F5 w widoku katalogu. Teraz przejedź w bok suwakiem aż ujrzysz kolumnę o nazwie "Prawa dostępu" (File permissions). Sprawdź, czy wartość w nawiasie jest dokładnie taka, jaką zanotowałeś z pola wartości numerycznej. Jeśli się nie zgadza, hosting nie spełnia odpowiednich wymogów.

Teraz zostaw ten plik na 24 godziny, wyłącz i włącz serwer poprzez panel w tym czasie kilka razy. Jeśli po 24 godzinach plik nadal posiada ustawione przez Ciebie prawa dostępu, wszystko jest ok, zabezpieczenie zadziała! Jeśli się zmieniły, przykro mi.

Dodatkowy warunek

Mamy jeszcze jedną rzecz do zrobienia: sprawdzić, czy hosting używa osobnych użytkowników dla FTP i do uruchamiania serwera. Zanotuj wartości z pola Właściciel/Grupa utworzonego pliku, teraz przejdź do głównego folderu w FTP i sprawdź, czy takie same wartości posiada plik hlds_run. Jeśli pierwsza wartość jest taka sama jak druga, niestety użytkownik jest ten sam, warunek niespełniony. Jeśli pierwsza wartość jest inna, a druga taka sama: użytkownik FTP jest inny niż użytkownik do uruchamiania serwera, warunek jest spełniony. Jeśli 2 wartość jest inna, oznacza to, że użytkownicy mogą nie należeć do tej samej grupy, jednak pewności nie ma.

Katalogi do zabezpieczenia

Teraz przedstawię które katalogi należy zabezpieczyć, należy wykonać na każdym z nich czynności opisane niżej.

/cstrike
/cstrike/addons/metamod
/cstrike/addons/amxmodx/configs
/cstrike/addons/amxmodx/configs/maps
/cstrike/addons/amxmodx/plugins

Katalog /cstrike/addons/amxmodx/configs/maps może nie istnieć, należy go utworzyć.

Dodatkowe operacje

Te czynności wykonujemy wyłącznie, gdy dodatkowy warunek został spełniony. Należy się upewnić, że katalogi które chcemy zabezpieczyć są własnością użytkownika FTP. Sprawdzamy w kolumnie Właściciel/Grupa czy wartości są takie same, jak dla utworzonego przez nas wcześniej pliku. Jeśli są, to nic nie trzeba robić, jeśli nie są, musimy przejąć folder.

Aby to zrobić, najprościej jest:

    Skopiować katalog wraz z całą zawartością na dysk

    Usunąć katalog z FTP

    Kopię z dysku ponownie wrzucić na serwer

Po wykonaniu tych czynności, możemy zabezpieczyć katalog.

Zabezpieczanie katalogu

Aby katalog został zabezpieczony, należy po prostu usunąć prawo zapisu do niego. W przypadku, gdy dodatkowy warunek na naszym hostingu został spełniony, usuwamy zapis dla grupy (2 wiersz), ale zostawiamy dla właściciela. Gdy nie został spełniony, usuwamy dla właściciela (1 wiersz).

Wady rozwiązania

Gdy dodatkowy warunek nie został przez hosting spełniony, rozwiązanie posiada 1 dodatkową wadę. Gdy chcemy do zabezpieczonego katalogu przez FTP dodać jakikolwiek plik, należy na chwilę usunąć zabezpieczenie, tj dodać prawo zapisu do pliku.

Wadą tego rozwiązania bez względu na spełniony dodatkowy warunek jest to, że pluginy na serwerze nie będą mogły stworzyć nowych plików, np pliku konfiguracyjnego z domyślną zawartością. Więc jeśli wgrywamy jakiś plugin, który powinien sobie taki plik utworzyć (albo kilka) należy wyłączyć przy 1 uruchomieniu pluginu nasze zabezpieczenie.

Problemy z Deaglesem

Są takie pluginy niestety, które chcą na siłę coś zapisywać w katalogu z konfiguracją serwera. Jednym z nich jest Deagle's map manager... No cóż, powinien on trzymać te pliki w katalogu data, a nie w configs, ale już trudno... da się z tym jednak szybko uporać, wystarczy utworzyć w configs katalog dmap i przerzucić tam wszystkie pliki konfiguracyjne deaglesa, prócz maps.ini (tworzy on plik mapvault.dat z konfiguracją edytowaną przez komendy, jego też trzeba tam przerzucić). Na katalog dmap ustawiamy możliwość zapisu, tak samo na pliki wewnątrz. Pluginu nie trzeba edytować, gdy widzi on katalog dmap, domyślnie zaciąga sobie z niego konfigurację

Rozwiązanie NIE WPŁYWA na stabilność serwera! Nie zwiększa się awaryjność serwera, jak przy filewatcherze.

Dobrze by było, jakbyś jednak pisał dodatkowo prawa dostępu za pomocą cyfr ^ ^

A nie będzie w formie cyfr, bo nie chce mi się tego dokładnie tłumaczyć. Jeśli chcesz, możesz się doczepić nawet w tym temacie z mini poradnikiem na ten temat No i nie sądzę, żeby było to potrzebne przy tej robocie. Opisałem dokładnie jak to na FileZilli wygląda, jeśli ktoś chce to przenieść na inny program, musi się troszkę podszkolić.

 

Od siebie dodam, że 1 hosting na 100% umożliwia "wygodną" wersję zabezpieczenia serwera: dedyki.net. Jeśli ktoś zna inne, warto napisać, nie jest to forma reklamy tych hostingów, ale oszczędzi innym ludziom pracy nad "wykrywaniem" tego, czy da się zabezpieczyć, czy nie.

 

No i te "sprawdzenia" które podałem w 100% skuteczne nie są. Jedynym słusznym jest po prostu zrobienie i sprawdzenie, czy działa.

Little update odnośnie Deagle's map managera, aby działał prawidłowo.

Nowsze dproto chroni juz przed tym bledem

Gratki Dobry poradnik A co do total comandera to się nie zgodzę. Lubię i FileZille i Totala. Total ma kilka błędów owszem, ale można zapisywać wszystkie konta do ftp i wybrać sobie z którym chcesz się połączyć. Wydaje mi się że w FileZilli nie ma tego. No ale jest za to wygodniejsza

Pierwszy przycisk na pasku FileZilli - Menadżer stron Nawet masz rozwijaną listę szybkiego dostępu, możliwość układania zapisanych kont FTP w kategorie i podkategorie (czy tam foldery i podfoldery), możliwość tworzenia zakładek, czyli automatycznie po połączeniu wrzuci Cię do podanego katalogu FTP, a nawet wybierze katalog lokalny który zdefiniujesz. Dużo, dużo, dużo więcej niż w Total Commanderze. No i obsługa SFTP. Kiedyś do tego poradnik zrobię.

Witam jeżeli confiigs mam tak

http://scr.hu/1ap7/10uow

 

to jest zabezpiesczony czy nie? Bo chyba o to chodzi aby ograniczyc atrybut chmod tak ?

 

Jeżeli coś źle pisze to przepraszam

proszę o odpowiedź 

I tak, i nie... zależy na jakim użytkowniku jest uruchamiany serwer.

 

Są 3 opcje

• użytkownik jest ten sam, co użytkownik FTP, czyli właściciel plików - wtedy musisz ograniczyć zapis dla właściciela, co utrudnia dostęp do FTP serwera

• użytkownik jest w tej samej grupie, co użytkownik FTP - wtedy ograniczasz zapis dla grupy i nie utrudnia to dostępu do FTP serwera

• użytkownik nie ma nic wspólnego z użytkownikiem FTP - wtedy ograniczasz zapis dla innych (na screenshocie "świat") - prawie niespotykane na hostingach gier i najgłupsze, bo dostęp do plików mogą uzyskać inne serwery uruchomione na tej maszynie

To z którą sytuacją masz do czynienia zależy od hostingu i w pierwszym poście opisałem łopatologicznie jak to sprawdzić.

 

Temat nadal aktualny?

Dla starszych binarek, które nie posiadają takowego zabezpieczenia wbudowanego jak najbardziej. Dla nowszych, które już posiadają - nie zaszkodzi

Dziękuje. Możesz dać link do opisu poszczególnych updateów hlds'a?

Niestety, ale sam nawet się nie orientuję które z binarek są podatne, a które nie. Podział jest mniej więcej w momencie wydania SteamCMD przez valve, jednak nie chciałbym nikogo w błąd wprowadzać. Jak już napisałem, zabezpieczenie serwera który nie jest podatny niczemu nie szkodzi, a nie wiadomo, czy w którejś następnej wersji błąd znów nie wystąpi (bądź jakiś podobny do niego)

Wystarczy najnowsze dproto.