Редактирование: СБ, 02 лекция (от 28 февраля)

Материал из eSyr's wiki.

Версия от 10:22, 20 марта 2011; 212.192.253.132 (Обсуждение)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

ПРЕДУПРЕЖДЕНИЕ: Вы редактируете устаревшую версию данной страницы. После сохранения страницы будут потеряны изменения, сделанные в последующих версиях.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

== Authentification-Authorisation-Accounting ==
Концепция трипл-А сформировлась в 60х годах. Первые мейнфреймы не имели аутентификации, но когда люди стали задумываться о сложных ос, она уже была. Например мультикс имел очень развесистую 3а.

Эти элемент обычно являются базовыми необходимым для реал защиты информации. Их важно разделять, хотя на практике неспециал очень часто их смешивают.

Аутентификация -- проверка что вася пупкин это вася пупкин.

Авторизация -- проверям что вася пупкин действительно имеет права читать и писать этот файл.

Аккаунтинг(Учет) позоляет проверить дествительно ли он читал писал файл или что он с файлом делал.

В реальной жизни концепции часто смешиваются.

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

Логин в юникс-ситему через консоль. Когда пользователь открвает консоль, 
что происзодит в первую очередь?

Линукс.

Какой первый процесс создается? init

Каким файлом конфигурируется init? /eyc/inittab. В нём есть набор строчек конфигурирования последовательных портов и консоли. В частости там есть запуск специального процесса getty(migetty, mingetty). Далее он запускает /(s)bin/login. Что делает login? спрашивает логин пользователя и пароль. Существует специальный набор вызовов для атентификации пользователей.PAM.
Если у нс есть 20 машин, на которых должны существовать пользователи, обычный /etc/passwd  не подойдёт. Потом возникла необходимость разнообрзия -- например одноразовые пароли. Или аутентификация через внешнюю конструкцию. Чтобы всему этому добавить гибкости САН 20 лет назад создала концепцию Plassable Authentification Modules. login обращается к libpam  и посредством этой билиотеки делает аутентификацию. Функции либпама сообщаем логин и пароль, а она возврщает ок или не ок. Обычн настройки пама хранятся в каталоге /etc/pam.d . Сам по себе логин не знает как устроена система аутентификации в конкретном дистрибутиве. После этого логин знает, что пользователь атентифицирован. Процедура проверки отчуждена вовне. Теперь нам необходимо понять какие права пользователь имеет в системе. В самом наглядном случае пользователю может быть присвоен какой-то security контекст в терминах selinux. Потом операция аккаунтинга. В самом простом случае пишем в журнал, что поьзователь такой-то залогинился. Давайте поговорим подробней про элементы тройки.

=== Аутентификация ===
* Самый простой способ. Секрет. Например, аутентификация по паролю. Знание пароля(секрета) -- основание считать что пользователь тот, за кого себя выдает.
* Криптографические методы. 
** цифровая подпись.  Как? зал -- посчитать хеши от юсбишных ключей!НА САМОМ ДЕЛЕ система предоставляет пользователю случайный набор байт, он его подписывает, система проверяет верность подписи. Просто логин нельзя подписывать изза (домашнее задание). 
  
Частным случаем системы является сеть. Каждый у кого есть точка доступа с этим сталкивался. Системой является активное сетевое оборудование и для устойчивости конструкции применяются дополнительные сетевые протоколы. Они необходимы потому что канал сязи от систеемы до пользователя скомпрометирован(в отличие от клавиатуры или последовательного порта, или ссх). В случае аутентификации в сети мы не можем полагаться на более низкие протоклы. Задачу обеспечения безопаснти решает набор протоколов 802.1x, развитие протокла wEP. Для первых вай-фай сетей был придман мезханизм безопасного подключения к сети, аутентификации и передачи данных. Подразумевал изначально использование статичских ключей длиной 56 или 112 бит. Обнаружилось много ошибок в дизайне, сейчас считается ненадёжным.(второй вопрос дз -- когда дома хорошо оставить сеть с вепом?). Поскольку веп показал себя недостаточно надежным ieee разработало 802.1x обеспечивает аутентифкацию к тому, что они назвали сетевые порты. Это значит, что он может использоваться и в проводных сетях.

Разберём его на уровне езернета. В тот момент когда сетевой порт переходит в состояние ап он попадает в состояние аутентификации и черех него могут идти только фреймы ответственнные за аутентификацию. Увидев езернет фреймы она выполняет запрос на аутентиф передает необходимые данные и в случае если проверка прошла упешна у него поднимается канальный, а может и сетевой уровень. Порт переходит в состояние аутентифкейтед и ему могут дать ип. Сама аутентиф происходит на канльном. Процедура обмена достаточно несложная.

Есть пользователь П и комутаттор К.
Когда П на физ уровне соединился с К, К шлёт ему запросы на аутентификацию. П передает К Auth Ready. К посылает возможные способы аутентификации(наиболее распространены -- по раздеяемому секртеу и по ключам). П шлёт необходимые данные для аутентификации. После чего либо переходит в состояние ап, либо нет.

Для того чтобы механизмы вообще работали необходим набор протоколв, которые эти механизмы могут обеспечивать. Их много, подробно обудим два -- RADIUS и kerberos. Увидите разницу в подходах и отличия при дизане пр систем.

радиус был разработан в конце 80ых и сипользовлся для аутентификации модемных подключений при звонках по телефону. радиус работает следующим образом. В терминах р а включает три основных элемента:
* пользователь
* аксесс сервер
* сервер аутентификации.

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

Code ID LEN

радиус работает по удп, используя i812/udp

CODE -- предопределенный тип операции
 * запрос на аутентификацию Auth Request
 * аутнетификация прошла успешноAuth Accept
 * аутентифкация прошла неуспешно Aut Reject
 * для прохождения аутентиф необходимы дополнительные данные  Auth Challenge
 
Далее следует любое количество атрибутов вида имя атрибута -- значение.
 
пароль пользователя не предается в открытом виде по сети. используется простая схема защиты -- хеш MD5 от секрета + случайное значение  и это иксорим с паролем.

* MD5(secret||random)
* md5(random||secret)
* md5(secret)

какой из вариантов лучше? (дз).

Передали этот запрос, радиус сервер может ответить достаточно он данных получил для аутентификации или нет. в auth challenge говорится какие дополнительне данные должен сообщить пользователь. Когда мы говорили про цифровую подпись, то самое протое -- передать в челленддж пакете то случайное значение, которое надо подписать. После этого пользователь формирует и передает новый auth request.

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

когда пользователь аутентифицир на косноли мы верим в нескомпрометированность канала. Когда пользователь дозванивается по модему канал может прослушиватся. Не хотелось бы вэтом канале передавать данне и парль в откртом виде. Чтобы решить эту проблему(в первый раз придумали для ppp). Протокол ppp  позволял поднять ип сединение поерх телефонной линии. Этот модемный канал мог прослушиваться злоумышленниками. Чтоб ее делать бло два проткола PasswordAP и CHallenge AuthP.

CHAP.
Пользователь приходил и говорил свое имя, по ппп аксесс серверу. асобщался с радиус-севрером по протоколу радиус. по ппп пользователь передавал ас hash(challenge+passwd). Радиус сервер знал пароль и мог пустить или не пустить. В этой конструкции надо чтобы радиус сервер знал пароль в открытом виде. Это не слишком хорошо. пожтому компания микрософт прижумала специальный прооткол mschap и mscha v2, который позволял хранить в радиус сервере пароли в виде хэша. Рботало просто -- пользователь выполнял двойное хэширование. Это не создавало безопасности, потому что знание хэша соотвтетствовало знанию пароля. У шнайера была статья пр уязвимости mschap применимо к pptp(собственно придуманные впн компании майкрософт). Еще лет 5 назд многие домонеты предлагали аутентифицировать по пптп. Название security flawnemts in mschap или как-то так.

Давайте поговорим чем отличается подход при аутентификации керберосом и зачем все это нужно.

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

4 действующих лица
* пользователь
* tgt сервер
* auth
* service

У нас есть только симметричная криптография, пользователь хочет получить доступ к сервису.

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

В современнй жизни все происходит намного проще, у нас есть крипт с откртым ключом и мы подключаемся по ссх.Такой развесистой схемы не нужно.

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

Если есть несколько дестяков систем, то возникает та же проблема, что и с аутентификацией. Централизованное управление. Для жтого опять же был придуман набор протоколов. Очень соблазнительн испоьзовать для этого радиус. Но радиус предполагает наличие дополнительных атрибутов в пакетов. Так вот в пакете аут аксепт радиус может преедать дополнительные атрибуты, которые описывают что именно может пользователь делать. например, может подключить локально, но не может ходить в сеть. Другим протколом, который это активно использует является протокол TACACS.

Есть пользователь, сервис и такакс сервер.

В случае радиуса пользователь одним удп пакетом пытался подключиться и потом приходил один удп пакет в котором говорилось например ДА МОЖНО и какие права.

В случае такакса. Пользователь подключается к такаксу и такакс держит сессию все время работы пользователя с сервисом. На каждую команду такакс сервер жает сервису разрешение выполнить команду или не дает разрешение. Принятие решения не закешировано в локальной системе, а принимется в режиме онлайн для каждого действия. В реальной жизни скорей всего не встретитесь даже циска уже не рекомендует его использовать. Не потому что протолк плоой но  так сложилось что в войне радиуса и такакса победил радиус. Такакс работает на tcp/49.

Если шагнуть от раритета в наши дни возникает ещё одна интересная проблема. Вот у нас есть пользователь который представляется системе посредством какого то приложения. Причем пользователь не всегда хочет целиком доверять приложению. Например я являюсь пользователем сервиса для размещения фотография писаниф сообщений себе н стеночку. И у меня есть приложения с эплстора и я не до конца ыуверен, что приложение благонадежно. мне бы хотелось делигировать часть полномочий этому приложению. Например разрешить постить фотографии. Но при этом не давать ему спамить моим друзьям. Если я отдаю этому приложению логин и пароль, фейсбук не сможет его от меня отличить. Родилась идея что части авторизации необходимо делигировать куда-то. Или например хотим чтобы твитер репостил в фейсбук, и при этом не говорить твитеру пароль от фейсбука. Для решения этой проблемы был придуман проткол oauth.

Поговрим коротко, а то в нём много нюансов не всегда работающих. Каким образом можно отличить меня от приложения.  У пользователя есть логин и пароль. Есть приложение. В терминологии оаута приложению переддается токен. Специальная бинарная строка, которое приложение не понимает, но если оно шлет его сервису, сервис может давать ему какие то права.  обращаюсь к сервису со своим логином и пролем и прошу сгенерировать токен. Токен передается прилжению. Сервис знает, что токен ассоциирован со мной. Можно сказать, что этому конкретному токену даются не все права, а только набор. У севриса поялвяется классическая табличка авторизации токены/права.

Когда приложение приходит к сервису, как правило оно приходит про хттп. Используется basic http authorisation.

GET /api.xml

Как работает хттп авторизация? код 401. В обычной ситуации браузер приходит на веб сервер и говорит ему
GET / http 1.1
сервер отвечает ему
401 AUTH Req
далее браузер рисует окошечко с логином и паролем и браузер делает вторую попытку
GET / http 1.1 / Authorisation Basic Base64(login:password)

Логин пароль передается практически открытым текстом. Поэтому её рекомендуется никогда не использовать. В случае oauth происходит практически тоже самое, только вместо basic идет oauth, а дальше идет токен который есть у этого приложения.

задания
* почему нельзя использовать подписаны логин
* статический секрет и какой способ лучше 
* практическое задание по взлому вепа.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.name/wiki/%D0%A1%D0%91%2C_02_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_28_%D1%84%D0%B5%D0%B2%D1%80%D0%B0%D0%BB%D1%8F%29