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 сайта
http://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-вых систем мне было
лениво искать):
HKLMSYSTEMCurrentControlSetServicesTcpipParameters: DefaultTTL
Key: TcpipParameters
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.
Vova
