Серия перевода со спигота
Всеобъемлющая серия постов, объясняющих, почему серверы Minecraft взламывают, и что вы можете сделать, чтобы предотвратить это. В этом посте речь пойдет о нескольких вещах, которые почти всегда присутствуют в тех классических видео на YouTube, где взламывают серверы. Я подробно объясню, почему это происходит, как это происходит, и что вы можете сделать, чтобы предотвратить это. Этот пост предназначен для всех: от (публичных) разработчиков плагинов, системных администраторов до профессионалов, которые имеют полные пользовательские сети.
В области кибербезопасности вы должны задавать себе вопрос не о том, взломают ли вас, а о том, когда.
Эти посты состоят из следующих частей;
- Безопасность сервера Minecraft | Часть 1; Осведомленность
- Безопасность сервера Minecraft | Часть 2; Цепочка эксплойтов
- Безопасность сервера Minecraft | Часть 3; Идентификация рисков (текущая)
- Безопасность сервера Minecraft | Часть 4; Снижение рисков
- Безопасность сервера Minecraft | Часть 5; Предотвращение рисков
Введение
Статья написана, потому что (слишком часто) видно, как взламывают серверы Майнкрафт. Это само по себе, хотя и проблематично, но не обязательно вызывает тревогу. Тревогу вызывает то, как и почему их взламывают. По этой причине и написан блог по безопасности (или как вы хотите его назвать), в котором рассказывается обо всем. Обратите внимание, что это руководство не относится конкретно к Minecraft; оно касается разработки программного обеспечения и системного администрирования в целом.Предисловие и предупреждение
Итак, прежде чем мы начнем. Эта часть длинная. Не в плане чтения, а в плане выполнения. Выполнение задач, описанных в этой части, потребует преданности, творчества и особенно времени. И хочу сразу предупредить: безопасность существует везде, во всех формах и размерах. Нет единого размера, подходящего для всех, нет простого контрольного списка, по которому можно было бы работать.Проблема с этой частью, однако, заключается в том, что трудно определить риски безопасности, если вы на самом деле не знаете о них. Некоторые из них просты, и я объясню их на примере триады ЦРУ. Другие не так просты. Например, как вы можете знать о SQL-инъекциях, если вы едва знаете, что такое SQL? Вот что я имею в виду, говоря о преданности делу и времени. Если вы хотите обеспечить безопасность своей сети, вам необходимо получить знания. По-другому и не скажешь. Вам нужно учиться, вам нужно изучать, вам нужно исследовать и вам потенциально нужно тестировать. Для некоторых это может оказаться сложным. Я постараюсь помочь вам самостоятельно овладеть этими знаниями.
Определение рисков
Прежде чем приступить к улучшению нашей безопасности, мы должны определить, что необходимо улучшить. Собрав информацию о том, какие риски у нас есть, мы можем начать планировать улучшения. Выявление в этой части будет касаться не только информации, но и самих систем, вероятности их взлома, способов взлома и последствий.Риск можно суммировать с воздействием и вероятностью. Высокая вероятность и высокое воздействие - это, естественно, высокий риск. Низкая вероятность и низкое воздействие - низкий риск. Высокое воздействие, низкая вероятность, средний риск. В Интернете есть матрицы, которые наглядно демонстрируют это.
Я нашел в Интернете вот эту, очень симпатичную;
Все это звучит очень красиво, верно? Метод идентификации рисков и присвоение им определенного балла. Это здорово, пока вы не поймете, что на самом деле вам нужно составить этот список. С чего вы вообще начнете? Некоторые из них, особенно те, у которых сложные и большие серверы, имеют довольно приличный технологический стек. Вы даже не можете приступить к подробному перечислению всех возможных рисков безопасности. Это просто слишком много. Слишком много, чтобы перечислять, и слишком много, в чем мы не уверены. Мы не можем, обладая знаниями в области безопасности, начать составлять список из 6 миллионов элементов риска из воздуха.
Вместо этого я предлагаю определить несколько проблем на более высоком уровне. На этом высоком уровне мы будем в основном рассматривать вопросы архитектуры и бокового перемещения. Даже зная, что нам нужно смотреть на вещи с высокого уровня, с чего мы начнем? К счастью, в такого рода анализе мы почти всегда используем 3 категории: конфиденциальность, целостность и доступность. Так называемая триада ЦРУ. И нет, это не имеет никакого отношения к Центральному разведывательному управлению.
Конфиденциальность
У всех нас есть данные. Без этого никак не обойтись. Мы обслуживаем продукт / услугу, у нас есть данные. Помните, что когда я говорю о данных, я также имею в виду программное обеспечение. Например, программное обеспечение, сделанное на заказ. Что касается конфиденциальности, мы должны оценить, насколько конфиденциальны эти данные. Насколько важно, чтобы эти данные никогда не стали достоянием общественности или чтобы к ним не получил доступ посторонний человек? Без сомнения, это PII (персональная идентифицируемая информация). Сегодня, когда действуют COPPA и GDPR, любые персональные данные должны рассматриваться как очень конфиденциальные. IP-адреса, адреса электронной почты и т.д. Возможно, также имена пользователей и идентификаторы UUID, хотя сейчас мы мало что можем сделать, чтобы скрыть их от общественности, не так ли?Давайте посмотрим на диаграмму выше и рассмотрим некоторые примеры распространенных данных. Эти примеры основаны на некоторых распространенных серверах.
UUIDs / имена пользователей
Как бы я ни был не совсем согласен с тем, что UUID являются личной информацией, многие люди утверждают, что это так. Давайте просто возьмем это как идеальный пример того, что имеет очень низкий уровень конфиденциальности. Даже если бы вы хотели сохранить их в тайне, вы не сможете. Они публично показываются и используются.- Вероятность: Всегда. Вы не можете скрыть их, когда они используются.
- Влияние: Отсутствует, они и так публичны.
- Риск: Отсутствует. Не стесняйтесь изменить мое мнение (о конфиденциальности!).
Доступы к логам IP-адресов игроков
Многие серверы, веб-сайты или практически любые службы регистрируют доступ к IP-адресам. Фактически, все они должны это делать. Однако следует помнить, что в GDPR, например, четко указано, чтоIP-адреса являются персональными данными. К ним следует относиться с максимальной конфиденциальностью. Если к ним получит доступ неавторизованное лицо, у вас могут возникнуть проблемы, если это произойдет в больших масштабах (утечка большого количества данных, воздействие на большое количество людей). Я дам этому вероятность, потому что многие люди предоставляют модераторам или администраторам доступ к IP-адресам. Например, в игре через Essentials.Будучи предельно официальным, если вы зарегистрированная компания вы должны заключить с людьми контракт на это, но я не буду вдаваться в подробности. Влияние должно быть довольно низким, так как я предполагаю, что никто случайно не станет модератором или администратором в первую очередь. Для анализа давайте следовать закону.
Вероятность: Значительный. Типичные настройки персонала и потенциальный несанкционированный доступ.
Влияние: Малая. Это не самое страшное, что может произойти утечка, поскольку IP-адреса также время от времени меняются.
Риск: Ниже среднего
Пароли
Ну вот, началось. Я не могу подчеркнуть, как много людей просто не понимают этого. Пароли очень важны. Они повсюду. Можно привести веские аргументы в пользу того, что вы должны использовать менеджер паролей, и это действительно так. Однако не стоит забывать, что мы имеем дело с детьми. У вас может быть веб-сайт или внутриигровая регистрация (например, на взломанных серверах), которые хранят пароль. Опять же, мы имеем дело с детьми. Серьезно, эти пароли не будут надежными, мы все это знаем. Дети только начинают осваивать интернет. Скорее всего, они везде будут использовать один и тот же пароль. Будет довольно жалко, если у ребенка взломают интернет-сервисы, потому что его пароль просочился из-за какого-то дурацкого сервера Minecraft, верно?Я даю этому возможную вероятность. Почему? Потому что люди глупы. Не игроки и их пароли, а системные администраторы и разработчики. Даже на спиготе пользователем @clx_ был найден плагин для чата, который просто записывал чат в базу данных MySQL. Оказалось, что это была SQL-инъекция. Далее модераторы спигота продолжили поиски, чтобы выяснить, можно ли это использовать. И, конечно оказалось, можно. Можно просто набрать что-то в чате, и вот, пожалуйста, сервер умирал. Это было весело. Если копнуть глубже, то можно было легко сделать подзапрос, чтобы прочитать столбцы из другой таблицы или даже другой базы данных, с потенциальными паролями. Мы могли бы также читать файлы из системы, потому что MySQL может делать это по какой-то причине.
- Вероятность: Возможна. Люди не знают. Множество 5-звездочных отзывов не защищает этот риск.
- Влияние: Значительно. Давайте защитим детей, пожалуйста. А также свои собственные (административные!) учетные записи.
- Риск: Выше среднего
Целостность
Целостность - это риск того, что данные не могут быть изменены, удалены или созданы без ограничений неавторизованным лицом. Теперь, в контексте Minecraft, я не совсем уверен, насколько это применимо. Мы можем думать о нашем защищенном спавне как о чем-то целочисленном, но мы все знаем, что он не должен быть изменяемым. Я думаю, что это также идет рука об руку с некоторыми темами, упомянутыми в части о конфиденциальности, а также в двух других частях этого руководства: "Осведомленность" и "Цепочка эксплойтов". Если у кого-то есть какие-либо примеры или вещи, которые стоит упомянуть здесь, обязательно дайте мне знать, но я думаю, что это вполне сочетается с общим менталитетом "не позволяйте никому получать доступ к вашим вещам без разрешения".Доступность
Вот тут-то и начинается самое интересное. Мы с вами знаем об этом: ботнеты, SYN-потоки, Ping of Death, Slow Loris, DDoS-атаки! Мы все их любим и ненавидим. Они суперкрутые, но и суперназойливые. К счастью, есть способ справиться с ними! Я подробно расскажу об этом в бонусной части этой серии, если она получит достаточную популярность. А пока давайте оценим ситуацию. У вас есть технологический стек. У вас могут быть прокси (Bungeecord), базы данных (MySQL, MongoDB), веб-сайты и т.д. Некоторые из этих компонентов крайне важны для того, чтобы оставаться доступными.Базы данных
К примеру на проекте Dyescape всё берется из базы данных. Контент (предметы, квесты, эффекты зелий, монстры, дроп, регионы, магазины, навыки, гильдии, подземелья, профессии и т.д.). Все это активно загружается и синхронизируется из базы данных и в нее. Вы, вероятно, можете себе представить, что эта база данных чрезвычайно важна для проекта. Эта база данных ни при каких обстоятельствах не должна выйти из строя. Если это произошло, она должна быть восстановлена как можно скорее. И я не говорю об этом легкомысленно. Конечно, наши серверы могут продолжать работать без базы данных в течение некоторого времени, но, естественно, данные не могут быть сохранены. Чем дольше мы будем ждать, тем большее влияние это окажет на игроков.Теперь, что-то настолько важное, в терминах безопасности управления информацией, называется драгоценным камнем. Это самая важная часть вашей информации (включая системы). Для нас эта база данных абсолютно точно является драгоценным камнем. По этой причине мы должны делать все возможное, чтобы она была доступна, работала и обслуживалась. Однако базы данных в вашем техническом комплексе, скорее всего, также являются драгоценностями. Множество приложений нуждаются в базе данных для того, чтобы функционировать. Она читает, она пишет, если ее нет, она не может делать ни то, ни другое. Все просто. От веб-сайтов до внутриигровых плагинов, все они полностью сломаются, если база данных недоступна. Я предлагаю вам действительно посмотреть на ваши установки баз данных и на то, насколько легко их можно испортить. Никакая база данных на вашем проекте не должна иметь публичного доступа. И я не имею в виду порты базы данных, я имею в виду весь сервер. Конечно, вы можете попытаться провести DDoS-атаку уровня 3/4, которая может перегрузить публичную сеть, но вещи не подключаются через публичную сеть.
Вероятность: Вероятно. У кого-то базы данных могут быть защищены должным образом, у кого-то нет. Однако DDoS-атаки или простые атаки на отказ в обслуживании очень распространены.
Влияние: Серьезное. Приложения в значительной степени зависят от него.
Риск: Высокий
Обратные прокси (bungeecord)
Обратный прокси - это что-то, к чему вы подключаетесь, и этот прокси, от вашего имени, подключается к внутреннему серверу, который не доступен вам напрямую. Или, по крайней мере, предполагается, что это не так. Да, я смотрю на вас, люди, которые устанавливают Bungeecord, не прочитав выделенный жирным красным раздел о безопасности после установки. Несмотря на то, что обратные прокси являются отличными во многих, многих отношениях, они также представляют собой несколько рисков.Типичные установки Bungeecord в Minecraft имеют один общий риск безопасности: они являются единой точкой отказа. У вас может быть 10 серверов Spigot, но один прокси Bungeecord. Если этот прокси выйдет из строя, единая точка входа будет разрушена, и весь ваш сервер станет недоступным. Он может стать недоступным по разным причинам: авария, перезагрузка или злоумышленник, делающий злонамеренные действия со злым умыслом. Независимо от этого, никогда не помешает приобрести несколько прокси-серверов Bungeecord для обеспечения безопасности доступности. Конечно, это излишество, если вам это не нужно, но один уровень защиты никогда не должен считаться достаточным. Bungeecord очень легкий, любой, кто читает эту тему, вероятно, имеет достаточно бюджета, чтобы запустить несколько Bungees.
Некоторые серверы, такие как Hypixel, из-за их безумного размера, конечно, выводят все на новый уровень. У них есть механизм, в котором они используют круговую настройку DNS (по сути, балансировка нагрузки на уровне DNS), чтобы направлять пользователей на набор ротируемых серверов bungeecord. Некоторые из них становятся публичными, люди присоединяются к ним, затем они скрываются, и появляются новые. У них сотни таких прокси-серверов. Удачи в их уничтожении.
Вероятность: Возможно. Все может упасть, все должно иногда перезапускаться, все может быть разрушено.
Влияние: Умеренное. Люди не смогут присоединиться к серверу.
Риск: средний
Скрытые риски
Эти риски немного пугают, но я хочу их упомянуть. Как я уже говорил в предыдущих частях этого руководства по безопасности, некоторые люди просто не знают о рисках безопасности. И разработчики, и системные администраторы. Я бы абсолютно рекомендовал вам, если вы серьезно относитесь к своему проекту, дважды проверить все, что вы устанавливаете, на предмет потенциальных рисков. Даже если они не предусмотрены, они могут быть там. Всегда есть риски, которые легко заметить. Самый распространенный - SQL-инъекции. Их легко найти, легко исправить, и, к сожалению, иногда их легко использовать с серьезными последствиями.Я бы настоятельно рекомендовал вам, когда вы используете конкретный инструмент, такой как MySQL, прочитать о рисках безопасности SQL, таких как SQL-инъекции. Затем изучите, как они создаются (например, в Java) и как их предотвратить. Посмотрите исходный код плагинов, либо на Github, если они с открытым исходным кодом, либо декомпилируйте их. Да, просто декомпилируйте их. Всем наплевать. Просмотрите исходники, поищите SQL-запросы (если плагин поддерживает их, конечно) и проверьте, как они реализованы. Я не буду вдаваться в подробности, но вот простое эмпирическое правило: есть ли в SQL-запросе пользовательский ввод, который вводится в запрос через конкатенацию строк, а не через PreparedStatement (то есть обычный Statement)? Скорее всего, это инъекция.
Это те дополнительные риски, о которых вам, возможно, придется узнать. Посмотрите на инструменты, которые вы используете, и немного погуглите на предмет рекомендаций по безопасности или подводных камней. Скорее всего, вы наткнетесь на вещи, которые можно перепроверить в реализации плагинов.
Самый большой риск из всех в безопасности серверов Майнкрафт:
Теперь, после того, как вы прочитали всю предыдущую стену текста; после того, как вы прочли о множестве рисков, которые существуют повсюду, скрываясь под травой, есть один риск, который намного больше, чем все остальные. Этот риск настолько велик и настолько велик, что его практически невозможно обнаружить или предотвратить. Риск безопасности, который имеет полный административный доступ. Подумайте об этом сами. Подумайте о том, что это может быть.ТЫ
Наибольший риск представляет не кто иной, как живой человек, помещенный между монитором и стулом. Иногда его также называют "PEBKAC" - Problem Exists Between Keyboard And Chair, Если переводить на русский, то это: — «Проблема существует между клавиатурой и стулом» Это называется социальной инженерией, и она более эффективна, чем вы думаете. Она существует во многих формах и повсюду. Разница между обычным взломом и социальной инженерией заключается в том, что социальная инженерия, как правило, совсем не техническая, а социальная. Она использует социальные возможности человека, чтобы добиться того, чего нельзя допускать.
Я приведу несколько серьезных, но и забавных примеров.
Вот короткое, очень короткое видео, которое демонстрирует, как может работать социальная инженерия, пытаясь заставить сотрудника службы поддержки предоставить вам доступ к какой-то учетной записи или даже просто к информации;
Отрывок из фильма «Кто я»
Вот ещё, на английском, можете включить субтитры на русском:
Какими бы глупыми ни казались вышеперечисленные действия, они эффективны. Вы входите куда-то, одетые так, будто вам нужно сделать какую-то работу, и некоторые люди не будут беспокоиться. Они решат, что вы - часть их самих, или не захотят устраивать сцену и останавливать кого-то, потому что вы потенциально можете нарушить чью-то работу или график.
Представьте, что вы работаете в крупной IT-компании, где двери здания закрываются на ключ-карту. Представьте, что кто-то идет позади вас и хочет попасть в тот же (запертый) отдел. Это большая компания, представьте, что в здании находится 10 000 человек. Вы открываете дверь, человек позади вас тоже хочет войти. Любой нормальный человек просто придержал бы дверь и был бы вежлив, верно? А что, если этот человек не должен иметь доступа в помещение? Вы этого не знаете, и вы не хотите быть придурком и буквально сказать парню "подожди", и нахрен закрыть перед ним дверь. Никто так не делает, и я не виню людей, но это все равно социальная инженерия.
Что касается сотрудников службы поддержки, имейте в виду, что профессиональные компании и их сотрудники часто обучены против этого. Однако это не значит, что вы сами не уязвимы для этого. Представьте, что вы начинающий игрок, не имеющий бюджета, пытающийся сделать уникальный сервер Minecraft. Все мы сталкивались с классическим "Здравствуйте, я из PlanetMinecraft, у вас вирус, пожалуйста, дайте мне админку", но все мы знаем, что это (надеюсь) никого не обманет. Но если вы отчаянно пытаетесь получить что-то уникальное, вы можете увидеть, как разработчик запрыгивает на ваш сервер, предлагая вам бесплатный пользовательский плагин. Вы обрадовались, он сделал несколько "функций", вы установили его, и бум, вы в полной заднице; вы только что установили вредоносное ПО.
Социальная инженерия просто повсюду, и она полагается на ошибки людей, а не на исполняемый код. Это особенно пугает тех, кто неопытен или просто не знает о безопасности. По крайней мере, осознание - это то, что вы должны получить от этих сообщений.
Подытожим
Риски встречаются повсюду. Выявить их бывает довольно сложно. Я не могу дать вам простой контрольный список, по которому вы можете пробежаться. Вам необходимо получить определенные знания по этим темам, и где все может пойти не так, чтобы вы могли самостоятельно перепроверить такие вещи, как SQL-инъекции. Последнее редактирование:
