В предудущем посте, мы выяснили, что за сохранность 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, принятого на несколько лет позже, чем ожидалось, покажет время. Ждем-с.
В очередной раз читаю про "Еще одна компания заплатит отчисления 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 считаются устаревшими, TLS1.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;
Недавно узнал о ряде уязвимостей в оборудовании 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-кодом с телефона уже не модно :) Правда, возникает много вопросов в смежных сферах, вроде безопасности, уж слишком мало подробностей пока известно об этой инициативе.
На сайте Motorola Solutions есть около 70 опубликованных Case Studies, количество публичных заказчиков подбирается к 200, о количестве непубличных остается только догадываться :) RIFD Journal (на который я сегодня постоянно ссылаюсь) публикует по нескольку публичных кейсов в неделю, что происходит в зоне Member Only - не знаю. Даже Беларусы внедряют RFID системы (не без нас). Жизнь кипит, а Украина пасет задних: у нас частотами UHF эксклюзивно владеет УкрЗализныця со своим САИПС - довольно интересной разработкой времен СССР, которая благополучно скисла после развала Союза. Конверсии, вроде, не предвидится...
