Ключевые слова:nat, freebsd, (найти похожие документы)
From: Dragon from SWAMP <Stas_Dragon@aport2000.ru.>
Newsgroups: email
Date: Mon, 6 Dec 2004 14:31:37 +0000 (UTC)
Subject: Определение факта использования транслятора адресов (NAT)
Попадёт ли NAT в красную книгу SWAMP?
ПРИ ПРИСКАЗКА:
В самом начале эта маленькая статейка предназначалась для пользователей
студенческой сети SWAMP (жителем которой я являлся до недавнего времени)
вот поэтому я и не стал менять название статьи.
Сеть SWAMP создавалась за деньги самих студентов и на сегодняшний
момент насчитывает около 1000 компьютеров. В этой сети есть свои форум,
где студенты обмениваются опытом, общаются на разные темы, обсуждают
личные и общие проблемы, там же есть разделы для статей но, увы админы
SWAMP не дают мне поместить её на студенческом форуме в разделе
"статей" считая, что моя статья учит студентов плохому
(прятать NAT от админов).
Правы или не правы эти два студента, которые запрещают статью для
публикации на студенческом форуме решать не мне, но чтобы труд
нескольких моих ночей не пропадал, я решил "запостить" статью здесь.
Если эта стаья не подходит для OpenNET по каким-то критериям то прошу
её убить, а если все нормально то было-бы интересно услышать Ваши отзывы
о ней.
Попадёт ли NAT в красную книгу SWAMP?
Компьютеров с NAT-ом не стало меньше, просто в цвете последних дней
Слишком много умных админов стали сдуру гонять за ним.
И пришлось ему стать осторожным, чтоб его не нашли,
И вот теперь почти не возможно будет NAT админам найти.
Присказка:
Эта статейка для пользователей и начинающих админов, которые хотят
знать ответ на вопрос можно ли найти NAT, и про стандартные заблуждения
о технологии NAT, и о возможных граблях.
Всё, что ниже будет написано, является моей личной фантазией и моим
маленьким опытом работы с этим зверем по имени NAT. Сразу предупреждаю,
что опытные пользователи не найдут в этой статье что-либо нового так,
что прошу сильно не ругать.
И так начнем
Маленький ликбез:
Обычно NAT (Network Address Translator) используют, когда необходимо
частной сети типа (10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255,
192.168.0.0-192.168.255.255) обеспечить выход в Интернет. Простым языком
- если у вас есть небольшая сеть и вам надо предоставить этой сети
доступ к сети Интернет, а имеете только несколько реальных IP адресов,
то NAT это то, что вам нужно.
NAT работает просто: в зависимости от направления передачи заменяет
IP-адрес отправителя или получателя в передаваемом пакете IP на IP-адрес
из пула адресов и вносит запись в таблицу NAT, где фиксируется
соответствие IP-адресов. Затем NAT рассчитывает новую контрольную
последовательность для заголовка IP (IP-Header), и измененный пакет IP с
новым заголовком передается адресату. Получив пакет IP, система
сравнивает IP-адреса (получателя и/или отправителя) с записями в таблице
NAT, соответствующим образом из меняет их, после чего создает
контрольную последовательность для заголовка IP и передает измененный
пакет адресату.
Для тех кто хочет узнать больше про среду обитания NAT, то определение
NAT приведено в RFC 1631.
В реальности, когда решают проблему с предоставлением частной сети
доступа к ресурсам Интернет, то реализуют это дело следующим образом:
конфигурируют Default Gateway (шлюз), на него устанавливают демон,
который умеет делать NAT, затем заворачивают трафик на этот демон. Для
компьютеров с ОС Windows все гораздо прозрачней, но смысл везде один
Gateway+NAT.
Итак заблуждение начинающего админа:
Очень часто начинающие админы думают, что установив NAT они тем самым
убивают двух зайцев, первый - локальная сеть имеет доступ к Интернет
ресурсам, второй - проблему с безопасным доступом к их локальной сети
извне, предполагая, что NAT не позволит создать соединение с
компьютерами их локальной сети из глобальной сети Интернет.
Здесь я хочу предостеречь начинающих админов. NAT - это просто
преобразование IP адресов и ни какую функцию безопасности NAT не несет.
Для того чтоб обезопасить свою сеть от соединений извне, нужно применять
межсетевой экран и т.п.
Да, и помните, увеличивая безопасность вы где-то, уменьшаете
функциональность, как было написано на обложке одной книги
"Администрирование - это искусство равновесия"
Для яркости приведу пример из моего личного опыта: Я настраивал NAT
только на ОС FreeBSD. Вот по этому мой пример будет с участием этой
прекрасной ОС. Свой первый NAT я делал по примерам c сайта
https://www.opennet.ru.
Если настроить NAT как описано в стандартных примерах то всё будет
отлично работать, но почти любой желающий сможет попасть в вашу сеть
скрытую за NAT-ом, прописав в своем маршруте внешний IP вашего шлюза.
Избавиться от этой особенности NAT можно двумя способами:
1 - вый настроить межсетевой экран с запретом входящих соединений
2 - рой внимательно почитать про функциональные возможности демона natd.
У каждого способа есть свои побочные эффекты и области действия, по
этому лично я применил оба метода для того, чтобы хоть как-то
обезопасить свою локальную сеть от доступа извне.
И так об областях действий и побочных эффектах.
Ключевыми словами в способе (1) слова "запрет входящих соединений". Кто
более-менее знаком со стеком TCP/IP сразу сообразят почему я выделил
эти слова и будут правы, именно эти слова накладывают область действий и
заставляют вылезти побочным эффектам. И так открываю ларчик! Стандартный
межсетевой экран работает на сетевом и транспортном уровнях TCP/IP -
если говорить более понятным языком, то сетевой экран просматривает
только заголовки протоколов IP, TCP,UDP, ICMP - но только TCP обладает
флагами соединений (SYN, AСK, FIN). Поэтому способ (1) можно применить
только для пакетов TCP, а для того чтобы пакеты остальных протоколов не
попали в локальную сеть, их придется "зарубить" на межсетевом экране, но
если мы их "зарубим", то получаем побочные эффекты: отсутствие DNS,
ping, tracert и других полезностей. Узнав про эти побочные эффекты,
кто-то подумает что, без ping, tracert сеть может обойтись, но вот без
DNS никак, да, чуть не забыл если запретить входящие соединения для
TCP, то у вас еще активный FTP "зарубится".
Как поступить с DNS, и какие типы ICMP разрешать/запрещать это решать
админу, который в свою очередь должен опираться на сетевую топологию
доверенной ему сети, нужды пользователей и требуемый уровень
безопасности.
Второй способ - это изучение возможностей демона NAT. Поскольку я
использовал демон natd, то опишу одну интересную функцию этого демона.
Ниже вырезка из man natd:
-deny_incoming | -d
Do not pass incoming packets that have no entry in the inter-
nal translation table.
Переводить не буду надеюсь всё, и так ясно. Но и тут нас ждёт
грабля/побочный эффект при включении этой опции: невозможно соединиться
ни с каким портом, весящим на внешнем IP нашего шлюза, но в некоторых
случаях этот эффект можно обойти, для обхода данного эффекта советую
почитать про опцию redirect демона natd . При тестирование всего этого
констуктора были еще некоторые эффекты, но про них я писать не буду чтоб
не уходить от главной темы.
Ищем NAT.
Всё, что было написано выше это была присказка, нужная для того чтобы
обратить ваше внимание на процесс конфигурирование демона NAT и на
стандартные ошибки при его конфигурирование.
Перейдем к основной теме, а точнее поиск NAT в локальной сети.
Для начала нам нужно ответить на следующий вопрос:
Чем же отличается пакет сформированный с помощью NAT от стандартного
сетевого пакета?
Правильный ответ будет - Ничем!
Тогда какже некоторые умудряются найти NAT?
Ответ на этот вопрос прост - эти "некоторые" ищут не NAT, а побочные
эффекты использования технологии NAT.
Итак начнем разбор полетов.
Я решил выделить три области в которых можно найти артефакты, косвенно
указывающие на наличие NAT:
1 - в конфигурации демона NAT
2 - на сетевом/траспортном уровне
3 - на "уровне приложений".
Первая область.
У каждой настройки NAT есть свои особенности, зная эти особенности,
можно проверить компьютер на наличие NAT. Хороший пример такой
особенности конфигурирования демона был описан мной выше в заголовке
"заблуждение начинающего админа", когда по FAQ-у был сконфигурирован
демон natd, на компьютере пропускающим в сеть скрытую NAT-ом соединения
извне.
Вторая область.
Признаки NAT можно поискать в заголовках пакетов, но зная как должен
работать NAT, то артефактов в заголовках мы найти не должны . Однако
есть одно большое "НО".
На этом уровне артефакт может подложить кто-нибудь другой ,работающий в
связке с демоном NAT. Выше я обращал ваше внимание, что обычно NAT
работает в связке с GATEWAY. Вот он то и подкладывает артефакт, имя
этому артефакту TTL (Time To Live). Если вы внимательно читали Олифера,
то должны помнить, что у каждого пакета установлен TTL . Стандартное
значение TTL для ОС Windows равно 128, а для *NIX систем TTL равно
64. При прохождении пакета через любой шлюз (GATEWAY), шлюз уменьшает
TTL на единицу.
Вот мы и нашли артефакт, по которому можно предположить, что на
компьютере с которого пришел пакет с TTL -ом меньше стандартного
установлен шлюз ну, а там где шлюз там и NAT иногда можно найти.
Как же избежать изменения шлюзом TTL?
Для FreeBSD которая является шлюзом, можно собрать ядро со следующей опцией:
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the ttl). This can be useful to hide firewalls
# from traceroute and similar tools.
тогда наш шлюз будет очень интересно работать с TTL.
Если у шлюза нет функции "не изменять TTL", то можно изменить значение
TTL на самих компьтерах, которые скрыты за NAT увеличить их
стандартное значение TTL на единицу, тем самым после прохождения
пакета через шлюз на выходе сново получим стандартное значение TTL.
Для ОС Windows значение TTL меняется здесь (для NIX-вых систем мне было
лениво искать):
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters: DefaultTTL
Key: Tcpip\Parameters
Value Type: REG_DWORD-Number of seconds/hops
ValidRange: 0-0xff (0-255 decimal)
Default: 128
Description: Specifies the default time-to-live (TTL) value set in
the header of outgoing IP packets. The TTL determines the maximum
amount of time that an IP packet may live in the network without
reaching its destination. It is effectively a limit on the number of
links on which an IP packet is allowed to travel before being
discarded.
Надеюсь идея с TTL вам ясна.
Третья область
Последняя область, где возможно найти артефакты, указывающие на
возможное наличие NAT, это уровень приложений. Так как этот уровень
очень большой и ёмкий, я просто акцентирую ваше внимание на некотором
примере подобного артефакта.
Как известно, ваш веб-браузер вместе с запросом на страничку передает
серверу информацию о своей версии, вся эта информация, при
соответствующих настройках веб сервера, сохраняется в логах сервера.
Используя эти логи, администратор может найти строки, содержащие
одинаковые IP адреса и разные версии веб-браузера. Наличие таких строчек
может означать, что вы используете несколько веб-браузеров, или через
ваш компьютер ходит "чужой" трафик.
И еще хотел бы обратить ваше внимание на различные интернет пейджеры,
которые тоже могут передавать какую-либо информацию, по которой можно
косвенно судить о наличие NAT.
Заключение:
Ваш зверь NAT не вымрет и не будет отстрелен "браконьерами" , если вы
поняли идеи этой статьи.
И напоследок, эта статья не является руководством как /что делать, её
смысл обратить ваше внимание на некоторые мелочи, которые помогут спасти
птицу NAT.
By Dragon from Dreamer-pc.
Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как но по нему можно вычислить НАТ.
А так же FTP в активном режиме передаёт севреру команду PORT со своим реальным айпишником, если не включать поддержку Active FTP то по логам так же можно будет вычислить НАТ.
>Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как
>но по нему можно вычислить НАТ.
>А так же FTP в активном режиме передаёт севреру команду PORT со
>своим реальным айпишником, если не включать поддержку Active FTP то по
>логам так же можно будет вычислить НАТ.
БОЛЬШОЕ СПАСИБО ЗА ДОПОЛНЕНИЕ!
Как появиться свободное время проверю/протестирую Ваши дополнения и перепешу статью с учетом ваших замечание.
Хм. А что же мешает поставить правила, запрещающие входящие соединения на fake-адреса на внешний интерфейс? Тогда все будет работать и невозможно будет проникнуть во внутреннюю сеть. Это верно для IPF.
Статайка ничего, сам сталкивался с таким, но и это все будет бесполезно, если сдетать так как у меня.
И доступ в сетку некатит, и ftp/www/dns работает как надо.
В лине все описанные проблемы решаются всего в несколько строк:
iptables -t mangle -A POSTROUTING -p ALL -o ethX -j TTL 255
iptables -t nat -A POSTROUTING -p ALL -o ethX -j MASQUERADE
iptables -A INPUT -p ALL -i ethX -j ACCEPT -m state
--state ESTABLISHED,RELATED
iptables -A INPUT -p TCP -m multiport --dports 21,80,... -i ethX -j ACCEPT -m state
--state NEW,ESTABLISHED
iptables -A INPUT -p ICMP -i ethX -j ACCEPT -m state
--state NEW,ESTABLISHED --icmp-type echo-request
iptables -A INPUT -p ALL -i ethX -j DROP
iptables -A FORWARD -p ALL -i ethX -j ACCEPT -m state
--state ESTABLISHED,RELATED
Отличить можно будет только другими извратными методами типа ковыряния в слепках длины ICMP, и то не факт.
Избавиться от этой особенности NAT можно двумя способами:
1 - вый настроить межсетевой экран с запретом входящих соединений
2 - рой внимательно почитать про функциональные возможности демона natd.
Честно говоря не понял первый пункт. Протокол TCP есть протокол с подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий трафик, то возникает глупый вопрос, а как вы получите ответ, например от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. Ответа нет. И вылетаете по таймауту.
Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы с приведением жизненного примера. Точнее с практикой, как это делалось.
Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу сделать, но статья, насколько я понял, ориентирована на начинающих и им бы не мешало показать на живом примере.
А касательно лога web-сервера - здесь вообще раздолье. Просто взять пару строк и привести пример. Ведь не многие по началу даже знают не то что как выглядит лог-файл апача, но и где он находиться.
Впрочем это я уже зарвался. Ниче так статья. Но все же объясните про входящие соединения. Что-то я Вас не понял.
>Честно говоря не понял первый пункт. Протокол TCP есть протокол с
>подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий
>трафик, то возникает глупый вопрос, а как вы получите ответ, например
>от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные.
Если я вас правильно понял то:
Дано: Локальная сеть<--->| xl0| G+NAT |xl1|<------>Интернет
Сеть А скрыта за NAT который установлен на шлюзе имеющем два интерфейса (xl0,xl1).
Задача: разрешить локальной сети А пользоваться всеми сервисами сети Интернет по протоколу TCP, но запретить обращение из сети Интернет к сервисам локальной сети по протоколу TCP.
Опишу только запрет.
Вспомним, как по протоколу TCP устанавливается соединение ( http://www.citforum.ru/nets/semenov/4/44/tcp_443.shtml ):
1) Comp0 --> ---SYN ---> Copm1
2) Comp0<-- ACK,SYN <-Comp1
3) Comp0<--- ---ACK<----Comp1
Если представить, что Comp0 есть локальная сеть (А) то для того чтоб запретить установление соединения по протоколу TCP с Comp0 нужно брандмауэром запретить все пакеты исходящие с xl0 с установленным флагом SYN идущие из сети Интернет.
Как выглядит это в действительности, выше «запостил» Игорь. Прошу обратить внимание на слова --state NEW,ESTABLISHED в конфиге Игоря.
P.S Большое спасибо за отзывы, и замечания.
P.S Еще раз подчеркну, что написанная мной статья прежде всего есть кусочек теории/мыслей, которые могут помочь найти/спрятать NAT. Просто в той локальной, студенческой сети в которой я жил, несколько студентов (администраторов) запретили использование NAT. Вот я и описал для студентов общие принципы нахождения/прятанья NAT, но увы администраторы сети убиваю мою статью «запостиную» в студенческом форуме, аргументируя, что статья учит студентов плохому… (вот такая у нас свобода слова) :(
по поводу опции natd -deny_incoming - можно перед
divert xxxx поставить например pass from any to me 22,25 и все будет работать
>Избавиться от этой особенности NAT можно двумя способами:
> 1 - вый настроить межсетевой экран с запретом
>входящих соединений
> 2 - рой внимательно почитать про функциональные возможности
>демона natd.
>
>Честно говоря не понял первый пункт. Протокол TCP есть протокол с
>подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий
>трафик, то возникает глупый вопрос, а как вы получите ответ, например
>от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные.
>Ответа нет. И вылетаете по таймауту.
>Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы
>с приведением жизненного примера. Точнее с практикой, как это делалось.
>Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем
>с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу
>сделать, но статья, насколько я понял, ориентирована на начинающих и им
>бы не мешало показать на живом примере.
>А касательно лога web-сервера - здесь вообще раздолье. Просто взять пару строк
>и привести пример. Ведь не многие по началу даже знают не
>то что как выглядит лог-файл апача, но и где он находиться.
>
>Впрочем это я уже зарвался. Ниче так статья. Но все же объясните
>про входящие соединения. Что-то я Вас не понял.
касательно уровня приложений - провайдер не имеет права хоть как-то анализировать ваш трафик (содержимое пакетов), это все равно что прослушивать телефонные переговоры. Если вам предоставили подобные логи - берите их и идите в суд. Они могут знать что вы так делаете, но мараться не будут. Если только с санкции.. Или я неправ???
но не имеет права разглашать и передавать третьим лицам увиденное
и если в договоре чётко прописан запрет на нат/прокси - результат анализа логов является поводом для подачи в суд за нарушение договора
Хорошая статья. Но есть существенное дополнение, а именно дело было так. Прочитал -> решил попробовать, так как на работе своя бука юзается именно через нат.
Тест был следующий
бука(172.31.5.51)->(NAT)рабочий комп(eth1:172.31.5.53, eth0:192.168.111.195)
Нетрудно видеть что eth0 внешняя сеть, а eth1 внутренняя якобы, бука за натом. Дальше к томуже свичу что и eth0 подключён комп (192.168.111.189) Понятно что в обычных условиях пинг на буку не пойдёт. Прописываем роутинг на 192.168.111.189, указав мой eth0 на рабочей машине как шлюх и воля. пинг идёт. Однако тут и одно но. Вроде бы всё как по статье да только не совсем. А именно. Что-то меня заставило усомнится в том что всё именно так как описано. Запустив банальный iptraf я посмотрел от куда приходят icmp, и что же я вижу? они приходят с 192.168.111.189. Если бы такой расклад был благодаря NAT тоесть если бы это была его фишка то icmp преобровывался и приходил от eth0 моего рабочего компа. Это при том что icmp на 192.168.111.189 приходит именно от eth0 (как и должно быть) а не от буки. Всё это наталкивает на вывод о том что фишка эта не в нате а в шлюзе. Весь сказ. И нат тут не причём получается. Поправте если я ошибся.
P.S. большое спасибо автору за статью, полезно было почитать
