В очередной раз читаю про "Еще одна компания заплатит отчисления Microsoft с Android" - очередная великая победа M$ над Google!

В "штатном" комплекте Android есть доступ к Exchange (Exchange AirSync - EAS). Он лицензируется (причем, поштучно!). Все, кто использует EAS в своих продуктах платят $$$ M$ с каждого устройства. И купить лицензию, а потом делиться её "с миром" нельзя. Так что, нет никакой разницы, кто держит права на Андроид, кто писал код и т.д. Именно поэтому, до сих пор не ни одного бесплатного приложения под не-M$ ось, которое умеет работать с серверами Exchange. Apple тоже платит, да. И никакого патентного троллинга здесть тоже нет.

А вот китайцы, которым главное сделать подешевле, просто штампуют свои устройства БЕЗ штатного почтового клиента (и сопутствующих сервисов), и имеют дядю Билла (или уже лучше говорить Стива?) в виду.

Зато вокруг - сплошная победа пиара над здравым смыслом и ни разу не указали, за что именно платят...

Несколько удивился, не увидев этого в новостях КО. На прошлой неделе была презентована атака, по сути, позволяющая взламывать HTTPS-сессии (естественно, с ограничениями, куда без них). В качестве примера приводится расшифровка cookies и последующий «угон» сессии PayPal за 10 минут! Конец безопасному е-мейлу, онлайн-банкингу и шоппингу?! Паниковать или нет?! Будем разбираться.

Атака построена довольно хитро. Атакующий умудряется вбрасывать пакеты в зашифрованный канал, при этом перехватывая шифрованные пакеты. В результате умелого использования уязвимостей блочного шифрования SSL3.0/TLS1.0 атакующий расшифровывает необходимые ему данные. Потом – делает что хочет. Особенность этой атаки в том, что база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами) здесь требуется значительно меньшая (за счет умелого вброса правильно сгенерированных пакетов) – утверждается, что сессию можно вскрыть за 10-30 минут.

Для начала несколько интересных и волнительных фактов:

• Обычный пользователь проводит за онлайн-шоппингом/банкингом/платежами/почтой более 10-30 минут за сессию, так что угроза вполне реальна (достаточная база для криптоанализа).
• Атака производится на протоколы SSL 3.0 и TLS 1.0, используя ряд уязвимостей, известных начиная с 2006 года (5 с гаком лет!)
• Многие из этих уязвимостей в SSL3/TLS1.0 никогда не были закрыты
  • Потому и SSL и TLS 1.0 считаются устаревшими, TLS 1.1 (не подверженный этой уязвимости) был выпущен в 2006 году, TLS 1.2 – в 2008 и обновлен в 2011.
• Так что, получается, нет проблемы? Проблема есть!
  • Большинство браузеров не поддерживают TLS1.1+ (пока что – только IE8+/Win7 и Opera10+)
  • А те, что поддерживают, не включают по умолчанию. А почему?
    • А потому, что большинство веб-серверов не поддерживают TLS1.1+ (или он не включен по умолчанию, а админ не почесался).
• Кроме того, даже SSL3.0/TLS1.0 не подвержены этой атаке, при использовании потоковых шифров (RC4, тоже не самый надежный вариант, однако).
  • Но многие сайты не поддерживают и этот механизм! Плюс, так как RC4 слабее, скажем, AES, по умолчанию будет выбран блочный режим с AES, оказавшийся уязвимым (блочный режим, не AES).

В общем, получилась ситуация «верхи не могут, низы не хотят»: если бы проблема было только на стороне клиента – все бы решилось быстрым обновлением браузеров. Но тут, похоже, придется обновить «весь Интернет».  Вот выдержка из новости с красноречивой статистикой:

«Как обнаружили исследователи из компании Opera, только 0.25% сайтов поддерживают TLS 1.1, TLS 1.2 поддерживают 0.02%. Несмотря на то, что спецификации TLS 1.1/1.2 были разработаны достаточно давно, поддержка этих протоколов в некоторых популярных браузерах всё ещё не реализована. Это создаёт проблему для владельцев сайтов, которые хотели бы обновиться, но из-за боязни потерять клиентов делать этого не хотят»

Внизу поста есть секция с подробностями для любопытных, а пока разработчики браузеров, веб-серверов, библиотек SSL/TLS и прочие вебмастеры будут искать способ спасения мира, нам пользователям, необходимо решить важнейший вопрос:

К счастью, особого повода для паники нет. Атака опирается следующие факторы:

• Возможность перехвата трафика;
• Использование блочных шифров (CBC) в SSL3.0/TLS1.0;
• Достаточная база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами);
• Возможность вброса данных.

С первым фактором сделать ничего нельзя. Как только мы отправили пакет, мы его уже не контролируем. А вот с остальными – можно:

Администраторы веб-сайтов могут оперативно включить поддержку RC4 (или выставить ее более приоритетной, чем всякие блочные режимы). Google, как выяснилось, уже давно использует этот метод, так что GMail, GDocs, G+ и иже с ними – в относительной безопасности.

Аналогично, пользователи могут открутить поддержку всех блочных Cipher Suites (*_CBC_*) в браузере/ОС (и заодно поддержку SSL3/TLS1.0, если браузер позволяет). Правда, при этом некоторые сайты могут отказаться работать, но тут уже пользователю решать: или потенциальный риск, или потерпеть без данного ресурса.

Можно ограничить длительность сессии. С той же почтой можно работать не через браузер, а через почтовый клиент, а там TLS сессии будут покороче. На худой конец – периодически делать logout J.

И самое интересное – возможность вброса данных. Здесь используется всеми любимый XSS, но в новой форме. Как обычно, плагин NoScript для Firefox выручает.

Стараясь сохранить баланс между количеством подробностей, интересностью и краткостью изложения, завершу заметку здесь. Сухой остаток:

• Проблема есть, она реальна;
• Для реализации атаки не понадобилось открывать ни одной новой уязвимости – все было известно много лет;
• Неизвестно, сколько лет этот баг УЖЕ эксплуатировали;
• С проблемой можно бороться, если знать как.

В ближайшее время ожидаю всплеска постапокалиптических новостей на тему «конец Интернета», потом волны апгрейдов и глюков на веб-сайтах, потом все вернется на круги своя.

Ситуация на данный момент:

• Браузеры:
  • Поддерживают TLS1.1+ только Opera 10+ и IE8+/Win7;
  • «В работе» Chrome и Firefox;
  • Любой IE под WinXP и Vista – не поддерживает (т.к. IE полагается на средства ОС);
  • Safari/OSX – не поддерживает, и Джобс его знает, что будет дальше.
• Серверы:
  • Поддерживают TLS1.1+: IIS7+, mod_gnutls для Apache;
  • OpenSSL (наиболее популярный) поддерживает TLS 1.1 только в бетах;
  • NSS (Chrome, Firefox и серверные реализации для Apache, Java и т.д.) поддерживает TLS1.1+ очень ограниченно;
  • Все остальное – не поддерживает.

Сравнительно свежий документ, который расписывает, какие браузеры и веб-серверы что поддерживают (заодно приводит краткий экскурс в историю SSL/TLS).

Две подробных статьи с анализом:

• http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
• http://www.imperialviolet.org/2011/09/23/chromeandbeast.html

Недавно узнал о ряде уязвимостей в оборудовании WLAN, позволяющих проводить довольно забавные, на мой взляд, атаки.

1. Cisco SkyJacking. Довольно старая (сейчас неактуальная) проблема, которая позволяла "угонять" точки доступа Cisco. Фактически, можно было заставить точки работать с чужим контроллером (т.к. контроллер может управлять точкой и по беспроводному соединению).  Основных сценариев развития событий было три с половиной:

• DoS-атака (банально отобрать все точки).
• Имперсонация (вот почему важна аутентификация не только клиента, но и сервера) со всеми вытекающими.
• Если точка подключена к проводной сети - можно забраться и в нее, т.к. мы рулим точкой и вольны ее конфигурировать как хотим.
• (полсценария) Если развернут Cisco WIPS - можно отобрать у него сенсоры и спокойно наплевать на его присутствие :)

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

2. Aruba SSID XSS. Эта проблемка уже посвежее. Как выяснилось, веб-интерфейс контроллеров Aruba (и заодно системы управления Aruba Airwave) некорректно обрабатывает некоторые строки, что позволяет провести XSS-атаку и выполнить скрипт на контроллере с правами админа (т.е. спокойно переконфигурировать систему, например, добавив пользователя в локальный RADIUS-сервер и сменив шифрование на WEP). XSS'ом нынче никого не удивишь, однако, интрига заключается в том, как сделать так, чтобы эти строки появились в веб-приложении UI контроллера - оно ведь по интернетам не ходит... Вот тут и проявляется "забавность" - достаточно принести свою точку доступа с "правильным" хитро составленным SSID и оставить дожидаться, чтобы сисадмин зашел в нужный раздел Web UI :)

В общем, по очевидным причинам с возрастанием сложности архитектур беспроводных сетей, возрастает и вероятность ошибки разработчиков ПО и прошивок. Но если раньше атаковали в основном криптозащиту и пользователей, то сейчас начинают открыто атаковать инфраструктуру, при чем аналога подобных атак в чисто проводной/Интернет-среде я припомнить не могу. Вот вам еще один аргумент в поддержку моего утверждения о том, что беспроводные IPS скоро будут очень актуальной темой (т.к. в данной ситуации обе атаки запросто ловятся и нейтрализуются правильной и правильно настроенной WIPS). А вы как считаете?

Давненько я не писал про RFID. Технология, которая еще несколько лет назад считалась чем-то очень странным и специфическим, за 2010-2011 годы подобралась к той степени принятия в индустрии, которую не так давно прошел Wi-Fi. Смотрите примеры:

EAS: все прекрасно знают антенны противокражных систем (EAS), стоящие на входах в почти любой крупный магазин. Еще 3 года назад все (в т.ч. и я сам) говорили "UHF RFID не заменит EAS - слишком ненадежна". Начиная с прошлого года Motorola Solutions с партнерами реализовала несколько проектов EAS на UHF RFID. И вот теперь Checkpoint (один из крупнейших производителей EAS-решений) выпускает EAS на ее основе! В качестве преимуществ - большая дальность и возможность разместить под потолком, избавившись от "воротец".

Пассивные метки с датчиками. Еще в прошлом году (да и в начале этого), наличие датчика (освещенности, температуры, влажности, и т.д.) на метке автоматически означало наличие батарейки, что переводило метки в разряд полуактивных (battery-assisted), удорожало их, и заставляло задуматься о том, как эти батарейки менять (в большинстве случаев - никак, выкидывали вместе с меткой). В последние пару лет именно в этой сфере можно было увидеть последние разработки в виде гибких батарей толщиной немногим более листа бумаги "раскатанных" по подложке вместе с меткой. И вот теперь - первые полностью пассивные метки с датчиками! Скажем так, медицина (датчики пульса и давления) и перевозчики скоропортящихся продуктов (рыба, фрукты, ягоды, где используются датчики температуры и нарушения целостности контейнера) и армия (транспортировка ящиков с оружием и боеприпасами) только что сэкономили порядочно денег и на CapEx и на OpEx.

Вживляемые метки. Еще пару лет назад говорили: "Зажми метку подмышкой - читаться не будет". И правда - человеческое тело состоит по большей части из воды, которая чрезвычайно эффективно поглощает и рассеивает радиоволны в UHF-диапазоне. Если RFID-метки и вживлялись раньше - то под кожу на небольшую глубину. И вот теперь - Ortho-Tag - метка, вживляемая в ортопедические имплантанты, в т.ч. искусственные кости и суставы, вокруг которых полно мышц, сосудов и т.д. Правда, для успешного считывания ридер приходится подносить вплотную к пациенту, так что есть еще куда расти :) (наглядной картинки не нашел)

Ну и немного россыпью интересности про не-UHF RFID:

• Компактная метка с датчиком температуры для мониторинга процесса приготовления мяса (в промышленных масштабах). Втыкается как булавка в мясо, и едет с ним по конвейеру через все стадии приготовления, фиксируя и рапортуя температуру, чтобы не испортить продукт. Активная, 433Mhz.
• Метка с датчиком, стоящая в реактивном двигателе истребителя и получающая энергию от его тепла. Применяется для мониторинга состояния этого самого двигателя (подшипников турбины и т.д.). Не знаю, можно ли назвать температуру работающего двигателя "теплом", но впечатляет! О технологии остается только догадываться.
• SAS (Скандинавские Авиалинии, часть Lufthansa) начинает раздавать наклейки с NFC-метками для участников программы Frequent Flyer. Теперь чекиниться с 2D-кодом с телефона уже не модно :) Правда, возникает много вопросов в смежных сферах, вроде безопасности, уж слишком мало подробностей пока известно об этой инициативе.

В общем, RFID шагает по планете. Причем, семимильными шагами, напоминая бум Wi-Fi пару лет назад. Это уже не мистика - это реальный инструмент повышения эффективности работы.

На сайте Motorola Solutions есть около 70 опубликованных Case Studies, количество публичных заказчиков подбирается к 200, о количестве непубличных остается только догадываться :) RIFD Journal (на который я сегодня постоянно ссылаюсь) публикует по нескольку публичных кейсов в неделю, что происходит в зоне Member Only - не знаю. Даже Беларусы внедряют RFID системы (не без нас). Жизнь кипит, а Украина пасет задних: у нас частотами UHF эксклюзивно владеет УкрЗализныця со своим САИПС - довольно интересной разработкой времен СССР, которая благополучно скисла после развала Союза. Конверсии, вроде, не предвидится...

Заканчиваем разговор, начатый в первой и второй частях. Сегодня будем разбираться с безопасностью.

Как уже упоминалось раньше, Wi-Fi Direct поддерживает WPA2-PSK для шифрования данных и WPS для безопасного установления соединения. WPA2 использует AES (и отключить его нельзя), а WPS использует EAP. Теоретически, это почти эквивалент WPA2-Enterprise, чего должно быть вполне достаточно для безопасной работы домашних пользователей. Однако, поскольку установление соединения теперь происходит а-ля Bluetooth, есть вероятность того, что все методики атаки BT теперь будут применимы и для Wi-Fi Direct. Наиболее вероятным сценарием представляется имперсонация HostAP и последующий Man in The Middle. Обе эти атаки работают на «8 уровне модели OSI» (человеческом) и не зависят от наличия технических мер защиты, таких как AES и EAP. (Тут можно рассказывать про защищенное туннелирование EAP, но успешные MITM-атаки на SSL показывают, что никакой пупер-механизм не защитит от невнимательности пользователя). Более общий, но сложнее реализуемый вариант – эксплуатация уязвимостей в драйверах/прошивках Wi-Di периферии и использование их как прокси для атаки других участников сети. Тут уж как повезет с разработчиками прошивок и драйверов.

В любом случае, для домашнего пользователя риск относительно невелик. Однако все становится серьезнее, если домашний пользователь с ноутбуком/смартфоном с поддержкой Wi-Di пришел на работу и подключился к корпоративной сети. Вдумайтесь – к вам в офис с утра «пришли» 50 точек доступа, и контроля над ними у вас нет! Описывать последствия, думаю, не имеет смысла. Кроме того, можно реализовать Man In The Middle, имперсонировав «легальное» периферийное устройство Wi-Fi Direct.

Все эти проблемы («корпоративный компьютер с подключением к LAN и включенным Wi-Fi», «подключение корпоративного компьютера к некорпоративной точке доступа», «Несанкционированная точка доступа в сети» она же Rogue) известны достаточно давно, просто с распространением WI-Fi Direct вероятность возникновения этих ситуаций увеличится в разы. Традиционный способ защиты: разрешить иметь только одно активное сетевое подключение, разрешить подключаться только к корпоративным ТД, использовать систему выявления и подавления чужаков. Правда это, фактически, обозначает, полный запрет Wi-Fi Direct (то же самое случилось с Ad-Hoc). Вопрос, только, как следить за выполнением этого запрета? Если компьютеры пользователей еще находятся (иногда) под контролем ИТ, то, скажем, смартфоны – уже нет. Поэтому помимо административных мер, нужны еще технические средства.

Традиционно, для «отлова и отстрела» Ad-Hoc применялись Wireless IPS. Wi-Fi Direct, скорее всего, только поспособствует росту спроса на них. Wireless IPS позволяет анализировать трафик в эфире и банально «отстреливать» все подключения «наших» устройств к «чужим», и наоборот. Таким образом, пока что, это единственная более-менее эффективная мера защиты сразу от Ad-Hoc, криво сконфигурированного Wi-Fi, попыток подключения в обход корпоративной сети, «слива» и до, которая не зависит от типа устройства. Последнее важно, т.к. не на всё можно поставить политику и следить за ее выполнением, как было упомянуто выше,

Подытоживая хочется сказать, что Wi-Fi Direct – это хорошая и полезная инициатива направленное на упрощение жизни рядовых человеков без существенного ущерба их безопасности, однако ценой некоторого бардака в эфире и головной боли корпоративных администраторов. Консумеризация ИТ - это, конечно, заманчиво - но домашнее держите дома :)

В первой части мы разбирались, что такое Wi-Fi Direct и чем он хорош. Во второй – будем разбираться, чем он плох, и о чем молчат маркетологи.

Начнем с простого и очевидного:

• Во-первых, Wi-Fi Direct намного более энергоемкий, чем BT. Тем более, с учетом AES. Кто уже помнит телефоны, работавшие без подзарядки неделями? С передачей потокового видео по Wi-Di счет может пойти на часы.

Кроме того, именно из-за этого фактора, восклицания об «убийце BT» стоит считать преувеличенными. В особенности на фоне принятия Bluetooth 4.0 и профилей с очень низким потреблением энергии, Можно говорить о вытеснении BT Wi-Fi Direct’ом в сегменте популярной бытовой электроники, но не более. Если уж кто и «приговорит» BT, то это будет ZigBee (или новая технология производства аккумуляторов радикально большей емкости).

• Во-вторых, повышенная дальность Wi-Di – это тоже не всегда хорошо. Повышенная дальность означает, что вас можно ломать с большего расстояния, что вы будете создавать больше помех соседям, а соседи – вам.

• В третьих, совместимость. К примеру, HP Wi-Fi Direct Mobile Mouse работает только с Windows 7 и Mac OS X, при этом для Windows 7 еще требуется соответствие HCL (очевидно, из-за использования MS Virtual Wi-Fi, благо ответ здесь "скорее да, чем нет").

Но это мелочи, для разогрева. Есть две действительно существенные проблемы.

1. Бардак в эфире.

Вот в этом интервью одним из преимуществ Wi-Di называется повышенная пропускная способность по сравнению с работой на ТД. Мол, чем больше устройств сидит на точке доступа, тем медленнее каждое работает, а с Wi-Di пара устройств может «спрыгнуть» с точки и работать напрямую, что будет быстрее. Я согласен с первой частью утверждения, но вывод о том, что Wi-Di будет работать быстрее – типичное маркетинговое обобщение.

Пока все устройства сидят на точке доступа, она имеет возможность контролировать процесс передачи данных, т.к. все устройства сидят в одной сети и играют по одним правилам. Даже если все происходит медленно, у вас есть контроль. Как только часть устройств спрыгивает с точки, объявляет суверенитет и запускает свою автономную сеть – у вас только что появился неконтролируемый источник интерференции. И чем больше таких отдельных Wi-Di сетей запущено – тем более замусоренным становится эфир, и тем медленнее работают ВСЕ. Кроме того, если в традиционной ситуации с точками доступа канальная обстановка достаточно стабильна (после того как точку поставили и настроили, она уже редко меняет канал и мощности), то тут все наоборот – устройства приходят и уходят, вещают на разной частоте и мощности. Одним словом – бардак. Вспомните о нашумевшем конфузе c Wi-Fi на презентации Apple (да и не только Apple) – Wi-Di на один шаг в приближает нас в этом направлении.

Интересно то, что эта проблема может быть актуальной как для домашних пользователей, так и для корпоративных беспроводных сетей. В спальном районе с многоэтажками 30-35 «соседей» с Wi-Fi – уже не предел. Если каждый пользователь обзаведется устройством с Wi-Di – количество сетей удвоится (точки-то никуда не денутся). В итоге сценарии с передачей потокового видео уже выглядят не так реалистично, если рядом кто-то будет играть по другой Wi-Di сети в StarCraft, а еще кто-то рядом будет по третьей сети передавать файлы на высокой скорости. Говоря языком техническим, стоит ожидать значительное увеличение и без того немалого джиттера.

Для корпоративных пользователей приход Wi-Di устройств типа вышеупомянутой HP Wi-Fi Direct Mouse обозначает хаотическое появление/исчезновение блуждающих неконтролируемых источников помех и постоянные пертурбации в тщательно спланированном канальном плане. Конечно, не все так плохо, но если где-то в офисе (например, в зоне Hot Desk) соберутся 10-20 человек с такими мышками и смартфонами с включенными SoftAP – я бы сильно забеспокоился о работоспособности, например, VoWLAN в этой соте.

К счастью, проблема может быть и не актуальной: все будет зависит от конкретных устройств и модели использования, - тут как повезет. Опять же, я не хочу сказать, что все так плохо. Я хочу сказать, что не все так хорошо. :)

Второй серьезный источник беспокойств – безопасность. Вроде-бы, Wi-Di рассчитан на домашних пользователей, и риски довольно небольшие. Однако существенным аспектом является то, что в наш век ноутбуков и смартфонов корпоративные пользователи – это пришедшие на работу домашние. Тут необходимо будет совершить еще один экскурс в эпоху Ad-Hoc, поэтому поговорим об этом аспекте в следующей части.

Без комментариев, просто выдержка из текста стандарта 802.11i-2004 (лежащего в основе WPA2), секция H 4.1 (страница 165):

A passphrase typically has about 2.5 bits of security per character, so the passphrase of n bytes equates to a key with about 2.5n + 12 bits of security. Hence, it provides a relatively low level of security, with keys generated from short passwords subject to dictionary attack. Use of the key hash is recommended only where it is impractical to make use of a stronger form of user authentication. A key generated from a passphrase of less than about 20 characters is unlikely to deter attacks.

Так вот, у кого пароль к домашней точке состоит из 20+ символов?

UPD: что интересно, в стандарте 802.11-2007 убрали упоминания 2.5+12 бит, но 20 символов оставили слово в слово.

Нашел в интернете компактные описания классических L2 атак: ARP Poisoning и DHCP Spoofing. Классические методы противодействия - ARP и DHCP Inspection на коммутаторе. А вот в случае беспроводной сети - уже так просто не отделаться.

Причина проста - в случае Ethernet-коммутации все пользователи сидят в отдельных L1 доменах, и общаются через центральную точку (коммутатор), который создает L2 домен и обладает полным контролем над трафиком. Достаточно настроить правильные фильтры на портах - и дело сделано.

В случае Wi-Fi все сидят в одном L1 домене. Поэтому фильтруй-не фильтруй, а пакеты проходить будут. Теоретически, можно запретить мобильным устройствам общаться напрямую, но:

• Большинство реализаций firewall'а на точках доступа фильтруют трафик между беспроводным и проводным интерфейсами, и не могут фильтровать трафик между двумя беспроводными клиентами. К сожалению, это так почти для всех вендоров первого эшелона Enterprise WLAN.
• То, что точка предписывает клиентам не общаться напрямую, еще не значит, что они не будут. Модифицировать драйвер для игнорирования этой опции не так и сложно.

Корпоративные пользователи могли бы тут возразить, что все это проблема открытых хотспотов (если только вы не корпоративный пользователь предоставляющий хотспоты) и прочих домашних/гостевых сетей. И я бы согласился, если бы не проблема украденных ноутбуков/смартфонов, содержащих кешированные PSK, которые в вскрываются на ура с помощью CUDA с 2008г. Так вот зная PSK можно вообще заниматься вбросом трафика в эфир не особо реагируя на все предписания и фильтрацию со стороны точки доступа (это не всегда верно, но для обсуждения этого вопроса нужно довольно глубоко погружаться в детали).

Использование 802.1/EAP, который как бы безопаснее (никаких PSK не хранится, у каждого пользователя свой индивидуальный динамический ключ) не всегда спасает, т.к. для широковещательного трафика все равно используется отдельный общий для всех ключ (ну, по другому и не вышло бы, иначе это уже не броадкаст). Так что с точки зрения броадкастных атак разницы между EAP/PSK особой нет.

Кстати, именно из-за этого ключа и была поднята жутко маркетинговая буча с Hole 196 (можете почитать на сайте "изобретателей").

Кроме того, если в случае проводного Ethernet атака таки прошла успешно, то по MAC-адресу злоумышленника можно всегда вычислить порт коммутатора и отключить его удаленно. В случае Wi-Fi злоумышленника найти сложнее. Можно попытаться его отключить от точки, послав фрейм диссоциации, но опять же, подправленный драйвер может его смело проигнорировать.

Все это приводит к следующим выводам и рекомендациям:

• Если не нужно, чтобы пользователи общались друг с другом - лучше им это запретить. Просто исходя из того, что  злоумышленников с немодифицированными драйверами несколько больше, чем тех, кто сумел такой драйвер раздобыть. Заодно отсекаются всякие "развлекающиеся" сотрудники.
• В последнее время доля коммуникаций типа "воздух-воздух" в Wi-Fi сетях растет, и предпосылок для остановки этого роста нет. Так что желательно выбирать оборудование, которое уже сейчас уделяет вопросу фильтрации во WLAN досточное внимание.
• Очевидное - не стоит использовать WEP и TKIP. Скажем так, если использовать WPA2 (даже с PSK), то описаный выше вброс трафика без ассоциации с ТД становится в порядки сложнее.
• По-возможности вместо PSK лучше использовать EAP. Скажем, тот же DHCP протокол в какой-то момент переходит на unicast'ы, и они уже мимо точки не пройдут (если точка таки умеет фильтровать трафик во WLAN). Большинство нормальных точек доступа имеют встроенный RADIUS-сервер, а большинство хороших - RADIUS-прокси с возможностью интеграции с AD. Так что настройка этого механизма не так и сложна. При грамотной реализации пользователи Windows подключаются со своими обычными именем/паролем, и даже на iPhone (вот тут стоит отдать честь Apple) все довольно просто.
• Кроме того, не стоит пренебрегать опцией Broadcast Key Rotation (если она у вас есть), которая динамическт меняет GTK через заданный интервал времени. Заодно избавитесь от Hole196 :)

Ну и последнее. Как было показано выше, даже самая рассовременная фильтрация от грамотно спланированного взлома не спасет. И местоположение взломщика не выдаст. Так что в очень скором времени ни одна по-настоящему серьезная Enterprise WLAN без WIPS не обойдется. Ну, хотя бы интегрированной в контроллер. Вот так...

Да, ссылки

• атаки и защита в проводном мире: ARP Spoofing and MITM, DHCP Snooping, Dynamic ARP Inspection.

• статьи в КО по WIPS: тут и здесь

Технология Wi-Fi Direct (она же Wi-Di) была анонсирована достаточно давно и предназначена для упрощения связи между отдельными Wi-Fi устройствами. Эдакий Bluetooth на основе Wi-Fi. От Bluetooth ее отличает повышенная дальность и скорость, а от существующих сетей Ad-Hoc Wi-Fi – повышенная безопасность и простота настройки. Вроде бы все классно. Так ли это? Самое время разобраться, тем более что на Computex Taipei 2011 уже показывают рабочие образцы.

Традиционно, для организации прямой беспроводной связи между потребительскими устройствами (а именно сюда целит Wi-Di) использовался Bluetooth, отличающийся невысокой сложностью, невысокой дальностью, невысокой скоростью и невысокими энергетическими потребностями. В наше время телефонов с двухъядерными гигагерцовыми процессорами и 512 RAM хочется чего-то большего. И вот вроде есть Wi-Fi, который и дальнобойнее, и быстрее, и уже даже мыльницы с Wi-Fi выпускают, но есть один нюанс…

Согласно первоначальному замыслу, Wi-Fi умеет работать в двух режимах: инфраструктурном (с точкой доступа, выступающей в роли арбитра трафика) и непосредственном (Ad-Hoc, когда несколько устройств организовывают одноранговую сеть без точки). Со временем, инфраструктурный режим развивался и шел вперед, в то время как Ad-Hoc застрял в 1990-x ^(*): этот режим поддерживают далеко не все бытовые устройства, он медленный (на уровне 802.11b) и незащищенный (стандарт описывает два механизма: Open и WEP на уровне того же 802.11b, все остальное – не гарантирующие совместимости отклонения). В общем, Ad-Hoc неудобен, опасен и малоприменим, так что современному Wi-Fi без точки доступа не обойтись.  Однако у домашнего пользователя настройка точки доступа вызывает (небезосновательно) примерно следующие ассоциации:

Разнообразные попытки производителей «бытового» Wi-Fi упростить жизнь пользователя привели к тому, что у домашних точек доступа практически не осталось настроек, и многие из них работают на дефолтах прямо из коробки (благодаря чему мы имеем огромное количество бесплатного Wi-Fi от интернет-провайдера «сосед»). С одной стороны, это поспособствовало популяризации Wi-Fi, с другой стороны, это поспособствовало мифу о ненадежности и незащищенности WI-Fi: вспомните недавний скандал с Google, которая сниффила трафик из (о ужас!) незащищенных шифрованием Wi-Fi сетей. В настоящее время приоритеты вендоров сменились с «простой Wi-Fi» на «простой и безопасный Wi-Fi», на этой волне вначале появился Wi-Fi Protected Setup (WPS), который свел задачу безопасного подключения к точке доступа к нажатию на кнопку и/или вводу PIN-кода, а сейчас появился Wi-Di, призванный сделать то же самое с Ad-Hoc режимом.

Что-же нам должен дать WI-Fi Direct?  Прежде всего - прямое безопасное соединение между устройствами, которое

• устанавливается так же просто как Bluetooth (нужно просто выбрать устройство из списка, не думая об SSID и PSK)
• работает быстрее чем BT (почти как 802.11n)
• работает на большем расстоянии, чем BT.
• очень надежен и безопасен, в отличии от Ad-Hoc Wi-Fi. В обеспечение этого лозунга WPA2 включен постоянно, и отключить его нельзя.

Как он собирается нам это предоставить? Поскольку принятие очередной поправки к стандарту 802.11 может занять несколько лет, Wi-Fi Alliance решил исхитриться в рамках существующих стандартов и спецификаций. Фактически, в каждом устройстве Wi-Fi есть программная точка доступа (т.н. SoftAP), которая умеет заявлять о себе, о возможностях устройства (а-ля профили BT) и поддерживает WPS. В зависимости от типа устройства могут быть реализованы и дополнительные функции (например, коммутация/маршрутизация трафика или streaming gateway). Реализация SoftAP позволяет подключить к устройству с поддержкой Wi-Di «обычные» устройства с поддержкой «обычного» 802.11 (главное, чтобы поддерживали WPA2). При этом, устройство с Wi-Di может одновременно быть подключено и по Wi-Di, и к обычной ТД Wi-Fi, обеспечивая, фактически, tethering.

В результате у неподготовленного пользователя появляется возможность подключиться напрямую к принтеру для печати, фотографии с фотоаппарата напрямую улетят на цифровую фоторамку, ваш гость сможет передавать видео со своего смартфона на ваш телевизор, не тратя время на подключение к домашней сети, и т.д. И все это происходит легко и просто, без танцев с бубном вокруг ESSID, каналов, PSK и т.д. Чипсеты с поддержкой Wi-Fi Direct предлагают все крупные производители (Atheros, Broadcom, Intel, Ralink и т.д.), продукты уже должны быть доступны. Все это позволило некоторым футуристам уже заявлять о скорой смерти BT, который уступит свою нишу Wi-Di.

Все ли так хорошо? О чем не говорят маркетологи? Об этом – в следующей части.

(*) Для справки, это не единственная часть стандарта 802.11, которая осталась в прошлом. Уже не используются Frequency Hopping и Point Coordination Function, очень скоро на свалку истории отправится WEP и, скорее всего, CCK, и уж точно мало кто знает, что первая версия протокола 802.11 описывала в т.ч. передачу в инфракрасном диапазоне.

Именно так - Bees with Machineguns называется интересный открытый облачный проект, недавно попавшийся на глаза. Описывается одной строчкой: "A utility for arming (creating) many bees (micro EC2 instances) to attack (load test) targets (web applications)". 

Т.е идея заключается в том, что в облаке Amazon EC2 создается огромное количество веб-клиентов, которые [по идее] предназначены для тестирования поведения веб-приложений под нагрузкой. Но есть и другое название для нежданного тестирования поведения веб-сервера под нагрузкой:) 

DDoSaaS - новый этап принятия облачных технологий!