Ребята и девчата, а можно все-таки хоть немного подробностей про самописный DNS-сервер? За счет чего такая производительность, более-менее подробные условия и результаты perfomance-тестов?
Цифра 3M qps, да еще и на ядро (подразумевается же, что она масштабируется при росте количества ядер линейно или близко к этому?) — очень серьезно для того, чтобы поверить на слово. Knot, pdns и остальные дают в лучшем случае сотни тысяч qps, и не на одном ядре.
И да, в тред призывается Александр flx Лямин, который в прошлом году на PhD рассказывал про ~15M pps на 16 (если не путаю) ядрах как про серьезное достижение. А тут получается минимум 6M pps (если сложить входящий и исходящий), да еще на одно ядро, да еще и с обработкой в user space. За год многое поменялось и теперь другие ориентиры?
NOD отдает новые, ранее неизвестные домены. Фильтровать их в DNS только потому, что они новые — не очень разумно.
У Virus Tracker нет выдачи в RPZ. У него есть API для доступа к данным (правда, только на двух верхних тарифах), с помощью которого можно получать сырые данные и на основании их формировать политики фильтрации в том виде, в котором это удобнее вашему инструменту.
Спасибо за статью!
Рад, что Вы не бросили эксперимент. На Хабре очень мало практики по этой теме.
Несколько вопросов/комментариев:
1) В схеме с fast-flux первый уровень (те узлы, которые крутятся round-robin'ом в A-записях) — всегда proxy до moshership-сервера. В простейшем варианте DNS для такого домена работает на abuse-устойчивом DNS-хостинге. Это называется single-flux. Случай посложнее — double-flux, когда и DNS для домена обслуживают боты (точнее, проксируют на mothership). В этом случае round-robin'ом крутятся еще и NS-записи.
2) FarSight Security не дают в явном виде фид для блокировки ботнетов. Их Security Information Exchange — сервис не для операторов DNS, а скорее для сервис-провайдеров услуг безопасности, которым нужны «сырые» данные DNS для анализа. Для того, чтобы подключиться к SIE, нужно поставить свою железку в дата-центр FarSight в Калифорнии или Вирджинии. А вот, например, Virus Tracker для операторов DNS гораздо удобнее. Им пользуется Яндекс.DNS для фильтрации ботнет-активности.
3) С утверждением
Активность botnet-агентов может приводить к значительному росту нагрузки на кэширующий DNS и канал связи
готов согласиться только в контексте «Атаки с использованием техники DNS amplification, реализуемые через ботнет-сети, могут приводить ...» :) Просто все, чтобы было выше этой фразы, касалось управления ботами и пресечения каналов связи с C&C-серверами. Эта «активность» ботов не дает большой нагрузки. Вот, например, статистика Яндекса: «Каждый день Яндекс.DNS обрабатывает около семи миллиардов запросов, из них примерно 1,9 миллиона отправляют боты.» 0,03% — это капля в море с точки зрения нагрузки (даже с учетом того, что большая часть этих запросов не попадает в кэш).
4) В своей предыдущей статье Вы утверждали, что скорее всего атака, которую Вы обнаружили, идет на DNS-сервера этих самых доменов (webpanel.sk, energystar.gov и doleta.gov). И хотя я с этим выводом не согласен (считаю, как минимум 2 из 3 доменов скорее всего использовались для усиления и отражения атаки на другие жертвы), не могу не отметить непоследовательность Ваших действий — если целью атакующего была недоступность ресурсов, которые обслуживают эти DNS-сервера, то включенная Вами фильтрация означает, что атакующий своих целей достиг. Хотя бы на небольшом участке фронта в лице Вашего DNS-сервера :)
Ну и напоследок — пожелание. Понятно, что ручная правка RPZ-зон — не вариант. Было бы здорово увидеть практику работы с каким-либо из перечисленнных в статье DNSBL-сервисов — процесс подключения к услуге, настройка, статистика по результатам использования.
В этом случае такая запись появилась бы в ловушке сто раз за день (и много раз больше за 3 месяца) и никак не могла бы считаться однодневкой.
Но я понял Вашу идею. Думаю, что количество редко подключающихся VPN-пользователей не настолько велико, чтобы дать существенную погрешность в измерениях. В отчете речь идет о сотнях миллионов таких имен.
Перечитал еще раз — да, Вы правы в части смешения понятий. Постарался исправить. Заодно и название поправил, хотя тут я с самого начала старался сделать его нейтральным, без желтизны. Наверное, плохо получилось :)
Раздельной статистики по доменам разного уровня, увы, нет.
Да, многие предлагают схему подтверждения через создание субдомена, но не думаю, что количество таких доменов могло серьезно повлиять на статистику. Речь ведь о сотнях миллионов уникальных доменов, обнаруженных за 3 месяца.
P.S.: Кстати, говоря про Яндекс.DNS, я подразумевал не DNS-хостинг от Яндекса, а Яндекс.DNS — публичный рекурсивный DNS-сервис.
SecurID запоминает использованные пароли. Повторно использовать его уже нельзя, даже если еще не прошла минута. Просто перехват ничего не даст, нужен mitm. Впрочем, от всего этого помогает SSL.
Мммм… даже и не знаю, что посоветовать. Термин этот я встретил впервые в документации на RSA SecurID, но она, по-моему, не доступна публично.
Если на пальцах, то работает это примерно так:
Дано:
а) У сервера есть константа N, задающая допустимые отклонения порядкового комера токенкода от текущего значения. Например, N=2. Если введенный пользователем токенкод попадает в +-N, то аутентификация считается успешной
б) У сервера есть константа L, на глубину которой он просчитывает токенкоды аккаунта. Если введенный пользователем токенкод не попадает в +-L, то аутентификация считается неуспешной. Например, L=20.
1) Количество неуспешних аутентификаций для аккаунта превысило допустимый предел. Cервер активирует для него флаг «режим next-tokencode», подозревая брутфорс или серьезную рассинхронизацию.
2) Сервер внезапно получает tokencode, попадающий в +-L и понимает — возможно, это наконец-то настоящий владелец аккаунта.
3) Чтобы убедиться наверняка, он подстраивает счетчик под найденное значение и просит пользователя сгенерировать и ввести следующий один код (next tokencode). Если и этот совпадает — ура, это хозяин!
Это, конечно, немного поверхностно и сумбурно, но, надеюсь, общая идея понятна.
Не нужна кнопка 3). Любой tokencode считается введенным. Единичные ошибки легко отсекаются небольшой модификацией алгоритма — принимать не только текущий код, но и плюс-минус N-ый (N-небольшое число, например 2). Если в эти границы tokencode не укладывается — считать попытку аутентификации неуспешной и после нескольких таких попыток включать режим next-tokencode.
Да, нажимать на кнопку. Смартфон тоже будет считать количество генераций tokencode. В случае несовпадения счетчика на сервере и смартфоне — включать режим next-tokencode (просить пользователя ввести два подряд сгенерированных кода, пропускать только в том случае, если оба совпали).
И почему вы реализовали HOTP как time-based OTP, тогда как в оригинале он event-based? Понятно, что криминала тут особого нет, но ведь сложность дополнительная — часы у клиента и сервера должны быть синхронизированы (до секунды, если я правильно прочитал код).
1) Процент от какой цены все-таки получает процент автор: от отпускной цены издательства или от «магазинной» цены? В тексте вроде бы четко сказано, что от отпускной, но цифры в примере ниже смущают — если отпускная цена 300р, то сколько же такая книга будет стоить в магазине?
2) Не запрещает ли автору договор с издательством распространять текст книги за деньги другим способом (например, через прямые продажи электронной версии со своего сайта)?
Число комбинаций для 5-символьного числового пароля 10^5, а не 5^10, разве нет? И со вторым примером та же история.
Цифра 3M qps, да еще и на ядро (подразумевается же, что она масштабируется при росте количества ядер линейно или близко к этому?) — очень серьезно для того, чтобы поверить на слово. Knot, pdns и остальные дают в лучшем случае сотни тысяч qps, и не на одном ядре.
И да, в тред призывается Александр flx Лямин, который в прошлом году на PhD рассказывал про ~15M pps на 16 (если не путаю) ядрах как про серьезное достижение. А тут получается минимум 6M pps (если сложить входящий и исходящий), да еще на одно ядро, да еще и с обработкой в user space. За год многое поменялось и теперь другие ориентиры?
У Virus Tracker нет выдачи в RPZ. У него есть API для доступа к данным (правда, только на двух верхних тарифах), с помощью которого можно получать сырые данные и на основании их формировать политики фильтрации в том виде, в котором это удобнее вашему инструменту.
Рад, что Вы не бросили эксперимент. На Хабре очень мало практики по этой теме.
Несколько вопросов/комментариев:
1) В схеме с fast-flux первый уровень (те узлы, которые крутятся round-robin'ом в A-записях) — всегда proxy до moshership-сервера. В простейшем варианте DNS для такого домена работает на abuse-устойчивом DNS-хостинге. Это называется single-flux. Случай посложнее — double-flux, когда и DNS для домена обслуживают боты (точнее, проксируют на mothership). В этом случае round-robin'ом крутятся еще и NS-записи.
2) FarSight Security не дают в явном виде фид для блокировки ботнетов. Их Security Information Exchange — сервис не для операторов DNS, а скорее для сервис-провайдеров услуг безопасности, которым нужны «сырые» данные DNS для анализа. Для того, чтобы подключиться к SIE, нужно поставить свою железку в дата-центр FarSight в Калифорнии или Вирджинии. А вот, например, Virus Tracker для операторов DNS гораздо удобнее. Им пользуется Яндекс.DNS для фильтрации ботнет-активности.
3) С утверждением готов согласиться только в контексте «Атаки с использованием техники DNS amplification, реализуемые через ботнет-сети, могут приводить ...» :) Просто все, чтобы было выше этой фразы, касалось управления ботами и пресечения каналов связи с C&C-серверами. Эта «активность» ботов не дает большой нагрузки. Вот, например, статистика Яндекса: «Каждый день Яндекс.DNS обрабатывает около семи миллиардов запросов, из них примерно 1,9 миллиона отправляют боты.» 0,03% — это капля в море с точки зрения нагрузки (даже с учетом того, что большая часть этих запросов не попадает в кэш).
4) В своей предыдущей статье Вы утверждали, что скорее всего атака, которую Вы обнаружили, идет на DNS-сервера этих самых доменов (webpanel.sk, energystar.gov и doleta.gov). И хотя я с этим выводом не согласен (считаю, как минимум 2 из 3 доменов скорее всего использовались для усиления и отражения атаки на другие жертвы), не могу не отметить непоследовательность Ваших действий — если целью атакующего была недоступность ресурсов, которые обслуживают эти DNS-сервера, то включенная Вами фильтрация означает, что атакующий своих целей достиг. Хотя бы на небольшом участке фронта в лице Вашего DNS-сервера :)
Ну и напоследок — пожелание. Понятно, что ручная правка RPZ-зон — не вариант. Было бы здорово увидеть практику работы с каким-либо из перечисленнных в статье DNSBL-сервисов — процесс подключения к услуге, настройка, статистика по результатам использования.
Но я понял Вашу идею. Думаю, что количество редко подключающихся VPN-пользователей не настолько велико, чтобы дать существенную погрешность в измерениях. В отчете речь идет о сотнях миллионов таких имен.
Да, многие предлагают схему подтверждения через создание субдомена, но не думаю, что количество таких доменов могло серьезно повлиять на статистику. Речь ведь о сотнях миллионов уникальных доменов, обнаруженных за 3 месяца.
P.S.: Кстати, говоря про Яндекс.DNS, я подразумевал не DNS-хостинг от Яндекса, а Яндекс.DNS — публичный рекурсивный DNS-сервис.
Подскажите, а сертификат ФСБ у этого «openssl с поддержкой российкой криптографии» есть? Если да — был бы признателен за ссылку на него.
Если на пальцах, то работает это примерно так:
Дано:
а) У сервера есть константа N, задающая допустимые отклонения порядкового комера токенкода от текущего значения. Например, N=2. Если введенный пользователем токенкод попадает в +-N, то аутентификация считается успешной
б) У сервера есть константа L, на глубину которой он просчитывает токенкоды аккаунта. Если введенный пользователем токенкод не попадает в +-L, то аутентификация считается неуспешной. Например, L=20.
1) Количество неуспешних аутентификаций для аккаунта превысило допустимый предел. Cервер активирует для него флаг «режим next-tokencode», подозревая брутфорс или серьезную рассинхронизацию.
2) Сервер внезапно получает tokencode, попадающий в +-L и понимает — возможно, это наконец-то настоящий владелец аккаунта.
3) Чтобы убедиться наверняка, он подстраивает счетчик под найденное значение и просит пользователя сгенерировать и ввести следующий один код (next tokencode). Если и этот совпадает — ура, это хозяин!
Это, конечно, немного поверхностно и сумбурно, но, надеюсь, общая идея понятна.
Если не трудно — два вопроса:
1) Процент от какой цены все-таки получает процент автор: от отпускной цены издательства или от «магазинной» цены? В тексте вроде бы четко сказано, что от отпускной, но цифры в примере ниже смущают — если отпускная цена 300р, то сколько же такая книга будет стоить в магазине?
2) Не запрещает ли автору договор с издательством распространять текст книги за деньги другим способом (например, через прямые продажи электронной версии со своего сайта)?