По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! Мы продолжаем обозревать и рассказывать вам про коммерческие модули для FreePBX и сегодня на очереди модуль Class of Service, который помогает администратору управлять доступом пользователей к различному функционалу IP-АТС. Итак, поехали!
Обзор
Лицензии на использование модуля Class of Service продаются за 99$ (на
Все, кто так или иначе причастен к миру IT, точно слышал это слово из трех букв - DNS. Domain Name System это своего рода телефонный справочник, в котором указаны адреса всех веб-сайтов в интернете. Также DNS это довольно простой протокол, работающий, как правило, через 53 порт и который используется системными администраторами в буквально каждой сети - ну а куда без него? В данной статье мы не будем подробно разбирать схему работы DNS и типа DNS серверов - это мы оставим на потом.
Каждый раз когда приложение или человек пытается попасть на какой-нибудь веб-сайт, DNS запрашивает в образном "телефонном справочнике" IP-адрес этого ресурса и отправляет вас по нужному адресу.
Темой этой статьи будет некорректное использование службы злоумышленниками: в какой-то момент умные товарищи поняли, что DNS также является прекрасным вектором атаки и научились использовать DNS в целях передачи информации и команд на компьютер жертвы, и это, по сути является основным принципом DNS туннелирования.
Принцип работы DNS туннелирования на пальцах
Пять шагов DNS туннелирования:
Злоумышленник использует DNS для маскировки вредоносных действий, т.к DNS трафик в 99,99% разрешен и не проверяется;
Далее злодеи туннелирует другие протоколы (к примеру, http) через DNS
Далее они туннелируют IP-трафик и передают украденную информацию
Украденную информация снова преобразуют в удобный для восприятия вид
Установленный туннель используют для передачи вредоносного ПО
Обратите внимание на скриншот - я запросил IP-адрес gismeteo.ru. В терминах технологии DNS, вы сделали запрос типа А (от слова Address). Типов подобных запросов существует несколько, и чуть ниже я попробую это продемонстрировать.
В любом случае, под капотом у DNS работает простая схема клиентский запрос на сервер, который в свою очередь отвечает клиенту обратно. А что если можно было бы "зашить" сообщение внутрь запроса?
Представьте себе, что хакеры контролируют DNS сервер: в таком случае, они смогут просто собирать всю нужную информацию без риска оказаться замеченными. Опять же - как DNS запрос может быть нелегитимным? Все привыкли к тому, что эта служба работает всегда и не несет никакой угрозы. Но если служба оказалась скомпрометированной, злоумышленники могут фальсифицировать запросы и использовать информацию, скрытую в различных полях ответных пакетов для контроля вредоносного ПО на компьютере жертвы.
Самая интересная часть - это туннелирование, то есть маскировка информации и передаваемых команд. Делается это, очевидно для того, чтобы подобный трафик прошел незамеченным мимо защитных систем и ПО. Для маскировки используются base32, base 64, а порой и полноценное шифрование.
Base32 и Base64 - это способы кодировки информации используя 32 символа и 64 соответственно. Суть данного упражнении в передаче любой информации в текстовом виде.У обоих методов есть минусы - Base32 код оказывается в 1,6 раза больше оригинальной информации, а Base64 - регистрозависим.
Когда возник данный тип атак?
Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года.
Далее в 2004 на ежегодной конференции Black Hat была представлена подробная техника - то есть буквально руководство по использованию данной атаки. Шло время и данный тип атак становился все популярнее - сегодня этот механизм встроен буквально в каждый вирус-шифровальщик.
Попробуйте погуглить словосочетание Sea Turtle - это все еще активная кампания, целью которой является взлом легитимных DNS серверов для перенаправления запросов на свои собственные сервера. То есть злоумышленники смогут отвечать на эти запросы ложными сайтами. К примеру пользователь будет пытаться зайти на Facebook или свой аккаунт Ozon, но на самом деле это будут копии страниц, созданные для перехвата пользовательской информации. Честно говоря, такой тип атак не имеет ничего общего с туннелированием DNS, но вектор атаки остается тем же. И представьте себе последствия от украденных учетных данных - лично я бы не хотел, что злоумышленники получили доступ к моим аккаунт в онлайн банках и социальных сетях.
Основные опасности DNS туннелирования
Как вы уже могли понять из моей спутанной и слегка аутичной статьи, DNS туннелирование является механизмом, который является катализатором для различного вида неприятностей, а именно:
Утечка данных: злоумышленники используют DNS для банального вывода текстовой информации с помощью определенной маскировки. Объемы вывода небольшие, но порой много и не требуется - к примеру, данные паспорта улетят очень быстро;
Удаленный контроль: злоумышленники отправляют различные команды через DNS, к примеру для управления RAT-ами (троянами с удаленным управлением). К слову, большое количество шифровальщиков именно так получают свои инструкции и ключи шифрования;
IP-Over-DNS туннелирование: сейчас уже можно найти специальные утилиты, в которых IP стэк имплементирован в клиент-серверную модель работы DNS. То есть такие утилиты позволяют относительно просто передавать информацию используя стандартные штуки вроде FTP, Netcat, ssh и пр. То есть через DNS можно будет передать буквально любую информацию
Техники детектирования DNS - туннелирования
Существует два основных метода по обнаружения некорректного использования DNS службы: анализ трафика и анализ полезной нагрузки.
При анализе полезной нагрузке необходимо обращать внимание на странные и аномальные запросы, особенно если они содержат в себе странные доменные имена, странные символы и пр. Для выявления подобного используются различные статистические техники.
В свою очередь, при анализе трафика, нужно обращать внимание на общее количество запросов к домену и сравнивать это число со средними значениями. Хакеры, осуществляющие DNS туннелирование, будут создавать большой объем DNS трафика - что сразу должно вызвать подозрения, так как отличия в объемах будут буквально на порядки.
Утилиты для создания DNS туннеля:
Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак.
Iodine: данная утилита доступна на большинстве платформ (Linux, Mac OS, Windows, FreeBSD) и позволяет установить SSH туннель между целью и вашим компьютером. Утилита не самая простая, когда-нибудь мы напишем статью чс примером ее использования;
OzymanDNS: функционал схож с Iodine, то есть утилита также позволяет строить SSH туннель. Интересно то, что это проект целиком и полностью написан на Perl;
DNSCat2: многофункциональный комбайн, который создает зашифрованный канал для управления (C2) и позволяет скачивать/загружать файлы, запускать cmd/powershell и пр.
Утилиты для мониторинга DNS туннеля:
dnsHunter: модуль на питоне, написанный для Mercenary-Linux. Данный модуль читает .pcap файлы, выделяет из них DNS-запросы и осуществляет геолукапы, что также может помочь при расследовании;
reassemble_dns: также утилита, написанная на питоне, которая позволяет читать .pcap файлы и реконструировать DNS запросы;
Раньше, когда хабы еще находили применение в архитектуре сетей, анализировать трафик было очень просто. Достаточно было подключить компьютер со специальным ПО к одному из портов хаба и мы получали каждый пакет, передающийся по сети. Теперь, когда хабы не используются, а коммутаторы отправляют пакеты только на определенный порт, анализ трафика усложнился.
Однако, большинство вендоров уже давно решили эту проблему, разработав механизмы “зеркалирования” трафика. Примерами таких механизмов являются SPAN(Switch Port Analyzer) и RSPAN (Remote Switch Port Analyzer), которые используются в оборудовании Cisco Systems. Не стоит путать SPAN/RSPAN с STP (Spanning Tree Protocol) и RSTP (Rapid Spanning Tree Protocol). Несмотря на то, что оба эти протокола работают на канальном уровне модели TCP/IP, служат они совершенно разным целям.
Технологии “зеркалирования” трафика, к которым относятся SPAN и RSPAN, позволяют настроить коммутатор так, чтобы все пакеты, приходящие на один порт или группу портов коммутатора, дублировались на другом, с целью их дальнейшего анализа и мониторинга.
Нет времени объяснять!
Торопитесь? Нет времени читать матчасть? Прыгайте по ссылке ниже, тут настройка!
Пример настройки
Теория
Как можно догадаться, функциональность SPAN’а ограничена пределами только одного устройства.
Для того, что бы SPAN заработал необходимо настроить следующее:
Источник (Source). То есть откуда брать трафик для анализа.
Здесь можно указать порт коммутатора, работающий в режиме access, trunk и etherchannel, группу портов, т.е VLAN или L3 порт.
Стоит отметить, что при указании в качестве источника определенного VLAN, будет дублироваться трафик со всех портов, которые в него входят. При добавлении или исключении порта из VLAN это сразу повлияет на SPAN.
Получатель (Destination).
Здесь указывается тот порт, куда будет “зеркалироваться” трафик.
Стоит отметить, что по умолчанию будет дублироваться весь трафик, который проходит через источник. Однако, можно сконфигурировать SPAN так, чтобы отслеживались только входящие или исходящие пакеты. Пример коммутатора с настроенным SPAN приведен ниже:
Как видно из рисунка, SPAN может отслеживать только трафик проходящий через коммутатор, на котором он настроен непосредственно.
Remote SPAN (RSPAN) же позволяет производить мониторинг трафика на физически удаленных портах, через сеть коммутаторов.
Источником трафика при настройке RSPAN являются source порты, входящие в специальный RSPAN VLAN, который задается специально для каждой RSPAN – сессии. Фреймы, передающиеся в этой сессии затем, проходят процедуру тегирования по протоколу 802.1q для передачи через другие устройства, находящиеся в сети. Добравшись до коммутатора, содержащего destination порт для данной RSPAN - сессии, трафик просто зеркалируется на указанный destination порт.
Ниже приведен типовой пример сети с настроенным RSPAN:
При настройке SPAN/RSPAN должны соблюдаться следующие условия:
На одном коммутаторе может быть максимально сконфигурировано 64 destination порта
Source порт не может быть destination портом и наоборот
Для каждой SPAN/RSPAN – сессии может быть только один порт destination
При объявлении порта как destination, он может только принимать “зеркалированный” трафик, остальные функции канального уровня становятся для него недоступными
При объявлении порта, работающего в режиме switchport trunk, как source порта, трафик всех VLAN’ов, проходящих через данный порт будет отслеживаться
Если в качестве источника указан VLAN, то трафик из другого VLAN’а, настроенного на коммутаторе не попадет в SPAN
По умолчанию на destination порт не отслеживается и не передается трафик следующих протоколов, работающих на канальном уровне: CDP (Cisco Discovery Protocol), STP (Spanning Tree Protocol), (VTP) VLAN Trunking Protocol, (DTP) Dynamic Trunk Protocol и (PAgP) Port Aggregation Protocol