Методы противодействия

Использование журнальных файлов при расследовании сетевых инцидентов

Для отслеживания работы ОС и приложений обычно предусматривается система журнальных файлов, которая фиксирует все события (приход запросов, соответствие запросов определенным критериям и т.д.)

Рассмотрим использование журнальных файлов на примере анализа успешной атаки вторжение через приложение SSH.

Если возникло подозрение относительно возможного вторжения, надо начинать с просмотра файлов secure и messages (каталог / var / log / ОС LINUX). В нашем случае атака началась в пятницу вечером (8-го июля 2005 года). Ниже представлены фрагменты журнальных файлов, иллюстрирующие характер атаки.

Jul 8 18:23:18 fender sshd[15017]:Illegal user anonymous from 207.232.63.45
Jul 8 18:23:20 fender sshd[15019]: Illegal user bruce from 207.232.63.45 (Нью-Йорк, США)
Jul 8 18:23:22 fender sshd[15021]: Illegal user chuck from 207.232.63.45
Jul 8 18:23:23 fender sshd[15023]: Illegal user darkman from 207.232.63.45
…
Jul 9 13:15:13 fender sshd[16764]: Illegal user bruce from 129.237.101.171
Jul 9 13:15:14 fender sshd[16766]: Illegal user chuck from 129.237.101.171
Jul 9 13:15:16 fender sshd[16768]: Illegal user darkman from 129.237.101.171
Jul 9 13:15:17 fender sshd[16770]: Illegal user hostmaster from 129.237.101.171
….
Jul 10 15:25:34 fender sshd[28450]: Did not receive identification string from 80.18.87.243\par
Jul 10 16:56:16 fender sshd[28457]: Illegal user lynx from 80.18.87.243\par
Jul 10 16:56:17 fender sshd[28459]: Illegal user monkey from 80.18.87.243\par
Jul 10 16:56:18 fender sshd[28461]: Illegal user lion from 80.18.87.243\par
….
Jul 10 02:42:02 fender sshd[18064]: Did not receive identification string from 166.70.74.35
Jul 10 03:09:13 fender sshd[18067]: Illegal user admin from 166.70.74.35 (Солт Лейк Сити, США)
Jul 10 03:09:14 fender sshd[18069]: Illegal user admin from 166.70.74.35
Jul 10 03:09:16 fender sshd[18071]: Illegal user admin from 166.70.74.35
….
Jul 10 16:56:16 fender sshd[28457]: Illegal user lynx from 80.18.87.243 (Венеция, Италия)
Jul 10 16:56:17 fender sshd[28459]: Illegal user monkey from 80.18.87.243
Jul 10 16:56:18 fender sshd[28461]: Illegal user lion from 80.18.87.243
….
Jul 10 16:56:40 fender sshd[28509]: Failed password for root from 80.18.87.243 port 45208 ssh2
Jul 10 16:56:41 fender sshd[28511]: Accepted password for root from 80.18.87.243 port 45298 ssh2
….
Jul 10 19:13:49 fender sshd[31152]: Accepted password for root from 81.181.128.181 port 4943 ssh2

Из записей видно, что машина была атакована из 7 точек. Четыре расположены в США ( IP=166.70.74.35; 207.232.63.45; 129.79.240.86 и 129.237.101.171 ), по одной — в Италии, Румынии и Венгрии ( IP=80.98.194.185 ). Производится подбор параметров доступа имя-пароль. Подбор продолжался около двух суток.

Успешный вариант был найден машиной из Италии ( IP-адрес=80.18.87.243 Венеция). Практически сразу атака со стороны всех ЭВМ была прервана и хакер вошел на атакуемую ЭВМ ( имя_ЭВМ=fender ) из машины с IP=81.181.128.181 ( Румыния ).

Для дальнейшего анализа событий нами были использованы данные из файла .bash_history, куда записываются все команды, исполняемые пользователем в терминальном режиме. Записи этого файла и результаты работы демона syslogd говорят о том, что через 3 минуты после успешного вторжения хакер заблокировал работу syslog.

Далее хакер заблокировал доступ к системе других пользователей, загрузил туда файл pass_file (объем 696057 байт), содержащий комбинации имя-пароль (небольшие фрагменты содержимого файла представлены ниже).

lynx lynx
monkey monkey
lion lion
heart heart
michel michel
alibaba alibaba
…..
root 123456
root 1234567
….
root 1234567890
root rootroot
root rootrootroot
root 123root123
root 987654321
….
root 4321
root 321
root root!
root root!@
root root!@#
….

Хакер рассчитывает на то, что пользователь ЭВМ ленив и выбирает простой пароль (легче запомнить — легче подобрать). Кроме того, хакер скопировал на взломанную ЭВМ несколько скриптов и файл со списком адресов — кандидатов на взлом. После этого машина включилась в работу по подбору паролей на других ЭВМ.

К сожалению, факт атаки был установлен лишь утром в понедельник. Сначала была проведена частичная блокировка. Хакер почувствовал неладное и выдал команды last и ps, пытаясь понять, что происходит; дальнейшая его работа была полностью блокирована.

Какие выводы из этой истории можно сделать? На атакованной рабочей станции была установлена SSH устаревшей версии (имевшей уязвимость) и использован достаточно простой пароль. По этой причине нужно своевременно обновлять ОС и версии приложений. (Про выбор паролей смотри RFC-2196.) Особо опасными с точки зрения атак является ночь и выходные дни. Если нет насущной необходимости, лучше на это время блокировать доступ к ЭВМ или даже выключать ее.

Помимо журнальных файлов ОС надо просматривать и соответствующие файлы приложений, например, Firewall (BlackIce Defender, ZoneAlarm и т.д.), Apache, баз данных и пр. Если даже в вашей зоне ответственности только один компьютер, просмотр всех важных файлов достаточно трудоемок. По этой причине следует рассмотреть возможность использования специализированных скриптов, которые возьмут эту работу на себя, информируя вас в случае выявления тревожных событий. Результаты работы скриптов должны накапливаться в базе данных. Эти данные могут использоваться для получения данных об атакерах и формирования ACL (списков управления доступом).

Хакер может попытаться уничтожить следы своего пребывания, стерев или очистив определенные журнальные файлы. Вполне возможно, в нашем случае хакер так бы и поступил, восстановив перед уходом и доступ по SSH. По этой причине следует заранее побеспокоиться о периодическом копировании журнальных файлов на недоступное для хакера устройство или сохранении их в зашифрованном виде. Но хакер может поступить и более жестоко, например, разметив заново системный диск. Хорошая схема защиты должна предотвращать такого рода действия или позволять хотя бы быстро восстанавливать разрушенную конфигурацию системы.

Следует учитывать, что сами журнальные файлы могут стать объектом атаки типа DoS. Большой поток запросов, поступающих с нескольких ЭВМ и обращенных к одному или нескольким ресурсам машины, могут привести к быстрому росту журнальных файлов, переполнить дисковое запоминающее устройство и блокировать работу сервера.

Широкое внедрение ИНТРАНЕТ, где группы разбросанных по сети пользователей локальных сетей объединяются друг с другом с помощью виртуальных каналов VLAN (Virtual Local Area Network; http://www.3com.com/nsc/200374.html), потребовало разработки новых протоколов. Архитектура VLAN позволяет эффективно разделять трафик, лучше использовать полосу канала, гарантировать успешную совместную работу сетевого оборудования различных производителей и обеспечить высокую степень безопасности. При этом пакеты следуют между портами в пределах локальной сети. В последнее время для задач построения VLAN разработан стандартный протокол IEEE 802.10 (3-ий сетевой уровень). Этот протокол предполагает, что пакеты VLAN имеют свои идентификаторы, которые и используются для их переключения. Протокол может поддерживать работу 500 пользователей и более. Полное название стандарта - IEEE 802.10 Interoperable LAN/MAN Security (MAN — Metropolitan Area Network — региональная или муниципальная сеть). Стандарт принят в конце 1992 года. Количество VLAN в пределах одной сети практически не ограничено. Протокол позволяет шифровать часть заголовка и информационное поле пакетов.

Стандарт IEEE 802.10 определяет один протокольный блок данных (PDU), который носит название SDE (Secure Data Exchange) PDU. Заголовок пакета IEEE 802.10 имеет внутреннюю и внешнюю секции и показан на рис. 13.4.

Рис. 13.4. Формат пакета IEEE 802.10

Поле чистый заголовок включает в себя три субполя. MDF (Management Defined Field) является опционным и содержит информацию о способе обработки PDU. Четырехбайтовое субполе said (Security Association Identifier) — идентификатор сетевого объекта ( VLAN ID). Субполе 802.10 LSAP (Link Service Access Point) представляет собой код, указывающий принадлежность пакета к протоколу vlan. Предусматривается режим, когда используется только этот заголовок.

Защищенный заголовок копирует себе адрес отправителя из mac-заголовка (MAC — Media Access Control), что повышает надежность.

Поле ICV (Integrity Check Value) служит для защиты пакета от несанкционированной модификации. Для управления VLAN используется защищенная управляющая база данных SMIB (security management information base).

Наличие VLAN ID (said) в пакете выделяет его из общего потока и переправляет на опорную магистраль, через которую и осуществляется доставка конечному адресату. Размер поля data определяется физической сетевой средой. Благодаря наличию mac-заголовка VLAN -пакеты обрабатываются как обычные сетевые кадры. По этой причине VLAN может работать в сетях TCP/IP (Appletalk менее удобна). В среде типа Netbios работа практически невозможна. Сети ATM прозрачны для VLAN. Протокол VLAN поддерживается корпорацией Cisco, 3com и др. Хотя VLAN ориентирован на локальные сети, он может работать и в WAN, но заметно менее эффективно. В последнее время разработано большое число специальных программных средств сетевой безопасности.

Одним из наиболее эффективных способов защиты информации является шифрование сообщений, что, к сожалению, заметно увеличивает время отклика (шифрование-дешифрование). Задержки при большом входном трафике могут привести к блокировке сервера.

Традиционные Firewall постепенно замещаются программами, способными анализировать не только заголовки, но и данные, например, XML- firewall или WEB-сервис firewall. Следует иметь в виду, что наличие Firewall сети или отдельной ЭВМ не является гарантией безопасности, — в частности, потому, что сама эта программа может стать объектом атаки. XML- firewall анализирует содержимое (поле данных пакетов) сообщений и контролирует аутентификацию, авторизацию и акаунтинг. Различие между XML- firewall и WEB-сервис firewall заключается в том, что последний не поддерживает открытые стандарты. В настоящее время Firewall должны контролировать четыре аспекта:

1. Целостность сообщений
2. Предотвращение DoS атак
3. Защита с учетом анализа данных
4. Аутентификация и авторизация.

Смотри:

• http://www.nwc.com/showitem.jhtml
• http://www.oasis-open.org
• http://vulcan.forumsys.com
• http://nwc.securitypipline.com (Network Computing USA's Security Pipeline — 'XML Gateways' статья Lori McVittie).

До недавнего времени компания CISCO хранила пароли в конфигурационных файлах в виде открытого текста, теперь они собираются использовать хешированное хранение паролей.

Но современные ЭВМ легко позволяют подобрать пароль при наличии хэша (2ГГц Intel может проверить 5000 паролей в сек). По этой причине нужно ограничить доступ к файлу хэшей паролей. Табличный метод (rainbow tables) может ускорить подбор на порядок.

Многофакторная аутентификация является, похоже, единственной альтернативой современной системе паролей. Здесь имеется в виду использование сертификатов, ID-карт пользователей, и контроль их биометрических данных (отпечатков пальцев, голоса или радужной оболочки глаза).

Многие администраторы, установив Firewall, IDS и антивирусную защиту, считают задачу обеспечения сетевой безопасности выполненной. К сожалению, это лишь небольшая часть мер обеспечения безопасности. При проектировании системы безопасности полезно иметь в виду пирамиду Maslow'а (смотри рис. 13.5). И начинать надо с проектирования основания пирамиды, где расположено управление обновлением программных продуктов (Patches) и организация основных процедур. Это логично, так как хакеры обычно фокусируют свои усилия на известных уязвимостях ОС или приложений, и своевременное их обновление, блокирующее выявленные слабости, крайне важно. Такие обновления должны сначала тестироваться с целью детектирования возможных негативных последствий, прежде чем они будут рекомендованы или установлены на всех ЭВМ организации. Источник обновления должен также проверяться всеми возможными средствами. Выполнение обновлений должно поручаться квалифицированному персоналу. Должны быть разработаны инструкции для базовых операций администрирования ЭВМ и сети в целом. Сюда входят операции аутентификации, авторизации и контроля качества паролей, шифрование административного трафика, обслуживание журнальных файлов и т.д.

Несколько увеличить безопасность может применение VLAN или VPN. Эти технологии не дают абсолютной защиты, но заметно поднимают уровень безопасности. Здесь нужно разделять истинные VPN и виртуальные сети, формируемые в рамках протокола MPLS. Последние помогают улучшить ситуацию лишь незначительно. Но пометка определенных потоков с помощью DSCP, меток MPLS или IPv6, не давая реальной защиты, заметно усложняют работу хакера (что само по себе уже неплохо).

Рис. 13.5. Пирамида Maslow