Pull to refresh

Comments 14

А есть пример правила для других протоколов?
Типа торрент заблокировать?
Блокировать торренты не стоит, правильнее урезать с помощью connpkts/connlimit (именно урезать, а не отрезать).

Про другие протоколы — сегодня чуть позже дополню статью.
Ну другие мне не очень интересно.
А торренты через l7 модуль если фильтровать — вешают ядро роутера.
Может с этим былоб лучше.
Ну, могу попробовать подсказать как легче всего в конкретной ситуации фильтровать.

Во-первых — задача именно заблокировать и на 100% или порезать, чтобы не ели канал?
Во-вторых — какая ширина канала/количество юзеров?

P.S: чтобы l7 не вешал ядро, можно выносить его в userspace (см. l7-filter-userspace), правда так производительность на большом канале падает сильно.
P.P.S: forum.nag.ru/forum/index.php?showtopic=55025&st=1060 хорошо раскрыта тема, в основном беда вроде как с utp бывает.
Кажется понял как можно проверить.
А где бинарики скачать чтоб потестить?
У вас CentOS 6 с 2.6.32-358 x86_64?
Если да, могу в личные сообщения скинуть бинарь.
поставлю такой не вопрос, скинь плиз
Так и был разрушен миф о необходимости дорогущего DPI и невозможности мелким интернет-провайдерам отфильтровать запрещенные сайты по URL, а не по IP :)
Ну, списки запрещённых сайтов не по дням, а по часам растут, пачкой правил с такими поисками можно потери пакетов до 90% довести и все абоненты убегут :)
Пачка правил в iptables действительно не самое лучшее решение, одно правило подгружающее список из файла при инициализации будет оптимальнее. Реализовывал подобный math модуль только с более детальным разбором http, чтобы точно определить где URL, а где содержимое, а систему загрузки и хранения базы недолго думая подсмотрел у плагина GeoIP, получился такой симбиоз. Для большого оператора конечно не пойдет в плане нагрузки, но для мелких все реально сделать.
> math
match, полагаю.

А не пробовали под нагрузкой использовать? Я когда свой DPI разрабатывал тоже думал что (да боже, на этом костыле от силы 200 юзеров работать смогут), а оказалось 10Гб/сек при 10000 URL фильтрует запросто на относительно бюджетном железе.
Какая нагрузка была — со всем справлялось, а синтетически хз как её верно воссоздать :))
Я сначала на отдельной железке просто маршрутизацией выделил «подозрительные» ip адреса находящиеся в реестре. Затем этот трафик прилетел на железку с iptables, где уже и разбирался по URL. Причем для ускорения процесса базу данных черного списка оформил в виде упорядоченного хэша по host'ам. Соответственно прилетает http, из него выдираем host, хэшируем несложной функцией, смотрим есть ли такой хэш в базе, если есть — то уже сравниваются url'ы.
Одна беда — пока работал так и не придумал как сделать вывод заглушки, соединения просто DROP'ались, а пользователь оставался в неведении почему так произошло.
Одна беда — пока работал так и не придумал как сделать вывод заглушки, соединения просто DROP'ались, а пользователь оставался в неведении почему так произошло.


У меня почти то же самое + пара плюшек с быстрым поиском GET и субдоменов.

А я для этого отдельный TARGET-модуль с tcp-session-hijack и отсылкой синтезированного HTTP 302 сделал.
Но мути с этим было — огого. Кстати, вместо DROP, возможно правильнее вам было использовать -j REJECT with-tcp tcp-reset, до написания своего модуля я его использовал. Не совсем логично, но по крайней мере загрузка страницы у пользователя не висит.

Вот пока что думаю как лучше с HTTPS поступать, в идеале на маршрутизаторе DNAT трафика идущего на IP адреса на сервер с заглушкой сделать, наверное, но я DPI не на самом маршрутизаторе держу, а сканирую зеркало трафика с коммутатора.
Sign up to leave a comment.