Comments 69
Ну зачем же, просто проапдейтят СОРМы )) По крайней мере, вряд дадут использовать эту технологию, если не будет хоть какого-нибудь контроля
-4
Что-то я не уловил. Если за обычными пакетами TCP следят, то почему не могут следить и за ретрансмиссией? Они же принципиально ничем не отличаются.
+1
Они просто не смогут разобрать где какие, как я понял
+2
Ага, когда ретрансмиссия используется в обычном режиме, то клиент прекрасно разбирает все. Но при этом количество ретрансмиссий несравнимо меньше с количеством обычных сообщений, поэтому уж их то можно не напрягаясь отследить.
+1
Теоретически можно поймать и на пересылке в ретрансмиссии. Но практически это сделать очень сложно. Через даже среднего провайдера в секунду проходит столько пакетов, что всех их проинспектировать очень затруднительно в плане вычислительных ресурсов. Если бы целиком все TCP соединение представляло собой тайную переписку, то достаточно было бы поймать и проанализировать всего лишь несколько пакетов. Но как было правильно подмечено, ретрасмиссия происходит достаточно редко поэтому поймать становится еще во много раз сложнее чем случае с целым TCP соединением.
+1
Ну почему же, на очень низкой скорости вполне можно сделать такой скрытый канал, а для передачи шифровки одного байта в секунду вполне хватит.
0
Тем, что ретрансмиссии пока не логируют.
-1
Принцип Неуловимого Джо.
+6
Ух, достаточно интересная, но сложная в реализации вещь
0
Да, сами авторы даже и не стали реализовывать — ограничились симуляцией. А вообще тема интересная, но что-то хабронарод не впечатлила. Видимо сложноват материал для среднего хабраюзера.
-1
Я думаю, впечатлила бы больше, если бы была реальная реализация этого метода, который можно было бы попробовать.
Это, разумеется, не в к Вам претензия :)
Это, разумеется, не в к Вам претензия :)
+4
Ничего сложного, строго говоря, вопрос только в том, что таки вещи не стоит афишировать. Можно-же инкаспулировать информацию в ICMP пакеты, причем когда я это упоминаю, даже не все ай-тишники понимают как это может быть.
+3
icmp — это уже старая песня. когда приложение, которое не хочет чтобы его обнаружили, тихо шлет пинги куда надо и в них передает скрытую информацию. а вот посылать тихо битые пакеты — это уже интересный случай.
другой момент меня заинтересовал а не проходит ли проверка целостности передаваемой информации на маршрутизаторах? т.е. уйдет ли битый пакет дальше первого умного роутера?
другой момент меня заинтересовал а не проходит ли проверка целостности передаваемой информации на маршрутизаторах? т.е. уйдет ли битый пакет дальше первого умного роутера?
+3
А куда спешить? Борцуны только начали читать RFC, толи еще будет.
Любой JS у тоталитарных спецслужб вызовет подозрение, да и стеганография на JS и без переписывания TCP/IP стека не впечатляет.
Любой JS у тоталитарных спецслужб вызовет подозрение, да и стеганография на JS и без переписывания TCP/IP стека не впечатляет.
0
UFO just landed and posted this here
Хм, метод действительно интересный, а при использовании в купе с криптографией так и подавно… но как быть с маршрутизацией таких пакетов? Они ведь должны не отличатся от других пакетов данной сессии иначе сразу станут видимыми, и как же они дойдут до нужного получателя и нужного порта?
0
Перехватить и расшифровать непросто, а вот «глушилку» поставить вполне реально. Кто мешает проксировать пакеты TCP и заниматься сборкой данных на устройстве-глушилке, а затем их пересылать получателю имитируя отправку от адресата? Поскольку данные проходят спецоборудование до того, как пойдут в сторону получателя (или, наоборот, сразу же после того, как попадут в подсеть назначения), то никакие ложные ретрансмиссии не помогут. На запрос ретрансмиссии «глушилка» честно ответит полученными данными.
+7
UFO just landed and posted this here
Нет, не отменили. Но все дело в том, что при помощи сокетов нельзя полностью контролировать работу TCP. Например нельзя «заказать» ретрансмиссию когда захочется. Если исходный пакет был получен корректно, то ядро не будет посылать запрос на ретрансмиссию — зачем? И, кстати, если все-таки «тайная» ретрансмиссия будет иметь место, то обычное ядро будет отбрасывать такие пакеты считая их дубликатами, ведь sequence number у них будет совпадать с уже полученными пакетами. Кратко говоря, для этого метода нужно иметь возможность контролировать работу TCP/IP стэка на уровне ядра, уровень raw socket'ов слишком высок для этого.
+2
Но менять стек не надо все равно. Сниферы ведь работают и получают все пакеты включая ретранслированные. А это обычные программы пользовательского уровня.
0
Имеется в виду изменение стэка не для перехвата и анализа, а для реализации самого метода.
0
Дык! для реализации метода потребуется raw-сокет на отсылку и libpcap-снифер захватывающий все пакеты для приема.
0
Ну, в принципе можно попытаться это сделать и так, но несовсем понятно как именно. Вам тогда придется все TCP соединение реализовывать при помощи raw-сокетов. Потому что в противном случае вы не будете знать когда именно посылать «тайный» пакет. Он же не наобум посылается, а когда приниматель просит это.
0
Ну, можно просто опустить IP-стек на нужном интерфейсе и/или не отдавать пакеты ядру, дропая их где-нибудь в файрволе.
0
Если «норма» потерянных пакетов составляет 0.1%, тогда и скорость передачи такой информации составит одну тысячную от нормальной скорости канала (то есть от 2 мбит останется 2 кбита), иначе этот канал просекут в момент по подозрительно большому количеству ретрансмиссий
+8
Совершенно верно подмечено, это действительно один из недостатков метода.
+2
А точнее одну десятитысячную — чтобы норму потяренных пакетов не нарушать )
0
Верно, письма посылать можно будет, а фотки и видео — уже нет.
0
Провайдер не всегда знает норму последней мили, особенно в случае слабого сигнала от wi-fi-роутера, который раздаёт интернет по квартире :-)
0
что этим методом хотят скрыть? факт установки соединения остается. факт передачи данных тоже. чисто статистически «тайные» данные лучше передавать в обычных пакетах, ведь таких пакетов гораздо больше, чем ретрансмиссионных.
0
Все верно. Но при этом в статье также рассматриваются случаи когда отправитель оригинальных пакетов, получатель оригинальных пакетов или же оба не знают о факте передачи скрытых данных. Т.е. в этих случаях стороны, обменивающиеся стеганограммой частично или полностью «паразитируют» на существующих соединениях. В этих сценариях факт установки соединения и факт передачи данных роли не играют, поскольку конечные узлы — не участники «тайной» передачи. Само собой в этих сценариях есть недостаток — паразитирующие узлы должны иметь возможность перехватывать все пакеты в соединении.
0
>Суть предложенного метода состоит в том, чтобы в пересылаемом сообщении отправлять не то, что было в первичном пакете…
Отловить такие пакеты элементарно, сам факт различия является признаком того, что пора готовить паяльник.
Кстати, понятие «пакет» не применимо к TCP (в отличие от UDP).
Отловить такие пакеты элементарно, сам факт различия является признаком того, что пора готовить паяльник.
Кстати, понятие «пакет» не применимо к TCP (в отличие от UDP).
-3
Кстати, понятие «пакет» не применимо к TCP (в отличие от UDP).
любопытно. почему?
0
Да, мне тоже любопытно.
0
Кажется человек просто придирается к словам, вот перечитал RFC — «Термин пакет в данном документе используется в основном для обозначения одной транзакции между хостом и его сетью». Так что в TCP есть пакеты и это понятие вполне применимо
0
Возможно, хотя мне кажется, что предложение «The term packet is used generically here to mean the data of one transaction between a host and its network» можно понимать и по-другому. А если точнее, то «transaction», как мне кажется — это акт единичной передачи порции данных, т.е. фактически один пакет. Хотя даже если я заблуждаюсь, то с 1981 года многое молго измениться и сейчас, я совершенно уверен, употребляют выражение «TCP пакет».
0
TCP оперирует байтами и ориентирован на поток данных.
Программно нельзя просто так заведомо передать пакет. Операционная система будет складировать все в буфер и выдавать в сеть сегменты информации по своему усмотрению. То же самое может произойти на особо умных маршрутизаторах и уж тем более на прокси. На приеме операционка опять все складирует в буфер и выдает программе.
Т.е. приняв сегмент TCP нельзя точно сказать что программа на другой стороне передала именно такой кусок.
Например, поток данных 123456789 программа передавала следующим образом: 1 234 56 789, на приеме можно получить, например, 1234 56789.
Есть, конечно, PUSH, но опять-таки не гарантируется что на выходе получим сегмент нужного размера. Да и смысла в этом нет. PUSH сделан для ускорения доставки, чтоб информация поменьше залеживалась в буферах.
Программно нельзя просто так заведомо передать пакет. Операционная система будет складировать все в буфер и выдавать в сеть сегменты информации по своему усмотрению. То же самое может произойти на особо умных маршрутизаторах и уж тем более на прокси. На приеме операционка опять все складирует в буфер и выдает программе.
Т.е. приняв сегмент TCP нельзя точно сказать что программа на другой стороне передала именно такой кусок.
Например, поток данных 123456789 программа передавала следующим образом: 1 234 56 789, на приеме можно получить, например, 1234 56789.
Есть, конечно, PUSH, но опять-таки не гарантируется что на выходе получим сегмент нужного размера. Да и смысла в этом нет. PUSH сделан для ускорения доставки, чтоб информация поменьше залеживалась в буферах.
-4
UFO just landed and posted this here
Чем же так TCP отличается UDP? Святым духом, что ли, передаётся?
0
Впринципе интересный способ, но есть смысл его слегка развить. Например записывать в резервные 6 бит некую мета-информацию… или в опциональные байты заголовка…
в качестве мета-информации можно например взять порядок следования пакетов или частоту их следования относительно обычных ретрансмиссий
в качестве мета-информации можно например взять порядок следования пакетов или частоту их следования относительно обычных ретрансмиссий
+1
Отличные предложения. На самом деле, если Вам интересно, то в статье авторы разбирают многие из техник, которые Вы предложили (и придуманы они уже давно). Всего авторы приводят 3 типа стеганографии при помощи TCP: (i) модификация пакетов и хедеров, (ii) модификация свойств соединения (изменение порядка следования пакетов, варьирование времени между пакетами и т.д.) и (iii) гибридные. Свой метод авторы относят к последней категории.
0
Такие вещи уже давно используются.
0
+1
Более чем уверен, что хорошие IDS, использующие поиск аномалий в трафике распознают эту стеганографию с полпинка.
+1
Эффективней тогда уж тогда обычной стеганографией пользоваться в образах DVD-фильмов или в авишках, косяк в 1 пикселе на фрейме вряд-ли кто заметит, а даже если и заметит — извиняйте хреново пожалось. Опять же при закрытом алгоритме размещения пикселя в кадре — замучаешься доказывать и расшифровывать.
И никто не докапается — а почему у тебя потери пакетов выше нормы? ;)
И никто не докапается — а почему у тебя потери пакетов выше нормы? ;)
0
Я так понимаю, посылатся обычный пакет и ретрансмиссия.
Тогда передача обнаруживается простым сравнением этих пакетов. Не так ли?
Хотя идея хороша, еее только нужно хорошенько обдумать, покурить TCP/IP.
Тогда передача обнаруживается простым сравнением этих пакетов. Не так ли?
Хотя идея хороша, еее только нужно хорошенько обдумать, покурить TCP/IP.
0
имхо, проще секретный документ запаковать в шифрованный файл siski_podrugi.rar и отправить обычным smtp :)
чем не точно такая же стеганография — нельзя, ведь, быть точно уверенным — что именно было в архиве :)
чем не точно такая же стеганография — нельзя, ведь, быть точно уверенным — что именно было в архиве :)
-1
Проще придумать свой или использовать какой-нить «мертвый» язык, на котором никто не говорит кроме вас и ващего адресата. В таком случае сообщения можно даже не шифровать, а писать прямым текстом, пусть дядечки читают смысл все равно им будет не понятен :)
Н ыпра нчог ыдганду :)
Н ыпра нчог ыдганду :)
0
Помимо того, что пропускная способность этого метода чудовищно низкая (как уже заметили в каментах выше), у этого метода ещё один существенный минус. Передача не защищена от ошибок на уровне TCP, т.к. сам этот метод паразитирует на средстве защиты.
0
Или я ничего не понял, или одно из двух. Этим методом вы пытаетесь скрыть сам факт передачи данных? Это при том, что в IP пакете явно прописан IP адрес получателя пакета, а в TCP — номер порта получателя. Таким образом, явно видно, что некие данные (не важно какие именно) пересылаются из токи А в точку Б. Ну и где здесь скрытая передача данных?
0
в том что порт этот может быть портом http. из цепочки пакетов сниффер покажет что пользователь просто ходил по сайту. а на самом же деле между хостами среди пакетов запросов ответов HTTP шел обмен данными другого рода.
0
Между какими хостами? Между клиентом и сайтом? Да, шел обмен данными, среди которых были конфиденциальные данные. Где здесь сокрытие факта передачи данных, я вас спрашиваю?
0
Подобный вопрос уже был выше, под ним и ответ. Повторюсь, во-первых можно пытаться скрыть факт передачи тайной информации. Тогда факт наличия соединения не играет роли — мы не пытаемся его скрыть. Во-вторых если все-таки нежелательно чтобы вообще знали о факте хоть какой-нибудь передачи, то как я писал выше, отправитель и получатель «нормальных» данных может вообще и не знать о факте тайной переписки.
0
> Security through obscurity
Безопасность по незнанию?)
Безопасность по незнанию?)
0
Не знаю что там используют Специально Обученные Люди, но повторно переданные пакеты подсвечивает другим цветом наиболее известный бесплатный софт для анализа — wireshark. Если у обьекта наблюдения на фоне остального нормального трафика пакеты по конкретному адресу постоянно красные, это тут же наведет аналитика на мысли.
0
Все верно, вопрос тут в том куда смотреть. Если у вас в секунду более 1000 TCP соединений в каждом из которых по 1000 пакетов, то Wireshark тут не помощник — в ручную перелопатить такой объем данных нереально.
0
Один человек столько не генерирует. Специально Обученные Люди действуют по решению суда или по секретному приказу начальника ( ну это в теории). В этот момент за кем наблюдать уже известно и трафика не так уж много.
Не вижу проблемы.
Не вижу проблемы.
0
Sign up to leave a comment.
TCP стеганография или как скрыть передачу данных в интернете