NAT не firewall, повторим еще разок



    Посмотрите на рисунок. Вот так конфигурируется классический NAT на маршрутизаторе Cisco, допустим там больше ничего не сконфигурировано. А теперь ответьте сами себе на вопрос. Может ли при определенных условиях кто-либо обратиться извне на RDP порт (TCP 3389) супер секретного сервера 192.168.0.250 и попытаться подобать пароль к нему. Уточним, что сервер стоит одиноко в сети и никуда сам не обращается (имеется в виду, что на нем нет никаких троянов, автоматических обновлений и прочих прелестей).

    Считаете — нет? Вспомним анекдот.

    Лекция по филологии. Старый профессор рассказывает:

    — В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но, нет ни одного языка в мире, в котором двойное согласие означает отрицание. Голос с задней парты:

    — Ну да, конечно, профессор.

    Почему нет


    Толковый сетевой инженер с уровнем CCNP сразу же ответит – нет, и обоснует это следующим образом. Для того, чтобы обмениваться данными с хостом за NAT необходимо чтобы в NAT создалась трансляция. Создание трансляции инициируется хостами из внутренней, с точки зрения NAT, сети. Серверное приложение на порту TCP 3389 само никуда не обратится, на то оно и серверное, поэтому трансляция не будет создана никогда, и никто во внутрь не пролезет. Инженер будет прав. Однако он не учитывает того, что обратиться к хосту за NAT извне при такой конфигурации можно, а уже после этого будет создана трансляция, через которую сервер будет передавать данные.

    Почему да


    Теоретически все просто. Задумайтесь, а что будет, если провайдер на своем маршрутизаторе B пропишет вот такой маршрут:
    ip route 192.168.0.0 255.255.255.0 2.2.2.2
    А будет следующее. Любой клиент провайдера может отправить TCP пакет на IP 192.168.0.250 порт 3389. Этот пакет, согласно таблицам маршрутизации провайдера будет доставлен на интерфейс FE0/0 марштрутизатора A. Что сделает с ним маршрутизатор A? То, для чего предназначены все маршрутизаторы — смаршрутизирует на хост 192.168.0.250. Сервер 192.168.0.250 в ответ пошлет пакет на IP адрес источника, пришедшего в изначальном пакете. Маршрутизатор A создаст трансляцию через которую будут передаваться данные к хосту источнику изначального пакета.

    А вот тут возникают сложности. Они связаны с тем, что пакет уходит на IP адрес 192.168.0.250 порт 3389, а возвращаются с адреса 2.2.2.2 и порта не обязательно 3389. Вы можете мне не верить, но при наличии у атакующего FreeBSD с его divert socket-ами, perl-а, воображения и понимания как работают протоколы TCP/IP, нет ничего не возможного и можно получить доступ на терминал атакуемого сервера в течение одного дня.

    Еще немного поговорим об этом


    Когда я рассказывал о такой атаке знакомому, работающему у провайдера, он мне задал резонный вопрос — а вот ты мне назови хоть одного провайдера, который будет заниматься подобными вещами? Я сам раньше работал у провайдера и знаю, что никакой, но ответил вопросом – а ты знаешь, что такое маршрутизация от источника, и то, что по умолчанию она не отключена на маршрутизаторах Сisco? Ты ее отключаешь?
    При использовании маршрутизации от источника атака не сильно усложняется, достаточно добавить, на сколько я помню, 5 байт в опциях IP пакета.

    Заключение


    Может быть, пост и провокационный, но я знаю, что большинство сетевиков не знают о подобной атаке и никогда не конфигурируют firewall в случае, когда используют NAT. Возможно, после прочтения этого поста кто-то и начнет следовать всем рекомендациям по защите сети, поверьте, они не просто так пишутся…
    Поделиться публикацией
    Комментарии 55
      +27
      Угу, я по этой грабле просто охрененно прогулялся и был глубоко удивлён.

      В какой-то момент меня задолбал техотдел с требованиями всяких VPN, я им выделил /29 белую сетку с DHCP внутри циски. Саму сетку пустил через вилан на коммутатор и на нужные порты.

      Выглядело это так:

      int vlan 1
      #серые адреса
      ip nat inside

      int vlan 2
      # провайдер
      ip nat outside

      int vlan 3
      # засранцы
      ip nat outside

      Какое же моё удивление было, когда из vlan3 с компьютера с белым адресом удалось обратиться по серому адресу сервера из vlan 1 и получить к нему доступ!

      Я это пофиксил, но вот понимание того, что nat работает ПОСЛЕ маршрутизации и только если это нужно, осталось.
        0
        >nat работает ПОСЛЕ маршрутизации

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

        Тут дело в том, что когда на WAN-интерфейс приходит пакет адресованный в LAN, а не на IP-адрес WAN-интерфейса, то так как такой записи нет в таблице трансляций NAT, то он маршрутизируется в соответствии с таблицей маршрутизации.
          0
          А вот у меня есть стойкое ощущение, что именно наоборот. И раз тут уж про циски говорят, то давайте их терминологией говорить, не «wan», а «outside» и «inside» порты. Так вот, сначала маршрутизация, а потом уже nat.

          У меня, например, так работает переключение провайдеров при дауне одного из них. Сначала мы делаем маршрутизацию, а потом уже (поняв, через какой интерфейс мы пойдём) применяется его трансляция.
            +2
            Ваш пример относится к исходящему из роутера трафику.

            Прочитайте ещё раз мой коммент выше внимательно.

            Для входящего пакета — сначала NAT, потом маршрутизация.
            Для исходящего пакета — сначала маршрутизация, потом NAT

            см. — NAT order operation
              0
              Судорожно пытаюсь понять, что такое «входящий» и «исходящий» трафик.

              Вот, например, когда пакет пришёл на fe0/1/3 — это входящий? На на vlan 1377 — это исходящий?

              В моём представлении «исходящий трафик» в маршрутизаторе — это то, что с порта выходит. А в локалку ли, или к одному из пиров (который по совместительству ещё и аплинк) — это дело уже десятое.

              Или вы про SOHO, где есть «порт интернета»?
                0
                входящий\исходящий относительно роутера.

                Классический Domain Based NAT несколько ограничен в своих возможностях и требует однозначного указания inside\outside, а вот более современная реализация NVI (NAT Virtual Interface) даёт возможность лучше понять этот алгоритм.

                При использовании NVI мы просто указываем на интерфейсе «ip nat enable» — т.е. просто включаем на этом интерфейсе проверку NAT. Все пакеты проходящие через этот интерфейс будут проверяться на наличие каких-либо NAT-трансляций.

                Т.е. пакет идёт через 3 стадии:
                1.входящий интерфейс
                2.маршрутизация
                3.исходящий интерфейс

                В 1 и 3 пунктах ВОЗМОЖНА проверка правил NAT. Соответственно при классическом NAT проверка делается на обоих интерфейсах, но подмена происходит только на outside интерфейсе, т.е. только один раз.

                Поэтому для пакета идущего из inside в outside подмена осуществляется ПОСЛЕ маршрутизации.
                А для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
                  0
                  Абсолютно верно.
                  Только
                  > для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
                  подменять ничего не надо :)
                    0
                    >подменять ничего не надо :)

                    а как же dst port в случае NAT overload?
                    ;)
                      0
                      Простите, не удержался, от того, чтобы немного не потроллить… :)
                  0
                  amarao, Вы не правы, и напрасно придираетесь к словам g0ff.
                  Давайте я объясню то же самое, что и g0ff, только другими словами.
                  В вашем случае, когда «заcранцы» из Vlan 3 стучались на серые IP из Vlan 1, пакеты приходили на inside (внутренний) с точки зрения NAT интерфейс. Маршрутизатор в этом случае решает куда их отправить. Если надо отправить через внешний с точки зрения NAT (outside) интерфейс, то сработает NAT, если через другой интерфейс, не важно прописано там inside, или ничего не прописано, то до NAT дело вообще не дойдет.
                  Теперь по тому, что написано в статье.
                  Когда пакет приходит на ouside с точки зрения NAT интерфейс, маршрутизатор проверяет заголовок пакета DST IP. Если IP адрес назначения попадает в пул внешних IP сконфигурированный для NAT, то срабатывает NAT, если нет — то маршрутизация.

          0
          А правильные ACL на входящем/исходящем интерфейсах от такого не спасут?
            +2
            Правильные acl конечно спасут, но автор намекат что acl это как раз firewall и при использовании nat про acl забывать нельзя — хотя спорно конечно.
              0
              В реальной жизни я не видел применения NAT без CBAC/ZBF или на худой конец Reflexive ACL.
            +12
            проблема высосана из пальца.
              +3
              Это не проблема, это нюанс.
              +3
              Я, конечно, знал, что NAT != firewall (люто ненавижу, когда доказывают обратное), но вот так внаглую подставить dst не догадался бы :).

              Насколько я понял, при получении ответа достаточно просто подменить в PREROUTING 2.2.2.2 на 192.168.0.250 (вроде, в Linux можно в tc)?

              Спасибо. Плюсанул, чего и остальным советую.
                0
                Это что же за ccnp и как он сдавал экзамен, если задача уровня ccnd.
                И решается она правильными acl на input.
                  0
                  CCND это же про проектирование, а CCNP — про реализацию, поэтому уровень у них может быть одинаковый, но в немного разных областях.
                  +5
                  Посколько пост в системном администрировании, а не в Cisco, позволю себе немного погундеть что данный финт это особенности раелизации Cisco.

                  Подозреваю что в iptables не сработает потому что -t nat -A PREROUTING, хотя не проверял и могу ошибаться.
                  В любом случае ничто не мешает обрабатывать правила NAT до маршрутизации и то что некоторые делают это после — это их личная проблема, а не глобальный недостаток.
                    +2
                    Это не глобальный недостаток, статья этого и не утверждает, а лишь ещё раз напоминает, что каждый инструмент нужно использовать для целей, для которых он предназначен — NAT для трансляции, файрволл и аклы — для безопасности.
                      0
                      А мне кажется, что сработает. Основная проблема — это чтоб у нас был определенный source port. Нужно так долбиться до тех пор, пока мы его не получим, вот и все.
                        +3
                        Да нет, POSTROUTING. Но кто ж делает forward с WAN-интерфейса без --state RELATED,ESTABLISHED?
                          +1
                          Вообще-то NAT есть в обоих цепочках. Т.е. вы спорите не о чем, но выглядит забавно ;)
                            +1
                            Чтобы не бродить по ссылкам вам:
                            image
                              0
                              Картинка старая, т.к. есть еще в INPUT и OUTPUT (последнее ядро посмотрел)
                                0
                                Хабр решил, что она слишком старая и не вставил.;)
                              +2
                              В HOWTO для маскарада из локалки используется цепочка POSTROUTING, а PREROUTING — для проброса портов, если он нужен.
                          0
                          Параноя детектед
                            +6
                            Лучше быть параноиком чем оправдываться что сеть сламали из-за «я не знал что это возможно».
                              0
                              Правилом хорошего тона является запрещать трафик из серых подсетей на внешних интерфейсах.
                                +4
                                Во — первых трафик не из серых сетей а на серые сети.
                                А на счёт паранойи — отнюдь нет.
                                Любую информацию можно использовать по разному, к примеру задайте такой вопрос на собеседовании с претендентом. Если даже он не ответит, посмотрите, загорятся ли у него глаза, когда скажете про маршрут от провайдера. Поверьте, его реакция может о многом про него рассказать…
                              +1
                              Это паранойя? Паранойя — это когда «одна сеть физически не должна быть подключена к другой, ибо могут взломать».
                              +1
                              Собственно, это недостаток схемы «разрешено все, что не запрещено». Такой финт с прохождением пакетов можно и на iptables увидеть (кажется удивительно, а на самом деле надо просто проштудировать порядок прохождения таблиц и цепочек пакетом).
                              Вот буквально сейчас на iptables с политикой «запрещено все, что не разрешено» прокинул порт на внутренний адрес, а доступа нет. А почему? А потому что в таблице NAT прероутинг сработал, а вот в таблице FILTER (с политикой DROP) прохождение я не разрешил.

                              Честно говоря, с циской особо не работал, но вот для iptables следует помнить, что маршрутизация и трансляция адресов — понятия разные и настраиваются в разных таблицах фаерволла.
                                +2
                                Как-то немного не логично, что маршрутизатор, у которого на ВНУТРЕННЕМ интерфейсе прописан, ip-адрес например 192.168.0.1/24 пропускает пакеты с ВНЕШНЕГО интерфейса от адресов из сети 192.168.0.1/24
                                  0
                                  Не совсем правильно выразился — пропускает пакеты с внешнего интерфейса отправленные в сеть 192.168.0.1/24
                                    0
                                    Оно не логично, но порой имеет место.

                                    У нас есть один провайдер такой. Из нашей внутренней сети можно пинговать сети 192.168.XX.0/24. Пакеты на эти сети шли через наш внешний адрес на маршрутизатор провайдера. Причем раньше от одного хоста даже ответ приходил :) Когда я написал об этом провайдеру (и приложил трассировку), он попросил (внимание!) скриншот трассировки :) Выслал. Теперь из этих сетей приходит ответ Packet Filtered. Но наш пограничный роутер все равно знает, что они доступны через внешний интерфейс :)
                                    +2
                                    Нет ничего не логичного. У маршрутизатора нет такого понятия как внутренний и внешний интерфейс. Все интерфейсы одинаковы.
                                      +1
                                      Да как-то хотелось верить, что маршрутизатор обеспечивает хотя бы базовую защиту, а в реальности любой кто в подъезде подключился к вашему марширутизатору вместо провайдера, может отправлять пакеты вашим сервисам во внутренней сети.

                                      Думаю, что такая потенциальная уязвимость актуальная для многих домашних пользователей и небольших организаций
                                        0
                                        Кто не понял, я про SOHO маршрутизаторы, которые обычно сами пользователи настраивают.

                                        То, что офисные Cisco должны быть правильно настроены админом, по моему само собой разумеется.
                                          0
                                          На SOHO-маршрутизаторах по умолчанию включен т.н. basic firewall, который тупо блокирует все входящие пакеты не имеющие соответствия в таблице NAT'a, поэтому там это не очень актуально.
                                            0
                                            Понятно, спасибо
                                        +2
                                        Вообще-то это функция маршрутизатора — форвардить входящие пакеты на тот интерфейс на котором прописан адрес относящийся к той же подсети.

                                        Единственное когда это может казаться нелогичным, это если вы работали только с маршрутизаторами типа SOHO-железка с одним портом для интернета и другим для внутренней сети, или аналогичной роли «сервером»-маршрутизатором на линуксе.
                                        0
                                        Да, это круто, и при SSRR это сработает, если вначале протрейсить маршрут, а потом задать список хопов жестко.

                                        Спасибо за статью!
                                          0
                                          Проще сделать через LSRR, в поле options надо будет прописывать только один IP, и маршруты тестить не надо.
                                          +1
                                          Вообще-то «no ip source-route» написаны большими буквами во всех best practice.
                                          Но это, конечно, не отменяет утверждения, что NAT это не мера безопасности.
                                            0
                                            Спасибо, интересно. Плюсанул топик до 100 :)
                                              0
                                              хорошая статья и полезная для многих… особенно для тех кто подумал, что находится в безопасности скрываясь за натом и строго контролируя трансляции внутрь своей сети :)
                                                0
                                                Теперь понятно почему в примерах для файрвола указывают адрес внешнего интерфейса:
                                                pass in on $ext_if proto tcp to ($ext_if) port { ssh, www }
                                                всегда думал, что это лишнее, как оказывается не зря.
                                                  +4
                                                  Толковый сетевой инженер с уровнем CCNP сразу же ответит – нет, и обоснует это следующим образом. Для того, чтобы обмениваться данными с хостом за NAT необходимо чтобы в NAT создалась трансляция.


                                                  Не совсем так. Толковый системный инженер знает, что трансляции NAT могут создаваться не только при непосредственной трансляции TCP/UDP соединений и, как минимум, задумается.

                                                  Существует несколько атак на инъекцию записей в таблицу трансляций NAT. Самая классическая через FTP. FTP требует дополнительного соединения для передачи данных, многие реализации NAT отслеживают команды протокола, в частности ответ 227 от FTP-сервера (на команду PASV), типа
                                                  227 Entering Passive Mode (192,168,0,250,13,61)
                                                  Там, где маршрутизатор не поддерживает stateful inspection, он просто смотрит на подобную сигнатуру в начале данных TCP-пакета c 21го порта FTP-сервера. Атака заключается в следующем — дается достаточно длинная команда на FTP-сервер, в конце которой записывается данный ответ с нужным адресом и портом. FTP-сервер дает ответ типа
                                                  500 'то, что ему передали' command not understood.
                                                  Размер длинной строки подгадывается так, чтобы ответ сервера улетел в двух TCP-пакетах и нужный текст пришелся на начало второго.
                                                  В результате маршрутизатор делает маппинг на требуемый 192.168.0.250:3389.
                                                    +2
                                                    Возражу, что для того, чтобы осуществить подобную атаку нужно сначала установить FTP соединение с внутренним хостом, а этого в условиях не было. А задумается инженер в любом случае, просто потому, что, раз спрашивают, то где подвох.
                                                    0
                                                    вот, кстати, кусочки входящих аксесс листов на одном маршрутизаторе:

                                                    со стороны аплинка:
                                                    deny ip 10.0.0.0 0.255.255.255 any (5810726 matches)
                                                    deny ip 192.168.0.0 0.0.255.255 any (2215826 matches)
                                                    deny ip 172.16.0.0 0.15.255.255 any (5226969 matches)

                                                    со стороны клиента:
                                                    deny ip any 10.0.0.0 0.255.255.255 (20932471 matches)
                                                    deny ip any 192.168.0.0 0.0.255.255 (46788406 matches)
                                                    deny ip any 172.16.0.0 0.15.255.255 (4554724 matches)

                                                    достаточно неосторожного маршрута, чтобы, при отсутствии элементарных мер безопасности, кто-то повеселился на славу :)
                                                      0
                                                      У меня почему-то от deny ip any 192.168.0.0 0.0.255.255 перестает работать инет во всей внутренней сети :-(
                                                        +1
                                                        извините, я здесь показал пример клиента с публичным (белым) адресом, которых у меня абсолютное большинство, за редким исключением… то есть в вашем случае этот ацл нужно применить немного раньше, до вашего интерфейса во внутренней сети, или изменить его в зависимости от использованной адресации в своей локальной сети :)
                                                          0
                                                          с того что у клиента белый адреса надо было начинать :-)

                                                          Кстати, после того как прочитав эту статью я поиграл с ACL, у меня возникли проблемы с FTP в passive mode. В чем причина я до сих пор не могу понять, потому что другие протоколы работают нормально.
                                                      0
                                                      Интересный сценарий, спасибо за статью.

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

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое