~AreEnn
~R4SAS
~orignal
~villain
&N00B
+Xeha
+relaybot
DUHOVKIN
Guest29533
HackerMan
Most2
Nausicaa
Ruskoye_911
Vort
`
acetone_
anon3
b3t4f4c3
fidoid
flumental
nemiga
not_bob_afk
plap
poriori
profetikla
segfault
soos
teeth
tensor
un
weko_
whothefuckami
java_
ща начну i2pd-flutter, вместо 2 проектов i2pd-android и i2pd-qt
weko
и чем именно явлется i2pd-flutter
java
глупый вопрос
java
гуятина
java
порт и2pd-qt на флаттер
Vort
поставил на тест с XU узлом последний коммит
Vort
смотрю - два раза выбрались правильно интродьюсеры. решаю проверить RI
Vort
и вижу, что интродьюсеры все исчезли. проверяю узел - он оказывается превратился в XR
Vort
это вообще нормально?
Vort
вижу уже и входящие с itag`ом
Vort
^^ а нет, похоже насчёт входящих я ошибся
Vort
с входящими как раз, наоборот, фигня
Vort
нет входящих теперь. в общем, похоже, это просто ошибка пир теста
Vort
опять надо баг гонять ) а ещё прошлый не проверен, так как интродьюсеров-зомби сегодня не было
Vort
вернулся опять Firewalled
Vort
смотрю логи по пир тесту, который привёл к статусу OK. пока что заметил, что запустилось два пиртеста сразу. уже понял, почему. но при чём тут ОК - ещё не понял
Vort
наверно двойной запуск не при чём
Vort
как я понял, у меня была недавно сессия с узлом, от котрого прилетел PeerTest msg=5. то есть, была пробита дырка
Vort
и так совпало, что Боб выбрал именно этого Чарли (у которого было пробитие)
Vort
1. может, я что-то не так понимаю. 2. но если понимаю правильно, то хз как такое чинить
Vort
может, надо хранить список узлов, с которыми недавно были коннекты, и не принимать во внимание PeerTest msg=5 от таких узлов
orignal
OK если до этого сессия была
orignal
тут ничего не поделать
Vort
опять ОК вывалился. ну так значит хранить информацию о последних сессиях
Vort
а вообще странно это - такое должно редко случаться
Vort
а тут второй случай за несколько часов
Vort
это при том, что SSU2 сессий на моём узле примерно 20-50
Vort
такие совпадения наводят на мысли об атаке
Vort
ну или просто я невезучий :)
Vort
оба Чарли были из Бельгии
orignal
тут x3
Vort
надо подумать, может ли атакующий как-то подстраивать такую ситуацию
orignal
смотнительно
orignal
точнее как может
orignal
боб же не знает у кого с чарли сессии
orignal
так а что с нулями то?
Vort
пока что нет условий для воспроизведения проблемы с нулями. вчера интродьюсеры творили какую-то фигню, а сегодня работают очень стабильно. так что пока что жду
Vort
сейчас на U узле у меня 51 транзит. при этом, 385 NTCP2 сессий и 678 SSU2 сессий. не многовато ли?
Vort
плохо представляю, какая норма, но что-то это выглядит дофига
orignal
может SSU сессии не дохнут?
orignal
потому что все время peer test шлют
Vort
из 678 сессий - 32 входящие
Vort
про пир тест не понял. это же U узел, он только сам тесты делает. и то, очень редко
Vort
NTCP2, понятное дело, вообще все исходящие
orignal
пардон keep alive
Vort
keepalive только для интродьюсеров у нас вроде
orignal
ты проследи будет ли их число все время расти или остановится
orignal
да но у тебя почти все исходящие сессии с relaytag
orignal
возможно бага где то что шлется для всех
Vort
ну так пока эти сессии не интродьюсеры, ничего туда не шлётся
Vort
да я сейчас буду логи смотреть
Vort
сессии же не просто так создаются. а по каким-то запросам
Vort
и эти запросы должны быть в логах
orignal
так у тебя у транзитов есть концы тоннелей
orignal
вот оттуда и прут запросы
Vort
заметил аномалию
Vort
DatabaseSearchReply for ogEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= num=0
Vort
NetDb: DatabaseSearchReply for OgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= num=3
Vort
NetDb: DatabaseSearchReply for OgGkPwEAAAAAAAAAAAAAAAEAAADZ3sfQMsbdX77AD6Q= num=3
Vort
странные хеши
orignal
ну значит в запросе такой был
Vort
NetDb: OgGkPwEAAAAAAAAAAAAAAAEAAADZ3sfQMsbdX77AD6Q= was not found on 7 floodfills
Vort
это не хеш, а херня. а его кто-то запрашивал. подозрительно
Vort
смотрю дальше
Vort
хотя для начала нарисую график по добавлениям и обновлениям RI. код у меня есть. вдруг получится красиво :)
Vort
понятно, что будут аномалии из-за двух статусов "ОК". но может будет что-то ещё
Vort
есть что-то ещё...
Vort
видимо, то, о чём tetrimer говорил
Vort
сейчас вытащу лог посвежее, обработаю и покажу график
Vort
и added и updated прыгают одновременно. хм
Vort
orignal: eI2NPDatabaseSearchReply - это только в ответ на наш запрос должно приходить или и просто так тоже?
orignal
есетственно только на запрос
Vort
а моему узлу делать нехрен OgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= запрашивать?
Vort
есть ли в i2pd проверка на то, что это ответ именно на запрос, а не просто так?
orignal
тебя в запросе о потсроении тоннеля об этом просят
orignal
говорят что следующий узел с таким адресом
orignal
вот ты и запрашиваешь
orignal
не помню есть или нет
orignal
насколько я помню там делается поиск запроса
Vort
"в запросе о потсроении тоннеля" - а там идентхеши логируются?
Vort
и вообще логируется ли запрос...
orignal
не помню
Vort
короч надо проследить что привело к I2NP: Handling message with type 3
Vort
если бы пришёл запрос на туннель, то было бы наверно сообщение Transports: RouterInfo for ... not found, requested ?
orignal
возможно
Vort
а такого для OgAA нету
Vort
сразу прямо DatabaseSearchReply и всё
Vort
без видимой предыстории
orignal
тогда надо смотреть
orignal
может опять какая атака
Vort
вот место в коде: github.com/PurpleI2P/i2pd/blob/8447822c3596cadadfa6c7bd7ab0643ddd814b34/libi2pd/I2NPProtocol.cpp#L814
Vort
я плохо в этом коде ориентируюсь, но пока что проверки на то, был ли запрос, не вижу
Vort
кстати, по времени вот это OgAAAAAAA чётко совпадает с первым всплеском на графике - [06/Aug/2023:15:33:37 +0300]
orignal
так смотри в треде netdb как обрабывается
orignal
а там должен быть поиск запроса
orignal
потому что нужны данные что уже запрашивали
Vort
auto dest = m_Requests.FindRequest (ident);
Vort
значит, не залогировали запрос своего узла
Vort
в логах XR узла тоже AAAAAAAAAAAAAAAAA находятся. но наверно там на фоне уймы других запросов это просто незаметно
Vort
по форме этих запросов с AAAAA у меня подозрение, что где-то может быть доступ за пределы памяти. может, и не в i2pd
Vort
допустим, вот такое: NetDb: DatabaseSearchReply for ~~-kPwEAAAAAAAAAAAAAAAEAAAAfpaKvNZuUlTqnL1A= num=1
Vort
такое ощущение, что с нулями перемежаются какие-то данные
Vort
NetDb: DatabaseSearchReply for ~~-CPwEAAAAAAAAAAAAAAAAAAAAAAAAAAD1SdXNzaWE= num=3
Vort
не нравится мне это. если я не ошибся, то ни через NetDb::RequestDestination, ни через NetDb::RequestDestinationFrom запрос с AAAAAA не проходит
Vort
ошибся. потому что запрос был отклонён с NetDb: Requested destination for Sr9AJ~d~AAAAAAAAAAAAAAAAAAAAAAAAEMQ8erlVAAA= not found
Vort
жду дальше
Vort
в общем, похоже, начинаю понимать
Vort
бывает, что запрос проходит через NetDb::RequestDestination (но я пока это не подтвердил), а бывает, что нет
Vort
но когда не проходит... он всё равно обрабатывается!
Vort
orignal: почему вот это так сделано? баг или в этом есть смысл? github.com/PurpleI2P/i2pd/blob/8447822c3596cadadfa6c7bd7ab0643ddd814b34/libi2pd/NetDb.cpp#L950-L954
orignal
баг я думаю
orignal
зачем нам ответ без запроса?
R4SAS
orignal: в тг поглядываешь?
orignal
мне некогда
orignal
я не буду разбираться счас с его проблемой
R4SAS
ты скажи, чего происходит когда в htobuf32 прилетает b32=0
orignal
когда буфер нулевой?
R4SAS
да
orignal
ясен пень что все повалится
orignal
вопрос то почему 0
R4SAS
оно?
orignal
так это нулевое значение
R4SAS
ладно, потом подумаем
orignal
почему там htobuf это более интересно
orignal
нормально там все
Vort
вот блин. похоже, атака идёт по-разному на R и на U узлы
Vort
на R узле всегда ответ Requested destination for ...AAA... not found
Vort
а вот на U узле через раз - то полная обработка (значит, found), то вот такая половинчатая
orignal
надо это поправить
orignal
нет запроса значит останаливаемся
Vort
а у меня там (на U узле) нету нужных инструментов, чтобы отследить, откуда запрос идёт
orignal
надо код поправить в приницпе
Vort
я боюсь, что это эксплоит на чтение памяти за пределами массива
Vort
то есть, это может быть 2 в 1 - и DDoS U узлов + флудфилов и какое-то извлечение данных откуда-то
orignal
да надо проверять и длину
Vort
бляя. а слона то я и не приметил
Vort
AAAA - это только частный случай
Vort
а вообще этих Requested destination for ... not found дохренища
Vort
за 30 часов работы XR узла - 90167 штук
Vort
их так много, что я вообще думал, что это норма - типа запрос пришёл, а ничего не нашлось
orignal
так с чего идут такие запросы?
orignal
может правда кто то ответами спамит?
orignal
ааа я знаю почему
orignal
наверное это с концов тоннелей берется
Vort
ну I2NP сообщение прилетает
Vort
я могу сейчас брекпоинт поставить. но не знаю - на что смотреть?
Vort
на стек?
orignal
то есть оно прилетает не к нам а к кому то еще
orignal
а мы просто в тоннеле его ловим
orignal
посмотри в TunnelEndpoin.cpp что там делается
Vort
давай вначале стек скажу
Vort
а не, там не понять
orignal
я вроде это уже выпилил
orignal
однозначно можно убирать тогда если незапршенный
Vort
короч мне кажется что и из NTCP2: I2NP и из SSU2: I2NP message идёт
Vort
но я пока плохо понимаю тот код
orignal
он так и должен идти
orignal
мы запрашиваем флудфил напямую и получаем ответ там же
Vort
ну а тут запроса нету, зато есть ответ?
orignal
дропать такой
Vort
который обрабатывается из-за бага и это решил атакующий поиспользовать?
orignal
почему он обрабатывался я выше объяснил
orignal
потому что мы раньше их в тоннелях ловили
Vort
то есть, остатки от старого кода?
Vort
хотя можно не пояснять
orignal
нашед
orignal
if (typeID == eI2NPDatabaseSearchReply)
orignal
// DatabaseSearchReply with new routers
orignal
i2p::data::netdb.PostI2NPMsg (CopyI2NPMessage (msg));
orignal
в Tunnel.cpp осталось
orignal
отткуда все и идет
orignal
это стоит выпилить
weko
Но всё же вот эти AAAAA есть же.
weko
Но интересно, у меня вроде нету
weko
А нет, есть
weko
Сообщения Database Lookup
Vort
weko: у тебя как проявляется? Try ~~8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= at 2 floodfill ? или Requested destination for AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= not found?
weko
Только DatabaseLookup
weko
Минут за 5 сообщений 10
weko
10-15
weko
Хотя не, тут штук 25
Vort
а, это у тебя флудфил?
weko
Короч 20 их
weko
Да
weko
Видимо только отдалённые последстия
weko
Не прямые
Vort
рождаются они на U узлах, а потом идут на флудфилы
Vort
ага
Vort
ну, точнее, понятно, что кто-то эти U узлы склоняет к такому поведению )
Vort
а вот как именно... пока что загадка
Vort
похоже, складывается цельная картина
Vort
помнишь, как я удивлялся, что на флудфил много U узлов "налипло"?
weko
Я не лез
weko
Что значит налипло?
Vort
и в netdb их много и в коннектах
Vort
по сравнению с XR узлом допустим
Vort
если U узлы из-за атаки делают много запросов к флудфилам, то это объясняет, почему их так много
Vort
а потом рейт на флудфиле проседает, потому что флудфил пытается пользоваться этими U узлами. а связаться с ними сложно, да и небось не на самых лучших каналах эти узлы
weko
Да, как раз не так давно просел рейт
weko
был выше вроде
weko
всё же где то эти RI создаются
weko
стоп. это же хэш
weko
а, значит таких RI в реальности не существует
Vort
ну да, чтобы узлы подольше поискали несуществующий RI
weko
но важно понимать что запросы могут быть вообще с одного узла и рассылаться через тунели
orignal
так это легко пофиксить же
weko
но тут вроде первоисточник - TBM
weko
вот за ними нужно следить