Сергей Яремчук

В статье «Контрольная сумма на защите Linux/FreeBSD» июньского номера журнала «Системный администратор» была рассмотрена настройка утилиты Tripwire, позволяющей системному администратору контролировать целостность важных системных файлов и быть предупрежденным о взломе. Но хотелось бы не доводить до всего этого и иметь возможность защититься и предотвратить взлом. Существует множество утилит, позволяющих определить признаки подготовки и начала атаки (сканирование портов, множество неудачных удаленных подключений к серверу), в этой статье познакомимся с тремя из них.

Набор программ TriSentry от компании Psionic Technologies Inc. (http://www.psionic.com) разработаны, чтобы увеличить защиту компьютерных сетей и уменьшить вероятность проникновения, эти приложения относятся к IDS (Intrusion Detection System – система обнаружения вторжений). Состоит TriSentry из трех ключевых компонентов: PortSentry, HostSentry и LogSentry, распространяемых как freeware и предназначенных для использования на UNIX-подобных операционных системах как вместе, так и раздельно, в зависимости от задач и необходимости.

PortSentry

PortSentry – программа, предназначенная для обнаружения сканирования портов, которое, как правило, всегда предшествует атаке. Она не только позволяет регистрировать это в системных журналах при помощи syslog, но и позволяет запустить в ответ любую программу (блокировки хоста firewall или переадресации на несуществующий dead host, traseroute, свой скрипт), которой могут быть переданы IP-адрес атакующего и номер атакуемого порта, или просто прописать адрес компьютера в файле /etc/hosts.deny. PortSentry обнаруживает практически все известные виды сканирования: Strobe-style, SYN/half-open, Null, XMAS, FIN, TCP connect и другие. В файле README.stealth архива вы найдете описание обнаруживаемых методов Stealth-сканирования. В настоящее время имеется уже версия 2.0 программы, отличающаяся от первой поддержкой libpcap, т.е. методами обнаружения сканирования. После закачки пакета распакуйте (tar xfz portsentry-2.0b.tar.gz) его и откройте в любимом редакторе файл portsentry_config.h, в котором содержатся некоторые опции конфигурирования, для большинства случаев подойдут используемые по умолчанию:

n  CONFIG_FILE “/usr/local/psionic/portsentry2/portsentry.conf” – содержится путь к конфигурационному файлу, если значение по умолчанию не подходит, изменив его, не забудьте подправить его и в Makefile в опциях INSTALLDIR (/usr/local/psionic) и CHILDDIR (/portsenry2);

n  WRAPPER_HOSTS_DENY “/etc/hosts.deny” – путь к файлу hosts.deny для работы tcpwrapper;

n  SYSLOG_FACILITY LOG_DAEMON – тип логов для syslogd (подробности в man 3 syslog);

n  SYSLOG_LEVEL LOG_NOTICE – уровень syslogd для посылки сообщений;

n  MAXSTATE 50 – максимальное количество запоминаемых хостов для проверки повторного подключения.

Знак решетки (#) в этом файле в начале строк с переменными – это не признак комментария, они требуются компилятором С при обработке файлов заголовков, поэтому удалять их не надо. После набираем:

# make linux (openbsd, freebsd, netbsd)

чтобы откомпилировать программу и затем под логином root:

# make install

Теперь в /usr/local должен появиться каталог psionic с подкаталогом portsentry2, в котором будут находиться три файла: portsentry – исполняемый файл программы, portsentry.conf и portsentry.ignore. В portsentry.ignore содержатся IP-адреса узлов, которые не дожны блокироваться.

По умолчанию там содержится два адреса 127.0.0.1 и 0.0.0.0, остальные при необходимости заносятся в формате <IP Address>/<Netmask>. Например:

192.168.2.0/24

192.168.0.0/16

192.168.2.1/32

По умолчанию используется 32-битная маска. Теперь самое время заглянуть в главный конфигурационный файл portsentry.conf. Опции в этом файле для удобства условно сгруппированы по секциям и имеют вид ОПЦИЯ=«значение».

Значения опций файла portsentry.conf

Interface Configurations

n  INTERFACE=«auto» – названия подконтрольного интерфейса, при наличии одного возможен вариант «auto», и он будет найден автоматически; если же их несколько, то необходимо указать на выбранный для контроля, например INTERFACE=«eth0», Portsentry может контролировать только один интерфейс.

n  INTERFACE_ADDRESS=«XXX.XXX.XXX.XXX» – IP-адрес интерфейса, без него Portsentry не сможет работать должным образом, в данное время не поддерживается динамическое определение адреса, в этом случае придется писать скрипт (но в ближайшее время, по заверениям разработчиков, такая опция будет реализована).

Port Configurations

n  TCP_PORTS – перечисляются через запятую все проверяемые Portsentry TCP-порты (диапазоны не поддерживаются), список желательно не делать слишком большим, чтобы уменьшить количество срабатываний, но он должен охватывать весь диапазон и содержать порт номер 1, так как в большинстве сканеров сканирование начинается именно с него, также не надо включать сюда порты, открытые работающими приложениями (20 – ftp, 25 – sendmail, 80 – httpd и пр.). При попытке подключения к указанному порту информация об этом заносится в логи, затем выполняется пользовательская команда и после узел блокируется при помощи ipchains.

n  UDP_PORTS – то же самое, только касается UDP-портов.

Configuration Files

n  IGNORE_FILE – полный путь к файлу portsentry.ignore.

n  HISTORY_FILE – путь к файлу с историей, в котором содержатся записи о времени блокирования, имени и IP-адреса хоста, атакованный порт и протокол (TCP или UDP).

n  BLOCKED_FILE – шаблон, из которого формируется файл блокировки, имеющий имя BLOCKED_FILE.про-токол.

Misc. Configuration Options

RESOLVE_HOST – при установлении в 1 производится запрос сервера DNS имени хоста нападавшего. На медленных компьютерах это может увеличить время реакции и может предупредить нападающего о наличии Portsentry, если он контролирует сервер имен. Значение по умолчанию – 0.

Ignore Options

n  BLOCK_UDP – позволяет задать ответную реакцию на сканирование в зависимости от установленного значения. При значении 0 ничего не происходит, узел не блокируется, команда не запускается; 1 означает блокировать узел и запустить на выполнение команду; 2 – только запустить заданную команду. Команда задается при помощи опции KILL_RUN_CMD.

n  BLOCK_TCP – то же самое, только для TCP-протокола.

Dropping Routes

В этой секции описывается команда, которая будет выполнена при обнаружении сканирования, при этом переменная $TARGET$ заменяется IP-адресом, а в переменную $PORT$ будет подставлен номер порта, к которому было подключение. В файле содержатся шаблоны команд (удаление маршрута, установка firewall) для различных операционных систем, необходимую нужно раскомментировать или дописать свою, используя параметр KILL_ROUTE.

# FreeBSD

#KILL_ROUTE="route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole"

# iptables support for Linux

#KILL_ROUTE="/usr/local/bin/iptables -I INPUT -s $TARGET$ -j DROP"

TCP Wrappers

KILL_HOSTS_DENY – опция задает строку, которая будет помещена в /etc/hosts.deny для блокировки доступа (ALL: $TARGET$).

External Command

n  KILL_RUN_CMD – команда, которая будет выполнена в сторону нападающего. Можно запустить отправку почты администратору или на любителя порцию фрагментированных пакетов.

n  KILL_RUN_CMD_FIRST – установка значения в 0 запустит команду, перед тем как маршрут будет удален из таблицы; в 1 – после.

Scan trigger value

SCAN_TRIGGER – определяет разрешенное количество подключений, прежде чем Portsentry начнет действовать. Значение по умолчанию 0 означает немедленную реакцию. Установка в 1 или 2 уменьшит количество ложных срабатываний. Но можно оставить как есть.

Это все опции применительно к версиям 1.1 и 2.0, но в версии 1.1, которая до сих пор пользуется популярностью, имеется еще одна опция – PORT_BANNER, которая задает сообщение, выводимое при подключении к проверяемому порту.

PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS BEEN LOGGED. GO AWAY."

Сами авторы программы не рекомендуют пользоваться ею, чтобы не злить взломщика, очевидно поэтому она и была убрана со второй версии программы. Хотя можно попытаться при помощи этой опции сбить начинающего взломщика с толку, указав, например, неправильные данные о системе.

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

# /usr/local/psionic/portcentry2/portcentry

После этого в файле /var/log/message должно появиться примерно такое сообщение, в котором описываются контролируемый интерфейс и порты:

Jun  4 09:00:32 grinder portsentry[1881]: adminalert: Monitoring interface eth0 and address: 192.168.0.4

Jun  4 09:00:32 grinder portsentry[1881]: adminalert: Initializing PortSentry BPF filters.

Jun  4 09:00:32 grinder portsentry[1881]: adminalert: Monitoring TCP ports: 1,11,15,79,111,119,143,515,540,635,666,1080,1524,2000,6667,

12345,12346,20034,27374,27665,31337,32771,32772,32773,32774,40421,49724,54320,54321

Jun  4 09:00:32 grinder portsentry[1881]: adminalert: Monitoring UDP ports: 1,7,9,69,161,162,513,635,2049,27444,32770,32771,32772,32773,

32774,31337,54321

Jun  4 09:00:32 grinder portsentry[1881]: adminalert: PortSentry is initialized and monitoring.

 

Последняя строка указывает на счастливый запуск утилиты, если ее нет, то что-то сделано неправильно. При этом могут быть следующие специфические сообщения:

n  adminalert – это сообщение выводит текущий статус PortSentry.

n  securityalert – сообщение о том, что некое защитное событие произошло.

n  attackalert – компьютер был атакован и соответствующие данные занесены в /etc/host.deny.

 

В первой же версии программы использовалось шесть режимов по три на каждый протокол (TCP и UDP):

n  portsentry -tcp (basic port-bound TCP mode)

n  portsentry -udp (basic port-bound UDP mode)

n  portsentry -stcp (Stealth TCP scan detection)

n  portsentry -atcp (Advanced TCP stealth scan detection)

n  portsentry -sudp («Stealth» UDP scan detection)

n  portsentry -audp (Advanced «Stealth» UDP scan detection)

Для каждого протокола может запускаться только один выбранный режим. В режиме basic открываются описанные в файле portsentry.conf контролируемые порты и при попытке соединиться с ними происходит блокировка, при этом PortSentry не реагирует на Stealth-сканирование. Режим Stealth отличается от предыдущего тем, что не держит порты открытыми, и атакующий получает достоверную информацию об используемых портах, а также выявляет практически все виды Stealth-сканирования. Режим Advanced является самым быстрым и рекомендуется разработчиками (во второй версии используется именно этот режим совместно со Stealth). При этом контролируются все порты ниже значений ADVANCED_PORTS_TCP и ADVANCED_EXCLUDE_UDP.

LogSentry

В системных журналах имеется довольно ценная информация, так как любое событие оставляет там свой след, но большинство системных администраторов заглядывают туда один-два раза в неделю, иногда даже вручную, что, согласитесь, очень утомительно. Утилита Logsentry (или logcheck) как раз и предназначена для автоматической проверки системных журналов на предмет нарушений безопасности и других необычных действий, таким образом немного облегчая труд. Берет свою родословную от скрипта frequentcheck.sh, входящего в состав firewall Gauntlet компании Trusted Information Systems Inc. (http://www.tis.com). Сценарий logcheck запускается при помощи демона cron, при этом программа при помощи утилиты grep проверит системные журналы на предмет наличия определенных ключевых слов, и в случае наличия их в файле сисадмин получит извещение по почте. Чтобы не проверять каждый раз все файлы полностью, для запоминания последней прочитанной в журнале позиции Logcheck использует программу, называемую logtail, которая запоминает ее и использует эту позицию на последующем шаге, чтобы обработать новую порцию информации. При этом в каталоге с лог-файлами появятся еще несколько файлов хххххх.offset, где хххххх – название лог-файла; если удалить его, утилита начнет проверять лог-файл опять сначала. Также утилита контролирует номер inode и размер лог-файла; при уменьшении размера или изменении номера inode счетчик сбрасывается и файл проверяется сначала. Поэтому можно не беспокоиться при удалении лог-файлов (точнее, переносе на резервный носитель), когда они разрастутся. Инсталляция программы очень проста, распаковываем архив.

# tar xfzv logsentry-1.1.1.tar.gz

И заходим в каталог (да, название немножко изменилось).

# cd logcheck-1.1.1

И теперь вводим команду mаке с указанием используемой операционной системы, например для Linux.

# make linux

После этого скомпилированная программа logtail вместе со вспомогательными файлами скопируется в каталоги, указанные в переменных INSTALLDIR_BIN, INSTALLDIR и INSTALLDIR_SH. По умолчанию это подкаталоги /usr/local/bin, /usr/local/etc и /usr/local/etc. Кроме основного скрипта logcheck.sh и программы logtail, в комплекте идут несколько вспомогательных файлов. Файл logcheck.hacking содержит ключевые слова (вроде LOGIN root REFUSED или attackalert от Portcentry), появление которых в лог-файлах может свидетельствовать только об одном – компьютер атакован, т.е. если такое слово будет обнаружено, то суперпользователь получит сообщение, которое просто не сможет не привлечь его внимания: «ACTIVE SYSTEM ATTACK». А файл logcheck.violations содержит набор слов, свидетельствующих, как правило, о каком-либо негативном действии (например, failed, denied и даже su root). Например, сравните следующие два сообщения:

Jun  4 09:00:32 grinder sendmail[5475]: VAA05473: to=crowland, ctladdr=root (0/0), delay=00:00:02, xdelay=00:00:01, mailer=local,

stat=refused

Jun  4 09:00:32 grinder rshd: refused connect from hacker@evil.com:1490

Первая строка указывает на довольно обычную житейскую ситуацию с sendmail, отдаленный компьютер отказался от подключений, т.е. слово refused к нашему случаю не имеет абсолютно никакого отношения. А вот в следующей некто с hacker@evil.com пробовал запускать rsh-сеанс на компьютере, это как раз наш случай (rshd приведен только для примера, использование его на компьютере, по-моему, плохая идея) и опять присутствует слово refused. Для того чтобы события, подобные первому, не отвлекали в файл logcheck.violations.ignore, добавляем строку, наличие которой заставит logsentry проигнорировать событие. В нашем случае это будет:

mailer=local, stat=refused

Но с занесением данных в этот файл надо быть осторожным, чтобы не пропустить важное. По умолчанию в нем содержится только одна строка stat=Deferred, позволяющая игнорировать сообщения grep. Чтобы иметь возможность искать некоторые слова и не сообщать об их наличии, предназначен файл logcheck.ignore. Поиски по ключевым словам в файлах logcheck.hacking и logcheck.violations, чтобы гарантировать, что ничего не пропущено, нечувствительны к регистру. А в файлах logcheck.violations.ignore и logcheck.ig-nore, наоборот, чувствительны к регистру, чтобы гарантировать 100% попадание и не пропустить что-нибудь интересное. Все *.ignore-файлы требуют точного текста.

Теперь необходимо сделать так, чтобы все сообщения системы записывались в один файл /var/log/messages. Для этого открываем в любимом редакторе /etc/syslog.conf. Он имеет приблизительно такую структуру: в левой части через точку с запятой перечисляются системные события, а в правой – файл или устройство (что для UNIX одно и то же), в которое сообщение, соответствующее данному событию, будет выводиться. Т.е. необходимо просто собрать все записи, которых нет в левой части, соответствующей /var/log/messages со всех таких событийных частей и дописать их (это в самом простом случае, либо почитайте man syslog.conf). Например, в RedHat 9 у меня такая строка:

*.info;mail.none;authpriv.none;cron.none;uucp,news.crit /var/log/messages

После этого на всякий случай устанавливаем новые права доступа к файлу /var/log/messages:

# chown root.wheel /var/log/messages

# chmod 600 /var/log/messages

Аналогично устанавливаем права для logcheck.sh и logtail:

# chown root.wheel /usr/local/etc/logcheck.sh

# chmod 600 /usr/local/etc/logcheck.sh

# chown root.wheel /usr/local/bin/logtail

# chmod 700 /usr/local/bin/logtail

После всего загляните в скрипт logcheck.sh и измените значения переменных SYSADMIN (пользователя, которому будет высылаться e-mail), а также MAIL и LOGTAIL в соответствии с вашей системой (в последнем случае достаточно закомментировать одни и раскомментировать другие строки).

Для начала, чтобы убедиться, что все работает нормально, запускаем скрипт logcheck.sh вручную, причем желательно несколько раз, чтобы удостовериться в том, что вы не получаете одни и те же сообщения. Если это так, то что-то не в порядке с logtail, попробуйте запустить ее вручную и посмотрите наличие файлa *.offset. Проблемы здесь могут быть две: или программа запукается не от имени root, или придется перекомпилировать.

И теперь, когда все в порядке, заносим в файл /etc/crontab приблизительно такие строки (для каждой системы свои), при этом демон cron должен быть, естественно, запущен.

00 * * * * root /bin/sh /usr/local/etc/logcheck.sh

 

И теперь каждый час запускается logcheck.sh, которая запускает в свою очередь logtail:

n  logtail анализирует log-файлы с последней запомненной позиции;

n  logcheck при помощи grep проверяет оставшийся текст на наличие сообщений о возможной атаке;

n  при помощи grep проверяются все возможные негативные сообщения;

n  на следующем шаге отбираются из них те, которые нужно проигнорировать (logcheck.violations.ignore);

n  все сообщения, которые нужно проигнорировать, заносятся в logcheck.ignore;

n  после всего этого сисадмин получает e-mail с оставшимися сообщениями.

Еще одна проблема может возникнуть с использованием утилиты logsentry. Связана она с локализацией. Дело в том, что в большинстве дистрибутивов local устанавливается автоматически по используемому основному языку системы. Естественно, после того как переменная LANG будет равняться KOI8-R, все сообщения будут выводиться на русском языке (и запись в лог-файлы также), дополнительно в последнее время обострилась ситуация с продвижением единой кодировки Unicode, т.е. в RedHat 8.0 и 9 LANG=«ru_RU.UTF-8». Logcenry в этом случае ничегошеньки (или почти) не найдет. И все потому, что все шаблоны записаны на английском. Поэтому лучше всего использовать Pan-European version, т.е. когда сообщения выводятся на английском (в AltLinux сейчас примерно так все и работает). Для этого в файле /etc/sysconfig/i18n меняем соответствующие строки на:

LANG="en_US"

SYSFONT="Cyr_a8x16"

SYSFONTACM="koi2alt"

Остальные можно оставить как есть. После этого проблем уже быть не должно.

HostSentry

И последняя, самая молодая, утилита HostSentry. Представляет собой инструмент обнаружения вторжения, основанный на технологии Login Anomaly Detection (LAD), который определяет подозрительные действия при входе в систему и позволяет быстро выявлять скомпрометированные пользовательские аккаунты и необычное поведение. HostSentry включает динамическую базу данных и фактически изучает поведение входа в систему пользователя. Это поведение используется модульными сигнатурами, чтобы обнаружить необычные действия. Прошу обратить внимание на словосочетание «при входе в систему», если компьютер уже скомпрометирован, и взломщик уже имеет легальный вход в систему, здесь уже помочь будет трудно, а вот когда делаются первые шаги, применение HostSentry будет как раз к месту. При этом необходимо помнить, что обнаружив ее, злоумышленник также может подменить утилиту.

При этом HostSentry определяет:

n  необычные действия при входе в систему;

n  подозрительные домены, с которых осуществляется вход;

n  подозрительные каталоги пользователей;

n  обнаруживает вмешательство в файлы истории команд и входа в систему;

n  неизвестные входы в систему;

n  имеет расширяемые модули сигнатур.

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

Программа полностью написана на объектно-ориентированном интерпретируемом языке Python, в большинстве современных дистрибутивов он уже имеется, если же нет, то первоначально необходимо его установить, взяв с домашней страницы http://www.python.org. После этого установка HostSentry проблем вызвать не должна, просто распаковываем архив, заходим в образовавшийся каталог и вводим make install, после чего все необходимые файлы будут просто перенесены в каталог /usr/local/abacus/hostsentry (на него указывает переменная INSTALLDIR в Makefile).

В файле hostsentry.conf устанавливаются пути к модулям, используемым утилитой, базам данных, необходимым для сбора информации, переменная WTMP_FILE должна указывать на wtmp-файл (для Linux обычно /var/log/wtmp) и некоторым другим файлам, о них ниже. Единственная переменная, на которую можно обратить внимание поначалу (остальные можно не трогать, а оставить как есть, хотя базы данных я бы переместил в каталог /var, где и положено им быть) – это WTMP_FORMAT, в которой устанавливается формат сохранения информации о логинах. Вся проблема здесь в том, что учет параметров входа в систему (Name, TTY, Time, Host) в различных реализациях UNIX ведется по-разному, например, имя хоста в BSD урезается до 16-32 байт, в RFC 1034 имя ограничено 256 символами, а в переменной MAXDNAME (arpa/nameser.h) имя узла ограничено 1024 символами. Это приводит к тому, что если нападавшим использовано длинное имя, то оно наверняка урежется (подробности в README.wtmp). Так вот в WTMP_FORMAT и устанавливается формат, чтобы обеспечить запись необходимых данных применительно к используемой системе (в простейшем случае необходимо будет раскомментировать соответствующую строчку, в будущем планируется максимально автоматизировать процесс).

В файле hostsentry.modules описывается, какие модули должны выполняться при регистрации пользователя в системе и при logout. В большинстве случаев можно оставить как есть. При необходимости сменить очередность выполнения модулей, их нужно просто переместить вверх/вниз. В файл hostsentry.ignore заносятся пользователи, которых не нужно отслеживать при помощи HostSentry, это может быть полезно, например, для пользователей типа «ftp», который обнаруживается в wtmp и вызывает большое количество ложных тревог из-за анонимного доступа (при этом все равно в базу данных пользователь будет включен). Для этого нужно просто разместить исключаемых пользователей по одному в строке (и надо заглядывать в него периодически, чтобы там не оказался root). Файл hostsentry.action описывает действия, которые должна предпринимать утилита, пока она только регистрирует залогинившихся пользователей. Теперь можно и запускать (для автоматического старта вместе с системой нужно включить эту строку в файл rc.local).

# python hostsentry.py

При этом в файле /var/log/messages должны появиться такие строки.

Jun  8 18:26:42 grinder hostSentry[23306]: adminalert: HostSentry version 0.02 is initializing.

Jun  8 18:26:42 grinder hostSentry[23306]: adminalert: Send bug reports to <crowland@psionic.com>

Jun  8 18:26:43 grinder hostSentry[23460]: adminalert: HostSentry is active and monitoring logins.

 

После первого запуска образуются две базы данных: hostsentry.db, содержащая записи обо всех пользователях, которые регистрировались с тех пор, пока HostSentry был в действии, и hostsentry.tty.db об используемых (активных) терминалах. В пользовательской базе данных хранятся объекты входа в систему пользователя, которые сформированы со следующей схемой:

n  username – имя входящего в систему пользователя;

n  recordCreated – дата начала записи в UNIX-формате;

n  firstLogin – первый вход в систему для этого пользователя;

n  trackLogins – список входов в систему этого пользователя (будет постоянно расти);

n  validLoginDays – дни, когда данному пользователю разрешено регистрироваться в системе;

n  validLoginHours – часы, когда пользователю разрешено регистрироваться;

n  adminDisabled – флаг, указывающий на то, что данная запись была отключена администратором;

n  securityDisabled – флаг, указывающий на то, что данный пользователь был лишен возможности регистрироваться модулем программы;

n  totalLogins – общее количество регистраций для данного пользователя;

n  version – версия схемы базы данных.

 

База данных терминалов помогает HostSentry поддержать список активных подключений и позволяет программе знать, когда пользователь регистрировался. Поскольку эти данные не используются между включениями, она обнуляется каждый раз при перезапуске HostSentry. При этом отслеживаются следующие элементы:

n  tty – TTY, с которого зарегистрировался пользователь;

n  username – имя пользователя;

n  loginStamp – уникальный timestamp для login;

n  version – версия схемы базы данных.

В loginStamp заносится информация, необходимая для обработки компонентами системы и формируется следующим образом:

loginIP@loginHostname@loginTTY@loginTime@logoutTime

 

Где:

n  LoginIP – IP-адрес пользователя при регистрации;

n  LoginHostname – имя хоста (полностью уточненное при помощи DNS);

n  LoginTTY – TTY пользователя;

n  LoginTime – время входа в систему в UNIX-формате;

n  LogoutTime – время выхода из системы в UNIX-формате.

Если попробовать теперь зарегистрироваться, то дополнительно появится сообщение, в котором указывается кто, когда, откуда и какие модули были выполнены.

Jun  8 18:30:19 grinder  -- sergej[1639]: LOGIN ON tty1 BY sergej

Jun  8 18:30:20 grinder hostSentry[23460]: securityalert: LOGIN User: sergej TTY: tty1 Host:

Jun  8 18:30:20 grinder hostSentry[23460]: securityalert: First time login for user: sergej

Jun  8 18:30:20 grinder hostSentry[23460]: securityalert: Action being taken for user: sergej

Jun  8 18:30:20 grinder hostSentry[23460]: securityalert: Module requesting action is: moduleFirstLogin

Jun  8 18:30:20 grinder hostSentry[23460]: securityalert: Action complete for module: moduleFirstLogin

Jun  8 18:30:21 grinder hostSentry[23460]: securityalert: Foreign domain login detected for user: sergej from: 

Jun  8 18:30:21 grinder hostSentry[23460]: securityalert: Action being taken for user: sergej

Jun  8 18:30:21 grinder hostSentry[23460]: securityalert: Module requesting action is: moduleForeignDomain

Jun  8 18:30:21 grinder hostSentry[23460]: securityalert: Action complete for module: moduleForeignDomain

При этом сообщение securityalert не пройдет еще и мимо Logcentry. Теперь требуется некоторое время, чтобы детектор аномалий изучил то, как пользователи обычно действуют при входе в систему, постепенно количество сообщений будет уменьшаться, но зато когда бухгалтер Вася Пупкин, работавший обычно из соседнего офиса, и не знающий вообще, что такое UNIX, попытается вдруг зарегистрироваться из Китая, то администратор будет предупрежден.

Список модулей, применяемых в HostSentry:

n  moduleOddDirnames – скорее, вспомогательный модуль, проверяет домашний каталог пользователя. Обычно хакеры пытаются скрыть свое пребывание в системе и каталоги называют «.. » , «...». Вот это и пытается выяснить данный модуль;

n  moduleRhostCheck – этот модуль проверяет пользовательский .rhosts-файл при выходе из системы, и если в нем содержатся постановочные знаки (“+”), это будет зарегистрировано, и администратору можно будет заняться исследованием (использование r-сервисов – плохая идея);

n  moduleMultipleLogins – все просто, если пользователь несколько раз одновременно зарегистрировался на компьютере, то он (компьютер) уже, скорее, взломан и администратора об этом предупредят;

n  moduleFirstLogin – единственная цель этого модуля – предупреждение администратора, когда пользователь входит в систему первый раз после запуска HostSentry, т.е. когда пользователь ввел пароль и получил UNIX shell. Может, это и есть наш Вася Пупкин, а может и нет; во всяком случае, администратору будет интересно узнать, зачем бухгалтеру интерактивная оболочка;

n  moduleForeignDomain – очень часто нападающие, скомпрометировавшие какую-то учетную запись, входят в систему с домена, которому, в общем-то, нечего делать на вашем компьютере. Если такой домен не перечислен в файле moduleForeignDomain.allow, то он причисляется к подозрительным, и администратор получает предупреждение. Примечание: из-за ограничений в некоторых системах, связанных с максимально хранимым именем хоста, о чем говорилось выше, данный модуль может давать противоречивые результаты, в этом случае, скорее всего, придется данный модуль отключить, для информации загляните в файл utmp.h заголовка ядра (в RedHat максимальное число – 256, что является вполне достаточным);

n  moduleHistoryTruncated – модуль при регистрации проверяет файл историй используемого командного интерпретатора, прописанного в /etc/passwd (поддержаны bash, csh и tcsh). Тревожный сигнал выдается, если файл не существует или нулевого размера, или это символическая ссылка на /dev/null;

n  moduleLoginLogout – просто регистрирует, когда пользователь входит и выходит из системы.

Вот такой вот набор TriSentry. Ничего сверхъестественного, но все работает отменно, автоматизирует процесс администрирования системы и позволяет предупредить сисадмина о начале неприятностей.