Aruba Networks — Часть 2: Построение безопасной беспроводной инфраструктуры

Введение

Приветствую всех, кто читает этот пост!
Ранее я рассказывал про Aruba Networks в «общем виде», и там же обещал написать отдельный пост про аспекты безопасности. Сразу честно предупреждаю — пост большой. Сравнений с какими-либо вендорами не будет; цель поста — показать возможности конкретного вендора. Все описанные ниже возможности поддерживаются всеми контроллерами Aruba. Встречайте.

Сначала хотел написать просто пост-перечисление возможностей, с какими-то техническими подробностями. Но эта идея быстро разонравилась. Мне кажется, вместо сухого описания возможностей контроллеров, которые вы можете запросто прочесть в даташитах / маркетинговых материалах / сладкоречивых менеджеров по продажам / прочих лиц и материалов, будет гораздо интересней рассмотреть их на примере развертывания инфраструктуры. Давайте представим какую-нибудь абстрактную организацию, головной офис которой находится в Москве или Питере, имеющий филиалы как в крупных городах, где есть нормальный Интернет, так и в городах, где связь, мягко говоря, не работает в режиме 24/7. Но при этом есть необходимость в централизованном управлении и контроле работы оборудования. Схематично представим это так:

(Названия офисов взяты с потолка).
В офисе «Москва» мы имеем высокоскоростное постоянное соединение, а также офис, подключенный по LAN к нему; связь с другими офисами мы осуществляем с передачей данных через Интернет. В этом плане офис «Новосиб» ничего сверхинтересного из себя не представляет — у него также постоянное высокоскоростное соединение. Единственное что, надо обезопасить передачу данных через Интернет, плюс обеспечить централизованное управление и контроль из «Москвы».
Самый интересный офис — «Где-то на просторах России». Где, как известно, далеко не везде высокоскоростной Интернет. И не всегда есть устойчивая связь.

Как видно, данная инфраструктура практически не обладает отказоустойчивостью (за исключением офиса "Где-то на просторах России" и "мобильного офиса", об этом ниже. При вылете контроллера в головном офисе упадет (или будет ограниченная функциональность) в офисах "Новосиб" и соседним с "Москвой". Об аспектах построения отказоустойчивой инфраструктуры планирую рассказать в третьей части. 

Нам надо реализовать, за минимум средств и времени (как обычно, в общем-то…), с минимальным использованием дополнительного софта и «железа»:

1. Предоставить доступ к Интернету и корпоративной сети всем сотрудникам. Но при этом, доступ к конфиденциальным материалам есть только при условии использования сотрудниками определенных устройств и верных учетных данных. Сотрудникам, использующим свои устройства, запрещаем доступ к конфиденциальным данным.
2. Предоставить доступ к Интернету гостям организации. При этом, гости не должны иметь доступа корпоративным секретам.
3. Запретить подключение к «чужим» беспроводным сетям.
4. Обеспечить функционирование беспроводных VoIP телефонов.
5. Обеспечить функционирование беспроводной системы видеонаблюдения.
6. Соблюдение политики безопасности компании (нельзя подключаться к каким-то ресурсам Интернета).
7. Обеспечить функционал WIPS (Wireless Intrusion Prevention System — система предотвращения вторжений в беспроводную среду).
8. Возможность посмотреть, где находится интересующее беспроводное устройство на плане помещения.
9. Возможность назначения различных политик безопасности для различных офисов.
10. Возможность централизованного управления сетью.
11. Возможность быстрого создания мобильной беспроводной инфраструктуры — под политиками безопасности организации.

Далее мы посмотрим, как строится инфраструктура во всех этих офисах; я постараюсь пойти от «простого к сложному»: вначале идет рассказ о базовых возможностях, далее будем копать глубже. Т.е., все, что применимо в «Москве», применимо и в других офисах. То, что применимо в соседнем офисе, то применимо и в «Новосибе»; и т.д. Это утверждение работает и в обратную сторону, однако применение таких решений не всегда целесообразно.

Офис «Москва»

Здесь у нас находится контроллер, а также точки доступа (далее ТД), соединенные с ним по LAN. Помимо собственно контроллера беспроводной сети в головном офисе находятся и другие серверы, такие как сервер VoIP, контроллер домена, сервер авторизации и т.д. Контроллер может располагаться как в DMZ (и выступить в роли проводного маршрутизатора), так и за DMZ, но в этом случае нужно обеспечить видимость контроллера для ТД, использующих для связи с ним сети общего пользования.

Будут подняты следующие сети: гостевая сеть, дающая доступ через портал авторизации (captive portal), сеть для сотрудников организации с различным уровнем привилегий (уровень привилегий зависит от способа авторизации и/или конкретного логина), отдельная сеть для функционирования беспроводных VoIP-телефонов, отдельная сеть для функционирования беспроводных камер видеонаблюдения (естественно, для VoIP должен быть поднят какой-то сервер, например, Asterisk). Все эти сети будут работать как виртуальные ТД (каждая со своим BSSID).

Контроллер у нас выглядит примерно так:

А точка доступа такая:

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

1. Грузится контроллер (примерно 10 мин).
2. ТД находят контроллер, используя Aruba Discovery Protocol или по статическому IP контроллера.
3. Устанавливается соединение ТД-Контроллер с построением GRE тоннеля.
4. C контроллера ТД получает информацию: о служебных сетях, виртуальных сетях, политики безопасности и прочие параметры.
5. Можно подключаться!

Здесь необходимо примечание. При прописывании ТД в контроллер вручную (AP Provision) можно выбрать варианты "удаленная ТД" или "локальная ТД". Основное отличие - в типе туннеля, прокладываемого до контроллера. При автопрописывании ТД (с использованием Aruba Discovery Protocol) с настройками по умолчанию, ТД пропишется как локальная, будет строиться туннель GRE - с последствиями, что на "плохих" LAN могут быть потери больших пакетов. 

Сейчас у нас есть «чистый» контроллер. Ну, может, с выполненной первичной инициализацией — получили какую-то одну простую сеть. Аппаратно все функционирует. Нужно сделать безопасную инфраструктуру, удовлетворяющую вышеописанным требованиям.

Настраиваем инфраструктуру в офисе «Москва»

Это — самый долгий и ответственный этап. Здесь мы производим все настройки на контроллере. И подготавливаем плацдарм для легкого «поднятия» удаленных офисов.
Для начала мы создаем все необходимые VLANы. В нашем случае это будет:

Для упрощения, здесь создано 3 VLAN, причем через VLAN 1 проходит трафик в Интернет, и через него же проходит трафик от удаленных офисов, что не есть хорошо.
Далее создаем виртуальные точки доступа для VoIP, видео-наблюдения, гостевого доступа и для сотрудников. Тут есть варианты, можно создать с отдельным BSSID для каждой, можно построить SSID`ы на одной BSSID. ТД поддерживают, в основном, до 8 BSSID. Некоторые до 16. Точки доступа объединяются в группы; мы можем создать для разных офисов разные группы.
Далее, нам необходимо определиться со способом аутентификации и с ролями пользователей. Каждая роль обладает определенными правами доступа; можно создать дополнительные роли, например «сотрудник с корпоративного устройства» и «сотрудник с личного устройства», с разными правами доступа к сети.
Но, прежде чем кидаться в дебри настроек, необходимо понять, как все работает. Контроллер функционирует под своей ОС ArubaOS.

Немного про Aruba OS 6.1

Основная «разменная монета» тут — профиль. Профиль содержит в себе группу настроек, например, настройки протокола ААА или специфические настройки беспроводной сети. Условно, профили можно разделить на 2 большие группы: 1-я группа — профили, отвечающие за собственно функционирование беспроводной сети (сведения о SSID`ах, аппаратных настройках ТД, управление радиоокружением), функции предотвращения вторжения; и 2-я группа — профили, отвечающие за детальные настройки аутентификации и дополнительные возможности оборудования. Профили в каждой группе иерархические; т.е. если не будет какого-то профиля «ниже», то сеть не взлетит. В принципе, при начальной конфигурации контроллера (и дальнейшего использования мастера создания сетей) создаются все необходимые профили, так что основная масса работы приходится на редактирование уже существующие профилей. Чтобы было понятнее, приведу дерево профилей (взято из свободной документации на сайте Aruba Networks).
Дерево профилей функционирования БЛВС:

Дерево «прочих» профилей:

Нетрудно заметить, что в части аутентификации профили ААА ссылаются на профили из группы Other.

Фаервол «привязывается» тут через назначение политик на роли пользователей; роли пользователей назначаются по результатам аутентификации. Однако, вопрос аутентификации не так прозрачен, как кажется; это мы рассмотрим чуть ниже. Сейчас же кратко опишем фаервол. Фаервол представляет собой межсетевой экран сеансового уровня (stateful firewall), есть возможность обнаружения простых DOS-атак (SYN TCP, IP spoofing) с блокировкой атакующего устройства (на время или до ручного вывода из «черного списка» администратором). Поддерживает ipv4 и ipv6, «белые» списки доступа.
Настройка фаервола не представляет никаких трудностей: политики содержат набор простых правил; правило состоит из полей IP Version (версия протокола), исходящий источник (можно создавать свои источники), источник назначения (также можно создавать свои), сетевой службы (опять-таки сами создаются; «из коробки» есть большинство используемых сетевых служб), различные действия (принять, отклонить, туннелировать и т.д.), опции зеркалирования и протоколирования, приоритет правила и т.д. Есть возможность применять различные правила в политике в зависимости от времени/дня недели. Время берется с контроллера; это следует учитывать при создании временных диапазонов для объектов, находящихся в другой временной зоне.
Следует отметить тут один не очень приятный момент для некоторых, характерный для Aruba OS: на самом деле, настройки фаервола гораздо шире, чем это предоставляется веб-интерфейсом; при использовании CLI — можно задавать более тонкие настройки. Другой вопрос, что там настройки уже ближе к более тонкой маршрутизации трафика, и нужны далеко не всегда и далеко не всем. К CLI можно подключиться, как используя прямое подключение (в порт контроллера), так и через SSH/Telnet. В последнем случае есть возможность ограничить IP-адреса, с которых возможно подключение. Также в самом веб-интерфейсе есть возможность виртуальной Java-based CLI. Но это тянет за собой установку JRE, и к тому же (теоретически) подвержено всем уязвимостям Java. В общем, лучше, наверное, будет подключаться «традиционными» SSH клиентами типа Putty.
На этом предлагаю закончить экскурс в Aruba OS; какие-то технические подробности будут поясняться далее, по мере необходимости. Как работает тут фаервол, думаю, всем понятно; ничего нетривиального тут нет. Давайте разберемся, как же мы все-таки назначаем роли?

Аутентификация пользователей

Давайте сначала посмотрим на схему процесса аутентификации (заранее прошу прощения за нарисованную не по канонам блок-схему):

Здесь рассмотрена схема аутентификации с использованием машинной аутентификации. Это означает, что если устройство не авторизовано для использования в данной сети, то пользователь не получит полный доступ, даже в случае положительного ответа сервера аутентификации. Машинную аутентификацию можно реализовать, например, с помощью сертификатов — предусмотрены соответствующие элементы управления.
Разумеется, можно создавать и более упрощенные схемы аутентификации.
Данная схема работает следующим образом: у нас определены 3 роли: например, полный доступ, ограниченный (скажем, есть доступ к материалам, не содержащих конфиденциальные данные) и гостевой доступы. Естественно, что конфиденциальные материалы должны лежать на отдельных серверах; вопросы контроля конфиденциальных материалов выходят за рамки данного поста; мы их рассматривать сейчас не будем.
В зависимости от того, насколько прошла успешно аутентификация, предоставляются соответствующие роли. При назначении ролей есть некоторые нюансы, но в целом на процесс они влияют незначительно.
Доступные варианты аутентификации:

1. RADIUS
2. LDAP
3. TACACS+
4. NTLM (Windows)
5. 802.1Х
6. Внутренняя БД
7. Настраиваемый веб-портал (Captive Portal)
8. XML-API серверы (фактически, самописные коннекторы)

Внутренняя БД не очень рекомендуется для аутентификации; исключение — создание гостевых учетных записей. В Aruba OS довольно-таки удобный инструмент создания гостевых учетных записей, с возможностью автоматического уведомления о логине/пароле/имени беспроводной сети по email человека, для которого делается доступ. Гостевая учетка ограничена по времени действия, по истечению которого она автоматически отключается (но остается во внутренней БД; с одной стороны, это удобно, с другой — есть необходимость ручного удаления ненужных записей).
Основная причина, по которой не рекомендуется использование БД для аутентификации сотрудников — это ее невозможность интеграции (скажем так… условная невозможность, API, в общем-то, найти можно) с системами управления учетными записями; да и просто в этом случае администрирование системы становится более затратным. Зачем это, если можно взять данные, например, из AD?
Механизм аутентификации, я думаю, в целом уже понятен. Давайте перейдем к подсистеме WIPS (Wireless Intrusion Prevention System).

WIPS подсистема; отслеживание местоположения; протоколирование событий

В этом разделе опишу работу WIPS, которая тесно переплетена с системой RTLS (Real-Time Location System), которую косвенно можно отнести к системам, позволяющим обеспечивать физическую безопасность; причем для RTLS не надо устанавливать никаких дополнительных вычислительных комплексов. Единственное «НО»: вычислительных ресурсов контроллера недостаточно для отслеживания большого количества устройств; поэтому, если необходимо организовать постоянное наблюдение за клиентами и «вражескими» устройствами, лучше использовать ПО Aruba AirWave. Но это не обязательно.
Также для повышения общего уровня безопасности желательно ограничить подключение «чужих» устройств к нашим беспроводным сетям, а также запретить подключение устройств, находящихся в зоне действия «своей» сети к «чужим» беспроводным сетям. Для нормальной работы WIPS необходимо сначала указать параметры в профиле IDS, такие как — критерии, по которым обнаруженные устройства считаются «вражескими» (rogue), виды запрещенных соединений внутри контролируемой зоны (контролируемая зона — зона, которая покрывается нашими ТД) и т.д. Aruba может подавлять Ad-Hoc сети, создаваемые устройствами внутри контролируемой зоны, определять некорректные MAC-адреса (в то же время исключая известные MAC-адреса виртуальных устройств VMWare, например). При подключении контроллера к локальной сети появляется возможность контролировать и проводную часть сети, видимой контроллеру; контролирование это базовое — мы можем отследить подключение несанкционированного устройства и перекрыть ему доступ к проводному сегменту сети (при условии, что на контроллер дополнительно возложены функции маршрутизатора), либо выполнить оповещение администратора.

Часто возникает вопрос: насколько обосновано с правовой точки зрения подавление подключений (например, подавление Ad-Hoc сети, создаваемой сотрудниками для обмена, скажем, фотками с воскресной пьянки)? Можно использовать следующие положения Трудового кодекса: ст.91: Рабочее время - время, в течение которого работник в соответствии с правилами внутреннего трудового распорядка и условиями трудового договора должен исполнять трудовые обязанности, а также иные периоды времени, которые в соответствии с настоящим Кодексом, другими федеральными законами и иными нормативными правовыми актами Российской Федерации относятся к рабочему времени. И статья 57: Режим рабочего времени - обязательное условие трудового договора.  Иными словами, на работе нужно работать. Помимо этого, такой запрет можно явно прописать в политике безопасности организации. Формально, этого может хватить для обоснования подавления; на практике же этот вопрос зачастую оказывается глубже. 

Что же мы можем сделать в беспроводных областях? А вот что:

1. Обнаружить несанкционированное подключение и подавить его.
2. Обнаружить несанкционированную Ad-Hoc сеть, мост.
3. Обнаружить несанкционированную точку доступа.
4. Определить местоположение беспроводного устройства.
5. Подавить подключение к «чужим» сетям.
6. Подавить подключение «чужих» клиентов к своим сетям.

Обнаружение и расчет местоположения на плане помещения осуществляется за счет использования триангуляции; в качестве базовых станций с известными координатами выступают точки доступа, координаты которых известны. При этом точки доступа продолжают выполнять свои основные функции — собственно, предоставлять доступ к сети.
Для улучшения качества обнаружения можно использовать специальный режим работы ТД — AirMonitor. Он предназначен для контроля радиоэфира и выполнения служебных операций, таких, как оптимизация сети, обнаружение нелегальных устройств и т.д.; однако, при функционировании в этом режиме ТД перестает предоставлять доступ клиентам к сети. Стоит заметить, что в некоторых случаях можно создавать «гибридные» ТД: часть времени они работают в режиме AirMonitor, а часть времени — в штатном режиме.
«Вражеские» устройства ищутся в том диапазоне, в каком работает ТД. Поскольку большинство ТД может работать одновременно в диапазонах 2,4 и 5 ГГц, то мониторится оба диапазона. Ниже приведу табличку, какие каналы мониторятся (взята из свободно распространяемой документации):

После активации режима WIPS, контроллер с помощью ТД получает данные об окружающих устройствах и классифицирует их в соответствии с параметрами, настроенными в профиле IDS для каждой группы ТД. В зависимости от настроек профиля, возможно как автоматическое подавление подключений, так и просто отображение сведений о «вражеских» устройствах на панели мониторинга.
Подавление беспроводных устройств происходит с помощью технологии Tarpit Shield; суть этой технологии состоит в том, что «вражескому» клиенту навязывают подключение к заведому неверному BSSID либо каналу; совместно с этим происходит деассоциация (отключение) клиента от ТД нашей сети. При попытке подключения к «чужой» сети происходит перехват данных с последующим навязыванием ложного маршрута «на себя».
Со стороны пользователя это видится как бесконечное переподключение к сети; при большой загрузке сети могут «проскакивать» некоторые пакеты, но процент потерь достаточно высок (скажем, выполнение ping на 10 запросов вернет 90-97% потерь); при попытке подключения к нашим точкам доступа возможно занесение устройства в «черный список».
При установленном AirWave и включенном режиме монитора мы увидим такую картинку (при использовании контроллера картинка будет почти такая же, но придется выбирать интересующее устройство для того, чтобы посмотреть его месторасположение):

Красными треугольниками обозначены «вражеские» ТД, желтые кружки с ноутбуками — легальные клиенты.
При настройке WIPS в зоне с большим радиозашумлением следует выделить какое-то время на обучение системы — чтобы она запомнила «нейтральные» ТД соседей, и не подавляла подключение соседских устройств к ним; чтобы исключить подключение «своих» устройств к соседским, следует более тонко настроить IDS профиль для соответствующей ТД, в частности, на определение максимального уровня сигнала устройства, подключающегося к «запрещенной» сети (т.к. соседские устройства в большинстве случаев будут обладать заведомо более слабым сигналом, чем «свои»).

Заключительным штрихом настройки в головном офисе должно стать ограничение доступа к контроллеру (с возможным отправлением в «черный список» устройств, которые попытались подключиться к контроллеру с несанкционированного IP). При необходимости можно ввести требование шифрования клиентского трафика.
Если есть установленная SIEM система, то можно пересылать логи прям на нее (протокол Syslog).
Переходим в офис рядом с «Москвой».

Соседний офис

Ранее мы создали необходимые роли и политики; в общем-то, здесь все почти то же самое, за исключением одного нюанса: по каким-то причинам, прокладывать сетевой кабель до каждой точки не было возможности, зато в достатке были розетки 220В. Поэтому решили построить Mesh-сеть.
Суть очень проста: создается дополнительная невидимая служебная сеть (Mesh-сеть), одна точка берет на себя роль шлюза (портала) между всеми остальными точками и проводной части сети.
Служебная информация, которой обмениваются точки, шифруется; во избежание подключения неавторизованных ТД можно использовать ТРМ — модуль, интегрированный в них.
Основные проблемы при использовании такой конфигурации:

1. Возрастает нагрузка на портал; поэтому хотя портал и может выполнять функции ТД, следует иметь ввиду, что у клиентов, подключенных к нему, могут возникнуть проблемы со скоростью
2. Если портал упадет, то сеть обвалится. Поэтому желательно позаботиться об избыточности; к тому же это позволит разгрузить первичный портал и распараллелить нагрузку на проводную часть сети

В остальном, для клиентов нет особой разницы — «традиционная» или «mesh» сеть.
Точки доступа подцепляются автоматически; но при этом они должны быть сконфигурированы соответствующим образом. Но тут есть нюанс: mesh всегда будет строить до контроллера исключительно GRE туннели (и считаться LAN-подключенной ТД), в то время как ТД, подключенную «традиционным» способом можно представить и как «удаленную», если есть какие-то особые соображения в плане безопасности либо есть опасения потери больших пакетов.

Давайте теперь рассмотрим вариант для «Новосиба» — с подключением через сети общего пользования.

Офис «Новосиб»

Этот офис у нас далеко от головного; LAN не протянешь, поэтому приходится использовать сети общего пользования. Сразу хочется оговорить, что здесь мы рассматриваем полуавтономный вариант (контроллера нет, при падении контроллера в головном офисе сеть какое-то время проработает… до первой перезагрузки). Если нужен автономный вариант — то он описывается для офиса «Где-то на просторах России».
Как вы уже поняли, без построения VPN нам тут не обойтись. Но, VPN VPN`у рознь. Первый и очевидный вариант — гонять весь трафик (включая и интернет-запросы) через головной офис — не самое хорошее решение. Хотя можно реализовать и такое. Наверное, более правильно будет отправлять в головной офис тот трафик, который предназначен для корпоративной LAN, ну и, конечно же, служебную информацию:

В этом варианте трафик, предназначенный для Интернета, пойдет в Интернет, не бегая в головной офис; однако, при использовании неавтономных ТД, мы теряем часть возможностей, такие, как аутентификация с помощью веб-портала, а также система остается зависимой от головного контроллера.
С другой стороны, с точки зрения управления сетью, мы работаем так, как будто бы офис «Новосиб» находится в соседнем здании. Мы можем настроить эту ТД как mesh-портал и построить сеть, аналогичную той, что строили в офисе рядом с «Москвой». С той только разницей, что до контроллера теперь идет VPN туннель (IPSEC), соответственно, контроллер должен либо видеться снаружи, либо как-то перенаправляться на него запросы от ТД.
В плане настройки — все можно сделать около контроллера, затем отдать монтажникам, с указанием, какую ТД подключать к LAN. Как видите, ничего сложного в плане настройки здесь нет.
Дальше будет еще проще.

Офис «Где-то на просторах России», а также «Мобильный офис»

Здесь ситуация несколько сложнее: Интернет медленнее, обрывы связи — явление не столь уж редкое. Отдельный контроллер туда поставить можно, но дорого. Точки, как мы ставили в «Новосибе» не подходят по причине неавтономности. Но у нас есть выход — использовать автономные точки доступа. Например, такую (второй вариант автономной ТД будет рассмотрен еще ниже — в разделе про «мобильный офис»):

Такие ТД по терминологии Aruba называются RAP (Remote Access Point). Для нормального функционирования RAP ТД должна быть внесена в «белый список» контроллера; это необходимо для предотвращения несанкционированного подключения. После установки VPN соединения ТД получает всю необходимую информацию от контроллера (политики и т.д.) и сохраняет их. RAP ТД имеет встроенный DHCP сервер; также возможна настройка таким образом, что при недоступности контроллера ТД будет работать как обычный роутер, предоставляя доступ в Интернет. Однако, при этом, разумеется, будет недоступной корпоративная сеть.

Если местный провайдер чем-то не устраивает, или нужно развернуть мобильный офис, то возможно использовать сотовую связь через USB GPRS/3G/4G модем. Для этого используем такую RAP ТД:

Она имеет USB порты, к которым можно подключить либо USB-модем (правда, для модемов надо создавать профили; но некоторые работают сразу, например, Huawei), либо USB-принтер или NAS-диск. Таким образом, можно легко развернуть полноценный мини-офис в любом удобном месте.

В случае использования этих ТД возможно использование веб-портала.

VoIP и видеонаблюдение

Реализация очень проста. Необходимы лишь собственно беспроводные камеры и телефоны. Для VoIP можно создать все необходимые политики в полуавтоматическом режиме (нужно будет только указать адрес АТС). Для видеотрафика придется прописать соответствующие правили марширутизации до сервера, занимающегося обработкой видеопотока с камер.

На этом я закончу эту часть; ввиду достаточно большого объема материала, я мог упустить какие-то подробности, которые могут быть интересны для читателей, но я о них не неаписал; прошу сообщить в комментариях о таких случаях.
Благодарю всех за внимание!