Так собственно все эти useradd, adduser меняют /etc/passwd, /etc/shadow, /etc/group
Когда я писала про мониторинг файлов /etc/passwd, /etc/shadow и /etc/group — это был как вывод ко всему разделу, что создавать пользователя — так себе идея для скрытого закрепления (какой бы техникой вы не пользовались). Возможно из-за прямого упоминания файлов, непонятно, что фраза относится к любому из перечисленных способов. Я подумаю, как перестроить абзац, чтобы подобных казусов не возникало.
Насчет демона — спасибо, я просто совсем об этом не подумала. Это действительно проще и тоньше.
Можете уточнить, сколько раз вы создавали свои библиотеки с такими же именами и пользовались таким способом?
Если честно, то один раз на CTF. Так как я пыталась сделать просто обзор, то включила эту технику. Сложная техника — это тоже техника. И она имеет право на жизнь.
Спасибо за ваш комментарий, мне приятно, что вы не прошли мимо и указали на ошибки/недоработки.
PAM
Pluggable Authentication Modules — модули для аутентификации, как несложно догадаться по переводу. До появления PAM администратору приходилось пройти все 12 кругов ада, чтобы настроить какую-то внешнюю систему аутентификации. Сейчас надо изменить пару строчек в паре конфигурационных файлов. Если в файле /etc/pam.d для всех определенных модулей выставить control_flag в значение optional, то мы сможет входить в систему вообще без пароля. Как и администраторы. Поэтому наш бекдорчик быстро найдут и закроют точку входа.
Если у нас уже root, и мы добавляем ключ в его домашнюю директорию, то тут больше вопрос, можно ли руту подключаться по SSH. И тогда скорее надо править конфиг ssh.
Если это обычный пользователь, то мы вряд ли сможем отредактировать sudoers
Есть третий вариант, когда пользователь не root, но имеет его привилегии (может делать sudo su). Но тогда нам в любом случае надо знать пароль. Или через sudoers можно сделать так, чтобы пароль не запрашивался?
Да, Вы абсолютно правы.
Но цель написания этой статьи была немного в другом. А именно объяснить возможную причину возникновения ошибки и дать решение, если кто-то с ней уже столкнулся. По тексту ошибки сложно найти ответ, тем более на русскоязычных ресурсах.
Спасибо.
Когда я писала про мониторинг файлов
/etc/passwd,/etc/shadowи/etc/group— это был как вывод ко всему разделу, что создавать пользователя — так себе идея для скрытого закрепления (какой бы техникой вы не пользовались). Возможно из-за прямого упоминания файлов, непонятно, что фраза относится к любому из перечисленных способов. Я подумаю, как перестроить абзац, чтобы подобных казусов не возникало.Насчет демона — спасибо, я просто совсем об этом не подумала. Это действительно проще и тоньше.
Если честно, то один раз на CTF. Так как я пыталась сделать просто обзор, то включила эту технику. Сложная техника — это тоже техника. И она имеет право на жизнь.
Спасибо за ваш комментарий, мне приятно, что вы не прошли мимо и указали на ошибки/недоработки.
Вы имеете в виду этот пам?
It depends
Если у нас уже root, и мы добавляем ключ в его домашнюю директорию, то тут больше вопрос, можно ли руту подключаться по SSH. И тогда скорее надо править конфиг ssh.
Если это обычный пользователь, то мы вряд ли сможем отредактировать sudoers
Есть третий вариант, когда пользователь не root, но имеет его привилегии (может делать sudo su). Но тогда нам в любом случае надо знать пароль. Или через sudoers можно сделать так, чтобы пароль не запрашивался?
Можешь подробнее объяснить, что ты имеешь в виду?
Ну если только так)
Но с другой стороны во wrapper можно сразу положить полезную нагрузку, без лишнего шага в виде trap :)
Но цель написания этой статьи была немного в другом. А именно объяснить возможную причину возникновения ошибки и дать решение, если кто-то с ней уже столкнулся. По тексту ошибки сложно найти ответ, тем более на русскоязычных ресурсах.
Спасибо.