Взял на вооружение "Протокол сбора данных о сетевых инцидентах" как предварительный этап аудита, не уделял раньше этому моменту должного внимания. Спасибо за статью!
Спасибо за "useful" статью, беру на вооружение! Приятно удивила генерация автоматического отчета netsh wlan show wlanreport, вся диагностическая информация клиента в одном месте. Единственное, у меня в винде почему-то проблема с кириллицей (если отдельно запускать в командной строке, таких проблем нет):
моя твоя не понимать
Как и написали уже 100 раз выше, я бы добавил в диагностику пару команд проверки data flow (винда):
tracert -d [IP]
pathping -n [IP]
Чаще приходится работать с заявками типа "Нет Интернета", и эта информация будет полезна для исключения/подтверждения проблем на пути передачи трафика.
Спасибо за статью с практическим опытом! Правда, после прочтения появилось несколько вопросов и недопониманий:
1) Почему в 5 ГГц имеется только 13 каналов, хотя даже на картинке указано 17 (что с каналами 132-144)?
2) Зачем в вашем случае (с одной ТД) вы выставляете значения калибровки и проводите калибровку? Других точек же нет! Почему просто статически не установить значения EIRP? + в данном случае не отключены низкие Data Rates (1, 2, 5.5, 11), или просто не сказано об этом. Это может привести к увеличению утилизации канала, в случае когда клиент отошел слишком далеко и работает на низких Data Rates.
3) Проведенный тест с rf-ping не отражает объективно качество . Может вы проводили его когда в сети больше никто не пытался что-либо передавать (не было других клиентов). Какие показатели утилизации каналов на ТД в течение рабочего времени?
Спасибо за статью! Интересные, "типичные" жизненные кейсы, а главное с практическими советами. У меня только возникло множество вопросов, которые не были затронуты (или опущены) в статье:
1) "Бабушка и MITM-атака". Вы построили новую Wi-Fi сеть с аутентификацией по сертификатом. Почему инцидентами безопасности занимается инженер подрядчика, а не сотрудник отдела ИБ данной компании? В таких случаях в проект включают разработку эксплуатационной документации (инструкция ИБ) и обучение персонала. Где система предотвращения вторжений (wIPS), или хотя бы реакция на разворачивание сторонней сети (Rogue Detection)? Эти вопросы опущены и складывается ощущение недоработки проекта.
2) "Wi-Fi на стадионе". Распределение радиоканалов по службам стадиона - жесткая дичь )), но, тем не менее, на контроллере можно было просто ограничить пул каналов для автоназначения. Лучше строить сеть так, чтобы она автоматически реагировала на занятые каналы и переключала точки в другие. Иначе, матч длиться 1,5-2 часа из которых вы час тратите на поиск и отключение левых точек, т.е. сервис в данной зоне не доступен 50% времени. Возможно стоило административно запретить использовать радиомосты при получении аккредитации.
3) "Потрогать точку". Подключиться к сети вместо ТД можно во многих случаях. Вопрос в целесообразности атаки. Нет ни слова про матрицу угроз и актуальность атаки (хотя статья про безопасность). Port Security - бесполезен, т.к. почти всегда на ТД указан MAC-адрес, злоумышленник легко его подменит. Единственная действенная мера - аутентификация ТД на порту через 802.1X. Чаще по логину/паролю (PEAP), можно и по сертификатам (EAP-TLS) - но это уже на грани паранойи.
Да, соглашусь с вами, с общественных доменов (mail, google и т.п.) зарегистрироваться не получится.
При регистрации партнера необходимо указать действующий сайт компании и соответствующий почтовый адрес.
Расчеты скрыты в коде программы (описание в документации я не нашел).
Из параметров расчёта только высота крепления ТД и канал (ширина). Программа рассчитана только для моделирования уровня сигнала. Соответственно, нет моделирования интерференции, SNR, утилизации (где учитывается MIMO) и пр.
Взял на вооружение "Протокол сбора данных о сетевых инцидентах" как предварительный этап аудита, не уделял раньше этому моменту должного внимания. Спасибо за статью!
Спасибо за "useful" статью, беру на вооружение! Приятно удивила генерация автоматического отчета
netsh wlan show wlanreport, вся диагностическая информация клиента в одном месте. Единственное, у меня в винде почему-то проблема с кириллицей (если отдельно запускать в командной строке, таких проблем нет):Как и написали уже 100 раз выше, я бы добавил в диагностику пару команд проверки data flow (винда):
Чаще приходится работать с заявками типа "Нет Интернета", и эта информация будет полезна для исключения/подтверждения проблем на пути передачи трафика.
Ждем продолжения :)
Спасибо за статью с практическим опытом!
Правда, после прочтения появилось несколько вопросов и недопониманий:
1) Почему в 5 ГГц имеется только 13 каналов, хотя даже на картинке указано 17 (что с каналами 132-144)?
2) Зачем в вашем случае (с одной ТД) вы выставляете значения калибровки и проводите калибровку? Других точек же нет! Почему просто статически не установить значения EIRP?
+
в данном случае не отключены низкие Data Rates (1, 2, 5.5, 11), или просто не сказано об этом. Это может привести к увеличению утилизации канала, в случае когда клиент отошел слишком далеко и работает на низких Data Rates.
3) Проведенный тест с rf-ping не отражает объективно качество . Может вы проводили его когда в сети больше никто не пытался что-либо передавать (не было других клиентов). Какие показатели утилизации каналов на ТД в течение рабочего времени?
Спасибо за статью! Интересные, "типичные" жизненные кейсы, а главное с практическими советами. У меня только возникло множество вопросов, которые не были затронуты (или опущены) в статье:
1) "Бабушка и MITM-атака". Вы построили новую Wi-Fi сеть с аутентификацией по сертификатом. Почему инцидентами безопасности занимается инженер подрядчика, а не сотрудник отдела ИБ данной компании? В таких случаях в проект включают разработку эксплуатационной документации (инструкция ИБ) и обучение персонала. Где система предотвращения вторжений (wIPS), или хотя бы реакция на разворачивание сторонней сети (Rogue Detection)? Эти вопросы опущены и складывается ощущение недоработки проекта.
2) "Wi-Fi на стадионе". Распределение радиоканалов по службам стадиона - жесткая дичь )), но, тем не менее, на контроллере можно было просто ограничить пул каналов для автоназначения. Лучше строить сеть так, чтобы она автоматически реагировала на занятые каналы и переключала точки в другие. Иначе, матч длиться 1,5-2 часа из которых вы час тратите на поиск и отключение левых точек, т.е. сервис в данной зоне не доступен 50% времени. Возможно стоило административно запретить использовать радиомосты при получении аккредитации.
3) "Потрогать точку". Подключиться к сети вместо ТД можно во многих случаях. Вопрос в целесообразности атаки. Нет ни слова про матрицу угроз и актуальность атаки (хотя статья про безопасность). Port Security - бесполезен, т.к. почти всегда на ТД указан MAC-адрес, злоумышленник легко его подменит. Единственная действенная мера - аутентификация ТД на порту через 802.1X. Чаще по логину/паролю (PEAP), можно и по сертификатам (EAP-TLS) - но это уже на грани паранойи.
Отличная вещь! Спасибо за наводку и спасибо создателю модели (Константину Баженину, судя по аккаунту). Попытаюсь распечатать в ближайшее время.
Хороший вариант. Высота до 3.6 м, а весит всего 4 кг. Беру на заметку!
Да, мы так и делали сначала, таскали обычный ИБП :).
Цена на PoE ИБП конечно высокая, но соизмерима со стоимостью одной точки доступа. Если закупать в рамках проекта где 100+ ТД, то уже оправдано.
Также в Интернете можно найти более дешёвые аналоги: iLepo, PowerWalker.
При регистрации партнера необходимо указать действующий сайт компании и соответствующий почтовый адрес.
Из параметров расчёта только высота крепления ТД и канал (ширина). Программа рассчитана только для моделирования уровня сигнала. Соответственно, нет моделирования интерференции, SNR, утилизации (где учитывается MIMO) и пр.
Достаточно создать аккаунт.