Wednesday, July 23, 2008

Конвергенция контроля доступа к периферийным устройствам и антивирусного ПО

В практике довольно часты случае, когда некая побочная возможность какой-либо системы имеет даже большее значение, чем основной функционал. Или не совсем целевое использование того или иного приложения приносить больше выгоды, чем штатный режим работы.

Для ограничения и контроля доступа к периферийным устройствам (съемные накопители USB, CD/DVD-приводы, пр.) мы используем соответствующее, специально для этого предназначенное, ПО. Функциями этого ПО (далее Система) являются: предоставление доступа к устройствам в соответствии с политикой использования, назначенной для конкретного пользователя/группы пользователей (система полностью интегрируется с MS Active Directory) и централизованное ведение журналов – т.е. имеется некий интерфейс из которого администратор Системы может посмотреть какие файлы были успешно или неуспешно записаны с или на устройство, а также, какой процесс операционной системы это сделал.

Последние время мы наблюдаем огромное количество различного вредоносного ПО, распространяющегося через автозапуск со съемных носителей и, соответственно, заражающие другие съемные носители. Приведу несколько примеров, далеко не все, – W32/Autorun-AK, PWS-LegMir.gen.k, PWS-WoW, Troj/Shuckbot-A, W32/Autorun.worm.u, пр. К сожалению, наш антивирус, развернутый на рабочих станциях пользователей не всегда успешно обнаруживает и лечит эти вирусы (обновления антивирусных баз жестоко отстают). Здесь и приходит на помощь анализ журналов Системы контроля доступа к периферийным устройствам. Алгоритм такой:

  • Формируем отчет по записи файлов .exe, .com на носитель,
  • Анализируем отчет: ищем записи файлов с подозрительными именами в корень носителя (в некоторых случаях ситуация совсем смешная – «процесс kesha.exe записал файл E:\ kesha.exe»). Понимание того, что такое «подозрительное» имя приходит с опытом, по началу, можно просто обращать внимание на файлы, записанные в корень тома. Опыт показывает, что бывают легитимные (не вирусы) файлы .exe, со странными именами, записанные в корень, но не попадался ни один легитимный файл .com, не являющийся вирусом.
  • Подозрительные имена просто проверяем в Интернет. Пример для Recycler.exe. Полезно то, что Система регистрирует не только имя файла, но и его размер, что позволяет его проверять.
  • Убедившись, что данный подозрительный файл, вероятнее всего вирус – включаем на антивирусе забирать файл в карантин по имени (вообще, система обладает функцией теневого копирования, что позволяет настроить забор файлов и на самой системе, но мы ее не используем, поскольку теневое копирование не работает для данного имени файла). Конечно, лучше забирать в карантин и по имени и по сумме MD5 (сумма берется из описаний, найденных в Интернете), но, например, наш антивирус умеет забирать только по имени – что ж, все лучше, чем ничего.
  • Пойманный вирус анализируется альтернативными движками, например - http://www.virustotal.com/ . Такая проверка должна увеличить уверенность, что данный образец – действительно нежелательное ПО.
  • Если опасения подтвердились – направляем отчет с http://www.virustotal.com/ и образец файла-вируса (взятого из карантина) в поддержку антивируса.

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

6 comments:

Dmitry E. Katyshkin said...

Проблема в том, что такое сочетание систем работает в случае, если вирус относиться к семейству Autorun...
Сейчас задумался, а какие еще системы безопасности можно вот так совместить... Но в голову ничего так сразу и не пришло...

Sergey Soldatov said...

Можно вот еще что сделать. По логам IDS изучать сайты, с которых срабатывают различные эесплоиты (атаки, в общем смысле), и закрывать эти сайты на системе фильтрации Web. Периодически это делаю.

Igor Gots said...

В догонку:
- Использование систем IPS в качестве "мягкого" межсетевого экрана
- использование honeypot'ов как средств обнаружения несанкционированной сетевой активности
...

Sergey Soldatov said...

Ну, конечно, honeypot-ы стоят отдельного поста, но, как мне кажется, применение их в коммерческой компании (не исследовательком институте) нецелесообразно. Я считаю, что задача honeypot-а собрать как можно больше данных об атакующем, с целью дальнейшего исследования. Логично, если бы я, работая в исследовательском центре по ИБ, расставил бы эти ловушки в интернете и собирал бы с них evidence для дальнейшего исследования. Но, я работаю в коммерческой компании, и моя задача обнаружить угрозу, а не исследовать ее детальным образом, чтобы, может быть написать очередной advisory или выпустить сигнатуру. Я считаю, что мои задачи прекрасно решает IDS и использовать honeypot в качечестве IDS я не планирую (я лучше буду использовать IDS в качестве IDS :-)). Вы можете возразить про всякие Zero-day-и, что ж, согласен, но замечу, что современные IDS умеют не только находить сигнатуры в трафике, но и анализировать трафик в принципе (отклонения от RFC, пояление тех или иных протоколов, откланения от типовых счетчиков: например, в 1000 раз увеличилось количество ARP-ответов, пр) - этого достаточно, чтобы понять что что-то не так, сделать workaround и дождаться день-два до появления сигнатуры для этого нового безобразия.

Igor Gots said...

Считаю последнее замечание провокацией!
IDS в крупной сети - вещь совершенно бесполезная! Эти системы не позволяют обнаружить простейших атак, в результате их реальная ценность не сопоставима с затратами на установку и сопровождение!
Теперь про honeypot'ы. Я не даром вспомнил о них в комментариях к статье о конвергенции. Как раз они, если их использовать не как инструмент исследователя, а как средства обнаружения злоумышленника выбирающего цель (IDS?)- справляются с работой на 100%.

Sergey Soldatov said...

Игорь,
1. считаю затраты на разворачивание honeypot-ов значительно выше, чем на разворачивание IDS. IDS может через RSPAN снифать вообще весь трафик, который у тебя есть в сети. В случае с honeypot тебе надо еще решить проблему, как туда направить трафик от атакера.
2. Все что наловит honeypot надо по-любому чем-то аналализировать. Чем ты это будешь делать? Опять же IDS-ом! Что бы ты не говорил, в любом случае IDS лучше ищет атаки и аномалии, чем ты это будешь делать глазами.
3. Я не знаю где ты набрался такого негатива к IDS, но поверь, IDS можно доточить до эффективной работы. Да, это процесс, причем бесконечный (также как бесконечен процесс Изменения инфраструктуры ИТ в погоне за желаниями бизнеса), но очевидная аксиома, что безопансоть - это процесс, а не цель, к которой можно когда-нибудь придти и начать полагать что все хорошо.