Comments 55
Угу, я по этой грабле просто охрененно прогулялся и был глубоко удивлён.

В какой-то момент меня задолбал техотдел с требованиями всяких 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 работает ПОСЛЕ маршрутизации и только если это нужно, осталось.
>nat работает ПОСЛЕ маршрутизации

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

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

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

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

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

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

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

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

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

Классический 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 подмена осуществляется ДО маршрутизации.
Абсолютно верно.
Только
> для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
подменять ничего не надо :)
>подменять ничего не надо :)

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

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

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

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

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

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

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

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

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

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

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

со стороны аплинка:
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)

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

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

Но, очевидно, что реализации этого сценария слишком много условий должно выполняться: везде по дороге должен быть включен source routing, на граничных маршрутизаторах должен быть разрешен трафик к серым сеткам (чтобы послать «инициализирующий пакет»), ну и не должно стоять никаких фильтров у самого клиента (что глупо, но в этом и суть статьи :).
Only those users with full accounts are able to leave comments. Log in, please.