ASA. Статья 15. Глубокое исследование протоколов (Advanced Protocol Handling)

Протоколы, которые мы используем в повседневной жизни, не всегда используют одну сессию для своей работы (когда весь обмен данными происходит по одной сессии TCP или UDP). Примерами таких «сложных» для МСЭ протоколов являются FTP, SIP, SCCP, H.323, и многие другие. Все приведенные протоколы используют для служебной информации одно соединение, а для передачи данных – другое. Например, популярный протокол SIP устанавливает служебную сессию на ТСР/5060 с SIP-сервером. Но голосовой поток идет от одного телефона до другого напрямую. Но этого мало: поток идет по паре случайных портов UDP с заголовком RTP (cisco использует для портов источника и назначения пару из диапазона [16384–32767], другие производители могут использовать другие диапазоны, например 2000-65535 или вовсе любые порты UDP из верхнего диапазона портов: 1024-65535). Вот в таких нечеловеческих условиях МСЭ, который стоит на пути прохождения служебного и голосового трафика, должен обеспечить работу не только служебного протокола, но и пропустить голосовой поток. И сделать это безопасно. А значит, МСЭ должен узнать, что за порты будут использовать телефоны для прямого соединения, и какой ip-адрес у локального и удаленного телефонов. Благо, эта информация передается по служебному каналу TCP/5060 при помощи специальных сообщений. Вот эти сообщения и может подслушивать МСЭ. А подслушав МСЭ, может поместить такую сессию в кэш сессий заранее! Вы, конечно, помните, что когда приходит пакет, ASA его сначала проверяет в кэше сессий и только потом по входящему списку доступа.

Для каждого сложного протокола надо знать структуру его сообщений и уметь использовать их для корректной и безопасной работы МСЭ. Глубокое инспектирование подразумевает собой разбор протокола до 7 уровня модели OSI. Понятно, что такой разбор требует затрат CPU и не малых. Поэтому включать инспектирование всех доступных протоколов «на всякий случай» не рекомендую.

Отдельно упомяну возможность разбирать до уровня приложений одноканальные, но очень распространенные протоколы HTTP, SMTP и некоторые другие. Для их работы не требуется открывать новые порты на МСЭ, но часто критерием для удаления того или иного пакета выступает параметр самого протокола. Например, «неугодный» URL, тип вложения, домен, тип подключающегося клиента и т.д. Тут тоже требуется знание структуры протокола, его сообщений и передаваемых данных. Все это умеет анализировать ASA и сейчас мы познакомимся с тем, как это настроить.

Для начала, надо отобрать пакеты для инспектирования. Как было показано в предыдущей главе, сделать это можно, указав в качестве критерия в классе трафика ключевое слово

Asa(config-cmap)# match default-inspection-traffic

Оно означает «в класс попадает весь трафик, который ASA умеет глубоко анализировать». Напомню, что посмотреть, какие протоколы и по каким портам в данной версии ОС будут попадать в этот класс, можно подглядеть, если в режиме настройки класса трафика дать вопросик:

Asa(config-cmap)# match ?
mpf-class-map mode commands/options:
default-inspection-traffic Match default inspection traffic:
               ctiqbe----tcp--2748 dns-------udp--53
               ftp-------tcp--21 gtp-------udp--2123,3386
               h323-h225-tcp--1720 h323-ras--udp--1718-1719
               http------tcp--80 icmp------icmp
               ils-------tcp--389 mgcp------udp--2427,2727
               netbios---udp--137-138 radius-acct---udp--1646
               rpc-------udp--111 rsh-------tcp--514
               rtsp------tcp--554 sip-------tcp--5060
               sip-------udp--5060 skinny----tcp--2000
               smtp------tcp--25 sqlnet----tcp--1521
               tftp------udp--69 waas------tcp--1-65535
               xdmcp-----udp--177

Если мы используем класс, куда пакеты попадают по критерию default-inspection-traffic, то для такого класса в политике мы можем применить некоторое количество указаний на глубокое инспектирование.

policy-map {PMAPNAME}
   class {CLASSNAME}
     inspect {PROTO}

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

Рассмотрим подробнее, какие протоколы ASA в версии 8.2 может глубоко анализировать

Asa(config-pmap-c)# inspect ?
mpf-policy-map-class mode commands/options:
   ctiqbe
   dcerpc
   dns
   esmtp
   ftp
   h323
   http
   icmp
   ils
   im
   ipsec-pass-thru
   mgcp
   mmp
   netbios
   pptp
   rsh
   rtsp
   sip
   skinny
   snmp
   sqlnet
   sunrpc
   tftp
   waas
   xdmcp

Здесь можно выделить несколько групп «сложных» протоколов:
1. Протоколы, которые работают не по TCP или UDP. Сюда относятся: РРТР (передача данных идет по GRE, 47/IP), IPSec-pass-thru (передача идет по протоколу ESP, 50/IP), ICMP и др.
2. Многопотоковые протоколы. Сюда относятся телефонные протоколы SIP, SKINNY, MGCP, CTIQBE, RTSP; протоколы передачи файлов FTP, TFTP; протокол управления RSH и др.
3. Одноканальные протоколы, которым требуется пристальное внимание. Сюда относятся HTTP, ESMTP, DNS, SNMP и др.

Часто возникает задача анализировать протокол, который идет не по стандартному порту. Яркий пример – работа HTTP через прокси-сервер. Для подключения к прокси-серверу могут использоваться порты 3128, 8080 и вообще любые ТСР порты. Как быть в таком случае? Для глубокого анализа надо отобрать пакеты в класс по критерию «номер порта»

class-map {CLASSNAME}
   match port {tcp|udp} {eq|range} {PORTNUMBER}

Где:
eq – равно
range – диапазон портов

Примечание: можно написать список доступа, где перечислить при помощи указаний permit все необходимые пакеты и в качестве критерия указать его.

Указать в политике, как именно анализировать собранные пакеты:

policy-map {PMAPNAME}
   class {CLASSNAME}
     inspect {PROTO}

Например, добавим в глобальную политику анализ протокола HTTP по порту 3128

class-map NONSTHTTP
   match port tcp eq 3128

policy-map global_policy
   class NONSTHTTP
     inspect http
Так как инспектирование происходит на уровнях 5-7 модели OSI, то МСЭ вообще говоря все равно, каким образом (по какому порту) поступил на анализ пакет соответствующего протокола.

Кстати, перед тем, как читать дальше, попробуйте ответить себе на вопрос, имеет ли смысл и что означает просто включение инспектирования HTTP. Что проверяет ASA?

Ну да, все правильно: ASA проверяет, что по указанному порту действительно идет протокол HTTP, а не что-нибудь иное.

Остается только применить политику на интерфейс или глобально и инспектирование включено.

service-policy {PMAPNAME} {interface INTNAME | global}

Отмечу, что по умолчанию на ASA уже есть класс трафика inspection_default, куда попадают все доступные для инспектирования пакеты, политика global_policy примененная глобально и в ней уже указано для класса inspection_default анализировать ряд протоколов, в частности, FTP, SIP и др. Но не включено инспектирование HTTP, ICMP и других протоколов.

Включение инспектирования HTTP существенно увеличивает нагрузку на CPU ASA, поэтому рекомендую проверить уровень пиковой загрузки после включения такого инспектирования.
С выключенным инспектированием ICMP сквозь ASA не проходит даже простейший ping, traceroute в Windows-формате (когда запрос идет по icmp и ответ по icmp. В *nix-формате запросы идут по UDP) и весьма нужный протокол Path MTU Discovery. Это происходит из-за того, что с точки зрения МСЭ снаружи приходит неопознанный пакет (ICMP — не сессионный протокол и невозможно определить по заголовку, относится ли этот пакет к какому-либо запросу изнутри). При включении инспектирования ICMP МСЭ анализирует не только сам пакет, но и сообщения внутри пакета и может отделить ответы на запросы изнутри. Их-то он и пропускает. Остальное, следуя правилу по умолчанию, отбрасывает.

Примечание: понятно, что правило по умолчанию можно изменить, применив на внешний интерфейс список доступа с соответствующими разрешениями.

Повторю сказанное в предыдущей главе: в документации cisco написано, что при конфликте правил, примененных на интерфейсе и глобально, приоритет имеет интерфейсное правило. На практике же очень часто возникает ошибка: если для одного и того же соединения должно выполнится инспектирование согласно политике на интерфейсе и глобальной политике, инспектирование не производится вовсе! Поэтому моя рекомендация: не допускайте пересечения правил инспектирования в политиках интерфейсов и глобальной политике.

Итак, как включить или выключить базовый функционал инспектирования, разобрались. Но в начале главы было русским по белому написано, что есть еще и расширенный функционал, который позволяет много больше в рамках проверки пакетов на 7 уровне. Этот функционал ждите в следующей публикации.

Источник: anticisco.ru/blogs/2010/11/asa-статья-15-глубокое-исследование-прото/