Плагин [ADMIN/SEC] UltimateServerProtector - плагин на уникальный админ-пароль для каждого игрока!

О класс, надеюсь бага не будет то что пароль нельзя ввести

 

Его и так нет. Если использовать дефолтный конфиг особенно, и даже не дефолтный у меня проблем не вызывал

 

Ну окей, ладно

 

Подниму, пожалуй.

В связи с последними событиями было не особенно до плагина. Думаю попозже выпущу версию 6.6 так сказать официально, но когда это будет - я не знаю

 

Обновление 6.6.6 (прекрасное число)

> Исправлены ошибки при командах
> Добавлена отмена поднятия предмета при не введенном пасе

 

Возможно я очень слеп, но просмотрев конфиг не заметил параметра включения/отключения админ-команд.

 

# Настройки повышенной безопасности
secure-settings:
# Применять ли наказания к операторам которых нет в списке
enable-op-whitelist: true
# Включить ли команды добавления новых игроков в конфиг
enable-admin-commands: false
# Включить ли IPWhitelist для администраторов
enable-ip-whitelist: false
# Выключать ли сервер, если отключается плагин (отключено по умолчанию) (запрещайте отгружать плагин в конфиге plugman)
shutdown-on-disable: false

 

Ап!

Хороший подарок мне на НГ :3

 

Исправил ошибку с логгированием 1 неуспешной попытки ввода админ-пароля.
Это было довольно глупо. Забыть переименовать 1 строку...

 

Обновление 6.7
> Добавлена возможность изменять сообщения в логах плагина.
> Багофикс, связанный с броадкастами в консоль и записями в логи.

Возможно, как ранее просили, добавлю поддержку PAPI, хотя и не вижу в этом большого смысла

 

Обновление 6.7.5
> Добавлено оповещение и запись в логи момента, когда игрок, будучи на сервере, был "пойман" на проверке на наличие админ прав. Полезно, если вы не используете функцию проверки на наличие игрока в конфиге.
> Исправлен недочет, связанный с неоднократным добавлением игрока в хешмапу "неавторизованных", когда у того имеются админ-права. (я не знаю как выразиться корректнее, но так или иначе, эта хрень вызывала забивание памяти, при отключенной функции лимита времени на ввод пароля и наказаний за отсутствие в конфиге особенно)
> Исправил проблемы с режимом сессии. Теперь её можно нормально отключить. хотя зачем?...

 

Hotifx 6.7.6
> Исправил ошибку со временем за которое игрок будет должен ввести админ-пароль

 

Hotfix 6.7.7
Попытался зафиксить просадку ТПС при включённом оп-вайтлисте на крупных проектах.
не знаю будет ли оно работать, но должно
Также добавил ссылку на скачивание с гугл диска, мало ли кому то с яндекса не удобно

 

В чём преимущество данной защиты перед двухфакторками через социальные сети и всякие google authenticator?

 

В первую очередь тем, что он тригерится на любого "администратора", даже если тот получил права нелегально тем или иным образом. Если вдруг кто-либо из высшей администрации с доступом к админ-правам, но не к файлам решит выдать админ-права тому или иному игроку (за деньги ли, или просто на твинк, для того чтобы в случае снятия делать гадости) U S P сразу пресечет попытки это сделать, т.к. без паса админка ничего не значит.
В отличие от плагинов на привязки к ВК иди гуглу, защита в виде паса даётся фактически насильно, что не даёт её отключить и следовательно подвергнуть аккаунт администратора опасности.
Также стоит вспомнить про вайтлист операторов, вайтлисте админ-IP и системе логгирования, что поможет определить в случае чего попытку нелегальной выдачи прав или взлома администратора.

 

Первое, что меня смущает - это отсутствие шифрования паролей администраторов. В случае утечки файла будут скомпрометированы данные сразу нескольких людей.
Во-первых, это повысит шанс взлома сервера.
Во-вторых, это повысит шанс взлома учётных записей администраторов. Многие используют одинаковые или очень схожие пароли везде и всюду.
Лучше не рисковать, и шифрануть SHA256 или bcrypt. Сделать это несложно, но в случае факапа проблем будет ощутимо меньше.

Администратор может благополучно добавить другой ник в список администраторов и назначить ему пароль при помощи /usp
Я не думаю, что хоть у кого-то будет ситуация, что у администратора есть право на /op, но нету на /usp. Смысла в этом ноль. Фактически на команду /usp можно повесить то же право, что и на /op - ничего не изменится.
Таким образом, от недобросовестных администраторов можно защититься лишь переключением параметра enable-admin-commands в значение false.
Но с таким же успехом можно было бы просто запретить выполнение команды /op от имени игроков, разве нет?
Короче говоря, неясен смысл отдельной команды и отдельного списка администраторов.
В то, что администратор может не знать про существование /usp, я тоже верю слабо.

Так что то, о чём ты написал - это скорее защита от стандартных хак-плагинов "на опку", поскольку они как раз не будут использовать команду /usp. По крайней мере пока твой плагин не особо популярен.

Окей, концепция классная. Но по факту это все та же двухфакторка. Сначала человек вводит один пароль, чтобы авторизоваться, а потом ещё один, чтобы пройти проверку USP. Эти два фактора имеют одинаковый тип. А это с точки зрения безопасности не очень хорошо. Про типы факторов авторизации можно почитать тут: https://habr.com/ru/company/1cloud/blog/277901/

Конечно, вместо "второго пароля" можно было бы придумать ещё миллион разных способов подтвердить второй фактор. Но зачем, если все это давно реализовано в плагинах на авторизацию?
Я веду к тому, что наиболее безопасным и удобным для администраторов вариантом была бы интеграция с плагинами авторизации, а именно с системой двухфакторок.
Условно говоря "аддон", принуждающий администраторов включать двухфакторку в плагинах на авторизацию.
Естественно, в начале придется делать интеграцию для наиболее популярных плагинов на авторизацию, но в конечном итоге получится максимально гибкий инструмент: хочешь - авторизуйся через ВК, хочешь - через дискорд, хочешь - через гугл. Причём ты не реализуешь все эти способы сам, а полагаешься на плагины авторизации. Не запариваешься с безопасным хранением токенов и пользовательских данных, не фиксишь баги, не думаешь над введением новых типов двухфакторок, а сидишь и отдыхаешь.

Насколько это сложно сделать технически - я не знаю. Но идея кажется мне достаточно интересной. Как минимум тут есть, о чём подумать.

Итог.
На текущий момент лично я для себя определил функционал твоего плагина так:
1) Принудительный второй фактор авторизации для администраторов (кстати жаль, что только для них)
2) Защита от примитивных хак-плагинов, выдающих права. Также оповещения о попытках выдачи и санкции для тех, кто попытался получить права
3) Возможность полностью отключать выдачу админских прав (и из игры, и из консоли). Хотя реализовал бы я это иначе, более нативно
4) Защита по IP админских аккаунтов. Правда это уже дублирование функций плагинов на авторизацию

 

Дело в том что не сами администраторы создают себе пароли, а лично главный админ, имеющий доступ к файлам. Шифровать пароли так или иначе не выйдет, т.к. подразумевается, что админ должен их лично каждому прописывать. Если он не глупый и будет создавать их не бездумно из 6 символов, то всё будет хорошо.

А вот если файл вдруг слили... то тут уж админ просчитался. Это всё равно что слить свой конфиг от аучми где указаны данные от БД.

По этому есть возможность не включать эти команды вовсе, что собстенно я рекомендую. В будущем может сделаю так, чтобы эти команды можно было выполнять только от консоли при желании, однако если на сервере установлены такие плагины как MyCommand или NoCheatPlus, жить будет трудно, т.к. они могут выполнять команды на прямую из консоли, что отключить нельзя, только заблокировать команды. Но тогда почему бы в таком случае не заблокировать команду /ups и алиасы?

А тут мы имеем дело с тем что... а плагин на принудительную привязку к ВК для администраторов имеется. AAP называется. К сожалению автор на него немного забил, так бы был идеальной заменой USPа.
Проблема в одном - удобство. Когда тебе нужно ввести админ-пароль ты можешь поставить мод на бинды и входить по нажатию кнопки в игре. Когда тебя просит ввести код из гугла или ВК, то тебе приходится самому вводить данные, что из раза в раз делать просто надоедает.

Для людей знающих как работать с ВК ДС и ТГ апи думаю будет не так и трудно, но чеееерт, это громадная работа.

У меня была идея проще, но куда эффективнее. Сделать ввод пароля через GUI меню, что обезопасит людей от такой штуки как цмд-логгер. Но как это реализовать я не думал, работать с гуи это для меня трудновато, но может быть, когда нибудь

 

Помимо этого, я бы рекомендовал конфиг от тех данных, которые меняются "динамически" - от списка администраторов с их айпишниками и паролями.
Во-первых, пересохранение конфига вызовет сложности с комментариями.
Во-вторых, это может привести к потере данных при редактировании администратором и одновременном сохранении сервером.

 

Реализую в следующих апдейтах, хотя когда они будут этого не знает никто

 

Вот только в самой БД все пароли будут зашешированы и засолены, что приведет к меньшему количеству проблем, чем если бы они были в открытом виде.
Поэтому хешировать все же стоит.
Как это сделать технически - вопрос другой. Так, например, не вижу проблемы в том, чтобы использовать хеширование прям в команде /usp setpass

Секундочку. Плагин рассчитан на безопасность в первую очередь. С точки зрения безопасности это не лучшее решение (почему - объяснил выше). Так, например, сопрут с компа файл с биндами, и все полетит в трубу.
Но если уж хочется добавить удобства - можно точно так же использовать сессии, которые уже реализованы.

Я не предлагаю работать с апи ВК, ДС, ТГ и прочими. Я предлагаю работать с уже существующими плагинами на авторизацию, чтобы заставить их принудительно требовать от некоторых игроков включение второго фактора. Этой работы куда меньше.
Перечитай ещё раз, что я предложил выше.

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

Собственно, встаёт вопрос - зачем реализовывать то, что скоро может стать неэффективным?
Мне кажется, куда разумней уделить время реализации второго фактора, который заведомо не подвержен работе перехвате трафика через майн?
Перечислять примеры не буду, ты и сам знаешь миллион таких, что не завязаны на игру