On Sat, May 28, 2016 at 01:28:58PM +0300, George L. Yermulnik wrote:
Hello!
On Sat, 28 May 2016 at 12:14:14 (+0300), Paul Arakelyan wrote:
И все, или большинство, правил одинаковые, только адреса отличаются ? Такое делается таблицей с 2.5K хостов, а не 2.5K правил. Таблицы и грузятся быстрее, и существенно меньше едят время CPU. Номера критичны - хосты попадают в правило с номером, являющимся функцией от времени и продолжительности, и удаляются соответственно правила по номеру - т.е. я не держу таблиц "кого засунул" в памяти, это ОС делает.
В таблицах ipfw каждой записи можно давать значение. И значение это можно использовать в других правилах. Либо парсить листинг таблицы и в зависимости от значения удалять записи. [957] 2004-03-07 14:32:40 Start smtpshield daemon [957] 2004-03-07 14:32:40 config - port: 193.124.54.51:25 -> 193.124.54.50:25 [957] 2004-03-07 14:32:40 config - port: 193.124.54.54:25 -> 10.9.8.7:25 [957] 2004-03-07 14:32:40 configured. Таблиц тогда ещё не очень было (они появились на несколько месяцев позже), зато был вагон спама и legacy-софта, типа uucp, который продолжала ещё долго использоваться и содержал кучу "интересностей", которые и закрывала эта штука.
-rw-r--r-- 1 unisol wheel 4752 Mar 25 2005 addfw.c -rw-r--r-- 1 unisol wheel 10794 Mar 25 2005 bllookup.c -rw-r--r-- 1 unisol wheel 1871 Mar 25 2005 expired.c -rw-r--r-- 1 unisol wheel 6534 Apr 22 2004 keytbl.c lrwxr-xr-x 1 root wheel 16 Sep 1 2013 proxy.c -> proxy.c.nofilter -rw-r--r-- 1 root wheel 52870 Apr 18 2008 proxy.c.nofilter -rw-r--r-- 1 unisol wheel 16495 Feb 15 2004 proxy.c.nofilter.v1 Вот как оно работает (писалось в 2004г, и поглядев в код с хитрожопой математикой я только могу сказать, что там более 3К номеров правил и время меряется "попугаями", а не минутами): прилетел спам с IP1 в 10:00 - создаём правило 1000 deny from IP1 setup прилетел спам с IP1 в 10:01 - создаём правило 1001 deny from IP1 setup (допустим, оно начало влетать раньше, чем появилось правило 1000) прилетел спам с IP2 в 10:15 - создаём правило 1015 deny from IP2 setup в 10:15 удаляем правила с номером 1000, в 10:16 снова создаются правила начиная с 1000. Такая политика, вкупе с "торможением" адресов в RBL очень мешает спамить и "умные спамеры" могут просто выбрасывать такие адреса из списков. Соответственно есть несколько таких закольцованных наборов правил = или понадобится несколько тысяч таблиц и грохать таблицы целиком (отдельно блочатся хосты на бОльшие временные промежутки - net.inet.ip.fw.tables_max: 128 наверно не просто так и что будет при 3000 вместо 128 - не знаю) или мучаться с ipfw table number delete addr - затратно, т.к. удалять нужно кучу адресов, у которых value, т.е. понадобится писать парсилку таблицы=затраты проца и вообще взаимодействовать с структурами ядра напрямую, иначе просто северный лис или держать в памяти все заблоченные адреса с таймаутами - т.е. притопать к модели с БД. Всё же сваять софтину, делающую что-то из разряда system("/sbin/ipfw add 1000") и ещё одну, удаляющую кучу правил по номеру sprintf (buf, "/sbin/ipfw -q -f delete %d %d %d %d %d", 1000+modint(nowtm, 21), 2000+modint(nowtm, 31), 3000+modint(nowtm, 46), 4000+modint(nowtm, 999), 5000+modint(nowtm, 2999)); было несоизмеримо проще. Чтоб уехать на таблицы или вообще другую ОС/фаервол - нужно переписать добавлялку и удалялку :). Всё же задача была сваять спаморезку, умеющую взаимодействовать с SA/clamd/чем-то ещё, а не уйти с головой в системное программирование. Плюс вопрос насколько это бы надёжно работало - добавить-удалить правило - это было написано "чуть не изначально", а таблицами только в середине 2004 начали ворочать и хз как оно себя повело бы при хроническом "добавили-удалили", вариант "шото крэшнулось бы" не подходил совсем - это ж не отдельный сервер с такой задачей, там ещё куча всего... -- Best regards, Paul Arakelyan.