Сборки серверов

СливПлатные

Сейчас онлайн

  • WarBanPe
  • GORLIIIN
  • Oscar
  • Floll4ikYT
  • Starik672
  • hyno731
  • MachuPapa2020
  • Padomipa
  • DenPlayStar
  • фейзи
  • makksisik
  • arichusnowie97
  • fr124
  • MrSoup
  • DarvusVilaks
  • Kumbasar
  • thesenya1
  • Topicone
  • tomas11
  • scr3mx
  • Marsano
  • xlassia
  • Mr_Neave
  • kneekick
  • YAkolyan
  • SinT
  • ChildFreak
  • mynnpng
  • OXIS
  • nutelovskiiy
  • Timka_2288223
  • MystalDev
  • denga118
  • imdas
  • isakovvv
  • ShadowDev777
  • Invensee
  • Ampharone
  • Damfler
  • excellname
  • AlexVolk
  • V6amopjxm
  • OderPrince
  • kakashka302
  • Krayn
  • StrelkovAA2281488
  • ytopchek
  • Dye_ee
  • YTaim

Безопасность сервера Minecraft | Часть 1; Осведомленность

Серия перевода со спигота​


Всеобъемлющая серия постов, объясняющих, почему серверы Minecraft взламывают, и что вы можете сделать, чтобы предотвратить это. В этом посте речь пойдет о нескольких вещах, которые почти всегда присутствуют в тех классических видео на YouTube, где взламывают серверы. Я подробно объясню, почему это происходит, как это происходит, и что вы можете сделать, чтобы предотвратить это. Этот пост предназначен для всех: от (публичных) разработчиков плагинов, системных администраторов до профессионалов, которые имеют полные пользовательские сети.

В области кибербезопасности вы должны задавать себе вопрос не о том, взломают ли вас, а о том, когда.

Эти посты состоят из следующих частей;​

Введение​

Статья написана, потому что (слишком часто) видно, как взламывают серверы Майнкрафт. Это само по себе, хотя и проблематично, но не обязательно вызывает тревогу. Тревогу вызывает то, как и почему их взламывают. По этой причине и написан блог по безопасности (или как вы хотите его назвать), в котором рассказывается обо всем. Обратите внимание, что это руководство не относится конкретно к Minecraft; речь идет о разработке программного обеспечения и системном администрировании в целом. Это первая часть серии.

Осознание​

В этой части будьте честны с собой. Скорее всего, у вас что-то работает (возможно, сервер Minecraft). Вы когда-нибудь садились на некоторое время и глубоко задумывались о том, насколько безопасна ваша сеть серверов? Как она может быть взломана, и что произойдет, если вас взломают (с точки зрения ущерба), и как вы будете бороться со взломом? Скорее всего, нет. Вот здесь и возникает первая проблема. Если вы задумывались об этом, поздравляю, вы на правильном пути.

К сожалению, многие люди не понимают, что недостаток внимания к безопасности приведет к рискам безопасности. Это неизбежно; если вы не будете активно думать о безопасности во время создания или обслуживания вашей установки, вы, скорее всего, создадите риски.

Оцените текущее состояние​

Первый шаг в этом направлении - начать оценку. Посмотрите на всю вашу систему (да, на всю, какой бы большой она ни была) и выясните, как именно все интегрировано друг с другом. Какие вещи связаны между собой, каковы некоторые общие службы или базы данных? Это очень важно знать для следующего раздела. При проведении такой оценки создайте схему того, как все работает и как все связано. Для этого можно использовать диаграмму компонентов UML.


Причина, по которой мы это делаем, более подробно объясняется в части 2; цепочка эксплойтов. Без лишних слов, все сводится к тому, что один эксплойт вызывает другой. Небольшая брешь в системе A может привести к бреши в системе B, C, D и т.д. Многие люди этого просто не понимают. Прекрасным примером является система разрешений. Многие администраторы, которые настраивают сервер MC, будут думать, что определенная функциональность безопасна, потому что на нее заблокировано разрешение. Это действительно так, пока вы не поймете, что неправильно настроили Свою банжи и кто-то может просто перевернуться. В этот момент ваши права для игроков и все запреты уже ничего не предотвращают, и тот факт, что ваше соединение с прокси севрером было нарушено (начальный эксплойт), теперь приводит к дальнейшим эксплойтам (цепочка эксплойтов).

Это то, что я называю цепочкой эксплойтов (возможно, для этого есть официальный термин), о которой я подробно расскажу во второй части.

Пример​

Ниже приведен пример. У нас есть классический сервер Minecraft, с настройкой BungeeCord, тремя различными игровыми режимами (Виживания, Скайблок и Скай Варс). Он состоит из баз данных, веб-магазина (автодоната) и синхронизации Discord (DiscordSRV). Это самая распространённая схема создаваемых серверов

Давайте посмотрим на изображение ниже, как все подключено в этом сценарии (скорее всего!);

11
У нас есть BungeeCord, подключенный ко всем серверам Spigot. Все серверы Spigot также подключены к одному серверу базы данных и одной базе данных (например, базе данных MySQL). Они также подключены к Автоданату и Discord. Для данного раздела предположим, что Discord и Автоданат интегрированы по максимуму: синхронизированная консоль в Discord. Мы предполагаем это, потому что я считаю это наиболее распространенным.

Теперь, я хочу, чтобы вы взяли это изображение и вставили его куда-нибудь в paint или куда-нибудь, что позволит вам легко рисовать на нем. Я хочу, чтобы вы нарисовали красный крест (двойную линию) через связи, которые не должны существовать вообще, и одинарную красную линию через связи, которые должны быть изменены (интеграции или функциональные возможности, которые должны быть отключены).

Обзор текущего В спойлере ниже - мой взгляд на него. Кое-что может вас удивить.

2

Постойте, я уже вижу, как вы трещите по костяшкам пальцев, готовясь разразиться полным ходом в поле для комментариев ниже. Но подождите, давайте внимательно посмотрим на это. Именно здесь приходит осознанность.

Посмотрите на эти функции и подумайте, какие из них необходимы. Для каждого это может быть по-разному; у одного человека может быть больше возможностей для пользовательской разработки по сравнению с другими. Однако суть остается неизменной: оба должны проанализировать ситуацию и задаться вопросом, должно ли все работать именно так.

Менталитет счастливого потока​

Многие люди настраивают свой сервер Minecraft по стратегии "счастливого потока". Они начинают устанавливать вещи, и как только они работают, они останавливаются. Все работает, все работает, у вас есть игроки, ваша работа закончена. Верно? Нет. Мы все (по крайней мере, я надеюсь) знаем о классическом "эксплойте" Bungeecord, когда игроки могут напрямую подключаться к вашему серверу Spigot через поддельный прокси Bungee, если вы не настроили брандмауэр должным образом. Как ни смехотворно стара эта техника, она работает и по сей день. Это должно подтвердить вышеупомянутый менталитет многих людей.

Проблема в том, что самая очевидная и простая настройка обычно не является лучшей (или, по крайней мере, не самой безопасной). Подумайте о том, что я упоминал ранее о вашей проблеме с разрешениями и о том, что вы получили Bungee'd (глагол, означающий, что у вас взломали брандмауэр Bungeecord). Вы можете думать, что все в порядке только с некоторыми разрешениями. Вы оставляете функциональность включенной, но прячете ее за правами. Все работает, все работает, у вас есть игроки, все в порядке. И все же. Пока вы не получите Bungee's, и все ваши разрешения не будут обойдены.

Это относится ко всему, что вы можете делать на сервере Minecraft: управлять сервером Discord, получать доступ к личным данным пользователей, читать личные данные из вашего интернет-магазина, изменять ваш интернет-магазин, выполнять SQL-запросы или читать файлы с диска (да, некоторые плагины достаточно глупы, чтобы иметь такую функциональность).


Плагины Spigot Хотя Spigot прекрасен благодаря механизму плагинов, это создает большой риск. Spigot отлично подходит для моддинга благодаря плагинам. Но давайте задумаемся об этом на секунду. Плагин, что это такое? В некотором смысле, это просто код, который автоматически выполняется другим кодом. По определению, это чрезвычайно рискованно. Все хакерство в основном сводится к тому, чтобы заставить машину делать то, что вы хотите. Некоторые из них более неожиданны или сложны, чем другие, но сводятся они к одному и тому же. Тот факт, что плагин в конечном итоге является ничем иным, как автоматически вызываемым кодом, является рискованным. Вы, как разработчик и администратор, должны это учитывать. Почему вы должны учитывать это как разработчик, будет рассказано далее. Вы всегда должны быть осторожны с плагинами, которые вы устанавливаете.

опубликовал список всех вредоносных программ, найденных им на Spigot. Было бы интересно, если бы он поделился цифрами о том, сколько вредоносного ПО он нашел, что это ПО делает и как оно работает. Также имейте в виду, что вредоносное ПО может распространяться! Если вы не настроили разрешения должным образом, один плагин может просто записать другой Jar-файл, эффективно перемещая код вредоносного ПО в новый Jar, что может помочь скрыть его вредоносные намерения.

Это опасно не только с точки зрения кода, но и с точки зрения конфигурации и данных. Подробнее об этом в частях 2, 3, 4 и 5.
 
Последнее редактирование:
ВерхНиз