По мотивам соседнего поста. К сожалению, вынужден уведомить, что революция откладывается. И у Amazon и у B&N на сайтах куча отзывов о проблемах подсветки: неравномерности, цветовые засветки, "протекания" подсветки в виде царапин и дыр. Опишу свой личный опыт.
Из опробованных мной двух свежих экземпляров Kindle Paperwhite оба оказались дефектными. В одном были видны хорошо заметные тени от подсветки (картинка ниже) и был разрыв в светоизолирующем(?) слое: хорошая такая светлая царапина, исчезающая, если подсветку убрать.
К сожалению, я фото не делал, но нашел аналоги в интернете. Вот пример косяков с подсветкой (здесь и далее при нажатии на картинку открывается оригинальная версия с исходного сайта):
В моем случае длина "теней" была раза в полтора больше, тени ощутимо наползали на текст при стандартных отступах, читать было не очень приятно. Вот терминальный случай:
При попытке обмена этого экземпляра на другой нарвался на еще большую неравномерность подсветки, да еще и с каким-то розовато-фиолетовым оттенком. Самое обидное, что при ярком освещении эти дефекты еле заметны, а вот вечерком - весьма ощутимы. Так что смысла от такой подсветки нет. В итоге пришлось оформлять возврат.
У Nook Glowlight проблем с тенями от подсветки, вроде, не отмечается, но зато этих самых "светлых царапин" полно, причем некоторые из них со временем, если верить отзывам превращаются в дыры. Обратите также внимание на засветку сверху. Основная причина - хилый светоизолирующий(?) слой, который рвется, мнется и гнется от малейшей нагрузки (сам диспей при этом не страдает и все отлично показывает с выключенной подсветкой).
На витрине магазина B&N стоял один такой демо-образец с тремя царапинами. На мой вопрос, считается ли это дефектом и подлежит ли замене было сказано: "Меняем только неработоспособные устройства, а эти белые черточки читать не мешают". Лично мне они не мешали читать только с выключенной подсветкой. Стоит отметить, что даже если B&N такой ридер поменяет, в замену новому могут прислать отремонтированный (refurbished).
В общем, в первом поколении подсветки революция если не отменяется, то как минимум откладывается до тех пор, пока не вылечат существующие детские болячки. Покупать Kindle или Nook с подсветкой в онлайне сейчас - лотерея, и шансы на выигрыш невелики.
Дабы закончить позитивно: оказывается, я прозевал момент, когда на Kindle портировали движок от CoolReader3 (естественно, нужен джейл) и теперь на нем можно спокойно читать FB2 и проч, без использования монструозной Calibre!
Безо всяких вступлений скажу, что устройства на Apple iOS в корпоративных сетях присутствуют в немалом количестве, и в будущем их меньше, похоже, не станет (особенно со столь массовой популяризацией идеологии BYOD). И не важно, используются ли они как непосредственно бизнес-устройства или просто как персональные гаджеты сотрудников и начальства. Поэтому, с ними надо мириться и как-то уживаться. В этой заметке собраны под одной крышей особенности функционирования Wi-Fi в Apple iOS и приведены ссылки на материалы для дальнейшего изучения. Давайте по порядку рассмотрим, что есть и чего нет в iOS, и как с этим жить.
Вначале хорошее.
Поддерживаются все нужные (и ненужные) механизмы шифрования: WEP, TKIP, CCMP. При этом помним, что если мы хотим 802.11n и высокие скорости в сети, то WEP и TKIP отпадают, о чем Apple предупреждает на сайте поддержки.
Поддерживаются все основные механизмы аутентификации: EAP-TLS, EAP-TTLS, EAP-SIM, PEAPv0 (MSCHAP-v2), PEAPv1 (GTC), а также проприетарные Cisco LEAP и EAP-FAST.
Из сертификатов поддерживаются PKCS#1 (.cer, .crt, .der) и PKCS#12
Очень дружественный к пользователю суппликант 802.1x – никаких многоуровневых диалогов с малопонятными опциями – просто введи пароль, выбери/подтверди сертификат и работай.
Таким образом, имеем поддержку и WPA и WPA2 в вариантах Personal и Enterprise и широким набором опций, которую пользователь может настроить самостоятельно.
Последние модели поддерживают 802.11n и даже 5ГГц.
В IOS6 имеется поддержка 802.11k и 802.11r, которые позволяют устройству при роуминге определить оптимальную точку доступа (ТД передают данные о своей загрузке) и быстро на нее перебраться.
В общем, в видении Apple i-устройства в корпоративных сетях ждет рай, тишь и благодать. Бумага, посвященная развертыванию iOS в корпоративных WLAN снабжена аж одной иллюстрацией. Видимо, больше ничего знать не надо.
Но не тут-то было.
Пойдем в обратном порядке.
802.11k и 802.11r (если верить вышеупомянутой бумаге) поддерживаются только на iPhone 4S, iPhone/iTouch 5 и новом iPad – так что на них пока что рассчитывать особо тоже не приходится.
5ГГц поддерживаются только на iPhone/Touch 5, iPad (1-4, mini) и Apple TV. Однако, большого энтузиазма по поводу iPhone 5 не видно, iTouch 5 вообще не понятно кому нужен (почти за те же деньги можно брать Mini), а iPhone 4/4S еще вполне неплохо себя чувствует. Поэтому, рассчитывать только на 5GHz для «тотальной» поддержки i-гаджетов не получится – придется работать в 2.4GHz со всеми вытекающими последствиями (3 канала, помехи, кучи соседей и т.д.).
Дружественный суппликант 802.1X позволяет спокойно принять чужой непроверенный сертификат.
Очень удобно для лаб и демонстраций, не очень приятно, если кто-то попадется на подставную точку доступа (далее спокойно вскрывается MSCHAP – а именно его использует подавляющее большинство из-за распространенности Active Directory – и добываются имя/пароль пользователя).
Данная фича отключается через Configuration Manager, но для этого нужно или сдать телефон IT-шнику, или прислать профиль пользователю удаленно и убедиться, что он его таки применил.
За компанию добавим про “сверхскорости” 802.11n и MIMO в смартфонах и планшетах. Без комментариев (авторства Amazon)
Тем не менее, поддержка 802.11n важна, т.к. без нее сеть падает в режим совместимости с 802.11a/g (HT Protection) и начинают страдать другие клиенты 802.11n.
Но, как любит говаривать автор нескольких популярных финансовых пирамид, это всё присказка была...
Статья на сайте поддержки Apple “рекомендации по настройке WiFi для iOS-устройств” раскрывает интересные подробности
iOS не любит скрытые имена сетей. Мой iTouch 4G на IOS5 вполне спокойно работает со скрытой сетью, но от других жалобы слышал.
Не поддерживаются широкие каналы (40MHz).
С одной стороны – ну и правильно, нечего в 2.4GHz соваться с широкими каналами. Их туда влазит ровно один, помех от этого в большинстве случаев больше чем толку. Но почему не поддерживаются 40MHz в 5GHz? Ответ на картинке выше – 20MHz и так за глаза хватает.
А что делать остальным устройствам в корпоративной сети где включены широкие каналы (если вы таки используете, скажем, iPad’ы в 5GHz, как делают некоторые ритейлеры модной одежды)? Ответ один – страдать. Параллельно с HT Protection в 802.11n есть режим совместимости 40MHz с 20MHz, который тоже понижает производительность сети аналогичными способами (предварительные фреймы и т.д.). Насколько – зависит от множества параметров, в основном, от того, как часто iPad будет требовать эфир – точно предсказать нельзя.
При подключении к Wi-Fi сети устройство проверяет наличие связи с Интернет пытаясь соединиться с сервером Apple и стащить оттуда определенную веб-страницу. Если эта страница недоступна, предполагается, что мы сидим на хотспоте и выскакивает окошко браузера с запросом на логин, при этом система больше не пытается лезть в сеть. Удобно. Как показал недавний инцидент с IOS6, при отсутствии доступа к данной странице – отсутствует доступ к сети.
Поддержка OKC особо никого не волнует, если вы не используете софт-фоны или у вас устройства на iOS6 (802.11r успешно заменит OKC).
При отсутствии доступа к Интернет более 20 мин устройство старается переподключиться или найти другую сеть (может, там повезет).
TAC добавляет еще один мазок к картине со скрытыми SSID – при наличии двух и более SSID, устройство всегда будет подключаться к открытым сетям, даже если намеренно выбрать профиль со скрытым SSID.
Устройства (особенно iPad) обладают значительной мощностью на передачу, но худшей чувствительностью на прием (сказывается домашняя специфика).
Возможны разнообразные косяки при отключении скорости 11Mbps (что требует, по-сути, включения поддержки 802.11b). Я не наблюдал таких проблем на своем устройстве с IOS4/5, скорее всего – это пережитки более старых версий. Однако, некоторые партнеры Motorola подтвердили, что сталкивались с такой проблемой у заказчиков.
Статья датирована Июлем 2012, возможно с выходом iOS6 часть проблем ушла. К сожалению, Applе не очень щедра на подробности.
Протокол Bonjour (анонс сервисов, передача видео AirPlay и т.д.) не маршрутизируется. Т.е. устройства должны быть в одной VLAN (что нормально в домашних условиях). Однако в корпоративной среде шансы подключения проводного AppleTV и беспроводного iPhone в одну VLAN минимальны (если у вас правильный дизайн сети).
Тем не менее, популярность AppleTV привела к тому, что многие вендоры внедрили т.н. Bonjour Gateway – по сути аналог DHCP Relay, но для Bonjour, и теперь даже меряются его работоспособностью, показывая диаметральнопротивоположные (это две разные ссылки) результаты :). Данная функция поддерживается Cisco, Aruba, Aerohive. Motorola не поддерживает Bonjour Gateway в «чистом» виде – предлагаются другие варианты проброса L2 по L3 – от проприетарного MiNT до L2TPv2/3 и PBR.
Есть еще мелочи (поддерживается только 1 WEP-ключ и т.д., устройства не подключаются к сетям с отключенной поддержкой WMM), но они на самом деле не должны никого волновать, т.к. не подобные конфигурации не должны использоваться в корпоративных сетях.
Итого.
Мое мнение о пригодности iOS к корпоративным внедрениям не поменялось, но жить с ним как-то надо. Давайте просуммируем все в виде рекомендаций для поддержки iOS в корпоративной беспроводной сети
В идеале, мы хотим дать людям доступ в Интернет и не более. Если необходима почта и проч – гораздо проще (с точки зрения Wi-Fi) заставить все эти устройства заходить в корпоративную сеть через VPN, чем сеять хаос и разрушение менять что-либо в отлаженной Wi-Fi сети.
В таком случае достаточно создать гостевую сеть, завести на ней https-хотспот с RADIUS-авторизацией, привязанной к корпоративной базе пользователей (AD или другой). О причинах обязательной аутентификации на хотспотах я уже писал здесь.
Сеть достаточно развернуть в 2.4GHz в режиме тотального гостевого доступа для всего подряд: поддержка b/g/n-скоростей (конечно-же, по возможности отключите низкие скорости 1,2,5.5Mbps), каналы 20MHz, нескрытые SSID и т.д.
Обязательным условием включения доступа i-устройству должно быть применение профиля безопасности, который блокирует возможность принятия чужих сертификатов (защита от фишинга и раскрытия корпоративных учетных данных).
Если же планируется поддержка корпоративных приложений в корпоративной сети – следует задуматься
Передаем ли мы синхронный трафик (голос, видео)? Многие школы в США сейчас используют iPad’ы для передачи учебных видеороликов, например.
Если нет – следуем рекомендациям прошлого параграфа, но вместо хотспота настраиваем 802.1X, благо, вариантов море. Поскольку среднестатистический юзер пугается слова "RADIUS" - гораздо проще убедить его применить профиль безопасности, отдав его в комплекте с настройсками сети ("ткни сюда и все настроится само").
Возможно, придется немного поиграться с настойками скоростей в сети (если проводились оптимизации) и включить некоторые рейты.
Убедитесь, что страница http://www.apple.com/library/test/success.html доступна из вашей сети, или настройте редирект на свой веб-сервер, который будет убеждать айфоны в том, что все в порядке. :)
Если таки планируется передача голоса и видео – все становится сложнее.
Традиционно, такие сети строятся в 5GHz, т.к. обеспечить QoS в «загрязненном» 2.4 весьма проблематично. Лучшим выходом будет заявить прямо, что работа потоковых приложений для iPhone4S и ниже не гарантируется и не поддерживается, после чего перевести iPad’ы и другие новые устройства в 5GHz.
При этом следует учесть широкие каналы, если они используются в 5GHz. Оценить падение производительности, вызванное появлением iPad’ов в такой сети, поможет тестирование.
Для быстрого роуминга (если он требуется) имеет смысл обновить пользователей до iOS6 (есть подозрение что 802.11k/r – это фишка ОС, а не чипсетов, все же) и настроить их в своей беспроводной инфраструктуре. Иначе – хотя бы включить PMK Caching.
Если планируется использование Bonjour – анализируем потоки трафика и делаем форвардинг L2 поверх L3 (или включаем и настраиваем Bonjour Gateway). Очень хорошо, если можно делать выборочный форвардинг по ACL, дабы не слать весь трафик, но это зависит от возможностей имеющегося сетевого оборудования.
Тщательно тестируем поведение устройств разных поколений и разных прошивок на разных скоростях. Обычно в высокопроизводительных WLAN отключают рейты 18Mbps и ниже. В данном случае, придется тестировать, какие скорости можно отключить – а какие оставить. Возможно, вкупе с особыми требованиями по мощности сигнала, это повлечет изменения в радиопланировании, к чему нужно быть готовым.
По безопасности есть замечательный документ NSA. Думаю, им можно верить (если это не намеренная дезинформация вероятного противника).
В заключение, отмечу, что Apple в плане Wi-Fi совершила значительный рывок. Если первые прошивки для iPhone были настолько кривыми, что косили намертво сети Cisco, то сейчас все гораздо лучше. Назвать iOS-устройства «корпоративными» я по-прежнему не могу, но, в целом, поддерживать iOS в корпоративной сети уже можно. Если быть осторожным в своих аппетитах и обещаниях. (Это не касаясь управления парком устройств и BYOD в целом!)
Делитесь мнениями. Особенно интересен опыт людей, поддерживающих 50+ устройств.
В этом посте хочу поделиться историей одной гениально простой атаки, которую наблюдал в прошлом году, и обсудить последствия. Здесь не будет "мяса" для хакеров, но будет:
Плюс одна поучительная байка в коллекцию "для бесед с пользователями" админам и безопасникам.
Почему в беспроводных сетях защищать нужно не только LAN от WLAN, и зачем нужен т.н. Wireless Firewall.
Рекомендации, как построить публичную сеть Wi-Fi для избежания подобных проблем.
Почему в гостиницах и других публичных сетях даже незашифрованный Captive Portal может оказаться предпочтительнее шифрования с PSK.
В принципе, я уже писал год назад на подобную тему для корпоративных сетей, но тут недавно пришлось глянуть на проблему под несколько иным углом.
Прежде всего, я не навязываю и не призываю срочно бежать и покупать крутой Wi-Fi с WIPS и RTLS. В каждой ситуации будут свои нюансы и приоритеты: кто-то прикроется пользовательским соглашением, кому-то просто плевать на пользователей, в каких-то странах не предусмотрено ответственности, где-то достаточно частичных мер, у кого-то еще какие-то нюансы. Я описываю - каждый выбирает сам.
Предыстория
История приключилась с моим коллегой в гостинице, где мы остановились. Гостиница предоставляет Wi-Fi бесплатно всем своим гостям. Сеть запаролена, PSK выдается на бумажке и меняется раз в несколько месяцев.
История
Коллега подключает ноутбук к сети, открывает Firefox, пишет адрес какого-то хорошо знакомого сайта. Вместо сайта появляется красивая страничка с заголовком сайта гостиницы и сообщением вида "Ваш браузер несовместим с сайтом, который вы пытаетесь открыть. Установите патч отсюда". Коллега впечатляется, запускает Chrome - та же страничка. Подключаем к сети Android и iPod Touch - то же самое. При этом "патч" всегда один и тот же :) Скачиваем "патч" - вполне ожидаемо ругается антивирус (нашли 3 разных типа malware).
В общем, сюжет очевиден - албанский вирус, распространяющийся фишингом и небольшим хаком в сети. Сам вирус интереса не представляет - интерес представляет понять, как всё это работает, чтобы таки получить доступ в Интернет без "патча".
Разбираемся
Путем некоторых простых исследований (на уровне ipconfig/ping) было выяснено, что на сайты можно заходить по IP. Значит проблема в DNS. Прописав DNS 8.8.8.8 мы получили полноценно работающий интернет. Теперь можно разбираться, как же работает атака. Было выяснено следующее:
Во WLAN сидел еще один DHCP-сервер (rogue DHCP), который выдавал корректные IP/mask/GW, но выдавал "свой" DNS-сервер вместо правильного провайдерского.
На том же хосте был поднят тот самый DNS-сервер, который все имена резолвил в один и тот же IP (который "по невероятному стечению обстоятельств" совпадал с IP DNS-сервера).
На том же IP был поднят веб-сервер, который, собственно, и показывал страничку и отдавал файл.
Как видите - все очень просто и не требует особых навыков для реализации. Вопрос: сколько "обычных людей" на это поведется? Также, странно, что злоумышленник ограничился "патчем" и не нарисовал заглавных страниц GMail/Bing/Facebook и т.д. - можно было бы насобирать аккаунтов. Даже с HTTPS: сколько людей обращает внимание на кривые сертификаты или на то, что их только что редиректнули с HTTPS на HTTP? Хотя, если на машине три трояна - они уже сами все насобирают..
Выводы и способы решения
При построении любой сети доступа важно не только защитить эту сеть и проводную инфраструктуру от "излишнего интереса" пользователей, но и защитить одних пользователей от других, менее порядочных. Это актуально и для корпоративных (приватных) сетей, и для публичных сетей (хотспоты, гостиницы, кафе-бары-рестораны и т.д.). При этом стоит помнить, что "беспроводная безопасность" - это не только шифрование: должны также присутствовать идентификация, аутентификация, разделение трафика и много чего другого. Описанная выше атака - не единственная чисто беспроводная атака, которую не определит ни один Firewall или IPS в проводном сегменте. Что же делать, чтобы такой проблемы не возникло?
Самое простое решение - запретить коммуникации между пользователями. Обычно, это делается включением/выключением одной галочки в настройках WLAN ("Disable MU-to-MU communication", Cisco PSPF, "Client Isolation" и аналоги). Однако, это не всегда нравится пользователям хотспотов и может противоречить целям использования сети (геймерские тусовки, VoWLAN в корпоративных сетях, и проч.). Хотя - если не противоречит - как уже было сказано, проще всего сделать именно так, и прописать этот пункт в "правилах пользования".
Лучший способ - запретить DHCP-, DNS- и (за компанию) и ARP-ответы в беспроводной сети. Для этого нужно иметь файрвол прямо на точке доступа, способный фильтровать трафик WLAN-to-WLAN (периодически это называют Wireless Firewall для подчеркивания отличия от традиционных FW). Для меня год назад было большим удивлением, что некоторые именитые вендоры этого не умеют (и по сей день). DNS и DHCP ответы разрешаются только от проводных хостов. ARP ответы от клиентов вообще не нужны - точка все равно знает все MAC-адреса клиентов (при ассоциации) и сможет ответить на запросы через Proxy ARP, так что заодно уменьшается количество паразитного трафика в сети. Таким образом мы избавляемся от DHCP/DNS/ARP-spoofing'а, rogue DHCP/DNS, APR-poisoning'а, связанных с ними MiTM-атак (и, наверное, еще много чего - дополняйте в комментариях).
Теперь, давайте обратим внимание на другой аспект. Вот я обнаружил поддельный сервер в сети. Я могу его заблокировать по MAC. Но если злоумышленник не дурак и периодически проверяет активность своей мышеловки, он это заметит, сменит MAC, и все продолжится. Кроме того, зная PSK, злоумышленник может вбрасывать пакеты в сеть пользователям даже не будучи подключенным к точек доступа, и даже с WPA2. Для этого надо изрядно постараться, т.к. в WPA/WPA2 распределение ключей посложнее, чем в WEP, но это возможно. Единственный способ избавиться от супостата - поменять PSK. А потом поменять его для всех клиентов! Да и это, хоть и отобьет атаку, не позволит найти и наказать злоумышленника (если не использовать системы позиционирования). А что уж говорить про открытые хотспоты? Таким образом, в публичных сетях, даже если они защищены PSK, как сеть нашей гостиницы, злоумышленник остается безнаказанным практически всегда.
Другое дело - использовать Captive Portal (только грамотно использовать) или 802.1x (заодно решает проблему с вбросом трафика, но в публичных сетях использовать 802.1x cложновато все-же). Каждый пользователь получает индивидуальные имя и пароль, к которым при логине привязывается MAC-адрес, аккаунт работает ограниченное время (в гостиничных системах строят автоматизацию для привязки к вписке-выписке). Таким образом, мы всегда можем вычислить, кто это забавляется, или, хотя бы, через кого произошла утечка идентификационных данных.
Оба этих нюанса чрезвычайно важны в такой опасной и увлекательной игре как перекладывание ответственности. Если у вас в пользовательском соглашении не зафиксирован отказ от ответственности (а не всегда это можно сделать, плюс, надо убедиться, что пользователь не может получить доступ к сети не согласившись с правилами использования ресурса), если через вашу сеть будут идти взломы, порно, пропаганда расизма/насилия и проч, и если вы не сможете найти крайнего - крайним назначат вас. Именно поэтому, в результате буйного разгула фишинга на хотспотах в Европе ввели обязательную идентификацию каждого пользователя на законодательном уровне (чаще всего, требуется ввести номер мобильного на который приходит SMS с индивидуальным кодом доступа). Понятно, что от этого тоже можно скрыться, но таким образом провайдер хотспота перекладывает ответственность на провайдера SIM-карты. Даже без использования аутентификации Captive Portal может перед тем как дать доступ показать заставку с "правилами использования ресурса" и заставить пользователя ткнуть в галочку "я принимаю условия", чего во многих случаях уже достаточно с правовой точки зрения (и пользователь потом не отвертится, что не видел соглашения). Так что, иногда открытая сеть с Captive Portal'ом может оказаться безопаснее закрытой сети с PSK - для ее владельцев :)
Как альтернатива, некоторые вендоры (Aerohive, Ruckus) реализуют нестандартную технологию "индивидуальных PSK", где каждому клиенту выдается свой уникальный ключ. Таким образом тоже решаются проблемы идентификации пользователей и массовой смены PSK при его утечке. Однако, доступность их в странах СНГ весьма ограничена, и иногда наблюдаются проблемы с совместимостью.
Заключение
В беспроводных сетях защита беспроводных пользователей от целиком беспроводных атак не менее важна, чем защита проводного сегмента. С помощью довольно несложных технических средств можно наладить фишинг в промышленных масштабах и другие атаки - и ни один проводной Firewall/IPS не поможет. Существуют технические меры, позволяющие ограничить доступ беспроводных пользователей к другим беспроводным пользователям:
Запретить коммуникации между ними вообще (поддерживается почти всеми производителями, но не всегда приемлемо в сети)
Запретить беспроводным пользователям посылать ответы важных сетевых сервисов: DHCP, DNS, ARP (гораздо лучше, но поддерживается не всеми и может не спасти от более сложных атак)
Использование Captive Portal/802.1x/PPSK позволяет идентифицировать источник атаки или утечки пользовательских данных
Специализированная Wireless IPS поможет прикрыться и от других атак
Система позиционирования (RTLS) позволяет определить приблизительное физическое местоположение источника
Все вышеперечисленное актуально для любых сетей (инсайдерские взломы никто не отменял), да и для проводных сетей тоже, но особенно важно для сетей публичных (хотспоты, гостиницы, КаБаРе и т.д.) с точки зрения
Привлекательности для клиентуры: "меня/друга там хакнули - я туда больше не пойду" и т.п.
Организационных вопросов: можно быстро разрулить проблему и найти виновного; возможно, кто-то из своих сотрудников решил "подработать" и т.д.
Легальных вопросов: можно переложить ответственность, если прижмут.
На последней DEFCON был продемонстрирован взлом протокола аутентификации MS-CHAPv2. В результате многие СМИ разразились информацией о том, что "тысячи VPN и WPA2-устройств находятся в опасности". Рассмотрим, насколько это утверждение верно для Wi-Fi сети реализующей WPA2. Скандалы? Интриги? Расследования?
Дабы не плодить сущности без необходимости, я дам выжимку с основными фактами и выводами, а также ссылки на первоисточники для тех, кого интересуют подробности.
Скандалы
Исходная информация: блог авторов атаки. Утверждается, что MS-CHAPv2 взламывается с результативностью 100%. Приводятся подробности, из которых видно, что нужно перехватить обмен по протоколу MS-CHAPv2, после чего, используя уязвимости в шифровании можно вычислить реквизиты пользователя. Утверждается, что MS-CHAPv2 используется в системах VPN и WPA2-Enterprise. При этом и VPN и WPA2 упоминаются в контексте AAA-серверов, что весьма логично, ибо именно там и ловится нешифрованный MS-CHAP.
Итого - таки да, MS-CHAPv2 взломан. Если перехватить MS-CHAPv2 обмен между клиентом и AAA-сервером - можно вычислить реквизиты пользователя.
Интриги
После этого, начали появляться статьи типа этой, где WPA2 уже используется вне контекста AAA-серверов. При этом делаются довольно серьезные заявления: "Users who want to crack the key protecting a target's VPN- or WPA2-protected traffic need only capture a single login attempt" (для взлома VPN/WPA2 достаточно перехватить одну попытку входа) и вплоть до "people should immediately stop using VPN and WPA2 products that rely on MS-CHAP" (людям следует немедленно прекратить использовать VPN/WPA2 с MS-CHAP).
Расследования
Ну, для начала, вспомним, что WPA2 существует в двух видах: WPA2-Personal (PSK) и WPA2-Enterprise (802.1x/EAP). MS-CHAPv2 используется только в Enterprise, поэтому пользователи PSK могут спать спокойно.
В Enterprise, MS-CHAPv2 является только одим из возможных методов EAP (есть еще довольно популярный GTC, TTLS и т.д.). Популярность MS-CHAPv2 вызвана тем, что это наиболее простой метод для интеграции с продуктами Microsoft (IAS, AD, и т.д.).
Тем не менее, хоть кто-нибудь видел реализацию WPA2-Enterprise с чистым EAP/MS-CHAPv2 ? Не припоминаю... Любой знающий человек скажет, что должен быть еще туннель (PEAP или TLS). Так вот при наличии туннеля перехват сессии MS-CHAPv2 уже невозможен, т.к. вначале надо взломать шифрование туннеля, так что сенсация отменяется.
Однако, расслабляться еще рано. Туннель строится между клиентом и точкой доступа. Если имперсонировать точку доступа, можно спокойно заполучить и клиента, и его "чистую" MS-CHAPv2 сессию со всеми вытекающими. Отсюда вывод из категории "уж сколько раз твердили миру": ставьте сертификаты на точки доступа и включайте проверку сертификатов на клиентах.
Таким образом, для грамотно построенной беспроводной сети с WPA2-Enterprise на основе PEAP/MS-CHAPv2 новая атака не страшна. Разве что, вклиниться в канал между аутентификатором (ТД, контроллером) и AAA-сервером, но это уже не относится к WPA.
Подробности, иллюстрации и рекомендации по настройке можно почитать здесь и тут.
Еще примеры замечательного маркетинга и ньюсмейкинга на почве безопасности:
В предудущем посте, мы выяснили, что за сохранность Registry администрация ответственности не несет. В этом расскажу о том, что можно сделать своими руками по этому поводу с помошью User Profile Hive Cleanup Service (UPHClean) и утилиты ERUNT. В завершение привожу пример того, как это сделал я.
Историческая справка.
Registry, каким мы его знаем, впервые появился в Win95, и сразу стало понятно, что терять/портить его не стоит. Благо, в OC семейства Win9x реестр автоматически бекапился при старте системы. При этом держалось от двух (Win95) до пяти (Win98/ME) уровней отката. Ручной бакап тоже не представлял проблем, т.к. достаточно было перегрузить компьютер в DOS-режиме и скопировать несколько файлов в безопасное место. Также Microsoft предоставляла утилиту ERU, которая бакапила реестр прямо из Windows.
С приходом Win2000 и ее производных (WinXP/Vistal/7) ситуация изменилась в корне. В системах на основе NT файлы Registry (C:\Windows\System32\Config и %userprofile%\ntuser.dat) всегда открыты и используются. В итоге стали проявляться неприятные баги, некоторые из которых встречаются и по сей день. Почти все они являются последствиями одного сценария: какая-то программка открывает ключ в Registry и забывает его закрыть. В результате, может происходить ряд интересных побочных эффектов:
* Во-первых, если не закрыт ключ в HKCU, logoff\перезагрузка/выключение компьютера может занять оооооочень много времени - Windows терпеливо ждет, пока все программы освободят HKCU, чтобы отлогинить пользователя (чего не происходит, если глючная программка прописана как системный сервис).
* Во-вторых, некоторые изменения так и не "сбрасывались" в реестр, и в итоге не сохранялись после перезагрузки. Особенно сильно это напрягало корпоративных пользователей с Roaming профайлами, которым зачастую приходилось, к примеру, каждый раз наблюдать сообщение "Please wait while Windows configures <программка>" при запуске какого-нибудь офисного приложения. В результате в Vista/W7 мы имеем файлы транзакций реестра (regtrans-ms), которые иногда занимают больше места, чем сами файлы реестра :)
* В худшем случае при перезагрузке нарушалась целостность реестра и можно было лишиться хайва целиком (чаще всего, опять же, HKCU). Это, кстати, продолжается по сей день, довольно много шума поднимается по поводу сервиса обновляющего Google Chrome, который любит открывать много дескрипторов и забывает закрывать некоторые из них.
Проблема была настолько серьезной, что Microsoft выпустила специальный сервис "User Profile Hive Cleanup Service", который насильно отключает всех от registry при перезагрузке (правда, только для HKCU/ntuser.dat). Очень рекомендую.
Все это показало насколько целостность реестра критична для систем на базе WinNT. Тем не менее,
В NT/2000 вообще нет автоматического бакапа реестра.
В WinXP бакап реестра производится только в процессе общего резервирования системы (если выбрать Backup System State). При этом файлы ОС (~500MB) кладутся в указанный пользователем каталог, а резервная копия реестра оказывается в C:\Windows\Repair, откуда ее надо скопировать ручками (ну, или удалить 500М барахла, если вам нужно было забакапить только реестр). К сожалению, графический интерфейс Windows не позволяет выбирать подкаталоги в NUL :)
В Vista/W7 вместо Windows\Repair реестр резервируется в System32\Config\RegBack средствами встроенной задачи Task Sheduler'а (по-умолчанию 10 дней). Прогресс налицо. Но только системный реестр.
Другого простого способа бакапить реестр целиком не было, и его пришлось придумать. Так появилась ERUNT (ERU для NT).
ERUNT.
ERUNT была разработана немецким специалистом по имени Lars Hederer, и, собственно, резервирует реестр любой WinNT-подобной ОС (NT/2K/2K3/XP/Vistal/7) в заданный каталог "по-живому" (т.е. не при перезагрузке, а в любое время в процессе работы ОС).
Подробности применения можно почитать в файле readme, я же расскажу о том, чем она понравилась лично мне, и как я ее использую.
Обладает GUI и CLI для резервирования и восстановления. Очень удобно использовать GUI для тестирования, а потом закатать все в параметры командной строки и создать Task (о чем ниже). Аналогично для воостановления: для полного восстановления можно сделать простой батник, для каких-то особенных ситуаций можно запустить GUI и выбрать то, что нужно.
Позволяет выбирать хайвы (системные и пользовательские) - можно бакапить: систему, профайл пользователя, профайлы других пользователей, все вместе. Вначале у меня был план "бакапить все раз в неделю, бакапить профайл каждый день", но программка работает настолько быстро, и бакапы занимают настолько мало места, что теперь просто бакаплю все каждый день.
Восстанавливает реестр из специального загрузчика или Windows Recovery Console. Обычно, хватает консоли (т.к., фактически происходит банальная перезапись файлов).
Устанавливается через инсталлер, но, вроде, никаких файлов за пределы своего каталога не кладет, так что годна к portable-применению. В каталоге хранится .INI файл, в который можно записать значения по умолчанию, что позволяет уменьшить количество задаваемых каждый раз ключей командной строки. В любом случае, утилита восстановления работает полностью независимо.
Куча интересных опций автоматизированного бакапа. Для себя сделал следующее:
В каталоге D:\Install\__Backups\RegBackup-ERUNT\ создаются подкаталоги с датой-временем в нужном мне формате (прим. RegBackup-ERUNT\2012-04-19-17.00.04\).
В каждом таком подкаталоге лежат, собственно, хайвы registry и утилита восстановления (чтобы не напрягаться).
Хранится история бакапов за 30 дней (можно настроить по количеству, скажем, 5 последних, или по времени). Старые удаляются автоматически (отключаемо).
Если сегодня бакап уже делали - второй (третий, и т.д.) раз пропускается. (полезно, т.к. в Task Scheduler'е стоит опция "если пропущено время запуска задачи - запустить при первой возможности", таким образом могут быть запущены два бакапа за день).
Стандартные опции вроде тихого режима и т.д.
Особенно впечатлило то, что в тоге я избавился от большей части ключей командной строки, т.к. значения, по умолчанию выставленные автором, делают как раз то, что мне нужно! :) Остальное было выставлено в INI-файле и в итоге огромная командная строка была сведена к AUTOBACK.EXE <имя каталога для бакапов>\#Date#-#Time#.
В завершение прилагаю ERUNT.INI и .XML для Task Scheduler'a (к сожалению, похоже, CMS КО не позволяет грузить на сервер произвольные файлы - только картинки).
Недавно Windows преподнесла очередной сюрприз и угробила безвозвратно кусок Registry. Windows System Restore не помог. В этой части - анализ инцидента с Windows System Restore. Во второй части - о том, как это самому резервировать реестр отдельно от полного бакапа системы.
Следуя призыву тов. Зубинского писать о чем-то полезном, решил опубликовать «разбор полетов». Пишите в комментариях, нужно ли такое на этом сайте, или убираться с ним на какой-нибудь habrahabr.
Установил программку от HP. Не понравилась, решил снести. HP, видимо, решила, что их программка настолько классная, что пользователь никогда не захочет с ней расстаться. Посему, не удосужилась снабдить программку анинсталлером. Благо, Windows 7 (да и WinXP тоже) делает System Restore Snapshot перед каждой инсталляцией, чем я и воспользовался.
После восстановления и перезагрузки - "Preparing Your Desktop" и я попадаю во временный профайл. Если система создает временный профайл – значит, что-то не в порядке с оригинальным. Смотрим, чего не хватает. Понимаю, что все на месте кроме HKEY_CURRENT_USER. Иду в каталог профайла - точно - файл ntuser.dat (в котором, собственно, хранится HKCU) пропал! Ntuser.dat.log есть, файлы транзакций (.BLF, .REGTRANS-MS) есть, а самого главного - нет! Ладно, думаю, откатимся на еще более ранний Restore Point. Откатываюсь - то же самое: ntuser.dat отсутствует. Беда…
Думаю, надо пойти посмотреть в сами Restore Point’ы: в WinXP все файлы просто лежали в подкаталогах C:\System Volume Information\SystemRestore\ – можно было взять любой и ручками восстановить. Иду в вышеупомянутый каталог и вижу там …ничего! Но ведь Restore Point’ы имеются? Обращаюсь к фольклору (гуглю). Оказывается, в Vista/7 механизм System Restore перестроили и теперь каждый Restore Point – это отдельный большой файл, так просто его уже не посмотришь.
Нахожу в Интернете ценную программку System Restore Explorer, которая позволяет монтировать Restore Point’ы в файловую систему и работать с ними, как с обычными каталогами. Монтирую, убеждаюсь что в каждом Restore Point отсутствует ntuser.dat! Я ожидал, что уж что-что, а профайл будет бекапиться всегда и целиком – приятный сюрприз от Microsoft!
После исследования фольклора оказалось, что проблема возникает, если в профайлах есть symlink’и или junction’ы (у меня C:\Users ведет в D:\Users) – System Restore работает на низком уровне, и вместо копирования target’ов копирует сами ссылки. Что, в общем, даже логично, претензии снимаются: сам виноват, поленился правильно кастомизировать процесс установки Windows (на то были причины).
В итоге, пришлось восстанавливать ntuser.dat из полного системного бакапа, благо, делаю я их регулярно. Родной Windows 7 Backup создает VHD, так что можно примонтировать образ и достать нужные файлы без полного восстановления. Идем в Disk Management, Action -> Attach VHD, выбираем файл, ставим галку “Read-Only” …FAIL. Битый VHD? Нет, просто Windows не может монтировать диски, не инициализировав их (нужно записать на диск метку)! Решения проблемы может быть два:
Таки примонтировать VHD как R/W, система его проинициализирует, «признает», впоследствии можно уже будет монтировать как R/O.
Использовать программку Gizmo Drive, которая этого недостатка лишена.
Восстанавливаем из VHD ntuser.dat, ntuser.dat.log (blf и regtans-ms на самом деле не нужны) – компьютер починили! Почему Win7 Backup создает VHD, который нельзя безопасно примонтировать без танцев с бубном для меня осталось тайной… Ответ услужливо подсказывает Доктор Хауз :)
Осталось решить задачу по предотвращению подобного в будущем. В следующей части расскажу про утилиту, которая учень умело и гибко бекапит реестр.
Многие считают, что SSL (Secure Sockets Layer) и TLS (Transport Layer Security) - одно и то же. Или что SSL - протокол, применяющийся в TLS. На самом деле, это примерно так же, как считать что Windows 95 и Windows XP - одно и то же (ведь Windows же).
TLS - результат эволюции и закрытия немалого количества дыр в протоколе SSL. Таким образом SSL - старый и небезопасный. TLS - новый и пока (тьфу-тьфу в версиях 1.1 и 1.2, но не 1.0) безопасный.
К сожалению, многие, не зная этой разницы, конфигурят именно SSL или только SSL (т.к. он доступен по умолчанию в большом количестве серверного ПО, а для TLS нужно скачать какой-нибудь дополнительный модуль), ну и потом попадают.
HTTPS (тот самый который отвечает за защищенные соединения в браузерах) может работать как поверх SSL, так и поверх TLS, смотря как сконфигурирован веб-сервер. Так что к нему относятся все перечисленные выше соображения. К сожалению, даже если сервер сконфигурирован для TLS 1.1 и 1.2 - не факт, что ваш браузер его поддержит. Я писал об этом еще в 2011, но воз пока и ныне там. Вроде, NSS с поддержкой TLS 1.1 таки выйдет в этом году, и мы наконец увидим его в FF/Chrome/Safari и куче другого опенсорсного ПО.
Так что:
а) не все "безопасные" соединения одинаково безопасны:
б) тем не менее, масштаб проблемы несколько преувеличен, все лечится правильной конфигурацией.
Хозяйке iPhone 4 на заметку. Наткнулся на любопытную выдержку из сертификационного отчета FCC по iPhone 4:
Табличка показывает распределение мощности Wi-Fi адаптера (Transmit Power) iPhone 4 в спектре 2.4GHz.. Как видите, по краям спектра мощность на 4.5dBm ниже, чем в середине - а это почти в три раза! Такой разброс обусловливается требованиями регуляторщиков к порядочному поведению по отношению к соседним частотным диапазонам (т.к. Wi-Fi - широкополосная технология и энергия спадает не сразу). Так что данную тенденцию можно экстраполировать и на другие телефоны, планшеты, и т.д.
Вывод: если ваш любимый гаджет плохо работает в туалете - переведите роутер на канал 6. :) Спасибо конкурентам за наводку :)
Размышления в свете анонса ряда новых продуктов. Приглашаю к дискуссии.
Все малые офисы, будь это главный офис конторы из 12 человек или один из магазинчиков огромного сетевого ритейлера, имеют одни и те же проблемы в плане ИТ-инфраструктуры:
Необходимость ее поддержания в работоспособном, актуальном, управляемом и безопасном виде
Отсутствие локальных специалистов
Вероятность переезда
Производители сетевого и серверного оборудования и корпоративного ПО, в принципе, неплохо позаботились о решении этих проблем:
Виртуализация позволяет обойтись одной-двумя физическими машинами.
Интегрированные роутеры (а-ля ISR) позволяют свести в одном устройстве функции роутера, Wi-Fi контроллера, IP АТС, сетевых сервисов типа DNS/DHCP/VPN/AAA и т.д. Иногда в довесок можно получить встроенную точку доступа или DSL-модем.
Использование Wi-Fi избавляет от прокладки и перепрокладки кабелей при переезде.
Почти все это добро разворачивается, мониторится и админится удаленно – решений предостаточно.
Так что для по-настоящему маленьких офисов всю инфраструктуру можно свести к двум коробкам (Branch Router с Wi-Fi и сервер) и двум кабелям (сервер<->роутер, роутер<->провайдер). Для бОльших офисов придется добавить UPS, дополнительные точки доступа Wi-Fi и, возможно, LAN-коммутатор. Только вот, кто-то должен все это продумать и внедрить. При чем, отдельно для серверной части, и отдельно – для сетевой. Почему же не пойти дальше?
Motorola Solutions анонсировала в начале этого года (и собирается продавать в скором времени) нечто под официальным названием "NX Series Integrated Services Platform" (NX4500, NX6500, NX9500). Перед тем как продолжить рекомендую посмотреть 5-минутный ролик. Хоть он и ориентирован на ритейл, ясное дело, работать будет и в других сферах.
Рабочее название продукта было Branch Office Box, что на мой взгляд, гораздо точнее отражает суть. В одной такой коробке формата 19” (2RU) можно получить следующее:
Сетевое решение на основе современной распределенной платформы WiNG5 включающее в себя:
Роутер со всеми необходимыми фичами, включая VPN, NAT, OSPF и PBR.
Firewall может поддерживать т.н. «роли пользователей»: помимо типичного статического назначения ACL’ов на интерфейсы можно назначать ACL непосредственно пользователям (динамически меняя их в зависимости от контекста, например, при роуминге)
Централизованное иерархическое управление и кластеризацию
Платформу, способную запускать виртуальные машины. Motorola предлагает следующие решения в виде отдельных VM:
Поддержка проводной и Wi-Fi телефонии
VoWi-Fi решение TEAM, которое может работать как с встроенной IP АТС (на основе Asterisk), так и с внешней IP/не-IP АТС
Функции вроде IVR, FMC, IP Push-To-Talk, интеграции с рациями и др.
Софт-фоны для WM, Android, iOS, PC
«Большая» WIPS на основе AirDefense
Решения для мониторинга и траблшутинга локальной сети (с большим уклоном в сторону WLAN: визуализация покрытия, спектральный анализ, сбор пакетов, аналитика и т.д., чтобы админам не приходилось постоянно выезжать на места).
Сервис отслеживания местоположения пользователей RTLS (более интересен для ритейлеров, для понимания перемещения покупателей по магазину)
Позволяет связать RTLS с бизнес-логикой(!)
Решения для Task/Workforce Management (интересно для магазинов/складов/клиник и т.д., где нужно раздавать задания работникам и следить за их исполнением)
Mobile Device Management, включающий BYOD
Возможность запуска своих VM (NX6500)
В общем, выглядит как-то так:
При этом, все это дело
Локально управляется с единой консоли
Централизованно управляется из центрального офиса с большой коробки NX9500
Работает в составе распределенной системы WiNG5
Может управляться собственным ИТ или отдаться на аутсорсинг
С технической точки зрения – ничего нового: всего лишь специального вида сервер, на котором крутятся виртуальные машины. Даже сетевые функции на самом деле реализованы в виде отдельной VM (которая крутится на отдельно выделенном процессоре, чтобы спокойно обеспечивать QoS и т.д.). Идея Virtual Appliances далеко не нова, к тому же, ряд вопросов по управлению VM (доставка, ограничения, кластеризация) не раскрыт.
С бизнес-же точки зрения – можно построить произвольное количество средних размеров офисов/складов/супермаркетов/клиник или чего-то еще на базе одной вот такой коробки, UPS и определенного количества точек доступа. При этом все это дело легко и просто (и значит, недорого в плане OpEx) централизованно управляется, распределенно работает, растет, меняется и масштабируется без особых проблем вместе с задачами бизнеса.
Выглядит очень просто, логично и потому заманчиво. Лично мне такая идея (при условии грамотной реализации) очень даже нравится. Как вы считаете - получится?
В конце прошлого года 802.11n окончательно подмял под себя (как минимум в плане поставок чипсетов) все предыдущие стандарты Wi-Fi - некоторые эксперты озвучивали цифры порядка 70%. Распробовав высоких скоростей публика хочет больше, и в наследники прочат 802.11ac, обещая до 1Gbps. Что это такое и так ли все просто? Давайте разберемся.
Что со скоростью?
802.11n использовал следующее для увеличения пропускной способности:
Оптимизированные мезанизмы модуляции и передачи пакетов позволяли "прорваться" с 54Mbps до ~75Mbps
Затем включался Channel Bonding - каналы шириной 40Mhz (в два раза шире традиционных 22Mhz) обеспечивали удвоение скорости - до 150Mbps.
Затем включался механизм Multiple Spatial Streams, коих по стандарту может быть до четырех, что позволяет достичь в теории 150*4 = 600Mbps
802.11ac собирается "догнать и перегнать" следующими способами:
Каналы шириной 80Mhz и 160Mhz, что позволяет моментально удвоить/учетверить результаты 802.11n.
Максимальное число Spatial Streams увеличили до 8, что позволяет еще раз удвоить скорости.
Оптимизация модуляции и методов передачи пакетов позволяет выжать еще немного ресурса и добиться того, что высокие скорости будут доступны не только в радиусе 4м от точки доступа.
Итого, сложив все факторы, мы можем получить скорость в теории в восемь с лишним раз превышающую показатели 802.11n - порядка 5Gbps. Маркетологи ликуют, пипл хавает. На практике, же, такая скорость практически недостижима:
Новые каналы уже не влазят в диапазон 2.4Ghz, поэтому 802.11ac будут работать только в 5Ghz. Но и в 5Ghz не все так просто. В той же Европе беспроблемно можно работать только на первых четырех каналах: 36/40/44/48 - на остальных необходимо включать DFS/TPC (сосуществование с радарами), что исключает возможность построения мало-мальски надежной сети. А в эти 4 канала влезет только 1 канал 802.11ac, да и то "всего-то" на 80Mhz. В качестве упражнения попробуйте посчитать сколько 160Mhz-каналов впишется в весь диапазон 5Ghz в разных регионах. Некоторые надежды возлагают на 802.11ad - версию стандарта, работающую в 60Ghz, но этот частотный диапазон пока четко оформлен только в США, и дальность связи в нем измеряется десятками метров (что очень неплохо для того, чтобы сбросить видео с телефона на телевизор или пользования беспроводной мышкой, но не для бизнес-сегмента). Так что, делим скорость пополам.
8 Spatial Streams требуют радиомодуля с 8 антеннами и подходящей обстановки (чтобы все 8 потоков в итоге сошлись на клиенте). Как будет выглядеть Dual-Radio точка доступа с 8x8:8 MIMO (16 антенн при Dual Radio!) остается только гадать :) Мобильные устройства, скорее всего, не пойдут дальше 4x4:4 из-за необходимости экономить электроэнергию и пространство в корпусе. Так что, режем скорость еще пополам.
Итого получаем максимум удвоение скоростей 802.11n - что само по себе все равно не плохо.
Почему же мы все равно перейдем на 802.11ac?
Помимо скоростей, 802.11ac предлагает два ключевых улучшения:
Beamforming - возможность динамически менять диаграмму направленности антенн (что реально для антенной решетки из 8 элементов). В идеале, это обозначает, что зона покрытия точки доступа оптимально подстраивается под текущее расположение клиентов. Beamforming не нов для Wi-Fi, тот же 802.11n описывает Beamforming как часть стандарта. Но часть опциональную! В 802.11ac он станет частью обязательной. Пока неясно как именно будет работать Beamforming в 802.11ac и будет ли от него в итоге хоть какая-то польза, но совершенно очевидно, что вводится он для максимизации эффекта следующего (и основного) улучшения.
В 802.11ac наконец-то появится MU-MIMO! Сети Wi-Fi - полудуплексные: пока один передает - остальные слушают. Пакеты передаются последовательно - в один момент времени передается один пакет. Если по "трубе" в 450Mbps (802.11n 3x3:3 MIMO) идет поток в 1Mbps - используется 1/450 полосы пропускания. Если при этом прибывают данные для другого клиента - использовать незадействованную полосу пропускания не удастся. В итоге толку от сверхвысоких скоростей 802.11n в сетях с большим количеством небыстрых клиентов (т.е. корпоративных) очень мало. MU-MIMO позволяет разбить "трубу" на несколько "трубок меньшего диаметра" и передавать данные по ним параллельно. Эта технология хорошо известна телекомщикам. Пока что, говорят о двух вариантах реализации MU-MIMO в 802.11ac: SDMA (Space Division Multiple Access) позволяет передавать данные разным клиентам по разным Spatial Streams (вот где нужен Beamforming!), Downlink MIMO позволяет разбить поднесущие OFDM на группы, и динамически (вроде-бы) выделять каждому клиенту нужное число поднесущих. Таким образом, даже если на точке доступа будут сидеть клиенты 2x2:2 MIMO - все равно можно будет использовать весь потенциал "трубы".
Итого
Как видно, даже если ограничить максимальную скорость одним Gbps, стандарт 802.11ac обещает существенные выгоды как для домашних (высокие скорости), так и для корпоративных сетей (эффективная утилизация этих самых высоких скоростей в сетях с большим числом клиентов). Кроме того, для поддержки новых радиорежимов нужно целиком и полностью менять все оборудование, что обещает существенные выгоды вендорам и интеграторам - все довольны, в общем :) В настоящее время ожидается, что стандарт будет ратифицирован в конце 2012/начале 2013 года, однако наболее оптимистично настроенные вендоры уже представили чипсеты и продукты на их основе на CES-2012. Уготована ли 802.11ac судьба 802.11n, принятого на несколько лет позже, чем ожидалось, покажет время. Ждем-с.
