Перейти к содержимому
Калькуляторы
Блокировка веб ресурса  

565 пользователей проголосовало

  1. 1. Для блокировка используем



Блокировка сайтов провайдерами маневры с DNS

1. это нельзя сделать силами только iptables и обычных веб-серверов по той причине, что сам HTTP-запрос делается уже после установления tcp-сессии. и если вы даже зарулите трафик на свой сервер, то он будет видеть просто какой-то трафик(у него не будет tcp-сессии)

 

2. поаккуратнее со string, если вы блокируется строчку "watch?v=XXX", то вы блокируете ещё и страничку, которая просто даёт ссылку(если искомая подстрока не будет в разных IP-пакетах)

Дык да.. Всё так. Но других способов, кроме как блочить по IP, на Linux не нашел..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А по IP заворачивать в сквид (или какой там Ваш любимый прокси) и там уже фильтровать? т.е. в прокси с фильтром попадет только то, что есть в списке (в смысле чьи IP есть в списке). Если в списке только IP, без урлов, то тут понятно, тут сразу резать, безо всяких там проксей. Если есть еще и урл, то в фильтрующий прокси. Я сомневаюсь что там великая нагрузка будет. например, я так понимаю основной трафик вконтакта идет не с тех урлов/ip, которые будут в базе. В базе будет страничка чьято. все ссылки отдаются с других серверов. Единственное, нужно бы озаботиться, чтобы IP клиента не менялся на IP прокси. Иначе на том же вконтакте будут проблемы с отдачей видео.

Кеш не нужен, соответственно диски побоку. Память да, нужна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Единственное, нужно бы озаботиться, чтобы IP клиента не менялся на IP прокси.

 

Собственно это и есть главная проблема

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для этого есть TPROXY, но в случае сквида, похоже, необходимо, чтобы и запросы, и ответы бежали через него. Я пытался сделать так, чтобы сквид+tproxy обрабатывал только исходящий трафик, а входящий бежал напрямую к клиенту (на тазике со сквидом поднимается bgpd и на НАСы анонсятся хосты, запросы к которым нужно фильтровать) - но не взлетело.

Вот если бы нашёлся добрый программист, который написал бы простейший проксяк, который тупо пропускал через себя исходящий трафик (запросы) + парсил GET и выдавал редирект на запрещённые урлы, было бы щасте =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Херасе простейший.

Там нужно из tcp пакетов собирать хттп запрос и потом его анализировать.

Если делать чисто ядерным то будет два массива корзин: один для соединений другой со списком для сравнения.

При этом нужно ещё уметь дефрагментацию для ипв4, и сборку самих пакетов. Плюс куча памяти: а вдруг запрос будет 16-64кб размером. Плюс вклинивание в тсп сессию своих данных.

(Кстати, как вы себе представляете, если у вас входящий к клиенту другим путём?)

С асимметричным трафиком сквид и всё остальное юзерспейсное на стандартном апи работать не будут, по очевидным причинам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Единственное, нужно бы озаботиться, чтобы IP клиента не менялся на IP прокси.

 

Собственно это и есть главная проблема

 

В чём проблема? Зафорвардить поток на прокси-сервер? man preferred-firewall

Настройить squid в transparent-режиме?

man squid.conf

http_port, опция intercept

 

Сделать squid без лишних опций?

В свете того, что через сквид будет иди трафик только тех, кого нужно фильтровать - так ли важен обратный маршрут мимо сквида? Сколько такого трафика? А если сквид с mem-only-cache?

Всё равно большую часть именно тех, кого нужно фильтровать, придётся зарезать (хм, хотя, vk.com/idXXXX так не прокатит, но именно таких страниц от vk немного) А вот всю AS vk на сквид заворачивать совсем не нужно :)

 

А если не сквид, то, например, privoxy, tinyproxy

 

Не выдумывайте себе проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для этого есть TPROXY, но в случае сквида, похоже, необходимо, чтобы и запросы, и ответы бежали через него. Я пытался сделать так, чтобы сквид+tproxy обрабатывал только исходящий трафик, а входящий бежал напрямую к клиенту (на тазике со сквидом поднимается bgpd и на НАСы анонсятся хосты, запросы к которым нужно фильтровать) - но не взлетело.

Вот если бы нашёлся добрый программист, который написал бы простейший проксяк, который тупо пропускал через себя исходящий трафик (запросы) + парсил GET и выдавал редирект на запрещённые урлы, было бы щасте =)

 

 

А в чем проблемы ? Ответы будут тоже только с тех же IP, что в базе.. т.е. трафик как с, так и на IP из базы ходят в прокси. т.е. Не надо туда гнать 100% трафика. только 80 порт и только с/на определенные IP. Даже если там будут IP ютуба и вконтакта, это будут не сервера кешей с тяжелым контентом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Херасе простейший.

Там нужно из tcp пакетов собирать хттп запрос и потом его анализировать.

Если делать чисто ядерным то будет два массива корзин: один для соединений другой со списком для сравнения.

При этом нужно ещё уметь дефрагментацию для ипв4, и сборку самих пакетов. Плюс куча памяти: а вдруг запрос будет 16-64кб размером. Плюс вклинивание в тсп сессию своих данных.

(Кстати, как вы себе представляете, если у вас входящий к клиенту другим путём?)

С асимметричным трафиком сквид и всё остальное юзерспейсное на стандартном апи работать не будут, по очевидным причинам.

Да-да-да, согласен, с простейшим я погорячился; вчера, когда только начинал обдумывать эту идёю, задача вообще элементарной казалась :)

 

>> Плюс вклинивание в тсп сессию своих данных.

>> (Кстати, как вы себе представляете, если у вас входящий к клиенту другим путём?)

Ну например серверу от имени клиента слать tcp reset, а клиенту - от имени сервера слать 302 редирект =) В общем, действительно не продумал до конца

 

В свете того, что через сквид будет иди трафик только тех, кого нужно фильтровать - так ли важен обратный маршрут мимо сквида? Сколько такого трафика? А если сквид с mem-only-cache?

А как его пускать НЕ мимо full transparent сквида? Ставить сквид в разрыв между брасами и бордером? Городить на бордере роут-мапы, чтобы трафик с нужных ip шел через сквид? Хреновые варианты

 

 

А в чем проблемы ? Ответы будут тоже только с тех же IP, что в базе.. т.е. трафик как с, так и на IP из базы ходят в прокси. т.е. Не надо туда гнать 100% трафика. только 80 порт и только с/на определенные IP. Даже если там будут IP ютуба и вконтакта, это будут не сервера кешей с тяжелым контентом.

Трафик С ip из базы не ходит в прокси. Прокси стоит "сбоку", он полностью прозрачный -> не подменяет ип клиента на свой -> ответ от сервера бордер пошлёт на брас, а не на прокси

Изменено пользователем Wingman

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в чем проблемы ? Ответы будут тоже только с тех же IP, что в базе.. т.е. трафик как с, так и на IP из базы ходят в прокси. т.е. Не надо туда гнать 100% трафика. только 80 порт и только с/на определенные IP. Даже если там будут IP ютуба и вконтакта, это будут не сервера кешей с тяжелым контентом.

Трафик С ip из базы не ходит в прокси. Прокси стоит "сбоку", он полностью прозрачный -> не подменяет ип клиента на свой -> ответ от сервера бордер пошлёт на брас, а не на прокси

 

Если просто стоит сбоку, то выключите ей питаение, чтобы не жрала электроэнергию.. А вот если завернуть туда трафик (как "туда" с dst-ip (+dst port 80) из базы так и "оттуда" с src-ip из базы (+src ip из базы)) По моему совсем не бином ньютона.. Как завернуть с нужным src ? ну на разных устройствах/операционках метод будет разный.. Но в более менее распространенных трафикорутилках в том или ином воде полиси рутинг есть. Настройте Ваш бордер на такую фичу...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну то есть если в списке будет страничка вконтакта - гонять через прокси все фронтенды вконтакта; если страничка ютуба - гонять все фронтенды ютуба. Нунафиг -)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Открою Вам секрет, через фронтенд ВИДЕО не качается ни там ни там.. Ага.

 

Варианта то ровно 4.

1. Забить

2. Заблочить по IP (но тогда ютуба с вконтактом вообще не будет в Вашем случае)

3. Купить DPI

4. Собрать DPI из подручных средств, например из сквида.

 

Вы уж там сами определитесь, что Вам нафиг, а что пойдет.. 1-й бесплатен, 2-й самый дешевый, 4-й среднинький, 3-й самый дорогой... Вам решать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да я как бы в курсе, но тем не менее. Всю АСку вконтакте (не путать с вкадре) проксить? ню-ню

Собсна, для кого-то это, наверное, тоже вариант. Я имел в виду несколько другое; это другое не взлетит без допиливания/разработки софта; засим предлагаю закончить =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да я как бы в курсе, но тем не менее. Всю АСку вконтакте (не путать с вкадре) проксить? ню-ню

Собсна, для кого-то это, наверное, тоже вариант. Я имел в виду несколько другое; это другое не взлетит без допиливания/разработки софта; засим предлагаю закончить =)

 

Мне почудилось, или в обсуждаемом софте AS небыло, но было поле IP.. Вот это, указанное там IP, и проксить. И НИЧЕГО другого. Вас трогать не должно что они укали 1 IP а там из 33, и меняются они и от региона и от времени суток. это не Ваша головная боль. Есть специяльно обученный дядя, который заполняет список.. При чем я бы записи без IP просто бы игнорил, во избежание. И уж ни разу не проявлял бы инициативу по ресолву имени в IP..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне почудилось, или в обсуждаемом софте AS небыло, но было поле IP.. Вот это, указанное там IP, и проксить. И НИЧЕГО другого. Вас трогать не должно что они укали 1 IP а там из 33, и меняются они и от региона и от времени суток. это не Ваша головная боль. Есть специяльно обученный дядя, который заполняет список.. При чем я бы записи без IP просто бы игнорил, во избежание. И уж ни разу не проявлял бы инициативу по ресолву имени в IP..

Вообще да, это я уже увлёкся :) Так-то до сих пор даже непонятно, как выглядеть основная масса записей там будет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А траф всё равно придётся куда то заворачивать, если нужно юрл смотреть.

В случае если сделать софтину которую я примерно описал то нужно только от абонента до адресов сайтов на которых юрл нужно будет заворачивать.

Кстати, там же хттп, а в хттп можно, например, два и более заголовков host передавать - не по стандарту, но работать будет во многих случаях. Такое и дпи от вендоров могут не прожевать корректно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут каждый должен понять что он хочет, сделать систему,

что бы не один запрещенный пакет не прошел, тогда это DPI однозначно.

Или систему для отмаза типа пришли проверили ну типа фильтрует и ушли.

 

У меня например вот так:

$IPTABLES -I blocksite -m set --match-set denyurl dst -j denyurl

$IPTABLES -A denyurl -m string --hex-string "GET|20|/watch?v=ujBcdZfsaS8" --algo kmp --to 64 -j DROP

В 80% сработает, а остальные 20% меня мало интересует, так же как и эффективность DPI при шифрованных сессиях.

Если кто то предложит более производительный метод с 60% срабатываний буду рад.

p/s Блокировка по ip не интересует.

Изменено пользователем Стич

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот нашёл интересную реализацию tproxy, может её доработать.

 

https://github.com/benoitc/tproxy/blob/master/README.rst

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня например вот так:

$IPTABLES -I blocksite -m set --match-set denyurl dst -j denyurl

$IPTABLES -A denyurl -m string --hex-string "GET|20|/watch?v=ujBcdZfsaS8" --algo kmp --to 64 -j DROP

Поясните, пожалуйста, несколько моментов:

1. для чего нужна цепочка "blocksite", что в ней находится и как (откуда) вообще в неё попадают пакеты?

2. я правильно понимаю, что у Вас еще и ipset используется, в который помещаются IP "blocksite"?

3. что такое "ujBcdZfsaS8" - конкретный параметр GET для конкретного "запрещенного" URL?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут каждый должен понять что он хочет, сделать систему, что бы не один запрещенный пакет не прошел, тогда это DPI однозначно.

Ошибочка - это deny ip any <block>. DPI может и пропустить особо изголежные вещи.

Пример... пример простой: GET /blockedurl/b%6cockedpage - не всякий DPI разберёт "blockedpage".

А если еще соффсетить Host хедер какими-нибудь "X-Padding: Host: xyzzy.com" килобайт на 7-8, да еще так, чтобы один "псевдохост" попал в разрыв сегмента, и сам правильный Host: - так же - и вообще может быть весело.

Web-сервак такое прожует, а вот поиск DPI'ем хост-хедера в 3-4-5 пакете, да еще на разрывах сегментов - это уже интересно. Если даже и разберет - все равно при массовых подобных фишках подгрузится конкретно.

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не нужны никакие паддинги, можно и так пакеты мелкие слать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну... в целом да. Еще интереснее как раз комбинация двух вариантов + псевдо-хост на разрыве сегмента [... X-Padding: ] [Host: xyzzy.com ... Ho] [st: block] [edhost.ru ...] - наверняка может некоторые DPI слегка вогнать в ступор.

 

А вообще я знаю, как все это свести на нет: любое несложное криптование (да хоть DES - он разрешён :) ) контента Host: и URL в первой строке (и только их) именем хоста. Слегка увеличит нагрузку на веб-серверы, намного легче HTTPS, но зато DPI будут в шоке. Поскольку DPI заранее имени хоста не знает никак - придется сверять с большим списком по IP :) Фронтэнду хоста - тоже - со списком вхостов, но на сервер нагрузка много ниже. Минус - лишаемся возможности использовать прокси, либо прокси надо явно говорить - на какой IP стучаться - хоста она не узнает.

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто что скажет по поводу вот этого и его производительности :

http://l7-filter.sourceforge.net/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я тут немного поэкспериментировал вечером, пробовал брать исходящий траф в мир на 80 порт чз libpcap,

 

выбирать пакеты с GET в начале, из них выдирать урл и хост, и проверять на совпадение со списком (хеш массив где урл это ключ),

ну и слать клиенту RST с подставного адреса, с нужным acknum, рвёт нормально в прицнипе.

Но некрасиво выглядит в браузере.

 

Вопрос а если я ему выдам полноценный хидер вебсервера с 301 кодом и урлом редиректа, а удалённому серверу кину RST для порядка.

Как себя поведёт браузер, отработает такой редирект или будет пытаться корректно закрыть коннект?

Изменено пользователем disappointed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не нужны никакие паддинги, можно и так пакеты мелкие слать.

Идея красивая но,

боюсь не сработает при схеме которая тут людям понравилась:

выделить сомнительные айпи в отдельный поток и пропустить через прокси...

прокси соберет все мелкие пакеты в один запрос и заблокирует таки плохой урл.

Но некрасиво выглядит в браузере.

это плохо, нужно явное уведомление - "Доступ запрещен! Вопросы? - смотреть здесь."

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это плохо, нужно явное уведомление - "Доступ запрещен! Вопросы? - смотреть здесь."

по-моему, это невозможно, если в "dpi" попадает только исходящий от клиента трафик.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.