А что не так то))) я так же тему читал в том числе про физру решил зайти не соединилось, проверил домен он свободный вот и зарегал
Добавлено: 06 фев 2014, 17:30
HackFresse
Самое интересное не в домене, а в разговорах на нем. цитата в моем предыдущем сообщении очень даже интересная
Добавлено: 06 фев 2014, 17:36
KCAHDEP
Ничего экстра одинарного или секретного не увидел
Добавлено: 06 фев 2014, 18:21
flylinkdc
Еще планирую
1. Добавить в конфиг флая - список портов, для которых блокировка коннекта будет вечная без попыток.
есть контр-аргументы?
80,411 и т.д.
2. Собирать статистику в базе флай-сервера для анализа поведения...
тут тоже хотелось бы обсудить алгоритм
Каждый клиент при детекте подобного - будет в момент сброса показателей "телеметрии" (сейчас это делается раз в час)
дополнительно скидывать и эту инфу.
наверно хватит имя хаба. ip и номер порта атакующего или может что-то еще добавить
По этой базе можно будет предупреждать юзеров воздержаться от посещения подобных хабов.
3. что-то еще?
Добавлено: 06 фев 2014, 20:40
HackFresse
Моё мнение по пункту 1 остаётся всё тем же - для общения между собой дц-клиенты не должны использовать порты <=1024.
Вместо списка портов в конфиге добавить одно элементарное условие IF(dst.port <1024) непосредственно в самом коде, и это уже решит бОльшую часть проблемы.
Если есть возможность собирать статистику, то сначала нужно проанализировать получаемые данные, а потом уже переходить к блокировкам.
Собирать нужно: имя хаба +IP хаба+ порт хаба, а также IP адреса назначения + все порты жертвы. Потом по каждому конкретному случаю делать какие-то выводы.
Там уже будет видно, как часто используются порты <1024, находится ли на адресе жертвы хаб, сайт, дц-клиент или еще что-то.
Добавлено: 06 фев 2014, 20:47
flylinkdc
HackFresse писал(а):Вместо списка портов в конфиге добавить одно элементарное условие IF(dst.port <1024)
Для новой версии клиента это можно и дописать..
Но ведь остается много старых клиентов у которых в конфиге стоят порты ниже 1024 - и они не будут долго обновляться.
к ним ведь нужно разрешать коннекты при условии что они настоящие и там действительно DC
я попробую также приделать и анализ ответа от коннекта - там по идее просто...
А стату пособираю - это не проблема. главное чтобы диска хватило
Добавлено: 06 фев 2014, 21:15
переподвыподверт
flylinkdc писал(а):есть контр-аргументы?
Пожалуй есть.
1) Бывает так, что провайдер в целях борьбы с р2р разрешает использовать лишь некоторые порты.
2) Ещё чаще бывает так, что трафик по 80-му порту имеет повышенный приоритет.
Добавлено: 06 фев 2014, 21:16
Kimbo
HackFresse писал(а):Моё мнение по пункту 1 остаётся всё тем же - для общения между собой дц-клиенты не должны использовать порты <=1024.
мне из-за ваших мнений порты что ли новые открывать для дс теперь.
И да, не забывайте, что не только CTM, а ещё и Search flood есть.
Добавлено: 06 фев 2014, 21:24
flylinkdc
переподвыподверт писал(а):Ещё чаще бывает так, что трафик по 80-му порту имеет повышенный приоритет
Принято - это я тогда отловлю если по 80 порту ответит www сервер - тогда в бан.
ок?
Добавлено: 06 фев 2014, 22:51
HackFresse
По поводу запрета p2p на всех портах, кроме нескольких стандартных, ничего сказать не могу, я видел отключение по L7, но там смена порта не помогает. Длительные закачки по 80 тоже со временем скорость теряют, но это настройки конкретного роутера (провайдер режет общую скорость без разбора, п2п там или редтуба).
Хорошо, если разрешать абсолютно все порты, то остаётся следовать протоколу + учитывать частоту запросов, т.е.
HackFresse писал(а):Кстати, наполнение массива стрёмных IP очень легко и просто сделать на основании учета неудавшихся коннектов.
Т.е. атака идёт по открытым портам - дц-клиент открывает сокет, получает какую-то порцию данных. Если данные отличаются от стандартного протокола взаимодействий дц-клиент<--> дц-клиент http://wiki.gusari.org/index.php?title= ... _handshake то такие IP надо игнорить (получил ответ вебсервера - сразу ясно, что что-то не так)
>>И да, не забывайте, что не только CTM, а ещё и Search flood есть.
Каждый пользователь с одним или более совпадениями должен послать UDP-пакет на {ip}:{порт}, в случае активного запроса
Я вот нашел на http://wiki.mydc.ru/$Search и http://wiki.mydc.ru/$SR, это оно?
Т.е. хаб рассылает якобы поисковые запросы от имени некоего {ip}:{порт}, а послушные дц-клиенты шуршат по своим файл-листам в поисках совпадений и посылают ответы куда-то вдаль?
По-моему, тут поможет только аналог Search interval .Та же херня, что и на хабе ("извините, вы не можете использовать поиск чаще одного раза в 180 секунд"), только со стороны клиента
Добавлено: 06 фев 2014, 22:57
KCAHDEP
Про udp flood еще забыли "тот" плагин и такое умеет
и для udp уже нет разницы открыт порт или закрыт
За ночь работы у меня в тесте прога словила два раза только один хаб dchub://dchub.wplus.net - атаковала 78.158.9.151 Port: 411
сидел на 470 хабах
Добавлено: 07 фев 2014, 06:25
KCAHDEP
Хаб питерского прова фулюганит? Оо помню в 90х у них на дайлапе сидел )))
Добавлено: 07 фев 2014, 12:40
flylinkdc
Посмотрел на атаку через поиск http://f-lite.ru/lfp/s020.radikal.ru/i7 ... ed.jpg/htm
Во флае есть базовый код о визуализации флудеров в обработке команды if (cmd == "Search")
он так-же вырезан нашим разработчиком с комментарием
#define IRAINMAN_USE_SEARCH_FLOOD_FILTER // TODO L: оптимизировать поиск несколько другим способом: не отвечать на одинаковые запросы от одного искателя в течении определённого промежутка времени, модификацию сделать внутри SearchManager - только это даст реальный эффект при большом числе открытых хабов.
#ifdef IRAINMAN_USE_SEARCH_FLOOD_FILTER
uint64_t tick = GET_TICK();
clearFlooders(tick);
seekers.push_back(make_pair(seeker, tick));
// First, check if it's a flooder
for (auto fi = flooders.cbegin(); fi != flooders.cend(); ++fi)
{
if (fi->first == seeker) // TODO - линейный поиск. не эффективно
{
return;
}
}
int count = 0;
for (auto fi = seekers.cbegin(); fi != seekers.cend(); ++fi)
{
if (fi->first == seeker) // [1] https://www.box.net/shared/9gb1e0hkp4220a7vwidj
count++;
if (count > 7)
{
if (isOp())
{
if (isPassive)
fire(ClientListener::SearchFlood(), this, seeker.substr(4));
else
fire(ClientListener::SearchFlood(), this, seeker + ' ' + STRING(NICK_UNKNOWN));
}
flooders.push_back(make_pair(seeker, tick));
return;
}
}
#endif // IRAINMAN_USE_SEARCH_FLOOD_FILTER
В коде идея в том, что ищутся флудеры в мапе. и потом кидает фаер в окошко статуса
void HubFrame::on(SearchFlood, const Client*, const string& line) noexcept
{
speak(ADD_STATUS_LINE, STRING(SEARCH_SPAM_FROM) + ' ' + line, true);
}
т.е. простая диагностика.
Давайте обсудим эту часть алгоритма....?
Как лучше сделать лок тут?
Добавлено: 07 фев 2014, 16:04
HackFresse
Как-то очень разбросаны по разным файлам и частям куски кода с одной функциональностью, + по-разному написаны одни и те же команды, тяжело читать (и представляю, насколько тяжелее править, ага).
Я бы делал всё на моменте получения текстовой команды из сокета хаба. Никакой разницы, какая команда пришла, просто отдать её на обработку валидатору.
Если валидатор этот по некоему своему внутреннему алгоритму скажет, что команда ему не знакома, или параметр корявый, или частота превышена - не пускать команды дальше на обработку.
Это же ж классическое "никогда не доверяй данным, полученным из внешнего источника"
В случае с ддосом этим поганым всего 2 команды - $ConnectToMe и $Search, из них можно получить просто IP и занести в массив. На основании этого массива с данными о dst-IP и о времени добавления можно уже посчитать количество запросов за последние N секунд. Массив и его обработка - очень дешевые штуки
Добавлено: 07 фев 2014, 18:00
HackFresse
за одну секунду можно словить кучу CTM
Добавлено: 07 фев 2014, 18:08
flylinkdc
HackFresse писал(а):за одну секунду можно словить кучу CTM
flylinkdc писал(а):
т.е. вы мою новую бетку-28 не пробовали? http://www.fly-server.ru/install/r5xx/src-bin/
она не должна так спамить в лог. а только раз в 10 мин дополняет файл ddos.log
скачал, запустил, поставил галку логировать ддос, зашел на тот хаб в отладчике сыпались $ConnectToMe %user craca.no-ip.org:411, а вот файла лога ддос так и не появилось. на данный момент атака прекратилась, обломались хаб так и не упал
Добавлено: 07 фев 2014, 19:20
HackFresse
flylinkdc писал(а):HackFresse писал(а):за одну секунду можно словить кучу CTM
Только что попробовал запустить FlylinkDC-r503-x86-beta28-build-16516-2014.02.07-07.02.34.7z - оно убивает мне винт уже на заставке (а дальше заставки не грузится вообще)
Да, в новый чистый каталог из архива вытянул папку compiled, просто запустил FlylinkDC.exe . Дергает http://armarium.org/u/2014/02/07/bVIKf.jpg , зачем - не знаю, вопрос к разработчикам
Добавлено: 07 фев 2014, 20:10
flylinkdc
У меня не повторяется
а вы точно ему базу и конфиг от старой версии не подсунули?
у меня после чистого запуско одного екзе
1. он запустил мастер спросив про ник и прочее
2. предложил обновиться - и закачал всякие смайлы
3. создал пустые базы данных
4. закрыл прогу - все закрылось быстро
у вас на картинке активность с другими размерами файлов.
почему так?
помогите разобраться а то я может выпускаю глючный флай на публику.
последнее что меня - отказался от режима WAL