On Fri, Mar 18, 2005 at 10:11:21AM +0200, Alexander Trotsai wrote:
Вот тут ты ласты и склеишь. ipfilter'ом чуть легче, но ненамного. Лучше делать все на L7, когда хосты срезаются на этапе коннекта уже софтом.
как под фри - не знаю а под линуксом я бы сделал так (концептуально - по-моему все равно под чем)
новая таблица - smtp-deny INPUT/tcp/25/syn -> smtp-deny и уже в smtp-deny добавлять правила для reject таким образом это тысячи правил буду проверяться ТОЛЬКО для tcp/25/syn
Я вижу применение firewall следующим образом: несколько групп правил, в каждой правила экспайрятся через определённый промежуток времени - пропорционально степени "влёта" в RBL'ы. Таким образом сохраняется возможность доставки писем (для тех IP, с которых мы принимаем почту, но подменяем на notification 2google:doublebolt.ua.net), просто их не пролезет более чем N/сутки, также уменьшается количество проверок для "совсем заблеклистнутых" IP. В текущем варианте получаем 48...N*48 писем и 1...M*1 проверку в сутки; N - число допустимых - коннектов с одного IP, M>N - если количество коннектов превышено, то мы принимаем соединение и после ожидания отваливаем по 421 try later. Но как-то некрасиво происходит expire - из cron прибивается раз в пол-часа и раз в сутки по набору правил. Идея по улучшению - номер правила будет зависить от времени занесения и "блэклистнутости". Соответственно получим несколько наборов правил и expire будет проходить по каждому из наборов отдельно (типа в одном наборе правило "живёт" 30 минут и имеем правила с номерами 1000...1029, в другом - N часов, имеем набор с номерами 2000...2000+N*60, и т.д.) Соответственно, каждую минуту будет происходить удаление кусочка набора правил и рост следующего кусочка набора. Получаем ежеминутную встряску ядерным процедурам распределения памяти и риск улететь в космос:). Вопрос в переносимости такого решения в "куда-нибудь ещё". В итоге - я так понимаю, можно заводить по таблице каждую минуту, типа smtp-deny01,smtp-deny02... и грохать их потом целиком или правила в них... Вот такое извращение ввиду отсутствия поддержки TTL для правил. :). -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message