Geum.ru

Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материалаРеферат

Содержание


Некоторые примеры
Записи РАМ в файлах журналов
Подобный материал:
1   ...   7   8   9   10   11   12   13   14   ...   101

Некоторые примеры


Теперь, когда вы имеете некоторое представление о возможностях модулей РАМ, давайте вновь обратимся к листингу 1.6. В первой его строке, имеющей тип auth, стоит вызов модуля securetty с флагом required. Стало быть, войти в систему как суперпользователь можно лишь с терминалов, перечисленных в файле /etc/securetty. Второй строкой проверяется пароль пользователя. Результат выполнения третьей строки определяется наличием файла /etc/nologin. Если такой файл не существует, возвращается значение УСПЕХ (SUCCESS). Четвертая строка закомментирована и потому игнорируется, но если удалить символ комментария, то будет включен механизм проверки удаленного доступа с использованием авторизации и паролей, управляемый файлами tty.dialup и passwd.dialup из каталога /etc/security. Последняя строка типа auth помечена флагом optional, однако она может понадобиться, если кто-то использует систему только для электронной почты.

Строка типа account проверяет, не устарел ли пароль пользователя.

Две строки типа session весьма стандартны. В первой строке модуль pwdb проверяет, может ли пользователь воспользоваться службой. Модуль второй строки, заносящий запись в файл lastlog, помечен флагом optional, поскольку пользователь должен получить возможность войти в систему даже в том случае, если файл lastlog не доступен на запись. Таким образом, в результате выполнения модуля lastlog вне зависимости от того, какое из трех значений — УСПЕХ (SUCCESS), НЕУДАЧА (FAILURE) или ИГНОРИРОВАТЬ (IGNORE) - получено, пользователь все равно сможет войти в систему.

Строка типа password помечена как required и предназначена для обновления маркеров авторизации в случае, если необходима смена пароля.

Некоторые файлы из /etc/pam.d весьма просты. В файле chfn, например, используется всего один модуль — pam_pwdb.so, помеченный как required для типов auth, account и passwd. Точно так же выглядит и файл для chsh. Файлы для служб электронной почты imap и pop чуть сложнее: в них модуль pwdb используется и для типа session, и еще вызывается модуль nologin для типа auth. Возможно, это не самая лучшая идея, но запись nullok разрешает использование «пустых» паролей.

Файлы остальных служб уже должны быть в принципе понятны, но пару-тройку из них, тем не менее, стоит прокомментировать. Во-первых, взглянем на файл службы ftp. В первой его строке используется модуль listfile. Смысл этой записи в том, чтобы посмотреть, есть ли имя данного пользователя в файле /etc/ftpusers, и если есть, отказать ему в доступе к ftp (в данном случае гораздо легче сказать, кто не может пользоваться ftp, чем перечислять всех, кто может). Если файл не существует или запись в него разрешается для всех пользователей, считается, что пользователь найден не был.

Теперь перейдем к файлу для rlogin. Первая строка проверяет, является ли безопасным терминал, с которого суперпользователь входит в систему (мы не хотим передавать пароль суперпользователя открытым текстом по сети, которой мы не доверяем). Поэтому проверьте, что у вас прописано в файле /etc/securetty. Согласно следующей строке наличия файлов /etc/hosts.equiv или ~/rhosts достаточно для предоставления доступа. Если же эти файлы не существуют, то доступ будет предоставлен лишь в случае успешного выполнения всех оставшихся модулей. Заметьте, строка, содержащая вызов модуля cracklib.so, закомментирована, поэтому, возможно, имеет смысл активизировать ее, чтобы пользователи не могли использовать небезопасные пароли.

Последний файл, на который стоит обратить внимание, это файл для службы su. Вот его первая строка:

auth sufficient pam_rootok.so

Эта строка позволяет суперпользователю становиться любым пользователем при помощи команды su без ввода пароля — свойство, которое вы уже, наверное, заметили, работая с системой.

Как видите, использование модулей и наличие возможности накопления их позволяет задавать авторизацию практически любой сложности. Если вы решите отредактировать какие-либо файлы из каталога /etc/pam.d в соответствии с собственными предпочтениями, то мне остается лишь посоветовать вам не лениться и всегда тестировать результаты изменений на нескольких сценариях, позволяющих проверить, что все работает точно так, как и было задумано, и никому лишнему доступ не предоставляется. Тестируйте как случай, когда авторизация должна проходить успешно, так и случай, когда подключающийся пользователь должен получить отказ. И не забудьте проверить суперпользователя, как истинного, так и лишь выдающего себя за такового.

Записи РАМ в файлах журналов


Результаты авторизации служб с ограничением доступа протоколируются демоном syslogd, который помещает все сообщения от РАМ в файл /var/log/secure (листинг 1.9).

Листинг 1.9. Содержимое /var/log/secure

Jan 11 16:45:14 chiriqui PAM_pwdb[30022]: (su) session opened for user root

by david(uid=0)

Jan 11 16:45:25 chiriqui PAM_pwdb[30022]: (su) session closed for user root

Jan 11 17:18:06 chiriqui login[13217]: FAILED LOGIN 1 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:13 chiriqui login[13217]: FAILED LOGIN 2 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:17 chiriqui PAM_pwdb[13217]: (login) session opened for user david

by (uid=0)

Jan 11 17:18:06 chiriqui login[13217]: FAILED LOGIN 1 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:13 chiriqui login[13217]: FAILED LOGIN 2 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:17 chiriqui PAM_pwdb[13217]: (login) session opened for user david

by (uid=0)

Jan 11 17:18:17 chiriqui -- david[13217]: LOGIN ON ttyl BY david

Jan 11 17:18:20 chiriqui PAM_pwdb[13217]: (login) session closed for user david

Каждая запись начинается с даты, времени и имени узла. После чего следует имя модуля РАМ и идентификатор процесса, заключенный в квадратные скобки. Затем, в круглых скобках, идет имя службы с ограничением доступа. Для листинга 1.9 это либо su, либо login. После имени службы следует либо «session opened» (сеанс открыт), либо «session closed» (сеанс закрыт).

Запись, следующая непосредственно за записью с «session opened», является сообщением о входе в систему, из которого можно узнать, кто и откуда вошел в систему. Если после нескольких попыток вы так и смогли войти в систему, имеет смысл обратиться к файлу /var/log/secure и посмотреть, отчего и на каком этапе вход в систему заканчивается неудачей.