Комментарии 16
На сложившуюся ситуацию мы обратили внимание коллег из государственных органов, которые всё время находились на мероприятии и распределяли и контролировали радиочастоты на стадионе. Благодаря непререкаемому авторитету коллег удалось вежливо убедить журналистов сменить частоты радиомоста, что и было сделано в перерыве (дабы не прерывать работу во время матча).
Запишем, запомним. "Скажи кто твой коллега..."
Понимаю ваш задор, но в реальной жизни это не так драматично выглядело )
Интегратор должен был обеспечить работу беспроводной сети, а представители надзорного органа - решать проблемы с нарушителями правил использования частот.
Как показала практика, проблемы возникали в основном из-за пользователей, которые поперек всех правил начинали городить свои беспроводные сети. Своими действиями они ухудшали и без того сложную помеховую обстановку на стадионе, а в результате страдали такие же пользователи. Вот таких ребят и просили выключать свои девайсы. А "коллеги из государственных органов" помогали сделать это быстро и без ненужных споров.
А сейчас часто используются решения на базе WLC контроллеров?
Раньше это была интересная тема, CISCO ее активно продвигала. Но у меня сложилось впечатление, что это направление отмирает.
Ничего подобного. Это системы на автономных точках умирают, ибо управлять ими в более-менее серьезных масштабах невозможно.
Циско (и другие вендоры) предлагают крупные решения на основе {железных, виртуальных}контроллеров, а если точек немного - то на основе мини-контроллера, работающего внутри одной из точек (у каждого производителя это называется по-разному).
А еще весь западный мир дружным строем в облака шагает. И это либо прямое облако, как у Juniper MIST, либо облако, управляющее мини-контроллером внутри точки, которая уже управляет другими точками, как в случае Aruba Instant + Central. У некоторых вендоров есть вариант сделать локальное облако, например Ruijie. Но контроллеры все ещё живы и жить будут долго.
Я это и имел в виду, ага.
Что железные контроллеры отмирают и решения по централизованному управлению начинают интегрироваться в сами точки или виртуализироваться.
С учетом этого, правильнее (на мой взгляд) говорить об актуальности централизованно управляемых сетей, или о самоорганизующихся сетях (типа MESH) - но не о сетях на базе контроллеров. Контроллеры - это баян и неадекватно дорогой баян. :))))
Я в свое время делал сеть на основе миниконтроллеров Cisco (кстати, прекрасно работала и, наверное, до сих пор работает - не знаю). Так вот эти контроллеры уже тогда (где то в 2014 году) стали EoL. А аналоги - это что-то интегрируемое в шасси Cisco или решение на очень большое количество точек, корпоративное до невозможности.
В самом деле, для простых задач, в которых не требуется централизованная обработка пользовательского трафика, можно смело использовать встроенные или облачные контроллеры.
Однако есть более сложные сценарии, когда пользовательский трафик нужно централизованно терминировать, анализировать, фильтровать, отправлять в другую локацию. Часто такие сценарии обусловлены требованиями безопасности. В этом случае аппаратный или виртуальный контроллер, который установлен в дата-центре заказчика внутри охраняемого периметра, остается оптимальным выбором.
При этом следует учитывать, что виртуальные контроллеры, устанавливаемые в среде виртуализации, могут иметь ограничения по функционалу или производительности, по сравнению с аппаратными контроллерами. А ещё, для них всё-таки нужно купить сервер. Из всего этого следует только то, что для решения каждой задачи есть более и менее подходящие инструменты, и у каждого есть свои плюсы и минусы.
Любой уважающий себя энтерпрайз использует контроллер нынче. Почему вы думаете, что это направление отмирает? Что может прийти на его смену? Управлять большим количеством точек доступа удобнее всего именно через контроллер.
А вот мне всегда интересно было, как ведёт себя защита от посторонних точек доступа, если например офис клиента занимает один этаж, а на другом - другая фирма? Ну или офисное здание стоит близко к другим зданиям, в том числе жилым.
Покуда соседские точки не начинают копировать SSID своих, все хорошо, просто пытаемся разбежаться по каналам. Если начинают копировать, это уже повод начать слать Deauth своим клиентам к чужим точкам подключающимся.
А они начинают делать тоже самое из вредности и получается хреновая ситуация...
Насколько я помню, единственный вариант избежать такой ситуации - это авторизация менджмент-фреймов. И тоже, Cisco его продвигала, стандарт 802.11w.
Вряд-ли бы соседи стали использовать аналогичный вашему SSID просто так – так что можно предположить изначальную вредность их намерений. Защита управляющих фреймов MFP включена в стандарт WPA3 и является обязательной. Так что все клиенты и точки доступа, работающие по данному стандарту, должны избавиться от этого недостатка.
Всё верно. Бездумное подавление чужих точек доступа влечёт как административные последствия, так и ответные действия.
Защита срабатывает не всегда. Точки доступа «видят» друг друга в радиоэфире, учитывают утилизацию радиосреды при выборе каналов, стараясь использовать наименее загруженные, не занятые «соседями». Таким образом, степень влияния соседей на вас и вас на соседей минимизируется.
Политики защиты от вторжений может срабатывать тогда, когда например происходит целенаправленная атака на вашу сеть с использованием ваших SSID (атака “Honeypot” или “Evil Twin”), или в корпоративный сегмент включается нелегитимное устройство и начинает вещать свой SSID (как в истории про торренты и топ-менеджеров).
Принципиально есть 2 механизма подавления. Один из них заключается в отправке Deauthentication фреймов клиентам нелегитимных точек доступа. Эти фреймы отправляются легитимной точкой доступа и предназначаются клиенту точки доступа, на которую сработали политики. Следствием работы этого метода является деаутентификация клиента от точки доступа. Но это не предотвращает попытки клиента повторно подключиться к этой точке.
Второй метод проприетарный, и заключается в имитации легитимной точкой подключения клиента к нелегитимной точке. Вместо того чтобы подключиться и что-то передавать, клиент только считает себя подключенным к нелигитимной точке, по факту же соединение не происходит. Это предотвращает настойчивые попытки клиента подключиться к нелигитимной точке, в эфире становится меньше фреймов аутентификации и деаутентификации, что снижает утилизацию эфира по сравнению с первым вариантом. Такой метод есть у Aruba.
Однако напомним, что с использованием механизмов защиты управляющих фреймов MFP или WPA3, эти методы работать не будут. От деаутентификации будут защищены как наши клиенты, так и соседские.
Истории забавные, спасибо.
Вообще, если помеху приходится искать во время сёрви - значит, её искать уже поздно :) Вы не думали для таких задач раскидывать сенсоры по объекту, собирать с них информацию и алярмить по достижению порогов? По-моему, у всех вендоров уже такие есть, с разным набором фич, выбирай - не хочу.
Спасибо за статью! Интересные, "типичные" жизненные кейсы, а главное с практическими советами. У меня только возникло множество вопросов, которые не были затронуты (или опущены) в статье:
1) "Бабушка и MITM-атака". Вы построили новую Wi-Fi сеть с аутентификацией по сертификатом. Почему инцидентами безопасности занимается инженер подрядчика, а не сотрудник отдела ИБ данной компании? В таких случаях в проект включают разработку эксплуатационной документации (инструкция ИБ) и обучение персонала. Где система предотвращения вторжений (wIPS), или хотя бы реакция на разворачивание сторонней сети (Rogue Detection)? Эти вопросы опущены и складывается ощущение недоработки проекта.
2) "Wi-Fi на стадионе". Распределение радиоканалов по службам стадиона - жесткая дичь )), но, тем не менее, на контроллере можно было просто ограничить пул каналов для автоназначения. Лучше строить сеть так, чтобы она автоматически реагировала на занятые каналы и переключала точки в другие. Иначе, матч длиться 1,5-2 часа из которых вы час тратите на поиск и отключение левых точек, т.е. сервис в данной зоне не доступен 50% времени. Возможно стоило административно запретить использовать радиомосты при получении аккредитации.
3) "Потрогать точку". Подключиться к сети вместо ТД можно во многих случаях. Вопрос в целесообразности атаки. Нет ни слова про матрицу угроз и актуальность атаки (хотя статья про безопасность). Port Security - бесполезен, т.к. почти всегда на ТД указан MAC-адрес, злоумышленник легко его подменит. Единственная действенная мера - аутентификация ТД на порту через 802.1X. Чаще по логину/паролю (PEAP), можно и по сертификатам (EAP-TLS) - но это уже на грани паранойи.
Бабушки, аудиты и брутфорс — истории о безопасности Wi-Fi-сетей