Daniel Ginsburg ([info]dbg) wrote,
@ 2007-06-05 20:03:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Ко вчерашнему.

Некоторые могли обратить внимание, что если пойти на http://community.livejournal.com/ru_politics, будучи незалогиненым, то ЖЖ честно покажет "This journal has been suspended.". А если пойти залогиненым, то ВСЕ ОПЯТЬ ПОВИСНЕТ, АААА!!!! Псы Тоталитарного Режима отслеживают невинных пользователей, интересующихся крамольным коммьюнити, и берут на карандашик!!! Страшно?

Разберемся.

Когда мы залогиненными идем на http://community.livejournal.com/ru_politics, ЖЖ нас перенаправит на URL вида http://community.livejournal.com/ru_politics/__setdomsess?dest=http://community.livejournal.com/ru_politics&k=ljdomsess.community.ru_politics&v= ....
Вот так вот у ЖЖ хитрО устроена схема авторизации.

Попробуем подсократить. Не логинясь, пойдем на http://community.livejournal.com/ru_politics/ - в конце ULR слеш. Опять все висит. Вот оно. Становится понятней.

Проверям (невалидным HTTP запросом, его валидность нам не важна):
$ telnet  204.9.177.18 80
Trying 204.9.177.18...
Connected to 204.9.177.18.
Escape character is '^]'.
GET /ru_politics

Параллельно запускаем tcpdump:
# tcpdump -S -nl -s0 host 204.9.177.18 and port 80
19:59:58.223493 IP 89.108.83.67.36117 > 204.9.177.18.80: S 516335794:516335794(0)
win 5840 <mss 1460,sackOK,timestamp 19335704 0,nop,wscale 0>
19:59:58.443826 IP 204.9.177.18.80 > 89.108.83.67.36117: S 845985459:845985459(0)
ack 516335795 win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 1054158263 19335704,
nop,nop,sackOK>
19:59:58.443858 IP 89.108.83.67.36117 > 204.9.177.18.80: . ack 845985460 win 5840
<nop,nop,timestamp 19335726 1054158263>
20:00:00.316302 IP 89.108.83.67.36117 > 204.9.177.18.80: P 516335795:516335813(18)
ack 845985460 win 5840 <nop,nop,timestamp 19335914 1054158263>
20:00:00.636080 IP 204.9.177.18.80 > 89.108.83.67.36117: . ack 516335813 win 4398
<nop,nop,timestamp 1054160456 19335914>
Все пролезло, к нам прилетел ACK.

Пробуем со слешом:
$ telnet  204.9.177.18 80
Trying 204.9.177.18...
Connected to 204.9.177.18.
Escape character is '^]'.
GET /ru_politics/
Опять смотрим tcpdump'ом:
# tcpdump -S -nl -s0 host 204.9.177.18 and port 80
20:00:15.680079 IP 89.108.83.67.36119 > 204.9.177.18.80: S 535122460:535122460(0)
win 5840 <mss 1460,sackOK,timestamp 19337450 0,nop,wscale 0>
20:00:15.900485 IP 204.9.177.18.80 > 89.108.83.67.36119: S 1002706682:1002706682(0)
ack 535122461 win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 1054175719 19337450,
nop,nop,sackOK>
20:00:15.900507 IP 89.108.83.67.36119 > 204.9.177.18.80: . ack 1002706683 win 5840
<nop,nop,timestamp 19337472 1054175719>
20:00:20.709008 IP 89.108.83.67.36119 > 204.9.177.18.80: P 535122461:535122480(19)
ack 1002706683 win 5840 <nop,nop,timestamp 19337953 1054175719>
20:00:21.794070 IP 89.108.83.67.36119 > 204.9.177.18.80: P 535122461:535122480(19)
ack 1002706683 win 5840 <nop,nop,timestamp 19338062 1054175719>
20:00:23.974075 IP 89.108.83.67.36119 > 204.9.177.18.80: P 535122461:535122480(19)
ack 1002706683 win 5840 <nop,nop,timestamp 19338280 1054175719>
20:00:28.334092 IP 89.108.83.67.36119 > 204.9.177.18.80: P 535122461:535122480(19)
ack 1002706683 win 5840 <nop,nop,timestamp 19338716 1054175719>
20:00:37.054082 IP 89.108.83.67.36119 > 204.9.177.18.80: P 535122461:535122480(19)
ack 1002706683 win 5840 <nop,nop,timestamp 19339588 1054175719>
А вот и ретрансмиты.

Судя по всему, атака не прекратилась, но ЖЖ стал умнее и теперь режет пакеты по строчкам 'GET /ru_politics/', 'POST /ru_politics/' и т.д. Причем, строчка должна быть в самом начале TCP-payload. Т.е. пост с этими строчками проходит (правда, с накоторой вероятностью может обломаться).

В общем, жжшным сисадминам за борьбу с DDoS'ом четверка. Была бы пятерка, если б они так сделали сразу.

(Post a new comment)


[info]nidd
2007-06-05 04:27 pm UTC (link)
А че, нельзя сделать маленький MTU и чтобы оно посылалось строчками GE ru _p ol itics?

(Reply to this) (Thread)

[info]dbg
2007-06-05 04:31 pm UTC (link)
Да можно, конечно. Но у атакующего цель нарушить работы атакуемой системы, а не своего ботнета :)

И еще раз скажу, что тактическая (не стратегическая) борьба с DDoS'ом - всегда ad hoc. Идет атака с этим паттерном, с этих хостов - фильтруем эти, пойдет с других - будем фильтровать другие. В данной ситуации ЖЖ справляется неплохо.

(Reply to this) (Parent)

[info]paxvel
2007-06-05 04:38 pm UTC (link)
too much free time :)

(Reply to this) (Thread)

[info]dbg
2007-06-05 04:39 pm UTC (link)
Ладно тебе, я ж после трудового дня развлекаюсь :)

(Reply to this) (Parent)

[info]ivlad
2007-06-05 08:07 pm UTC (link)
люблю я тебя за то, что ты в такой хуйне, как истерика вокруг ДПНИ и прочего, найдешь пищу для ума. и поделишься.

(Reply to this) (Thread)

[info]dbg
2007-06-05 08:11 pm UTC (link)
Ну, должен же я найти среди всего этого безумия кусочек для своего гиковского счастья :)

(Reply to this) (Parent)

[info]dbg
2007-06-05 08:15 pm UTC (link)
На самом деле, я бы с огромным удовольствием прочитал подробный технический отчет о том, что происходило, когда все это закончится.

(Reply to this) (Parent)(Thread)

[info]ivlad
2007-06-06 03:48 am UTC (link)
мне почему-то кажется, мы его не увидим :(

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 06:44 am UTC (link)
Не увидим. Ибо они будут привлекать к разборкам своих американских ментов. А это значит, что публично им сказать будет ничего нельзя.

(Reply to this) (Parent)

[info]silpol
2007-06-30 12:12 pm UTC (link)
можно записаться в "кружок по интересам", и там даже расскажут и покажут, только вот членство там не дешевое... но невозможного ничего нет ;)

(Reply to this) (Parent)

[info]ivlad
2007-06-06 10:37 am UTC (link)
вот тебе еще в копилку: http://abstract2001.livejournal.com/615069.html

(Reply to this) (Thread)

[info]ivlad
2007-06-06 11:47 am UTC (link)
впрочем, там ответили: http://abstract2001.livejournal.com/615069.html?thread=9866909#t9866909

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 11:53 am UTC (link)
Да, я увидел. Там действительно приезжает win=0, а потом window update. Вот сижу думаю, что за хня. Скорее всего какой-то слишком умный мидлбокс, хотя не знаю. Пока идеи нет.

(Reply to this) (Parent)(Thread)

[info]ivlad
2007-06-06 12:04 pm UTC (link)
ну, да, какой-нить балансировщик нагрузки, только на что он рассчитывает таким поведением, я не очень понимаю...

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 01:46 pm UTC (link)
Я нашел ту статью на юзениксе, в которой я читал про похожее:
http://216.239.59.104/search?q=cache:pb-LK-0jrfAJ:www.usenix.org/events/nsdi07/tech/full_papers/mahimkar/mahimkar.pdf+dFence+%22zero+window%22&hl=ru&ct=clnk&cd=2&gl=ru

Network-based SYN cookie generation. Our policy for
mitigating spoofed SYN floods is shown in fig. 4. It is
based on the well-known idea of SYN cookies [4, 20],
except that, unlike the traditional approach, we do not
require any modifications to the server TCP software.
After a dFence middlebox M has been dynamically
introduced into all routes to some host S that is experi-
encing a denial of service attack, all traffic to S passes
through M. On receipt of a SYN packet whose desti-
nation is S, the middlebox computes the SYN cookie as
a cryptographic hash of connection parameters and the
(frequently re-generated) local secret, adds the value of
the cookie to the sequence number in the SYN packet,
and uses it as the sequence number in its SYN-ACK re-
sponse. No state is established at the middlebox at this
stage.
Note that in the SYN-ACK response, the middlebox M
sets the receiver window size to zero. Upon receiving the
SYN-ACK with zero window size, C sends back an ACK
packet and then enters the TCP Persist Mode. While in
this state, C is not allowed to send any data packets with
non-zero payload. So M effectively “chokes” C. M
can “unchoke” C later by sending it any packet with a
non-zero window size. If M receives data packets from
C before the handshake with S is complete, it marks C
as non-conforming and simply drops all further packets
from C.

(Reply to this) (Parent)

[info]dbg
2007-06-06 02:04 pm UTC (link)
Да, это точно middle box, который отыгрывает 3way handshake перед сервером.

Если посмотреть на успешную сессию, например, такую, как показано здесь: http://abstract2001.livejournal.com/615069.html?thread=9876637#t9876637
То можно заметить, что TTL приходящих оттуда пакетов меняется:
SYN/ACK мне прилетел с TTL=242, window update тоже, а дальше все начало валиться с TTL=51.

(Reply to this) (Parent)

[info]dbg
2007-06-06 02:22 pm UTC (link)
И презабавнейший мидлбокс, надо сказать. Принимает соединения на все порты. :)

(Reply to this) (Parent)

[info]dbg
2007-06-06 02:33 pm UTC (link)
Эксперименты с другими портами показали вот что. Если идти на порт, скажем, 666, то этот мидлбокс примет соединение, анонсирует win=0, а клиент будет долбиться со своими zero window probe. Т.е. будет наблюдаться в точности такая же ситуация, как у тех, кто не может получить доступ. Видимо, этот мидлбокс отыгрывает 3-way handshake с клиентом, потом сразу же с сервером, и если с сервером удалось, то посылает клиенту window update.

Остается вопрос, почему у одних работает, у других нет? Пока теория происходящего состоит в том, что этот мидлбокс - лоадбалансер. Одних клиентов он форвардит на живой сервер, других на дохлый. Но как удостовериться в этом точно, я пока не придумал. Буду думать дальше.

(Reply to this) (Parent)(Thread)

[info]ivlad
2007-06-06 03:23 pm UTC (link)
> Но как удостовериться в этом точно, я пока не придумал. Буду думать дальше.

если исходить из предположения, что сервера там хотя бы 3, причем один из них лежит, можно попытаться найти разницу в ответах web-сервера при приходе из разных мест в расчете на попадание на разные серверы. сюдя по http://abstract2001.livejournal.com/615069.html?thread=9910429#t9910429 балансировка нагрузки осуществляется вне зависимости от ASки, что, кстати, позволяет исключить идею с эникастом, которая грела мне душу полчаса по пути домой, пока я не прочитал твой последний коммент, итого, там либо банальный round-robin, возможно, с какой-то persistency (как по-русски), привязанной к ip, либо хеш ip на поле размера количества серверов. тогда, правда, идея с 3 серверами туманна, потому что балансеры вечно норовят нормально балансировать только на степени двойки.

вторым вариантом может быть поискать разницу в заголовках IP и TCP (с надежной на отсутствие нормализации трафика в мидлбоксе) после хендшейка. если б можно было заставить удаленный хост поставить TCP Timestamp, например. Или найти разницу в IPid, по-моему, их так никто случайным образом и не генерирует.

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 03:38 pm UTC (link)
Надо еще напороться на два разных работающих.

(Reply to this) (Parent)

[info]dbg
2007-06-06 03:46 pm UTC (link)
Вот тебе пакетные дампы: http://ot-e.biz/kasp-addr1.pcap и http://ot-e.biz/kasp-addr2.pcap
Первый неудачный, второй удачный.
Вдруг оно тебя на какую мысль наведет.

(Reply to this) (Parent)

[info]dbg
2007-06-06 02:37 pm UTC (link)
Ну до кучи, просто чтобы сказать явно. Этот мидлбокс стоит на той стороне, в чем нетрудно убедиться tcptraceroute'ом.

(Reply to this) (Parent)

[info]dbg
2007-06-06 03:22 pm UTC (link)
Хех. Версия про кривой LB находит свое подтверждение. Ты ведь помнишь, что на мальпасе два адреса. Идем с одного, получаем проблему. Идем с другого, все работатет отлично. Все в пределах одной сети, все в пределах одной машины. tcptraceroute с обоих адресов, естественно, одинаковый.

Гэбня, бля, цензура, бля.

Как думаешь, делать отдельный пост?

(Reply to this) (Parent)(Thread)

[info]ivlad
2007-06-06 07:26 pm UTC (link)
> Как думаешь, делать отдельный пост?

Угу, а то меня эти бессмысленные тренинги и непрекращающиеся пресейлы утомили :)

(Reply to this) (Parent)

[info]dimrub
2007-06-06 07:57 pm UTC (link)
Здорово! Осталось определить, какой именно LB там стоит (вот позорище-то будет, если WSD).

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 08:03 pm UTC (link)
Вот пока у меня нет идей, как бы это провернуть. Так что я с благодарностью приму советы.

(Reply to this) (Parent)(Thread)

[info]dimrub
2007-06-06 08:05 pm UTC (link)
Пока кроме как тупо гуглить на "web load balancer window size SYN" ничего в голову не приходит. Вот, кстати, приколитесь:

http://lippard.blogspot.com/2006/07/craigslist-no-longer-uses-tcp-window.html

Звучит знакомо? :)

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 08:09 pm UTC (link)
Да, да, да. Очень, очень похоже.

(Reply to this) (Parent)

[info]dimrub
2007-06-06 08:09 pm UTC (link)
Тэк-тэк-тэк... Есть подозрение, что это f5, BIG-IP:

http://www.f5.com/solutions/technology/pdfs/BIGIPV9Security_White_Paper.pdf

One type of Denial of Service attack is known as a SYN flood, in which an attack is
launched for the purpose of exhausting a system's resources, leaving it unable to establish
legitimate connections. The BIG-IP system's SYN CHECK feature works to alleviate SYN
floods by sending cookies to the requesting client on the server's behalf, and by not
recording state information for connections that have not completed the initial TCP
handshake. This unique feature

И так далее.

Админу, который поставил LB, и не наладил на нем health checks, надо отрывать конечности.

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 08:11 pm UTC (link)
Отлично! Как же оно у меня сразу не нагуглилось.
Насчет конечностей согласен стопроцентно.

(Reply to this) (Parent)(Thread)

[info]swix
2007-06-07 03:27 am UTC (link)
Там не конечности, там иное отрывать надо. Чтобы не размножались...

(Reply to this) (Parent)

[info]nuclight
2007-06-07 06:32 am UTC (link)
Это может быть еще и OpenBSD'шный pf со включенным synproxy. На FreeBSD ео портировали тоже. Фича та же - устанавливает соединение сначала сам, соответственно, чтоб данные не ходили, пока он не закончит, используется нулевое окно.

(Reply to this) (Parent)(Thread)

[info]dimrub
2007-06-07 08:29 am UTC (link)
Эти бы, однако, использовали стандартный SYN cookie, наверное, а тут - что-то задумчивое. Думаю, все же, f5: с них бы сталось сделать свою имплементацию, без постоянных битов, чтобы дополнительно озадачить потенциальных хакеров.

(Reply to this) (Parent)

[info]kyprizel
2007-06-07 11:10 am UTC (link)
http://community.livejournal.com/lj_dev/496186.html?thread=4517178#t4517178

(Reply to this) (Parent)(Thread)

[info]dimrub
2007-06-07 11:13 am UTC (link)
Ну дык, популярная штука вполне, наравне с киской. Я совершенно не удивлюсь, если солидный (?) провайдер layer42.net пользуется этим делом для своих клиентов.

(Reply to this) (Parent)(Thread)

[info]kyprizel
2007-06-07 11:31 am UTC (link)
они немного разного уровня с киской ) причем не в пользу киски :))

(Reply to this) (Parent)(Thread)

[info]dimrub
2007-06-07 11:35 am UTC (link)
Да, я у них интервьюировался несколько месяцев назад. Серьезные ребята, произвели хорошее впечатление.

(Reply to this) (Parent)

[info]di
2007-06-06 04:57 pm UTC (link)
Не хотел влезать в разговор, но к вопросу "Делать ли отдельный пост"...
После вот этого вот: http://www.civilguard.org.ua/docs/20070606.htm
Да, делать.

(Reply to this) (Thread)

[info]dbg
2007-06-06 05:10 pm UTC (link)
Ууух, как жирно. "Позорная акция", "никаких сомнений в скоординированности", "нарушения основополагающих гражданских прав". Это, конечно, по части карательных психиатров.

Есть [технические] вопросы, на которые у меня нет точного ответа, я подумаю еще, и, вероятно, действительно вынесу отдельным постом.

(Reply to this) (Parent)

[info]dbg
2007-06-06 06:25 pm UTC (link)
Написал.

(Reply to this) (Parent)(Thread)

[info]di
2007-06-06 06:33 pm UTC (link)
Супер!
Это единственный пост, на который можно ссылаться вполне убедительно.

Хотя я вот думаю...
Я юрист, кой-чего понимаю в компьютерах. Гуманитарий грубо говоря, но озабоченный.
И ваш разговор понимаю на 90%.
Но как же легко дурить людей, используя элементарное незнание простейших сетевых принципов...
Там в комментариях человек 50, которые на 100% верят, что если у них сайт не открывается - провайдер заблокировал, гад!

Грустно это, хотя никуда не денешься.
Спасибо вам :)

(Reply to this) (Parent)(Thread)

[info]dbg
2007-06-06 06:43 pm UTC (link)
Не за что. А человека действительно легко обмануть, это правда. Даже себя самого легко обмануть. Я уверен, что вся эта истерика возникла из-за того, что несогласные сами себя перепугали до полусмерти байками о спецслужбах.

(Reply to this) (Parent)
понра
[info]nealar
2007-06-06 06:39 pm UTC (link)
Зачёт!
очень интересно.
Сам бы я так не сумел раскопать.

(Reply to this)

Проститутки Киева интим intim sex Девочки
(Anonymous)
2008-02-03 10:32 am UTC (link)
Проститутки Киева досуг dosug sex Девочки
c ув http://kurtizanka.com.ua
kurtizanka.com.ua

(Reply to this)

Письма которые мне приходят с Вашего адреса.
(Anonymous)
2008-06-16 04:33 pm UTC (link)
Здравствуйте, многоуважаемая администрация форума dbg.livejournal.com!
Ко мне в почту simpakisa@mail.ru пришло за последнее время 416 писем со всякой дурацкой рекламой отелей, таблеток, порно, и т.д.. Обратный адрес указан admin@dbg.livejournal.com , administrator@dbg.livejournal.com alex@dbg.livejournal.com и другие. И все адреса с Вашего сайта!
Огромная просьба, вычеркнуть мой адрес из списка Вашей рассылки и не слать мне впредь всякую гадость. Иначе, я буду вынуждена принять меры.
С уважением,
Ирина.

(Reply to this)

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