Из соображений безопасности переименуйте / etc / passwd и / etc / shadow [закрыто]

8

У меня есть сервер. Мой сервер защищен, но давайте представим себе хорошего хакера, который входит. Теперь он может посмотреть /etc/passwdи /etc/shadow. Я хотел бы переименовать эти файлы /etc/passwdв нечто подобное /etc/xxanoda.

Я думал, что могу сделать ссылку, но для хакера это будет легко сделать ls -l.

Можно переименовать эти файлы и по-прежнему иметь работающую ОС, без проблем совместимости, или это совершенно бесполезно? Просто для поиска знаний.

Марко Каджано
источник
1
Я думаю, что можно использовать отдельный сервер аутентификации, чтобы хранить все пароли пользователей. Главный сервер свяжется с сервером аутентификации, когда пользователь попытается войти в систему. Сервер аутентификации держится подальше от пользователей (прямой доступ в Интернет отсутствует).
Ctrl-Alt-Delor
9
Безопасность по неизвестности - это не безопасность вообще.
дверная ручка
Это ужасная, ужасная, ужасная идея.
Шадур

Ответы:

29

Filesystem Hierarchy Standard для Unix-подобных систем включает /etc/passwdв определенном месте, и инструменты , следовательно , обычно жёстко смотреть там для него. Хотя теоретически вы можете перекомпилировать все соответствующие утилиты для поиска в новом месте, любой злоумышленник всегда может просто искать строки в этих двоичных файлах, чтобы найти новый файл, или использовать регулярные выражения для поиска файлов с passwdаналогичным содержимым.

shadowФайл должен быть доступен для чтения только root(и , возможно , к группе под названием shadow). Если злоумышленнику удалось получить root-доступ к вашей системе, он имеет полный контроль, и то, могут ли они читать ваши файлы passwd / shadow, на данном этапе не имеет значения.

Вероятно, есть несколько ситуаций, когда наличие файлов, находящихся не в ожидаемых местах, может помочь, например, если у вас плохо настроенный веб-сервер, который позволяет кому-то запрашивать http://myserver/../../etc/passwd, но в целом такого рода косвенное обращение потребует много работы для минимального преимущества безопасности.

chronitis
источник
8
В последнем случае лучше вместо веб-сервера исправить ...
Braiam
Но это нормально, потому что все пользователи с учетными записями на самом сервере не имеют паролей, только SSH-ключи, и информация о паролях в /etc/passwdлюбом случае не сохраняется , верно?
Blacklight Shining
12

Лучшее, что было бы, это «совершенно бесполезно», как вы выразились. (Это не создает дополнительного препятствия для злоумышленника)

/etc/passwd действительно содержит имена учетных записей, но любой, кто имеет доступ к оболочке, сможет найти их.

/etc/shadowсодержит конфиденциальную информацию (хеши паролей), но она доступна только для пользователя root. Если злоумышленнику удалось получить права суперпользователя - что вы можете сказать о катастрофе ?

guntbert
источник
1
Вы также должны предполагать, что злоумышленник имеет полный доступ к каждому файлу в вашей системе (и, возможно, скачал свою собственную копию), пока вы не узнаете иначе.
Берт
4
"Как вы пишете катастрофу?" вероятно, лучше работает в контексте, где вам не нужно произносить стихийное бедствие, чтобы спросить его: D
9

В современных Unices (и Unix-подобных, в том числе Ubuntu) /etc/passwdне содержит никаких секретов. Переименовать его будет гораздо сложнее, чем стоит, учитывая, сколько утилит потребуется перестроить, чтобы найти его на новом месте.

/etc/shadowДругое дело, поскольку в этом файле есть секреты, но переименование не поможет. Он доступен для чтения только пользователю root, поэтому даже если хакер войдет в систему как другой пользователь, этого недостаточно для доступа к файлу. Вот почему пароли были удалены /etc/passwdв первую очередь: каждый должен уметь читать/etc/passwd , но только root должен иметь возможность получить действительные пароли, поэтому пароли были перемещены в файл, который мог прочитать только root.

Если хакер делает получить корень, то переименование не спасет вас. Простой рекурсив grepможет дать хакеру список файлов в /etc/shadowпохожем формате, и тогда хакеру нужно только просмотреть их, чтобы найти нужные ему данные. Вы задержали его максимум на несколько часов, а возможно, и меньше: опять же, не стоит того времени, которое потребуется для изменения и перекомпиляции всех утилит, которые зависят от /etc/shadowместоположения.

Ложка
источник
Кроме того, если у него есть доступ с правами root, ему не нужен пароль. Он может просто suвойти в любой аккаунт или сменить пароль любого пользователя в системе. И если он действительно хочет иметь пароли (на тот случай, если пользователи повторно используют свои пароли в другом месте), он может загрузить измененный loginдвоичный файл или добавить pamмодуль, который перехватывает попытки аутентификации и передает ему комбинации имени пользователя / пароля.
Шадур
2

Вы не можете просто переименовать эти файлы. Многие процессы и программы будут искать их, так как это стандарт в системах Linux. Что вы можете сделать, так это правильно защитить ваш сервер.

Frantique
источник
Я просто хотел добавить больше безопасности, у меня есть более одного веб-сайта на моем сервере.
Марко Каджано
2

Хотя это, наверное , не использовать для переименования /etc/passwdи /etc/shadowфайлов, если вы хотите дополнительную безопасность вы можете захотеть взглянуть на РАМ (вставные модули аутентификации) и NSS (Name Service) Переключатель. Как здесь.

PAM можно использовать для добавления модулей аутентификации, которые вместо чтения своей аутентификационной информации из стандартных файлов считывают ее из другого источника, например из ldap или базы данных. Использование его будет означать, что /etc/shadowего можно почти полностью исключить.

NSS дополняет PAM, делая некоторые разрешения имен (например, к каким группам принадлежит этот пользователь) независимо от стандартных файлов ( /etc/passwd, /etc/groups). Его использование будет означать, что ваш файл passwd потенциально будет содержать только запасную опцию для root, и ничего более. Использование ключей SSH для проверки входа в систему root также устранит необходимость иметь пароль root внутри теневого файла (хотя это может быть желательно, если разрывается соединение SSH).

В качестве альтернативы, если вы не хотите аутентифицировать своих пользователей через отдельную базу данных или хост ldap, вы также можете создать свои собственные модули PAM и NSS, которые читают их данные из нестандартного файла, хотя я бы не рекомендовал этот вариант.

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

Обратите внимание, что не все приложения поддерживают PAM (однако многие из них поддерживают). Однако NSS можно использовать для реализации аутентификации для приложений, которые не поддерживают PAM, и некоторые сайты, о которых я читал, действительно предлагают такой подход. Это, однако, означает, что модуль NSS предоставит (потенциально) хешированный пароль любому, кто может получить доступ к слою аутентификации NSS, чего почти всегда нужно избегать (в основном это то же самое, что предоставить некорневому доступу на чтение к теневому файлу). )! Поэтому, если вы собираетесь использовать этот подход, всегда убедитесь, что NSS используется только для предоставления пользователю основных данных (например, содержимого /etc/passwd), а PAM используется в качестве уровня аутентификации.

SztupY
источник