Daniel Ginsburg ([info]dbg) wrote,
@ 2007-06-04 13:15:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Нынче модная тема в жж - блокировка слов ru_politics, ru_nbp и еще нескольких.

Цензура, гэбня, удушение свободы слова ...

Некоторые "проводят исследования" и "выясняют масштабы" (на самом деле глупо пиарятся, собирая ссылки на свой журнал): http://insie.livejournal.com/231258.html?style=mine.

Раздаются здравые голоса, что это борьба с DDoS'ом и "цензуру" проводит простой пакетный фильтр, который просто сбрасывает пакеты с ключевыми словами: http://zhuzh.livejournal.com/365653.html.

Разберемся.

Вот baseline:
$ tcptraceroute -n -w1 -m32 204.9.177.18 80
Selected device eth0, address 89.108.83.67, port 33940 for outgoing packets
Tracing the path to 204.9.177.18 on TCP port 80 (www), 32 hops max
 1  * * *
 2  88.212.194.49  0.274 ms  0.249 ms  0.248 ms
 3  88.212.192.65  1.045 ms  0.546 ms  0.312 ms
 4  217.150.45.194  0.712 ms  0.659 ms  0.542 ms
 5  213.248.72.161  58.356 ms  58.470 ms  58.904 ms
 6  80.91.254.6  56.990 ms  59.335 ms  56.187 ms
 7  213.248.65.157  66.138 ms  64.982 ms  63.803 ms
 8  80.91.249.251  130.342 ms  128.359 ms  125.505 ms
 9  213.248.80.73  150.702 ms  159.382 ms  148.196 ms
10  213.248.80.26  208.132 ms  194.752 ms  196.654 ms
11  63.65.130.45  195.336 ms  197.092 ms  196.518 ms
12  152.63.56.174  200.267 ms  196.824 ms  197.076 ms
13  152.63.88.138  214.208 ms  213.019 ms  210.511 ms
14  152.63.72.197  226.025 ms  225.946 ms  225.685 ms
15  157.130.173.50  225.469 ms  226.575 ms  225.318 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  204.9.177.18 [open]  224.118 ms  228.352 ms  227.686 ms


Звездочки с 16 по 29 хоп (у других количество этих звездочек будет другим) - явление само по себе довольно интересное и объяснимое, но не про них сейчас речь.

Проверяем гипотезу о пакетной фильтрации:
# cat rubeer
ru_beer
# cat rupol
ru_politics
#
# hping2 -S -p 80 -d 100 -E rubeer 204.9.177.18
HPING 204.9.177.18 (eth0 204.9.177.18): S set, 40 headers + 100 data bytes
[main] memlockall(): Success
Warning: can't disable memory paging!
len=140 ip=204.9.177.18 ttl=35 id=11233 sport=80 flags=SA seq=0 win=512 rtt=224.0 ms
len=140 ip=204.9.177.18 ttl=35 id=61206 sport=80 flags=SA seq=1 win=512 rtt=223.8 ms
len=140 ip=204.9.177.18 ttl=35 id=52314 sport=80 flags=SA seq=2 win=512 rtt=223.5 ms

--- 204.9.177.18 hping statistic ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max = 223.5/223.8/224.0 ms
#
# hping2 -S -p 80 -d 100 -E rupol 204.9.177.18
HPING 204.9.177.18 (eth0 204.9.177.18): S set, 40 headers + 100 data bytes
[main] memlockall(): Success
Warning: can't disable memory paging!

--- 204.9.177.18 hping statistic ---
4 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms


Обратите внимание, мы цепляли payload к SYN-пакетам. Приложение этих данных увидеть не может, следовательно, это действительно пакетный фильтр.

Выясняем где фильтр:
# hping2 -n --ttl 15 -S -p 80 -d 100 -E rupol 204.9.177.18
HPING 204.9.177.18 (eth0 204.9.177.18): S set, 40 headers + 100 data bytes
[main] memlockall(): Success
Warning: can't disable memory paging!
TTL 0 during transit from ip=157.130.173.50
TTL 0 during transit from ip=157.130.173.50
TTL 0 during transit from ip=157.130.173.50

--- 204.9.177.18 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#
# hping2 -n --ttl 64 -S -p 80 -d 100 -E rupol 204.9.177.18
HPING 204.9.177.18 (eth0 204.9.177.18): S set, 40 headers + 100 data bytes
[main] memlockall(): Success
Warning: can't disable memory paging!

--- 204.9.177.18 hping statistic ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms


Несложно видеть, что фильтр у самого ЖЖ. Единственное разумное объяснение этому - борьба с DDoS'ом, особенностью которого является присутствие ключевых слов в запросах к ЖЖ.



(Post a new comment)


[info]filonov
2007-06-04 09:23 am UTC (link)
вся эта история с ддос'ом пахнет банальным пеаром. А админам, как всегда, отдуваться.

(Reply to this) (Thread)


[info]dbg
2007-06-04 09:32 am UTC (link)
Уж кто и за что досит, я даже догадываться не буду.

(Reply to this) (Parent)


[info]ex_sighup150
2007-06-04 09:27 am UTC (link)
Ай, молодца :) Я только что прочёл про это счастье, и уж было взял в руки hping, как увидел твой пост :))

(Reply to this)


[info]_smith_
2007-06-04 09:43 am UTC (link)
Грамотно!

(Reply to this)


[info]paxvel
2007-06-04 11:05 am UTC (link)
ээ.. а сам-то ты https-ом чтоли постил?

(Reply to this) (Thread)


[info]dbg
2007-06-04 11:11 am UTC (link)
_

(Reply to this) (Parent)(Thread)


[info]paxvel
2007-06-04 11:23 am UTC (link)
и точно. пусть переименовываются в ру_амперсанд_хэш_95_семиколон_политикс %)

(Reply to this) (Parent)


[info]iskatel
2007-06-04 11:40 am UTC (link)
это не борьба с ddos. Это именно чистая цензура, пусть и топорно сделанная. Мне пофиг, сделаны это на уровне балансера или веб-сервера. Есть факт насчет цензуры.

Впрочем, я могу поверить при одном допущении - что ddos-ящие очень тупы. (иначе мне непонятно, отчего нельзя успешно задосить парочкой других методов, против которых такой подход бесполезен)

(Reply to this) (Thread)


[info]dbg
2007-06-04 11:46 am UTC (link)
В качестве цензуры такая мера бессмыслена. Смотри первую строчку моего поста. В качестве борьбы с DDoS'ом очень даже.

Что касается "парочкой других методов", то оперативная борьба с DDoS'ом - это всегда ad hoc меры. Есть атака - фильтруем по возможности как можно более специфично. Сменился паттерн - снимаем старый фильтр, ставим другой и т.д. пока атакующему не надоест.

(Reply to this) (Parent)


[info]nidd
2007-06-04 11:47 am UTC (link)
слушай, но ведь грепать весь входящий поток на определенное сочетание букв, особенно такое длинное как ру_политикс, этож сам маршрутизатор задосится!

(Reply to this) (Thread)


[info]dbg
2007-06-04 11:49 am UTC (link)
Неа. Это довольно просто и на гигабите вполне можно иметь line rate фильтрацию, особенно, если таких фильтров не очень много. 10GE так отфильтровать уже сложнее.

(Reply to this) (Parent)(Thread)


[info]dimiii
2007-06-04 02:17 pm UTC (link)
А что насчёт звёздочек?

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-04 02:27 pm UTC (link)
Оставлю читателю в качестве упражнения :)
Подсказка: посмотреть tcpdump'ом на ttl завершающего пакета при трассировке.

(Reply to this) (Parent)


[info]dbg
2007-06-04 02:39 pm UTC (link)
А черт, упражнения не получится. Они уже починили.
Selected device eth0, address 89.108.83.67, port 34232 for outgoing packets
Tracing the path to 204.9.177.18 on TCP port 80 (www), 32 hops max
 1  89.108.64.1  20.509 ms  0.410 ms  0.384 ms
 2  88.212.194.49  0.268 ms  0.258 ms  0.257 ms
 3  88.212.192.65  0.956 ms  0.362 ms  0.406 ms
 4  217.150.45.194  0.611 ms  0.534 ms  0.541 ms
 5  213.248.72.161  50.304 ms  50.274 ms  50.283 ms
 6  80.91.254.6  50.760 ms  50.510 ms  50.528 ms
 7  213.248.65.157  58.119 ms  58.470 ms  58.159 ms
 8  80.91.249.251  125.337 ms  125.285 ms  125.351 ms
 9  213.248.80.73  147.595 ms  147.520 ms  148.124 ms
10  213.248.80.26  192.335 ms  192.174 ms  249.527 ms
11  63.65.130.45  194.514 ms  194.578 ms  194.660 ms
12  152.63.56.174  196.566 ms  196.478 ms  196.460 ms
13  152.63.88.138  210.573 ms  210.609 ms  210.617 ms
14  152.63.72.197  225.674 ms  225.509 ms  225.683 ms
15  157.130.173.50  222.034 ms  222.086 ms  222.267 ms
16  * * *
17  204.9.176.19  244.246 ms  244.271 ms  244.388 ms
18  204.9.177.18 [open]  243.791 ms  243.819 ms  244.512 ms

В общем, дело в том, что некоторые железки посылают пакет, завершающий трассировку, с тем же ttl, с которым получили оригинальный пакет. Если ttl оригинального пакета недостаточен, то завершающий пакет просто не вернется. Признак такого поведения - ttl=1 у последнего ответа при трассировке.

(Reply to this) (Parent)


[info]ru_pchel
2007-06-04 08:31 pm UTC (link)
А можно пояснить - чем просто?
В любом случае надо заглядывать внутрь.

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-04 08:38 pm UTC (link)
Ну заглядываем внутрь, ну и что? Это не так сложно, как кажется. Да, это конечно, дороже, чем поглядеть на заголовки и форварднуть пакет. Но ничего совсем уж невыполнимого тут нет. Вот например: http://www.hoti.org/archive/Hoti11_program/papers/hoti11_07_dharmapurikar_s.pdf

(Reply to this) (Parent)(Thread)


[info]ru_pchel
2007-06-04 08:41 pm UTC (link)
Ссылочка не открывается.

Просто от свитчевания трафика, где можно затащить в control plane минимум, а то и вообще ничего не тащить, так все на модулях и оставить, просто переместив по внутренней шине, доходим до того, что надо еще пакетик прошерстить. Причем все пакетики.
Неплохая такая нагрузочка. При том, что место хранения информации в пакете точно не известно, и надо сделать какой-то из поисков, что само по себе тоже затратно.
По мне слишком хорошая загрузка на роутер.
Если конечно это все не в железе сделано в этих железках Тогда какие вопросы.

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-04 08:45 pm UTC (link)
У меня открывается. Хочешь, переложу к себе.
Ничего тащить на control plane не надо. Собственно, статья о том, как это реализуется на FPGA.

(Reply to this) (Parent)(Thread)


[info]ru_pchel
2007-06-04 08:48 pm UTC (link)
Хочу конечно
Интересно.

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-04 08:51 pm UTC (link)
http://ot-e.biz/hoti11_07_dharmapurikar_s.pdf

(Reply to this) (Parent)(Thread)


[info]ru_pchel
2007-06-04 09:07 pm UTC (link)
Прочитал, спасибо.

А почему 10GE так отфильтровать уже сложнее.?
И почему если таких фильтров не очень много?

В первом случае нам следует увеличивать мощности (грубо частоту) фильтрующего устройства
Во втором случае нам придется увеличивать кол-во параллельных блоков (фильтров Блума), которые работают в пакете. Один блок - на одну сигнатуру.

Вижу только одно узкое место. DDoS может запросто забить блок, который выполняет false positive filtering. Но здесь тоже можно увеличивать мощности и параллелить.

P.S.: Или я все не так понял? :)

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-04 09:16 pm UTC (link)
"Не очень много" - в смысле больше на порядки. Надо иметь больше хэшфункций чтобы false positives было не слишком много, надо иметь больше памяти, ибо сами строчки все равно приходится держать.

10G, наверное, тоже можно. Несколько кристаллов, между которыми делить нагрузку. Это небесплатно, как в смысле денег, так и в смысле энергопотребления/тепловыделения. Но я не специалист в hardware design, умные люди меня в случае чего поправят.

(Reply to this) (Parent)(Thread)


[info]ru_pchel
2007-06-04 09:22 pm UTC (link)
В приведенной статье ребята ловят 10К сигнатур, если не ошибаюсь.
Вполне себе ничего так.

Завтра распечатаю статью. Почитаю ее с карандашиком и mathcad-ом. Поглядим где там собака по производительности зарыта :)

(Reply to this) (Parent)


[info]azz_kikr
2007-06-05 06:07 am UTC (link)
это надо же! :) лет 5-6 назад я накатал сканер на блумовских
фильтрах для одной конторки (ну как обычно, ловили ключевые
слова, но еще надо было сделать так, чтобы база слов была "невидимой").
Я тогда про фильтры Блума узнал из сорцов Squid, а потом зачитал у Кнута.

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-05 07:11 am UTC (link)
Это случайно не тот хак над аськой, про который ты как-то рассказывал? :)

(Reply to this) (Parent)(Thread)


[info]azz_kikr
2007-06-05 03:28 pm UTC (link)
Изначально его для почты прикрутили, потом уже перешли на IM :)

А Для IM все еще хитрее было - строился граф связей между
респондетами, на ребра вешались различные веса (кол-во
сообщений X, log X, etc) и строились стандартные структуры
(e.g. spanning-tree, SPT)

Затем еще вычислялся "PageRank" (собственный вектор матрицы
весов) - много чего веселого получалось. Дальше - больше:
для ребер строились векторы ключевых слов (уже на этих фильтрах)
и проводилась баейсовская классификация. На таком, уже
раскрашенном, графе (ребру соотвествует класс - цвет), снова
вычислялось все вышеупомянутое.

А да, самое важное, конечно - сообщения сами не "накапливались",
чтобы не нарушать тайну личной жизни, переписки тп тп - собиралась
только статистическая информация :) Ну и дополнительно идентификаторы
абонентов подменялись на случайные числа, для анонимности.

В общем приколов было много а денег мало :) Потому вот снова сваливаю
в Брюссель, в пятницу лаба SP. Вернусь через недельку только, погуляю
еще чуток :)

(Reply to this) (Parent)(Thread)


[info]dbg
2007-06-05 03:31 pm UTC (link)
Удачи. :)

(Reply to this) (Parent)


[info]brusilov_14
2007-06-04 09:03 pm UTC (link)
Дядя - сервера на Западе ставятся как раз с запасом на случай таких вот случаев.
Это не Совдепия, где директору ставят последний Пень с турбовзлётом, а под сервак с ба-а-альшим скрипом выделяют бабло лишь на занюханый Атлон с полгигом оперативки от силы.

(Reply to this) (Parent)(Thread)


[info]nidd
2007-06-04 11:01 pm UTC (link)
че серьезно?

(Reply to this) (Parent)(Thread)


[info]ragingbender
2007-06-05 06:31 am UTC (link)
печально, но факт.
во многих конторах такое бывает. как в самых маленьких, так и в больших системных банках. чесно.

(Reply to this) (Parent)


[info]ariokh_dark
2007-06-05 09:34 am UTC (link)
Вас кто-то жестоко обманул.

(Reply to this) (Parent)


Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…