 |
|
|
|
Три составных части защиты
Три составных части защиты В статье «Контрольная сумма на защите 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, в котором содержатся некоторые опции конфигурирования, для большинства случаев подойдут используемые по умолчанию:
Знак решетки (#) в этом файле в начале строк с переменными – это не признак комментария, они требуются компилятором С при обработке файлов заголовков, поэтому удалять их не надо. После набираем: # 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
Port Configurations
Configuration Files
Misc. Configuration Options
Ignore Options
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
External Command
Scan trigger value
Это все опции применительно к версиям 1.1 и 2.0, но в версии 1.1, которая до сих пор пользуется популярностью, имеется еще одна опция – PORT_BANNER, которая задает сообщение, выводимое при подключении к проверяемому порту.
Сами авторы программы не рекомендуют пользоваться ею, чтобы не злить взломщика, очевидно поэтому она и была убрана со второй версии программы. Хотя можно попытаться при помощи этой опции сбить начинающего взломщика с толку, указав, например, неправильные данные о системе. После того как все параметры установлены, можно запускать утилиту. Во второй версии это просто запуск исполняемого файла без параметров. # /usr/local/psionic/portcentry2/portcentry После этого в файле /var/log/message должно появиться примерно такое сообщение, в котором описываются контролируемый интерфейс и порты:
Последняя строка указывает на счастливый запуск утилиты, если ее нет, то что-то сделано неправильно. При этом могут быть следующие специфические сообщения:
В первой же версии программы использовалось шесть режимов по три на каждый протокол (TCP и UDP):
Для каждого протокола может запускаться только один выбранный режим. В режиме 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). Например, сравните следующие два сообщения:
Первая строка указывает на довольно обычную житейскую ситуацию с 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:
Еще одна проблема может возникнуть с использованием утилиты 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 определяет:
Когда 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 должны появиться такие строки.
После первого запуска образуются две базы данных: hostsentry.db, содержащая записи обо всех пользователях, которые регистрировались с тех пор, пока HostSentry был в действии, и hostsentry.tty.db об используемых (активных) терминалах. В пользовательской базе данных хранятся объекты входа в систему пользователя, которые сформированы со следующей схемой:
База данных терминалов помогает HostSentry поддержать список активных подключений и позволяет программе знать, когда пользователь регистрировался. Поскольку эти данные не используются между включениями, она обнуляется каждый раз при перезапуске HostSentry. При этом отслеживаются следующие элементы:
В loginStamp заносится информация, необходимая для обработки компонентами системы и формируется следующим образом: loginIP@loginHostname@loginTTY@loginTime@logoutTime Где:
Если попробовать теперь зарегистрироваться, то дополнительно появится сообщение, в котором указывается кто, когда, откуда и какие модули были выполнены.
При этом сообщение securityalert не пройдет еще и мимо Logcentry. Теперь требуется некоторое время, чтобы детектор аномалий изучил то, как пользователи обычно действуют при входе в систему, постепенно количество сообщений будет уменьшаться, но зато когда бухгалтер Вася Пупкин, работавший обычно из соседнего офиса, и не знающий вообще, что такое UNIX, попытается вдруг зарегистрироваться из Китая, то администратор будет предупрежден. Список модулей, применяемых в HostSentry:
Вот такой вот набор TriSentry. Ничего сверхъестественного, но все работает отменно, автоматизирует процесс администрирования системы и позволяет предупредить сисадмина о начале неприятностей. |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
