Разрешить только исходящий трафик IPSEC на порт (используя IPTABLE?)
Проблема:
У меня ситуация, когда сервер IPSEC и целевой сервер (скажем, http-сервер) оказываются на одной машине, и мне нужно разрешить ТОЛЬКО трафику, проходящему через сервер IPSEC, иметь доступ к порту, на котором запущено мое приложение, и блокировать всех остальных в этом порту.
Больше деталей:
- Настройка выглядит следующим образом: (Хост A) <---- IPSEC VPN TUNNEL -> (Хост B (Linux), где приложение работает на порту XXXX).
- Никакого дополнительного шлюза IPSEC или межсетевого экрана не задействовано.
- Хост B имеет публичный IP-адрес (статический).
- Хост А инициирует соединение, и VPN-туннель устанавливается.
- Когда я регистрировал трафик, поступающий на порт XXXX после дешифрования ipsec, он выглядел как любой обычный пакет, и для src было установлено значение "IP-адрес хоста А", а для dst было установлено значение "IP-адрес хоста B", и поскольку пакет предназначен для хоста B, Правила POSTROUTING не будут применяться к нему после обработки ipsec.
На данный момент я добавил правило в iptables для принятия всего трафика через порт XXXX:
-A ВХОД -p tcp --dport XXXX -s 0.0.0.0/0 -j ПРИНЯТЬ
В то время как это заставляет вещи двигаться, порт XXXX открыт для всего мира, и это опасно.
Любая идея, как я могу работать с помощью конфигурации ipsec или правил iptables или любым другим способом для достижения цели, когда ТОЛЬКО трафик, исходящий из конечной точки ipsec, имеет доступ к XXXX?
Несколько мыслей в моей голове:
- Можно ли идентифицировать пакеты TCP, которые покидают конечную точку IPSEC и имеют правило в iptables, позволяющее только этим пакетам достигать порта XXXX?
- Можно ли иметь некоторые настройки iptable /ipsec, чтобы пропустить правила INPUT после обработки ipsec? таким образом, у меня может быть правило iptable для отбрасывания всех пакетов на порт XXXX, и пакеты, выходящие из ipsec, не будут затронуты.
- Может быть, создать виртуальный интерфейс на хосте B и направить трафик IPSEC через него и разрешить доступ к порту XXXX только через этот виртуальный интерфейс?
- В худшем случае у меня получится, что сервер ipsec (хост B) и сервер приложений (хост C) будут работать на разных компьютерах и разрешить трафик на порт XXXX на хосте C ТОЛЬКО с хоста B.
Я попробовал решение @ С iptables пакеты совпадений, полученные через туннель IPSEC, но это не сработало, так как я полагаю, что упомянутая политика применяется к пакетам, достигающим IPSEC, а не к пакету, который покидает IPSEC?
Дайте мне знать, если я пропустил какие-либо детали или любую дополнительную информацию, которая вам нужна. Любая помощь / предложения будут с благодарностью.
2 ответа
Спасибо за предложения. Оказалось, что это связано с тем, как IPSEC VPN работает на устройствах iOS (apple).
На устройствах iOS при включении ipsec VPN правило автоматически добавляется в таблицу маршрутизации для отправки трафика сервера / однорангового узла IPSEC непосредственно на шлюз, чтобы избежать зацикливания (повторное шифрование пакета), а остальная часть трафика отправляется сначала в туннель ipsec для получить зашифрованный и затем на сервер ipsec.
И в моем случае сервер IPSEC и целевой сервер (на который направлен трафик) оказываются одной и той же машиной (разрешается на один и тот же IP-адрес), поэтому, когда трафик отправляется на целевой сервер (порт XXXX), а не шифруется в туннеле IPSEC он был отправлен напрямую на сервер из-за особого правила без инкапсуляции в пакет ipsec. Поэтому, когда эти пакеты поступали на сервер, он не распознавался как пакеты ipsec, и это было проблемой.
Поскольку я не мог избежать того, что iOS-клиент отправляет трафик на порт XXXX (хотя и без инкапсуляции ipsec), мне пришлось искать способ, позволяющий только этому устройству иметь доступ к порту XXXX, а не всему миру. Итак, в итоге я создал собственный скрипт обновления ipsec на сервере ipsec, который динамически добавляет правило цепочки INPUT, чтобы разрешить трафик с IP-адреса установленного клиента на порт XXXX при подключении vpn и удалить правило при отключении vpn. Таким образом, только клиенты, подключенные к VPN, будут иметь доступ к порту XXXX.
IPSec обеспечивает защиту любого трафика, поступающего из подсетей на другом конце. Например, если вы используете openswan, то в подсетях прав (и иногда в левых подсетях) будет указываться любая связь, исходящая с другого конца, так что вы можете разрешить только трафик, поступающий из этих подсетей.
Если у вас есть клиенты RW, подключающиеся с разных IP-адресов, существуют плагины для ppp, такие как сценарии ip-up и ip-down, которые вы можете использовать, чтобы разрешить или запретить определенные порты для определенных IP-адресов.
Необходимо подключить политику IPsec либо к сокету (сложно), либо глобально.
Здесь IPsec дублирует часть логики брандмауэра, поскольку позволяет сопоставлять пакеты с IP-адресами и портами и искать требуемую политику IPsec.
Для обычных настроек VPN политики обычно применяются ко "всему трафику из этой подсети в эту подсеть", но они могут быть более мелкими, например
require all traffic to my IP address port 80 from that other IP address to be encrypted
deny all other traffic to my IP address port 80
Можно иметь политику без ассоциации безопасности, и в этом случае ядро будет обращаться к демону IKE, чтобы получить ее.
Если клиент меняет IP-адрес, вы можете сгенерировать политики "require" из демона IKE и настроить статическую политику "deny" только с приоритетом ниже, чем сгенерированные правила.