LINUX.ORG.RU

Модуль HTTP rDNS для nginx

 ,


1

2

Российская компания «Флант» выпустила модуль для веб-сервера nginx, реализующий простой механизм контроля доступа по доменному имени клиента.

Модуль nginx-http-rdns расширяет возможности nginx возможностью преобразования IP-адреса клиента в доменное имя (с помощью rDNS-запроса) и создания простых списков контроля доступа (политики «разрешить» и «запретить») на основе полученного доменного имени. Может использоваться, например, в системах защиты от DDoS-атак (для обработки исключений по хостам поисковых машин и т.п.).

Исходный код опубликован под BSD, выложен на GitHub. Багрепорты и патчи приветствуются.

>>> Подробности

прикольно. осталось встроить какой-нибудь ЯП в конфигурационный файл и самостоятельно костылить новые возможности сервера. oh wai..

Spoofing ★★★★★ ()

Тут вспоминаются стоп-листы роскомнадзора.

anonymous ()

сразу вспомнилось «ударим онанизмом по проституции!». защита от ddos при помощи... reverse dns??? «дураков у нас на руси на сто лет припасено».

anonymous ()
Ответ на: комментарий от anonymous

хм годная идея, и деньги экономишь и жена без молочницы ходит

anonymous ()

Есть мнение, что dns lookup - самый простой способ помочь атакующим положить веб сервер

update. Посмотрел кто автор новости и пошёл читать код модуля. Может я чего-то не понимаю

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 2)

Что за маразм? DNS lookup как защита от DDoS, рукалицо...

anonymous ()

Есть реальный опыт успешного использования в годном production, поэтому «руколицующие» анонимусы всерьез не воспринимаются. Кроме того, никто не говорил ограничивать применение приведенным примером.

shurupov ★★ ()
Ответ на: комментарий от shurupov

Честно скажу, что прочёл описание модуля по диагонали. Возможно задам глупый вопрос. Как насчёт динамических списков доступа с хранением в базе?

imul ★★★★★ ()
Ответ на: комментарий от shurupov

опыт успешного использования

«•06.2010—10.2012: начальник отдела по разработке и сопровождению веб-ресурсов МИЭМ»

Я правильно понял, да? :)

Вообще, тут все абсолютно правы: использование данного модуля весьма сродни добровольной помощи ддосерам. Как в отношении собственно сайта, так и в отношении глобального DNSа на глупые запросы (как будто без вас его мало кто ДДоСит). Да и вообще - лишнее потребление ресурсов и траффика (очевидно, на кеширование распознанных имен... или... oh,shi... вы на каждый запрос IP сверяете с DNSом?).

Реализация доступа всё-равно осуществляется на уровне application, так зачем огород городить? Помимо крепостной стены еще и рвом. Водички, значит, туда налить и для пущего цимеса сточные воды и продукты жизнедеятельности туда же сливать.

Логи анализировать? Так куда проще при распарсивании на отдельном хосте IP преобразовать в DNS.

Вот серьёзно, ответьте на один простой вопрос: А ЗАЧЕМ?

slamd64 ★★★ ()
Ответ на: комментарий от slamd64

Ах, да... по поводу поисковиков и вообще секурности.

rDNS не имеет вообще никакого отношения к реальному DNSу. То есть, злоумышленник на какой-нибудь 99.99.99.99 вполне может прописать ответку www.linux.org.ru :)

По-сути, наивно доверяя rDNSу вы НАОБОРОТ снижаете защищенность вашей сети/сервера.

slamd64 ★★★ ()
Ответ на: комментарий от slamd64

Насчет реального DNS - есть double режим: сначала rDNS - получаем доменное имя, затем DNS - список ip, если исходный ip там есть - ip считается зарезолвленным.

Насчет доса dns серверов - модуль поддерживает работу под «if». Т.е. резолвинг можно включать только в определенных случаях.

Между прочим, в apache подобная функциональность тоже есть, называется HostnameLookups.

anonymous ()

А кэширование имен там есть? Чтобы лишний раз сервер имен не ронять.

thesis ★★★★★ ()
Ответ на: комментарий от slamd64

По-сути, наивно доверяя rDNSу

По сути, rDNS может спокойно жужжать в твоей же стойке и разруливать айпишники целых сетей в один адрес типа denied.chinahacker.cn.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

В nginx есть встроенный в core dns resolver с поддержкой кэширования.

anonymous ()
Ответ на: комментарий от anonymous

Это не снимает вопроса про сабжевый модуль.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Он работает через стандартный resolver. Т.е. кэширование есть.

anonymous ()
Ответ на: комментарий от anonymous

Дык ведь замечательно, если в самом деле так.

thesis ★★★★★ ()
Ответ на: комментарий от anonymous

сначала rDNS - получаем доменное имя, затем DNS - список ip, если исходный ip там есть - ip считается зарезолвленным

То есть, ДВА запроса... да еще и с вероятностью ложно-отрицательного срабатывания! Генитально!

Простой пример: обращаетесь к хосту по DNS-имени из одной страны - получаете один блок IP. Из другой страны - другой блок IP. На самом деле «основной» сервер расположен в третьей стране и обратная зона прописана как раз на этот IP. Опля.

В общем, глупость несусветная. Проще и разумнее вопрос доступа решать паролями-явками на уровне приложения и(или) http-авторизации.

slamd64 ★★★ ()
Ответ на: комментарий от slamd64

Да, еще вот...

Если же вспомнить VPSки и прочий говнохостинг, когда сотни сайтов висят на одном IP, но эти все заморочки с rDNS теряют всякий смысл абсолютно.

slamd64 ★★★ ()
Ответ на: комментарий от slamd64

Мир разный. Если для вас они теряют смысл, то это не означает, что так же происходит у других. Лучше эту свою энергию направить на создание проектов, которые имеют смысл для вас.

shurupov ★★ ()
Ответ на: комментарий от shurupov

Классика жанра: когда возразить нечего, переходим на личности. В данном случае - на псевдоглубокомысленное философствование.

slamd64 ★★★ ()
Ответ на: комментарий от thesis

Тогда следующий вопрос: нафига в таком случае rDNS, если проще добавить такие адреса в блэклист в самом nginx-е?

anonymous ()

фуфло. Бекрезолвы всегда пишутся такие как заказывает кастомер. А значит что там вполне может быть микрософт.ком. Более того, очень часто бекрезолв даже не резолвится...

Jetty ★★★★★ ()
Ответ на: комментарий от Jetty

Думаю, этот тип защиты предполагается использовать, чтобы отбивать волны зомби-хомяков с обратками вида dsl-XX-XX-XX-XX.rostelecom.cn

Правда, я не понимаю, как в таком случае планируется что-то кэшировать при таком количестве уникальных «посетителей».

anonymous ()
Ответ на: комментарий от anonymous

Хм... ну кешировать имо не нужно. А список «плохих» хостов можно всять из почтовых списков... но в чем профит такого подхода, мне совсем неочевидно...

Jetty ★★★★★ ()
Ответ на: комментарий от slamd64

Классика жанра: когда возразить нечего, переходим на личности. В данном случае - на псевдоглубокомысленное философствование.

Было бы на что возражать кроме вашего нежелания увидеть пользу в том, в чем другие уже видели. (К слову, беглый google по запросу функций такого модуля легко показывает, что потребность у людей есть.) У нас работает, нам помогает (для защиты от постоянного DDoS'а, в сочетании с тем же testcookie, с целью не забанить нужных ботов вроде поисковых машин). Если вы считаете, что делать что-то лучше другим способом — это ваше полное право, равно как и спорить об этом :-)

shurupov ★★ ()
Последнее исправление: shurupov (всего исправлений: 1)

А почему бы не использовать стандартную системную libwrap для этой же цели?

Aceler ★★★★★ ()
Ответ на: комментарий от shurupov

Великий Хаос! Это что ж за DDoS такой странный, от которого можно защититься на локальном сервере? Мои тапочки уже смеются.

DDoS - это когда вам недельку льют гигабит 10 минимум. Это счастье, от которого оптические SFPшки на пограничных cisco asr виснут. От этого невозможно защититься на сервере по определению.

Какой-то вы ерундой страдаете, еще раз вам это повторяю.

slamd64 ★★★ ()

Чушь какая!!!
Видимо, вас по настоящему не досили.

vada ★★★★★ ()

в зеноне используется это дерьмо, чем неимоверно доставляет сервисам защиты от DDoS, которые проксируют запросы через себя :)

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.