LINUX.ORG.RU

iptables. можно ли маркировать все исходящие пакеты google chrome?

 


0

3

iptables. можно ли маркировать все исходящие пакеты google chrome тегом, например, «jack», при сефринге, чтобы приходящие от посещенных сайтов пакеты имели уже маркированный тег «jack»?

чтобы защититься от подмены трафика...


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

А если локально? Смотреть какие запросы идут на порты 80 и 443, а потом искать ответы от хостов, на которые эти запросы уходили? Это, конечно, если в http(s) ходит только chrome.

alozovskoy ★★★★★
()

грязный хак - отдельный пользователь для хрома, а iptables умеет смотреть пакеты по пользователям
еще один - network namespace'ы(вроде так). Там свой изолированный интерфейс, и на него iptables

ii343hbka ★★★
()

Нельзя. Все метки на пакетах теряются после отправки пакета. А если быть точнее - метки существуют только на твоей машине.
Посмотри RFC по IP/TCP/HTTPS - там нет таких меток (хотя там есть много другого конечно).

Чем не устраивает https? Если у тебя в браузере установлены доверенные сертификаты и ты доверяешь удостоверяющим центрам, то от man-in-middle ты защищён.
Ну, исключаю какие-нибудь уязвимости в протоколе :)

Nao ★★★★★
()

чтобы защититься от подмены трафика...

Что мешает атакующему подменить сами метки?

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

ТС хочет защищаться от подмены трафика. Чем пришедший от удаленного хоста ответ поможет узнать, не было ли подмены?

YAR ★★★★★
()

Можно править порт источника. Но оно тебе не поможет, используй tls, блджад.

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

В общем случае - никак.

Если есть контроль над локальной и удалённой машиной, то пообмениваться сетевым трафиком между ними и снять например tcpdump'ом трафик на обеих концах. Потом сравнить.

Гораздо важнее не определить, а предотвратить возможность подмены.
На голом IP/TCP, IP/UDP от этого не защитишься.

Можно защититься использую протоколы прикладного уровня с TLS/SSL, например HTTPS.
Если есть контроль над обеими сторонами коммуникации (например свой удалённый сервер), то вариантов масса: это различные туннели, например OpenVPN или IPSec.
В этом случае, искажение пакетов третьей стороной вызовет ошибку при расшифровке. Такие пакеты будут отброшены и не дойдут до следующего уровня.

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

Ну и если например есть подозрение что трафик подменяет кто-то в локальной сети или провайдер, а цель - ходить на сайты без https, то можно использовать различные сервисы VPN (при условии что ты доверяешь этому сервису).

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

Нет, в плане VPN понятно, а если нет контроля над удаленной машиной? Тот же https я так понимаю тоже будет возможно «поломать» если есть сертификат.

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

А откуда сертификат? У удалённой машины спёрли? CA слили сертификат? От кого защищаемся то?

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

Откуда я знаю? =) Сертификат просто есть. Я пока не придумал способа, который бы мог гарантировать что ответ пришел именно от того сервера\приложения, которому ты отправил запрос.

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

Если никому/ничему не доверять, то нет такого способа.
Может удалённый сервер взломали и трафик прослушивается/подменяется уже на сервере, а может в ядре линукса закладка от ФБР.

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

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

Тот же https я так понимаю тоже будет возможно «поломать» если есть сертификат.

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

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