форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Сообщение от Dragon_Stas on 13-Янв-04, 17:04  (MSK)
Вот тут находится рисунок сетей 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
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

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

	2. "Практико-Теоритический вопрос о NAT. (у всех так или только ..."
	Сообщение от Dragon_Stas on 15-Янв-04, 01:38  (MSK)
	Просто я думал ,что может я где-нибудь накасячил :) БОЛЬШОЕ СПАСИБО за предложение в помощи с настройкой IPFW,  но я надеюсь, что сам справлюсь :), ведь, как я понимаю, там просто нужно запретить для сети, находящийся за NAT, вхождение пакетов с флагом SYN, а также все пакеты на порты ниже 1024. Но, если у меня не получится, то обязательно обращусь к Вам за советом. P.S Тут нашел в мане natd опцию -d, все вроде ОК, но только нельзя соедениться ни с одним портом на шлюзе :(. Но возможно мне поможет выйти из этой ситуации опция riderect . Буду на днях проверять :). P.S.S Если у Вас есть какие-нибудь предложения как с помощью опций natd увеличить безопасность сети находяшиюся за NAT то плиз расскажите :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Сообщение от Cheeto_McMourrell on 15-Янв-04, 05:10  (MSK)
Хотелось бы поблагодарить вас за достаточно внятное описание задачи. >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 Небольшая неувязочка
	Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

	8. "Написал задание :) Все знающие ALL  посмотрите плиз"
	Сообщение от Dragon_Stas on 19-Янв-04, 20:39  (MSK)
	Уважаемое 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).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Скоро"
	Сообщение от rex_3 on 19-Янв-04, 22:13  (MSK)
	Посижу вечерок попробую набросать конфы. Один вопрос: я понимаю 192.168.2.0/24 и 192.168.0.0/24 , но зачем 29 и 30? В принципе всё понятно, придётся запускать 2 ната (1 на выход с обоих сетей, 2-ой редиректом с 80), а внешний выход закрыть файерволом. И второй вопрос адрес 192.168.1.0, должен светиться для всех (можно ведь вообще зашифроваться) или только для избранных, кто знает о внешнем входе на http сервер?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Скоро"
	Сообщение от Dragon_Stas on 19-Янв-04, 23:29  (MSK)
	>Посижу вечерок попробую набросать конфы. >Один вопрос: я понимаю 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 будут разные.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "информация к размышлению"
	Сообщение от Dragon_Stas on 20-Янв-04, 00:14  (MSK)
	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. то есть редирект со стороны # интернета срабатывает
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "АУУУ"
	Сообщение от Dragon_Stas on 21-Янв-04, 22:51  (MSK)
	тема!
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "natd -d на 100% защитит или нет ?"
	Сообщение от Dragon_Stas on 23-Янв-04, 21:28  (MSK)
	Вот вопрос возник! natd с опцией -d на 100% процентов защитит сеть которая находится за этим NAT-ом от соединений из вне или всетаки можно как нибудь инициировать соединение с сеткой находящиейся за natd -d. ? P.S Просто хочется буть увереным в правиле: /sbin/ipfw add 10 divert natd all from any to any via xl0 совместно с опцией: deny incoming yes
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "natd -d на 100% защитит или нет ?"
	Сообщение от Dragon_Stas on 27-Янв-04, 23:28  (MSK)
	Уважаемые ГУРУ ! ну скажите свое веское слово
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

	16. "natd -d на 100% защитит или нет ?"
	Сообщение от lh on 28-Янв-04, 09:59  (MSK)
	>Вроде где-то выше было написано что для уверенности есть фаерволл, который должен >запрещать маршрутизацию всяких пакетов с фейковыми адресами снаружи внешнего интерфейса. Угу... В rfc2827 это написано, например... Да только кто их читает.. :(
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "natd -d на 100% защитит или нет ?"
	Сообщение от Dragon_Stas on 28-Янв-04, 15:48  (MSK)
	>Вроде где-то выше было написано что для уверенности есть фаерволл, который должен >запрещать маршрутизацию всяких пакетов с фейковыми адресами снаружи внешнего интерфейса. Ну так ведь сеть провайдера не есть фейковая сеть (просто я ее обозначил как 192.168.1.0/32) IP спуфинг естственно будет закрыт правилом типа ipfw add <номер> deny all from <приватные_сети> to <мой_интернет_IP> in via <интерфейс_смотрящий_в_инет> P.S спасибо за подзатыльник про rfc2827 вечерком сяду возьму словарь и начну переводить
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "natd -d на 100% защитит или нет ?"
	Сообщение от Dragon_Stas on 28-Янв-04, 18:01  (MSK)
	Народ ну кто нить мне даст 100% достоверный ответ про natd -d ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

21. "Практико-Теоритический вопрос о NAT. (у всех так или только ..."
Сообщение от vrspider on 11-Мрт-04, 16:10  (MSK)
Ну всё зделал так же , но не проходит  пинг и всё и никакого наттинга нет , вопрос , возможно что 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 -изнутри ?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.