ну-ну

нет причин не использовать xinetd :)

Класс. Я эту проблему запихнул в bugzill'у еще 21 мая 2000 года (это http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11548 - исходный багрепорт от меня, тот, что указан в их анонсе, отмечен как дубликат). Там народ сразу патч запостил - мол, известная проблема. И только сейчас появляется официальный анонс -- почти год прошел!!! Между прочим, по указанной урл-ке можно прочитать о том, как все это происходило - RedHat не хотел об этом говорить... Я этим не хочу "наехать" на RedHat (а то опять flame поднимится), просто прикольно. На самом деле это реально очень небольшая проблема - просто мало кто включает эти сервисы от inetd (а кто включает (как я например), тот заметил бы кучу коннектов в состоянии TIME_WAIT)..

дык все уже давно xinetd ставят ...

xinetd [Re: Re: inetd в RH6]

2kmike: На самом деле есть. Xinetd сам - прекрасная цель для DoSов. Если у inetd это просто опечатка, то xinetd *так построен*. Собственно, у меня на всех RedHat7 стоит inetd (этот самый, патченный) вместо xinetd по-умолчанию. А с xinetd "прикол" - вместо того, чтобы *немного* подправить inetd (который прекрасно работает много лет), следано полностью новое "произведение", которое совершенно несовместимо по конфигам, само толстое и неповоротливое... :(

2mjt: так вроде xinetd и задумывался, как в том числе и средство от DoS-ов. там есть ограничение на кол-во instances данного сервиса. ну и встроенная функциональность tcpd не мешает :)

Не знаю, как он задумывался. Да, он позволяет ограничивать запуск сервисов (более аккуратно, чем inetd), но сама реализация этого механизма тоже может быть использована для DoS. Об этом недавно говорилось в их mailinglist (я его получаю, но где он архивируется, не знаю). Вывод был примерно такой, что с DoS'ами мы пока подождём, сперва функциональность доделаем (это утрировано). Я уже не помню подробностей (лень сейчас искать). Просто мне кажется, что xinetd в том виде как он сейчас есть просто слишком "жирный" - это достаточно простая программа (даже вместе с tcp_wrappers и контролем количества/частоты запуска сервисов), хотя это чисто мое мнение, возможно, ошибочное. Между прочим - кто-нибудь может предложить *эффективный* алгоритм "зарезания" тех ip-шников, которые "флудят", при этом оставляя возможность работать остальным? То есть чтобы не целиком сервис отключать, а только с определенных наиболее активных адресов. (Проблема в том, как хранить информацию о последних ip-адресах в виде, позволяющем быстро к ней обращаться и который не требует тонны памяти - что как раз и будет местом для организации dos'а).

-------------------------- . Между прочим - кто-нибудь может предложить *эффективный* алгоритм "зарезания" тех ip-шников, которые "флудят", при этом оставляя возможность работать остальным? То есть чтобы не целиком сервис отключать, а только с определенных наиболее активных адресов. (Проблема в том, как хранить информацию о последних ip-адресах в виде, позволяющем быстро к ней обращаться и который не требует тонны памяти - что как раз и будет местом для организации dos'а). -------------------------- Имхо алгоритм простой - таблицу на 4096 IP-адресов ( для примера ). В таблице хранятся все последние IP адреса. Причём при внесении в таблицу , адресу придаётся коэфициент , которые уменьшается со временем. При повторном обращении - коэфициент возрастает. Соответсвенно если IP набирает большой коэфициент - то заносим его во вторую таблицу ( уже меньшую по размеру ) , что означает что данный IP блокирован. К примеру на 5 сек. Через 5 сек IP удаляется из таблицы , и всё заново. Размер таблицы можно взять и больше во благо IP & Weight занимает мало. PS: Всё это чистое имхо , а алгоритм пока постинг читал придумал ;) bandures ( bandures@mail.ru )

Х-м, а об этом разве не писали?

... или я не прав?

Что-то там про полный фаирвол говорилось в 2.4
эх уйду в отпуск буду читать много :-)