mptcp и уход от корелляционных методов слежения

[gliderexpert]

Допустим, есть некий источник траффика (source) и цель (target).
Источник и цель находится в одной стране. Соответственно, использование VPN'ов в любом варианте, включая TOR - бесполезно, т.к. цепочку можно отследить по размеру пакетов и времени доставки, кореллируя данные СОРМа на передающей стороне, с данными СОРМа на принимающей стороне. Так можно начинать собирать доказательную базу причастности источника траффика к траффику идущему на цель.

Интересно мнение опытных специалистов, насколько в данной ситуации поможет следующая схема - делим исходящий траффик на несколько каналов при помощи методов multipatch tcp , каждый из этих каналов заворачиваем в TOR. Сумматор mptcp ставим на зарубежный VDS , и траф с него заводим обратно в страну где находится source.

По идее, можно обнаружить только факт использования mptcp , и отследить наши устройства, использующие mptcp - но вот смогут ли "умные люди" /*работающие зачем-то на "дядю" */ , собрать разные каналы в один поток и скорелировать его с трафом на цель? Ведь аплинки mptcp будут уже в цепочке тора.

Примерно такая схема

 

[bbi34yy]

bbi34yy сказал(а):
Я, может не сильно углубился, но тот же Whonix прекрасно рандомизирует размер пакетов.

а тайминги?

 

[gliderexpert]

Если под таймингами ты подразумеваешь TCP Timestamps (Каждый свое значение вкладывает), то и с этим там все в порядке.
Две утилиты работают, которые я заметил - tirdad и sdwdate.
Ты сам там FAQ почитай. Там много чего интересного.

 

[bbi34yy]

нет, не timestamps , а время отправки исходящего пакета и время приема этого пакета целью. Общее количество пакетов. Соответственно эти данные регистрируются СОРМом, или в постпроцессинге данных, собранных по "закону яровой"...
FAQи я конечно же читал, да и wireshark'ом владею...

 

[gliderexpert]

gliderexpert сказал(а):
т.к. цепочку можно отследить по размеру пакетов и времени доставки, кореллируя данные СОРМа на передающей стороне, с данными СОРМа на принимающей стороне. Так можно начинать собирать доказательную базу причастности источника траффика к траффику идущему на цель.

Поиск источника по корреляции пакетов я считаю, на данный момент, невыполнимой задачей. Когда источник известен, и задача найти корреляции в передаваемых данных между ним, и известным приемником, то это видится выполнимым, особенно если время наблюдения длительное. И вполне сойдет, как дополнительное доказательство в суде РФ или США.

ЗЫ. На практике, 90% садятся из-за отвалившегося впн, причем всего один раз. Тупо людям лень сеть или kill switch настроить, а может знаний не хватает. И светятся реальные айпишники в токсе мента из вашего контакт листа, логах джаббер сервера, на биржах, форумах, или еще где. А дальше из тысяч заходов по ВПН и тором, менты отлично находят всего один ваш заход, который важен, и раскручивают его. Это прям в методиках ментов всех стран, начинайте искать с тех айпи, где минимальное количество заходов, или максимальное количество заходов.

ЗЫЫ. Правоохранители ни одной страны с корреляциями данных так не копают, имхо, даже когда террористов ловят, но тема интересная. Ебучее будущее, не приходи!

 

[Stallman]

Пожалуйста, обратите внимание, что пользователь заблокирован
а сорм разве не стоит на всех бэкбонах (i.e. внутри target страны) ? если так, то есть теоретическая возможность откоррелировать любой траффик, неважно через какой миксер он прошел до попадания в страну.

 

[Harbour]

Harbour сказал(а):
а сорм разве не стоит на всех бэкбонах (i.e. внутри target страны) ? если так, то есть теоретическая возможность откоррелировать любой траффик, неважно через какой миксер

Поэтому нужно разбить исходящий траффик на несколько физически независимых каналов.
Вопрос в том, можно ли коррелировать каналы mtcp в tor оболочке между собой и установить таким образом источник, а далее уже его взаимосвязь с целью.

 

[gliderexpert]

gliderexpert сказал(а):
Вопрос в том, можно ли коррелировать каналы mtcp в tor оболочке между собой и установить таким образом источник, а далее уже его взаимосвязь с целью.

П - Паранойя. 100% нет.

 

[Stallman]

Stallman сказал(а):
Поиск источника по корреляции пакетов я считаю, на данный момент, невыполнимой задачей.

gliderexpert сказал(а):
Соответственно, использование VPN'ов в любом варианте, включая TOR - бесполезно, т.к. цепочку можно отследить по размеру пакетов и времени доставки, кореллируя данные СОРМа на передающей стороне, с данными СОРМа на принимающей стороне.

gliderexpert сказал(а):
делим исходящий траффик на несколько каналов при помощи методов multipatch tcp , каждый из этих каналов заворачиваем в TOR

Пожалуйста, обратите внимание, что пользователь заблокирован

└─ Бывали случаи когда московские фэйсы искали корелляцию в траффике всей МСК, но чтоб это произошло вновь они во первых должны пздц как захотеть этого. + иметь на это время, так как там толковых спец-ов ( не комерсантов, коих пздц проц 60-70 ) не так уже много, но опять же это понятие относительное, я думаю на нас с вами людей там точно хватит.


└─ не факт. Если у тебя по середине цепочки прокси воткнут радио-модем или иной канал связи независящий от интернета,. отследить уже сильно тяжелее, разгребая цепочку. эт тот вариант плох тем, что этоти штуки сами по себе красная тряпка - указывающая на то что, в локации чет мутят.


└─ ты пробовал траффик разводить по разным 3г\4г роутерам и можно, как вариант распределить для каждого процесса свой канал связи. но тоже смысла нет особого. так как если сотовая вышка рядом одна то там все и останется.
Но дробя трафик по каналам да еще и в тор заворачивая - можешь про внц\рдп забыть - нихера не будет работать, ток консоль софт, и то с delay-ами

 

[KAJIT]

KAJIT сказал(а):
└─ Бывали случаи когда московские фэйсы искали корелляцию в траффике всей МСК, но чтоб это произошло вновь они во первых должны пздц как захотеть этого. + иметь на это время, так как там толковых спец-ов ( не комерсантов, коих пздц проц 60-70 ) не так уже много, но опять же это понятие относительное, я думаю на нас с вами людей там точно хватит.

Ну это какой-то террор и пиздец, то о чем ты говоришь.
У них не было наколок, как сузить поиск?
Ну потому что наслоение данных уже мешает, а какой там анализ возможен и чего?

 

[stepany4]

gliderexpert сказал(а):
Поэтому нужно разбить исходящий траффик на несколько физически независимых каналов.
Вопрос в том, можно ли коррелировать каналы mtcp в tor оболочке между собой и установить таким образом источник, а далее уже его взаимосвязь с целью.

Пожалуйста, обратите внимание, что пользователь заблокирован

во-во - "физически независимых". если не использовать только tor или tor везде, а добавить шуму и пыли в виде совершенно разных L1 level, на которых нет СОРМ, то думаю придется мусоркам сильно напрягаться исключительно с других сторон, но никак не с сетевой.

 

[Harbour]

stepany4 сказал(а):
У них не было наколок, как сузить поиск?

Пожалуйста, обратите внимание, что пользователь заблокирован

это исключение из правила. это не показатель. да действительно небыло варианта по другом. Но типа нашли по итогу и набутылили все равно
Ну потому что наслоение данных уже мешает, а какой там анализ возможен и чего? >>> а пробивали всех кто конектился к определенному серверую чел юзал паблик вафлю. нашли за 4рые дня
Последнее редактирование: 08.11.2021

 

[KAJIT]

У нас на работе установили вот эту ебалу - https://roskomsvoboda.org/cards/card/tspu-blokrovki-runet/
Кто знает насколько это крутая штука.

 

[yashechka]

KAJIT сказал(а):
пробивали всех кто конектился к определенному серверую чел юзал паблик вафлю. нашли за 4рые дня

Я же тебе и про это и говорю. Мы можем крутить днями тысячи самых потрясающих графов связей в визуальном представлении связей что до идентификаторов.
Ну дня за четыре конечно разберемся. А в реале, можно было бы за пару часов.
Оперативно-технические средства не всегда панацея. Особенно в таких кейсах.

 

[stepany4]

Stallman сказал(а):
П - Паранойя. 100% нет.

KAJIT сказал(а):
как вариант распределить для каждого процесса свой канал связи. но тоже смысла нет особого. так как если сотовая вышка рядом одна то там все и останется.

П - Пруфы? ))


Останется, но будет разделено по хранилищам разных операторов, +закрыто "луковичным" шифрованием ТОРа, и будет ли оно являться доказательной базой в случае чего?

Единственный вариант - если шифрованный TOR ом multipath tcp траф смогут собрать в один поток - собственно, вопрос темы возможно ли ЭТО.

 

[gliderexpert]

Используй чужие точки wifi, забудь про деанонимизацию. Анонимзируй себя чем хочешь или не анонимизируй, проблемы всё равно не у тебя будут, а у соседа. =) Хотя всё же не подставляя его под удар, анонимизируй vpn через shadowproxy и tor. Следи за его квартирой, чтобы если вдруг гости наведаются, у тебя был шанс скрыться, уйти в оффлайн, переключится на другую точку и зачистить следы присутствия в роутере старой точки. Соседу ничего не грозит.

 

[Samorez]

gliderexpert сказал(а):
Останется, но будет разделено по хранилищам разных операторов, +закрыто "луковичным" шифрованием ТОРа, и будет ли оно являться доказательной базой в случае чего?

stepany4 сказал(а):
А в реале, можно было бы за пару часов.

Пожалуйста, обратите внимание, что пользователь заблокирован

бро трабла в том, что работать анрил. не пашет не черта по такой схеме

да понятно что некоторые могут и за 20мин. Но они исключение из правила. Контрактор цру\фбр канеш может, ему ток данные дай. уже все отработано
( https://www.palantir.com/platforms/gotham/ ) < --- эти вон к примеру

 

[KAJIT]

KAJIT сказал(а):
Контрактор цру\фбр канеш может, ему ток данные дай

Дам. Одно коммерческое решение дам.
С условием что моих bro и их решения palantir ты на этом форуме поднимать не будешь.
Для общего ознакомления.
Специальные решения для специальных служб
UPLOAD.EE - File does not exist
File does not exist. Upload.ee
www.upload.ee
от модератора: перезалил сюда по просьбам посетителей форума

 

[stepany4]

KAJIT сказал(а):
бро трабла в том, что работать анрил. не пашет не черта по такой схеме

ssh- консоль отлично работает, мосты на x25 сети тоже