flylinkdc писал(а):А как ты определил этот список?
С помощью бота-сиделки на хабах. Он умеет заходить на все хабы сразу, и, если какие-то из них участвуют в ддос-атаке, это становится видно по кол-ву запросов CTM.
Добавлено: 17 мар 2014, 08:18
KCAHDEP
hubmonitor или скрипт для хаба?
Добавлено: 17 мар 2014, 10:49
HackFresse
alex82 писал(а):HackFresse
Да нет, но если это не CTM, то и обсуждать нет смысла.
В общем идея в следующем: а что, если вместо того, чтобы рвать соединения с юзерами, участвующими в атаке, попытаться наоборот удержать их? Возможно, даже ответить в соответствии с протоколом. Ведь если соединение уже установлено, клиент не будет пытаться соединиться повторно. Я так думаю
Я никогда не ковырял внутренности DC-клиентов, и потому не знаю, насколько те или иные из них отличаются умом и сообразительностью в этом плане. Но в этой теме присутствует человек, который в этом наверняка разбирается. Уважаемый flylinkdc, что скажете по этому поводу? Будут ли клиенты пытаться соединиться с указанным ником/адресом повторно, если одно соединение уже установлено?
Нужно разбирать логику дц-клиентов, делают ли они различия между подключениями к хабу и подключениями к юзерам..
Хендшейк-то разный еще можно попытаться хабом утрясти,
Спойлер
(client C successfully establishes TCP connection to a hub H)
C H
<- $Lock <lock> Pk=<pk>|
-> $Key <key>|
-> $ValidateNick <nick>|
<- $HubName <hubname>|
<- $Hello <nick>|
.....
(client B successfully establishes TCP connection to client A)
A B
<- $MyNick <nickOfClientB>|
-> $MyNick <nickOfClientA>|
-> $Lock <lockOfClientA> Pk=<pkOfClientA>|
<- $Lock <lockOfClientB> Pk=<pkOfClientB>Ref=<hubAddress>|
-> $Supports <extensionA1> <extensionA2> ... |
-> $Direction Download <randomNumberOfClientA>|
-> $Key <keyOfClientA>|
<- $Supports <extensionB1> <extensionB2> ... |
<- $Direction Upload <randomNumberOfClientB>|
<- $Key <keyOfClientB>|
-> $ADCGET file <fileName> <params>|
<- $ADCSND file <fileName> <params>|
<- (*** binary data is now transfered from client B to client A ***)
но вот что клиент с этим подключением будет делать дальше - вопрос. Как удержать подключение максимально долго и не дать создать новое - вопрос тяжелый..
Нужен хабсофт, который будет игнорить получаемые от клиентов команды
Итого для теста нужно 2 хаба - один с запущенным CTM - флудом, а второй с изменённым хендшейком.
Добавлено: 17 мар 2014, 16:06
alex82
KCAHDEP писал(а):hubmonitor или скрипт для хаба?
Самописный бот.
Опробовал я свою идею на практике. Получилось не очень красиво.
Под PtokaX без переделки ее мозгов невозможно реализовать полноценное рукопожатие клиент-клиент, поскольку хаб при подключении клиента всегда посылает $Lock, тем самым нарушая последовательность команд. Однако, можно удержать клиенты на некоторое время таким вот "хитрым" способом:
function UnknownArrival(user,data)
return true
end
Для теста использовался небольшой хаб (около 150 юзеров), и при этом клиенты умудрились создать около 800 активных соединений. А что же будет, если в атаке будет участвовать хаб-тысячник?
В общем, остается один вариант - вычислять хабы злоумышленника, и убивать их аналогичным способом. Некрасиво это, но зато эффективно: нет хаба - нет ддоса
Добавлено: 17 мар 2014, 16:24
HackFresse
flylinkdc писал(а):alex82 писал(а):Будут ли клиенты пытаться соединиться с указанным ником/адресом повторно, если одно соединение уже установлено?
В коде наследников StrongDC++ есть такая проверка:
...
1. порты 80 и 2501 вообще защищены от такой атаки
2. коннекты создаются но их не более 5 от каждого атакующего (IP:PORT)
В оригинальном DC++ такой проверки нет.
Примерно так и получается, 150 юзеров по 5 коннектов - 750 коннектов.
Насколько хуже держать соединения открытыми, чем постоянно отвергать новые (которых с каждого дц-клиента несколько штук в секунду)?
Добавлено: 17 мар 2014, 16:45
alex82
В том-то и дело - это лучше, а не хуже. Пока клиент подключен, он не флудит данными, а как отключился - тут же отправляет $MyNick по-новой. Вопрос в том, выдержит ли сервер большое количество подключений?
Добавлено: 17 мар 2014, 16:46
KCAHDEP
А если цикл 1 секунда 50 запросов 1000 юзеров еще веселее да и не все хабы можно прибить таким макаром
Клиенты поддерживающие расширение: StrongDC 2.4 и выше, а также клиенты на нем базирующиеся..
Назначение: расширение команды $Lock отсылаемой клиенту.
Описание:
данное расширение команды $Lock используется при инициалиации соединения между клиентами, т.е. после отправки через хаб команды $ConnectToMe. Команда имеет вид:
как видно синтаксис идентичен старой версии команды, но в самом конце добавилась строка Ref=dc.domain.com:port причём без разделительного пробела, для совместимости сос тарыми клиентами. Данный параметр показывает на то с какого хаба клиентом была получена команда $ConnectToMe для инициализации соединения.
Для чего эту фичу добавили в стронг неизвестно, в вопросах файлообмена она абсолютно не нужна, но вот для владельцев хабов да и не только может быть очень полезной. В случае DDoS атаки CTM вам на блюдечке с каёмочкой клиенты будут слать адрес хаба с которого этот ддос устроили
Т.е. имеет смысл логировать входящие сообщения.
Сервера теперь стали толще и дешевле, и в соседней теме есть сказочные показатели онлайна.. у Верлихаба заявлена работа с более чем 20 000 коннектов.
Вот если бы была фича с функцией разделения по группам юзеров (то, про что я в соседней теме и распрягал ) - было бы вообще шикарно.
Помечать группу клиентов (соединений), держать сокеты открытыми, но ничего им не отправлять - соединения не будут рваться из-за недопустимых команд, не будет инициировано новое подключение после разрыва, экономия трафика на рассылке команд и поисковых запросов. Мастхэв-фича, короче
Добавлено: 18 мар 2014, 13:22
переподвыподверт
alex82 писал(а):есть ли там проверка IP-адресов в командах
В 3.6 уже есть. Другое дело, что её можно преднамеренно либо по незнанию отключить, при этом предупреждение как в 4.х не выскакивает.
[12:15:46] <VerliHub> The last 20 messages were:
[13:18:08] <KCAHDEP>оклемался наконец-то
[13:19:52] <KCAHDEP>постигла всетаки кара небесная дудосеров
Проклятие Алексиса подействовало, али ответку врубили?
Добавлено: 18 мар 2014, 14:46
KCAHDEP
Может кто и вырубил или помог отбить, мир не без добрых людей
Добавлено: 18 мар 2014, 15:03
slav
KCAHDEP писал(а):Может кто и вырубил или помог отбить, мир не без добрых людей
Может он сам, под сильным "давлением общественности" задумался о своём поведений и решил больше так не делать?
Добавлено: 18 мар 2014, 15:06
KCAHDEP
думаешь эта шайка лейка прочитала форум и абасралась с испугу? не думаю
Добавлено: 18 мар 2014, 15:28
slav
KCAHDEP писал(а):думаешь эта шайка лейка прочитала форум и абасралась с испугу? не думаю
Я же написал выше: "под сильнымдавлением общественности". Ну, вместо слова "общественности" можно поставить "пользователей". Вообщем, если очень много пользователей дружно попросили... то у кого-то может проснулась совесть, даже если её и не было.
Добавлено: 18 мар 2014, 23:41
HackFresse
"сильное давление общественности"?
"очень много пользователей дружно попросили"?
серьёзно?
Добавлено: 22 мар 2014, 16:05
alex82
Эти говнохабы снова используют юзеров для DDoS-атаки:
На этот раз атакуются какие-то румыны по адресу dc.vpspro.ro:411. Че-то мне кажется, что пора удалять весь этот шлак из хаблиста. А с другой стороны - как же я потом узнаю, что они кого-то ддосят? Сиделка-то использует тутошний список хабов.
Добавлено: 23 мар 2014, 00:11
HackFresse
+1 за исключение из публичного списка хабов, замеченных в ддосе.
+1 за создание дополнительного списка забаненных хабов, чтобы заинтересованные лица могли натравливать на них своих сиделок
91.192.190.158 - какой-то странный хаб, особых признаков ддоса я там не увидел (2 других хаба в это время активно куда-то CTMили), но в cmd-отладчике очень много $MyInfo
HackFresse писал(а):+1 за создание дополнительного списка забаненных хабов, чтобы заинтересованные лица могли натравливать на них своих сиделок
Интересная мысль... Создать "Чёрный список" хабов....
Добавлено: 23 мар 2014, 05:35
KCAHDEP
тогда уж и каждому по "сиделке"
Добавлено: 23 мар 2014, 05:50
alex82
HackFresse писал(а):91.192.190.158 - какой-то странный хаб, особых признаков ддоса я там не увидел (2 других хаба в это время активно куда-то CTMили), но в cmd-отладчике очень много $MyInfo
Это все скрипт ддоса от рукожопого автора. По-хорошему, оно и должно отправлять, $MyINFO того ника, что затем будет использован в $CTM. Это нужно чтобы особо умные клиенты не игнорировали запрос от "юзера", которого нет на хабе. Но слать его каждый раз нет необходимости. А почему нет собственно $CTM, понятия не имею. Возможно, админ там совсем рукожопый, и сделал грубую ошибку в строке, отвечающей за это.
Добавлено: 23 мар 2014, 10:34
HackFresse
Нет, по-моему, путаешь с чем-то другим..
Для CTM-атаки через NMDC-протокол (ADC не смотрел) отправка $MyINFO абсолютно не нужна, поскольку в $ConnectToMe используется сразу IP:port жертвы.
Дц-клиенты не знают соответствий {ник на хабе}=={ip:port}, эта информация не рассылается в $MyINFO, дц-клиентам приходится верить командам с хаба на установление соединения (в этом и возможность атаки на любой адрес и порт)
Дц-клиент без раздумий установит соединение с любыми IP:port и вышлет туда свой ник и $Lock , отсутствие проверки частоты запросов и корректности ответа на другой стороне и даёт ддос-атаку
вот кусок сообщений из CMD-отладчика с пояснениями
Hub: [Outgoing][91.192.190.158] $Search Hub:HackFresse F?T?0?9?TTH:H7HFTAMN2A7AW3LM3CWVGDVBS76VLJ3K4KHMI4A|
-- я искал на хабе файл
Hub: [Incoming][91.192.190.158] $SR Andrey58 ФИЛЬМЫ\Фильмы СССР\КИН-ДЗА-ДЗА! (полная реставрация).mkv3143980250 0/10TTH:H7HFTAMN2A7AW3LM3CWVGDVBS76VLJ3K4KHMI4A (91.192.190.158:411)
-- мне с хаба 91.192.190.158:411 пришел ответ от Andrey58 (какие у него адрес и порт - неизвестно )
Hub: [Incoming][91.192.190.158] $ConnectToMe HackFresse 46.146.194.17:2282
-- пришла команда от хаба на установление соединения. с кем и зачем - неизвестно
Client: [Outgoing][46.146.194.17] $MyNick HackFresse|
Client: [Outgoing][46.146.194.17] $Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.709ABCABC|
-- но мой дц-клиент быстренько и без лишних раздумий туда подключился, сразу же отправил ник + Lock и ждёт ответа
Client: [Incoming][46.146.194.17] $MyNick Andrey58
-- оказалось, что на той стороне действительно дц-клиент Andrey58, от которого и пришел поисковый ответ. только теперь можно получить соответствие "Andrey58 c хаба 91.192.190.158:411 имеет 46.146.194.17:2282". Пока удалённый клиент не ответит - его IP и порт для входящих подключений узнать нельзя
Client: [Incoming][46.146.194.17] $Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.785ABCABC
Client: [Outgoing][46.146.194.17] $Supports MiniSlots XmlBZList ADCGet TTHL TTHF BanMsg ZLIG |
Client: [Outgoing][46.146.194.17] $Direction Download 15214|
Client: [Outgoing][46.146.194.17] $Key ����A ѱ���0�0 0 0 0 0 0|
Client: [Incoming][46.146.194.17] $Supports MiniSlots XmlBZList ADCGet TTHL TTHF ZLIG
Client: [Incoming][46.146.194.17] $Direction Upload 21348
Client: [Incoming][46.146.194.17] $Key ����A ѱ���0�0 0 0 0 0 0
Client: [Outgoing][46.146.194.17] $ADCGET file TTH/H7HFTAMN2A7AW3LM3CWVGDVBS76VLJ3K4KHMI4A 0 8388608|
Client: [Incoming][46.146.194.17] $MaxedOut 43
--- попытка закачки файла, нужно ожидать, я 43 в очереди
-- затем снова прилетела куча $MyINFO
Hub: [Incoming][91.192.190.158] $MyINFO $ALL pastyh [84]<FlylinkDC++ V:(r402),M:A,H:44/0/1,S:90>$ $100 $$861857883540$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Jonny0795 Jonny0795<FlylinkDC++ V:r502,M:A,H:2/0/0,S:15>$ $50$p.fominov2012@yandex.ru$112041245090$
Hub: [Incoming][91.192.190.158] $ZOn
Hub: [Incoming][91.192.190.158] $MyINFO $ALL rmtm [NWLink] <StrgDC++ V:2.22,M:A,H:4/5/0,S:9>$ $100$$1230627886976$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Horev [NWLinkВесёлый] <StrgDC++ V:2.06,M:A,H:14/1/0,S:5>$ $1000$ $104992013695$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Rumpelstiltskin [Unet] <gl++ V:5.83,M:A,H:0/1/0,S:6>$ $1000$$9734732018804$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL [GTK]LAV_Server [GTK] hubdc.ru - доступно скачивание через Интернет.<GTK-Avalink++ V:2.00,M:A,H:6/3/3,S:99>$ $1000$ $14693971219043$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Monkey_JF6mAW [Брест] [15]<FlylinkDC++ V:r502,M:P,H:7/0/0,S:15>$ $50)$$260882537635$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Kirill1980 [NWLinkВесёлый] <StrgDC++ V:2.22,M:P,H:12/0/1,S:13>$ $100$k-samsonov@yandex.ru$217833257847$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Queeni[Work] [Obit] [3]<FlylinkDC++ V:r501,M:P,H:0/1/0,S:3>$ $50!$$0$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL alex0715 [Интернет] <SSQLite++ V:2.43.13802,M:P,H:37/10/0,S:235>$ $1009$$5532354876534$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL octopus [NWLinkВесёлый] Искровский 4 корп. 2<++ V:0.704,M:A,H:2/1/0,S:10,G:0,I:3>$ $100$$4359292902706$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Rise [InterZet] старый ворчун<StrgDC++ V:2.21,M:P,H:1/2/0,S:4>$ $100$$92793192961$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL 0xFFFF [Интернет] [14]<FlylinkDC++ V:r501-x64,M:P,H:14/0/0,S:15>$ $50)$$39249745351$
...
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Sc3afSat007911 [Интернет] [9]<FlylinkDC++ V:r502-x64,M:P,H:245/0/2,S:10>$ $1)$$84515736846$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Tutti-Frutti [Киров] [15]<FlylinkDC++ V:r503-beta22,M:A,H:52/0/0,S:15>$ $50$$116740419961$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Algusik [Интернет] [15]<FlylinkDC++ V:r422,M:P,H:16/0/0,S:15>$ $50$$82641045213$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL HackFresse [Интернет] [10]<gl++ V:0.61,M:P,H:2/1/0,S:10>$ $0.005$$0$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Alextits23 [Интернет] [23]<FlylinkDC++ V:r502-x64,M:P,H:31/1/3,S:23>$ $50)$$183009430184$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL uoiuytgh [Киров] [15]<FlylinkDC++ V:r503-beta41-x64,M:A,H:1/0/0,S:15>$ $50$$67383962794$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Jonny0795 [Интернет] Jonny0795<FlylinkDC++ V:r502,M:A,H:2/0/0,S:15>$ $50$p.fominov2012@yandex.ru$112041245090$
Hub: [Incoming][91.192.190.158] $MyINFO $ALL Sc3afSat007911 [Интернет] [8]<FlylinkDC++ V:r502-x64,M:P,H:244/0/2,S:10>$ $1)$$84515736846$
Hub: [Outgoing][91.192.190.158] $RevConnectToMe HackFresse Andrey58|
-- мой дц-клиент (в пассиве) отправил запрос на соединение с Andrey58. и хотя какие-то IP:port уже были получены ранее, всё равно повторный запрос на получение инструкций
Hub: [Incoming][91.192.190.158] $ConnectToMe HackFresse 46.146.194.17:2282
-- хм, кто бы это мог быть? да не важно, сначала соединимся, а потом будет выяснять, зачем нам это нужно
Client: [Outgoing][46.146.194.17] $MyNick HackFresse|
Client: [Outgoing][46.146.194.17] $Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.709ABCABC|
-- кто бы ты ни был, вот мои ник и лок
Client: [Incoming][46.146.194.17] $MyNick Andrey58
Client: [Incoming][46.146.194.17] $Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.785ABCABC
Client: [Outgoing][46.146.194.17] $Supports MiniSlots XmlBZList ADCGet TTHL TTHF BanMsg ZLIG |
Client: [Outgoing][46.146.194.17] $Direction Download 31654|
Client: [Outgoing][46.146.194.17] $Key ����A ѱ���0�0 0 0 0 0 0|
Client: [Incoming][46.146.194.17] $Supports MiniSlots XmlBZList ADCGet TTHL TTHF ZLIG
Client: [Incoming][46.146.194.17] $Direction Upload 26788
Client: [Incoming][46.146.194.17] $Key ����A ѱ���0�0 0 0 0 0 0
Client: [Outgoing][46.146.194.17] $ADCGET file TTH/H7HFTAMN2A7AW3LM3CWVGDVBS76VLJ3K4KHMI4A 0 8388608|
Client: [Incoming][46.146.194.17] $MaxedOut 41
-- в очереди уже чуть меньше народу
Добавлено: 23 мар 2014, 11:25
alex82
HackFresse,
Клиенты знают, какие юзеры находятся на том или ином хабе, они видят ник в команде $ConnectToMe, они знают, с какого хаба пришла команда. Так почему же они не могут игнорировать запросы на соединение с несуществующими юзерами?
Я не говорю что так есть (исходники клиентов не ковырял). Я просто предполагаю. Возможно, причина в другом.
asdqweqwe- это мой ник, я получаю команду на соединение с непонятно кем, и мой дц-клиент покорно создаёт коннект и отправляет мои ник и лок непонятно куда.
в данном случае на игровой сервер World of Warcraft, который обрывает соединение, потому что по его протоколу принята другая последовательность совершенно иных инструкций
Эта команда начинает процесс соединения между клиентами. Команда отправляется на хаб клиентом, находящимся в активном режиме. Хаб пересылает эту команду целевому клиенту без изменения. Получив эту команду, целевой клиент отвечает, соединяясь напрямую с указанным IP на указанный порт.
С какого хаба пришла команда - известно, куда именно будет установлено подключение - абсолютная тайна. "сначала подключаемся, потом разбираемся, зачем"
Были какие-то наработки по поводу "в CTM учитывать еще и ник"
Для клиентов NeoModus Direct Connect v2.205 и DC:PRO v0.2.3.97A:
старый неоптимальный скрипт, который просто меняет описания юзеров, добавляя инфу о провайдере. к ддосу это никак не относится
Добавлено: 25 мар 2014, 21:03
flylinkdc
Защита от ddos влита в ветку FlylinkDC++ r4xx
те, кто не хочет переходить на r5xx могут потыкать ее в r4xx
версия доступна в автообновлении.
я там только логирование не стал выносить в отдельный файл логов