☰

Почему наличие пользователя без пароля может быть плохой идеей (в этом сценарии)?

tag-icon • tag-icon security users password non-root-user privileges
Почему наличие пользователя без пароля может быть плохой идеей (в этом сценарии)?

Я думал, разместить ли это здесь или в разделе безопасности SE... но решил выбрать Unix SE, поскольку это не совсем вопрос криптографии, а скорее пользователей/привилегий Linux. Возможно, мой гугл-фу сегодня слаб, но единственное, с чем я столкнулся до сих пор, либо

  1. иметь очень общие, неопределенные ответы о том, что это «плохая практика» или «не одобряется» без каких-либо конкретных примеров, или
  2. есть ответы, которые предполагают, что пользователь без пароля имеет права root или иным образом игнорирует все возможные меры защиты.

Для ясности: я не защищаю это и на самом деле ищу веские причины.нетсделать это, но я хотел бы найти конкретные причины, а не просто «это плохо». :-)

Итак, разобравшись с этим, позвольте мне привести пример, который на самом деле заставил меня задуматься об этом в первую очередь:

Допустим, я рассматриваю возможность настройки домашней системы, где у меня будет надежный пароль на rootаккаунте. Кроме того, у меня будетнекорневая учетная запись с именем fredто естьНЕТв группе администраторов wheel(или sudoersв Debian / Ubuntu). В этой системе у меня также будет /homeотдельный, зашифрованный LUKS раздел, который будет разблокирован во время процесса загрузки. Другими словами, парольделаетвсе еще вводятся между GRUB и менеджером входа - но менеджер входа настроен на автоматический вход. Кроме того, предположим, что я также настроил (от root) password -f -u fred:принудительная разблокировкапароль для fred(фактически делая fredпароль пустым).

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

  • Разделы LUKS не закрываются при срабатывании блокировки заставки (по крайней мере, не в Cinnamon и при условии, что одинявляетсянастроен на срабатывание). Так что если кто-то проник в мой дом и fredуже вошел в систему, он мог бы просто сесть и включить монитор, а затем продолжить просматривать все, fredк чему имеет доступ, — если только он сначала не отключит/не перезагрузит/не унесет ПК (и таким образом снова не заблокирует LUKS). И я подозреваю, что если бы я достаточно постарался, я мог бы найти способ вызвать скрипт при срабатывании заставки, а затем заблокировать LUKS из этого скрипта, тем самым закрыв эту дыру (или, может быть, kde/xfce/gnome/etc уже имеют какой-то способ позаботиться об этом?).

Даже если бы fredу него был хороший надежный пароль, он не мог бы установить программное обеспечение / возиться с системными настройками, не будучи администратором. И, я не знаю наверняка, но я думаю, что доступ браузера / Wine к файлам не изменился бы в любом случае. Есть ли здесь что-то более рискованное, чем если быfred делалесть пароль?

Редактировать: Я не думаю, что это имеет значение, но дистрибутив — Fedora (с включенным SELinux), но если вам удобнее отвечать относительно другого дистрибутива (или без SELinux), это нормально.

Редактирование №2: Относительно ssh/ samba. Я обычно настраиваю что-то вроде /media/sdb1/sharedпапки, а не использую общие ресурсы Samba $HOMEили как они там называются. Я считаю, что это довольно легко настроить в небольшой пользовательской среде, например дома (я бы, очевидно, не стал делать этого в рабочей среде или в среде, где не все пользователи доверяют друг другу). Но я всегда использую отдельные, защищенные паролем учетные записи пользователей Samba (не те же пользователи, которые входят в систему) и следую нескольким руководствам по укреплению своей smb.confнастройки. Если вы увидите недостатки в этой настройке, я буду считать их допустимыми для атаки на гипотетический сценарий/настройку с пустым паролем в учетной записи входа fred(помните, что пароль учетной записи Samba — этонетхотя и пусто).

Для ssh, я хочу подтвердить, что по умолчанию пустые пароли отклоняютсявсеучетные записи (не только на root). Если нет, то я буду считать ответ FelixJN действительным. В противном случае, я бы - аналогично samba- вероятно, использовал ту же настройку, которую я обычно делаю, которая является усиленной версией конфигурации по умолчанию. Я не помню, чтобы менял много настроек для этого, поэтому я попытаюсь посмотреть, смогу ли я найти, какие именно настройки я обычно изменяю, и включить их сюда. Не в своей голове, я знаю, что меняю номер порта, но это не так уж важно.

Подтверждая sshотклонение, я был удивлен, увидев, что LM19, passwdпохоже, не поддерживает -fфлаг (force), поэтому, как ни странно, я смог создать только пустого пользователя non-root на fedora. Когда я попытался перейти sshс ящика LM19 на fedora, мне было отказано:

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

Помимо порта, похоже, я также увеличил минимально допустимые шифры/MAC-адреса/KexAlgorithms, уменьшил LoginGraceTime/ MaxAuthTries/ MaxSessions, установил PermitRootLogin no/ UsePAM yes/ ChallengeResponseAuthentication no. Для PermitEmptyPasswords:нет, похоже, было значением по умолчаниюно я высказался ясно.

решение1

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

При использовании пользователей без пароля ваша задача — проверить каждую сетевую службу на вашем компьютере, чтобы выяснить, разрешает ли она удаленный вход без пароля.

Общий принцип безопасности заключается в том, что вы хотите, чтобы что-то «отвалилось», заблокировав всех, а не впустив никого. Если у вас есть пользователи без пароля, то ошибки и простые упущения с большей вероятностью откроют где-нибудь какую-нибудь лазейку.

Одним из таких примеров могут быть почтовые серверы. Если у вас есть машина с публичным адресом IPv4, то, гарантированно, естьволябыть еженедельными или даже ежедневными попытками входа в SMTP. Хакеры просто перебирают каждый адрес IPv4 в поисках уязвимой машины (всего 4 миллиарда адресов).

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

решение2

Я бы обычно рассматривал следующие аспекты:

  1. Удаленный доступ:

Если у вас есть какие-либо опции удаленного доступа, например sshактивные, это открытая дверь по очевидным причинам. В этом случае пункты 2 и 3 особенно применимы.

  1. Конфиденциальность и безопасность данных:

Ваш пользователь раскрывает информацию, которая, возможно, не должна быть доступна непривилегированным пользователям, и, конечно, ваша дата может быть удалена кем угодно. Некоторые люди просто разрушительны.

  1. Безопасность системы:

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

Вопрос в том, сколько камней вы готовы положить на чьем-то пути.

Итак, возникает вопрос: зачем нужен пользователь без пароля, если можно использовать автоматический вход и избежать хотя бы некоторых из этих рисков, максимально повысив потребность в физическом доступе?

Связанный контент