flylinkdc писал(а):А как ты определил этот список?
С помощью бота-сиделки на хабах. Он умеет заходить на все хабы сразу, и, если какие-то из них участвуют в ддос-атаке, это становится видно по кол-ву запросов CTM.
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 ***)
но вот что клиент с этим подключением будет делать дальше - вопрос. Как удержать подключение максимально долго и не дать создать новое - вопрос тяжелый..
Нужен хабсофт, который будет игнорить получаемые от клиентов команды
Опробовал я свою идею на практике. Получилось не очень красиво.
Под PtokaX без переделки ее мозгов невозможно реализовать полноценное рукопожатие клиент-клиент, поскольку хаб при подключении клиента всегда посылает $Lock, тем самым нарушая последовательность команд. Однако, можно удержать клиенты на некоторое время таким вот "хитрым" способом:
function UnknownArrival(user,data)
return true
end
Для теста использовался небольшой хаб (около 150 юзеров), и при этом клиенты умудрились создать около 800 активных соединений. А что же будет, если в атаке будет участвовать хаб-тысячник?
В общем, остается один вариант - вычислять хабы злоумышленника, и убивать их аналогичным способом. Некрасиво это, но зато эффективно: нет хаба - нет ддоса
В том-то и дело - это лучше, а не хуже. Пока клиент подключен, он не флудит данными, а как отключился - тут же отправляет $MyNick по-новой. Вопрос в том, выдержит ли сервер большое количество подключений?
Клиенты поддерживающие расширение: StrongDC 2.4 и выше, а также клиенты на нем базирующиеся..
Назначение: расширение команды $Lock отсылаемой клиенту.
Описание:
данное расширение команды $Lock используется при инициалиации соединения между клиентами, т.е. после отправки через хаб команды $ConnectToMe. Команда имеет вид:
как видно синтаксис идентичен старой версии команды, но в самом конце добавилась строка Ref=dc.domain.com:port причём без разделительного пробела, для совместимости сос тарыми клиентами. Данный параметр показывает на то с какого хаба клиентом была получена команда $ConnectToMe для инициализации соединения.
Для чего эту фичу добавили в стронг неизвестно, в вопросах файлообмена она абсолютно не нужна, но вот для владельцев хабов да и не только может быть очень полезной. В случае DDoS атаки CTM вам на блюдечке с каёмочкой клиенты будут слать адрес хаба с которого этот ддос устроили
Т.е. имеет смысл логировать входящие сообщения.
Сервера теперь стали толще и дешевле, и в соседней теме есть сказочные показатели онлайна.. у Верлихаба заявлена работа с более чем 20 000 коннектов.
Вот если бы была фича с функцией разделения по группам юзеров (то, про что я в соседней теме и распрягал ) - было бы вообще шикарно.
Помечать группу клиентов (соединений), держать сокеты открытыми, но ничего им не отправлять - соединения не будут рваться из-за недопустимых команд, не будет инициировано новое подключение после разрыва, экономия трафика на рассылке команд и поисковых запросов. Мастхэв-фича, короче
KCAHDEP писал(а):думаешь эта шайка лейка прочитала форум и абасралась с испугу? не думаю
Я же написал выше: "под сильнымдавлением общественности". Ну, вместо слова "общественности" можно поставить "пользователей". Вообщем, если очень много пользователей дружно попросили... то у кого-то может проснулась совесть, даже если её и не было.
На этот раз атакуются какие-то румыны по адресу dc.vpspro.ro:411. Че-то мне кажется, что пора удалять весь этот шлак из хаблиста. А с другой стороны - как же я потом узнаю, что они кого-то ддосят? Сиделка-то использует тутошний список хабов.
+1 за исключение из публичного списка хабов, замеченных в ддосе.
+1 за создание дополнительного списка забаненных хабов, чтобы заинтересованные лица могли натравливать на них своих сиделок
91.192.190.158 - какой-то странный хаб, особых признаков ддоса я там не увидел (2 других хаба в это время активно куда-то CTMили), но в cmd-отладчике очень много $MyInfo
HackFresse писал(а):91.192.190.158 - какой-то странный хаб, особых признаков ддоса я там не увидел (2 других хаба в это время активно куда-то CTMили), но в cmd-отладчике очень много $MyInfo
Это все скрипт ддоса от рукожопого автора. По-хорошему, оно и должно отправлять, $MyINFO того ника, что затем будет использован в $CTM. Это нужно чтобы особо умные клиенты не игнорировали запрос от "юзера", которого нет на хабе. Но слать его каждый раз нет необходимости. А почему нет собственно $CTM, понятия не имею. Возможно, админ там совсем рукожопый, и сделал грубую ошибку в строке, отвечающей за это.
Для CTM-атаки через NMDC-протокол (ADC не смотрел) отправка $MyINFO абсолютно не нужна, поскольку в $ConnectToMe используется сразу IP:port жертвы.
Дц-клиенты не знают соответствий {ник на хабе}=={ip:port}, эта информация не рассылается в $MyINFO, дц-клиентам приходится верить командам с хаба на установление соединения (в этом и возможность атаки на любой адрес и порт)
Дц-клиент без раздумий установит соединение с любыми IP:port и вышлет туда свой ник и $Lock , отсутствие проверки частоты запросов и корректности ответа на другой стороне и даёт ддос-атаку
вот кусок сообщений из CMD-отладчика с пояснениями
Клиенты знают, какие юзеры находятся на том или ином хабе, они видят ник в команде $ConnectToMe, они знают, с какого хаба пришла команда. Так почему же они не могут игнорировать запросы на соединение с несуществующими юзерами?
Я не говорю что так есть (исходники клиентов не ковырял). Я просто предполагаю. Возможно, причина в другом.
asdqweqwe- это мой ник, я получаю команду на соединение с непонятно кем, и мой дц-клиент покорно создаёт коннект и отправляет мои ник и лок непонятно куда.
в данном случае на игровой сервер World of Warcraft, который обрывает соединение, потому что по его протоколу принята другая последовательность совершенно иных инструкций
Эта команда начинает процесс соединения между клиентами. Команда отправляется на хаб клиентом, находящимся в активном режиме. Хаб пересылает эту команду целевому клиенту без изменения. Получив эту команду, целевой клиент отвечает, соединяясь напрямую с указанным IP на указанный порт.
С какого хаба пришла команда - известно, куда именно будет установлено подключение - абсолютная тайна. "сначала подключаемся, потом разбираемся, зачем"
Были какие-то наработки по поводу "в CTM учитывать еще и ник"
Для клиентов NeoModus Direct Connect v2.205 и DC:PRO v0.2.3.97A:
Защита от ddos влита в ветку FlylinkDC++ r4xx
те, кто не хочет переходить на r5xx могут потыкать ее в r4xx
версия доступна в автообновлении.
я там только логирование не стал выносить в отдельный файл логов