форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
Сообщение от opennews (ok) on 03-Апр-15, 11:45
Роберт Грэм (Robert Graham) из команды Errata Security, получивший известность как разработчик сверхпроизводительного DNS-сервера robdns (http://www.opennet.dev/opennews/art.shtml?num=41386) и системы masscan (https://github.com/robertdavidgraham/masscan), способной за 5 минут просканировать порты всех хостов в интернет, опубликовал (http://blog.erratasec.com/2015/04/pin-pointing-chinas-attack...) результаты исследования источника подстановки вредоносных JavaScript-блоков, применяемых для DDoS-атаки (http://www.opennet.dev/opennews/art.shtml?num=41919) на GitHub. Исследование подтвердило, что модификация трафика производится на оборудовании "Великого китайского файрвола (https://ru.wikipedia.org/wiki/%D0%97%D0%...)" или в непосредственной близости от него, в частности в инфраструктуре магистральной опорной сети крупнейшего китайского провайдера China Unicom. Пока непонятно санкционирована ли атака китайскими властями или она стала возможной в результате взлома инфраструктуры сети China Unicom третьими лицами. Для определения точки подстановки трафика был использован довольно интересный метод, основанный на анализе изменения TTL (https://ru.wikipedia.org/wiki/Time_to_live) (поле в заголовке IP-пакета, уменьшаемое на единицу на каждом транзитном маршрутизаторе). Ранее, изучая атаку на GitHub, исследователи из компании  Netresec обнаружили (http://www.netresec.com/?page=Blog&month=2015-03&post=China&...) важные особенности работы с TTL на перехватывающем трафик MITM-узле. Подмена осуществлялась только для пакетов с низким TTL ("пришедших издалека"), а подменённые в результате MITM-атаки пакеты снабжались с аномальном большим TTL, т.е. значение данного поля искусственно заменялось на большое значение, что явно выделяло прошедшие через MITM-прокси пакеты в общем потоке ответов от сервера. В ситуации с осуществляющем атаку на GitHub MITM-прокси, проверочные пакеты к серверу Baidu, отправленные с TTL 64, достигают целевого хоста при TTL 46, т.е. по пути наблюдается 18 транзитных шлюзов. Но после отправки web-запроса, ответ приходит с TTL 98 или 99, что можно использовать как сигнал получения ответа от подставного сервера. Роберт Грэм решил воспользоваться данной аномалией и проследить на каком узле в цепочке передачи пакета происходит изменение TTL. Для этого им был подготовлен модифицированный вариант утилиты traceroute,  отправляющий HTTP-запросы с изменённым TTL и отслеживающий пакеты об исчерпании времени жизни от маршрутизаторов. Большинство систем выставляет по умолчанию для пакетов значение TTL 64, по мере прохождения маршрутизаторов значение TTL уменьшается и в момент достижения целевого хоста содержит своё минимальное значение, позволяющее оценить число транзитных маршрутизаторов по пути следования пакетов. Принцип действия утилиты traceroute сводится к том, что она вначале отправляет пакет с TTL=1 и так как время жизни пакета истекает на первом маршрутизаторе, получает от него ICMP ответ с отражением данного факта. Таким образом определяется первый узел по пути следования пакета. Затем проверки повторяются с TTL=2,3... до тех пор пока не будет получен положительный ответ, что будет сигнализировать достижение целевого хоста. Особенностью созданного Робертом Грэммом мдифицированного варианта traceroute является то, что для анализа узлов за китайским межсетевым экраном вначале осуществляется установка http-соединения с нормальным TTL, после чего начинается цикличная проверка с минимальными значениями TTL (1,2,3... и до достижения хоста).  В один прекрасный момент при определённом TTL будет пройдет весь путь следования пакета и достигнут целевой хост. При этом полученное пошаговой проверкой число хопов будет отличаться от числа хопов, полученных в результате первого запроса (при пошаговой проверке 12, при прямом запросе 94). <center><a href="http://2.bp.blogspot.com/-IvEzQf13xYc/VRyA6fbMD7I/AAAAAAAACs... src="http://www.opennet.dev/opennews/pics_base/0_1428049194.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Появление ответа при запросе с TTL значительно ниже возвращённого при первой проверке эталонного TTL будет свидетельствовать о достижении MITM-прокси. IP-адрес с которого был получен последний ответ об истечении времени жизни пакета можно считать адресом MITM-прокси. В данном случае, MITM-прокси находится в сети оператора China Unicom. Примечательно, что обратная проверка через запуск traceroute из Китая к запрещённому в Китае внешнему ресурсу, показывает, что пакеты блокируются в инфраструктуре China Unicom. URL: http://arstechnica.com/security/2015/04/ddos-attacks-that-cr.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=41965
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+10 +/–
Сообщение от бедный буратино (ok) on 03-Апр-15, 11:45
если каждый китаец сделает по коммиту - у гитхаба место кончится
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+48 +/–
	Сообщение от annualslayer (ok) on 03-Апр-15, 12:00
	если каждый буратина пошутит по шутке -- петросяну жрат будет нечего
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	172. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
	Сообщение от нуяпетрасянь on 07-Апр-15, 05:47
	> если каждый буратина пошутит по шутке -- петросяну жрат будет нечего в лорквотез!
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	3. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+2 +/–
	Сообщение от Andrey Mitrofanov on 03-Апр-15, 12:08
	> если каждый китаец сделает по коммиту - у гитхаба место кончится Зато git "победит" в соревновании за популярность у пользователей. </гипотетически> А "для места" -- добавят в git дедупликацию с котятами(). Все ж китайские коммиты на одно лицо. ()http://www.opennet.dev/opennews/art.shtml?num=41945
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
Сообщение от grec on 03-Апр-15, 12:24
Кто практикует обход китайских бастионов при обращении изнутри? VPN зарезают или нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
	Сообщение от Крокус on 03-Апр-15, 12:41
	VPN официально не запрещен (т.е. не сажают). Но Великий файрвол режет все адреса популярных компаний, продающих услуги VPN, и непосредственно адреса самих серверов VPN. В институтских сетях по анализу трафика как-то обрывают соединения с VPN. Но, в принципе, все работает. VPN маскируют под SSL на порт 443, есть тюнингованные клиенты для противодействия анализу. Многие компании обслуживают большой рынок китайских хомячков.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+1 +/–
	Сообщение от Крокус on 03-Апр-15, 12:45
	А уж зоопарком бесплатных программ: FreeGate, UltraSufr, Psiphon и т.п. с тобой поделится каждый китаец.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	64. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	–1 +/–
	Сообщение от Номномном on 03-Апр-15, 18:55
	> А уж зоопарком бесплатных программ: > FreeGate, UltraSufr, Psiphon и т.п. > с тобой поделится каждый китаец. При том в половине наверное встроено спайваре. Не китайское, так АНБшное. Ну ладно там свой сервак на который тоннель прокинул - не паливно и катит. А юзать левай софт от хзкого - вы там в своем уме?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	110. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
	Сообщение от Аноним (??) on 04-Апр-15, 00:33
	>Кто практикует обход китайских бастионов при обращении изнутри? VPN зарезают или нет. Вывозили в поднебесную ноут с openVPN. Скорость режет практически до нуля. С трудом открыли и прочитали содержимое каталога. Практически пользоваться невозможно.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	145. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	–1 +/–
	Сообщение от count0krsk (ok) on 04-Апр-15, 19:52
	> Вывозили в поднебесную ноут с openVPN. Скорость режет практически до нуля. С > трудом открыли и прочитали содержимое каталога. Практически пользоваться невозможно. Так а не проще открыть rdp/free nx до своего сервака в другой стране, и оттуда пользоваться инетом?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	173. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
	Сообщение от Аноним (??) on 07-Апр-15, 09:26
	> Так а не проще открыть rdp/free nx до своего сервака в другой > стране, и оттуда пользоваться инетом? Или познакомить кЕтайский фаервол с MPTCP, так интереснее, пожалуй :)
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

174. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
Сообщение от v_paranoid on 08-Апр-15, 10:51
Перевод/пересказ оригинала тут некорректный, А сам анализ Netresec и Грэма очень интересный. > Подстановка используемых в атаке JavaScript-блоков осуществлялась > только для пакетов с низким TTL ("пришедших издалека"). Неверно. Просто для пришедших снаружи в сторону китайских сетей. > В подменённых в результате MITM-атаки пакетах значение поля с TTL искусственно заменялось на большое значение, Неверно. Пакеты не подменялись, подменялся javascript. А пакеты инжектились в оригинальный поток. > Например, проверочные пакеты к серверу Baidu, > отправленные с TTL 64, достигают целевого хоста при TTL 46, > Но после отправки web-запроса, ответ приходит с TTL 98 или 99, что можно > рассматривать как признак получения ответа от подставного сервера. Неверно. В анализе наблюдают пакеты ОТ сервера к клиенту, и в этом потоке у некоторых пакетов TTL отличается от остальных. Он не просто меньше - он другой (в оригинальной статье приводили пример с ttl 228). > Для этого им был подготовлен модифицированный вариант утилиты traceroute, > отправляющий HTTP-запросы с изменённым TTL > и отслеживающий ICMP-ответы шлюзов об исчерпании времени жизни пакетов. Неверно. Утилита вовсе не смотрит на ICMP, только на ответы http-сервера. > При этом, полученное в результате пошаговой проверки число хопов > будет отличаться от числа хопов, полученных в результате первого запроса > (при пошаговой проверке 12, при прямом запросе 94). Неверно. Число 12 вообще не имеет значения на этом скриншоте. Грэм обращает внимание на ttl 46,92,93,94. > Появление ответа с TTL, значение которого значительно меньше, > чем TTL первой проверки, будет свидетельствовать о достижении MITM-прокси. Не совсем. TTL не всегда меньше, он другой. > адрес с которого был получен последний ответ об истечении > времени жизни пакета можно считать адресом MITM-прокси. Неверно. Адрес последнего icmp ответа это некий роутер, а mitm сидит очевидно после него.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	175. "Анализ TTL помог выявить источник DDoS-атаки на GitHub"	+/–
	Сообщение от Рауль (ok) on 12-Апр-15, 22:27
	Главное подобрать правильные методы анализа, при которых Китайцев можно обвинить
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема