IP-адрес источника записи переадресации портов Linux
Я работаю над настройкой нескольких приманок ICS для исследования, поэтому мне нужно иметь возможность записывать исходный IP-адрес получаемого трафика.
Я сам управляю серверами локально, но использую CGNAT/Double NAT при соединении 4G. Я настроил переадресацию портов через VPN-туннель Wiregurad на Linux VPS, чтобы предоставить внешний IP-адрес, по которому я могу открывать порты.
Однако это работает нормально, поскольку порт, пересылающий весь трафик, полученный приманками, имеет исходный IP-адрес VPS. Насколько я понимаю, переслать его с исходным IP-адресом невозможно, поскольку возникнут проблемы с маршрутизацией обратного трафика.
Мой вопрос: какой метод лучше всего записать исходный IP-адрес, чтобы его можно было сопоставить с трафиком, полученным на приманке? Я планирую перехватывать весь трафик в приманке, было бы целесообразно также перехватить и VPS и каким-то образом связать их?
Спасибо, Дэйв
Используя ответ ниже, вот шаги, которые я предпринял, чтобы это заработало:
1: удалена строка MASQUERADE выше, чтобы остановить изменение исходного IP-адреса.
2. Добавьте маршрутизацию на основе политик на сторону Honeypot:
ip -4 route add default dev wg0 table 4242
ip -4 rule add pref 500 from x.x.x.2 lookup 4242
3. Измените разрешенные IP-адреса в конфигурации Wireguard на стороне Honeypot, чтобы направлять весь трафик для внешних IP-адресов обратно через туннель. Я использовал этот сайт для расчета правильной конфигурации https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/
Одна ловушка, на которую следует обратить внимание, — это убедиться, что вы исключили IP-адрес для VPS, поскольку в противном случае Wireguard попытается направить трафик настройки туннеля через еще не существующий туннель, что происходит так хорошо, как вы можете себе представить!
Изменить: я добавил диаграмму, чтобы проиллюстрировать ситуацию. И VPS, и хост Honeypot — это машины Ubuntu, подключенные напрямую через туннель. Как мне следует использовать маршрутизацию на основе политик, чтобы сохранить исходный IP-адрес zzzz, когда он достигнет Honeypot? Допустим, yyyy:44444 на VPS перенаправляется на xxx2:33333.
Текущие правила IPTables, используемые для переадресации (на VPS):
iptables -I FORWARD -d x.x.x.2 -p tcp --dport 33333 -j ACCEPT
iptables -I FORWARD -s x.x.x.2 -p tcp --sport 33333 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp --dport 44444 -j DNAT --to-destination x.x.x.2:33333
iptables -t nat -I POSTROUTINGq -d x.x.x.2 -o wg0 -j MASQUERADE
1 ответ
Лучше вообще не выполнять преобразование адресов — часто SNAT является самым простым решением проблемы «маршрутизации ответов», но не обязательно единственным решением. Было бы возможно и лучше правильно настроить маршрутизацию, даже если это займет больше времени, чем просто установка правила SNAT на сервере.
Но если трансляция неизбежна, то лучше всего записать исходный адрес в том месте, где происходит трансляция адреса:
При использовании шлюза на базе Linux все состояние NAT (как входящего, так и исходящего) – и фактически все состояние каждого соединения, даже если NAT не используется – доступно в подсистеме «conntrack», например, вы можете отслеживать новые соединения в реальном времени. с использованием
В частности, вы хотите настроить ulogd2 с помощью
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so"
(other plugins...)
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"
stack=ct1:NFCT,ip2str1:IP2STR,print1:PRINTFLOW,emu2:LOGEMU
[emu2]
file="/var/log/ulog/ct.log"
С conntrack вам не нужно будет ничего сопоставлять, поскольку одна и та же запись состояния будет иметь как исходные, так и преобразованные («ответные») адреса/порты, что в первую очередь необходимо для работы NAT с отслеживанием состояния.
(Возможно, вы также захотите включить
Насколько я понимаю, переслать его с исходным IP-адресом невозможно, поскольку возникнут проблемы с маршрутизацией обратного трафика.
Частично это правда — всегда есть проблемы с множественной адресацией, но с этими проблемами можно справиться, в зависимости от ОС, работающей на ваших локальных шлюзах (или, альтернативно, на самих локальных серверах).
Если ваш локальный шлюз (локальная конечная точка WireGuard) также основан на Linux, то для достижения правильной маршрутизации обратного трафика к различным восходящим потокам часто используется «политическая маршрутизация». Например, в простейшем случае (когда конечная точка туннеля также является узлом назначения) политика маршрутизации может выбирать маршруты в соответствии с локальным IP-адресом. Например:
На внутреннем хосте создайте новую таблицу маршрутизации, которая маршрутизирует все через wg0 (это можно сделать с помощью
ip -4 route add default dev wg0 table 4242 ip -6 route add default dev wg0 table 4242Создайте правило политики, выбрав эту таблицу для всех ответов, которые будут отправлены с IP-адреса wg0:
ip -4 rule add pref 500 from x.x.x.2 lookup 4242 ip -6 rule add pref 500 from fdXX:XX::2 lookup 4242
Если у вас есть несколько хостов с отдельным шлюзом, выступающим в качестве конечной точки WireGuard, шлюз может использовать метки пакетов (опять же полагаясь на conntrack для корреляции входящих и исходящих пакетов) для выбора одной из нескольких таблиц маршрутизации — пакеты, поступающие через WireGuard, вызывают изменение потока. отмечены в conntrack, а затем пакеты, поступающие из локальной сети, маршрутизируются обратно через WireGuard благодаря этой отметке.
(Аналогичные функции доступны в шлюзах на базе BSD, использующих pf; насколько я слышал, реализовать такую маршрутизацию с pf даже проще, чем с Linux.)