Пользователь
18,7
рейтинг
3 сентября 2013 в 15:53

Администрирование → Изучаем deep packet inspection у RETN

Новость: Магистральный провайдер RETN, не смотря на то, что он магистральный, осуществляет фильтрацию трафика посредством DPI. Поскольку оператор он магистральный, и, в частности, занимается доставкой зарубежного трафика, то на выходе мы имеем цензуру для многих провайдеров, в том числе и тех, кто чхать хотел на всякие «запретные списки», но имеют RETN в аплинках.

DPI — совокупное название технологий, при которых оборудование «залезает» во внутрь трафика, то есть реагирует не только на заголовки пакетов разного уровня, но и на содержимое.

Во избежание помех тест проводился из нескольких городов и с нескольких провайдеров, что позволило исключить фактор локальных провайдерских фильтраций (второй, косвенный тест основывался на использовании TTL-сканирования, который всегда указывал на район RETN'а).

Посмотрим, как именно RETN осуществляет DPI, ревностно исполняя законы о защите наркотиков от суицидальных порнографических детей, нарушающих авторские права.

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

Адрес этого поста внесён в список запрещённых к просмотру гражданами Российской Федерации. В связи с этим я осуществил необратимые манипуляции с доменным именем журнала таким образом, чтобы не существовало ни одного достоверного и однозначного алгоритма обращения получившейся хеш-функции.

Посмотрим на бытовые симптомы проблемы:

wget -d --tries 1 stervozzinka.dreamwidth.og/15580.html

Рядом на консоли запускаем tcpdump host stervozzinka.dreamwidth.og

17:17:14.376828 IP local.49510 > dreamwidth.og.http: Flags [P.], seq 1:136, ack 1, win 115, options [nop,nop,TS val 11199749 ecr 1627034663], length 135
17:17:17.924801 IP local.49510 > dreamwidth.og.http: Flags [P.], seq 1:136, ack 1, win 115, options [nop,nop,TS val 11200636 ecr 1627034663], length 135
17:17:18.068805 IP local.49509 > dreamwidth.og.http: Flags [P.], seq 1:136, ack 2, win 115, options [nop,nop,TS val 11200672 ecr 1627029045], length 135


Одинаковый seq — признак перепосыла сегмента. Но понять, где блокируют (на получении ответа или на отправке запроса) мы не можем. Но точно видим, что таки блокируют, ибо просто так TCP-сегменты не перепосылают.

Переключимся со своевольного wget'а на что-то попроще, чтобы точно контролировать отправляемое:

echo -e "GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80
Это нас никак не продвинет, однако даст некоторую свободу экспериментировать с заголовками. Указанный запрос так же блокируется.

А вот для вариаций (которые нарушение RFC, но varnish'ем со стороны dreamwidth обрабатываются нормально) мы можем увидеть некоторые особенности:

  • GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n" (два пробела после GET) — пускает
  • GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (два пробела перед HTTP/1.1 — не пускает
  • get /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (get маленькими буквами) — пускает
  • GET /15580.html HTTP/1.1\nIgnore:me\nHost: stervozzinka.dreamwidth.og\n (лишний заголовок между GET и HOST) — не пускает


Предварительный вывод — скучный и примитивный exact matching. Если так, то как оно понимает, что из содержимого пакета заголовок, а что нет?

Так что…

echo -e "GET /15580.html\n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80 — не пускает.

Для тех, кто не понял — я поставил два перевод строки после GET, то есть Host уже относится к телу, а не к заголовку. А ещё я убрал HTTP/1.1, то есть это plain HTTP 1.0, у которого не бывает заголовка Host, то есть мы запросили /15580.html с сервера без указания на hostname.

Заметим, запрос без hostname работает: GET /15580.html \n\n

Другими словами, мы видим, что DPI проверяет что-то совсем несусветное — наличие Host в BODY. В результате дропаются запросы, к блокируемому сайту не имеющие никакого отношения.

Усложним эксперимент:
echo -e «POST /\n\nА ты знаешь, что они банят по содержимому? Например: GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80

Ой, ой, ой. Нам забанили отправку POST'а с невинным содержанием. Этот POST не дошёл до сервера. Не может быть?

Давайте проверим, и отправим пост более культурными методами:

curl -d "GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n" dreamwidth.og

Наше предположение — фильт требует наличия обоих строчек в одном пакете и не проверяет его валидность:

curl --connect-timeout 10 -d "GET /15580.html\n`seq 1 10000`\nHost: stervozzinka.dreamwidth.og\n" 69.174.244.50

Проходит. Это означает, что пакете должны быть оба заголовка. (да-да, если мы напишем такой запрос на сервер, у которого Host: в заголовке пойдёт другим пакетом, то, возможно, мы сможем пробить цензуру.

Ещё одна проверка: проверяют ли люди номер порта?
echo -e "GET /\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443
(пустой ответ)

echo -e "GET /15580.html\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443
(таймаут)

Нет. Трафик на 443ий порт фильтруют с тем же успехом (пропускают обычный, дропают „запрещённый“).

Ещё одна проверка: фильтруют ли по IP? Находим соседний (из того ж сегмента) открытый IP, отвечающий на 80ом порту. Пускают.

Итог



Условия для дропа пакета:
  • На любом порту TCP (UDP не проверялось)
  • С любыми флагами
  • По фактическому наличию в пакете (в любом порядке) строк
    • GET /15580.html
    • Host: stervozzinka.dreamwidth.og
  • Совпадению src_IP с указанным в списке для запрета


Таким образом, это больше напоминает packet filter с поиском сигнатур без регэкспов в проходящих пакетах, а вовсе не не настоящий DPI.
Георгий Шуклин @amarao
карма
269,0
рейтинг 18,7
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (57)

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

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

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

      Tracert после этого мне выдал тот же RETN
      • 0
        Ха, а вот это забавно.
        • 0
          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]  сообщает: Заданная сеть недосту
          пна.


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

    Хм… А у меня открывается страница. Хороший провайдер. =)
  • 0
    Журнал был заблокирован? А у моего провайдера весь Dreamwidth не открывался… Но VPN никто не отменял :-)
    • 0
      Он всё ещё заблокирован.
  • 0
    Бить запрос на пакеты помельче и exact matching не сработает. Интересно, это конструктивное ограничение (один пакет) или просто нюанс настройки DPI…
    • 0
      Проще просто поставить второй пробел между Host: и адресом.
      • 0
        Это поправить в правиле DPI намного легче. А вот обработка потока из нескольких частей (=нескольких пакетов, которые составляют одну сущность) — уже сильно меняет структуру обработки потока в DPI. Надо копить пакеты, ждать определенное время других частей пакета, определять — есть ли ещё части, клеить приходящие части в один пакет и каждый раз проверять — а достаточно ли мы получили, чтобы проверить на соответствие правилу? А это всё память, ресурсы, такты. Это кардинально другая штука по сравнению «пришел пакет -> пропустить/дропнуть».
  • 0
    Я думаю, у Кипчатова можно узнать подробности, kipchatov.ru/
  • 0
    Забавно что в Украине ваш реестр тоже работает :)
    Киевстар тоже использует РЕТН и при попытке открыть искомую страницу мне в Укриану прилетает страничка о её блокировке (причём прилетает как редирект на блайн/корбина телеком :)
    Для чистоты эксперемента попросил друзей из Финляндии открыть — у них оригинал открывается.
    И спрашивается — это лень админов магистрального провайдера отделить запросы из Украины или как?
    • 0
      У меня нет достоверных доказательств (TTL-тестирование для TCP весьма спорная штука), но по косвенным признакам выглядело так, что фильтрация идёт на выходе из сети RETN'а, то есть на последнем (или предпоследнем) маршрутизаторах перед Амстердамом.

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

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

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

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

        nemesis --help
        TCP options:

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

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

        net-geek.org/dbg/2009/12/yota-scandal.html
  • –1
    Я что-то сильно сомневаюсь что у магистрального провайдера могут в принципе стоять DPI. Чтобы так фильтровать траффик на 1 Тб/c, надо купить оборудования на несколько миллионов долларов
    • 0
      Думаете, это так неподъемно? Не теми масштабами мыслите.

      www.vedomosti.ru/tech/news/15832871/filtr-dlya-rostelekoma

      Стартовая цена конкурса — 1,12 млрд руб.
      • 0
        Это для мобильной сети, на широкополоску затраты будут на два порядка больше.
  • 0
    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».

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