Jump to content
Калькуляторы
Блокировка веб ресурса  

536 members have voted

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



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

grep Huge /proc/meminfo
AnonHugePages:     67584 kB
ShmemHugePages:        0 kB
HugePages_Total:    3448
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:         7061504 kB

 

cat ./extfilter.ini 
; Переводить имя хоста в прописные буквы. Если url_normalization установлен в true, то не имеет значения.
;lower_host = false

domainlist = /usr/local/etc/extfilter/domains
urllist = /usr/local/etc/extfilter/urls
ssllist = /usr/local/etc/extfilter/ssl_host

; файл с ip:port для блокировки
hostlist = /usr/local/etc/extfilter/hosts

; Список ip адресов/сетей для блокировки ssl если нет server_name в ssl hello пакете. Загружается если block_undetected_ssl = true.
sslips = /usr/local/etc/extfilter/ssl_ips

; если false, то будет послан ответ от сервера 403 Forbidden вместо редиректа. Default: false
http_redirect = true

# если в конце url будет указан символ ? иди &, то после этого символа будет добавлен блокированный url: redirect_url[?|&]uri=http://...
redirect_url = http://roskomnadzor.xxxx.net

; посылать tcp rst в сторону сервера от имени клиента. Default: false
rst_to_server = true

; Default: 0 - disable
statistic_interval = 300

; Блокировать ssl по ip из файла с ip адресами в случае отсутствия SNI. Default: false
block_ssl_no_sni = false

; Какие ядра использовать. Default: все ядра, кроме management.
core_mask = 7

; файл статистики (для extfilter-cacti)
statisticsfile = /var/run/extFilter_stat

; mtu на интерфейсе для отправки пакетов в сторону абонентов. Default: 1500
; out_mtu = 1500


; CLI для управления или сбора статистики extfilter
; cli_port = 9999
; cli_address = 127.0.0.1

; Количество каналов памяти (для DPDK)
;memory_channels = 2

; Количество повторных пакетов в сторону клиента (от 1 до 3)
answer_duplication = 3

; Режим работы фильтра. Может быть зеркало (mirror) или мост (inline)
operation_mode = mirror

; Использовать jumbo frames
; jumbo_frames = false

; Максимальная длина ethernet фрейма при включенном jumbo_frames
; max_pkt_len = 9600

; здесь задаются порты, с которых необходимо снимать трафик
; формат:
; [port n]
; queues = a,b; a1,b1...
; n - номер порта dpdk
; a - номер очереди
; b - ядро, обрабатывающее очередь a
; Пример:
[port 0]
queues = 0,1;1,2

; Порт для отправки уведомлений через dpdk
[port 1]
type = sender
; На какой mac адрес отправлять пакеты
mac = d4:xx:xx:xx:xx:xx

[dpi]
; Масштабирование количества обрабатываемых потоков 1..10
scale = 3

; Собирать и анализировать фрагментированные пакеты
;fragmentation_ipv6_state = false
;fragmentation_ipv4_state = false
; fragmentation_ipv4_table_size = 512
; fragmentation_ipv6_table_size = 512

; Собирать и анализировать tcp потоки с неправильными порядком
;tcp_reordering = false

[logging]
loggers.root.level = information
;loggers.root.level = debug
loggers.root.channel = fileChannel
channels.fileChannel.class = FileChannel
channels.fileChannel.path = /var/log/extFilter.log
channels.fileChannel.rotation = 1 M
channels.fileChannel.purgeCount = 4
channels.fileChannel.archive = timestamp
channels.fileChannel.formatter.class = PatternFormatter
channels.fileChannel.formatter.pattern = %Y-%m-%d %H:%M:%S.%i [%P] %p %s - %t
channels.fileChannel.formatter.times = local
/dpdk/usertools/dpdk-devbind.py --status

Network devices using DPDK-compatible driver
============================================
0000:01:00.0 'I350 Gigabit Network Connection 1521' drv=igb_uio unused=
0000:01:00.1 'I350 Gigabit Network Connection 1521' drv=igb_uio unused=

Network devices using kernel driver
===================================
0000:01:00.2 'I350 Gigabit Network Connection 1521' if=enp1s0f2 drv=igb unused=igb_uio 
0000:01:00.3 'I350 Gigabit Network Connection 1521' if=enp1s0f3 drv=igb unused=igb_uio 
0000:02:00.0 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller 8168' if=enp2s0 drv=r8169 unused=igb_uio *Active*

Other Network devices
=====================
<none>

Crypto devices using DPDK-compatible driver
===========================================
<none>

Crypto devices using kernel driver
==================================
<none>

Other Crypto devices
====================
0000:00:1a.0 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine 2298' unused=igb_uio

Eventdev devices using DPDK-compatible driver
=============================================
<none>

Eventdev devices using kernel driver
====================================
<none>

Other Eventdev devices
======================
<none>

Mempool devices using DPDK-compatible driver
============================================
<none>

Mempool devices using kernel driver
===================================
<none>

Other Mempool devices
=====================
<none>

 

cat /var/run/extFilter_stat 
worker.core.1.total_packets=91329729
worker.core.1.ip_packets=12283123
worker.core.1.ipv4_packets=12272152
worker.core.1.ipv6_packets=10971
worker.core.1.total_bytes=1303629589
worker.core.1.matched_ip_port=0
worker.core.1.matched_ssl_sni=44
worker.core.1.matched_ssl_ip=0
worker.core.1.matched_http_bl_ipv4=158
worker.core.1.matched_http_bl_ipv6=0
worker.core.1.ipv4_fragments=3064
worker.core.1.ipv6_fragments=0
worker.core.1.ipv4_short_packets=0
worker.core.2.total_packets=13888318
worker.core.2.ip_packets=13885456
worker.core.2.ipv4_packets=13873507
worker.core.2.ipv6_packets=11949
worker.core.2.total_bytes=6013916780
worker.core.2.matched_ip_port=0
worker.core.2.matched_ssl_sni=40
worker.core.2.matched_ssl_ip=0
worker.core.2.matched_http_bl_ipv4=30
worker.core.2.matched_http_bl_ipv6=0
worker.core.2.ipv4_fragments=6811
worker.core.2.ipv6_fragments=0
worker.core.2.ipv4_short_packets=0
allworkers.total_packets=105218047
allworkers.ip_packets=26168579
allworkers.ipv4_packets=26145659
allworkers.ipv6_packets=22920
allworkers.total_bytes=7317546369
allworkers.matched_ip_port=0
allworkers.matched_ssl_sni=84
allworkers.matched_ssl_ip=0
allworkers.matched_http_bl=188
allworkers.ipv4_fragments=9875
allworkers.ipv6_fragments=0
allworkers.ipv4_short_packets=0
allports.received_packets=105217582
allports.missed_packets=0
allports.rx_nombuf=0
allports.ierrors=0

 

Edited by layNiko

Share this post


Link to post
Share on other sites

Вроде все должно работать. Дамп не снимал? Посмотри прилетает ли от фильтра пакет

Share this post


Link to post
Share on other sites
6 часов назад, layNiko сказал:

Поменял сетевую и перешел на обновленный фильтр. HTTPS - блокирует на ура, а вот HTTP пропускает. Фильтр одним портом подключен к зеркалу, а вторым в свободный порт центрального шлюза. В конфиге фильтра вписан MAC порта шлюза. Но редиректы не доходят до "клиента"

Советую посмотреть, есть ли в логах фильтра ошибки. Файл url готовится моим скриптом?

Share this post


Link to post
Share on other sites

@max1976 , похоже нашел в чем проблема... проведу пару тестов, подготовлю картинки схем включения "сэндера" и отпишусь.

ПС: 99,99% что проблема в схеме включения

 

В итоге:

В приложенной схеме не приходят редиректы. Тестовая машина включена через NAS1 и сендеру назначена отправка на MAC1. Но если порт-сендер переключить в свитч, в любой влан идущий через NAS1 и указать MAC NASa, то редиректы прибегают... может я что-то не так настраиваю на шлюзе, но каждый порт у него не связан с другими через коммутационную матрицу имея собственные...

EXTFILER.png

Edited by layNiko

Share this post


Link to post
Share on other sites

Коллеги проверьте скрипт zapret.pl

Сыпет в логи:

2018-12-21 14:57:34 | ERROR | main  | Error occured while working with registry: Can't call method "ip" on an undefined value at /opt/zapret/zapret.pl line 1561.
2018-12-21 14:59:34 | ERROR | main  | Can't connect to the SMTP server: Connection timed out
2018-12-21 15:01:34 | ERROR | main  | Can't connect to the SMTP server: Connection timed out
Чтобы это могло быть?

 

Share this post


Link to post
Share on other sites
В 21.12.2018 в 01:55, layNiko сказал:

MAC NASa, то редиректы прибегают... может я что-то не так настраиваю на шлюзе

Шлюз должен знать маршруты до сетей. Если отправляешь NAS  он то знает маршруты. Видимо что то не донастроено

Share this post


Link to post
Share on other sites

Вот есть в пропуске из url:

`id в реестре 1246311, http://excodit.com/ore/kupit-marihuana-tyumen.html, 148.66.136.60, GET    `

tcpdump показывает что фильтр вообще не отвечает на этот запрос. Пропусков и ошибок нет.

На скриншоте ещё такие же url c таким же поведением.

Процессор не самый новый, конечно, но и трафика не сильно много у меня.

 

 

er_url.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 час назад, Morphus сказал:

tcpdump показывает что фильтр вообще не отвечает на этот запрос. Пропусков и ошибок нет. 

На скриншоте ещё такие же url c таким же поведением.

11:58:49.394517 IP mysite.com.44916 > 148.66.136.60.http: Flags [P.], seq 1:379, ack 1, win 229, options [nop,nop,TS val 3919089996 ecr 627586432], length 378: HTTP: GET /ore/kupit-marihuana-tyumen.html, HTTP/1.1
11:58:49.394829 IP 148.66.136.60.http > mysite.com.44916: Flags [P.], seq 1:189, ack 379, win 229, length 188: HTTP: HTTP/1.1 302 Moved Temporarily
11:58:49.394851 IP 148.66.136.60.http > mysite.com.44916: Flags [P.], seq 1:189, ack 379, win 229, length 188: HTTP: HTTP/1.1 302 Moved Temporarily
11:58:49.394862 IP 148.66.136.60.http > mysite.com.44916: Flags [P.], seq 1:189, ack 379, win 229, length 188: HTTP: HTTP/1.1 302 Moved Temporarily
11:58:49.394870 IP 148.66.136.60.http > mysite.com.44916: Flags [P.], seq 1:189, ack 379, win 229, length 188: HTTP: HTTP/1.1 302 Moved Temporarily
11:58:50.116839 IP 148.66.136.60.http > mysite.com.44916: Flags [P.], seq 1:497, ack 379, win 122, options [nop,nop,TS val 627587243 ecr 3919089996], length 496: HTTP: HTTP/1.1 200 OK

 

Перенаправляет

Share this post


Link to post
Share on other sites
15 минут назад, Morphus сказал:

@epollia @layNiko что может быть не так с моим фильтром ? Не знаю что смотреть. :(

смотри какой трафик приходит на фильтр, и куда подключен порт для ответов.

а то может у тебя прилетает трафик после nat, а в сеть подключен перед nat севрером или еще что. Тут в твоей сети лучше тебя никто не разбирается)

Mac адреса сверь. Послушай трафик который вылетает с фильтра.

Вспомни что менял на фильтре, что в логах фиьтра?

Edited by epollia

Share this post


Link to post
Share on other sites
25 минут назад, epollia сказал:

смотри какой трафик приходит на фильтр, и куда подключен порт для ответов.

а то может у тебя прилетает трафик после nat, а в сеть подключен перед nat севрером или еще что. Тут в твоей сети лучше тебя никто не разбирается)

Mac адреса сверь. Послушай трафик который вылетает с фильтра.

Вспомни что менял на фильтре, что в логах фиьтра?

Хорошо, завтра буду копать дальше. Спасибо за наводки!

Share this post


Link to post
Share on other sites
5 часов назад, arhead сказал:

Шлюз должен знать маршруты до сетей. Если отправляешь NAS  он то знает маршруты. Видимо что то не донастроено

Знать-то он знает, но вот нашел в чем косяк, NAT на центральном похоже поганит всё. В логах такую хрень нашел:

 

 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205
 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205
 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205

NAT какого-то черта меняет порт с 80 на рандомый....

Edited by layNiko

Share this post


Link to post
Share on other sites
14 часов назад, layNiko сказал:

Знать-то он знает, но вот нашел в чем косяк, NAT на центральном похоже поганит всё. В логах такую хрень нашел:

 


 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205
 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205
 in:ExtFilter out:NAS1, src-mac a0:36:9f:85:9f:29, proto TCP (ACK,PSH), 104.18.41.52:80->192.168.0.20:48030, NAT (104.18.41.52:80->104.18.41.52:64)->192.168.0.20:48030, len 205

NAT какого-то черта меняет порт с 80 на рандомый....

 

я бы на твоем месте сделал по другому, порт sender воткнул тудаже, откуда у тебя идет mirror. Настроил бы либо отдельный vlan, либо в уже существующий ( все равно ip адресе не занимать). На счет mac адреса не совсем понятно. Судя из схемы у тебя разные vlan заведены на разные nas, а какие-то идут в обход них. Тут надо думать :(.

Как мне кажется нужно NAT вытащить выше чем sender, либо mirror выше чем NAT

Edited by epollia

Share this post


Link to post
Share on other sites

@epollia вообще странно то, что большинство url то блокируется, из базы рандомно проверял, значит подключено верно, иначе бы вообще ничего и никакие url не блокировались ? 

Share this post


Link to post
Share on other sites

Я ни на что не намекаю, но точно твой фильтр их блокирует?

Если точно он, тогда несколько вариантов: 

  1. Фильтр не справляется
  2. Проблемы с зеркалом
  3. Трафик от фильтра приходит позже чем от боевого сервера.
  4. Вроде у ребят были проблемы еще с сетевыми

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

Share this post


Link to post
Share on other sites
16 минут назад, epollia сказал:

Я ни на что не намекаю, но точно твой фильтр их блокирует?

Идет редирект на нашу заглушку, делать это может только фильтр.

17 минут назад, epollia сказал:

Фильтр не справляется

Должны же быть пропущенные пакеты в таком случае ? А их нет.

 

18 минут назад, epollia сказал:

Проблемы с зеркалом

Вероятно.

19 минут назад, epollia сказал:

Трафик от фильтра приходит позже чем от боевого сервера.

Всегда не блокируются одни и те же URL?

В моём случае ответ вообще не приходит от фильтра и да, на одни и те же url, просто они не всегда попадают в отчёт видимо. Бывает что пропусков нет вообще, а ссылки прошлые открываются.

24 минуты назад, epollia сказал:

тут лучше не браузерами проверять, потому что они могут сразу отдать из кеша страницу

открываю dev tools и ставлю галочку Disable cache. 

 

27 минут назад, epollia сказал:

Вроде у ребят были проблемы еще с сетевыми

Не знаю что ответить :)

 

Продолжаю копать и эксперементировать

Share this post


Link to post
Share on other sites

стоит ли у тебя в конфиге фильтра

fragmentation_ipv4_state и

tcp_reordering 

?

Share this post


Link to post
Share on other sites
49 минут назад, epollia сказал:

стоит ли у тебя в конфиге фильтра

fragmentation_ipv4_state и

tcp_reordering 

?

Оба параметра закомментированы

Share this post


Link to post
Share on other sites

Для эксперемента попробуй выставить в true.

А у тебя точно тарфик до проблемных серверов попадает на фильтр?, может у тебя пиринг какой хитрый сделан и этот трафик на фильтр не попадает?

Share this post


Link to post
Share on other sites
26 минут назад, epollia сказал:

Для эксперемента попробуй выставить в true.

выставить в true, перезапустить фильтр и проверить ссылки ?

26 минут назад, epollia сказал:

А у тебя точно тарфик до проблемных серверов попадает на фильтр?, может у тебя пиринг какой хитрый сделан и этот трафик на фильтр не попадает?

Точно нет. Мы маленький провайдер.

 

26 минут назад, epollia сказал:

Для эксперемента попробуй выставить в true.

Заблокировался!

Прошелся по вчерашнему списку - все блокируются!

Огромная благодарность за помощь epollia 

 

Понаблюдаю как оно дальше будет.

Edited by Morphus

Share this post


Link to post
Share on other sites

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

Речь шла про tcp_reordering 

Я бы по экперементировал с разными комбинациями.

У меня в силу конфигурации сети и зеркала стоит только 

fragmentation_ipv4_state = true
fragmentation_ipv4_table_size = 512

 

Edited by epollia

Share this post


Link to post
Share on other sites
27 минут назад, epollia сказал:

Речь шла про tcp_reordering

Проблем быть не должно. Но возьму на заметку.

32 минуты назад, epollia сказал:

fragmentation_ipv4_state = true
fragmentation_ipv4_table_size = 512

сделал пока что так же.

 

Потестировал старые пропуски, обнаружил что редиректы не блокируются:

1) с http://stuffelam.info/sankt-peterburg.html (185.229.224.120)  на https://stuffelam.info:443/sankt-peterburg.html, 185.229.224.120, GET

2) С: http://stuffcoole.info/viksa.html (185.229.224.120) на https://stuffcoole.info:443/viksa.html, 185.229.224.120, GET

Похоже я рано обрадовался.

Share this post


Link to post
Share on other sites

у меня блокируются.

Tcpdump-ом смотрел? Может ответ долго летит?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now