Ограничение кол-ва сессий с одного IP

[vic~]

Как на FreeBSD ограничить кол-во сессий с одного IP?

Хочу таким образом избавиться от несанкционированных прокси.

[alcool]

офтоп - есть раздел софтваре

 

а вообще, я бы сделал IPNATом. там можно диапазон портов выделять. Выдели 25 портов..

[flashwolf]

man ipfw

ищем limit, src-adr

 

пример http://www.opennet.ru/tips/info/224.shtml

[G.Y.S.]

2flashwolf - не годиться.

2vic~ - только на прикладном уровне. Например сквид.

[Shiva]

vic~,

смотри модули расширения к ipfw, там есть несколько, которые тебе помогут, название не помню.

[G.Y.S.]

какая чушь

[Kuzmich]

G.Y.S., А чем keepstate limit не угодил? Делает как раз то, чего автор просит - ограничевает количество одновременных соединений с IP...

 

alcool Зачем для этого NAT привлекать, тем более, что в условиях задачи про NAT ничего не говориться...

 

Другое дело, что РАЗУМНОЕ ограничение количества сессий сложно подобрать. Кто-то и втроем в 10 сессий уложится (особенно если знают про ограничение), а кому-то для нормальной работы 10 мало... например, ICQ+VPN до работы+IRC+пара докачивающихся файлов в гетрайте + mail.ru-агент + windows update неожиданно запустился...

 

Тот же сквид, установленный в качестве "паразитного" прокси спокойно позволит ограничить количество исходящих сессий. Использование parent-proxy теоретически вообще позволит в одной сессии выкачать весь интернет - последовательными запросами к паренту без обрыва соединения.

 

ИМХО, единственный вариант - смотреть содержимое пакетов. NAT'ы практически всегда отлавливаются по нестандарным значениям TTL, http-прокси - по содержимому пакетов (X-Forwarder-For, кажется...)... Только и это не дело:

1. Некоторые файрволы/баннерорезалки содержат в себе встроенный прокси-сервер. Так что законопослушный пользователь может попасть под раздачу.

2. Умный враг может настроить свой прокси или nat на режим, когда дополнительные заголовки не вставляются в запрос, и TTL принудительно выставляется в одно и то же значение (правда, traceroute делать будет неудобно из-зи такого nat'а).

 

ИМХО, способов борьбы с проксями в сети немного:

1. Сделать высокую абонентку, а интернет продавать по себестоимости - тогда наличие у кого-то прокси не ударит по карману - абонентка уже уплочена.

2. Запретить прямую пересылку пакетов между абонентами, т.е. продавать только интернет и доступ к "официальным" игровым и файловым серверам. Если кто-то решит продавать трафик в таком варианте - ему придется строить собственную сеть, т.е. он просто станет твоим субпровайдером.

[G.Y.S.]

Kuzmich

1. Что будет при флуде, пробовали смотреть? too many dynamic rules и ... все ост динамические правила "впролете", да их можно увеличить sysctl переменной, но это не спасет отца демократии. А флуда - хоть отбавляй: и вири и сетевые сканеры. Никуда от них не денешься.

2. ограничивать количество сессий, имхо, отнють не задача фаервол. Это уже прикладной уровень. Надо юзать сквид. Он для этих целей и сделан. Подругому никак.

 

ИМХО, способов борьбы с проксями в сети немного:  

согласен

[mitchell]

используем pf. разные ограничения на разные протоколы - udp, tcp, icmp. freebsd 5.3.

[Kuzmich]

G.Y.S.,

1. Ну и отлично. Имеено с этим и можно справиться с портсканами, лавсанами и т.п. Too many dynamic rules возникает только тогда, когда флуд идет через keep-state правило БЕЗ limit'ов. Так что, sysctl net.inet.ip.fw.не_помню_точно_как_называется ставим в ${лимит сессий на пользователя}*${количество пользователей}+небольшой запасик на всякий случай - и вот оно счастье. Прользователь первый заметит, что схватил вирус - по пропаданию интернета.

 

2. Обоснуй сие голословное утверждение.

2.1. И сквид сделан совсем не для этого. У него даже сайт называется squid-cache.org. Где ключевое слово - cache.

2.2. Есть еще аська, есть mirc - они через сквид не ходют. Есть еще ftp, который в transparent-proxy не завернешь принудительно...

 

mitchell,

И какие ограничения разумны? Поделись и обоснуй, плиз...

[mitchell]

Kuzmich, 60 сессий tcp + 60 udp на 220 кбитах вполне достаточно для комфортной работы одного- или двух компьютеров (для одновременной работы, разумеется). Сайты открываются, картинки-баннеры грузятся, осел работает. Опытным путем установлено, что проблемы начинаются с третьего компьютера (одновременно работающего с первыми двумя), что крайне не нравится некоторым недобросовестным юрлицам, обманными путями подключающихся на безлимиты для частников. Случаев перепродажи нашего интернета я лично не знаю, с натами и проксями не боремся - незачем :)

[Shiva]

mitchell,

осёл исполь***т до 4 соединений на 1 IP. Настоящий убийца это FlashGet, он до сих пор не научился закрывать порты (собака).

[G.Y.S.]

2 Kuzmich

1. Количество динамических правил - относиться ко всей системе сетевой защиты (ipfw)

Too many dynamic rules возникает только тогда, когда флуд идет через keep-state правило БЕЗ limit'ов

не-а. Too many dynamic rules возникает только тогда, когда флуд идет через любые динамические правила, к коим относится и limit.

sysctl net.inet.ip.fw.не_помню_точно_как_называется ставим в ${лимит сессий на пользователя}*${количество пользователей}+небольшой запасик на всякий случай - и вот оно счастье.

Кузмич, было бы очень интересно! Вспомни. Прошу. А так.. в счастье слабо пока вериться ))

 

 

2. Конечно.

Задача fw - фильтровать пакетики. А не следить за количество открытых соединений различных прикадных протоколов. Согласен? И те фичи которые суют в ipfw имхо бесполезны. А свид - хоть он и прокси, способен выполнять поставленную автором топика задачу.

[Kuzmich]

1.

Только что проверил.

 

Написал утилиту, генерящую сплошной поток UDP-пакетов по заданному диапазону IP-адресов, запустил этот поток через тестовый роутер FreeBSD 4.9.

 

Тест первый:

 

sysctl net.inet.ip.fw.dyn_max=20

ipfw add 500 allow ip from any to any limit src-addr 10

 

пускаю поток пакетов, загрузка процессора роутера 100%, полет нормальный.

 

Тест второй:

 

sysctl net.inet.ip.fw.dyn_max=20

ipfw add 500 allow ip from any to any limit src-addr 20

 

Вся консоль в ipfw: install_state: Too many dynamic rules.

 

Вывод - правило limit вполне защищает пул памяти, выделенный под хранение динамических правил, от переполнения при флуде.

 

Для желающих повторить эксперимент - генератор флуда можно взять на http://eliseeff.chat.ru/udpflood.exe. 25 килобайт, винды. За безглючность флудера не ручаюсь - на свой страх и риск.

 

2. Не согласен. Не убедительно. Опять голословное утверждение. Почему бы файрволу и не следить за количеством соединений, если это не требует от него практически никаких дополнительных усилий? Раз уж от всё-равно умеет отслеживать соединения различных "прикладных протоколов" (на самом деле - только до 4-го уровня OSI - http или ssh льется у тебя с порта 8080 файрволу безразлично) для обеспечения безопасности системы?

 

Сквид, т.к. он HTTP-прокси, не способен выполнять поставленную задачу, т.к. в задаче небыло ни слова про ограничение количества сессий только определенного набора протоколов. Или ты знаешь способ завернуть через сквид GRE, ICMP, IGMP, RSVP, L2TP?

[G.Y.S.]

не заметил ответ.

1. Потрясающе. На дня обязательно сам проверю.

Спасибо.

[BB]

Сквид, т.к. он HTTP-прокси, не способен выполнять поставленную задачу, т.к. в задаче небыло ни слова про ограничение количества сессий только определенного набора протоколов. Или ты знаешь способ завернуть через сквид GRE, ICMP, IGMP, RSVP, L2TP?

Он конечно не всесилен, но есть весьма универсальное средство метод CONNECT. Завернуть FTP SMTP POP ICQ и т.п. через него не представляет проблем.