Cisco Network Based Application Recognition (NBAR)

cisco_nbarNBAR, аки видно из названия, призван понимать или пытаться понять какому протоколу принадлежит трафик, пролетающий через интерфейс маршрутизатора. Основное назначение — классификация трафика по конкретным протоколам прикладного уровня. Обычный ACL тоже в состоянии классифицировать трафик, но максимум, что он для этого может использовать — это IP адреса, и номера портов tcp и udp. Например, нечто лезет на порт 80 TCP. с точки зрения ACL это скорее всего http, т.к. исторически именно http использует порт 80. Больше ACL сказать нечего в принципе. NBAR же, может показать, что это не просто http, а http трафик канала youtube, или что это вообще не http, а какой-нибудь yahoo-messenger или торрент-клиент, пытающийся вылезти через, как правило, открытый порт. Что можно сделать имея эту информацию? Ну, можно понаделать всяких пакостей для пользователей, что-нибудь избирательно для них заблокировав, хотя идеалогически NBAR больше относится к плоскости QoS. Т.е. выцепили из потока нужные пакеты и повесили на них ту или иную маркировку, благодаря которой эти пакеты уже можно приоритезировать или наоборот притормаживать.  Чтобы перевести описание в практическую плоскость, зададимся конкретными целями.

Итак, нужно:

— ограничить пропускную способностью трафика youtube 1.5 Mbit/sec. Теперь пользователи не смогут сожрать всю полосу пропускания интернет-канала организации (которая, скажем, составляет 30 Mbit/sec) просмотром видеороликов. Да, 1.5 — это ни о чем, ни никто на практике так не сделает, так как это — ну совсем мало, но для примера — самое оно.

— вообще запретить использование мессенджера yahoo, потому что у нас, например, этот мессенджер вообще запрещен политикой информационной безопаснности.

— и не трогать обычный http трафик.

Т.е. вроде бы все работает по 80 порту, но политики для разных приложений разные. Удобно и полезно.

Итак, для построения политик инспектирования трафика используется т.н. C3PL фреймворк или MQS (Modular Quality of Service). Сначала с помощью class-map классифицируем трафик по описанным выше критериям:

Теперь, с помощью policy-map, непосредственно прописываем, что мы будем делать с трафиком, который попадает под каждый class-map.

Тут все наглядно и не требует объяснения — выбрали трафик и сказали что с ним делать. Строка police в MATCH_YOUTUBE означает, что максимальная полоса пропускания для этого класса трафика (youtube) составляет 1500000 бит/сек (1.5 Мбит/сек), как и планировалось, и что допускается на короткие промежутки времени превышать этот придела на 10 кбит/сек.

Теперь вешаем созданную политику, например, на внеший интерфейс, который смотрит в сторону провайдера:

С этого момента весь трафик, проходящий через интерфейс Gig0/2 во входящем направлении инспектируется в соответствии с примененной политикой. Запустим на любом ПК youtube и откроем любое видео в HD качестве, попереключаемся между разными видеороликами. Через некоторое время ютуб начинает подторжмаживать. Посмотрим на счетчики:

Видно что примененная политика работает и что аж 277 пакетов были благополучно уничтожены, т.к. прилетели после того, как полоса пропускания уже была забита.

Тест блокировки yahoo-messenger в моем случае завершился неудачей. Этот друг нормально подключился к серверу и счетчики ничего не показали. Вероятно, причина в том, я использовал для теста маршрутизатор с IOS  двухлетней давности, на котором NBAR также не обновлялся (посредством PDLM). Соответственно, yahoo, видимо, эволюционировал, а текущая версия NBAR еще об этом не знает.

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

Как работает NBAR?

Да,  есть и эвристический анализ, который иногда позволяет идентифицировать даже шифрованный трафик, но, по большей части, это сигнатуры. Инспектируется не весь трафик, проходящий через маршрутизатор, а только некая его подозрительная часть. Сначала наблюдаются порты, характерные на данный момент времени для конкретного протокола. Какие протоколы ищутся на каких портах можно увидеть с помощью команды show ip nbar port-map. Для IOS  15.1(2)T3 и его нативного NBAR движка увидим следующее:

Итак, NBAR смотрит за трафиком, идущим на определенные tcp и udp порты. Это фильтр в крупную клетку. Когда нечто попалось, как в примере выше, на порту tcp 80, NBAR начинает копать глубже, дабы понять, что это за приложение из тех, что ему на данный момент известно. Как оказалось из примера выше, этот NBAR о youtube еще кое что знал, а о yahoo messenger уже не очень.

Чтобы обновить NBAR не обязательно обновлять IOS целиком. Загрузить актуальную версию NBAR можно посредством установки новых PDLM пакетов — это файлы, которые описывают тот или иной протокол (по сути, сигнатуры, для каждого протокола  — свой PDLM):

Или, если IOS более актуален, можно сразу установить application pack, который сразу содержит все возможные PDLM (т.е. PDLM для каждого протокола, с которым может работать NBAR):

Да, еще NBAR — statefull, т.е. он не просто смотрит на каждый пакет в отдельности, а инспектирует traffic-flow в обе стороны, и может приняти решение о принадлежности трафика к тому или иному протоколу ни по одному пакету (т.к. иногда этого сделать невозможно), а по результату наблюдению за обменом пакетами в рамках сессии.

Сейчас актуальным является NBAR2 — тот же NBAR, только знает больше протоколов и использует более гранулярный подход для выбора трафика, подлежащего инспектированию.

Еще NBAR/NBAR2 есть основа, т.е. ядро той штуки, которая у Cisco называется модным словом AVC — Application Visibility and Control. Вещь, которая призвана сделать сети Application Aware, т.е. понимающими приложения. AVC применяется в ряде устройств и совсем не обязательно это должен быть маршрутизатор. Вот, напрмер, скриншот с нашего беспроводного контроллера Cisco 5508 WLC, который обслуживает множество lightweight точек доступа:

Cisco AVC

Это список приложений, которые этот контроллер «понимает». По бегунку справа видно, что перечень более чем обширен. Для инспекции пакетов применяется тот же самый NBAR2.  Каждое приложение из списка можно выбрать и: 1. запретить; 2 повесить QoS маркировку, которую позже другие сетевые устройства будут использовать для приоритезации трафика. Например, можно задать приоритет голосовому SIP трафику:

Cisco AVC apply

Или, убить тот же многострадальный youtube (что ни есть хорошо:)):

Cisco AVC apply_2А, да, еще забыл про ISR. На роутере можно включить функцию nbar protocol discovery. Команда вешается на интерфейс. В этом случае роутер просто будет мониторить весь трафик, проходящий через его интерфейс(ы), и собирать статистику по приложениям.

Теперь интерфейс Gig0/0 стал совсем внимательым.

Посмотрим что он насобирал:

ip_nbar_protocol_discoveryНа этом, думается, пока хватит.


Не забывайте оставлять комментарии, если пост был вам полезен!
Опубликовано в Сети Метки: , , ,

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Заодно посмотрите мои фоты в моем профиле вконтакте. Любые вопросы по существу статей можете задать там же.
Hostenko — лучший WordPress-хостинг