Forum
Użytkownicy
Kalendarz
Dodatki SourceMod
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.
