Кроме вышеперечисленных типичных трансляций встречаются еще и необычные задачи. Рассмотрим два случая, не перечисленных в предыдущих частях
1. Трансляция адресов между интерфейсами с одинаковым уровнем безопасности.
Напомню, что по умолчанию передача пакетов между такими интерфейсами запрещена, однако если разрешить, то между такими интерфейсами возникает обычная маршрутизация. Даже если включено строгое правило nat-conrol. Однако, это не значит, что между такими интерфейсами нельзя транслировать адреса. Для этого мы используем обычный формат внутренних (inside) динамических и статических трансляций
2. Трансляция адресов на одном интерфейсе.
Еще большей экзотикой является трансляция адресов пакетов, приходящих и уходящих с одного и того же интерфейса. Напомню, что и такая ситуация по умолчанию запрещена. Но можно разрешить. Примером такой топологии может служить случай, когда вы подключаетесь снаружи к ASA по туннелю IPSec и хотите сквозь этот туннель выходить через ASA в Интернет, используя , например, адрес внешнего интерфейса ASA. В этом случае с точки зрения ASA пакет IPSec приходит, расшифровывается на внешнем интерфейсе и далее ASA по табличке маршрутизации должна опять отправить его через внешний интерфейс.
Напомню, что по умолчанию передача пакетов между такими интерфейсами запрещена, однако если разрешить, то между такими интерфейсами возникает обычная маршрутизация. Даже если включено строгое правило nat-conrol. Однако, это не значит, что между такими интерфейсами нельзя транслировать адреса. Для этого мы используем обычный формат внутренних (inside) динамических и статических трансляций
2. Трансляция адресов на одном интерфейсе.
Еще большей экзотикой является трансляция адресов пакетов, приходящих и уходящих с одного и того же интерфейса. Напомню, что и такая ситуация по умолчанию запрещена. Но можно разрешить. Примером такой топологии может служить случай, когда вы подключаетесь снаружи к ASA по туннелю IPSec и хотите сквозь этот туннель выходить через ASA в Интернет, используя , например, адрес внешнего интерфейса ASA. В этом случае с точки зрения ASA пакет IPSec приходит, расшифровывается на внешнем интерфейсе и далее ASA по табличке маршрутизации должна опять отправить его через внешний интерфейс.
Несмотря на странный дизайн, настройка такой трансляции не сложна, хотя и непривычна:
nat (out) 10 {IPSECLAN}
global (out) 10 interface
Аналогично можно и статическую трансляцию описать:
static (out,out) {translated_address} {real_address}
К дополнительным возможностям можно отнести технологию DNS Doctoring.
Частенько возникает ситуация, когда вы пользуетесь внешним ДНС-сервером и пытаетесь попасть на свои же локальные сервера по имени.
Частенько возникает ситуация, когда вы пользуетесь внешним ДНС-сервером и пытаетесь попасть на свои же локальные сервера по имени.
Понятно, что сервер вернет глобальный адрес сервера, а не частный. Что делать?
Первое, что можно предложить, это использовать локальный ДНС-сервер и создать в нем новую зону типа .local. Тогда обращение на сервер сначала будет разрешаться в локальной зоне и лишь затем в глобальной.
Также можно воспользоваться локальным файлом hosts (для Windows %WINDIR%\system32\drivers\etc\hosts). Что довольно не удобно при количестве машин больше 1
Первое, что можно предложить, это использовать локальный ДНС-сервер и создать в нем новую зону типа .local. Тогда обращение на сервер сначала будет разрешаться в локальной зоне и лишь затем в глобальной.
Также можно воспользоваться локальным файлом hosts (для Windows %WINDIR%\system32\drivers\etc\hosts). Что довольно не удобно при количестве машин больше 1
Ну и ещё один вариант предлагает ASA: надо подслушивать ДНС запросы клиентов и в ДНС-ответах заменять глобальный адрес сервера на его реальный (частный) адрес. Для этого ASA анализирует строчки static в конфигурации и если видит в ДНС-ответе GLOB_IP, сразу же меняет его на LOCAL_IP
Делается это так:
nat (ins) # {условие} dns
static (dmz,out) GLOB_IP LOCAL_IP dns
Слово dns надо указывать у всех строк static, которые мы бы хотели подменять.
Еще одной технологией, упомянутой ранее, является защита от DoS-атаки SYN Flood (массовая заливка запросов на открытие ТСР сессии как правило с поддельных адресов источника). Технология называется SYN Cookie
Для того, чтобы разобраться с этой технологией, сначала опишу, как ASA обрабатывает ТСР-сессии, проходящие сквозь нее.
В пакете запроса на открытие ТСР-сессии, как вы без сомнения знаете, посылается единственный флаг SYN, а также поле «начальный номер сегмента» (initial sequence number).
В пакете ответа на это запрос приходит уже 2 метки: SYN и ACK и 2 поля – начальный номер сегмента соседа и подтверждение получения вашего начального номера (acknowledgement). Третьим пакетом ТСР сессии является окончательное подтверждение запрашивающим всех параметров. Там идёт только флаг ACK и поля: начальный номер сегмента+1, подтверждение получения соседского номера сегмента. Такая сессия называется установленной. Если какой-то из этих шагов не выполнен, то такая сессия называется «зародышем» или «полуоткрытой» (embryonic). Она опасна тем, что не несет полезной нагрузки, но отжирает память сервера, на который пришёл запрос. Этим и пытаются воспользоваться хакеры, подделывая адрес источника и посылая с него множество запросов, заставляя сервер отвечать «в никуда» и расходуя память.
Опишем ещё раз схематически, как происходит установление сессии (так выглядят заголовки пакетов):
Для того, чтобы разобраться с этой технологией, сначала опишу, как ASA обрабатывает ТСР-сессии, проходящие сквозь нее.
В пакете запроса на открытие ТСР-сессии, как вы без сомнения знаете, посылается единственный флаг SYN, а также поле «начальный номер сегмента» (initial sequence number).
В пакете ответа на это запрос приходит уже 2 метки: SYN и ACK и 2 поля – начальный номер сегмента соседа и подтверждение получения вашего начального номера (acknowledgement). Третьим пакетом ТСР сессии является окончательное подтверждение запрашивающим всех параметров. Там идёт только флаг ACK и поля: начальный номер сегмента+1, подтверждение получения соседского номера сегмента. Такая сессия называется установленной. Если какой-то из этих шагов не выполнен, то такая сессия называется «зародышем» или «полуоткрытой» (embryonic). Она опасна тем, что не несет полезной нагрузки, но отжирает память сервера, на который пришёл запрос. Этим и пытаются воспользоваться хакеры, подделывая адрес источника и посылая с него множество запросов, заставляя сервер отвечать «в никуда» и расходуя память.
Опишем ещё раз схематически, как происходит установление сессии (так выглядят заголовки пакетов):
0. Source_ip|Dest_ip|Source_port|Dest_port|FLAGS|Seq_number|Ack_number
1. Client_ip|Server_ip|Client_tcp_port|Server_tcp_port|SYN|init.seq.client|0
2. Server_ip|Client_ip|Server_tcp_port|Client_tcp_port|SYN,ACK|init.seq.server|init.seq.client+1
3. Client_ip|Server_ip|Client_tcp_port|Server_tct_port|ACK|init.seq.client+1|init.seq.server+1
У ASA по умолчанию включена защита от старенькой атаки подделки третьего пакета сессии. Старые реализации стека TCP/IP ставили
init.seq.client=0 ASA же добавляет некоторую случайную дельту кinit.seq.client. А для того, чтобы клиент и сервер все же могли установить сессию, ASA вычитает эту дельту из поля Ack_number обратного пакета
Мы бы хотели не допустить массовых обращений со стороны хакеров, но при этом не блокировать нормальных пользователей.
Как вы видите, кое-что в заголовке остается неизменным. Этим и пользуется ASA. Если на ней включить технологию SYN Cookie, ASA будет перехватывать запросы на открытие сессии на сервер и отвечать от себя. Вся соль технологии в том, что в качестве
init.seq.server ASA поставит не просто так число, а некий хэш (или cookie) частей заголовка, которые не меняется для данной сессии.
Init.seq.server=hash[IP_HEADER]
Значение этого хэша от 0 до 65535. Далее ASA отправит этот пакет запрашивающему и забудет про него. Если запрашивающий был хакером, то третьего пакета не будет вообще, а если же он вдруг оказался нормальным пользователем, то при получении пакета ACK ASA снова вычислит
Hash[IP_HEADER] и сравнит его с полем ACK_NUMBER пришедшего пакета. Если все хорошо, то должно выполняться равенство
Hash[IP_HEADER]= ACK_NUMBER-1
Если так и есть, то после этого ASA быстренько откроет сессию от имени запрашивающего с сервером (ведь она знает все параметры сессии), разницу между
Вот такая ASA злобная спуферша Правда, на благо вам
init.seq.server, придуманного самим сервером, иhash[IP_HEADER] ASA запомнит и будет добавлять при прямом проходе к Seq_number и вычитать из Ack_number. Таким образом, трафик по этой сессии будет ходить сквозь ASA транзитом, почти без вмешательства.Вот такая ASA злобная спуферша
Правда, на благо вам
Важно: добавление дельты в
init.seq можно и иногда нужно отключать.
Источник: anticisco.ru/blogs/2010/02/asa-статья-8-nat-часть-3-нетипичные-случаи-и-д/
Комментариев нет:
Отправить комментарий