безопасность PostScript
СЕРГЕЙ ЯРЕМЧУК 44
безопасность В статье «Контрольная сумма на защите 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, в котором содержатся некоторые опции конфигурирования, для большинства случаев подойдут используемые по умолчанию: CONFIG_FILE “/usr/local/psionic/portsentry2/portsentry.conf” – содержится путь к конфигурационному файлу, если значение по умолчанию не подходит, изменив его, не забудьте подправить его и в Makefile в опциях INSTALLDIR (/usr/local/psionic) и CHILDDIR (/portsenry2); WRAPPER_HOSTS_DENY “/etc/hosts.deny” – путь к файлу hosts.deny для работы tcpwrapper; SYSLOG_FACILITY LOG_DAEMON – тип логов для syslogd (подробности в man 3 syslog); SYSLOG_LEVEL LOG_NOTICE – уровень syslogd для посылки сообщений; MAXSTATE 50 – максимальное количество запоминаемых хостов для проверки повторного подключения. Знак решетки (#) в этом файле в начале строк с переменными – это не признак комментария, они требуются
№7(8), июль 2003
компилятором С при обработке файлов заголовков, поэтому удалять их не надо. После набираем: # 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, остальные при необходимости заносятся в формате /. Например: 192.168.2.0/24 192.168.0.0/16 192.168.2.1/32
По умолчанию используется 32-битная маска. Теперь самое время заглянуть в главный конфигурационный файл portsentry.conf. Опции в этом файле для удобства условно сгруппированы по секциям и имеют вид ОПЦИЯ=«значение».
Значения опций файла portsentry.conf Interface Configurations INTERFACE=«auto» – названия подконтрольного интер-
фейса, при наличии одного возможен вариант «auto», и он будет найден автоматически; если же их несколько, то необходимо указать на выбранный для контроля, например INTERFACE=«eth0», Portsentry может контролировать только один интерфейс. INTERFACE_ADDRESS=«XXX.XXX.XXX.XXX» – IP-адрес интерфейса, без него Portsentry не сможет работать должным образом, в данное время не поддерживается динамическое определение адреса, в этом случае придется писать скрипт (но в ближайшее время, по заверениям разработчиков, такая опция будет реализована).
Port Configurations TCP_PORTS – перечисляются через запятую все про-
веряемые Portsentry TCP-порты (диапазоны не поддерживаются), список желательно не делать слишком большим, чтобы уменьшить количество срабатываний, но он должен охватывать весь диапазон и содержать порт номер 1, так как в большинстве сканеров сканирование начинается именно с него, также не надо включать сюда порты, открытые работающими приложениями (20 – ftp, 25 – sendmail, 80 – httpd и пр.). При попытке подключения к указанному порту информация об этом заносится в логи, затем выполняется пользовательская команда и после узел блокируется при помощи ipchains. UDP_PORTS – то же самое, только касается UDP-портов.
45
безопасность Configuration Files IGNORE_FILE – полный путь к файлу portsentry.ignore. HISTORY_FILE – путь к файлу с историей, в котором
содержатся записи о времени блокирования, имени и IP-адреса хоста, атакованный порт и протокол (TCP или UDP). BLOCKED_FILE – шаблон, из которого формируется файл блокировки, имеющий имя BLOCKED_FILE.протокол.
Misc. Configuration Options RESOLVE_HOST – при установлении в 1 производится запрос сервера DNS имени хоста нападавшего. На медленных компьютерах это может увеличить время реакции и может предупредить нападающего о наличии Portsentry, если он контролирует сервер имен. Значение по умолчанию – 0.
Ignore Options BLOCK_UDP – позволяет задать ответную реакцию
на сканирование в зависимости от установленного значения. При значении 0 ничего не происходит, узел не блокируется, команда не запускается; 1 означает блокировать узел и запустить на выполнение команду; 2 – только запустить заданную команду. Команда задается при помощи опции KILL_RUN_CMD. BLOCK_TCP – то же самое, только для TCP-протокола.
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 должно появиться примерно такое сообщение, в котором описываются контролируемый интерфейс и порты:
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 KILL_RUN_CMD – команда, которая будет выполнена
46
в сторону нападающего. Можно запустить отправку почты администратору или на любителя порцию фрагментированных пакетов. KILL_RUN_CMD_FIRST – установка значения в 0 запустит команду, перед тем как маршрут будет удален из таблицы; в 1 – после.
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,3133 7,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. Jun
Последняя строка указывает на счастливый запуск утилиты, если ее нет, то что-то сделано неправильно. При этом могут быть следующие специфические сообщения: adminalert – это сообщение выводит текущий статус PortSentry. securityalert – сообщение о том, что некое защитное событие произошло. attackalert – компьютер был атакован и соответствующие данные занесены в /etc/host.deny. В первой же версии программы использовалось шесть режимов по три на каждый протокол (TCP и UDP): portsentry -tcp (basic port-bound TCP mode) portsentry -udp (basic port-bound UDP mode) portsentry -stcp (Stealth TCP scan detection) portsentry -atcp (Advanced TCP stealth scan detection) portsentry -sudp («Stealth» UDP scan detection) 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
№7(8), июль 2003
После этого скомпилированная программа 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
[email protected]:1490
Первая строка указывает на довольно обычную житейскую ситуацию с sendmail, отдаленный компьютер отказался от подключений, т.е. слово refused к нашему случаю не имеет абсолютно никакого отношения. А вот в следующей некто с
[email protected] пробовал запускать 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 одно и то же), в которое сообщение, соответствующее
47
безопасность данному событию, будет выводиться. Т.е. необходимо просто собрать все записи, которых нет в левой части, соответствующей /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 chmod chown chmod
root.wheel /usr/local/etc/logcheck.sh 600 /usr/local/etc/logcheck.sh root.wheel /usr/local/bin/logtail 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: logtail анализирует log-файлы с последней запомненной позиции; logcheck при помощи grep проверяет оставшийся текст на наличие сообщений о возможной атаке; при помощи grep проверяются все возможные негативные сообщения; на следующем шаге отбираются из них те, которые нужно проигнорировать (logcheck.violations.ignore); все сообщения, которые нужно проигнорировать, заносятся в logcheck.ignore; после всего этого сисадмин получает e-mail с оставшимися сообщениями. Еще одна проблема может возникнуть с использованием утилиты logsentry. Связана она с локализацией. Дело в том, что в большинстве дистрибутивов local устанавливается автоматически по используемому основ-
48
ному языку системы. Естественно, после того как переменная LANG будет равняться KOI8-R, все сообщения будут выводиться на русском языке (и запись в лог-файлы также), дополнительно в последнее время обострилась ситуация с продвижением единой кодировки Unicode, т.е. в RedHat 8.0 и 9 LANG=«ru_RU.UTF-8». Logcenry в этом случае ничегошеньки (или почти) не найдет. И все потому, что все шаблоны записаны на английском. Поэтому лучше всего использовать PanEuropean version, т.е. когда сообщения выводятся на английском (в AltLinux сейчас примерно так все и работает). Для этого в файле /etc/sysconfig/i18n меняем соответствующие строки на: LANG="en_US" SYSFONT="Cyr_a8x16" SYSFONTACM="koi2alt"
Остальные можно оставить как есть. После этого проблем уже быть не должно.
HostSentry И последняя, самая молодая, утилита HostSentry. Представляет собой инструмент обнаружения вторжения, основанный на технологии Login Anomaly Detection (LAD), который определяет подозрительные действия при входе в систему и позволяет быстро выявлять скомпрометированные пользовательские аккаунты и необычное поведение. HostSentry включает динамическую базу данных и фактически изучает поведение входа в систему пользователя. Это поведение используется модульными сигнатурами, чтобы обнаружить необычные действия. Прошу обратить внимание на словосочетание «при входе в систему», если компьютер уже скомпрометирован, и взломщик уже имеет легальный вход в систему, здесь уже помочь будет трудно, а вот когда делаются первые шаги, применение HostSentry будет как раз к месту. При этом необходимо помнить, что обнаружив ее, злоумышленник также может подменить утилиту. При этом HostSentry определяет: необычные действия при входе в систему; подозрительные домены, с которых осуществляется вход; подозрительные каталоги пользователей; обнаруживает вмешательство в файлы истории команд и входа в систему; неизвестные входы в систему; имеет расширяемые модули сигнатур. Когда 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).
После первого запуска образуются две базы данных: hostsentry.db, содержащая записи обо всех пользователях, которые регистрировались с тех пор, пока HostSentry был в действии, и hostsentry.tty.db об используемых (активных) терминалах. В пользовательской базе данных хранятся объекты входа в систему пользователя, которые сформированы со следующей схемой: username – имя входящего в систему пользователя; recordCreated – дата начала записи в Unix-формате; firstLogin – первый вход в систему для этого пользователя; trackLogins – список входов в систему этого пользователя (будет постоянно расти); validLoginDays – дни, когда данному пользователю разрешено регистрироваться в системе; validLoginHours – часы, когда пользователю разрешено регистрироваться; adminDisabled – флаг, указывающий на то, что данная запись была отключена администратором; securityDisabled – флаг, указывающий на то, что данный пользователь был лишен возможности регистрироваться модулем программы; totalLogins – общее количество регистраций для данного пользователя; version – версия схемы базы данных. База данных терминалов помогает HostSentry поддержать список активных подключений и позволяет программе знать, когда пользователь регистрировался. Поскольку эти данные не используются между включениями, она обнуляется каждый раз при перезапуске HostSentry. При этом отслеживаются следующие элементы: tty – TTY, с которого зарегистрировался пользователь; username – имя пользователя; loginStamp – уникальный timestamp для login; version – версия схемы базы данных. В loginStamp заносится информация, необходимая для обработки компонентами системы и формируется следующим образом: loginIP@loginHostname@loginTTY@loginTime@logoutTime
Где:
LoginIP – IP-адрес пользователя при регистрации; LoginHostname – имя хоста (полностью уточненное при помощи DNS);
LoginTTY – TTY пользователя; LoginTime – время входа в систему в Unix-формате; LogoutTime – время выхода из системы в Unix-формате.
# python hostsentry.py
При этом в файле /var/log/messages должны появиться такие строки. 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 Jun 8 18:26:43 grinder hostSentry[23460]: adminalert: ↵ HostSentry is active and monitoring logins. Jun
№7(8), июль 2003
Если попробовать теперь зарегистрироваться, то дополнительно появится сообщение, в котором указывается кто, когда, откуда и какие модули были выполнены. 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
49
безопасность 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
↵
moduleFirstLogin – единственная цель этого модуля –
↵
предупреждение администратора, когда пользователь входит в систему первый раз после запуска HostSentry, т.е. когда пользователь ввел пароль и получил Unix shell. Может, это и есть наш Вася Пупкин, а может и нет; во всяком случае, администратору будет интересно узнать, зачем бухгалтеру интерактивная оболочка; moduleForeignDomain – очень часто нападающие, скомпрометировавшие какую-то учетную запись, входят в систему с домена, которому, в общем-то, нечего делать на вашем компьютере. Если такой домен не перечислен в файле moduleForeignDomain.allow, то он причисляется к подозрительным, и администратор получает предупреждение. Примечание: из-за ограничений в некоторых системах, связанных с максимально хранимым именем хоста, о чем говорилось выше, данный модуль может давать противоречивые результаты, в этом случае, скорее всего, придется данный модуль отключить, для информации загляните в файл utmp.h заголовка ядра (в RedHat максимальное число – 256, что является вполне достаточным); moduleHistoryTruncated – модуль при регистрации проверяет файл историй используемого командного интерпретатора, прописанного в /etc/passwd (поддержаны bash, csh и tcsh). Тревожный сигнал выдается, если файл не существует или нулевого размера, или это символическая ссылка на /dev/null; moduleLoginLogout – просто регистрирует, когда пользователь входит и выходит из системы.
↵ ↵ ↵ ↵ ↵
При этом сообщение securityalert не пройдет еще и мимо Logcentry. Теперь требуется некоторое время, чтобы детектор аномалий изучил то, как пользователи обычно действуют при входе в систему, постепенно количество сообщений будет уменьшаться, но зато когда бухгалтер Вася Пупкин, работавший обычно из соседнего офиса, и не знающий вообще, что такое Unix, попытается вдруг зарегистрироваться из Китая, то администратор будет предупрежден. Список модулей, применяемых в HostSentry: moduleOddDirnames – скорее, вспомогательный модуль, проверяет домашний каталог пользователя. Обычно хакеры пытаются скрыть свое пребывание в системе и каталоги называют «.. » , «...». Вот это и пытается выяснить данный модуль; moduleRhostCheck – этот модуль проверяет пользовательский .rhosts-файл при выходе из системы, и если в нем содержатся постановочные знаки (“+”), это будет зарегистрировано, и администратору можно будет заняться исследованием (использование r-сервисов – плохая идея); moduleMultipleLogins – все просто, если пользователь несколько раз одновременно зарегистрировался на компьютере, то он (компьютер) уже, скорее, взломан и администратора об этом предупредят;
50
Вот такой вот набор TriSentry. Ничего сверхъестественного, но все работает отменно, автоматизирует процесс администрирования системы и позволяет предупредить сисадмина о начале неприятностей.
безопасность
№7(8), июль 2003
51
