Jump to content
Калькуляторы

Пров вмешивается в трафик? DNS

Reply to this topic

dmitry.destroyer   

dmitry.destroyer
Posted

На днях наблюдаю у себя:

C:\Users\Diman89>nslookup lawfilter.ertelecom.ru

╤хЁтхЁ: UnKnown

Address: 192.168.0.1

Не заслуживающий доверия ответ:

╚ь : lawfilter.ertelecom.ru

Addresses: 2a02:2698:a000::64

92.255.241.100

 

C:\Users\Diman89>nslookup hdclub.org

╤хЁтхЁ: UnKnown

Address: 192.168.0.1

Не заслуживающий доверия ответ:

 

╚ь : hdclub.org

Addresses: 2a02:2698:a000::64

92.255.241.100

 

роутер - микротик

на тике гугл-днс

при заворачивании всего трафика через впн ситуация не меняется (те же ip выдаются)

 

(может я что не правильно делаю?)

/ip route print detail
6 A S  dst-address=0.0.0.0/0 gateway=VDS gateway-status=VDS reachable distance=1 scope=30 target-scope=10 routing-mark=VDS 

7 ADS  dst-address=0.0.0.0/0 gateway=172.21.0.1 gateway-status=172.21.0.1 reachable via  PPPoE_DOMRU distance=1 scope=30 target-scope=10 

8 ADC  dst-address=172.21.0.1/32 pref-src=*.***.***.*** gateway=PPPoE_DOMRU gateway-status=PPPoE_DOMRU reachable distance=0 scope=10 

9 ADC  dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=bridge_lan gateway-status=bridge_lan reachable distance=0 scope=10 

10 ADC  dst-address=192.168.0.1/32 pref-src=192.168.4.2 gateway=VDS gateway-status=VDS reachable distance=0 scope=10 

/ip route rule
add action=lookup-only-in-table disabled=no dst-address=0.0.0.0/0 src-address=192.168.0.100/32 table=VDS

Share this post

Link to post
Share on other sites

disappointed   

disappointed
Posted

Вроде ЭРТХ давно лезет в днс запросы наружу,

вполне может спуфить в ответ.

Или возможно д-нат делает 53/UDP на свои днс сервера,

попробуйте спросить об этом ресурсе внешний днс сервер с заведомо несуществующим ip адресом.

Share this post

Link to post
Share on other sites

dmitry.destroyer   

dmitry.destroyer
Posted (edited)

1) а как это сделать? (сделать с тика?)

проверял через 2ip.ru/lookup/ - ip выдается другой

2) существуют способы избежать подобного? завернуть дефолт через впн, так понимаю, тоже не поможет?

Edited by dmitry.destroyer

Share this post

Link to post
Share on other sites

disappointed   

disappointed
Posted

А если вписать в микротике несуществующий ip как внешний днс, например 8.7.6.5

Чисто понять, каким методом подмена происходит.

Share this post

Link to post
Share on other sites

BelyaevAlexander   

BelyaevAlexander
Posted (edited)

Они снифают UDP/53 и отвечают быстрее чем настоящий сервер, от его IP, если домен из "списка".

 

Это можно исправить обрасывая ответы с IP заглушек.

 

Пример для netfilter-а Linux-а:

 

iptables -t filter -N dns

iptables -t filter -I INPUT -p udp -m udp --sport 53 -j dns

iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000064|" --algo bm --to 65535 -j DROP

iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000065|" --algo bm --to 65535 -j DROP

iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000066|" --algo bm --to 65535 -j DROP

iptables -t filter -A dns -m string --hex-string "|5cfff164|" --algo bm --to 65535 -j DROP

iptables -t filter -A dns -m string --hex-string "|5cfff165|" --algo bm --to 65535 -j DROP

iptables -t filter -A dns -m string --hex-string "|5cfff166|" --algo bm --to 65535 -j DROP

 

 

Для Mikrotik смотрите в сторону L7 filter: http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/L7

Edited by BelyaevAlexander

Share this post

Link to post
Share on other sites

disappointed   

disappointed
Posted

Они снифают и отвечают быстрее чем настоящий сервер.

Всё же DPI да? Жесть. Я думал тупой DNAT 53го порта на свои днсы.

Но всё равно фишка с прописыванием несуществующего днса прокатит, ради смеха,

ткнуть этим, дескать чё в вашей сети прилетают ответы от запросов к несуществующим днс-серверам.

Share this post

Link to post
Share on other sites

orlik   

orlik
Posted

Настройте у себя dnssec и спросите провайдера, почему у вас dns не работает :)

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

Share this post

Link to post
Share on other sites

dmitry.destroyer   

dmitry.destroyer
Posted

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

/ip firewall filter
add action=jump chain=input jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
add action=jump chain=forward jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
# IPv6
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00d"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00e"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00f"
# IPv4
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1d"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1e"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1f"
add action=return chain=CHECK_LAWFILTER_DNS
add action=jump chain=input jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=jump chain=forward jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=drop chain=CHECK_LAWFILTER_HTTP content="Location: http://lawfilter.ertelecom.ru"
add action=return chain=CHECK_LAWFILTER_HTTP

если кому понадобится

мнения будут?

Share this post

Link to post
Share on other sites

BelyaevAlexander   

BelyaevAlexander
Posted

Не понимаю что там в content написано... убедитесь, что лишнее не дропает?

Если работает и не дропает лишнего, то нормально .)

 

Кстати, фильтровать то, что они лезут в HTTP - мило, но:

Уверены что хотите искать по всем пакетам TCP/80 ? Ресурсов хватит? К тому-же с SSL уже не поможет. Корректней маршутизировать адреса "из списка" через VPN, раз уж он есть.

 

В mikrotik-е подозреваю это можно сделать через policy routing и http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Address_list ?

Share this post

Link to post
Share on other sites

dmitry.destroyer   

dmitry.destroyer
Posted

- я не совсем понимаю нужно ли добавлять к 80му и 443й порт

- я не понимаю логики: если дропать их подложный ответ, и ждать корректый - зачем тогда вообще нужен VPN?

 

BelyaevAlexander

вроде не дропает...по крайней мере за вчерашний вечер проблем не заметил

по ресурсам вроде бы проблем тоже не испытываю

насчет списков - благодарю, почитаю/попробую

 

Saab95

счетчик на правилах тикает

Share this post

Link to post
Share on other sites

BelyaevAlexander   

BelyaevAlexander
Posted (edited)

- я не совсем понимаю нужно ли добавлять к 80му и 443й порт

- я не понимаю логики: если дропать их подложный ответ, и ждать корректый - зачем тогда вообще нужен VPN?

По TCP/443 обычно ходит SSL, он зашифрован. TCP/443 нет смысла добавлять, они в него не вторгаются, так как он зашифрован, его просто блокируют/перенаправляют DNAT-ом.

 

VPN нужен для:

1. TCP/443;

2. Ресурсов которые "добровольно себя блокируют" исходя из страны запрашивающего;

3. Ну и не отсвечивать, что таки ходите на ресурсы из списка;

4. Блокировка может оказаться "выше", на аплинке провайдера, тогда drop их "Location ... " не поможет;

5. Избавляет от необходимости просматривать HTTP трафик. Хотя можно совместить address list со "списком" и drop по content="Location ...". Хотя тут просто вопрос оптимизации нагрузки на процессор.

 

В остальном да, можно просто дропать то, когда они вмешиваются, как сейчас. Тут вам решать.

 

З.Ы:

Saab95

счетчик на правилах тикает

Это странно. Так не должно быть, скорее всего трафик не идет через VPN.

Edited by BelyaevAlexander

Share this post

Link to post
Share on other sites

dmitry.destroyer   

dmitry.destroyer
Posted

По TCP/443 обычно ходит SSL, он зашифрован. TCP/443 нет смысла добавлять, они в него не вторгаются, так как он зашифрован, его просто блокируют/перенаправляют DNAT-ом.

по этому и не понимаю

если они пытаются ответить быстрее - они же будут "везде" отвечать быстрее? днс-запрос же будет в любых случаях, в т.ч. и HTTPS?

 

Это странно. Так не должно быть, скорее всего трафик не идет через VPN.

мб я неправильно понял предложенные мне правила...сделал так:

/ip firewall filter> print
10    ;;; drop_lawfilter_domru
     chain=input action=jump jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53 log=no log-prefix="" 
11    chain=forward action=jump jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53 log=no log-prefix="" 
12    chain=CHECK_LAWFILTER_DNS action=drop content=\\FF\F1d log=no log-prefix="" 
13    chain=CHECK_LAWFILTER_DNS action=drop content=\\FF\F1e log=no log-prefix="" 
14    chain=CHECK_LAWFILTER_DNS action=drop content=\\FF\F1f log=no log-prefix="" 
15    chain=CHECK_LAWFILTER_DNS action=return log=no log-prefix="" 
16    chain=input action=jump jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80 log=no log-prefix="" 
17    chain=forward action=jump jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80 log=no log-prefix="" 
18    chain=CHECK_LAWFILTER_HTTP action=drop content=Location: http://lawfilter.ertelecom.ru log=no log-prefix="" 
19    chain=CHECK_LAWFILTER_HTTP action=return log=no log-prefix="" 

/ipv6 firewall filter> print
8    ;;; drop_lawfilter_domru
     chain=input action=jump jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53 log=no log-prefix="" 
9    chain=forward action=jump jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53 log=no log-prefix="" 
10    chain=CHECK_LAWFILTER_DNS action=drop content=*\02&\98\A0\00\00\00\00\00\00\00\00\00\00d log=no log-prefix="" 
11    chain=CHECK_LAWFILTER_DNS action=drop content=*\02&\98\A0\00\00\00\00\00\00\00\00\00\00e log=no log-prefix="" 
12    chain=CHECK_LAWFILTER_DNS action=drop content=*\02&\98\A0\00\00\00\00\00\00\00\00\00\00f log=no log-prefix=""

Share this post

Link to post
Share on other sites

Ivan_83   

Ivan_83
Posted

ИМХО правила отрабатывать не будут, как я понимаю: когда запрос уходит куда то запись об этом появляется в контраке, как об установленном соединении, когда приходит ответ он чекается по котраку и он там есть, поэтому пакет идёт мимо всех этих правил.

 

Но в любом случае продолжать разговор без дампов смысла не имеет, ибо это гадание.

Share this post

Link to post
Share on other sites

BelyaevAlexander   

BelyaevAlexander
Posted (edited)

ИМХО правила отрабатывать не будут, как я понимаю: когда запрос уходит куда то запись об этом появляется в контраке, как об установленном соединении, когда приходит ответ он чекается по котраку и он там есть, поэтому пакет идёт мимо всех этих правил.

 

Эм? Разве в цепочке filter пакеты зависят от conntrack, это же не nat цепочка? Разумеется если микротик не скрывает зачем-то первой записи вида conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT, но это было бы странно .)

 

Но в любом случае продолжать разговор без дампов смысла не имеет, ибо это гадание.

 

04:06:06.942663 IP (tos 0x0, ttl 64, id 36948, offset 0, flags [none], proto UDP (17), length 64)
   gw-l.45467 > 8.8.8.8.53: [bad udp cksum 0x6805 -> 0x6f44!] 6976+ A? danbooru.donmai.us. (36)
04:06:06.943649 IP (tos 0x60, ttl 120, id 54321, offset 0, flags [none], proto UDP (17), length 80)
   8.8.8.8.53 > gw-l.45467: [udp sum ok] 6976 q: A? danbooru.donmai.us. 1/0/0 danbooru.donmai.us. [10m] A 92.255.241.100 (52)
04:06:06.953739 IP (tos 0x60, ttl 54, id 9776, offset 0, flags [none], proto UDP (17), length 96)
   8.8.8.8.53 > gw-l.45467: [udp sum ok] 6976 q: A? danbooru.donmai.us. 2/0/0 danbooru.donmai.us. [17m38s] A 67.202.114.133, danbooru.donmai.us. [17m38s] A 67.202.114.134 (68)

 

Первый есть: хоть и не от топик стартера, но пусть будет .)

 

по этому и не понимаю

если они пытаются ответить быстрее - они же будут "везде" отвечать быстрее? днс-запрос же будет в любых случаях, в т.ч. и HTTPS?

 

Независимые процессы:

1. Сначала идет разрешение имени в IP по DNS - они пытаются подменить IP адрес там;

2. Потом они уже пытаются влезть в сам трафик до этих адресов.

 

мб я неправильно понял предложенные мне правила...сделал так:

Да, не совсем. Фильтр с content для IPv6 адресов должены быть в цепочке IPv4, так же как и правила IPv4 должны быть внутри цепочки IPv6. (Дублироваться)

Это из-за того, что если вы используете DNS поверх IPv4/UDP, то в ответе всё равно может содержаться адрес из IPv6. Так-же верно и обратное.

Edited by BelyaevAlexander

Share this post

Link to post
Share on other sites

Дегтярев Илья   

Дегтярев Илья
Posted

А еще можно не просматривать содержимое пакетов, а смотреть только TTL.

Поддельные ответы имеют постоянный большой ttl.

Share this post

Link to post
Share on other sites

Ivan_83   

Ivan_83
Posted
Эм? Разве в цепочке filter пакеты зависят от conntrack, это же не nat цепочка? Разумеется если микротик не скрывает зачем-то первой записи вида conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT, но это было бы странно .)

Есть statefull и stateless фаерволы.

Первые отслеживают состояние (коннтрак в терминологии линуха) а вторые нет.

Собственно, вторые сильно ограниченны в возможностях и мало кому нужны, по сути там возможности как ACL на коммутаторах: тупо матчить и пускать/дропать.

Те если у тебя какая то софтина внутри сети есть с udp и она работает на не фиксированном порту то чтобы она получала ответы из инета тебе придётся разрешать все пакеты юдп из инета со всех адресов на все порты твоего компа с этой софтиной, те можно сказать что такого фаервола практически и нет. Тоже самое и с TCP.

Кажется, в линухе есть NOTRACK опция для правил в иптаблес.

Вот тебе нужно создать правило output для udp dst 53 с этой опцией, тогда твои правила начнут обрабатываться, но работать это будет только для днспроки который встроен в сам тик, все остальные должны будут у тика адреса спрашивать.

 

 

Если по правильному, то нужно использовать dnssec или шифрованный VPN.

Правильнее нагнуть такого оператора или свалить от него.

Можно попробовать резолверы на tcp перевести, я когда то игрался (году в 2004-5) и оно работало.

Сейчас можно, наверное, unbound обучить использовать только tcp для резолвинга.

Он же умеет и DNSSEC чекать, но не уверен что он будет ждать второго правильного ответа.

Share this post

Link to post
Share on other sites

BelyaevAlexander   

BelyaevAlexander
Posted (edited)

Есть statefull и stateless фаерволы.

 

Это очевидно. И да:

сonntrack НЕ ВЛИЯЕТ на filter - эта цепочка всегда обрабатывает все пакеты, во всяком случае это верно для netfilter-а Linux-а.

Это поведение можно изменить руками, добавив запись -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT в самое начало цепочек, но микротик такого не делает, что очевидно.

А statefull достигается за счет ctstate который может быть NEW|RELATED|ESTABLISHED|INVALID и параметра сессии ctmark, который - произвольное число.

 

Такое поведение отличается только для nat цепочки, она действительно связана с conntrack.

 

Так что правила у топик стартера срабатывают, вопрос был в том:

Насколько корректно он дропает.

Как он так настраивал VPN, что трафик через него не шел.

Edited by BelyaevAlexander

Share this post

Link to post
Share on other sites

dmitry.destroyer   

dmitry.destroyer
Posted
Да, не совсем. Фильтр с content для IPv6 адресов должены быть в цепочке IPv4, так же как и правила IPv4 должны быть внутри цепочки IPv6. (Дублироваться)

так (сами правила и их порядок в т.ч.)? извините, "я только учусь"

 

/ip firewall filter
add action=jump chain=input jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
add action=jump chain=forward jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00d"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00e"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00f"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1d"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1e"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1f"
add action=return chain=CHECK_LAWFILTER_DNS
add action=jump chain=input jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=jump chain=forward jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=drop chain=CHECK_LAWFILTER_HTTP content="Location: http://lawfilter.ertelecom.ru"
add action=return chain=CHECK_LAWFILTER_HTTP

/ipv6 firewall filter
add action=jump chain=input jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
add action=jump chain=forward jump-target=CHECK_LAWFILTER_DNS protocol=udp src-port=53
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00d"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00e"
add action=drop chain=CHECK_LAWFILTER_DNS content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00f"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1d"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1e"
add action=drop chain=CHECK_LAWFILTER_DNS content="\\\FF\F1f"
add action=return chain=CHECK_LAWFILTER_DNS
add action=jump chain=input jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=jump chain=forward jump-target=CHECK_LAWFILTER_HTTP protocol=tcp src-port=80
add action=drop chain=CHECK_LAWFILTER_HTTP content="Location: http://lawfilter.ertelecom.ru"
add action=return chain=CHECK_LAWFILTER_HTTP

 

нашел тему на хабре, по поводу блокировок: http://habrahabr.ru/post/228305/

проверился софтинкой, вывод ниже

 

[O] Тестируем DNS

[O] Получаем эталонные DNS с сервера

Эталонные адреса: ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']

Адреса через системный DNS: ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']

Адреса через Google DNS: ['5.178.68.100', '69.165.95.242', '92.255.241.100', '92.255.241.100']

Адреса через DNS AntiZapret: ['107.150.11.192', '107.150.11.192', '92.255.241.100', '92.255.241.100']

[?] Способ блокировки DNS определить не удалось

 

[O] Тестируем HTTP

Открываем http://sukebei.nyaa.se/?page=view&tid=395631'>http://sukebei.nyaa.se/?page=view&tid=395631

[☠] Сайт не открывается

Открываем http://sukebei.nyaa.se/

[✓] Сайт открывается

Открываем http://gelbooru.com/index.php?page=post&s=view&id=1989610'>http://gelbooru.com/index.php?page=post&s=view&id=1989610

[☠] Сайт не открывается

Открываем http://gelbooru.com/

[✓] Сайт открывается

Открываем через прокси http://sukebei.nyaa.se/?page=view&tid=395631'>http://sukebei.nyaa.se/?page=view&tid=395631

[✓] Сайт открывается

Открываем через прокси http://sukebei.nyaa.se/

[✓] Сайт открывается

Открываем через прокси http://gelbooru.com/index.php?page=post&s=view&id=1989610'>http://gelbooru.com/index.php?page=post&s=view&id=1989610

[✓] Сайт открывается

Открываем через прокси http://gelbooru.com/

[✓] Сайт открывается

 

[O] Тестируем HTTPS

Открываем https://2chru.net/

[☠] Сайт не открывается

Открываем https://e621.net/

[☠] Сайт не открывается

 

[!] Результат:

[⚠] Ваш провайдер блокирует чужие DNS-серверы.

Вам следует использовать шифрованный канал до DNS-серверов, например, через VPN, Tor или HTTPS/Socks прокси.

[⚠] У вашего провайдера "обычный" DPI.

Вам поможет HTTPS/Socks прокси, VPN или Tor.

 

Т.е. при проверке данных с эталонных DNS я частично получаю неверные данные от прова - 92.255.241.100

Share this post

Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Followers 0
Go to topic listing Активное оборудование Ethernet, IP, MPLS, SDN/NFV...