На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2006-6-21 на главную / новости от 2006-6-21
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 21 июня 2006 г.

Как обезопасить беспроводные технологии

Любые новые технологии — «палка о двух концах», иными словами, любая новая технология приносит ее обладателю проблемы, число которых пропорционально дивидендам, полученным с помощью использования этой новой технологии. В любом случае стоит задуматься о рисках, которые таят в себе так полюбившиеся многим беспроводные технологии, и о том, как их минимизировать.

В одном из номеров журнала «Кейс», издаваемого компанией «КОРУС Консалтинг», упоминалось об использовании беспроводной связи в крупном гипермаркете, где была внедрена ERP-система Axapta Retail. Использование карманных персональных компьютеров (КПК), оснащенных возможностью беспроводной связи, позволило расширить функциональные возможности этой системы. У работников магазина значительно сократились затраты времени на стандартные процедуры — приемку товара, инвентаризацию и многое другое. Большинство данных, например для бухгалтерии, они могут передавать прямо с собственного рабочего места. С учетом площади гипермаркета – около 10 000 кв. м – это сэкономило им массу времени.

Теперь смоделируем ситуацию: нарушителю удается продублировать ПО с настройками КПК, входящего в систему гипермаркета, на своем КПК. Нарушитель авторизуется в системе под идентификатором КПК-оригинала. После этого он может выполнять все те же действия, что и продавец. Степень ущерба для компании может стать огромной.

Чтобы избежать такой ситуации, нужно правильно оценивать риски, которые таят в себе методы аутентификации пользователей в беспроводных системах. Как и в обычных сетях, в Wi-Fi используется защита на уровне IP, для чего предназначен безопасный протокол передачи данных IPSEC. Это основа безопасности беспроводных сетей и «подводная часть айсберга», однако не стоит забывать про его верхнюю часть – аутентификацию сервера и клиента на более высоком уровне. В последнее время широко используется и протокол аутентификации на базе открытых ключей – EAP-TLS (а также его модификация при туннелировании – EAP-TTLS), он-то и служит защитой клиента и сервера от нарушителя. Этот протокол надежно защищает передаваемые данные, однако и в нем можно разглядеть недостатки: например, отсутствует возможность делегирования прав доступа от одного клиента другому.

Для чего протоколу такая «гибкость»?

Возьмем для примера проект сети крупных гипермаркетов. Допустим, КПК с соответствующим ПО есть у каждого сотрудника компании: от менеджера до продавца. Каждый работник выполняет свои функции, соответственно, менеджер назначает права (функции) своей команде работников. Для этого необходимо построить схему делегирования прав, которую можно совместить с безопасным протоколом EAP-TLS.

На мой взгляд, сегодня выбрать способ авторизации, устраивающий владельца беспроводной сети, позволяет набор протоколов стандарта 802.х и, в частности, протокол EAP-TLS, построенный на базе доверенных сертификатов (CA). В общих чертах, эта схема работает так: клиент отправляет серверу доступа случайное число с. Затем сервер доступа отправляет собственный сертификат cert(AS) и другое случайное значение s. В случае, если серверу доступа необходимо аутентифицировать клиента, он отправляет сообщение с запросом, уведомляя клиента, что ему требуется отправить свой сертификат и цифровую подпись в ответе. Получив сертификат от AS, клиент проверяет его достоверность с помощью открытого ключа СА. Если он действующий, клиент выбирает другое случайное значение p, зашифровывает его с помощью открытого ключа сервера и отправляет его обратно. Это значение необходимо для создания сессионных ключей. Если в сети выполняется обоюдная аутентификация, клиент отправляет сертификат cert(клиент) вместе с сообщением доверенного сертификата. Отправитель содержит открытый ключ клиента и аутентифицирует клиента, определяя, известен ли ему секретный ключ, который соотносится с открытым ключом в сертификате. По завершении handshake сервер отправляет сообщение TLS-finished. Клиент аутентифицирует сервер, проверяя, совпадает ли отправленное сервером сообщение с вычисленным клиентом.

Главное достоинство EAS-TLS — поддержка взаимной аутентификации и устойчивость ко многим типам атак. К недостаткам я бы отнес невозможность делегирования прав доступа к сети другим пользователям. И, что немаловажно, данный протокол не поддерживает аутентификацию клиентов, которые не имеют сертификата, подписанного CA и доверенного серверу доступа.

Наиболее гибким я бы назвал сочетание протокола EAP-TLS и функции делегирования прав Greenpass. Предположим, в схеме будут участвовать два субъекта – гость и делегатор (субъект, передающий права). Поскольку протокол EAP-LTS построен на базе открытых ключей, гостю сперва необходимо будет передать открытый ключ делегатору, тот же в ответ отправляет цепочку сертификатов (после того, как подпишет их). Процесс делегирования происходит следующим образом:

  1. Гость предоставляет значение открытого ключа, обернутое в сертификат Х.509, модулю аутентификации, который в дальнейшем хранит их в Кэше.
  2. Приложение со стороны Гостя генерирует оригинальное изображение, построенное на базе фракталов из открытого ключа Гостя, и отправляет их обратно на приложение Гостя, где они отображаются на экране.
  3. Делегатор открывает своё веб-приложение и получает открытый ключ Гостя из Кэша. веб-приложение подсоединяется к Апплету делегирования в веб-браузере делегатора и отправляет ему открытый ключ гостя.
  4. Апплет делегирования отображает оригинальное изображение Гостя, делегатору необходимо сравнить его с тем, которое отображалось на стороне Гостя.
  5. Если сравниваемые изображения совпадают, то Апплет делегирования создаст и подпишет SPKI сертификат, который несет в себе привилегии доступа в локальную сеть через Wi-Fi. Затем он отправит этот сертификат обратно веб-приложению делегатора, а затем направит его в Кэш.
  6. Когда Гость обновит веб-страницу по делегированию прав Greenpass, приложение опознает в нем ожидающего авторизации на удостоверение личности, извлечет цепочку сертификатов из Кэша авторизации и отправит ее в хранилище сертификатов.
Прямая передача ключей или сертификатов по сети или выделенному каналу имеет много преимуществ. В качестве альтернативного варианта обмен информацией может происходить посредством инфракрасного порта, однако данное решение требует установки дополнительного ПО. Для передачи ключей и сертификатов лучше выбрать веб-сервер, который будет являться связующим звеном между гостем и делегатором. Такое решение имеет многочисленные преимущества:

• Веб-сервер может опознать открытый ключ гостя с помощью аутентификации SSL. SSL либо TLS позволяют серверу получить открытый ключ клиента и проверить его согласно закрытому ключу, даже если доверительные отношения с создателем клиентского сертификата Х.509 отсутствуют.

• В большинстве случаев пользователю не требуется экспортировать сертификат EAP-TLS в файл. Для SSL-аутентификации большинство клиентов ОС (Windows, FreeBsd), наряду со стандартными веб-браузерами (Internet Explorer, Opera), использует стандартные хранилища ключей, которые доступны EAP-TLS и другим клиентам.

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

Вкратце, протокол аутентификации EAP-TLS – это именно тот путь, который обеспечивает надежность беспроводных клиента и сервера с сохранением гибкости делегирования прав. Поэтому, какую бы роль ни играли беспроводные технологии в вашем бизнесе, у вас всегда есть возможность избежать неприятных подводных камней, связанных с новыми рисками.

Об авторе:
Антон Мальцев - консультант департамента BPM компании «КОРУС Консалтинг»

 В продолжение темы:
2006-06-26   Некачественные драйверы Wi-Fi делают ноутбуки уязвимыми
Обсуждение и комментарии
M&M's
22 Jun 2006 1:53 PM
Сильная статья. Когда буду открывать свою первую сеть гипермаркетов, обязательно проконсультируюсь в Корусе.
 

M&M's
22 Jun 2006 1:54 PM
ЗЫ что-то Михаил Елашкин давно не публиковался... Пора бы уж.
 

bash
22 Jun 2006 3:21 PM
Аффтар жжот.

Тихническая грамотность - нулевая, статейка рссчитана на маркетологов с аксапты ;)

А всего-то нужно было использовать vpn + ssl + не выпускать кпк из рук.

Можно особы замут сделать с kerborus и т.п. серверами аутентификации, но это уже изврат.

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

Andrews - andrewsugo.ru
22 Jun 2006 3:42 PM
А по-моему, на первый взгляд,- все честно.
Есть альтернативы, это понятно. Автор предлагает свой подход. Грамотно и для широких масс все объясняет.
Или это научный журнал по информационной безопасности?
Уважаемые, объясните в чем ошибки в этой публикации?
Или Вы просто не любите автора? :)
 

Andrews - andrewsugo.ru
22 Jun 2006 3:43 PM
Непонятно только, к чему приурочена эта статья и кого она может реально спасти :)
 

Antonio - antik77mail.ru
22 Jun 2006 3:57 PM
2bush:
Уважаемый bush, не слишком ли голословные заявления?
Предложить всем известную схему vpn + ssl - вы тем самым не открыли америку.
Предложение с kerberos - неактуально, он имеет весомые недостатки. В нем нет механизма аутентификации KDC, при этом хосты, сервисы, пользователи могут аутентифицировать друг друга.
Как следствие - перехват логина/пароля.
Так же, все ключи находятся в одном хранилице => взлом сервера -> система под угрозой.

 

M&M's
22 Jun 2006 5:44 PM
Мне непонятна практическая сторона вопроса. Фракталы, сертификаты, делегаторы - все это может быть хорошо для Зоны 51, но не очень применимо для гипермаркетов. ИМХО для этого есть более простые, но вполне эффективные решения.
 

bash
22 Jun 2006 5:51 PM
2Antonio, я не bush, а bash, на тот случай, если Вы имели ввиду именно меня.

>Как следствие - перехват логина/пароля.

Кем? На уровне беспроводной сети WPA + RADIUS вполне достаточно, чтобы обеспечить хоть какую-то безопасность, на этом уровне. VPN - это еще один уровень. Ну уж и на всякий случай SSL. По-моему и так достаточно, как минимум.

>Предложить всем известную схему vpn + ssl - вы тем самым не открыли америку.

А зачем использовать что-то другое, по-моему и так все надежно. А главное и мозг не нужно засорять. А там уж kerberos или не kerberos - Это дело хозяйское...

На этом уровне проблем нет. Вопрос в другом - как обьяснить продавцу, как этим всем пользоваться...
 

bash
22 Jun 2006 6:07 PM
А уже на уровне веб страничек принимать товар и делать инвентаризацию. Для посторонних кпк эта сеть будет выглядеть, как набор точек доступа, которые даже не выходят на связь...

А вот утеря кпк - это уже катастрофа! Даже, если все настроено грамотно...
 

Михаил Елашкин - imhoelashkin.com
23 Jun 2006 8:08 PM
2 M&M's
я книгу дописываю ))
 

Михаил Елашкин - imhoelashkin.com
23 Jun 2006 8:18 PM
Что до статьи, то это классический образец бреда псевдонаучного. Почему-то автор считает, что если повесить на дверь четыре очень похожих замка, то все станет безопасно. При этом окна можно не закрывать...
Я уже было испугался, но прочитал должность - консультант по ВРМ. Ну это диагноз. Вообще-то у Корус довольно сильная команда безопасников. Я никогда с ними не общался, но слышал хорошие отзывы. Может не мучаться, а сходит к своим же ребятам и они объяснят элементарные истины по безопасности.
Ну например, что безопасность понятие комплексное и прочность системы определяется прочностью самого слабого узла. Что толку бороться за сеть, если в безопасности есть другие дыры? Нужен полный анализ всей системы безопасности, а не радостный крик консультанта совсем по другим вещам - ой, я дырочку нашел! Ну нашел, возьми пирожок с полки. А как думаешь, а если я просто приду с КПК и устрою атаку требую ответа по всем выделенным Wi-Fi. Ни одно устройство не сможет получить доступа к сети. Кстати, это можно сделать и удаленно с помощью направленной антены. Ну и как вам эта угроза? Сколько будет стоить?
Далее, многкратное дублирование не увеличивает безопасность, а увеличивает геморрой админа.
Ну итд итп...

Кстати, мне лично, хватает дома WPA-PSK, отмены трансляции названия сети и фильтрации по MAC адресам - последние два это уже для полноты картины, но снижают риск наткнуться на упорного идиота. При этом стоимость и сложность решения соответствуют угрозе.
 

M&M's
24 Jun 2006 3:30 PM
2 Михаил Елашкин:
> я книгу дописываю ))
о чем? Надеюсь, не "Кластерные системы для чайников"? :-))))
 

Antonio - antik77mail.ru
25 Jun 2006 8:53 PM
2Елашкин:
Уважаемый, где именно статье упоминалось о комплексонй безопасности? Вовсе не предполагал раскрывать тему - "защита от всех случаев жизни". Или Вы хотите подискутировать о политиках безопасности - MAC/DAC и пр.?
В статье рассматривается конкретный предложеный компонент безопасности, касающийся беспроводной передачи данных, что в нынешнее время весьма актуально. Не больше, не меньше.
Насчет "диагноза", - вы случаем не врач? Тогда к чему полемика в виде бечспочвенного обливания материалов других, может предложите свои?
Рад за вашу домашнюю безопасность, но не путайте понятие дом и предприятие.
Разные риски - разные подходы к безопасности.
Есть большие сомнения насчет того, что вы понесете большие убытки в случае проникновения постороннего в вашу сеть.

2 M&M's:
Соглашусь, что существуют достаточно надежные методы защиты беспроводной связи, но и количество методов взлома в нынешнее время постоянно растет.
Здесь нет никакой уфологии и Зоны 51 :)
 

M&M's
26 Jun 2006 10:48 AM
2 Antonio:
Все нормально. Статья хорошая. Но если вы публикуетесь в зидинете.ру, будь те готовы к тому, что в токбэке вас разнесут в пух и прах ;-)))
 

Badadios
26 Jun 2006 12:26 PM
А что за система которая ключи в кеше хранит! Красота. Кстати привет МТСу с ихним WI-FI. Судя по их рвению и непродуманности функционирования системы , эти альтруисты и мецинаты наверное решили всем бесплатный интернет подарить!
Ура! Вперед МТС.
 

Antonio - antik77mail.ru
26 Jun 2006 5:18 PM
2 Badadios:
Соглашусь, это, пожалуй, единственное слабозащищенное место во всей схеме.
Но, его можно легко заменить на БД под управлением СУБД - за безопасность данных будет отвечать непосредственно встроенные средства защиты СУБД, такие как VPD, OAS, OLS, FGAC если говорить об Oracle.

2 M&M's:
Понимаю :-)) Критика хороша, когда аргументирована :)
 

Просто Прохожий
3 Jul 2006 4:18 PM
2 Antonio:
Для Елашкина будет невосполнимой потерей если сопрут при взломе домашней сети эпохальный труд "Кластерные системы для чайников"... :-)
Ах как легко мы разбасываемся аббревиатурами... Елашкин нервно курит в стороне. Пора писать "Системы криптования для чайников"... нашла коса на камень
 

duck - kuomail.ru
7 Jul 2006 2:50 PM
Что за чушь, в торговых сетях используются терминалы сбора данных, а не кпк под эти цели. Во вторых покажите мне хоть один супермаркет, где бы использовались небезопасные протоколы, они используются по умолчанию на уровне wifi и выше, не говоря уже фильтрации мак адресов, аксес листов на циске. Эта статья для кого? Для желающих ознакомиться с впа, тлс и т.д.?
 

 

← май 2006 16  17  19  20  21  22  23  25  26 июль 2006 →
Реклама!
 

 

Место для Вашей рекламы!