Бывают ситуации, когда нужно дать доступ к серверу сотруднику, и нужно это всё контролировать. Иными словами знать, что делал, какие команды он вводил, какой результат получал и т.д. Можно всё время стоять у него за плечами, а можно настроить аудит. В ОС FreeBSD для этих целей придумали аудит событий. Это можно делать 2-мя способами: штатным и с помощью дополнительных приложений. Штатный способ достаточно хорошо описан в “хэндбуке” (http://www.freebsd.org/doc/ru/books/handbook/audit.html), поэтому в этой статье опишу альтернативный способ на примере приложения sudosh.
Что же представляет собой sudosh? Это псевдооболочка, которая позволяет протоколировать не только то, что вводиться и результат, который выводится на терминал, время потраченное на эти действия, а и потом воспроизвести эти действия при необходимости! При этом имеет небольшой размер (всего 27 кБ), минимум настроек, что делает её чуть ли не заменимой в аудите.
Переходим от теории к практике, а точнее к установке и настройке. Ставить будем из портов. Замечу сразу, что в портах присутствует сразу 3 ветки sudosh. Советую ставить третью, поэтому переходим в указанный порт и ставим:
#cd /usr/port/security/sudosh3 && make install clean
После установки появится конфигурационный файл /usr/local/etc/sudosh.conf. Он состоит из пар параметр=значение. Вот некоторые из них:
#папка, куда будут складываться логи
logdir = /var/log/sudosh
#оболочка по умолчанию
default shell = /usr/local/bin/bash
#разделитель
delimiter = -
#уровень и метка логгирования
syslog.priority = LOG_INFO
syslog.facility = LOG_LOCAL2
#очищать среду при входе
clearenvironment = yes
Остальные параметры можно узнать из страниц справочника man к данной утилите.
Файл конфигурации готов. Создаём папку /var/log/sudosh и ставим ей права 0777, ибо в папке будут создаваться файлы, владельцами которых являются пользователи, которых мы собираемся контролировать. В противном случае при логине пользователя сеанс сразу же будет закрываться.
И так, создаём тестового пользователя (или меняем оболочку у существующего) и ставим ему в качестве шелла /usr/local/bin/sudosh:
#pw useradd -n test -s /usr/local/bin/sudosh
Так же не забываем добавить sudosh в файл с оболочками /etc/shells:
#echo '/usr/local/bin/sudosh' >> /etc/shells
После этого проверяем работу нашего “логгера”. В папке /var/log/sudosh будут созданы 3 файла:
-rw------- 1 test wheel 42B 3 фев 20:39 test-test-input-1265219751-u41wqlifaXPMJEB8
-rw------- 1 test wheel 80K 3 фев 20:39 test-test-script-1265219751-u41wqlifaXPMJEB8
-rw------- 1 test wheel 2,0K 3 фев 20:39 test-test-time-1265219751-u41wqlifaXPMJEB8
Имена файлов составляются по принципу {ИМЯ_ПОЛЬЗОВАТЕЛЯ1}-{ИМЯ_ПОЛЬЗОВАТЕЛЯ2}-{ТИП_ЛОГГИРОВАНИЯ}-{ВРЕМЯ_В_unixtimestamp}-{СЛУЧАЙНЫЙ_ИДЕНТИФИКАТОР}
где
– ИМЯ_ПОЛЬЗОВАТЕЛЯ1 – пользователь, от которого выполнен вход на терминал
– ИМЯ_ПОЛЬЗОВАТЕЛЯ2 – пользователь, от которого выполняются собственно команды
– ТИП_ЛОГГИРОВАНИЯ – input (какие команды вводит пользователь), script (полная копия того, что твориться на консоле), time (временные штампы)
Чаще всего что, ИМЯ_ПОЛЬЗОВАТЕЛЯ1=ИМЯ_ПОЛЬЗОВАТЕЛЯ2, в том случае, если вход выполнен от того же пользователя, от которого выполняются команды. Но если вы вошли под пользователем user, а потом по su перешли на test, то файлы примут такой вид:
-rw------- 1 test wheel 42B 3 фев 20:39 user-test-input-1265219751-4EB60vspkheWTOLI
-rw------- 1 test wheel 80K 3 фев 20:39 user-test-script-1265219751-4EB60vspkheWTOLI
-rw------- 1 test wheel 2,1K 3 фев 20:39 user-test-time-1265219751-4EB60vspkheWTOLI
PS.
Неужели всё так хорошо и нет подводных камней? На самом деле, есть одна ложка дёгтя и имя этой ложке – mc. При запуске mc в логе пишется мусор, ибо mc по сути это псевдографика и в логе она превращается в сплошной мусор. Та же участь подстерегает и остальные логгеры консоли (На штатном audit такая же проблема). Поэтому не пугайтесь, если вдруг увидите мусор в логах.
Опубликовано с разрешения редакции журнала RootUA и газеты FOSS News
