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. Т.е. выцепили из потока нужные пакеты и повесили на них ту или иную маркировку, благодаря которой эти пакеты уже можно приоритезировать или наоборот притормаживать.  Чтобы перевести описание в практическую плоскость, зададимся конкретными целями.


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

Cisco Lightweight AP + WLC. Немного о взаимодействии точек доступа с контроллером.

Когда-то во время изучения писаний о беспроводном доступе, натыкался на проблему того, что сразу слишком много деталей, при том, что общая картина еще не сформировалась. Вот, в частности, читая о том, как lightweight точки доступа работают с контроллером точек доступа (WLC), мне не было до конца ясно через какой VLAN точки вешаются на контроллер, в какие интерфейсы контроллера включаются в LAN, как клиенты, подключающиеся к точкам попадают в нужный им VLAN, предназначенный для беспроводного доступа (через контроллер или сами и если через контроллер, то как?), как они получают IP адреса и пр. Пришел к выводу, что мне тогда помогла бы подобная картинка (click to enlarge):

Взаимодействие беспроводного контроллера с точками доступаНу и краткое описание.

Во первых, контроллер и точки доступа в данном случае включены в сеть всего одним физическим интерфейсом. Тут есть несколько VLANов, но физический интерфейс — один (это не обязательно должно быть так, но здесь так).

У контроллера, на этом одном физическом интерфейсе настроено два VLAN-а:

— VLAN 1 — это основной VLAN корпоративной сети и в нем находится много защищаемых ресурсов, к которым у беспроводных клиентов (тем более — гостей) доступа быть не должно.

— VLAN 2 — это как раз VLAN для беспроводных клиентов, который, через межсетевой экран, имеет доступ в Интернет, равно как и все, кто в этом VLAN-е сидит.

Теперь, последовательно, но достаточно поверхностно, дабы лишними деталями не усложнять понимание.

Точки доступа, которые находятся с контроллером в одном VLAN-е (VLAN 1), после включения в сеть и подачи на них питания (PoE), получают от DHCP сервера в VLAN 1 (на схеме не показан) некий IP адрес, а также, в DHCP опции 43, адрес контроллера, к которому им нужно подключиться. Например, точка А получила IP 10.200.0.33/24, а контроллер имеет IP 10.200.0.10/24. Точка инициирует подключение к контроллеру и после того как они друг с другом пообщались между ними, внутри VLAN 1, устанавливается CAPWAP туннель, через который передается вся информация, касающаясе беспроводного взаимодействия.

Теперь, когда связь между точками LAP и WLC установлена, посмотрим что происходит с трафиком от беспроводных клиентов.

Для простоты считаем, что беспроводным клиентам нужен только доступ в интернет, при этом доступ в локальную сеть предприятия для них должен быть закрыт. Опуская детали того, как клиент ассоциируется с беспроводной сетью (dot1x или иные способы аутентификации и авторизации на контроллере), смотрим как идет трафик от клиента в интернет.

Сначала пакеты по воздуху попадают на точку доступа, которая аккуратно упаковывает их в CAPWAP заголовки и отправляет контроллеру вместе с информацией о том, к какому SSID подключен данный конкретный клиент (т.к. на одной точке может висеть множество SSID). Контроллер получает CAPWAP пакет, извлекает его содержимое (т.е. расшифровывает и снимает CAPWAP заголовки) и по SSID, о котором сообщила ему LAP, делает вывод о том, в какой VLAN нужно его отправить. Т.е. у контроллера есть соответствие, как например: SSID INTERNET = VLAN 2. Так, контроллер отправляет уже чистый IP пакет от беспроводного клиента в VLAN 2, которая у него висит на том же физическом интерфейсе, что и VLAN 1.  Попав в VLAN 2 клиент получает IP адрес из пула для беспроводных клиентов (на схеме показан отдельным сервером), например, 10.200.1.10/24, и имеет доступ в разрешенные для него на МСЭ внешние сети.

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


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

Как заблокировать TeamViewer или практическое применение Cisco FPM

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

Немного теории

Теории на эту тему хватает, но все же еще раз, ну на всякий случай. Для тех кому лень читать, и нужно тупо заблокировать TeamViewer – готовый конфиг в конце статьи.

FPM (Flexible Packet Matching) — реализованная в IOS технология,  позволяющая идентифицировать трафик по содержанию полей в заголовках и payload пакетов. По сути своей – аналогична ACL, но не имеет ограничений по тому, какую часть пакета можно матчить. В случае с  ACL  —  это три поля в заголовке IP:  Source IP Address, Destination IP address, Protocol  + 2 поля в заголовке TCP/UDP: Source Port , Destination Port (ну или type/code для ICMP).  В случае с FPM матчить можно по любому биту пакета.

Нужно обратить внимание, что FPM ну совсем никак не statefull, не анализирует всю сессию, не анализирует фрагменты, не анализирует пакеты с IP Options. Излишние детали по ограничениям опущу, они все прекрасно описаны на cisco.com.  FPM для анализа нужен один пакет со всеми заголовками, поскольку, опираясь на эти заголовки и смещения относительно них, и строятся правила. ИМХО – аналогично Atomic IP engine в Cisco IPS, но с большими возможностями.


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

Cisco + S-terra NME RVPN иVPN Gate 1000. Защищенная DMVPN сеть с российскими алгоритмами шифрования.

Настало время это описать. Через силу, но надо.

Текст о том, как на оборудовании Cisco и S-Terra построить большую отказоустойчивую DMVPN сеть с шифрованием ГОСТ.

Чтобы содержание имело смысл нужно быть в курсе таких понятий как IPSec, GRE, GRE over IPSEC, DMVPN и других к ним относящихся. Какое-то понимание можно получить отсюда.

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

Для большой и разветвленной сети VPN очень удобно использовать оборудование Cisco с их замечательной технологией DMVPN  со всеми ее преимуществами. Ограничение здесь в том, что Cisco, естественно, не поддерживает российских алгоритмов шифрования. Для исправления этого недостатка были придуманы модули NME RVPN, производимые компанией S-Terra. Модуль вставляется в маршрутизатор Cisco Серии 2900 и трафик, который нужно шифровать, пропускается через него. Вместо NME RVPN могут быть использованы отдельные устройства – криптошлюзы (VPN Gate 100, 1000, 3000), выполняющие ту же самую функцию и отличающиеся характеристиками производительности.


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

MS Exchange NLB Multicast mode with HP Procurve switches

Flood NLB ExchangeВесь текст с точки зрения сетевого специалиста, а не администратора Microsoft Exchange и серверов Windows. Здесь все, что касается сути проблемы и ее решения на сетевом уровне.

Проблема

Кластер Exchange включает в себя три сервера, которые для избыточности используют NLB в режиме unicast. Режим прекрасен тем, что сетевая карта каждого из трех серверов  отвечает на один и тот же MAC-адрес, который присвоен NLB кластеру. Как результат — все свитчи в LAN сходят с ума, т.к. они не в состоянии заполнить свою CAM-table и вынуждены флудить весь трафик до кластера через все свои порты (кроме того, на который пакет пришел). И это ужасно. В нашем случае вышло что каждый хост в сети постоянно ловит около 10Мбит/сек юникастового флуда, который этому хосту не предназначен, а который интересен только серверу Exchange. У нас даже есть несколько IP-телефонов, подключенных к 10Мбит/сек интерфейсам, которые сразу почувствовали неладное, т.к. для них «места в проводе» не осталось — это, кстати, и заставило копать что не так.

Решение

Наименее трудоемких/затратных решений — два.


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

Заодно посмотрите мои фоты в моем профиле вконтакте. Любые вопросы по существу статей можете задать там же.

Hostenko — лучший WordPress-хостинг