The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Совет о высоконагруженном фильтре трафика"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Firewall, Фильтрация пакетов / Linux)
Изначальное сообщение [ Отслеживать ]

"Совет о высоконагруженном фильтре трафика"  +/
Сообщение от SpiritOfStallman (ok) on 15-Мрт-12, 12:39 
Дня доброго, господа.
Хотелось бы послушать мнения знающих людей.
Никто ли не реализовывал фильтрацию траффика для большого кол-ва пользователей, ака разрешаем ходить только куда я хочу, с тем что клиенты не в моей локальной сети (over 2000)?
По сути: интересно ваше мнение чем бы эффективней было это сделать. Этот способ должен был бы терпеть подобную высоконогруженность, при (о, как неожиданно :)) наименьших затратах на нагрузку железок. В идеях есть прокся (но от этой идеи слёзы на глазах). Нынче это реализовано методом централизованого хранения правил айпитейблса, клиент просыпается, качает правила и начинает работу (не плохо, но вот при большом вайт-листе клиентские тазики просто загибаются)
В идеале, я это вижу (абстракция) клиент хочет на xxx.com, спрашивает у сервера "хочу туда-то" сервак сам проверяет в своих листах, и говорит да\нет, но при разрешении не транслирует траффик через себя, а попросту разрешает машине идти по этому адресу её каналами. Не встречалось ли вам нечто похожее?
Буду очень рад вашим мыслям.
ЗЫ: еще слышал о  ipsec для айпитейблса, существенно ли он разгружает фильтрацию? никто ли плотно с ним, случайно, не работал?
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от KobaLTD. email on 15-Мрт-12, 16:24 
>[оверквотинг удален]
> хранения правил айпитейблса, клиент просыпается, качает правила и начинает работу (не
> плохо, но вот при большом вайт-листе клиентские тазики просто загибаются)
> В идеале, я это вижу (абстракция) клиент хочет на xxx.com, спрашивает у
> сервера "хочу туда-то" сервак сам проверяет в своих листах, и говорит
> да\нет, но при разрешении не транслирует траффик через себя, а попросту
> разрешает машине идти по этому адресу её каналами. Не встречалось ли
> вам нечто похожее?
> Буду очень рад вашим мыслям.
> ЗЫ: еще слышал о  ipsec для айпитейблса, существенно ли он разгружает
> фильтрацию? никто ли плотно с ним, случайно, не работал?

Начнем с того что сужествует только 2 - принципиальных способа что то перекрыть 1) на "промежуточном" хосте 2) на локальном. И сужествует два варианта политик 1) разрешено все что не запрещено 2) запрещено все что не разрешено.
Далее
Если у вас блэк лист больше чем вайт лист(его надо смотреть по списком посещаемых сайтов) то вам нужно дейтвовать по политеке №2 если нет то по политеки №1.
Далее
Лочить сайты по ip - это извращение и ненужный труд - на практике 70% порно сайтов меняют ip на домене в среднем раз в 2 недели. Вы будут просто тратить ВСЕ свое время по актулизации своего блэк листа.
Далее
Лочить сайты (ip) на локале тоже изврат - есть http тунели, анонимные прокси - которые позволят обойти эти ограничения на раз.
От сюда вывод - если Вам нужно что то закрывать - то это нужно делать только на промежуточном хосте.
Теперь практика. 2000 юзверей это не много - средная железка типа кореквада с 2 гигами - переварит это в легкую. Нужно немного просто настроить - если филтровать файр волом (для Извращенцев) - то тут не важно колво пользователей тут все решит максимальная пропускная способность канал. Для уменьшения нагрузки не обезательно проганять ВСЕ соединения через список - нужно создать несколько цепочек правил котрые будет отсеивать и разбивать на меньшие подгруппы допустим
iptables -t nat -a postrouting -p tcp -s <локалка> --dport 80,8080 -J NETWORKS
iptables -t nat -a postrouting -p tcp -s <локалка> -o ethX -j DNAT ...........
iptables -t nat -a NETWORKS -p tcp -d xxx.xxx.xxx.0/24 -J XXXNETWORKS
iptables -t nat -a NETWORKS -p tcp -d yyy.yyy.yyy.0/24 -J YYYNETWORKS
iptables -t nat -a NETWORKS -p tcp -J RETURN
iptables -t nat -a XXXNETWORKS -p tcp -d xxx.xxx.xxx.xx1 -J DROP
iptables -t nat -a XXXNETWORKS -p tcp -d xxx.xxx.xxx.xx2 -J DROP
iptables -t nat -a XXXNETWORKS -p tcp -d xxx.xxx.xxx.xx2 -J RETURN

(синтаксис может и не правельны - доработаетшь, писал на вскидку чтобы показать принцеп)

Такая кострукция поможет снизить нагрузку в разы.
А Вообще "правельней" фильтровать спомощью прокси - более гибкая система - при этом если хочешь зарыть один из методов обхода "фильтка" как анонимные прокси - нужно нелать НЕ прозрачные прокси.
А вообще тема у тебя обширная и форумом тут не отделать - читай материалы в инете.

ipsec это http://ru.wikipedia.org/wiki/IPsec - протакол зациты - как любая криптография для трафика он увеличивает нагрузку и уменьшает эфективную ширину канала и к твоей задачи вообще не имеет ни какого отношения


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от Andreich email(??) on 15-Мрт-12, 18:35 
>[оверквотинг удален]
> хранения правил айпитейблса, клиент просыпается, качает правила и начинает работу (не
> плохо, но вот при большом вайт-листе клиентские тазики просто загибаются)
> В идеале, я это вижу (абстракция) клиент хочет на xxx.com, спрашивает у
> сервера "хочу туда-то" сервак сам проверяет в своих листах, и говорит
> да\нет, но при разрешении не транслирует траффик через себя, а попросту
> разрешает машине идти по этому адресу её каналами. Не встречалось ли
> вам нечто похожее?
> Буду очень рад вашим мыслям.
> ЗЫ: еще слышал о  ipsec для айпитейблса, существенно ли он разгружает
> фильтрацию? никто ли плотно с ним, случайно, не работал?

Может посмотреть в сторону IPSet?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от KobaLTD. email on 15-Мрт-12, 21:45 
>[оверквотинг удален]
>> плохо, но вот при большом вайт-листе клиентские тазики просто загибаются)
>> В идеале, я это вижу (абстракция) клиент хочет на xxx.com, спрашивает у
>> сервера "хочу туда-то" сервак сам проверяет в своих листах, и говорит
>> да\нет, но при разрешении не транслирует траффик через себя, а попросту
>> разрешает машине идти по этому адресу её каналами. Не встречалось ли
>> вам нечто похожее?
>> Буду очень рад вашим мыслям.
>> ЗЫ: еще слышал о  ipsec для айпитейблса, существенно ли он разгружает
>> фильтрацию? никто ли плотно с ним, случайно, не работал?
> Может посмотреть в сторону IPSet?

Может и подойдеть. - но как я писал выше - Web Filtering при помощи fireWall - это ИЗВРАЩЕНИЕ - не для это при думывали данную штуку, хотя некоторые используют его и для этого. Фаервол слущит для защиты системы и контроля трафика, а для Web Filtering - существует proxy (куширующий/некеширующий).

>> В идеале, я это вижу (абстракция) клиент хочет на xxx.com, спрашивает у
>> сервера "хочу туда-то" сервак сам проверяет в своих листах, и говорит
>> да\нет, но при разрешении не транслирует траффик через себя, а попросту
>> разрешает машине идти по этому адресу её каналами.

Счас внимательно прочитал "пожелания клиента". Мне это интересно как это "а попросту
разрешает машине идти по этому адресу её каналами"  - у человека на каждом тазике ПРЯМОЙ канал в инет :):):).
А из практиче - возможна и такая схема - на каждом тазике свой прокси, который тягает да/нет по средством SOAP сервиса с друго сервака с базой листов - на squid это реализуеться в 2 счета. Собственно вы получите то что просили - только такая связка будет настолько медленной - что накладные ресурсы для "общего прокси" вам покажуться цветочками.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от KobaLTD. email on 15-Мрт-12, 21:50 
>[оверквотинг удален]
>>> разрешает машине идти по этому адресу её каналами.
> Счас внимательно прочитал "пожелания клиента". Мне это интересно как это "а попросту
> разрешает машине идти по этому адресу её каналами"  - у человека
> на каждом тазике ПРЯМОЙ канал в инет :):):).
> А из практиче - возможна и такая схема - на каждом тазике
> свой прокси, который тягает да/нет по средством SOAP сервиса с друго
> сервака с базой листов - на squid это реализуеться в 2
> счета. Собственно вы получите то что просили - только такая связка
> будет настолько медленной - что накладные ресурсы для "общего прокси" вам
> покажуться цветочками.

Да кстати есть и трейтий вариант - ДЛЯ ОСОБОГО ИЗВРАЩЕНИЯ :):):) подымаете свой DNS сервер, и прописываете зоны для блокируемых доменов, а в зонах отдаете какой нить внутренйи ip для всех закрытых сайтов. Тоже самое можно и зделать просто раскидывая файл hosts по всем тазикам - только мой совет - proxy в вашем случаи оптимальное решение.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от SpiritOfStallman (ok) on 15-Мрт-12, 23:20 
>[оверквотинг удален]
>> свой прокси, который тягает да/нет по средством SOAP сервиса с друго
>> сервака с базой листов - на squid это реализуеться в 2
>> счета. Собственно вы получите то что просили - только такая связка
>> будет настолько медленной - что накладные ресурсы для "общего прокси" вам
>> покажуться цветочками.
> Да кстати есть и трейтий вариант - ДЛЯ ОСОБОГО ИЗВРАЩЕНИЯ :):):) подымаете
> свой DNS сервер, и прописываете зоны для блокируемых доменов, а в
> зонах отдаете какой нить внутренйи ip для всех закрытых сайтов. Тоже
> самое можно и зделать просто раскидывая файл hosts по всем тазикам
> - только мой совет - proxy в вашем случаи оптимальное решение.

ну я и не собирался получать тут пошаговую инструкцию, и не прекращал аудит материалов инета :)
в первую очередь спасибо за ответ
ну а касательно всего что вы сказали, сам пока самым логичным вижу проксю (может даже несколько, что бы распределять нагрузку)
предлагали еще вариант NuFW, но пришли к тому, что проект, к сожалению на грани смерти

в общем этот вопрос за пару вечеров просто не решить. нужно пособирать решения, посравнивать, покумекать :)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Совет о высоконагруженном фильтре трафика"  +1 +/
Сообщение от DeadLoco (ok) on 16-Мрт-12, 05:02 
> Никто ли не реализовывал фильтрацию траффика для большого кол-ва пользователей, ака разрешаем
> ходить только куда я хочу, с тем что клиенты не в  моей локальной сети (over 2000)?

2000 клиентов - это НЕ высоконагруженный узел.
Я аутсорсю проксю местного универа, там нужно фильтровать траффик на предмет всякой порнухи. Машин в сети как раз около 2к. Канал - 200мбит. Нагрузка на сервант (хеон5200 4Г ОЗУ)  выше 20% поднимается только изредка. Фильтрация ведется сквидовыми ацлями. Списки регекспов в 3-5к строк. Доступ практически анлимитный, т.е. кроме порнухи ничего больше не режется, доступны файлопомоища, одноглазники и законтаченые. Суточный траффик - ок. 500 гиг. Сквид с такой нагрузкой справляется.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от SpiritOfStallman (ok) on 16-Мрт-12, 11:00 
>> Никто ли не реализовывал фильтрацию траффика для большого кол-ва пользователей, ака разрешаем
>> ходить только куда я хочу, с тем что клиенты не в  моей локальной сети (over 2000)?
> 2000 клиентов - это НЕ высоконагруженный узел.
> Я аутсорсю проксю местного универа, там нужно фильтровать траффик на предмет всякой
> порнухи. Машин в сети как раз около 2к. Канал - 200мбит.
> Нагрузка на сервант (хеон5200 4Г ОЗУ)  выше 20% поднимается только
> изредка. Фильтрация ведется сквидовыми ацлями. Списки регекспов в 3-5к строк. Доступ
> практически анлимитный, т.е. кроме порнухи ничего больше не режется, доступны файлопомоища,
> одноглазники и законтаченые. Суточный траффик - ок. 500 гиг. Сквид с
> такой нагрузкой справляется.

огромное спасибо за ваш пост. это действительно ценная информация
нужно будет покатать решение

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Совет о высоконагруженном фильтре трафика"  +/
Сообщение от artemrts (ok) on 18-Мрт-12, 23:17 
>> Никто ли не реализовывал фильтрацию траффика для большого кол-ва пользователей, ака разрешаем
>> ходить только куда я хочу, с тем что клиенты не в  моей локальной сети (over 2000)?
> 2000 клиентов - это НЕ высоконагруженный узел.
> Я аутсорсю проксю местного универа, там нужно фильтровать траффик на предмет всякой
> порнухи. Машин в сети как раз около 2к. Канал - 200мбит.
> Нагрузка на сервант (хеон5200 4Г ОЗУ)  выше 20% поднимается только
> изредка. Фильтрация ведется сквидовыми ацлями. Списки регекспов в 3-5к строк. Доступ
> практически анлимитный, т.е. кроме порнухи ничего больше не режется, доступны файлопомоища,
> одноглазники и законтаченые. Суточный траффик - ок. 500 гиг. Сквид с
> такой нагрузкой справляется.

Не пробовали заменить сквид с туевой кучей регэкспов на блокировку порно и др. на уровне ДНС? Естественно ДНС-запросы только через свой ДНС либо редирект файерволом. Тем же ДНС-фильтром можно и анонимайзеры резать и всякое другое. Не сочтите за рекламу, но неплох SkyDNS.ru, до недавнего времени даже баннеры резал в бесплатном аккаунтее.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру