Обновить
13
0

Пользователь

Отправить сообщение
На Apple TV постоянно всё отваливалось, так что подконец она зависла :)
Китайский перевод шел только на РФ (или МСК).
Я подключался через свой сервер в Германии — тормозов и обвалов было меньше + косяков с китайским переводом не было.
Из статьи непонятно:
1. Косяк был только с UDP портом на который передавались сообщения, SNMP Trap пакет в остальном был полностью правильным?
2. Настроить порт на который передавался было не возможно? Вы не пытались настроить сервер, чтобы он слушал на другом порту?
3. Производитель предоставляет MIB? Вы пытались разобрать что находится в той самой бинарной части, которую вы просто отрезали (там могла быть дополнительная интересная информация, например: timestamp, ID-порта, его предыдущее состояние и т.д.)?
Спасибо за разъяснения. FarSight — удалю.
Акадо много лет блокирует и по шапке ещё не получила (сервис как был закрыт, так и остается закрыт).
На маршрутизаторе стоковая прошивка, поменять нет возможности.
А большинство пользователей вообще не знаю что это такое :)
По поводу FarSight Security я имел в виду NOD, вот описание с их сайта:
NOD is also published in DNSBL and RPZ formats. Many network defense products are directly capable of ingesting and acting upon policy information in the supported «rbldnsd» format (for NOD DNSBL) or in IETF «zone file format» (for NOD RPZ). Farsight updates our NOD distribution files very frequently owing to the importance of timeliness in this data feed. Customers are advised to check for updates once a minute, noting that «rsync» is extremely efficient and will use very little network bandwidth even when executed frequently. Note that Farsight expects to announce AXFR/IXFR/NOTIFY support for the NOD DNSBL and NOD RPZ distributions at a later time.
Я с ними не связывался, но предположил, что они дают свой RPZ.

По поводу Virus Tracker — не обнаружил ни слова про RPZ и описания алгоримов их работы. Может они предоставляют списки доступа для маршрутизаторов/файрволов?
Нет, я вообще не ограничиваю пользователей :) Но данная глава была как раз написана как для корпоративщиков, так и для операторов.
Я не думаю, что после этой статьи операторы блокирующие доступ по IP массово начнут переходить на использование RPZ.
Но если Вы настаиваете, то я могу перенести эту фразу «к корпоративной» части главы :)
К сожалению, в нашей стране всё работает именно так.
Поэтому большая часть мелких (а иногда и крупных) операторов не парится и блокирует всё по IP.
Спасибо. Тест мой ещё продолжается, надеюсь ещё будут интересные результаты :)
1) Я не против, просто для такой небольшой статьи не стал усложнять. Основная цель же была не рассказ про Fastflux. Полную ссылку с описанием забыл добавить :)
2) Спасибо. Ещё раз проверю.
3) Да. Это именно так и есть. Но если не будет коммуникаций с C&C, то и не будет атаки. И мне кажется, что статистика Яндекса тут менее интересна, по сравнению со статистикой операторов, так как на них приходит первый «удар».
Круглый стол от Яндекса в тему:
tech.yandex.ru/events/yac/2013/talks/1135/
4) По сравнению с предыдущей статьей я немного переосмыслил результаты :) Относительная нагрузка на мой сервер была небольшая до 5Мб/с (сервер имеет Гигабитный uplink), но с учетом того, что она выросла в 3 раза за несколько минут, я решил не дожидаться дальнейшего усиления атаки и рисковать отключением от Hetzner :)
Любую задачу можно разумным образом автоматизировать :)
А что обосновывать то? Если не заблокировать доступ, то половина пользователей себе пропишут 8.8.8.8 и администратор получит «по шапке».
Мы же обсуждаем варианты использования, а не методы их обхода :)
Они запрещены в РФ на законодательном уровне. Интернет-провайдеры обязаны блокировать доступ к ним.
Для маленьких операторов (у которых нет больших и жирных DPI) лучше их блокировать не на уровне IP (когда могут пострадать невинных несколько сайтов), а на уровне доменов с помощью RPZ, Proxy, DPI — вреда будет меньше.
Для провайдеров сайты попавшие в реестр eais.rkn.gov.ru/.
На корпоративном уровне (это каждая компания решает самостоятельно :), например, социальные сети.
Обычного администратора должна волновать производительность его сервера (комбинация железа и софта) — это можно сделать с помощью dnsperf.
А данное исследование нужно использовать для того что бы выбрать подходящий софт на этапе установки по производительности и фитчам.

PS Были бы данные — графики любые красивые нарисовать :)
Используя dnsperf можно протестировать производительность своего DNS-сервера, лучше это делать без полезной нагрузки :)
Я говорю немного о другом. Создавая любой продукт не возможно сразу оценить все аспекты легитимного и нелегитимного его использования. То что дыры могут не замечаться/не закрываться годами — это другой вопрос.
Надеюсь, эта статья донесет до продвинутых пользователей эту проблему. :)
Сразу сложно создать идеального сферического коня в вакууме :)
Пример — DNSSEC. Затыкали одну дыру, а получили другую :)
Вот вчерашний файл файл.
Формат: Client IP (DNS имя||Информация Whois) — Количество запросов.
За ночь пришло очень много запросов (т.е. атака усилилась).
И BTW, пока основная жертва это мой DNS :)
За прошедших 12 часов количество поступивших запросов удвоилось (то есть стало более миллиона), но при этом сервер выполнил всего около 4х тысяч рекурсивных запросов.
Как я написал в посте выше, определить жертву достаточно сложно. Фактически нужно «пробивать» какждый IP, смотреть какие потенциально интересные сервисы могут находится на данном сервере и в данной сети. И даже в этом случае нет 100% гарантии, что была найдена именно жертва.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность