sudo: 3 попытки ввода неверного пароля - может ли root видеть пароль открытым текстом?

Если какой-либо пользователь не может получить доступ к какой-либо команде sudo3 раза, об этом следует сообщить пользователю root в журналах доступа \ ошибках.

Может ли root увидеть эти попытки (например, пробные пароли) в тексте в журналах?

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

Попытки входа в систему успешные и неудачные входят в систему

/var/log/auth.log

Пример успешной попытки:

Oct 23 21:24:01 schijfwereld sudo: rinzwind : TTY=pts/0 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash
Oct 23 21:24:01 schijfwereld sudo: pam_unix(sudo:session): session opened for user root by (uid=0)

И неудачно

Oct 23 21:25:33 schijfwereld sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/1 ruser=rinzwind rhost=  user=rinzwind
Oct 23 21:26:02 schijfwereld sudo: rinzwind : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash

Он регистрирует неудачную попытку и также записывает в общей сложности 3 неправильно введенных пароля.

Пароли для sudoпопыток никогда не показываются и не сохраняются.

Обычная практика - не регистрировать пароли, используемые при попытках входа в систему, даже если рассматриваемый пароль был недействительным. Это просто потому, что пароль может быть действительным для другого пользователя в той же системе (например, пользователь неправильно набрал свое имя пользователя , а не пароль) или может быть тривиальным изменением действительного пароля (пользователь пропустил букву или около того).

Любой из этих случаев оставил бы незашифрованный пароль, лежащий в системе, уязвимым для некоторой утечки информации. (Пароль также может быть действительным паролем для какой-либо другой системы, отличной от той, в которой он был введен, но это действительно большая проблема для «них», а не для «нас».)

В некоторой степени с этим связаны случаи, когда пользователь записывает свой пароль вместо своего имени пользователя (например, он обычно использует систему, которая вводит имя пользователя автоматически, но теперь этого не делает, но все же вводит пароль в первую очередь). В этом случае у вас будет незашифрованный пароль в журналах. Это не оптимально, но полезно видеть имена пользователей для обычных неудачных попыток входа в систему, и не существует простого решения для их хранения, кроме паролей, введенных в качестве имен пользователей.

Тем не менее, ничто не мешает администратору системы также заставить систему регистрировать пароли. Добавление регистрации, вероятно, можно сделать, добавив один вызов syslog()и перекомпилировав модуль PAM. (PAM - это то, что и sudoиспользует Ubuntu , но, конечно, то же самое относится и к веб-приложениям и ко всему прочему.)

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

Говоря в общем, очень немногие программы в Unix когда-либо регистрируют реальные пароли в системном журнале или где-либо еще - почти никогда нет веских причин для этого, и есть веские веские причины этого не делать.

Из-за способа хеширования паролей система не может определить разницу между неправильным паролем и опечаткой. Если ваш пароль был% $ zDF + 02G, и вы ввели% $ ZDF + 02G, он вас так же сильно подведет Если бы вы ввели «rubberbabybuggybumpers», но регистрация неудачного пароля выдала бы ценную информацию злоумышленнику, читающему журнал.

Один случай , я нашел , где программа действительно имеют возможность войти пароли (и случай использования , где это было бы хорошей идеей) в серверах RADIUS, где вы можете в крайнем случае включения дополнительной информации-чем-- Вы, вероятно, хотели режим отладки, а затем явно добавили флаг, который означает «да, включая пароли», потому что у вас клиент не может подключиться, и вам необходимо исключить абсолютно все возможные причины ...