LINUX.ORG.RU
ФорумAdmin

Вопрос по iptables DNAT и DMZ


0

0

Смотрел руководство iptables 1.1.19, книгу "оптимизация и защита линукс сервера" и ещё несколько источников.

Везде пробрасывать порты до сервера, стоящего в DMZ предлагают приблизительно следующим образом:

(1) iptables -A PREROUTING -i $EXT_I -s $EXT_NET -d $EXT_IP -p tcp --dport 80 -j DNAT --to-destination $DMZ_HTTP_IP

(2) iptables -A FORWARD -i $EXT_I -s $EXT_NET -o $DMZ_I -d $DMZ_HTTP_IP -p tcp --dport 80 -m state --state NEW -j ACCEPT

iptables -A FORWARD -i $EXT_I -s $EXT_NET -o $DMZ_I -d $DMZ_HTTP_IP -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i $DMZ_I -s $DMZ_HTTP_IP -o $EXT_I -d $EXT_NET -m state --state ESTABLISHED,RELATED -j ACCEPT

где:
EXT_I -внешний интерфейс
EXT_NET - адреса внешней сети (если интернет, то этот параметр можно опустить)
EXT_IP - IP маршрутизатора на внешнем интерфейсе
DMZ_I - интерфейс, смотрящий в DMZ.
DMZ_HTTP_IP - адрес сервера в DMZ зоне

Всё это работает прекрасно (если я конечно нигде не ошибся).

Но с такой схемой проброса возможна (или невозможна?) примерно такая "атака", позволяющая выявить наличие DMZ.

Например:
EXT_I=eth0
EXT_NET=10.0.0.0/8
EXT_IP=10.0.0.1

DMZ_I=eth1
DMZ_NET=192.168.0.0/24
DMZ_HTTP_IP=192.168.0.10

Атакующий IP=10.0.0.20

Тогда для нормального доступа к DMZ_HTTP_IP должен прийти пакет с:
-s=10.0.0.20 -d=10.0.0.1 -p tcp --dport=80
пакет пройдёт через правило (1) и потом через правило (2).

Но ведь доступ получить можно и так:
На хосте 10.0.0.20 прописываем:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.1 dev eth0(к примеру)
Тогда придёт такой пакет (-d адрес в принципе можно угадать перебором):
-s=10.0.0.20 -d 192.168.0.10 -p tcp --dport=80

Пакет не пройдёт через правило (1) т. к. -d не совпадает с EXT_IP но благополучно пройдёт через правило (2) и тем самым выдаст информацию о наличии DMZ.

Я пробовал проводить такой эксперимент на простенькой одноранговой сети (на интерфейсе EXT_I), всё замечательно получается.

В некоторых источниках вместо правила (2) предлагают использовать совсем простое правило без проверки --dport и state.

Для исправления ситуации как я понимаю можно использовать например такое доп. правило, но только до принятия решения о маршрутизации и до раскрытия NAT пакета:
iptables -t mangle -A PREROUTING -i $EXT_I -s $EXT_NET -d $EXT_IP -p tcp --dport 80 -j MARK --set-mark 1
А правило (2) изменить примерно на такое:
iptables -A FORWARD -m mark --mark 1 -j ACCEPT

Что вы об этом всём думаете?
Может можно как-нибудь более изящно решить эту проблему?


Разреши на внешнем интерфейсе входящие обращения только к "-d 10.0.0.1" а всё остальное дропай..

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

т. е.
iptables -t nat -A PREROUTING -i $EXT_I -d ! $EXT_IP -p tcp --dport 80 -m state --state NEW -j DROP

таким образом получается, что в таблице nat цепочке PREROUTING фильтровать надо.

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

Неужели это как раз такой исключительный случай? Это же надо по хорошему делать везде, где делается DNAT!

Неужели никто раеьше с этим не сталкивался (не обращал внимания) ?

ksicom
() автор топика

>Но с такой схемой проброса возможна (или невозможна?) примерно такая "атака", позволяющая выявить наличие DMZ.

Извините, DMZ у вас для того чтобы о нем никто не знал?

Я думал наличие DMZ для защиты корпоративной локалки от публично доступных серверов, которые могут быть скомпроментированны.

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

>Я думал наличие DMZ для защиты корпоративной локалки от публично доступных серверов, которые могут быть скомпроментированны.


Согласен, но всё-таки лучше чтобы об устройстве сети (в том числе и сегменте DMZ) потенциальный взломщик знал как можно меньше. И уж точно чтобы не мог обратиться к ней по внутреннему IP напрямую.


А что в FORWARD DROPать? Туда пакеты после правильного DNAT и по описанной мною схеме приходят "одинаковые". По какому критерию их убивать?


Мне видятся 2 варианта:
1 - DROP в nat/PREROUTING, но это идеологически не совсем правильно.
2 - в mangle/PREROUTING правильные(или неправильные) пакеты помечать и ACCEPT/DROP их в цепочке FORWARD.
Но как-то это всё сложно получается :) и некрасиво.

ksicom
() автор топика
Ответ на: комментарий от sdio

>Может в FORWARD?

Да, конечно, в FORWARD.. Просто, обычно, делаю некие свои обобщённые правила, которые затем и подключаются, по мере надобности, к различныи интерфейсам и цепочкам фильтрации.. А, в данном случае, да..

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

Ваша проблема надумана.
Какая разница как клиент пришел в DMZ прямо или по ДНАТ?
Важно к каким портам у него есть доступ и куда он может пойти из DMZ если скомпроментирует сервер.

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

Технически разницы никакой.

Меня смущает, что клиент может получить (пусть и совсем малую) информацию об устройстве сети.

DMZ конечно отдаётся на растерзание. Но всё равно её надо защищать хоть как-то. И мне кажется если потенциальный взломщик не будет знать о наличии DMZ, это лучше чем если он о ней будет знать.

И ещё меня смущает, что во всех просмотренных мною документах умалчивается об этой "особенности".

Ну и как пример практического применения данной особенности:
Многие используют DNAT просто для проброса внутрь своей сети портов. (без всяких специально выделенных DMZ). Используя эту особенность провайдер может находить среди них тех, у кого NAT.

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

man iptables (модуль conntrack):
--ctstate state
... DNAT A virtual state, matching if the original destination differs from the reply source.

Т.е. в правило (2) (в FORWARD цепочке) нужно добавить "-m conntrack --ctstate DNAT".
Оно ?

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