Логирование действий пользователя

0

0

Есть ли какой-нибудь продукт (желательно бесплатный), который скидывал бы в лог все команды, запускаемые пользователем из shell'а. А в идеале - ещё и все кнопки, которые он нажимал во время сеанса доступа через ssh.

Ситуация: есть хостинг, на котором пользователю даётся shell через ssh. Проблема в том, что некоторые (особо умные :) ) пользователи научились запускать csh, который не ведёт логов, либо запускают vi и уже из него выполняют все нужные им команды. В результате нельзя проконтролировать, что пользователь делал.

Ссылка

←	детектор скана портов

Защита в Linux Mandrake 9.0 Final

→

нафик?

geek ★★★
(21.08.04 05:27:21 MSD)

Ссылка

в ядре есть стандартная опция process acounting

anonymous
(21.08.04 08:29:07 MSD)

Ссылка

есть http://linuxbsm.sourceforge.net. не знаю, насколько оно живое, и вообще рабочее. знаю, что это калька с солярисного BSM, который весьма неплох.

наверняка, есть еще варианты. GrSecurity какой-нибудь , возможно, это умеет.

Кстати, а зачем? Ну делает пользователь что-то, что страшного?

ivlad ★★★★★
(22.08.04 20:04:50 MSD)

Ответ на: комментарий от ivlad 22.08.04 20:04:50 MSD

> Кстати, а зачем? Ну делает пользователь что-то, что страшного?

Страшно то, что пользователь запускает, например, экплоит. Хорошо ещё, если не на соседний хост. Или пытается дырки в системе поискать.

anonymous
(23.08.04 00:19:53 MSD)

Ссылка

Спасибо за советы.

Я решил не добавлять модули ядра, т.к. сервер боевой и вносить элемент нестабильности в него не хочется.

Пока поставил пользователям в качестве shell'а screen и прописал screen'у сбрасывать в лог всё, что выводится на экран. Потом можно просто делать cat <screenlog и смотреть на пользовательскую сессию в real-time'е. Нужно только замедлитель между cat и файлом вставлять.

Такой вариант пока устраивает, но хотелось бы большего. :)

anonymous
(24.08.04 16:25:03 MSD)

Ответ на: комментарий от anonymous 24.08.04 16:25:03 MSD

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

ivlad ★★★★★
(24.08.04 16:59:52 MSD)

Ответ на: комментарий от ivlad 24.08.04 16:59:52 MSD

> ядро патчить - единственный надежный способ. остальные практически всегда можно обойти.

Бесспорно.

Но приходится искать компромис между хотелками (логирование) и потребностями (надёжность).

anonymous
(24.08.04 19:30:37 MSD)

Ответ на: комментарий от anonymous 24.08.04 19:30:37 MSD

> потребностями (надёжность).

а чем модули ядра ненадежны??? точно такой же код на C, как и само ядро...

ivlad ★★★★★
(25.08.04 09:05:44 MSD)

Ответ на: комментарий от ivlad 25.08.04 09:05:44 MSD

> а чем модули ядра ненадежны??? точно такой же код на C, как и само ядро...

Если ошибка будет в коде обычной программы, то всё закончится в худшем случае падением этой программы.

Если ошибка будет в модуле ядра, то всё может закончится kernel panic (в лучшем случае), либо полным умиранием сервера (если модуль запорет какую-нибудь информацию в драйвере файловой системы).

Добавляя новый модуль в ядро мы увеличиваем кол-во потенциальных мест, где может возникнуть ошибка. Поэтому я и не хочу добавлять ещё один модуль ядра. :)

Я охотно верю, что ошибок в данном конкретном модуле может и не быть, но проверять это на production сервере нет никакого желания.

anonymous
(25.08.04 15:14:02 MSD)

Ссылка

Ответ на: комментарий от ivlad 25.08.04 09:05:44 MSD

Да что вы говорите?

А как же это:

http://downloads.securityfocus.com/vulnerabilities/exploits/ptrace-kmod.c

anonymous
(25.08.04 20:47:31 MSD)

Ответ на: комментарий от anonymous 25.08.04 20:47:31 MSD

> Да что вы говорите?

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

ivlad ★★★★★
(26.08.04 11:48:26 MSD)