Comments 18
Все хорошо, но можно ли обойтись без упоминания в правилах адресов/ссылок на заблокированные ресурсы? Как изменится поведение фильтра без первого правила?
Очевидно, это новое знание требует добавления в GoodbyeDPI.
Ну молодец. Умный умный. А никто и не знал. Только вот узнал такое и сидеть надо тихо, чтобы не портить другим людям.
taurusbusy у вас в Ульяновске ТТК тоже не дает использовать Google DNS?
В Питере вместо Google DNS, резолвит через те же:
В Питере вместо Google DNS, резолвит через те же:
BL-gw.transtelecom.net
Filter-gw.transtelecom.net
Это работает в ТТК, гугл не нужен, и бонусом резолвит зоны типа lib где много полезных зеркал.
У нас 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Хорошо, что пока еще не подменяют ничего.
Спасибо за ответ
Спасибо за ответ
да все ТТК-улн подменяет
[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.
Совершенно верно, если выставлены провайдерские DNS, то картина, возможно, именно такая. Но ТТК не подменяет ответы от других публично доступных DNS-серверов, а уж разрулить запросы по форвардерам умеет любой кеширующий DNS, будь то unbound, bind или др. Разумеется, удобнее всего делать это на границе подконтрольной вам сети, например, на домашнем роутере.
Для борьбы с подменой вообще всех DNS-ответов существует dnscrypt.
Для борьбы с подменой вообще всех DNS-ответов существует dnscrypt.
Интересно, спасибо. Только это не DPI. Он бы таким не занимался. На самом деле схема эта очевидная и работает банально на случае, кто быстрее ответит. На маршрутизаторе оператора зеркалится трафик на небольшой сервачок и если система увидит запрос к ресурсу из списка — она вот такое вытворяет. Пакет от заблокированного ресурса вам наверное прилетит, только вы его уже не будете ждать.
Что будет, когда списки вырастут ещё больше — сложно представить. Мы у себя внедряли такое (шибко подробностей не знаю, другой отдел), и налетали на штрафы от ркн за пропуски больше допустимого процента — банально система не успевала срабатывать в ответ на запросы ревизора от ркн. В итоге мы их перепробовали несколько и на чём то остановились по результатам тестов. Но принцип у них у всех один и тот же. Иначе это должна быть железка, через которую надо пропускать весь пиринг с операторами — а это совсем дорого уже только по железу, не говоря уже о софте и внедрение.
Для подстраховки оператор может организовать для ревизора лаг на секундочку, что б наверняка )) но мы без этого обошлись естественно (иначе нафиг на такую систему блокировки тратить деньги).
Что будет, когда списки вырастут ещё больше — сложно представить. Мы у себя внедряли такое (шибко подробностей не знаю, другой отдел), и налетали на штрафы от ркн за пропуски больше допустимого процента — банально система не успевала срабатывать в ответ на запросы ревизора от ркн. В итоге мы их перепробовали несколько и на чём то остановились по результатам тестов. Но принцип у них у всех один и тот же. Иначе это должна быть железка, через которую надо пропускать весь пиринг с операторами — а это совсем дорого уже только по железу, не говоря уже о софте и внедрение.
Для подстраховки оператор может организовать для ревизора лаг на секундочку, что б наверняка )) но мы без этого обошлись естественно (иначе нафиг на такую систему блокировки тратить деньги).
Пакет от заблокированного ресурса вам наверное прилетит, только вы его уже не будете ждать.
После провайдерского FPA ни ACK, ни HTTP-ответ от заблокированного ресурса уже не приходят. Специально tcpdump-ом искал их на внешнем интерфейсе роутера.
На маршрутизаторе оператора зеркалится трафик на небольшой сервачок и если система увидит запрос к ресурсу из списка — она вот такое вытворяет.
ЕМНИП трафик зеркалируется только для СОРМа, блокировки каждый провайдер реализует в меру своих технических возможностей. У ТТК возможностей хоть отбавляй, поэтому не удивлюсь, если они под свой DPI зарегистрировали отдельную AS и глобально сливают туда весь трафик к заблокированным ресурсам. Для них — это проще всего.
Пообсуждали с коллегой. Стало понятно (мне), что принцип хоть и одинаков (или сильно похож), но методы и алгоритмы действия при этом у каждого продукта «фильтрации» свои. Тут мы правды не найдём, хотя бы потому, что никто из нас не знает, как оно у ТТК на самом деле (особенно в обособленном бизнесе в той локации). Да и тема не моя.
У меня такой же провайдер, на роутере openwrt, всего одно слово ipv6.
ipv6 не спасает от подмены DNS, я выше привел резолвинг через DNS ТТК
В моем случае спасает. Все запросы на любые ipv4 dns сервера перехватываются провайдером и подменяются, а на ipv6 dns сервера, через туннель, не подменяются.
Правда я все равно пользуюсь dnscrypt для скрытия dns трафика от провайдера. Трафик через туннель хоть пока и не перехватывается, но идет в открытом виде, что, теоретически, не мешает начать его анализировать какими-нибудь dpi.
К тем провайдерам, которые предоставляют нативную поддержку ipv6 это, наверное, не относится.
Правда я все равно пользуюсь dnscrypt для скрытия dns трафика от провайдера. Трафик через туннель хоть пока и не перехватывается, но идет в открытом виде, что, теоретически, не мешает начать его анализировать какими-нибудь dpi.
К тем провайдерам, которые предоставляют нативную поддержку ipv6 это, наверное, не относится.
Не много не понятен механизм подделки Рутрекера — как в принципе можно подделать его IP да так, чтобы FPA принял клиент как за оргинальный?
Принцип атаки, осуществляемой ТТК, довольно подробно описан здесь (способ с TCP-битом RST). Т.к. ТТК является провайдером доступа в Интернет, то для него осуществлять подобный вид MITM-атаки не представляет никакой технической или организационной сложности.
Sign up to leave a comment.
Преодоление блокировки в ТТК (Транстелеком) при помощи pf