URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 39300
[ Назад ]

Исходное сообщение
"Практико-Теоритический вопрос о NAT. (у всех так или только у меня)"

Отправлено Dragon_Stas , 13-Янв-04 17:04 
Вот тут находится рисунок сетей http://s-krylov.hotbox.ru/NetQuest-1.4.png

Суть темы следующая:
есть две сети сеть1=192.168.2.0/29 и сеть 192.168.0.0/30.
есть шлюз который соединяет эти две сети.
на этом шлюзе запушен демон natd, который натит все адреса из сети 192.168.2.0/29 в адрес 192.168.0.1.
теперь делаем следующие:
с IP 192.168.2.2 пингуем IP 192.168.0.2. На компютере 192.168.0.2 запускаем снифер и видем, что на компьютер 192.168.0.2 приходят пакеты от машины 192.168.0.1. Вроде все верно NAT работает как надо !
Затем делаем с точностью да на оборот, с компютера 192.168.0.2 начинаем пинговать 192.168.2.2. Компьютер 192.168.2.2. пингуется.
ВОПРОС: почему так происходит ведь сеть 2.168.2.0/29 спрятана за NAT-ом?.
Как от этого избавиться ? то есть получить как бы одну сторонию связь (сеть 192.168.2.0/29 может ходить через NAT куда угодно, а в нее не кто попасть попасть не должен)
P.S просто я всегда думал, что если сеть находится за NAT-ом то в нее попасть НЕВОЗМОЖНО :( , а практика показала, что можно.

Вот вырезки из конфигов GATEWAY-я (может я где нить, что-то не то врубил :) ).
rc.conf
-----------------------------
defaultrouter="192.168.xx.xx"
hostname="test-pc.ns.zel.ru"

ifconfig_rl0="inet 192.168.2.1  netmask 255.255.255.248"
ifconfig_rl1="inet 192.168.0.1  netmask 255.255.255.252"

gateway_enable="YES"
inetd_enable="YES"
sshd_enable="YES"
firewall_enable="YES"
natd_enable="YES"

firewall_script="/etc/firewall.conf"
firewall_logging="YES"
natd_interface="rl1"
natd_flags="-f /etc/natd.conf"
-----------------------------------

firewall.conf

/sbin/ipfw -f flush

/sbin/ipfw add 10 divert natd all from any to any  via rl1
/sbin/ipfw add 20 allow all from any to any via lo0
/sbin/ipfw add 60000 allow log all from any to any

-----------------------------------

natd.conf

interface rl0
use_sockets yes
same_ports yes


Содержание

Сообщения в этом обсуждении
"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено rex_3 , 14-Янв-04 10:15 
Естественно так у всех, просто кто-то этого не замечает :)
А ситуация в том что у тебя на обоих машинах прописан шлюз (если закроеш его на 1, то и не будет видет она другой сети) и они друг друга спокойно видят в обход ната (отключи нат и всё сразу станет понятно, так как ничего не изменится).

А закрывается всё это дело с помощью ipfw (если с правилами не разберёшся, могу помочь).


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено Dragon_Stas , 15-Янв-04 01:38 
Просто я думал ,что может я где-нибудь накасячил :)
БОЛЬШОЕ СПАСИБО за предложение в помощи с настройкой IPFW,  но я надеюсь, что сам справлюсь :), ведь, как я понимаю, там просто нужно запретить для сети, находящийся за NAT, вхождение пакетов с флагом SYN, а также все пакеты на порты ниже 1024. Но, если у меня не получится, то обязательно обращусь к Вам за советом.

P.S Тут нашел в мане natd опцию -d, все вроде ОК, но только нельзя соедениться ни с одним портом на шлюзе :(. Но возможно мне поможет выйти из этой ситуации опция riderect . Буду на днях проверять :).

P.S.S Если у Вас есть какие-нибудь предложения как с помощью опций natd увеличить безопасность сети находяшиюся за NAT то плиз расскажите :)


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено Cheeto_McMourrell , 15-Янв-04 05:10 
Хотелось бы поблагодарить вас за достаточно внятное описание задачи.
>P.S просто я всегда думал, что если сеть находится за NAT-ом то
>в нее попасть НЕВОЗМОЖНО :( , а практика показала, что можно.
Собственно НАТ это не гарантирует. Более того, это совершенно разумно. Это собственно следует из названия технологии, она делает только то, как называется. Ее придумали для экономии IP адресов (или более эффективного использования) и ни в коем случае не для защиты. Более того, его использование в ряде случаев приносит дополнительные проблемы. Некая "защита" является лишь побочным эффектом, основанным на использовании "левых" немаршрутизируемых адресов. Что и как было задумано вы можете почитать в соответствующем документе RFC (http://www.ietf.org/rfc/rfc1631.txt?number=1631). То поведение, которое вы желаете видеть, реализуется в качестве дополнительной функции, которая своим существованием обязана лишь простоте для ее реализации именно здесь. Если бы оно было железно вбито в natd, то это бы значительно сократило гибкость и сферу использования НАТ. Часто именно нужно, чтобы сеть за натом была доступна. К этому же случаю относится тот пример, который вы привели в цитате ниже.

>P.S Тут нашел в мане natd опцию -d, все вроде ОК, но только нельзя >соедениться ни с одним портом на шлюзе :(. Но возможно мне поможет выйти >из этой ситуации опция riderect . Буду на днях проверять :).
Вот эта опция вероятно и организует то, что вы хотели. И именно в том у нее минус, что соединиться со шлюзом будет нельзя, т.к. у приходящих пакетов нет записи в таблице трансляции. Это применимо только тогда, когда данная машина (и все находящееся за NAT) является ИСКЛЮЧИТЕЛЬНО клиентом, т.е. не предоставляет свои ресурсы внешней сети, не принимает соединения извне. В этом случае к схеме эффективно приделывается костыль в виде опции deny_incoming, для реализации задачи посредством информации, содержащейся в таблице трансляции.

Мой совет - не занимайтесь ерундой, ваше желание использовать redirect основано именно на ложном стереотипе, что НАТ защищает сеть. Не надо на него возлагать таких задач, он для этого не предназначен. Если вы хотите ограничить доступ извне (из сети 192.168.0.0/30) - используйте firewall, он именно для этого и предназначен.

>БОЛЬШОЕ СПАСИБО за предложение в помощи с настройкой IPFW,  но я
>надеюсь, что сам справлюсь :), ведь, как я понимаю, там просто нужно
>запретить для сети, находящийся за NAT, вхождение пакетов с флагом SYN,
Не стоит так трактовать задачу. Если вам уж так дороги флаги, используйте их только для того чтобы разрешать, а не запрещать, и то с оглядкой. Тем более в примере с ICMP ping, который вы привели, таких флагов нет, ровно как и во многих других случаях.
>ниже 1024.
Ровно как и это магическое число

>natd_interface="rl1"
>...
>natd.conf
>interface rl0
Небольшая неувязочка


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено rex_3 , 15-Янв-04 10:32 
Говорю сразу, что с помощью отбрасывания syn пакетов вход в свою сетку не закрыть, как и перекрывая порты.
Использование redirect лишено смысла, так как насколько я понял задачей является просто транслирование одной сети в другую.

"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено Dragon_Stas , 15-Янв-04 14:58 
>Говорю сразу, что с помощью отбрасывания syn пакетов вход в свою сетку
>не закрыть, как и перекрывая порты.
>Использование redirect лишено смысла, так как насколько я понял задачей является просто
>транслирование одной сети в другую.
Задача не совсем простая, но ИМХО стандартная. :)
Сегодня подготовлю полное описание поставленной передомной задачи и выложу в этом топике.
Мне будет очень интересно (думаю не только мне) услышать Ваше мнение по практической реализации этой задачи.

P.S Пошел готовить описание задачи и список требований :)


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено Dragon_Stas , 15-Янв-04 14:51 
> Хотелось бы поблагодарить вас за достаточно внятное описание задачи.
СПАСИБО! Я очень старался :)
>Мой совет - не занимайтесь ерундой, ваше желание использовать redirect
>основано именно на ложном стереотипе, что НАТ защищает сеть.
Вы правы это все произошло из-за неправильного понимания мной реализации NAT.
>Не стоит так трактовать задачу. Если вам уж так дороги флаги,
>используйте их только для того чтобы разрешать, а не запрещать, и то с >оглядкой. Тем более в примере с ICMP ping, который вы привели, таких
>флагов нет, ровно как и во многих других случаях.
>>ниже 1024.
>Ровно как и это магическое число
Тут Вы тоже правы, с флагами можно только в протоколе TCP колдовать, а вот с UDP и ICMP придется, придумывать чтонибудь иное.

>>natd_interface="rl1"
>>...
>>natd.conf
>>interface rl0
>Небольшая неувязочка
Угу, простите за опечатку :)


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено Dragon_Stas , 15-Янв-04 15:04 
Я пошел готовить описание поставленной пердо мной задачи и списока требований.
Надеюсь в дальнейшем на Вашу (ALL) конструктивную помощь в решении этой задачи.

"Написал задание :) Все знающие ALL  посмотрите плиз"
Отправлено Dragon_Stas , 19-Янв-04 20:39 
Уважаемое ALL!
Если Вам не трудно поделитесь плиз опытом и знаниями, как лучше организовать следующую задачу.
Общий рисунок на который я далее буду ссылаться находиться по адресу http://s-krylov.hotbox.ru/netQ3.gif

B.S Хочется услышать Ваше мнение как это лучше организовать и рекомендации о том как максимально обеспечить безопасность сети LAN.

ДАНО:
Есть три сети LAN=192.168.2.0/29, DMZ=192.168.0.0/30, INTERNET=192.168.1.0/24 (я его так условно обозначил).
Есть шлюз под управлением ОС FreeBSD 4.9, который имеет три интерфейса.
rl0 - смотрит в сторону LAN и имеет IP=192.168.2.1
xl0 - смотрит в сторону INTERNET и имеет один выделенный интернетовский адрес IP=192.168.1.80
rl1 - смотрит в сторону DMZ и имеет IP=192.168.0.1
В DMZ стоит компьютер 192.168.0.2 (dmz-server).
В локальной сети LAN серверов нет, зато есть клиенты типа 192.168.2.2.

ЗАДАНИЕ:
1) Надо обеспечить для сети LAN взаимодействие с сервисами сети INTERNET, а также взаимодействие с сервисами сети DMZ,  но чтоб трафик LAN->DMZ не выходил в сеть INTERNET используемые протоколы TCP/UDP/ICMP. (на рисунке это обозначено желтыми стрелками)
2) Так, как имеется всего один выделенный IP адрес и существует необходимость выставить в сеть INTERNET некоторые сервисы (SMTP, POP3, HTTP, SSH, e.t.c) то все запросы (выборочные TCP,UDP)пришедшие на внешний интерфейс 192.168.1.80 должны перенаправляться в DMZ на сервер 192.168.2.2. (на рисунке обозначено синими стрелками)
3) Компьютеры, находящиеся в сети DMZ так же должны взаимодействовать по протоколам TCP/UDP/ICMP  c сервисами расположенными в сети INTERNET. (на рисунке обозначено зеленными стрелками)
4) При выполнении пунктов 1,2,3 должно обязательно выполняться следующие требование:
К компьютерам сети LAN из сетей INTERNET и DMZ обращение по любым протоколам и по любым портам должно быть запрещено. (т.е максимально защитить сеть LAN от проникновения из сетей INTERNET и DMZ).

КАК Я ПЫТАЛСЯ (надеялся) РЕШИТЬ ЭТУ ЗАДАЧУ:
На интерфейс, смотрящий в Интернет я повесил демон natd c опцией -deny incoming это мне позволило защитить сеть LAN и DMZ от соединений из сети INTERNET. Далее я настроил редирект для нужных портов c интерфейса xl0=192.168.1.80 на DMZ-SERVER=192.168.2.2.. Вроде все ОК, сеть LAN взаимодействует с сетью INTERNET, работает перенаправление в DMZ с интерфейса xl0 и выполняется часть условия #4 (обеспечена защита от сети INTERNET).

Осталось обеспечить только защиту сети LAN от сети DMZ. Вот как это красиво сделать чтоб все работало, как написано выше, у меня не получается :(. Так как демон natd при задание в ipfw правила отличного от
/sbin/ipfw add divert 8669 all from any to any via (нужный_интерфейс)
опцию -deny incoming выполняет криво (ICMP все равно проходит в сеть находящуюся за NAT).


"Скоро"
Отправлено rex_3 , 19-Янв-04 22:13 
Посижу вечерок попробую набросать конфы.
Один вопрос: я понимаю 192.168.2.0/24 и 192.168.0.0/24 , но зачем 29 и 30?

В принципе всё понятно, придётся запускать 2 ната (1 на выход с обоих сетей, 2-ой редиректом с 80), а внешний выход закрыть файерволом.

И второй вопрос адрес 192.168.1.0, должен светиться для всех (можно ведь вообще зашифроваться) или только для избранных, кто знает о внешнем входе на http сервер?



"Скоро"
Отправлено Dragon_Stas , 19-Янв-04 23:29 
>Посижу вечерок попробую набросать конфы.
>Один вопрос: я понимаю 192.168.2.0/24 и 192.168.0.0/24 , но зачем 29 и
>30?
просто так захотелось :)
>
>В принципе всё понятно, придётся запускать 2 ната (1 на выход с
>обоих сетей, 2-ой редиректом с 80), а внешний выход закрыть файерволом.
>
Да, нужно будет как минимум два natd, но просто как мне показывает практика работы с natd, ИМХО организовать приведенную мной схему с помошью  трех сетевых интерфейсов сложновато. :)
>
>И второй вопрос адрес 192.168.1.0, должен светиться для всех (можно ведь вообще
>зашифроваться) или только для избранных, кто знает о внешнем входе на
>http сервер?
Я не очеь понял Ваш вопрос и решил еще раз пояснить задачу.

Смысл в том, что сеть 192.168.2.0 должна быть защищена как со стороны интернета (192.168.1.0) так и со сотороы DMZ (192.168.0.0). Соединения с ней (192.168.2.0) нужно запретить на 100%.
В DMZ  будет один сервер с кучей сервисов которые должны буть доступны как из сети INTERNET, так и из сети LAN. Сервисы на сервере в DMZ будут разные.


"информация к размышлению"
Отправлено Dragon_Stas , 20-Янв-04 00:14 
natd.conf
------------
interface xl0
port 8690
redirect_port tcp 192.168.0.2:25 25
deny_incoming yes
use_sockets yes
same_ports yes

firewall.conf
---------------
/sbin/ipfw add 30 divert 8690 log all from 192.168.2.0/29 to any out via xl0
/sbin/ipfw add 40 divert 8690 log all from 192.168.0.0/30 to any out via xl0
/sbin/ipfw add 50 divert 8690 log all from any to 192.168.1.80 in via xl0

/sbin/ipfw add 10000 allow all from any to any via lo0
/sbin/ipfw add 60000 allow log all from any to any

работает как то странно :(
заметки как у меня все работает если в диверте определить сети не как any! :)
-----------------------------------------------------------
###########################################################################
# ICMP, TCP, UDP LAN->INTERNET ( OK ). natd работает
# ICMP, TCP, UDP DMZ->INTERNET ( OK ). natd работает
# c 192.168.1.81 ping 192.168.2.2 ответ приходит от 192.168.1.80
# также на интерфейсе rl0 видны пакеты от 192.168.1.81. (вывод опция в natd -d
# не срабатывает).
#
# c 192.168.1.81 telnet 192.168.2.2:порт_для_тестирования
# соединение не устанавливается, но на интерфейсе rl0
# видны пакеты от 192.168.1.81. (вывод: опция в natd -d
# не срабатывает или срабатывает но как то особено).
#
# c 192.168.2.2 telnet 192.168.1.80:порт_который_указан_в_опции_redirect_для_natd
# соединение не устанавливается. На интерфейсах rl1 и xl0 чисто. А это
# почему так происходит ?

# c 192.168.1.81 telnet 192.168.1.80:порт_который_указан_в_опции_redirect_для_natd
# соединение устанавливается с машиной 192.168.0.2. то есть редирект со стороны
# интернета срабатывает


"АУУУ"
Отправлено Dragon_Stas , 21-Янв-04 22:51 
тема!

"natd -d на 100% защитит или нет ?"
Отправлено Dragon_Stas , 23-Янв-04 21:28 
Вот вопрос возник!
natd с опцией -d на 100% процентов защитит сеть которая находится за этим NAT-ом от соединений из вне или всетаки можно как нибудь инициировать соединение с сеткой находящиейся за natd -d. ?

P.S Просто хочется буть увереным в правиле:

/sbin/ipfw add 10 divert natd all from any to any via xl0

совместно с опцией: deny incoming yes


"natd -d на 100% защитит или нет ?"
Отправлено Dragon_Stas , 27-Янв-04 23:28 
Уважаемые ГУРУ !
ну скажите свое веское слово



"natd -d на 100% защитит или нет ?"
Отправлено A Clockwork Orange , 28-Янв-04 09:51 
Вроде где-то выше было написано что для уверенности есть фаерволл, который должен запрещать маршрутизацию всяких пакетов с фейковыми адресами снаружи внешнего интерфейса.

"natd -d на 100% защитит или нет ?"
Отправлено lh , 28-Янв-04 09:59 
>Вроде где-то выше было написано что для уверенности есть фаерволл, который должен
>запрещать маршрутизацию всяких пакетов с фейковыми адресами снаружи внешнего интерфейса.

Угу... В rfc2827 это написано, например... Да только кто их читает.. :(


"natd -d на 100% защитит или нет ?"
Отправлено Dragon_Stas , 28-Янв-04 15:48 
>Вроде где-то выше было написано что для уверенности есть фаерволл, который должен
>запрещать маршрутизацию всяких пакетов с фейковыми адресами снаружи внешнего интерфейса.

Ну так ведь сеть провайдера не есть фейковая сеть (просто я ее обозначил как 192.168.1.0/32)
IP спуфинг естственно будет закрыт правилом типа
ipfw add <номер> deny all from <приватные_сети> to <мой_интернет_IP> in via <интерфейс_смотрящий_в_инет>

P.S спасибо за подзатыльник про rfc2827 вечерком сяду возьму словарь и начну переводить


"natd -d на 100% защитит или нет ?"
Отправлено Dragon_Stas , 28-Янв-04 18:01 
Народ ну кто нить мне даст 100% достоверный ответ про natd -d ?

"natd -d на 100% защитит или нет ?"
Отправлено A Clockwork Orange , 28-Янв-04 18:05 
Надо стараться делать как сразу надо.
100% защиту тебе ничто не даст.
Для этого надо комплекс мер, от топологии, до программных и аппаратных средств.

"natd -d на 100% защитит или нет ?"
Отправлено Dragon_Stas , 28-Янв-04 21:39 
>Надо стараться делать как сразу надо.
>100% защиту тебе ничто не даст.
ну это ясно :)
А я имею виду защиту от иницилизации соединений со стороны сети 192.168.1.0/24 (то есть со стороны сети провайдера). То есть мне надо удостовериться, что natd с опцией -d будет работать как работает "прокси".
То есть соединение с внешним миром происходит только если оно инициированно со стороны локальной сети. Ну народ, может я как то плохо изесняю свои мысли ???? может кто нить дать подтвердить или опровергнуть про то, что natd c опцией -d работает как "прокси" ???


>Для этого надо комплекс мер, от топологии, до программных и аппаратных средств.
>


"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Отправлено vrspider , 11-Мрт-04 16:10 
Ну всё зделал так же , но не проходит  пинг и всё и никакого наттинга нет ,
вопрос , возможно что
ipfw deny icmp from any to my.ip.address in via my.inet.interface
ipfw deny tcp  from any to my.ip.address 21,22,23,3128,3129,139 in via  my.inet.interface
тормозит или блокирует всю єту натину ?
ечли может то как зделать чтобы никто не убил и всё включая
httpd , sendmail -снаружи
и sshd , ftpd , squid -изнутри ?