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 работает ПОСЛЕ маршрутизации и только если это нужно, осталось.
В какой-то момент меня задолбал техотдел с требованиями всяких 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, то он маршрутизируется в соответствии с таблицей маршрутизации.
Для входящего в роутер пакета NAT обрабатывается раньше, чем маршрутизация, а для исходящего наоборот — сначала маршрутизится, потом уже NATируется.
Тут дело в том, что когда на WAN-интерфейс приходит пакет адресованный в LAN, а не на IP-адрес WAN-интерфейса, то так как такой записи нет в таблице трансляций NAT, то он маршрутизируется в соответствии с таблицей маршрутизации.
А вот у меня есть стойкое ощущение, что именно наоборот. И раз тут уж про циски говорят, то давайте их терминологией говорить, не «wan», а «outside» и «inside» порты. Так вот, сначала маршрутизация, а потом уже nat.
У меня, например, так работает переключение провайдеров при дауне одного из них. Сначала мы делаем маршрутизацию, а потом уже (поняв, через какой интерфейс мы пойдём) применяется его трансляция.
У меня, например, так работает переключение провайдеров при дауне одного из них. Сначала мы делаем маршрутизацию, а потом уже (поняв, через какой интерфейс мы пойдём) применяется его трансляция.
Ваш пример относится к исходящему из роутера трафику.
Прочитайте ещё раз мой коммент выше внимательно.
Для входящего пакета — сначала NAT, потом маршрутизация.
Для исходящего пакета — сначала маршрутизация, потом NAT
см. — NAT order operation
Прочитайте ещё раз мой коммент выше внимательно.
Для входящего пакета — сначала NAT, потом маршрутизация.
Для исходящего пакета — сначала маршрутизация, потом NAT
см. — NAT order operation
Судорожно пытаюсь понять, что такое «входящий» и «исходящий» трафик.
Вот, например, когда пакет пришёл на fe0/1/3 — это входящий? На на vlan 1377 — это исходящий?
В моём представлении «исходящий трафик» в маршрутизаторе — это то, что с порта выходит. А в локалку ли, или к одному из пиров (который по совместительству ещё и аплинк) — это дело уже десятое.
Или вы про SOHO, где есть «порт интернета»?
Вот, например, когда пакет пришёл на 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 подмена осуществляется ДО маршрутизации.
Классический 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 подмена осуществляется ДО маршрутизации.
amarao, Вы не правы, и напрасно придираетесь к словам g0ff.
Давайте я объясню то же самое, что и g0ff, только другими словами.
В вашем случае, когда «заcранцы» из Vlan 3 стучались на серые IP из Vlan 1, пакеты приходили на inside (внутренний) с точки зрения NAT интерфейс. Маршрутизатор в этом случае решает куда их отправить. Если надо отправить через внешний с точки зрения NAT (outside) интерфейс, то сработает NAT, если через другой интерфейс, не важно прописано там inside, или ничего не прописано, то до NAT дело вообще не дойдет.
Теперь по тому, что написано в статье.
Когда пакет приходит на ouside с точки зрения NAT интерфейс, маршрутизатор проверяет заголовок пакета DST IP. Если IP адрес назначения попадает в пул внешних IP сконфигурированный для NAT, то срабатывает NAT, если нет — то маршрутизация.
Давайте я объясню то же самое, что и g0ff, только другими словами.
В вашем случае, когда «заcранцы» из Vlan 3 стучались на серые IP из Vlan 1, пакеты приходили на inside (внутренний) с точки зрения NAT интерфейс. Маршрутизатор в этом случае решает куда их отправить. Если надо отправить через внешний с точки зрения NAT (outside) интерфейс, то сработает NAT, если через другой интерфейс, не важно прописано там inside, или ничего не прописано, то до NAT дело вообще не дойдет.
Теперь по тому, что написано в статье.
Когда пакет приходит на ouside с точки зрения NAT интерфейс, маршрутизатор проверяет заголовок пакета DST IP. Если IP адрес назначения попадает в пул внешних IP сконфигурированный для NAT, то срабатывает NAT, если нет — то маршрутизация.
А правильные ACL на входящем/исходящем интерфейсах от такого не спасут?
проблема высосана из пальца.
Я, конечно, знал, что NAT != firewall (люто ненавижу, когда доказывают обратное), но вот так внаглую подставить dst не догадался бы :).
Насколько я понял, при получении ответа достаточно просто подменить в PREROUTING 2.2.2.2 на 192.168.0.250 (вроде, в Linux можно в tc)?
Спасибо. Плюсанул, чего и остальным советую.
Насколько я понял, при получении ответа достаточно просто подменить в PREROUTING 2.2.2.2 на 192.168.0.250 (вроде, в Linux можно в tc)?
Спасибо. Плюсанул, чего и остальным советую.
Это что же за ccnp и как он сдавал экзамен, если задача уровня ccnd.
И решается она правильными acl на input.
И решается она правильными acl на input.
Посколько пост в системном администрировании, а не в Cisco, позволю себе немного погундеть что данный финт это особенности раелизации Cisco.
Подозреваю что в iptables не сработает потому что -t nat -A PREROUTING, хотя не проверял и могу ошибаться.
В любом случае ничто не мешает обрабатывать правила NAT до маршрутизации и то что некоторые делают это после — это их личная проблема, а не глобальный недостаток.
Подозреваю что в iptables не сработает потому что -t nat -A PREROUTING, хотя не проверял и могу ошибаться.
В любом случае ничто не мешает обрабатывать правила NAT до маршрутизации и то что некоторые делают это после — это их личная проблема, а не глобальный недостаток.
UFO just landed and posted this here
А мне кажется, что сработает. Основная проблема — это чтоб у нас был определенный source port. Нужно так долбиться до тех пор, пока мы его не получим, вот и все.
Да нет, POSTROUTING. Но кто ж делает forward с WAN-интерфейса без --state RELATED,ESTABLISHED?
Параноя детектед
Лучше быть параноиком чем оправдываться что сеть сламали из-за «я не знал что это возможно».
Правилом хорошего тона является запрещать трафик из серых подсетей на внешних интерфейсах.
Во — первых трафик не из серых сетей а на серые сети.
А на счёт паранойи — отнюдь нет.
Любую информацию можно использовать по разному, к примеру задайте такой вопрос на собеседовании с претендентом. Если даже он не ответит, посмотрите, загорятся ли у него глаза, когда скажете про маршрут от провайдера. Поверьте, его реакция может о многом про него рассказать…
А на счёт паранойи — отнюдь нет.
Любую информацию можно использовать по разному, к примеру задайте такой вопрос на собеседовании с претендентом. Если даже он не ответит, посмотрите, загорятся ли у него глаза, когда скажете про маршрут от провайдера. Поверьте, его реакция может о многом про него рассказать…
UFO just landed and posted this here
Собственно, это недостаток схемы «разрешено все, что не запрещено». Такой финт с прохождением пакетов можно и на iptables увидеть (кажется удивительно, а на самом деле надо просто проштудировать порядок прохождения таблиц и цепочек пакетом).
Вот буквально сейчас на iptables с политикой «запрещено все, что не разрешено» прокинул порт на внутренний адрес, а доступа нет. А почему? А потому что в таблице NAT прероутинг сработал, а вот в таблице FILTER (с политикой DROP) прохождение я не разрешил.
Честно говоря, с циской особо не работал, но вот для 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. Но наш пограничный роутер все равно знает, что они доступны через внешний интерфейс :)
У нас есть один провайдер такой. Из нашей внутренней сети можно пинговать сети 192.168.XX.0/24. Пакеты на эти сети шли через наш внешний адрес на маршрутизатор провайдера. Причем раньше от одного хоста даже ответ приходил :) Когда я написал об этом провайдеру (и приложил трассировку), он попросил (внимание!) скриншот трассировки :) Выслал. Теперь из этих сетей приходит ответ Packet Filtered. Но наш пограничный роутер все равно знает, что они доступны через внешний интерфейс :)
Нет ничего не логичного. У маршрутизатора нет такого понятия как внутренний и внешний интерфейс. Все интерфейсы одинаковы.
Да как-то хотелось верить, что маршрутизатор обеспечивает хотя бы базовую защиту, а в реальности любой кто в подъезде подключился к вашему марширутизатору вместо провайдера, может отправлять пакеты вашим сервисам во внутренней сети.
Думаю, что такая потенциальная уязвимость актуальная для многих домашних пользователей и небольших организаций
Думаю, что такая потенциальная уязвимость актуальная для многих домашних пользователей и небольших организаций
UFO just landed and posted this here
Да, это круто, и при SSRR это сработает, если вначале протрейсить маршрут, а потом задать список хопов жестко.
Спасибо за статью!
Спасибо за статью!
Вообще-то «no ip source-route» написаны большими буквами во всех best practice.
Но это, конечно, не отменяет утверждения, что NAT это не мера безопасности.
Но это, конечно, не отменяет утверждения, что NAT это не мера безопасности.
Спасибо, интересно. Плюсанул топик до 100 :)
хорошая статья и полезная для многих… особенно для тех кто подумал, что находится в безопасности скрываясь за натом и строго контролируя трансляции внутрь своей сети :)
Теперь понятно почему в примерах для файрвола указывают адрес внешнего интерфейса:
pass in on $ext_if proto tcp to ($ext_if) port { ssh, www }
всегда думал, что это лишнее, как оказывается не зря.
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.
вот, кстати, кусочки входящих аксесс листов на одном маршрутизаторе:
со стороны аплинка:
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 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 перестает работать инет во всей внутренней сети :-(извините, я здесь показал пример клиента с публичным (белым) адресом, которых у меня абсолютное большинство, за редким исключением… то есть в вашем случае этот ацл нужно применить немного раньше, до вашего интерфейса во внутренней сети, или изменить его в зависимости от использованной адресации в своей локальной сети :)
Интересный сценарий, спасибо за статью.
Но, очевидно, что реализации этого сценария слишком много условий должно выполняться: везде по дороге должен быть включен source routing, на граничных маршрутизаторах должен быть разрешен трафик к серым сеткам (чтобы послать «инициализирующий пакет»), ну и не должно стоять никаких фильтров у самого клиента (что глупо, но в этом и суть статьи :).
Но, очевидно, что реализации этого сценария слишком много условий должно выполняться: везде по дороге должен быть включен source routing, на граничных маршрутизаторах должен быть разрешен трафик к серым сеткам (чтобы послать «инициализирующий пакет»), ну и не должно стоять никаких фильтров у самого клиента (что глупо, но в этом и суть статьи :).
Sign up to leave a comment.
NAT не firewall, повторим еще разок