Комментарии 18
Все хорошо, но можно ли обойтись без упоминания в правилах адресов/ссылок на заблокированные ресурсы? Как изменится поведение фильтра без первого правила?
0
Очевидно, это новое знание требует добавления в GoodbyeDPI.
+2
Ну молодец. Умный умный. А никто и не знал. Только вот узнал такое и сидеть надо тихо, чтобы не портить другим людям.
-17
taurusbusy у вас в Ульяновске ТТК тоже не дает использовать Google DNS?
В Питере вместо Google DNS, резолвит через те же:
В Питере вместо Google DNS, резолвит через те же:
BL-gw.transtelecom.net
Filter-gw.transtelecom.net
0
У нас Google DNS так же заворачиваются на Filter-gw, но ответы не подменяются:
Первый запрос ходит не через провайдерский DNS, а через unbound с такой записью:
# host rutracker.org
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.
# host rutracker.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.
Первый запрос ходит не через провайдерский DNS, а через unbound с такой записью:
forward-zone:
name: "rutracker.org"
forward-addr: 77.88.8.8
forward-addr: 193.58.251.251
0
Хорошо, что пока еще не подменяют ничего.
Спасибо за ответ
Спасибо за ответ
0
да все ТТК-улн подменяет
[evk:prtech:~]>host rutracker.org
rutracker.org has address 62.33.207.197
rutracker.org has address 62.33.207.196
rutracker.org has IPv6 address 2a00:1e48:99:6::2:2
rutracker.org has IPv6 address 2a00:1e48:99:6::2:3
[evk:prtech:~]>host rutracker.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.
[evk:prtech:~]>host rutracker.org
rutracker.org has address 62.33.207.197
rutracker.org has address 62.33.207.196
rutracker.org has IPv6 address 2a00:1e48:99:6::2:2
rutracker.org has IPv6 address 2a00:1e48:99:6::2:3
[evk:prtech:~]>host rutracker.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.
0
Совершенно верно, если выставлены провайдерские DNS, то картина, возможно, именно такая. Но ТТК не подменяет ответы от других публично доступных DNS-серверов, а уж разрулить запросы по форвардерам умеет любой кеширующий DNS, будь то unbound, bind или др. Разумеется, удобнее всего делать это на границе подконтрольной вам сети, например, на домашнем роутере.
Для борьбы с подменой вообще всех DNS-ответов существует dnscrypt.
Для борьбы с подменой вообще всех DNS-ответов существует dnscrypt.
0
Интересно, спасибо. Только это не DPI. Он бы таким не занимался. На самом деле схема эта очевидная и работает банально на случае, кто быстрее ответит. На маршрутизаторе оператора зеркалится трафик на небольшой сервачок и если система увидит запрос к ресурсу из списка — она вот такое вытворяет. Пакет от заблокированного ресурса вам наверное прилетит, только вы его уже не будете ждать.
Что будет, когда списки вырастут ещё больше — сложно представить. Мы у себя внедряли такое (шибко подробностей не знаю, другой отдел), и налетали на штрафы от ркн за пропуски больше допустимого процента — банально система не успевала срабатывать в ответ на запросы ревизора от ркн. В итоге мы их перепробовали несколько и на чём то остановились по результатам тестов. Но принцип у них у всех один и тот же. Иначе это должна быть железка, через которую надо пропускать весь пиринг с операторами — а это совсем дорого уже только по железу, не говоря уже о софте и внедрение.
Для подстраховки оператор может организовать для ревизора лаг на секундочку, что б наверняка )) но мы без этого обошлись естественно (иначе нафиг на такую систему блокировки тратить деньги).
Что будет, когда списки вырастут ещё больше — сложно представить. Мы у себя внедряли такое (шибко подробностей не знаю, другой отдел), и налетали на штрафы от ркн за пропуски больше допустимого процента — банально система не успевала срабатывать в ответ на запросы ревизора от ркн. В итоге мы их перепробовали несколько и на чём то остановились по результатам тестов. Но принцип у них у всех один и тот же. Иначе это должна быть железка, через которую надо пропускать весь пиринг с операторами — а это совсем дорого уже только по железу, не говоря уже о софте и внедрение.
Для подстраховки оператор может организовать для ревизора лаг на секундочку, что б наверняка )) но мы без этого обошлись естественно (иначе нафиг на такую систему блокировки тратить деньги).
0
Пакет от заблокированного ресурса вам наверное прилетит, только вы его уже не будете ждать.
После провайдерского FPA ни ACK, ни HTTP-ответ от заблокированного ресурса уже не приходят. Специально tcpdump-ом искал их на внешнем интерфейсе роутера.
На маршрутизаторе оператора зеркалится трафик на небольшой сервачок и если система увидит запрос к ресурсу из списка — она вот такое вытворяет.
ЕМНИП трафик зеркалируется только для СОРМа, блокировки каждый провайдер реализует в меру своих технических возможностей. У ТТК возможностей хоть отбавляй, поэтому не удивлюсь, если они под свой DPI зарегистрировали отдельную AS и глобально сливают туда весь трафик к заблокированным ресурсам. Для них — это проще всего.
0
Пообсуждали с коллегой. Стало понятно (мне), что принцип хоть и одинаков (или сильно похож), но методы и алгоритмы действия при этом у каждого продукта «фильтрации» свои. Тут мы правды не найдём, хотя бы потому, что никто из нас не знает, как оно у ТТК на самом деле (особенно в обособленном бизнесе в той локации). Да и тема не моя.
0
У меня такой же провайдер, на роутере openwrt, всего одно слово ipv6.
0
ipv6 не спасает от подмены DNS, я выше привел резолвинг через DNS ТТК
0
В моем случае спасает. Все запросы на любые ipv4 dns сервера перехватываются провайдером и подменяются, а на ipv6 dns сервера, через туннель, не подменяются.
Правда я все равно пользуюсь dnscrypt для скрытия dns трафика от провайдера. Трафик через туннель хоть пока и не перехватывается, но идет в открытом виде, что, теоретически, не мешает начать его анализировать какими-нибудь dpi.
К тем провайдерам, которые предоставляют нативную поддержку ipv6 это, наверное, не относится.
Правда я все равно пользуюсь dnscrypt для скрытия dns трафика от провайдера. Трафик через туннель хоть пока и не перехватывается, но идет в открытом виде, что, теоретически, не мешает начать его анализировать какими-нибудь dpi.
К тем провайдерам, которые предоставляют нативную поддержку ipv6 это, наверное, не относится.
0
Не много не понятен механизм подделки Рутрекера — как в принципе можно подделать его IP да так, чтобы FPA принял клиент как за оргинальный?
0
Принцип атаки, осуществляемой ТТК, довольно подробно описан здесь (способ с TCP-битом RST). Т.к. ТТК является провайдером доступа в Интернет, то для него осуществлять подобный вид MITM-атаки не представляет никакой технической или организационной сложности.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Преодоление блокировки в ТТК (Транстелеком) при помощи pf