antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 27 Февраль , 2010

Трансляция сетевых адресов не является защитной технологией, однако она настолько часто применяется, что пропускать её не стоит. Все возможности трансляции сетевых адресов здесь описывать не буду, коснусь лишь самых частоиспользуемых.

Трансляция сетевых адресов (Network Address Translation, NAT) как правило, требуется на границе между сетью компании и провайдером Интернет.

Обычно разделяют внутреннюю (inside) и внешнюю (outside) трансляции. Внутренняя трансляция подменяет адрес источника при выходе «наружу» маршрутизатора, а внешняя трансляция подменяет адрес источника при проходе «внутрь». Направление определяется при помощи меток, написанных на интерфейсе

ip nat {inside|outside}


Если мы написали на интерфейсе или подинтерфейсе такую команду, значит мы явно указали, что данный интерфейс будет принимать участие в трансляциях и какую роль будет играть. Маршрутизатор поступает так: если пакет пришёл на интерфейс, помеченный как внутренний (ip nat inside), а следуя таблице маршрутизации должен выйти через интерфейс, помеченный как внешний (ip nat outside), то это значит, что надо искать в конфигурации правила, описывающие статические или динамические внутренние (inside) трансляции.

Примечание: на практике как правило, достаточно использовать внутреннюю трансляцию, чтобы подменить частные, немаршрутизируемые в Интернете адреса (RFC1918) на глобальные, выданные провайдером. Использование внешней трансляции — экзотика, но неправильной настройке может доставить массу хлопот админу.

Также, определяют трансляции адрес в адрес (Network Address Translation, NAT, выполняется на 3 уровне модели OSI, один адрес заменяется другим), и трансляции с учетом порта (Port Address Translation, PAT, выполняется на уровне модели OSI и подменяет не только адрес, но и порт). Понятно, что трансляцию РАТ можно выполнить только для протоколов, у которых есть порты (TCP, UDP). Зато используя РАТ можно несколько локальных адресов странслировать в один глобальный: в кэш трансляций записывается соответствие исходного адреса и порта и полученных в результат трансляции адреса и порта.

Пример: пусть 2 локальных пользователя с адресами 10.1.1.100 и 10.1.1.200 решили посетить один и тот же сайт www.anticisco.ru. Если мы используем NAT, в этом случае нам надо каждому внутреннему пользователю выдать по глобальному адресу из пула провайдера ISPPool():

10.1.1.100 -> ISPPool(1)
10.1.1.200-> ISPPool(2)

Если же мы будем использовать РАТ, то можем сопоставить разным частным адресам один глобальный, но запишем ещё и порты источника:

10.1.1.100:29010 -> ISPPool(1):1024
10.1.1.200:18932 -> ISPPool(1):1025

И когда придёт ответ от сервера, маршрутизатор выберет из кеша трансляций ту, на чей порт придёт ответ.

Чтобы окончательно добить вас, дорогие читатели, скажу ещё, что трансляции делятся на статические и динамические. Статические строго привязывают один адрес к другому (в случае с NAT) или пару адрес и порт (в случае с РАТ). А динамические создаются по необходимости, если пришедший пакет удовлетворяет критерию отбора для правил трансляции.

Давайте теперь посмотрим, какими командами настраиваются упомянутые трансляции. Напомню, мы рассматриваем простой случай с одним провайдером и только внутренние трансляции

Динамические трансляции:
1. Определяем пул адресов для NAT.
ip nat pool {POOLNAME} {start_ip} {end-ip} netmask {mask}

Пример:
ip nat pool INET 1.1.1.100 1.1.1.150 netmask 255.255.255.0

Важно: указывая маску для пула вы сообщаете маршрутизатору, какие адреса считать адресами сети и широковещания (броадкаст, broadcast). Эти адреса маршрутизатор будет исключать из выдачи. Нужно это, если пул адресов шире классовой маски. Например, вы хотите пул с 192.168.100.1 по 192.168.101.254, но при этом это 2 сети с маской /24. Тогда указание маски 255.255.255.0 очень важно.

2. На всех интерфейсах, участвующих в трансляциях, надо указать
ip nat {inside|outside}

3. Описываем специальный список доступа, который служит критерием для выполнения трансляции.
ip access-list extended {ACLNAME}
permit {условия}

4. Описываем саму динамическую трансляцию адрес в адрес (NAT)
ip nat inside source list {ACLNAME} pool {POOLNAME}

Если же стоит задача создать РАТ трансляцию в адреса этого пула, то добавляем одно ключевое слово:
ip nat inside source list {ACLNAME} pool {POOLNAME} overload

Можно также для РАТ использовать адрес внешнего интерфейса:
ip nat inside source list {ACLNAME} interface {int} overload

Важные замечания: часто начинающие делают ошибку, забывая добавить ключевое слово overload. Т.к. в этом случае используется NAT, значит как только пул будет исчерпан, новые трансляции создаваться не будут. Особенно это критично, если забывают добавить overload при трансляции в адрес интерфейса. Также важно помнить, что выполняется первая по счёту трансляция из конфигурации, с которой совпал пакет.

Статические трансляции.
Статические трансляции позволяют жестко связать частный внутренний адрес и глобальный внешний. Благодаря этому возможно обратиться снаружи на глобальный адрес и тогда адрес назначения подменится на частный адрес.
Формат команды такой
Для NAT:
ip nat inside source static {LOCAL_IP} {GLOBAL_IP}

Работает она так: если пакет идёт со стороны внутреннего интерфейса в сторону внешнего, то его адрес источника подменится с LOCAL_IP на GLOBAL_IP. А когда пакет бежит в обратном направлении, его адрес назначения подменяется с GLOBAL_IP на LOCAL_IP

Для РАТ:
ip nat inside source static {tcp|udp} {LOCAL_IP} {LOCAL_PORT} {GLOBAL_IP} {GLOBAL_PORT}

Работает также, но только подменяем мы не адрес, а пару {адрес:порт}.

Пример: выпустим наружу всю локальную сеть 10.1.1.0/24 за интерфейсом f0/1 наружу, используя адрес интерфейса f0/0, а также опубликуем («пробросим») 25 порт частного почтового сервера
10.1.1.100 в порт 2525 адреса 1.1.1.200
!
int f0/0
ip address 1.1.1.254 255.255.255.0
ip nat outside
!
int f0/1
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
ip access-list extended NAT
permit ip 10.1.1.0 0.0.0.255 any
!
ip nat inside source list NAT interface f0/0 overload
ip nat inside source static tcp 10.1.1.100 25 1.1.1.200 2525

Посмотреть созданные трансляции (кэш) можно командой
sh ip nat translation

Почистить весь кэш
clear ip nat translation *

Важно: кэш трансляций имеет время жизни. У ТСР время большое (по умолчанию 3600секунд), у UDP существенно меньше (30 секунд). Эти параметры можно поменять. При изменении правил трансляции кэш надо чистить. Если есть 2 провайдера, то при переключении между провайдерами также надо чистить кэш

 

Метки: , ,
Опубликовано: Маршрутизаторы и коммутаторы

 

9 комментариев “Защищаемся маршрутизатором. Простой NAT”

comment rss - Trackback

  1. Ilya:

    маленький забавный коммент. Ivan Pepelnjak, CCIE#1354, в своей статье IPv6 myths (http://blog.ioshints.info/2010/02/ipv6-myths.htm) про НАТ говорит буквально следующее: «Anyone who thinks NAT is a security feature deserves to become part of a botnet» 🙂 Хотя я с ним не согласен и видимо мы с Сергеем рискуем таки стать частью ботнета 🙂

    • Greg:

      Ilya: А вы действительно считаете что при таких настройках

      int f0/0
      ip address 1.1.1.254 255.255.255.0
      ip nat outside
      !
      int f0/1
      ip address 10.1.1.1 255.255.255.0
      ip nat inside
      !
      ip access-list extended NAT
      permit ip 10.1.1.0 0.0.0.255 any
      !
      ip nat inside source list NAT interface f0/0 overload
      ip nat inside source static tcp 10.1.1.100 25 1.1.1.200 2525

      никто не сможет стукнуться на сервер 10.1.1.100 TCP порт 3389 и если там Windows сервер не получит возможность ввести пароль на Remote Desktop?

      Если да, то «You deserve to become part of a botnet»

      • Насколько я знаю НАТ, порт 3389 не будет прокинут внутрь на 10.1.1.100, поэтому на РДП не попасть…

        Но есть тонкость: порт 3389 попадает в верхний диапазон портов, поэтому есть небольшая вероятность, что некая сессия , открытая с сервера, будет иметь порт источника 3389, однако и в этом случае попасть на РДП не получится

        • Greg:

          Всё совсем не так.
          «порт 3389 попадает в верхний диапазон портов, поэтому есть небольшая вероятность» тут вероятность нулевая. Порт 3389 серверный и никогда не начнёт сам инициировать соединение, значит трансляция не создастся по определению.

          Но….
          1) Если из внешней подсети 1.1.1.0/24 кто-то смаршрутизирует на 1.1.1.254 пакеты для подсети 10.1.1.0 то можно будет обратиться на этот порт, в результате создастся трансляция, которую можно будет эксплуатировать. А смаршрутизировать может, если не считать провайдера любой клиент в одной с вами подсети.
          2) Не обязательно быть с 1.1.1.254 в одной подсети, достаточно быть в одном влане, чтобы иметь возможность доставить произвольный пакет на интерфейс int f0/0
          3) Есть такая интересная фича у протокола TCP/IP, называется маршрутизация от источника(задаётся IP опциями в пакете), которая по дефолту не рубится цисками, её тоже можно проэксплуатировать для такой атаки, при этом даже не обязательно быть в подсети 1.1.1.0/24, достаточно, чтобы провайдер не закрыл такую маршрутизацию.

          Пожалуй всё.

          • Greg:

            Пожалуй, стоит добавить, что не всё так просто. Тут ко всему прочему нужно манипулировать пакетами, изменяя их при передаче, однако при наличии нормальной операционки, типа линуха или фрибсд. Это только кажется сложным, пока сам не попробуешь.
            Походу с нуля, на перле это делается за несколько часов, поверьте я пробовал.

          • Операционка конечно никогда с серверного порта инициировать не будет. Это понятно.

            Я имел ввиду, что многие железяки при трансляциях РАТ подставляют вместо порта источника первый свободный из верхнего диапазона (1024-…)
            Теоретически, через 2365 трансляций будет задействован 3389 🙂
            Но это ни к чему не приведет

            ЗЫ Кстати, я, как давно специализирующийся на безопасности, всегда утверждал и утверждаю: НАТ — НЕ защитная фича.

  2. Ilya:

    и еще маленькое имхо: я бы добавил, что статическая трансляция не требует наличия прямой для обработки обратной. А динамические требуют.

» Оставить комментарий

Вы должны войти чтобы прокомментировать.