Спасибо за подробный ответ. Фактически pxGrid вы используете только для взаимодействия м/у продуктами Cisco.
По поводу «сторонние вендоры начинают поддерживать интеграцию» я не соглашусь. На самом деле существуют интеграции которые работают довольно давно (например, у нас она вышла 2.5 года назад), но так как платформа относительно закрытая, то большого интереса в этом нет.
В этом плане OpenDXL (изначально McAfee DXL) мне кажется более ориентированным на сторонние разработки.
Чтобы мир стал чище, нужно повсеместно применять bcp38 и очень желательно закрывать открытые рекурсивные DNS у обычных пользователей.
Запросы ANY на авторитативных серверах, если они не возвращают больших ответов (нет DNSSEC) в основном безвредны (ибо используют их для Amplification/Reflection).
Запросы ANY для своих клиентов — rate limit. Более одного запроса в секунду обычно не требуется, хотя можно и увеличить интервал.
Для внешних клиентов кэш вообще не должен отвечать (криворукие ISP — можно отнести к разряду клиентов)
1. Это естественно плохо. Но ставить открытый для всех рекурсивный DNS намного хуже.
2. Это generic DNS сервер, который может делать и авторитативку и кэш. При этом на кэше есть хорошие фитчи типа RPZ.
3. В таком случае нужно прикрываться ACL и постепенно переводить данных клиентов на правильные настройки. Как найти клиентов — query.log в помощь.
Если вы делаете резольвер, перестаньте отвечать на запросы ANY потому, что это вид запроса, который на самом деле толком не стандартизован и используется на 99% всякими замечательными вирусами.
Статья больше похоже на brain dump — отрывочные сведения по настройке DNS серверов.
— иметь свой собственный DNS можно даже дома. Если нет сервера или подходящего маршрутизатора, то его можно поднять на raspberry Pi. Одно из применений дома — резать рекламу и well know bad domains, например с использованием RPZ;
— держать открытый рекурсивный DNS сервис в интернет — плохо и для большинства случаев это не нужно;
— не упомянуты ACL на уровне DNS. В особенности для bind это важно, когда один сервер является авторитативным и рекурсивным;
— запросы ANY бывают полезны для админов и лучше делать rate limit на них, чем совсем резать;
— rate limit можно настраивать на уровне DNS (в частности в bind).
PS «резольвер» — ужастный термин, хоть и короткий.
1. Да, вполне логично. Просто цена за такую аренду будет выше. IP-адреса никому передавать не надо. Клиент платит не за IP, а за атаку. Все сети европейских провайдеров есть в БД RIPE, которая находится в свободном доступе. Владелец сети ботнет 100% знает какие провайдеры заражены.
2. Когда botnet/malware ищет командный центр, имхо, светиться ему никакого смысла нет. 1 запрос в 2-3 секунды будут маловаты для проведения атаки (конечно если в сети провайдера не тысяча таких зловредов). В собранном трафике (это были часы средней нагрузки) за 5 минут было обнаружено от 30 до 80 атакующих IP (в разных pcap по разному).
Зачем — цели могут быть разные, начиная с того, что нужно навредить клиентам этого провайдера (по услугам Internet, хостинг, хостин DNS) и заканчивая общим вредом инфраструктуре провадера (обиженный клиент, сотрудник, конкурент).
Я знаю пример, когда студент (дело было в Штатах) не хотел сдавать экзамен и поэтому организовывал атаку (арендовал ботнет) на сеть колледжа.
Когда пытаются отравить кэш, то делают это на уровне организации/провайдера. Каждому конкретному клиенту (если это не целенаправленная жертва) смысла отравлять кэш нет, так как требуется много ресурсов.
По поводу заказа конкурентов — труда не много:
1. Сеть ботнетов для проведения атаки арендуется достаточно дешево. Вот пример по стоимости аренды сети botnet (цены указаны на 2013): www.havocscope.com/how-to-ddos-by-renting-botnet/
The price to rent 1,000 infected computers in the United States costs $180. If the hosts are located in the United Kingdom, the price is $240. France and Russia both costs $200, Canada costs $270, and 1,000 infected computers located around the world costs $35. There is a daily limit of 20,000 hosts.
2. На устройствах клиентов оператора помимо дыры с открытым ресолвером может быть настроен forwarding — запросов на сервер провайдера (проверить достаточно просто, послав запрос на свой DNS). Просканировать сети операторов на открытые ресолверы дело нескольких минут/десятков минут;
3. Провести «вирусную» акцию например, попросить установить «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара). Есть на эту тему исследование «An empirical study on incentivizing users to ignore security advice»
Стандартные настройки bind 9.10 — 1000 исходящих запросов в секунду и время таймаута 10 секунд (кол-во исходящих запросов можно увеличить, таймаут уменьшить нельзя). То есть чтобы забить все исходящие соединения нам нужно генерировать по 100 запросов в секунду всего. Кол-во запросов в секунду от каждого бота в принципе не важно, но чем больше будет зараженных систем, тем сложнее их отсечь на уровне query rate limit. Я посмотрел в одном pcap (атака была на минимальном уровне), каждый зараженный компьютер генерировал около 5 паразитных запросов в секунду
Из open source DNS серверов я не знаю, кто может это делать автоматом.
Допилить можно 2-мя способами:
1. в bind есть блок, который отвечает за мониторинг запросов (параметры конфигурации clients-per-query, max-clients-per-query). По умолчанию для статистики рассматриваются FQDN. То есть этот блок нужно допилить так, чтобы статистика ещё считалась по доменам 2-го и 3-го уровня. Для других open source думаю так же можно найти подходящее место для анализа и статистики;
2. автоматизировать процесс анализа запросов и статистики, если, конечно, QPS не очень большой. Например, сервер DNS может отправлять лог-файлы через syslog (как внутри системы, так и на внешний сервер), которые будут сохранятся в БД и периодически (раз в минуту анализироваться). При большей нагрузке (сказать сложно какой именно) можно вешать свою программу на обработку входящего сислог. Если от дополнительной нагрузки (от syslog) у нас перестал справляться DNS, то смотрим пункт 1 :)
Reflection атака (эффективна в сочетании с Amplification) нацелена на определенный IP (сайт, сервер). Этот IP может находится в пределах сети ISP или за её пределами. DNS-запросы поступают от клиентов этого ISP. Проблемы начинаются тогда, когда оператор не контролирует какие пакеты уходят из его сети/сегментов сети, то есть атакующий может заспуфить IP и его кэш начнет отвечать на адрес 8.8.8.8, который нашей сети не принадлежит.
Весной 2013 года проходила конференция Yandex, где приводились цифры, что 25% провайдеров (или сетей, уже не помню) не контролируют исходящие пакеты из своей сети.
Дополнительные угрозы состоят в том, что клиенты оператора не всегда защищают свои устройства предоставляющие услуги DNS (например маршрутизаторы). Осенью я сканировал /16 своего провайдера и обнаружил в ней 70 открытых рекурсивных DNS серверов (доступность из внешнего мира я проверял со своего сервера в Германии).
Цели могут быть разные начиная от заказа конкурентов и заканчивая общей политической ситуацией, когда атакуют всех.
По поводу cache poisoning, на первый взгляд задача не упрощается (для атаки используются левые домены), так как помимо атакующих запросов остаются все остальные запросы.
Если для атаки используется какой-то легитимный домен, то тут уже можно рассматривать и cache poisoning и NXDomain атаку на авторитативный сервер.
Иван, эти атаки как раз и идут от клиентов провайдера. Такие клиенты обычно заражены всякой дрянью (даже корпоративщики).
То что кэш нужно закрывать от внешних клиентов это истина, которую в принципе не нужно объяснять.
Ссылка в тексте на открытый ресолвер была приведена для того, что показать, что набор портов, которые использует malware — невелик.
Какое используется ПО — не важно, все подвержены атаке, пороги просто будут другие.
Удивительно, что народ так мало знает про SNMP про SNMP Trap'ы в частности. В особенности поражают фразы про крупицы знаний и «больше интересных функций на ftp Cisco». Информации навалом, даже на хабре есть куча статей о применении SNMP.
BTW MIB-файлы устанавливать совершенно не обязательно, главное знать правильные OIDы.
BTW MTV на автобусах Гугловских написано, которые сотрудников развозят.
По поводу «сторонние вендоры начинают поддерживать интеграцию» я не соглашусь. На самом деле существуют интеграции которые работают довольно давно (например, у нас она вышла 2.5 года назад), но так как платформа относительно закрытая, то большого интереса в этом нет.
В этом плане OpenDXL (изначально McAfee DXL) мне кажется более ориентированным на сторонние разработки.
И если да, то с какими?
Запросы ANY на авторитативных серверах, если они не возвращают больших ответов (нет DNSSEC) в основном безвредны (ибо используют их для Amplification/Reflection).
Запросы ANY для своих клиентов — rate limit. Более одного запроса в секунду обычно не требуется, хотя можно и увеличить интервал.
Для внешних клиентов кэш вообще не должен отвечать (криворукие ISP — можно отнести к разряду клиентов)
2. Это generic DNS сервер, который может делать и авторитативку и кэш. При этом на кэше есть хорошие фитчи типа RPZ.
3. В таком случае нужно прикрываться ACL и постепенно переводить данных клиентов на правильные настройки. Как найти клиентов — query.log в помощь.
Запрос ANY прекрасно описан в rfc1035:
— иметь свой собственный DNS можно даже дома. Если нет сервера или подходящего маршрутизатора, то его можно поднять на raspberry Pi. Одно из применений дома — резать рекламу и well know bad domains, например с использованием RPZ;
— держать открытый рекурсивный DNS сервис в интернет — плохо и для большинства случаев это не нужно;
— не упомянуты ACL на уровне DNS. В особенности для bind это важно, когда один сервер является авторитативным и рекурсивным;
— запросы ANY бывают полезны для админов и лучше делать rate limit на них, чем совсем резать;
— rate limit можно настраивать на уровне DNS (в частности в bind).
PS «резольвер» — ужастный термин, хоть и короткий.
2. Когда botnet/malware ищет командный центр, имхо, светиться ему никакого смысла нет. 1 запрос в 2-3 секунды будут маловаты для проведения атаки (конечно если в сети провайдера не тысяча таких зловредов). В собранном трафике (это были часы средней нагрузки) за 5 минут было обнаружено от 30 до 80 атакующих IP (в разных pcap по разному).
Я знаю пример, когда студент (дело было в Штатах) не хотел сдавать экзамен и поэтому организовывал атаку (арендовал ботнет) на сеть колледжа.
По поводу заказа конкурентов — труда не много:
1. Сеть ботнетов для проведения атаки арендуется достаточно дешево. Вот пример по стоимости аренды сети botnet (цены указаны на 2013):
www.havocscope.com/how-to-ddos-by-renting-botnet/
2. На устройствах клиентов оператора помимо дыры с открытым ресолвером может быть настроен forwarding — запросов на сервер провайдера (проверить достаточно просто, послав запрос на свой DNS). Просканировать сети операторов на открытые ресолверы дело нескольких минут/десятков минут;
3. Провести «вирусную» акцию например, попросить установить «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара). Есть на эту тему исследование «An empirical study on incentivizing users to ignore security advice»
Стандартные настройки bind 9.10 — 1000 исходящих запросов в секунду и время таймаута 10 секунд (кол-во исходящих запросов можно увеличить, таймаут уменьшить нельзя). То есть чтобы забить все исходящие соединения нам нужно генерировать по 100 запросов в секунду всего. Кол-во запросов в секунду от каждого бота в принципе не важно, но чем больше будет зараженных систем, тем сложнее их отсечь на уровне query rate limit. Я посмотрел в одном pcap (атака была на минимальном уровне), каждый зараженный компьютер генерировал около 5 паразитных запросов в секунду
Reflection только внутри сети, acl нужно и на кэше прописывать.
Допилить можно 2-мя способами:
1. в bind есть блок, который отвечает за мониторинг запросов (параметры конфигурации clients-per-query, max-clients-per-query). По умолчанию для статистики рассматриваются FQDN. То есть этот блок нужно допилить так, чтобы статистика ещё считалась по доменам 2-го и 3-го уровня. Для других open source думаю так же можно найти подходящее место для анализа и статистики;
2. автоматизировать процесс анализа запросов и статистики, если, конечно, QPS не очень большой. Например, сервер DNS может отправлять лог-файлы через syslog (как внутри системы, так и на внешний сервер), которые будут сохранятся в БД и периодически (раз в минуту анализироваться). При большей нагрузке (сказать сложно какой именно) можно вешать свою программу на обработку входящего сислог. Если от дополнительной нагрузки (от syslog) у нас перестал справляться DNS, то смотрим пункт 1 :)
Весной 2013 года проходила конференция Yandex, где приводились цифры, что 25% провайдеров (или сетей, уже не помню) не контролируют исходящие пакеты из своей сети.
Дополнительные угрозы состоят в том, что клиенты оператора не всегда защищают свои устройства предоставляющие услуги DNS (например маршрутизаторы). Осенью я сканировал /16 своего провайдера и обнаружил в ней 70 открытых рекурсивных DNS серверов (доступность из внешнего мира я проверял со своего сервера в Германии).
По поводу cache poisoning, на первый взгляд задача не упрощается (для атаки используются левые домены), так как помимо атакующих запросов остаются все остальные запросы.
Если для атаки используется какой-то легитимный домен, то тут уже можно рассматривать и cache poisoning и NXDomain атаку на авторитативный сервер.
То что кэш нужно закрывать от внешних клиентов это истина, которую в принципе не нужно объяснять.
Ссылка в тексте на открытый ресолвер была приведена для того, что показать, что набор портов, которые использует malware — невелик.
Какое используется ПО — не важно, все подвержены атаке, пороги просто будут другие.
Радуйтесь, что не заминусовали :)
BTW MIB-файлы устанавливать совершенно не обязательно, главное знать правильные OIDы.