посчитать удачные и неудачные incoming tcp connections
Hi! Вынес я из своего smtpproxy поддержку ipfw&co в 2 отдельных софтины - expire daemon (экспайрит по часам правила) + добавлялка адресов (получает IP & RBL score и пущает ipfw). "ляпота" - 7000+ ipfw rules насобиралось(ну, кое что там раза по 2 подобавлялось - думаю эдак половина, где-то 300+ быстро экспайрящихся правил), количество входящих соединений радикально упало - наверно минимум на 50% (хотя, посмотрим, что будет посреди недели)... Вот и думаю - чего б написать в ipfw, чтоб считать разницу между попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - бо считать deny в куче появляющихся и исчезающих правил - как-то нереально). -- 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
Sat, Mar 26, 2005 at 08:32:54, unisol wrote about "[uanog] посчитать удачные и неудачные incoming tcp connections":
Вынес я из своего smtpproxy поддержку ipfw&co в 2 отдельных софтины - expire daemon (экспайрит по часам правила) + добавлялка адресов (получает IP & RBL score и пущает ipfw). "ляпота" - 7000+ ipfw rules насобиралось(ну, кое что там раза по 2 подобавлялось - думаю эдак половина, где-то 300+ быстро экспайрящихся правил), количество входящих соединений радикально упало - наверно минимум на 50% (хотя, посмотрим, что будет посреди недели)... Надо использовать ipfw tables, меньше будет грузить.
Вот и думаю - чего б написать в ipfw, чтоб считать разницу между попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - бо считать deny в куче появляющихся и исчезающих правил - как-то нереально). ACK без SYN на те же пары хостов и портов.
-netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, Mar 26, 2005 at 08:32:54AM +0200, Paul Arakelyan wrote:
Hi! Вынес я из своего smtpproxy поддержку ipfw&co в 2 отдельных софтины - expire daemon (экспайрит по часам правила) + добавлялка адресов (получает IP & RBL score и пущает ipfw). "ляпота" - 7000+ ipfw rules насобиралось(ну, кое что там раза по 2 подобавлялось - думаю эдак половина, где-то 300+ быстро экспайрящихся правил), количество входящих соединений радикально упало - наверно минимум на 50% (хотя, посмотрим, что будет посреди недели)...
Вот и думаю - чего б написать в ipfw, чтоб считать разницу между попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - бо считать deny в куче появляющихся и исчезающих правил - как-то нереально).
А статистика, выдаваемая по netstat -s -p TCP, не сгодится? В частности, примерно такое: 204498 connection requests 111947 connection accepts 3390 bad connection attempts
-- Best regards, Paul Arakelyan.
-- NO37-RIPE
On Sat, Mar 26, 2005 at 10:41:48AM +0200, Valentin Nechayev wrote:
Sat, Mar 26, 2005 at 08:32:54, unisol wrote about "[uanog] посчитать удачные и неудачные incoming tcp connections":
Вынес я из своего smtpproxy поддержку ipfw&co в 2 отдельных софтины - expire daemon (экспайрит по часам правила) + добавлялка адресов (получает IP & RBL score и пущает ipfw). "ляпота" - 7000+ ipfw rules насобиралось(ну, кое что там раза по 2 подобавлялось - думаю эдак половина, где-то 300+ быстро экспайрящихся правил), количество входящих соединений радикально упало - наверно минимум на 50% (хотя, посмотрим, что будет посреди недели)... Надо использовать ipfw tables, меньше будет грузить. Ну - до "тяжело" пока ещё далеко ;). И тяжко таблицами управлять будет, у меня добавляются правила с номером, зависящим от времени добавления и RBL score - то есть, имеется несколько групп правил, в каждой группе они экспайрятся через 20...2900+ минут, то есть при такой системе нужно "навороченный" экспайрер+добавлятель и всё в БД попутно хранить - можно нарваться на большие грабли, если что-то из этого упадёт. Вобщем - пока что подожду 4 дня - получу "среднеустаканенный" набор "долгоиграющих" правил, пока вот имеем: ipfw show|wc -l 10368 Вот "маложивущий" набор - от 20 минут до 45 (почта от таких принимается и подменяется на notification): ipfw show 1000-4000|wc -l 603
попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - ACK без SYN на те же пары хостов и портов. чичас попробуем :)
-- 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
On Sat, Mar 26, 2005 at 12:04:03PM +0200, Oleg V. Nauman wrote:
On Sat, Mar 26, 2005 at 08:32:54AM +0200, Paul Arakelyan wrote:
Вот и думаю - чего б написать в ipfw, чтоб считать разницу между попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - бо считать deny в куче появляющихся и исчезающих правил - как-то нереально).
А статистика, выдаваемая по netstat -s -p TCP, не сгодится? В частности, примерно такое: 204498 connection requests 111947 connection accepts 3390 bad connection attempts
7132770 connection requests 7368183 connection accepts Что-то странно оно начитало ^^^ 265397 bad connection attempts И мало ли куда кто коннектился - мож кто порты сканил, например... -- 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
Бесплатно дарю идею: роутить нехороших мальчиков в null0 (или в lo0). Нагрузка на процессор будет на порядок меньше, даже если таких маршрутов будут тыщщщщщи. А вообще женится Вам пора, барин. Paul Arakelyan wrote:
Hi! Вынес я из своего smtpproxy поддержку ipfw&co в 2 отдельных софтины - expire daemon (экспайрит по часам правила) + добавлялка адресов (получает IP & RBL score и пущает ipfw). "ляпота" - 7000+ ipfw rules насобиралось(ну, кое что там раза по 2 подобавлялось - думаю эдак половина, где-то 300+ быстро экспайрящихся правил), количество входящих соединений радикально упало - наверно минимум на 50% (хотя, посмотрим, что будет посреди недели)...
Вот и думаю - чего б написать в ipfw, чтоб считать разницу между попытками установления соединений и удачно установленными соединениями (то есть, чего кроме 'setup' ещё нужно считать - бо считать deny в куче появляющихся и исчезающих правил - как-то нереально).
-- Pavel Narozhnyy Product manager - Datacom O. Gonchara, 73, 5 floor, Kiev, Ukraine Phone/fax: +380-44-490-22-18 mobile: +380-50-276-00-84 http://data.huawei.com/ =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Mar 28, 2005 at 08:14:30AM +0300, Pavel Narozhnyy wrote:
Бесплатно дарю идею: роутить нехороших мальчиков в null0 (или в lo0). Экспайрить КАК? У меня ключевым моментом явилась именно простота реализации expire - прибил несколько номеров правил (эдак 5/минуту) - и никаких проблем. Такие танцы с маршрутами требуют БД-подобной сущности. Хотя на самом деле то, что blocking/unblocking вынесено в отдельные софтины, позволяет изголяться как угодно. В принципе я уже придумал, как такое сделать, не увлекаясь БД, но как-то странно оно выглядеть будет :). Несколько каталогов(по 1 на score), в каждом из них по N,M,... каталогов(по одному на единицу времени жизни правила), в которых лежат файлы с названиями из IP.
Нагрузка на процессор будет на порядок меньше, даже если таких маршрутов будут тыщщщщщи. Честно говоря, до сих пор плохо представлял себе, каково оно получить 12,000+ правил и как оно фурычить будет... Если каждый пакет проходит через ту кучу правил - то взлёт interrupt rate до каких-то нереальных величин - 70+% на P3-1GHz, при том, что если добавить перед всем. ipfw add 50 skipto 998 tcp from any to any 25 via fxp0 in setup то получим только 1-4%. Что за глупость (ну - system time - я понимаю, но прерывания тут при чём?!)
А вообще женится Вам пора, барин. "Что он вам плохого сделал?", как говорит моя мама :)
-- 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
Pavel Narozhnyy wrote: PN> Бесплатно дарю идею: роутить нехороших мальчиков в null0 (или в lo0). PN> Нагрузка на процессор будет на порядок меньше, даже если таких маршрутов PN> будут тыщщщщщи. А чего не в discard направлять ? Эффект-то один и тот же, но disc он жеж специально для этого и придуман - пакеты давить. -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Tue, Mar 29, 2005 at 11:30:01AM +0300, vladimir.sharun@ukr.net wrote:
Pavel Narozhnyy wrote: PN> аЕЯОКЮРМН ДЮПЧ ХДЕЧ: ПНСРХРЭ МЕУНПНЬХУ ЛЮКЭВХЙНБ Б null0 (ХКХ Б lo0). PN> мЮЦПСГЙЮ МЮ ОПНЖЕЯЯНП АСДЕР МЮ ОНПЪДНЙ ЛЕМЭЬЕ, ДЮФЕ ЕЯКХ РЮЙХУ ЛЮПЬПСРНБ PN> АСДСР РШЫЫЫЫЫХ.
ю ВЕЦН МЕ Б discard МЮОПЮБКЪРЭ ? щТТЕЙР-РН НДХМ Х РНР ФЕ, МН disc НМ ФЕФ ЯОЕЖХЮКЭМН ДКЪ ЩРНЦН Х ОПХДСЛЮМ - ОЮЙЕРШ ДЮБХРЭ. По моему, если через ту кучу правил (можно считать, устаканилось на отметке 12,500) пропускать только setup-пакеты - то ой сколько их должно быть, чтоб хреново стало совсем. Хотя решение типа "зароутить в ..." явно более "кросс-платформенное".
-- 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
On Tue, Mar 29, 2005 at 11:30:01AM +0300, vladimir.sharun@ukr.net wrote:
Pavel Narozhnyy wrote: PN> Бесплатно дарю идею: роутить нехороших мальчиков в null0 (или в lo0). PN> Нагрузка на процессор будет на порядок меньше, даже если таких маршрутов PN> будут тыщщщщщи.
А чего не в discard направлять ? Эффект-то один и тот же, но disc он жеж специально для этого и придуман - пакеты давить.
Если не нужно icmp hvost unreachable etc. А так адекватно работатет только в паре с ipfw add xxx unreach host ip from any to any out via ds0
-- UKR.NET Postmaster
-- NO37-RIPE Internet is a wonderful mechanism for making a madman of yourself
Интересная тема - количество правил в ipfw за неделю упало(!) с 12K+ до 9K. И логи поменьшали до размеров прошлогоднего лета (почти в 2 раза меньше стали .bz2). Вывод интересный напрашивается: половина спама посылается хорошо организованными конторами с неленивыми товарищами. On Fri, Apr 01, 2005 at 01:42:23PM +0300, Oleg V. Nauman wrote:
On Tue, Mar 29, 2005 at 11:30:01AM +0300, vladimir.sharun@ukr.net wrote:
Pavel Narozhnyy wrote: PN> Бесплатно дарю идею: роутить нехороших мальчиков в null0 (или в lo0). PN> Нагрузка на процессор будет на порядок меньше, даже если таких маршрутов PN> будут тыщщщщщи. Вообще-то мне тяжко представить, сколько connections/s в port 25 в меня должно валиться, чтоб те несколько тысяч ipfw rules сколь нибудь значительно нагрузили сервер. Думаю, тормоза в ipfw - это будет наименьшая из проблем при той ситуации. А подсчёт "прошедших" connection requests - одно правило опосля кучи ipfw deny, одно перед - и несложная математика поможет подсчитать "сколько застряло".
-- 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
participants (5)
-
Oleg V. Nauman
-
Paul Arakelyan
-
Pavel Narozhnyy
-
Valentin Nechayev
-
vladimir.sharun@ukr.net