LINUX.ORG.RU

Но ведь это дыра для DDoS!

 , , ,


0

3

Посмотрел тут недавно лайв кодинг одного прикольного чувака из Сибири, который стримит на Твиче и позже выкладывает на Ютубе.

Ниже ссылки на этот стрим на обоих ресурсах:

Этот стрим посвящён проблеме закрытия сокета до того, как все посланные данные на самом деле ушли к получателю. Суть проблемы в том, что функция write (как и неупомянутая в стриме send) пишет данные в ядро, а дошли ли эти данные до получателя уже полностью она не знает, хотя сокеты в Linux блокирующие по-умолчанию. Если сразу после write() или send() вызвать close(sock), у принимающей стороны случится ECONNRESET (Connection reset by peer). Случиться это может в случае, если и принимающая сторона решила что-то нам послать в самом начале, а мы это не прочитали. Это важное условие, потому что в противном случае всё работает верно и без ухищрений.

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

В статье предлагаются следующие шаги для решения данной проблемы:

Во-первых предлагается вызывать shutdown(sock, SHUT_WR) на отправляющей стороне сразу после последнего write. Но этого недостаточно, поэтому так же предлагается выставить опцию сокета SO_LINGER которая уже сама по себе должна решить проблему, но почему-то её не решает и это выглядит так, как будто она просто не работает. Есть и Linux-only вещи, такие как SIOCOUTQ ioctl(). Но универсальным решением предлагается просто бесконечный цикл, в котором вычитываются все данные и лишь затем можно закрывать сокет.

Я проверил на своём компьютере большинство из выше перечисленного и этот бесконечный цикл действительно работает, а SO_LINGER с и без shutdown(sock, SHUT_WR) и даже с shutdown(sock, SHUT_RDWR) действительно не работает. Но ведь решение с бесконечным чтением в цикле - это дыра уровня DDoS, ведь если ко мне будет идти бесконечный поток данных, сокет я никогда не закрою.

Ещё одно наблюдение. Если перед закрытием сокета вызвать shutdown(sock, SHUT_WR) и короткий sleep, это так же решает проблему. Неужели в UNIX/Linux/POSIX нет нормального решения данной проблемы?



Последнее исправление: zg (всего исправлений: 2)
Ответ на: комментарий от zg

Сокеты закончились и вот он DDoS.

Сокеты закончились, сервер упал и перезапустился, разрабы получили сообщение в логах. Всё норм.

Но иногда нужен и голый TCP, а тут людей учат чему-то неправильному.

TCP должен умереть. Абсолютно ублюдочный протокол, на самом-то деле. Благо, мир движется в этом направлении, и есть QUIC.

hateyoufeel ★★★★★
()
Ответ на: комментарий от zg

У тебя физически нет 100% способа узнать приняла ли на самом деле принимающая сторона пакет или нет, если ты не получил ACK. Она может принять пакет, но не отправить ACK, или ACK может потеряться. И твой write будет висеть в ожидании вплоть до истечения всех таймаутов на соединение, если retry не сработали.

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

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

Если тебе нужно что-то большее, то не используй TCP. Используй, например, UDP и наверни сверху свою надёжность. Или свой протокол замути, благо в неиспользуемых ID протокола в IP недостатка нет, /etc/protocols говорит что

#       134-254                 # Unassigned
Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Или свой протокол замути, благо в неиспользуемых ID протокола в IP недостатка нет, /etc/protocols говорит что

Они скорее всего не будут работать. Помню пытался кастомные опции то ли к tcp то ли к ip сделать - оно не работало уже (через локалку разумеется работало). У домашних, по крайней мере, провов скорее всего файрволлы режут всё непонятное.

firkax ★★★★★
()
Ответ на: комментарий от hateyoufeel

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит. TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений). Для каких-то важных штук, которым нужна повышенная надёжность, но который при этом гарантированно не захотят тратить кучу трафика можно и другие протоколы делать, а ширпотребная вебня должна сидеть на своём низком приоритете и первой отваливаться (добровольно) при признаках потерь пакетов.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ну так ТС не уточнял где ему надо обеспечить 100% гарантированнную передачу данных.

Если всё кроме TCP/UDP/ICMP на пути режут, то, очевидно, либо поднимать VPN, либо делать поверх UDP.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

TCP надёжен настолько, насколько это возможно. А тебе советую почитать про задачу двух генералов, а не искать мифические протоколы, которые более надёжны, чем TCP. У TCP проблемы есть и QUIC некоторые из них решает, но вопрос надёжности к ним не относится.

Единственное, что можно притянуть в плане надёжности это слабоватая контрольная сумма - всего 16 битов.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 6)
Ответ на: комментарий от firkax

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

  • Ублюдочная идея нумерованных портов, которая должна сдохнуть;
  • Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
  • Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения без лишней головной боли;
  • Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, последние две проблемы решает QUIC. Вторую тоже частично решает, но с некоторым скрипом.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 5)
Ответ на: комментарий от vbr

TCP надёжен настолько, насколько это возможно.

О чём я прямым текстом и написал:

Это протокол, который обеспечивает лишь условный уровень надёжности при котором ты можешь быть уверен что принимающая сторона получила все данные только в том случае если ты получил все подтверждения от неё. … TCP пригоден только для каналов с низким уровнем потерь и при отсутствии зловредного намерения на принимающей стороне.

А тебе советую почитать про задачу двух генералов, а не искать мифические протоколы, которые более надёжны, чем TCP.

Так это не я, а ТС ищет. Меня TCP, как и его реализазия в линуксе более чем устраивают и никаких проблем с ними, требующих каких-то действий я не вижу.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Какой же ты мерзкий.

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

Ублюдочная идея нумерованных портов, которая должна сдохнуть;

А что в ней плохого? Ты хочешь текстовые длинные идентификаторы вместо этого передавать? Так они однозначно хуже.

система идентификации соединений через (sip, sport, dip, dport),

Опять - ты хочешь что-то длинное вместо них?

абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;

Да ну, УМВР.

Отсутствие возможности разбиения данных на отдельные сообщения

Это обычно делается уровнем выше.

Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт

Да нет, основная причина - веб-макаки везде. Пакетно-ориентированных протоколов поверх tcp полно, ни у кого нормального это проблем не вызывало.

Если пакет от сообщения A просрался, приложение не получит сообщение Б

А это, частично, то о чём я писал. Если у тебя потерялся пакет - остановись и подожди. Возможно ты забил канал и мешаешь соседям, дай им тоже им попользоваться. И большинство таких штук - вовсе не в самом tcp заложено, а во всякий дефолтных настройках (которые например позволяют retransmission timeout до нескольких минут делать, причём в линуксе это предусмотрительно сделано хардкодом в ядре а не sysctl, чтобы всякие домохозяйки не пытались «улучшать» себе инет ценой общественного вреда).

Если quic позволяет из коробки обходить это ограничение - он плохой.

Я не спорю, что протоколы, более устойчивые к сетевым проблемам, нужны. Но нужны они для нормальных вещей (таких как ssh например, чтоб потери пакетов не бесили фризами консоли по несколько секунд или минут), а не для ширпотребного веба со страницами по мегабайту или, хуже того, видеопотоками.

firkax ★★★★★
()
Ответ на: комментарий от hateyoufeel

система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты

а что там не работает? всё работает

Отсутствие возможности разбиения данных на отдельные сообщения

там же написано - что для потоков, не нравится - есть udp и sctp.

Ублюдочная идея нумерованных портов

предлагаешь вместо 2х байтового номера порта сделать номер в X байт с переменной длинной?

sergej ★★★★★
()

пишет данные в ядро, а дошли ли эти данные

ты должен подтверждать вручную в своем протоколе поверх tcp.

нет нормального решения данной проблемы?

Какой проблемы?

anonymous
()
Ответ на: комментарий от alysnix

не знаю что там он написал… просто берешь неблокирующие сокеты и все операции, тебе нужные, реализуешь с нормальными таймаутами.

Ну не всем нужна асинхронщина.

а отслылка данных делается с ожиданием подтверждения их приема в течении секунды например.

Тебе осталось рассказать как получить подтверждение приёма через socket API.

если за секунду подтверждения не пришло, пытаешься что-то делать. как минимум это говорит о том, что на логическом уровне нет коннекта, и противная сторона перестала реагировать.

Что-то делать у тебя уже на уровне реализации TCP протокола сделано. Если получение пакета не подтверждено этот пакет будет послан заново самой реализацией TCP.

а просто так кидать в сокет и закрывать его… это совсем ненадежно.

Так на то он и блокируется, чтобы убедиться в том, что все данные отосланы. К сожалению лишь до ядра, а закрытие сокета иногда обрывает свзь ещё до того, как ядро отослало все пакеты.

zg
() автор топика
Ответ на: комментарий от zg

подтверждение приёма через socket API

Никак, нет такой фичи в socket API

Так на то он и блокируется, чтобы убедиться в том, что все данные отосланы

Нет, в случае send блокируется он для естественной регуляции скорости подачи данных со стороны отправителя. Когда в tcp заканчивается tx буфер выделенный ОС под соединение очередной send блокируется до появления в буфере места для очередной порции данных.

anonymous
()
Ответ на: комментарий от Stanson

У тебя физически нет 100% способа узнать приняла ли на самом деле принимающая сторона пакет или нет, если ты не получил ACK. Она может принять пакет, но не отправить ACK, или ACK может потеряться. И твой write будет висеть в ожидании вплоть до истечения всех таймаутов на соединение, если retry не сработали.

В TCP уже есть механизм обработки ситуации потерия ACK и проблема вовсе не в функции write.

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

В данном случае теряются данные из-за неработающего SO_LINGER.

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

Речь вообще не о протоколе, на уровне протокола всё хорошо. Речь идёт о его релализации и socket API. Давай для аналогии поговорим о работе с диском, ну с кажем в Java. Допустим мы открыли файл через FileInputStream, а затем обернули его буфером и ридером. Если я вызову close ридера произойдёт последовательный вызов close всех нижестоязих ридеров и стримов, вплоть до исходного FileInputStream. При этом все данные в буфере каждого из них (если такой буфер есть) будут слиты вниз на диск. Вот примерно такое же поведение ожидается и от close сокета, по крайней мере с ненулевым SO_LINGER.

Если тебе нужно что-то большее, то не используй TCP. Используй, например, UDP и наверни сверху свою надёжность.

Во-первых зачем изобретать велосипед? Во-вторых почему ты решил, что так можно делать всегда?

zg
() автор топика
Ответ на: комментарий от anonymous

Никак, нет такой фичи в socket API

Вот именно.

Нет, в случае send блокируется он для естественной регуляции скорости подачи данных со стороны отправителя. Когда в tcp заканчивается tx буфер выделенный ОС под соединение очередной send блокируется до появления в буфере места для очередной порции данных.

О чём и речь. Он блокируется лишь до окончания записи в ядерный буфер, а потом хоть трава не расти и закрытие сокета тупо убивает всё, что ещё осталось недопосланным в этом буфере. Это поведение должен меняться при помощи SO_LINGER, но он сломан.

zg
() автор топика
Ответ на: комментарий от anonymous

Live coding ничего общего не имеет с «программистскими» видео. Вы бы сначала ознакомились с темой, прежде чем показывать свое невежество и газофицировать лужу.

Узнаю типичное совково-программистское хамство и ЧСВ. Наверное поэтому Алексей Кутепов, за разве что одним исключением, никогда не стримит на русском.

zg
() автор топика
Ответ на: комментарий от Stanson

Ну так ТС не уточнял где ему надо обеспечить 100% гарантированнную передачу данных.

Везде, где никто, кроме собственного сокета, не теряет эти самые данные на ровном месте. Разумеется речь лишь про TCP.

zg
() автор топика
Ответ на: комментарий от zg

Это поведение должен меняться при помощи SO_LINGER, но он сломан.

Точно ли сломано? Как бы если тебя это так интересует то просто прочитай исходники, там чётко будет видно что и почему происходит и уже с этим можно дальше работать. Так-то я запустил тот пример и оба варианта отрабатывают у меня нормально.

V1KT0P ★★
()
Ответ на: комментарий от zg

Что-то делать у тебя уже на уровне реализации TCP протокола сделано. Если получение пакета не подтверждено этот пакет будет послан заново самой реализацией TCP.

это лишь значит, что данные доехали до буферов ос. но это не значит, что кто-то их прочитал. и прочитал и понял.

а твоя задача, чтобы их прочитали и поняли. иначе твой протокол ни о чем.

нет, ну если тебе важно просто отправить, не особо заботясь о том, что их прочтут..то зачем их вообще отравлять.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от V1KT0P

Физических или виртуальных?

Физических

Кстати еще мысль использовать сисколы напрямую, а то мало-ли это glibc что-то не так делает.

Цель - как раз найти кто делает не так.

zg
() автор топика
Ответ на: комментарий от firkax

Не знаю что это такое. Посмотрел в поиске - что-то гугловское. Значит да, именно они.

Веб макаки как раз не любят gRPC, начинают топать и требовать RestAPI.

zg
() автор топика
Ответ на: комментарий от zg

В TCP уже есть механизм обработки ситуации потерия ACK

Да неужели. Приёмник принял пакет и отрубился. ACK не приехал. Дальше что?

и проблема вовсе не в функции write.

А с write никакой проблемы нет. Как и с TCP.

Проблема у тебя, ты хочешь от TCP того, для чего он просто не предназначен.

В данном случае теряются данные из-за неработающего SO_LINGER.

А с чего ты взял, что они теряются?

Давай для аналогии поговорим о работе с диском, ну с кажем в Java

Мда. Java не работает с диском. Вообще. В ней в принципе нет ни прерываний чтоб syscall вызвать, ни способа писать-читать регистры периферии чтобы работать с диском напрямую.

При этом все данные в буфере каждого из них (если такой буфер есть) будут слиты вниз на диск.

Жаба головного мозга? Данные не будут слиты на диск, например, если у тебя JVM грохнулась. Или диск выдернули. Или комп из розетки.

Вот примерно такое же поведение ожидается и от close сокета, по крайней мере с ненулевым SO_LINGER.

Ещё раз - если принимающая сторона не хочет отправлять ACK, то никакой SO_LINGER не поможет. В TCP нет способа узнать, был ли на самом деле принят отправленный пакет или нет.

Во-первых зачем изобретать велосипед?

Ну так это тебе нужен велосипед, с гарантированной доставкой в любых условиях.

Во-вторых почему ты решил, что так можно делать всегда?

Потому что всегда можно сделать своё, если не нравится то, что сделали другие.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Ну ты зануда.

Приёмник принял пакет и отрубился. ACK не приехал. Дальше что?

Речь вообще не шла о физическом сбое.

А с write никакой проблемы нет.

«И твой write будет висеть…» - это кто сказал? И снова, я говорил вовсе не о зависании write.

А с чего ты взял, что они теряются?

Статью не читал, ролик не смотрел?

Java не работает с диском. Вообще. В ней в принципе нет ни прерываний чтоб syscall вызвать, ни способа писать-читать регистры периферии чтобы работать с диском напрямую.

Снова, никто не говорил ни о прерываниях, ни о сисколах ни о прочих твоих заумствованиях. Речь шла о буферах данных, которым делают flush перед реальным закрытием и именно этим избегают потерю данных.

Жаба головного мозга? Данные не будут слиты на диск, например, если у тебя JVM грохнулась. Или диск выдернули. Или комп из розетки.

Так это у тебя что-то с мозгом. Ты ещё марсиан вспомни или атомную войну. Ещё раз, специально для тебя, речь вовсе не об этом. Речь о работе API. Всё ещё не понятно? Забей ибо разжёвывать дальше я тебе не доктор.

Ещё раз - если принимающая сторона не хочет отправлять ACK, то никакой SO_LINGER не поможет. В TCP нет способа узнать, был ли на самом деле принят отправленный пакет или нет.

Ну откуда ты взял, что «принимающая сторона не хочет отправлять ACK»? Это тебе какие-то голоса в голове напели? Ещё раз настоятельно рекомендую внимательно прочитать статью и/или посмотреть первую половину ролика с наглядной демонстрацией потери данных.

Ну так это тебе нужен велосипед, с гарантированной доставкой в любых условиях.

Это клиника, ты читать не умеешь.

Потому что всегда можно сделать своё, если не нравится то, что сделали другие.

У тебя снова проблемы с пониманием. Речь идёт о реализации стандартного или стороннего протокола, который должен работать поверх TCP. Автор стрима реализовал WebSocket и какое-то время не мог разобраться с иногда возникающей потерей данных. Прочитанная и продемонстрированная им статья помогла исправить эту проблему.

zg
() автор топика
Ответ на: комментарий от zg

О чем и речь, Rexim стримит на английском потому что там аудитория понимает и ценит live coding. А в русской аудитории понабегут хейтеры и будут плакать что это не нужно это же «программисткое» видео, хотя сами до такого никогда в принципе не дорастут, ведь они не могут в критическое мышление и не осознают какого рода квалификация должна быть (спойлер: довольно высокая)

anonymous
()
Ответ на: комментарий от zg

Засунь свой ролик себе туда, где ему самое место. Насмотрятся говнища всякого, а потом всякой чушью на форумах срут.

Никаких проблем ни с TCP, ни с реализацией оного в линуксе нет.

Автор стрима реализовал WebSocket

Ну и дебил этот автор. Во-первых, потому что только дебил будет «стримить своё программирование», а во-вторых потому что WebSocket это лютая мерзость, которая не имеет никакого смысла, и реализована теми самыми упорышами которые из браузеров сделали невменяемых глюкавых монстров с анальными зондами. Нет вообще ничего удивительного, что эта параша работает через жопу и требует камлания с бубном чтобы хоть как-то работать.

Не надо использовать WebSocket ни для чего и никогда. А пользователям браузеров крайне рекомендуется отключить это говно совсем. Оно не нужно. В firefox это делается выставлением network.websocket.enabled в false.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 2)

Если перед закрытием сокета вызвать shutdown(sock, SHUT_WR) и короткий sleep, это так же решает проблему. Неужели в UNIX/Linux/POSIX нет нормального решения данной проблемы?

чтобы тебя не зафлудили снаружи, ты должен сделать shutdown(sock, SHUT_RD) - то есть запретить прием, а потом вычитать все что есть принятого.

потом сделать шатдаун за запись, и тут закрыть свой сокет.

ты так делал?

alysnix ★★★
()
Ответ на: комментарий от firkax

Сомнительная стратегия. Не надо решать несуществующие задачи странными способами.

у него некий особый случай. он создал себе проблему и пытается ее решить. но похоже он решает ее не так как надо.

alysnix ★★★
()
Ответ на: комментарий от sergej

а что там не работает? всё работает

Ты переключился на другую wifi-сеть, у тебя сменился IP, все соединения надо устанавливать с нуля. Не работает.

Отсутствие возможности разбиения данных на отдельные сообщения

там же написано - что для потоков, не нравится - есть udp и sctp.

SCTP нет, он умер. Здоровая часть роутеров не поддерживают NAT для него. Поддержка софта тоже так себе. Ну и собственные недостатки у него тоже есть.

UDP сам по себе достаточно бесполезен, но на его базе сделан QUIC. От которого @firkax тут поплавило (в сетях он, похоже, разбирается ещё хуже чем в программировании).

Ублюдочная идея нумерованных портов

предлагаешь вместо 2х байтового номера порта сделать номер в X байт с переменной длинной?

Узко мыслишь. Номера портов нужны для двух вещей:

  • Мультиплексирование при установке соединения (т.е. выбрать в какому сервису подключаться: 22 для ssh, 25 для smtp и т.д.);
  • Трекинг уже установленных соединений.

Для первого можно просто посылать строчку с названием сервиса в первом пакете. Т.е. это будет происходить ровно один раз за сессию, проблемы вообще быть не должно.

Для второго можно при установке соединения задавать уникальный ID для него (например, UUID на 128 бит) и передавать его в каждом пакете. Если из пакетов после этого будут выкинуты номера портов и прочая бесполезная ссанина, сильного оверхеда не будет. Бонусом получается возможность продолжить соединение после смены IP одним из участников, и вот это вот позволит упростить реализацию современных сетей. Например, современные сотовые сети достигают бесшовной передачи абонента между базовыми станциями тем, что эмулируют одну огромную локальную сеть, в которой каждый абонент имеет постоянный IP (v6). Вот этот вот анал-карнавал сразу станет не нужен.

Ксо жалению, TCP и UDP никогда не сдохнут, потому что тогда придётся все существующие сети на мороз выкидывать вместе с софтом и админами, которые ничего больше не умеют. А жаль.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

красиво было на бумаге, да забыли про овраге…
я считываю uuid потока, который хочу вскрыть и шлю пакеты от другого адреса под этим же uuid, ибо uuid не привязан к адресу. целевая прога ловит и правильные пакеты данных и засланные мной левые. разобрать кто прав кто виноват не получится ибо произвольная смена адреса допускается в предлагаемом протоколе связи.

тададам !! продвинутый погромист хайтюфил пропогандирует дырки в протоколах.
просто чутка подумал наперед… сохдать хороший протокол это вам не в лужу пёрнуть.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 3)
Ответ на: комментарий от pfg

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

Да нет, это решается криптотокеном при установлении соединения. Тащемта, весь трафик сейчас всё равно с TLS идёт, поэтому твои пакеты с другого адреса и с неправильным токеном будут отосланы в /dev/null.

С слову, идентификация соединений по (sip,sport,dpi,dport) тоже нифига не безопасна сама по себе, потому что провайдер может насовать говна в трафик. И, хуже того, суёт. Доказано РКН.

просто чутка подумал наперед… сохдать хороший протокол это вам не в лужу пёрнуть.

Ага. И, я бы сказал, авторы TCP тут обосрались, но их винить – гиблое дело. В 70х никто не предполагал, что инторнеты примут нынешний облик.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

и криптотокен генерить для каждого пакета и таскать в каждом пакете ?? %) ибо если криптотокен будет неуникальным, то его можно скопировать в левые пакеты :)
абсолютного решения тут не сделаешь.
и абсирание авторов TCP тут не поможет :)

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)
Ответ на: комментарий от pfg

и криптотокен генерить для каждого пакета и таскать в каждом пакете ?? %)

Зачем для каждого? Только при переустановке соединения. Ты сейчас replay attack описываешь, это решается.

и криптотокен генерить для каждого пакета и таскать в каждом пакете ??

В каждом сообщении будет подпись этого сообщения. TLS так и делает. Сообщение может состоять из нескольких пакетов.

абсолютного решения тут не сделаешь.

Что такое «абсолютное решение»? Я тут утверждаю, что с учётом накопившегося за последние 40 лет опыта, можно сделать гораздо лучше TCP. Ни про какие «абсолютные решения» я не пишу.

и абсирание авторов TCP тут не поможет :)

Авторов TCP никто не обсирал. Авторы TCP делали протокол с учётом имевшейся у них информации, актуальной почти 50 лет назад. Другой вопрос, что сегодня их опыт не актуален вообще никак и современные сети не имеют ничего общего с сетями их 1970х (Ethernet тоже надо под нож пустить, к слову).

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Зачем для каждого? Только при переустановке соединения. Ты сейчас replay attack описываешь, это решается.

дык я не про переустановку соединения говорю :), а про возможность передачи потока с разных адресов под одним uuid.
как отличить левые пакеты от правых ?? по какому параметру ??
тут не стабильны поток с TLS с одного и того же адреса, что эффективно отфильтровывается, а работа с каждым отдельным пакетом :)
я лишь к тому, что твое предложение с фильтрацией по некоторому uuid пакетов дырявое. кг/ам %) предлагай дальше.

pfg ★★★★★
()
Ответ на: комментарий от pfg

дык я не про переустановку соединения говорю :)

Сорян, опечатался. Я имел ввиду восстановление соединения при смене IP у одного из участников.

как отличить левые пакеты от правых ?? по какому параметру ??

По подписи. Даже в текущей ситуации единственный способ отличить твои пакеты от тех, что тебе провайдер или РКН напихал, это подпись. Ваш К.О.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

Фильтровать сетевые (ддос-) пакеты на уровне приложения с привлечением асимметричной криптографии - это мощно.

Удачи фильтровать DDoS трафик по номеру порта лол! Проблему DDoS ничего в этом треде вообще не решает.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Если адрес уникален и сетевая инфраструктура (провайдеры) не занимается подменой адресов, то такой ддос в принципе невозможен и режется уже на первом хопе, а не на последнем на уровне приложения.

anonymous
()
Ответ на: комментарий от anonymous

О каком DDoS речь-то? DDoS подразумевает, что исходящих адресов много (первая D – Distributed). Типичный DDoS – это внезапно появившиеся 100 гигабит в секунду трафика на твоём сайте. Их бесполезно фильтровать в одном месте, хоть по номеру порта, хоть ещё как.

сетевая инфраструктура (провайдеры) не занимается подменой адресов

А они занимаются. Почти все поголовно. Классический случай: многие провайдеры при попытке зайти на «запрещённый» сайт пришлют тебе RST от якобы того сервера.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonymous

Да нет. Всё, что я описываю, это просто замена TCP на QUIC сразу поверх IP плюс немножко фишек сверху (NAT через ID сессии из QUIC вместо номеров портов). Это даже не моя идея, так-то. Я ещё отсюда стащил (автор в итоге участвует в разработке Tailscale).

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)