[dmitry.destroyer]

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

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

[disappointed]

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

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

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

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

[dmitry.destroyer]

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

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

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

Изменено 27 октября, 2015 пользователем dmitry.destroyer

[disappointed]

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

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

[BelyaevAlexander]

Они снифают 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

Изменено 27 октября, 2015 пользователем BelyaevAlexander

[disappointed]

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

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

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

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

[DimaM]

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

[orlik]

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

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

[dmitry.destroyer]

BelyaevAlexander

спасибо, буду думать

[dmitry.destroyer]

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

/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

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

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

[BelyaevAlexander]

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

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

 

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

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

 

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

[Saab95]

Попробуйте сделать туннель с шифрованием и проверить будет ли подмена.

[dmitry.destroyer]

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

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

 

BelyaevAlexander

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

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

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

 

Saab95

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

[BelyaevAlexander]

- я не совсем понимаю нужно ли добавлять к 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.

Изменено 30 октября, 2015 пользователем BelyaevAlexander

[dmitry.destroyer]

По 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="" 

[Ivan_83]

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

 

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

[BelyaevAlexander]

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

 

Эм? Разве в цепочке 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. Так-же верно и обратное.

Изменено 31 октября, 2015 пользователем BelyaevAlexander

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

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

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

[nuclearcat]

Еще проверить подмену можно так:

 

nslookup -q=txt o-o.myaddr.l.google.com

(если подмена непрозрачна)

[alibek]

TTL подменить еще проще.

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

[Ivan_83]

Эм? Разве в цепочке 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 чекать, но не уверен что он будет ждать второго правильного ответа.

[dmitry.destroyer]

болею(

правила не менял

hdclub восстановился, упал nnm-club :D

симптомы аналогичные

[BelyaevAlexander]

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

 

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

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

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

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

 

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

 

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

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

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

Изменено 2 ноября, 2015 пользователем BelyaevAlexander

[dmitry.destroyer]

Да, не совсем. Фильтр с 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

[aak]

Тыц