Недавно мы проводили очередной виртуальный саммит, который был посвящен теме безопасности DNS и использования этого протокола при расследовании инцидентов ИБ (первый саммит мы посвятили теме фишинга и борьбы с ним). Не буду пересказывать 4 часа мероприятия, тем более, что часть его была посвящена решениям Cisco, а я стараюсь в персональном блоге не сильно злоупотреблять и рекламировать наши решения, но некоторые слайды позволю себе выложить, так как они, на мой взгляд, могут быть полезны.
Собственно, идея этих слайдов достаточно проста. При расследовании инцидентов у нас обычно перед глазами находится только адрес, с которого осуществляется атака или с которым идет взаимодействие скомпрометированного узла. Просто адрес - IP или DNS. Это точка отсчета, с которой часто начинается расследование инцидента.
Эту информацию мы берем из разных источников - внешних (например, ФинЦЕРТа, ГосСОПКИ, Лаборатории Касперского или Cisco) и внутренних (МСЭ, proxy, IPS или Neflow collector). Данные из внешних источников могут быть обогащены дополнительной информацией, которая, конечно, требует перепроверки. Но часто вы получаете просто адрес, который вам нужно блокировать, что, конечно, не совсем полезно с точки зрения расследования инцидентов.
При расследовании нам нужно ответить на ряд важны вопросов:
И вот тут нам может помочь как раз DNS-протокол, к которому мы так привыкли, что даже не замечаем того, что он нам может дать с точки зрения кибербезопасности. А дать он может очень многое:
Например, по длине FQDN можно отслеживать сайты, используемые для кражи информации. Также мы можем проанализировать названия доменов и попробовать идентифицировать уровень энтропии в них для идентификации DGA-доменов. Наконец, мы с легкостью можем понять, кто, когда и где регистрировал домен.
Больший объем этой информации можно выцепить с помощью обычных утилит, входящих в состав Windows, Linux или MacOS (например, whois или dig). Можно и различные web-сервисы под эту задачу задействовать, но они выдадут примерно ту же информацию.
Правда, у этих утилит есть один недостаток, который делает их пусть и полезными для расследования инцидентов, но все-таки не до конца. Они не дают сводной и ретроспективной информации об истории домена, о его взаимодействии с другими доменами, об истории IP-адреса или автономной системы, на которых "висит" домен, о том, какими еще доменами владеет автор исследуемого домена и т.п.?
Последние упомянутые сведения позволяют нам составить представление уже не только по отдельному домену, но по целой инфраструктуре, которую использует злоумышленник или злоумышленники при реализации атаки. И собирать данную информацию в ручном режиме уже затруднительно - нужен автоматизированный инструментарий для анализа DNS.
С помощью такого инструментария можно достаточно оперативно выследить сотни и тысячи доменов, находящихся в инфраструктуре злоумышленников. Может быть даже так, что эти домены еще не пустили в ход и только готовят к будущим атакам.
Я обещал, что не буду пересказывать четырехчасовой саммит, поэтому не буду глубже погружаться в эту тему. Просто хочу лишний раз напомнить, что при расследовании инцидентов не стоит недооценить информацию, которая находится на виду и которая позволяет получить достаточно детальные сведения о том, кто вас атакует. Анализ DNS для этого подходит как нельзя лучше.
Собственно, идея этих слайдов достаточно проста. При расследовании инцидентов у нас обычно перед глазами находится только адрес, с которого осуществляется атака или с которым идет взаимодействие скомпрометированного узла. Просто адрес - IP или DNS. Это точка отсчета, с которой часто начинается расследование инцидента.
Эту информацию мы берем из разных источников - внешних (например, ФинЦЕРТа, ГосСОПКИ, Лаборатории Касперского или Cisco) и внутренних (МСЭ, proxy, IPS или Neflow collector). Данные из внешних источников могут быть обогащены дополнительной информацией, которая, конечно, требует перепроверки. Но часто вы получаете просто адрес, который вам нужно блокировать, что, конечно, не совсем полезно с точки зрения расследования инцидентов.
При расследовании нам нужно ответить на ряд важны вопросов:
И вот тут нам может помочь как раз DNS-протокол, к которому мы так привыкли, что даже не замечаем того, что он нам может дать с точки зрения кибербезопасности. А дать он может очень многое:
Например, по длине FQDN можно отслеживать сайты, используемые для кражи информации. Также мы можем проанализировать названия доменов и попробовать идентифицировать уровень энтропии в них для идентификации DGA-доменов. Наконец, мы с легкостью можем понять, кто, когда и где регистрировал домен.
Больший объем этой информации можно выцепить с помощью обычных утилит, входящих в состав Windows, Linux или MacOS (например, whois или dig). Можно и различные web-сервисы под эту задачу задействовать, но они выдадут примерно ту же информацию.
Правда, у этих утилит есть один недостаток, который делает их пусть и полезными для расследования инцидентов, но все-таки не до конца. Они не дают сводной и ретроспективной информации об истории домена, о его взаимодействии с другими доменами, об истории IP-адреса или автономной системы, на которых "висит" домен, о том, какими еще доменами владеет автор исследуемого домена и т.п.?
С помощью такого инструментария можно достаточно оперативно выследить сотни и тысячи доменов, находящихся в инфраструктуре злоумышленников. Может быть даже так, что эти домены еще не пустили в ход и только готовят к будущим атакам.
Я обещал, что не буду пересказывать четырехчасовой саммит, поэтому не буду глубже погружаться в эту тему. Просто хочу лишний раз напомнить, что при расследовании инцидентов не стоит недооценить информацию, которая находится на виду и которая позволяет получить достаточно детальные сведения о том, кто вас атакует. Анализ DNS для этого подходит как нельзя лучше.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.