Pull to refresh

Comments 57

Можно так обходить защиту, выставляя длинные куки. Если, конечно, они передадутся до Host
1) Бан по dns обошёл при помощи dns google (8.8.8.8).
2) Бан по ip сменив провайдера.
После этого не открывалась только эта страничка.

3) Бан по адресу добавив ещё один слеш в адрес.
stervozzinka.dreamwidth.og//15580.html

Можно это дело автоматизировать даже ))

Tracert после этого мне выдал тот же RETN
Ха, а вот это забавно.
C rublacklist всё сложнее.

Трассировка маршрута к rublacklist  [213.144.23.25]
с максимальным числом прыжков 30:

...
   7    46 ms    48 ms    49 ms  te-4-1.bb-c.act.fra.de.oneandone.net [212.227.12
0.130]
  8    47 ms    52 ms    46 ms  ae-3.bb-d.fra3.fra.de.oneandone.net [212.227.120
.89]
 9    48 ms    45 ms    48 ms  te-2-3.bb-d.bs.kae.de.oneandone.net [212.227.120
.29]
 10    49 ms    48 ms    45 ms  ge-6-3-rmt.bb-d.bs.kae.de.oneandone.net [212.227
.34.234]
 11  10g.rt2ipc1.ka.telemaxx.net [81.26.160.54]  сообщает: Заданная сеть недосту
пна.


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

Хотел базу айпишников скачать.
3.1) Ещё вариант как HTTP прокси задать IP адрес и порт (80) заблокированного хоста. Я так на RedTube хожу теперь. Для того чтобы не ломиться на остальные сайты через него же пользую локальный файл proxy.pac который и выбирает как идти на сайт. Но один заблокированный сайт мне попался который не понял такого запроса.

Вариант с модификацией хедеров

3.2) Если хедер Host: www.… маленькими буквами буквами тоже проходим.

get маленькими буквами некоторые сайты не любят больше чем host.

Важно что при этих манипуляциях часто получаем адекватный ответ от сервера а не ошибку или редирект.
Упс, сорри, пропустил ключевую фразу.
Думаю всё-таки org, так как у днс серверов нет никакой информации о «stervozzinka.dreamwidth.og»
Если пост прочитать ещё раз, то появится.
Здесь нигде не написан полный урл, так что все в порядке =)
Основание? В реестре зарпещённых сайтов нет ни одного сайта из зоны ".og".
Не-не-не, я понял комментарий так, что автор комментария считает ".og" опечаткой, и что должно быть написано ".org".
Ибо зоны .og не существует в природе
:)
К пуговицам претензии есть?
Интересная статейка. Спасибо.
Нельзя не поставить жирный плюс и за эту фразу:
Посмотрим, как именно RETN осуществляет DPI, ревностно исполняя законы о защите наркотиков от суицидальных порнографических детей, нарушающих авторские права.
модно, стильно, молодёжно. а главное — остроумно.
Странно, почему в браузерах до сих пор нет кнопки «пересылать http-запрос по одному байту в пакете». Не думаю, что есть DPI магистрального уровня, способные такое отловить — слишком большие скорости и нагрузки.
Из разряда вредных советов потому что: возрастет нагрузка на канал/устройства. Да и складывать эту «колбасу» воедино потом как-то нужно. А если подумать, от скольки источников необходимо будет принимать, вообще грустно становиться.
А кто говорит использовать это для всех сайтов по умолчанию?
Кнопка — она кнопка и есть: видишь что сайт заблокирован — жми кнопку и заходи, пусть и медленнее обычного.

А колбасу эту складывать TCP с рождения умеет, тут волноваться нечего.
А с нагрузкой что делать? Пакетов из-за избыточности станет больше как минимум в 4 раза больше с одного клиента.
Речь об отправке пакетов размером 1 байт. Соответственно железки у провайдера по фильтрам ничего не найдут в каждом отдельном пакете, а складывать пакеты воедино для них будет слишком затратно. Со стороны сервера никаких изменений, со стороны клиента в плане сбора ответа — тоже без изменений, всё сделает TCP. Да, скорость будет не ахти, но в случае отсутствия альтернативы — вполне неплохой вариант.
Против блокировок по IP — не поможет. А они — самые разрушительные.
И тут мы включаем прокси…
Потому что браузер — это L7. А tcp — это L4 и занимается этим ОС. И как tcp отправляет данные — сугубо фиолетово вышележащим уровням. И надеяться, что уходить данные будут именно теми порциями, какими вы скарлимаваете их тсп с вышележащего уровня — нельзя. Пришел от удаленной стороны win 0 (ну не может удаленная сторона временно принимать наши данные) — и у нас копится буфер. Потом он начнет опорожняться, когда удаленная сторона прочихается. И вся ваша нарезка — собьется.

net-geek.org/dbg/2007/10/reading-tcp-socket.html

Так что DPI изначально это умеют (читать именно tcp поток), если это конечно полноценная DPI, а не простой match ip пакетов, как предполагает автор топика.
Уважаемый, ну не думаете же Вы, в самом деле, что ssh клиент получит данные от sshd-сервера только когда этих данных наберется полный буффер для передачи?

Что касается DPI vs packet match — мой исходный пост как раз о том, что магистральные нагрузки не предполагают использования полноценной DPI.
По ссылке как раз разобран случай, очень похожий на интерактивный трафик. В общем случае оно будет работать, но совсем не обязано. И наглядно показано, как необоснованные надежды могут быть развеяны.
Если у вас Линукс, то этого можно добиться, подкрутив настройки протокола TCP командами:

sysctl net.ipv4.tcp_rmem="<желаемое количество байт в пакете> <желаемое количество байт в пакете> <желаемое количество байт в пакете>

и
sysctl net.ipv4.tcp_wmem="<желаемое количество байт в пакете> <желаемое количество байт в пакете> <желаемое количество байт в пакете>"


Да, одно и тоже число следует повторить три раза. Первая команда влияет на входящие данные, а вторая — на исходящие.
Осторожно: если поставить мало, то TCP будет работать очень медленно, как будто на том конце кто-то неспешно набирают ответ вручную.
Я не уверен, что это адекватно будет обработано существующими congestion алгоритмами. В конце-концов, slow start происходит не с бухты-барахты, да и, вероятнее всего, стек всё равно туда сначала в районе MTU запихает.
Если значение маленькое, то проблем быть не должно.

Эти три числа задают, соответственно, минимальный, дефолтный, и максимальный размер буфера, в котором накапливаются данные для одного TCP-соединения, которые нужно отправить или принять. Поэтому ядро не сможет послать за раз больше, чем максимальный размер буфера(чем последнее число).
Ну логично, что не полноценный DPI, ибо это дешевле. WCCP + access_list основанный на запретных ip и далее пересылка тех пакетов которые попадают в acess_list на squid для анализа url, дешево и практично, остальное напрямую, чтобы не нагружать squid бесполезной работой. Причем можно делать матчинг только по 80 порту, ибо обычно требуют только его закрыть.
А можно накормить магистрального провайдера какими-то запросами чтобы он тратил излишне много ресурсов на проверки?
В текущем виде нет, так как такие штуки реализуются на уровне ПЛИС маршрутизатора (или специализированной железки) и обрабатываются со скоростью среды.

А вот жаловаться на проблему с прохождением пакетов, у которых в теле есть подобные сигнатуры можно, т.к. сами сигнатуры не запрещены, а запрещён доступ к сайту.
Я бы лучше оставил, как есть. Это не вина провайдера и данный механизм позволяет хотя бы не резать лишние адреса на том же ip
Хэш функция обработки домена работает по открытому алгоритму? А то security through obscurity — сами понимаете… :-D

Открытому, открытому. Думаю, все cryptography experts сумели легко восстановить алгоритм по его специфичным сигнатурам.
За основу возьмём широко известный журнал Стервозинки (широко известен он только тем, что был заблокирован, заблокирован за какую-то нелепицу, причём заблокирован давно, и из бана выползать не собирается).

Хм… А у меня открывается страница. Хороший провайдер. =)
Журнал был заблокирован? А у моего провайдера весь Dreamwidth не открывался… Но VPN никто не отменял :-)
Он всё ещё заблокирован.
UFO just landed and posted this here
Проще просто поставить второй пробел между Host: и адресом.
UFO just landed and posted this here
Забавно что в Украине ваш реестр тоже работает :)
Киевстар тоже использует РЕТН и при попытке открыть искомую страницу мне в Укриану прилетает страничка о её блокировке (причём прилетает как редирект на блайн/корбина телеком :)
Для чистоты эксперемента попросил друзей из Финляндии открыть — у них оригинал открывается.
И спрашивается — это лень админов магистрального провайдера отделить запросы из Украины или как?
У меня нет достоверных доказательств (TTL-тестирование для TCP весьма спорная штука), но по косвенным признакам выглядело так, что фильтрация идёт на выходе из сети RETN'а, то есть на последнем (или предпоследнем) маршрутизаторах перед Амстердамом.

Так что фильтрация украинских GET'ов мало отличается от фильтрации русских GET'ов — и там и там фильтруется весь выходящий из сети трафик.
тоесть если кто то внезапно подключился к RETN где нибудь в Амстердаме то он тоже будет наблюдать заглушку?
С большой вероятностью, да. Не думаю, что там кто-то смотрит геоданные по IP на каждом проходящем пакете.
это лень админов магистрального провайдера отделить запросы из Украины или как?

Это лень законодателей точно сформулировать, где и что блокировать. =)
Вы написали — с любыми флагами. Что-то в статье не видно проверок (или я пропустил?), везде подразумевается метод tcp-коннект. Было бы интересно проделать что-то типа

net-geek.org/dbg/2007/06/lj-banned-words.html
"… Обратите внимание, мы цепляли payload к SYN-пакетам..."
О, а опция -E всего лишь потроха tcp берёт, а не полностью raw пакет? Спасибо, легче TTL тестирование делать будет.
Видимо только тсп-пайлоад.

Есть альтернативы. Возможно остинато это умеет. Я пользовался олдовым nemesis

nemesis --help
TCP options:

-P Это точно то, что нужно.

Вот еще одно расследование от того же чела.

net-geek.org/dbg/2009/12/yota-scandal.html
Я что-то сильно сомневаюсь что у магистрального провайдера могут в принципе стоять DPI. Чтобы так фильтровать траффик на 1 Тб/c, надо купить оборудования на несколько миллионов долларов
Это для мобильной сети, на широкополоску затраты будут на два порядка больше.
ingvarr.net.ru/publ/6-1-0-5384

1,64 Петабайта мобильного трафика за один квартал в 2011 году в Украине. На дворе 2013.

telekomza.ru/2013/02/11/cisco-k-2017-godu-obem-mobilnogo-trafika-vyrastet-v-13-raz/

"… И, наконец, в 2017 году объем мобильного трафика превысит объем трафика фиксированной широкополосной связи."

Это конечно все пока слова. Но DPI уже есть и у МТС и у Вымпелкома. Не думаю, что они не закложились на рост ближайших лет. И да, речь ведь не о суммах денег, а о том, могут ли себе их некоторые позволить. По факту — могут и позволяют.
Обсуждается ведь фраза «Я что-то сильно сомневаюсь что у магистрального провайдера могут в принципе стоять DPI».
Sign up to leave a comment.

Articles