Logo mark Archiwum

Kompleksowy poradnik dotycz膮cy bezpiecze艅stwa serwer贸w Minecraft

Poradniki
vps, minecraft, zarz膮dzanie
logixdev
logixdev

馃敀 Kompleksowy poradnik dotycz膮cy bezpiecze艅stwa serwer贸w Minecraft

馃憞 Spis tre艣ci:

  1. Wprowadzenie
  2. Typy atak贸w
  3. Zabezpieczenie przed w艂amaniami na serwery spi臋te z BungeeCordem
  4. Zabezpieczenie serwera VPS/dedykowanego
  5. Zabezpieczenie przed atakami DoS/DDoS
  6. Crashery BungeeCord i Spigota
  7. Zabezpieczenie przed botami
  8. CloudFlare, zabezpieczenie strony WWW
  9. Poza tym...

1. Wprowadzenie Zauwa偶y艂em, 偶e na forach cyklicznie przejawiaj膮 si臋 podobne tematy dotycz膮ce bezpiecze艅stwa serwer贸w Minecraft. Najcz臋艣ciej zadawane pytania dotycz膮 sposob贸w zabezpieczenia przed atakami bot贸w, atakami DoS/DDoS b膮d藕 atakami aplikacyjnymi (tzw. crasherami). Aby mo偶e troch臋 ograniczy膰 ilo艣膰 tych pyta艅, postanowi艂em, 偶e napisz臋 taki poradnik, kt贸ry z czasem by膰 mo偶e b臋dzie aktualizowany (data ostatniej zmiany na dole tematu). Wszystko, co tu napisa艂em opieram na swojej wiedzy, prawie dziesi臋cioletnim do艣wiadczeniu w prowadzeniu du偶ych serwer贸w (najwi臋ksze projekty przekracza艂y liczb臋 500 graczy). Jednocze艣nie zastrzegam, 偶e sytuacja zmienia si臋 dynamicznie, s膮 znajdowane nowe sposoby, luki itp.

2. Typy atak贸w Sposob贸w na czasowe niepo偶膮dane zatrzymanie dzia艂ania serwera lub wygenerowanie op贸藕nie艅 czy innych niedogodno艣ci w trakcie rozgrywki jest wiele. Najpopularniejsze z nich to:

  • ataki DoS/DDoS: niegdy艣 chyba najpopularniejszy typ atak贸w, w du偶ym uproszczeniu polega na wys艂aniu du偶ej ilo艣ci zapyta艅 do serwera, na kt贸re ten nie mo偶e odpowiedzie膰 co prowadzi do przeci膮偶enia 艂膮cza i finalnie do znacznych lag贸w lub nawet crasha serwera. DoS od DDoS r贸偶ni si臋 tym, 偶e atak DoS jest przeprowadzany z jednego komputera, natomiast DDoS z wielu najcz臋艣ciej w tzw. sieci botnet (tzw. komputer贸w zombie). Ten drugi jest zdecydowanie popularniejszy ze wzgl臋du na wi臋ksz膮 skuteczno艣膰. Do przeprowadzania atak贸w cz臋sto s膮 stosowane tzw. bootery/stressery. Wi臋cej przeczytasz tutaj.

  • ataki bot贸w: bardzo popularny problem na wielu serwerach. Atak polega na uruchomieniu specjalnego programu, kt贸ry najcz臋艣ciej z r贸偶nych adres贸w IP (tzw. proxy) wpuszcza nawet do kilkuset graczy na sekund臋 na serwer, co prowadzi do lag贸w, spamu chatu itp.

  • ataki aplikacyjne: ostatnio bardzo popularny typ atak贸w. Metod jest mn贸stwo, s膮 gotowe skrypty (tzw. crashery). W szczeg贸lno艣ci na starszych, niewspierany wersjach gry (np. 1.8) silnik ma wiele luk przez co wywo艂uj膮c odpowiednie komendy b膮d藕 dzia艂ania na serwerze mo偶emy zak艂贸ci膰 jego stabilno艣膰.

Pewnie mo偶na by艂oby jeszcze wyr贸偶ni膰 tu wi臋cej kategorii, ale my艣l臋, 偶e lepiej przej艣膰 do tej najwa偶niejszej cz臋艣ci, czyli jak si臋 przed wi臋kszo艣ci膮 z nich zabezpieczy膰, reszta wyjdzie w praniu. :slight_smile:

3. Zabezpieczenie przed w艂amaniami na serwery spi臋te z BungeeCordem Prowadz膮c sie膰 serwer贸w ka偶dy tryb dzia艂a osobno (dotyczy si臋 to r贸wnie偶 serwer贸w pojedynczych, ale podzielonych na osobne instancje, czyli tzw. sektory). Opiszmy to na przyk艂adzie, b臋dzie pro艣ciej.

  • Proxy BungeeCord jest hostowane na porcie 25565,

  • Serwer autoryzacyjny z wyborem trybu i pluginem do rejestracji kont jest hostowany na porcie 25566,

  • Serwer Survival jest hostowany na porcie 25567. I teraz musimy zrobi膰 tak, aby gracz m贸g艂 po艂膮czy膰 si臋 z ka偶dym serwerem, ale jedynie przez proxy, czyli aby porty 25566 i 25567 by艂y dost臋pne tylko dla Bungee, a gracz nie m贸g艂 si臋 bezpo艣rednio z nimi po艂膮czy膰 przez list臋 serwer贸w. Dlaczego? Bo mo偶e wtedy np. wej艣膰 bezpo艣rednio na serwer Survival z pomini臋ciem logowania. 鈿狅笍 Uwaga! Pluginy typu IPWhitelist czy OnlyProxyJoin nie daj膮 pe艂nej ochrony i nie s膮 zalecane. To bardzo cz臋sty pow贸d w艂ama艅 na serwerach. Je艣li mamy dost臋p do konsoli SSH, mo偶emy szybko i bezpiecznie zablokowa膰 dost臋p do serwer贸w u偶ywaj膮c do tego celu IPTables lub prostszego i aktualnie nawet bardziej polecanego ufw. Aby zablokowa膰 bezpo艣redni dost臋p do serwera na danym porcie, u偶yj komendy: iptables -I INPUT ! -s $BUNGEE_IP -p tcp --dport $SERVER_PORT -j DROP 鈩癸笍 $BUNGEE_IP to adres Twojego proxy BungeeCord a $SERVER_PORT to port serwera do kt贸rego bezpo艣rednie po艂膮czenie chcesz zablokowa膰. Je艣li chcesz zablokowa膰 zakres port贸w, jest taka sama zasada, tylko nieco zmieniona regu艂ka: iptables -I INPUT ! -s $BUNGEE_IP -p tcp --dport $START_PORT:$END_PORT -j DROP 鈩癸笍 Zasada z adresem jest taka sama, natomiast $START_PORT zast臋pujesz pocz膮tkowym portem, natomiast $END_PORT ko艅cowym, kt贸re chcesz zablokowa膰.

馃 A co je艣li u偶ywasz ufw? Wtedy wystarczy jedna komenda do odblokowania jedynie portu 25565 z danego adresu, bo ten firewall domy艣lnie blokuje wszystkie po艂膮czenia przychodz膮ce, chyba, 偶e regu艂y stanowi膮 inaczej. W tym przypadku je艣li nasze proxy jest hostowane na tej samej maszynie i ma port 25565 (czyli domy艣lny), u偶ywamy komendy: ufw allow from localhost to any port 25565 proto tcp

鈿狅笍 Domy艣lnie regu艂y IPTables s膮 usuwane po restarcie serwera. Na systemach Ubuntu/Debian musisz po dodaniu ich doinstalowa膰 pakiet iptables-persistent i przej艣膰 przez kr贸tki instalator zaznaczaj膮c jedynie, aby zapisa膰 dodane regu艂y IPv4 i IPv6. Robisz to komend膮: apt-get install iptables-persistent

鈩癸笍 Wi臋cej o zabezpieczeniu BungeeCorda dowiesz si臋 na tej stronie. A co je艣li nie masz fizycznego dost臋pu do serwera SSH? Wtedy masz problem. Cz臋艣膰 hosting贸w oferuje ju偶 firewall w panelu, wtedy wystarczy doda膰 do regu艂 (tzw. bia艂ej listy) jedynie adres proxy. Ja nie korzystam i nie polecam te偶 wi臋kszo艣ci hosting贸w Minecrafta ze wzgl臋du na ich kiepsk膮 jako艣膰, wi臋c dok艂adnie ca艂ego procesu nie opisz臋. Szukaj informacji w stronach informacyjnych konkretnego hostingu b膮d藕 napisz ticketa, aby pomogli. Lub kup VPS'a tutaj. ;)

4. Zabezpieczenie serwera VPS/dedykowanego No w艂a艣nie, skoro mowa o VPS. Pami臋tajmy, 偶e to na nim stoi nasz serwer, znajduj膮 si臋 wra偶liwe pliki, wi臋c najpierw to jego nale偶y zabezpieczy膰. Jakie s膮 podstawowe czynno艣ci, kt贸re powinni艣my wykona膰 po 艣wie偶ej instalacji systemu?

  • zmiana has艂a na losowo wygenerowane (np. przez stron臋 https://www.random.org/passwords/), kt贸re ma minimum 24 znaki i nie jest u偶ywane nigdzie indziej. Aby zmieni膰 has艂o na serwerze u偶yj komendy passwd.

  • u偶ywanie klucza logowania SSH. Wi臋cej informacji w poradniku autorstwa @bopke pod tym linkiem.

  • zmiana portu SSH z domy艣lnego 22 na jakikolwiek inny. Jak to zrobi膰? Poradnik autorstwa @Fallen tutaj.

  • Instalacja pakietu fail2ban, dzi臋ki kt贸remu przy zbyt wielu pr贸bach b艂臋dnego logowania do SSH czasowo dost臋p zostanie zablokowany. Instalujemy komend膮 apt install fail2ban i nie wymaga wi臋kszej konfiguracji.

  • Zabezpieczenie bazy danych MySQL/MariaDB. To tej bazy danych u偶ywamy najcz臋艣ciej u偶ywamy do plugin贸w. Po instalacji wykonujemy komend臋 sudo mysql_secure_installation, ustawiamy tam trudne, losowo wygenerowane has艂o (wed艂ug takiej samej zasady jak do konta SSH, ale inne!), najlepiej blokujemy dost臋p spoza localhosta. Podstawowa znajomo艣膰 j臋zyka angielskiego wystarczy do szybkiego przej艣cia konfiguratora. :)

  • Zabezpieczenie bazy danych Redis. Rzadziej u偶ywana baza danych, ale bardzo wydajna i przydatna do zapisu danych, kt贸re musz膮 by膰 szybko synchronizowane (np. przy sektorach czy systemu RedisBungee). W pliku konfiguracyjnym Redisa (najcz臋艣ciej znajduj膮cy si臋 w /etc/redis/redis.conf znajdujemy linijk臋 requirepass i ustawiamy trudne has艂o oraz odhaszowujemy linijk臋 bind 127.0.0.1 (je艣li jest przed ni膮 znak #).

  • Dopuszczenie logowania do SSH tylko z danego adresu IP. To metoda, kt贸ra b臋dzie dobra tylko w momencie gdy mamy statyczny adres IP, logujemy si臋 tylko z jednego komputera i mamy jako tako pewno艣膰, 偶e ten adres nie ulegnie zmianie. W przeciwnym razie bezpowrotnie utracimy dost臋p do danych. Aby to zrobi膰, mo偶emy u偶y膰 znanego nam ju偶 pakietu ufw, wykonujemy komend臋: sudo ufw allow from 203.0.113.4 to any port 22 鈩癸笍 Je艣li SSH mamy na porcie 22, je艣li na innym, to oczywi艣cie odpowiednio modyfikujemy powy偶sz膮 komend臋 oraz wklejamy sw贸j adres.

Pami臋tamy r贸wnie偶 o regularnym aktualizowaniu systemu komendami apt update oraz apt upgrade. Starajmy si臋 nie u偶ywa膰 konta root. Nie podajemy nikomu has艂a. To takie absolutne podstawy, w innych poradnikach na forum znajdziecie jeszcze kilka sposob贸w na zabezpieczenie serwera VPS. :slight_smile:

5. Zabezpieczenie przed atakami DoS/DDoS Tutaj sprawa ma si臋 tak, 偶e w zasadzie najlepsz膮 ochron膮 jest wykupienie serwera, kt贸ry takow膮 ochron臋 oferuj臋. Niestety 偶adne regu艂y dzia艂aj膮ce po stronie serwera nie dadz膮 nam skutecznej ochrony z bardzo prostego powodu. Ruch filtrowany b臋dzie ju偶 na poziomie pow艂oki systemu, a wi臋c zapytania b臋d膮 do niego dochodzi艂y i drenowa艂y zasoby. W tym momencie jedyn膮 i praktycznie bezkonkurencyjn膮 us艂ug臋 Anty-DDoS oferuje OVH w swoich ofertach GAME. Mitygacja atak贸w jest szybka, regu艂y s膮 odpowiednio dostosowane. VPS'y dost臋pne w hostingu, na kt贸rego forum si臋 znajdujemy r贸wnie偶 tak膮 ochron臋 posiadaj膮, a w panelu jest mo偶liwo艣膰 w艂膮czenia dodatkowego filtrowania UDP i zmiana regu艂.

Przy niekt贸rych typach atak贸w (np. SYN flood) pomocne mog膮 by膰 takie regu艂y IPTables: iptables -N SYN_FLOOD iptables -A INPUT -p tcp --syn -j SYN_FLOOD iptables -A SYN_FLOOD -m limit --limit 1/s --limit-burst 3 -j RETURN iptables -A SYN_FLOOD -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

馃挰 Pss! Rozszerzona, pe艂na wersja regu艂 w formacie do dodania w pliku before.rules je艣li korzystamy z ufw, czyli regu艂y IPTables, kt贸re b臋d膮 wykonywa膰 si臋 przed za艂adowaniem reszty dost臋pna pod tym linkiem.

Powy偶sze regu艂y mog膮 jedynie pom贸c, ale pami臋tajmy, 偶e to, co dzieje si臋 jeszcze przed naszym serwerem jest najistotniejsze, czyli infrastruktura filtruj膮ca samego dostawcy, przepustowo艣膰 艂膮cza oraz to, ile atak贸w ju偶 przyj臋li艣my (bo firewall w OVH mo偶na powiedzie膰 uczy si臋 z ka偶dym atakiem i lepiej filtruje). Wi臋cej o ochronie Anty-DDoS Game przeczytasz tu. O innych nie wspominam, bo mo偶na powiedzie膰, 偶e nie umywaj膮 si臋 do tego, co oferuje OVH. Dowodem na to jest chocia偶by to, 偶e w zasadzie ka偶dy du偶y serwer w Polsce aktualnie tam jest hostowany.

鉂楋笍 Wszystkie serwery VPS (zar贸wno w lokalizacji PL jak i FR) w ofercie LVLUP oferuj膮 opisan膮 ochron臋 Anty-DDoS Game. Je艣li chcesz zaopatrzy膰 serwer w serwer VPS z 10% zni偶k膮, mo偶esz u偶y膰 kodu rabatowego CRAFTCODE.PL.

6. Crashery BungeeCord i Spigota Po pierwsze i najwa偶niejsze, zawsze u偶ywaj aktualnego softu. Stare wersje (np. 1.7, 1.8) s膮 ju偶 niewspierane, wi臋c autorzy Spigota nie odpowiadaj膮 za b艂臋dy, kt贸rych w贸wczas by艂o sporo i je艣li chcesz ich u偶ywa膰, tylko po Twojej stronie spoczywa odpowiedzialno艣膰 za napisanie 艂atek.

Aby uchroni膰 si臋 przed r贸偶nymi crasherami na BungeeCorda (poprzez np. spamowanie pakietami netty) mo偶esz u偶y膰 forka BungeeCorda o nazwie FlameCord, kt贸ry jest dost臋pny pod tym linkiem. Niestety, ale domy艣lne Bungee niewiele robi w celu weryfikacji pakiet贸w. Ten fork nie jest idealny, ale z wszystkich dost臋pnych za darmo jest najlepszy. Z p艂atnych jest np. Aegis, kt贸ry jest na bie偶膮co wspierany i poprawiany.

Od tego samego autora jest r贸wnie偶 plugin ExploitFixer, kt贸ry te偶 nie jest idealny, ale pomaga przy najbardziej prymitywnych metodach atak贸w na Spigota. Jest dost臋pny tutaj.

Co jeszcze z takich og贸lnych porad? Nie u偶ywajcie plugin贸w typu ServerListPlus, te偶 mo偶na tym nabroi膰 wysy艂aj膮c odpowiednie pakiety.

7. Zabezpieczenie przed botami Zablokuj po艂膮czenia zagraniczne (to ostatnio jest troch臋 utrudnione ze wzgl臋du na trudniej dost臋pne bazy kraj贸w). Ustaw limity po艂膮cze艅 z jednego adresu. U偶yj kilku osobnych serwer贸w do autoryzacji kont, kt贸re nie maj膮 premium, 偶eby roz艂o偶y膰 ruch i nie wp艂yn膮膰 na stabilno艣膰 g艂贸wnych serwer贸w. Dodaj plugin, kt贸ry wymaga spingowania listy serwer贸w, aby wej艣膰 i wyrzu膰 gracza przy pierwszym wej艣ciu na serwer. Co do wszelkich plugin贸w typu AntiBot, to mam ambiwalentne podej艣cie, bo cz臋sto ma艂o co blokuj膮, a laguj膮 albo utrudniaj膮 wej艣cie na serwer normalnym graczom. Tu jeden z lepszych tego typu darmowych plugin贸w. Z p艂atnych plugin贸w polecam XProtect, a najlepsz膮 ochron臋 ma ww. Aegis.

8. CloudFlare, zabezpieczenie strony WWW Nieod艂膮czn膮 cz臋艣ci膮 wielu serwer贸w jest strona WWW. Warto korzysta膰 z CloudFlare, czyli dodatkowej bariery obronnej, kt贸ra ukrywa realny adres naszego serwera przy pingowaniu. Poza tym umo偶liwia te偶 w艂膮czenie chocia偶by certyfikatu SSL dla strony, jest analityka itd. Dodajemy rekord typu A oraz SRV dla serwera Minecraft. Wi臋cej o tym tutaj.

9. Poza tym... Nie u偶ywamy plugin贸w do permisji dzia艂aj膮cych po stronie BungeeCorda. Uwa偶amy na dodawanie uprawnie艅 u偶ytkownikom w Bungee. Nie u偶ywamy po stronie proxy ViaVersion, tylko Travertine/Waterfall lub najlepiej wy偶ej wymionego FlameCord, aby obs艂ugiwa膰 wiele protoko艂贸w po艂膮czenia. Nie trzymamy 偶adnych danych wra偶liwych danych w plain text w naszych pluginach, tylko szyfrujemy (i to sensowniejszym szyfrem ni偶 MD5 chocia偶by).

To tyle. 馃槉 Je艣li macie jakie艣 propozycje, co mo偶na doda膰, co zmieni膰, to 艣mia艂o, chcia艂bym, 偶eby ka偶dy co艣 dorzuci艂 ze swojej wiedzy. Jeszcze kilka punkt贸w mo偶e b臋dzie dopisane jak b臋dzie mi si臋 chcia艂o. Nie pisa艂em o takich podstawach jak u偶ywaj pluginu do autoryzacji kont, bo wydaje mi si臋 to oczywiste. 呕r贸d艂a podane w ka偶dym konkretnym podpunkcie + wiedza w艂asna. Pami臋tajcie, 偶e najpierw zabezpieczamy, a nie jak ju偶 jeste艣my atakowani, bo wtedy mo偶e by膰 za p贸藕no, frustracja graczy jest du偶a, a my ryzykujemy w艂amaniami, wyciekami plik贸w itp. Warty uwagi poradnik na GitHubie w j臋zyku angielskim dost臋pny tutaj.

Data ostatniej aktualizacji poradnika: 04.05.2020 r.

Pozdrawiam! 馃憢

|84x126Poradnik miesi膮ca: marzec 2020

psycho
psycho

Dopisa艂bym w przypadku OVH jeszcze co艣 o ich firewall'u kt贸ry mo偶emy dodatkowo skonfigurowa膰 (dla VPS/Dedyk贸w zakupionych u nich). Chyba w planach jest te偶 mo偶liwo艣膰 konfiguracji firewalla OVH dla VPS'贸w, ale nie wiem czy to pewniak.

artur9010
artur9010

logixdev:

4. Zabezpieczenie serwera VPS/dedykowanego No w艂a艣nie, skoro mowa o VPS. Pami臋tajmy, 偶e to na nim stoi nasz serwer, znajduj膮 si臋 wra偶liwe pliki, wi臋c najpierw to jego nale偶y zabezpieczy膰. Jakie s膮 podstawowe czynno艣ci, kt贸re powinni艣my wykona膰 po 艣wie偶ej instalacji systemu?

Wi臋kszo艣膰 tego punktu mo偶na zast膮pi膰 logowaniem kluczem

Nieznajomy11
Nieznajomy11 Moderator forum.lvlup.pro

logixdev:

oraz odhaszowujemy linijk臋 bind 127.0.0.1 (je艣li jest przed ni膮 znak #).

Czemu? Bind na tylko localhost to jaki艣 problem? Ok, ju偶 widz臋 o co chodzi艂o.

logixdev:

Nie trzymamy 偶adnych danych wra偶liwych danych w plain text w naszych pluginach, tylko szyfrujemy (i to sensowniejszym szyfrem ni偶 MD5 chocia偶by).

Funkcje skr贸tu (md5, sha256) to nie jest szyfrowanie.

bopke
bopke Moderator forum.lvlup.pro

Nieznajomy11:

Czemu? Bind na tylko localhost to jaki艣 problem?

przecie偶 jemu chodzi w艂a艣nie o odkomentowanie linijki binduj膮cej na localhost. Wydaje mi si臋, 偶e redis binduje si臋 domy艣lnie na localhosta, ale lepiej mie膰 pewno艣膰 ni偶 jej nie mie膰 :cowboy_hat_face:

Nieznajomy11
Nieznajomy11 Moderator forum.lvlup.pro

Faktycznie. Przez to, 偶e w domy艣lnej konfiguracji redisa jest ju偶 bind 127.0.0.1, zrozumia艂em to jako sugestie zakomentowania dyrektywy.

# By default, if no "bind" configuration directive is specified, Redis listens
# for connections from all the network interfaces available on the server.
# It is possible to listen to just one or multiple selected interfaces using
# the "bind" configuration directive, followed by one or more IP addresses.
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
#
# ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the
# internet, binding to all the interfaces is dangerous and will expose the
# instance to everybody on the internet. So by default we uncomment the
# following bind directive, that will force Redis to listen only into
# the IPv4 loopback interface address (this means Redis will be able to
# accept connections only from clients running into the same computer it
# is running).
#
# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
# JUST COMMENT THE FOLLOWING LINE.
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1
logixdev
logixdev

Wi臋ksza aktualizacja poradnika dzi艣 tj. 04.05.2020 r.

Doda艂em:

  • informacj臋 o logowaniu kluczem SSH jako bezpieczna metoda (dzi臋ki @artur9010 za propozycj臋 i @bopke za poradnik)
  • nowe, rozszerzone regu艂y IPTables do pomocy przy filtrowaniu wszelakich atak贸w
  • informacj臋 o oferowaniu na wszystkich serwerach VPS w LVLUP ochrony DDoS Game i m贸j kod rabatowy (CRAFTCODE.PL) na 10% zni偶ki 馃槈
  • poszerzenie informacji o ochronie przed botami, dodanie nowego zalecanego pluginu
  • poprawki liter贸wek, dodanie spisu tre艣ci dla lepszej czytelno艣ci tematu

Je艣li macie jakie艣 propozycje lub znacie nowe inne luki w zabezpieczeniach, zach臋cam do pisania propozycji. Poradnik b臋dzie dalej aktualizowany i aktualny dla nowszych wersji Minecraft, kt贸re zostan膮 wydane.

masterspro123
masterspro123

logixdev:

Z p艂atnych jest np. Aegis, kt贸ry jest na bie偶膮co wspierany i poprawiany.

XD https://www.youtube.com/watch?v=xR_K9UULwpA&t=30s https://www.youtube.com/watch?v=0dE8yjKNyWE

Kamil02167
Kamil02167

obraz|690x172