[P&AM Lab] some admin tasks

[Grigoriy A. Sitkarev]

Всем доброго здоровья!

Я завтра утром улечу в Москву и вернусь только к концу недели. К субботе 
я буду в Лаборатории по расписанию.

ruyk wrote:
> 1) На одном из серверов необходимо настроить логгирование действий
> пользователей (к примеру когда какие команды в консольке набивались),
> подключившихся из внешней сети.
> Демон наверное auditd не вполне подходит т.к. он работает на слишком
> низком уровне. Подозреваю что замучаюсь потом логи анализировать.
> 
> Нашёл ещё snoopy(https://github.com/a2o/snoopy). Разделяемая
> библиотека, которая вешает хуки на execve вызовы. Тоже не подходит так
> как в логи попадает много левой информации, т.к. например при
> инициализации bash из .bashrc и profile запускается куча левого хлама.
> 
> Решил остановиться на rootsh (http://sourceforge.net/projects/rootsh/)
> Могу врать но на сколько я понял он создаёт пару псевдотерминалов между
> пользователем и запускаемой программой, и поэтому всё что попадаёт на
> экран может быть словленно им и записано в лог.
> Как решил задачу:
> С помощью директивы openssh сервера ForceCommand будет запускаться
> скрипт который будет анализировать переменную SSH_CLIENT и в
> соответствии с ней запускать rootsh или обычный bash.
> 
> Вроде всё хорошо но не отпускает мысль что я нашёл не оптимальное
> решение, есть какие-то штатные средства которые позволят добиться того
> же?

Культура и опыт Unix учит нас, что одного единственно верного решения не 
существует.

Мне кажется, что вы не понимаете основной принцип этой ОС. Здесь вы сами 
можете конструировать нужные вам инструменты. Если есть какой-то текст, 
то с помощью комбинации программ, объединённых конвеером, мы можем 
получить совершенно новый инструмент. Порядок и способ использования 
этих программ может быть совершенно неочевидным, и здесь Unix таит много 
непознанных возможностей и простора для творчества.

Можно сказать, что если вам удалось текстуализировать временную метку, 
PID, UID, GID и вызовы exec с аргументами, то остаётся лишь пропустить 
этот текстовый поток через фильтр. Из полученного «дистиллята» 
формируются отчёты и представляются в нужной форме, вплоть до печатных 
форм в PostScript, сгенерированных в troff.

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

> 2) Совсем коротенько опишу:)
> Надо обеспечить передачу логов по шифрованному каналу с одного сервера
> на другой.
> Так как канал должен быть шифрованным, на сколько я понимаю, syslog и
> rsyslog сразу отваливаются.
> Из более менее подходящих программ нашёл только nxlog (
> http://nxlog-ce.sourceforge.net/)
> 
> Есть ли известные вам удобные инструменты для централизованного анализа
> логов (не грепить жеж)?
> Может кто-то сталкивался с подобной проблемой, насоветуйте пожалуйста
> ещё инструментов её решения.

Опять вернёмся к теме взаимодействия программ. Любой сетевой трафик 
можно пропустить через туннель ssh. Любую удалённую команду можно 
запустить точно так же через ssh. Многие утилиты могут использовать 
stdin/stdout других программ для ввода-вывода, например, rsync. (Для 
этого у rsync есть опция -e, она же --rsh.) Кроме того, тот же rsync 
имеет такие опции как --append и --append-verify.

Если говорить про Rsyslog, то он сам имел поддержку TLS. Защищённый 
обмен можно было организовать его встроенными средствами, через PKI.

По поводу анализа логов -- всё сказаное выше справедливо и по отношению 
к этой задаче. Если очень хочется интегрированное решение, то можно 
попробовать OSSEC [1].

> P.S.: Начало появляться это неловкое чувство когда понимаешь что только
> ты задаёшь в рассылке вопросы :-[

Дело в том, что все стали писать лично мне. Плохого в этом ничего нет, 
безусловно, я сам люблю получать письма и отвечать. Но как-то не очень 
пока получается вовлечь коллектив в совместную разработку. И вам всем 
стоит об этом задуматься.

[1] http://www.ossec.net

--
Г.А.