LINUX.ORG.RU

работа с ip-пакетами


0

1

Здравствуйте!

Пишу программу, которая должна заменять большой ip-пакет, исходящий с компьютера на несколько меньших определенного размера. В случае же, когда размер пакета слишком мал, дополнять его мусором.

1) Если писать модуль ядра и работать со структурами sk_buff, то получается не сильно переносимо на новые версии ядра и не очень удобно. К тому же глупо работать с sk_buff, чтобы собрать из них ip-пакет, когда он только что на них был разбит.

2) Если использовать библиотеку libipq для работы с iptables, то, как я понимаю, получаешь только первый ethernet фрейм, относящийся к ip-пакету. По нему надо решать, отбросить пакет или нет. Остальные фрагменты пакета в userspace не передаются. Этот вариант тем более не подходит, так как надо работать с ip-пакетом целиком.

Итак, вопрос, как получить доступ к ip-пакету в тот момент, когда он еще не фрагментирован на ethernet фреймы? Или подскажите, пожалуйста, библиотечку, которая умеет выдавать исходящие с компьютера (да подойдут и входящие) ip-пакеты целиком.

Спасибо!

Ответ на: комментарий от AITap

Нет, с помощью нее можно только просматривать пакеты. Она используется пассивными снифферами. Работает с ethernet фреймами.

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

Задача в этом и состоит. Надо, чтобы никто «азбукой Морзе» через длины пакетов не передавал информацию с компьютера. Для этого надо в зависимости от статистики выравнивать длины ip-пакетов.

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

Это в универе такая задача поставлена?

А как ты пакет мусором дополнишь если у пакета есть контрольная сумма? Такой пакет просто не пройдёт. А если пересчитать контрольную сумму то ты нарушишь целостность пакета своими данными.

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

> Это в универе такая задача поставлена? Да, это часть курсовика.

А как ты пакет мусором дополнишь если у пакета есть контрольная
сумма? Такой пакет просто не пройдёт. А если пересчитать контрольную
сумму то ты нарушишь целостность пакета своими данными.

Хорошее замечание. Буду считать, что пакет не подписан :-)

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

Да, пожалуй, это самое простое решение моей задачи. Буду перенаправлять весь исходящий трафик на свой сокет, с определенным портом. Спасибо!

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

Хорошее замечание. Буду считать, что пакет не подписан :-)

Это CRC, а не подпись. Пакет с битым CRC в IP-заголовке просто будет выкинут ближайшим маршрутизатором.

libpcap умеет работать с сетевыми устройствами в raw-режиме, минуя ядерный netfilter, etc.

Ethernet- и IP-фреймы по структуре такие простые, что можно самому всё за день написать, попутно изучая документацию.

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

Я думал, что фраза «если пересчитаешь контрольную сумму, то нарушишь целостность пакета» обозначает именно подпись, потому что «если пересчитаешь CRC, то будет битый CRC» странно звучит. Если я его пересчитаю, то он уже не будет битым :-)

Никто не спорит, что можно и за день и за меньше написать :-)

spopov ()

Перехват ip_output.
А ещё лучше(если работа будет с TCP), tcp_sendmsg или tcp_sendpage.(в таком случаи можно будет контролировать все передаваемые данные)

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

> А если пересчитать контрольную сумму то ты нарушишь целостность пакета своими данными.

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

gandjubas ()

Афтар, дополнять пакеты мусором у вас не получится - получатель поперхнётся. В этом случае я бы рекомендовал осуществлять сборку последовательных пакетов идущих по тому же самому адресу.

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

Каким образом?

«получатель поперхнётся».

Если вы не в курсе

поучи меня ещё сетям

если речь идёт о TCP соединении.

Фрагментация на уровне ip работает. См. поле Fragment Offset и флаги DontFrag и MoreFragments. На уровне tcp это тоже в теории можно, но ни один серьёзный роутер этим заниматься не будет. Как и фрагментацией пакетов, это всё бьёт по производительности и порождает лишние проблемы.

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

Пакет с битым CRC в IP-заголовке просто будет выкинут ближайшим маршрутизатором.

Кстати, один товарищ из циско сказал что роутеры скорее всего не проверяют контрольную сумму на уровне ip(речь, правда, об mpls шла). Только целостность ethernet-кадра проверяется внутри PHY. Лень проверять. Но, конечно, контрольная сумма пересчитывается при изменении ttl.

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

Надо, чтобы никто «азбукой Морзе» через длины пакетов не передавал информацию с компьютера.

Кстати, есть куча других способов передавать информацию скрытно. Азбука морзе как-то уж слишком медленно. Например, через icmp echo/reply в payload. Или битиками tcp «моргать». Или в ttl шифровать информацию. Да много чего придумать можно.

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

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

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

> Или битиками tcp «моргать»

То что предлагает автор - это практически стеганография, а у вас будет заметен факт передачи скрытой информации. Например: никто не моргает битиками, один вы моргаете - вуаля, вы себя выдали.

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

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

Только для tcp-трафика, а тут речь про ip шла. Хотя, подозреваю, именно tcp и интересует.

никто не моргает битиками, один вы моргаете

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

true_admin ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.