antiCisco blogs


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

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

Кроме вышеперечисленных типичных трансляций встречаются еще и необычные задачи. Рассмотрим два случая, не перечисленных в предыдущих частях

1. Трансляция адресов между интерфейсами с одинаковым уровнем безопасности.
Напомню, что по умолчанию передача пакетов между такими интерфейсами запрещена, однако если разрешить, то между такими интерфейсами возникает обычная маршрутизация. Даже если включено строгое правило 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 🙂

Ну и ещё один вариант предлагает 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). Она опасна тем, что не несет полезной нагрузки, но отжирает память сервера, на который пришёл запрос. Этим и пытаются воспользоваться хакеры, подделывая адрес источника и посылая с него множество запросов, заставляя сервер отвечать «в никуда» и расходуя память.
Опишем ещё раз схематически, как происходит установление сессии (так выглядят заголовки пакетов):

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 быстренько откроет сессию от имени запрашивающего с сервером (ведь она знает все параметры сессии), разницу между init.seq.server, придуманного самим сервером, и hash[IP_HEADER] ASA запомнит и будет добавлять при прямом проходе к Seq_number и вычитать из Ack_number. Таким образом, трафик по этой сессии будет ходить сквозь ASA транзитом, почти без вмешательства.
Вот такая ASA злобная спуферша 🙂 Правда, на благо вам 🙂

Важно: добавление дельты в init.seq можно и иногда нужно отключать.

Предыдущая статья SNAF <<< >>> Следующая статья SNAF

 

Метки: , ,
Опубликовано: Безопасность cisco

 

2 комментария “ASA. Статья 9. NAT. Часть 3. Нетипичные случаи и дополнительные возможности”

comment rss - Trackback

  1. Ilya:

    Сереж, сказал бы про same security traffic permit при трансляциях…

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

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