Комментарии 42
Но ведь ни что не мешает запретить удалённый логин рутом и использовать su после логина другим пользователем.
Первая картинка интригует. Как вариант, можно не искать BeOS, а взять её реинкарнацию — Haiku.
В беосе не было мультиюзерности, все эти зачатки портировались из юникса видимо случайно или как заглушки для обратной совместимости.
Дела минувших дней:
Fun with Linux - Changing the root user name
https://web.archive.org/web/20150402063400/http://linuxers.org/article/fun-linux-changing-root-user-name-linux
How do you rename root?
https://unix.stackexchange.com/questions/8447/how-do-you-rename-root
Так наверно можно поиграться. Пробовать не советую.
Переименование root — ничем не лучше изменения порта sshd. Security by Obscurity. Я никогда не понимал, почему в пингвиниксах по умолчанию разрешён удалённый вход для root.
В Windows пользователь Administrator ничем не отличается от других пользователей, кроме хоть и расширенного, но всё равно далеко не полного набора прав, предоставленных ему изначально. Его можно без последствий переименовать или лишить каких угодно прав.
В Windows имеет значение не имя пользователя, а группы, все права системой назначаются на них. И есть учётные записи служб - вот они ближе по аналогии к root. Но вряд ли удастся их переименовать.
В Windows имеет значение не имя пользователя, а группы, все права системой назначаются на них.
Это, говоря мягко, неправда. Во-первых, в любой сколько-нибудь нормальной ОС не имеют значения ни имя пользователя, ни имя группы, поскольку это всего лишь символические имена для удобства человека. В Unix это uid/gid (хотя и есть ещё старый код, куда “root” вшит в код). В Windows — SID'ы (и у пользователей, и у групп). Во-вторых, права в Windows могут предоставляться (и предоставляются, посмотри внимательно дефолтную Local Policy) конкретным пользователям.
Модель безопасности NT на три головы выше, чем в Unix. Оно и понятно, Unix до сих пор тащит на себе порочное наследие самых первых версий — uid=0. Это — неизлечимая дыра Unix, и она полностью отсутствует в NT. И access token'ы в NT — от рождения, а не привинченные сбоку к примитивной модели Unix.
Сиды в Windows жёстко ассоциируются с определёнными сущностями, поэтому справедливо называть их по именам. Базовые группы и их права, учётки служб - являются неотъемлемой частью системы, у нас нет возможности настроить их по другому. По сути, суперпользователь в Windows - все учётные записи служб вместе взятые плюс группа Администраторы и именно этот набор можно считать полной аналогией root.
Второй день про себя рассуждаю, а какая парадигма всё таки лучше, развитой набор прав, как в Винде, или один гарантированный на всё?.. При всей дырявости uid=0, Винда, будем честны, тоже нам ничего не гарантирует. Выделение ролей выглядит более взросло, но концепция *никсов позволяет реализовать это разделение на более высоком уровне сводя управление ролями к одному сервису. В общем, считаю эксперимент AlexGluck весьма любопытным, с точки зрения изучения возможности перехода Линя на систему разделения ролей служебных сущностей.
Модель безопасности NT на три головы выше, чем в Unix. Оно и понятно, Unix до сих пор тащит на себе порочное наследие самых первых версий — uid=0. Это — неизлечимая дыра Unix, и она полностью отсутствует в NT. И access token'ы в NT — от рождения, а не привинченные сбоку к примитивной модели Unix.
К этому абзацу — одни вопросы. Ну, кроме, разве что, двухуровневой системы прав, где ACL добавляется опционально (и в подавляющем большинстве инсталляций — не нужен)
Пару раз экспериментировал с переименованием рута, в нормальных системах всё продолжает работать и никаких фантомных рутов не создаётся как в центос\редос.
Правда некоторые уведомления захардкожены, если их поправить, то вообще супер. В линуксе руту даже сменить айдишник можно будет, а не только имя, вот теперь задумал поиграться.
Вот только настроить права нормально ещё тот квест. Да и половина программ работать перестаёт если не под админом установлена.
Есть костыль в виде создания второго юзера с идентификатором равным нулю (например - ручным редактированием /etc/passwd). Таким образом, появляется "запасной вход" с правами суперпользователя.
Правда, даже если вы зайдёте от имени этого второго пользователя, имя все равно будет отображаться "root"
Мэйнтейнерам сообщили об ошибках? Или так и будем это терпеть?
А смысл?
Можно взять какой-либо rc-init типа дистрибутив или до D-Bus и там можно изгаляться без проблем.
А здесь - просто человеческий фактор, когда общее умолчание в многих компонентах Обще Системного Программного Обеспечения (ОСПО) сделали безальтернативным.
Хотя в самом ядре никаких таких жёстких привязок нет. Т.е. наверняка в андроиде такую проблему возможно не наблюдают.
В интернете много желающих перебирать пароли к SSH, что получить мощности вашего сервера безвозмездно.
что?
Использовать нестандартный порт? Не поможет.
Поможет, особенно, если это действие комбинировать с ремэппингом стандартного порта (в джайл, на "мусорный" сервер и т.п.).
Поможет от пионеров перебирающих сканером диапазоны по стандартным портам.
Тому кто устроит полный перебор портов вашего сервера простая смена порта ничем не помешает.
Такие упоротые параноики как я ремэппят не только стандартный порт, но и пачку портов вида 9022, 9222, 10022, 20022, 22122, 22222 и т.п. Но брутфорсов по ним(при открытом 22) ни разу не было, так что это избыточность, хотя лиссяра говорил, что паранойи много не бывает.
Того, кто устраивает полный перебор портов, мгновенно угасит IPS.
Если сделать telnet на порт, где сидит SSH, то оттуда донесется что-то вроде
$ telnet 127.0.0.1 22
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1Так что просто смена поможет, но ненадолго.
не сильно, это все равно что ключ от двери поглубже под коврик сунуть.
если уж чуть болл серъезно думать о скрытии порта, то использовать portknocking (или pingknocking для винды) или более мудреные варианты
Для тех кто рассуждает о Windows: групповые политики позволяют сменить имя пользователей по умолчанию (администратор и гость), и первый пользователь в системе, вводимы при процедуре OOBE - не адинистратор по сути, а пользователь с возможностью запуска от имени администратора
Автор устроил двойную проверку переименуя root на void. Предполагаю, что из-за такого имени в первый раз поломалась CentOS streem. Когда прочитал, вспомнилось история с номерами в США на авто и текстом "void".
Там вроде был null, а не void?
У автора был NULL, а у его жены -- VOID. Но, надо сказать, я знал только про NULL.
https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/
Отключить вход по паролю? Лениво
Пройтись по всей системе, начиная со структур ядра, а потом попробовать несколько дистрибутивов? Фигня вопрос)
P.S. Авторизацию по ключам добавили в SSH где-то в 1995 году. Ожидается, что в Selectel знают про эту фичу.
Что будет, если переименовать суперпользователя? Экспериментируем, удивляемся и расстраиваемся…