Буду премного благодарен, и да… уберите генерацию spec файла в cmake :)
был несказанно удивлен когда написав свой spec принялся делать rpmbuild и увидел, что cmake-ом Вы генерируете свой :)
У одного интернет провайдера было порядка 50k почтовых ящиков, провайдер был хорошим, добрым и справедливым, но он разрешал отправлять почту через свой сервер только авторизованным пользователям.
И однажды случилось непоправимое злобный вирус украл пароль от одного из ящиков пользователей и разослал немножко спама,
Провайдер пользователя отключил, но было поздно провайдер попал во все черные списки.
Инженеры провайдера выписались из всех списков за 4 часа, но был один популярный почтовый сервер который все никак не хотел получать от провайдера письма.
Через форму выписки добрый провайдер 20 раз пытался связаться с тех. сапортом, но была пятница и никто кроме эха ему не отвечал.
Все выходные не было слышно не звука и только в понедельник в 12 часов по местному времени служба поддержки человеческим языком спросила о принятых мерах в отношении спамера.
После того как добрый провайдер сказал, что пользователя расстреляла кровавая гэбня и предоставила все фото материалы по этому делу, популярный почтовый сервер начал принимать от доброго провайдера почту.
Четверо суток. Нет не так. ЧЕТВЕРО СУТОК У… КИ ИЗ mail.ru не принимали от нас почту.
Назовите мне еще хоть одну контору которая в 2011 году вручную правит черные списки?
Можно же использовать IPMARK + HTB — дел на 10 минут, производительность потрясающая. Пример использования здесь centos.alt.ru/?p=532.
Либо поставить ipfw который позволяет в 3 строчки порезать трафик. Пример здесь centos.alt.ru/?p=505.
Либо использовать надстройку над HTB SC которая использует либо flow классификатор либо u32 хэш фильтры и тоже показывает высокую производительность. Пример здесь centos.alt.ru/?p=504.
Запускать критичный сетевой сервис (DNS) на одной машине с другим сервисом (SMTP) потребление ресурсов сервера которым не ограничено помоему очень плохая идея.
Вообще по хорошему хотелось бы иметь DNS Proxy на базе например того же nginx, который может работать с большим количеством backend серверов, и ограничивать количество запросов определенных типов от каждого из клиентов.
Только я не представляю кто сможет взяться и осилить данную задачу.
Классно, вот как раз супер реактивного ресолвера мне то и не хватает для DNS туннелей.
Причем денег я вам платить не буду, а буду сидеть вечно в отключенном состоянии и гонять трафик поверх вашего реактивнейшего DNS ресолвера — побольше бы таких администраторов.
С чего Вы взяли, что режутся валидные DNS запросы? Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
Проблема в том, что введение адекватных ограничений это единственный метод борьбы с DNS флудом.
В большинстве случаев даже завирусованный вусмерть клиент этих ограничений не заметит, а вот спам бот который будет пытаться ресолвить MX, не сможет это делать так быстро, как он этого хочет.
Перечитайте статью. Где Вы все увидили ограничение валидных запросов. Ограничение будет только если от клиента идет непрерывный DOS DNS сервера, вот для того чтобы все ресурсы сервера не были исчерпаны одним пользователей и вводятся ограничения. Для j,sxyjuj gjkmpjdfntkz никакой разницы не будет
conntrack таблица в Linux ограничена размером оперативной памяти и вашей фантазией.
Если сетевые адаптеры не реалтек а нормальные Интелы и irq от них раскиданы по различным ядрам, то очень мало вероятно чтобы один клиент подключенный по 100 мбит/с завалил сервер подключеный по гигабиту.
Все очень просто. Представьте себе клиента компьютер которого рассылает спам, и спам бот постояно обращается к DNS серверу провайдера «долбя» его вопросами типа
Где почтовик mail.ru?
Где почтовик gmail.ru?
Где почтовик yahoo.com?
DNS сервер мало того что принимает данные запросы, так он еще и тратит ценные ресурсы отвечая на них. В конечном итоге DNS сервером тратится огромное количество ресурсов на запросы которые генерируются вредноносным ПО.
В статье описан метод снижения нагрузки на DNS сервер, неважно какое ПО на нем работает, причем данный метод никак не отражается на работе валидных клиентов.
Вы поймите, что абсолютно не Важно какое название у вашего рекурсивного DNS сервера.
Если при максимальном количестве запросов к вашему серверу X, любой из Ваших пользователей может сделать X+1 запрос, то название Вашего DNS сервера меня не интересует :)
Не правда, проще дропнуть пакет, чем отдать его на обработку приложению и потом отдавать ответ клиенту.
iptables + recent наиболее быстрое решение для подобных задач, recent вообще работает поразительно быстро и не оказывает существенной нагрузки на CPU в отличии от connlimit.
Или CoverRadio — любимое радио мертвых чернокожих?
был несказанно удивлен когда написав свой spec принялся делать rpmbuild и увидел, что cmake-ом Вы генерируете свой :)
в части касающейся адаптеров
У одного интернет провайдера было порядка 50k почтовых ящиков, провайдер был хорошим, добрым и справедливым, но он разрешал отправлять почту через свой сервер только авторизованным пользователям.
И однажды случилось непоправимое злобный вирус украл пароль от одного из ящиков пользователей и разослал немножко спама,
Провайдер пользователя отключил, но было поздно провайдер попал во все черные списки.
Инженеры провайдера выписались из всех списков за 4 часа, но был один популярный почтовый сервер который все никак не хотел получать от провайдера письма.
Через форму выписки добрый провайдер 20 раз пытался связаться с тех. сапортом, но была пятница и никто кроме эха ему не отвечал.
Все выходные не было слышно не звука и только в понедельник в 12 часов по местному времени служба поддержки человеческим языком спросила о принятых мерах в отношении спамера.
После того как добрый провайдер сказал, что пользователя расстреляла кровавая гэбня и предоставила все фото материалы по этому делу, популярный почтовый сервер начал принимать от доброго провайдера почту.
Четверо суток. Нет не так. ЧЕТВЕРО СУТОК У… КИ ИЗ mail.ru не принимали от нас почту.
Назовите мне еще хоть одну контору которая в 2011 году вручную правит черные списки?
покажите пожалуйста, а так же ядро и версию используемого драйвера
Можно же использовать IPMARK + HTB — дел на 10 минут, производительность потрясающая. Пример использования здесь centos.alt.ru/?p=532.
Либо поставить ipfw который позволяет в 3 строчки порезать трафик. Пример здесь centos.alt.ru/?p=505.
Либо использовать надстройку над HTB SC которая использует либо flow классификатор либо u32 хэш фильтры и тоже показывает высокую производительность. Пример здесь centos.alt.ru/?p=504.
Только я не представляю кто сможет взяться и осилить данную задачу.
Причем денег я вам платить не буду, а буду сидеть вечно в отключенном состоянии и гонять трафик поверх вашего реактивнейшего DNS ресолвера — побольше бы таких администраторов.
С чего Вы взяли, что режутся валидные DNS запросы? Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
Netflow безусловно собирается. Поясните мысль по поводу блокировки на основании netflow.
Проблема в том, что введение адекватных ограничений это единственный метод борьбы с DNS флудом.
В большинстве случаев даже завирусованный вусмерть клиент этих ограничений не заметит, а вот спам бот который будет пытаться ресолвить MX, не сможет это делать так быстро, как он этого хочет.
Если сетевые адаптеры не реалтек а нормальные Интелы и irq от них раскиданы по различным ядрам, то очень мало вероятно чтобы один клиент подключенный по 100 мбит/с завалил сервер подключеный по гигабиту.
Где почтовик mail.ru?
Где почтовик gmail.ru?
Где почтовик yahoo.com?
DNS сервер мало того что принимает данные запросы, так он еще и тратит ценные ресурсы отвечая на них. В конечном итоге DNS сервером тратится огромное количество ресурсов на запросы которые генерируются вредноносным ПО.
В статье описан метод снижения нагрузки на DNS сервер, неважно какое ПО на нем работает, причем данный метод никак не отражается на работе валидных клиентов.
Если при максимальном количестве запросов к вашему серверу X, любой из Ваших пользователей может сделать X+1 запрос, то название Вашего DNS сервера меня не интересует :)
iptables + recent наиболее быстрое решение для подобных задач, recent вообще работает поразительно быстро и не оказывает существенной нагрузки на CPU в отличии от connlimit.