Как настроить авторизацию доступа

HTTP авторизация

HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространённой схемой HTTP авторизации является «Basic» (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с её использованием.

Общий механизм HTTP авторизации

RFC 7235 определяет средства HTTP авторизации, которые может использовать сервер для запроса у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом 401 (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок WWW-Authenticate (en-US), содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок Authorization с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке Authorization .

В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.

Прокси-авторизация

Этот же механизм запроса и ответа может быть использован для прокси-авторизации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса 407 (Proxy Authentication Required) и заголовок Proxy-Authenticate (en-US), который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок Proxy-Authorization (en-US).

Доступ запрещён

Если (прокси) сервер получает корректные учётные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом 403 Forbidden . В отличии от статус кода 401 Unauthorized или 407 Proxy Authentication Required , аутентификация для этого пользователя не возможна.

Аутентификация с помощью изображений

Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с Firefox 59, изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).

Кодировка символов HTTP аутентификации

Браузеры используют кодировку utf-8 для имени пользователя и пароля. Firefox использовал ISO-8859-1 , но она была заменена utf-8 с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как баг 1419658).

WWW-Authenticate and Proxy-Authenticate headers

WWW-Authenticate (en-US) и Proxy-Authenticate (en-US) заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:

Here, is the authentication scheme («Basic» is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like «Access to the staging site» or similar, so that the user knows to which space they are trying to get access to.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization (en-US) request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

Authentication schemes

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

The most common authentication scheme is the «Basic» authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:

• Basic (see RFC 7617, base64-encoded credentials. See below for more information.),
• Bearer (see RFC 6750, bearer tokens to access OAuth 2.0-protected resources),
• Digest (see RFC 7616, only md5 hashing is supported in Firefox, see баг 472823 for SHA encryption support),
• HOBA (see RFC 7486 (draft), HTTP Origin-Bound Authentication, digital-signature-based),
• Mutual (see draft-ietf-httpauth-mutual),

AWS4-HMAC-SHA256 (see AWS docs).

Basic authentication scheme

The «Basic» HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

Security of basic authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Restricting access with Apache and basic authentication

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

The .htaccess file typically looks like this:

The .htaccess file references a .htpasswd file in which each line contains of a username and a password separated by a colon («:»). You can not see the actual passwords as they are encrypted (md5 in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn’t be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

Restricting access with nginx and basic authentication

For nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

Access using credentials in the URL

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

Источник

Wi-Fi с логином и паролем для каждого пользователя или делаем WPA2-EAP/TLS подручными средствами

С практической точки зрения было бы удобно управлять Wi-Fi сетями, выдавая пароль каждому пользователю. Это облегчает задачу с доступом к вашей беспроводной сети. Используя так называемую WPA2 PSK авторизацию, чтобы предотвратить доступ случайному пользователю, нужно менять ключ, а также заново проходить процесс авторизации на каждом отдельном Wi-Fi устройстве. Кроме того, если вы имеете несколько точек доступа, ключ нужно менять на всех из них. А если Вам надо скрыть пароль от кого-нибудь, придется раздать всем сотрудникам новый.

Представим ситуацию — к вам в офис зашел кто-то посторонний (клиент, контрагент?), и нужно дать ему доступ в интернет. Вместо того, чтобы давать ему WPA2 — ключ, можно сделать для него отдельный аккаунт, который потом, после его ухода, можно удалить заблокировать. Это даст вам гибкость в управлении учетками, а пользователи будут очень довольны.

Мы сделаем удобную схему, применяемую в корпоративных сетях, но полностью из подручных средств с минимальными финансовыми и аппаратными вложениями. Ее одобрит служба безопасности и руководство.

Немного теории

Когда-то давно инженерами IEEE был придуман стандарт 802.1x. Этот стандарт отвечает за возможность авторизации пользователя сразу при подключении к среде передачи данных. Иными словами, если для соединения, например, PPPoE, вы подключаетесь к среде(коммутатору), и уже можете осуществлять передачу данных, авторизация нужна для выхода в интернет. В случае же 802.1x вы не сможете делать ничего, пока не авторизуетесь. Само конечное устройство вас не допустит. Аналогичная ситуация с Wi-Fi точками доступа. Решение же о допуске вас принимается на внешнем сервере авторизации. Это может быть RADIUS, TACACS, TACACS+ и т.д.

Терминология

Вообще авторизация пользователя на точке может быть следующих видов:

• Open — доступна всем
• WEP — старое шифрование. Уже у всех плешь проедена о том, что его ненадо использовать вообще
• WPA — Используется TKIP в качестве протокола шифрования
• WPA2 — Используется шифрование AES

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

• WPA-PSK, WPA2-PSK — ключ к доступу находится в самой точке.
• WPA-EAP, WPA2-EAP — ключ к доступу сверяется с некоторой удаленной базой данных на стороннем сервере

Также существует довольно большое количество способов соедининея конечного устройства к серверу авторизации (PEAP, TLS, TTLS. ). Я не буду их здесь описывать.

Общая схема сети

Для наглядного понимания приведем общую схему работы нашей будущей схемы:

Если словами, то клиенту, при подключении к Wi-Fi — точке предлагается ввести логин и пароль. Получив логин и пароль Wi-Fi точка передает эти данные RADIUS-серверу, на что сервер отвечает, что можно делать с этим клиентом. В зависимости от ответа, точка решает, дать ему доступ, урезать скорость или что-то еще.
За авторизацию пользователей будет отвечать наш сервер с установленным freeradius. Freeradius является реализацией протокола RADIUS, который в свою очередь является реализацией общего протокола AAA. AAA — это набор средств для осуществления следующих действий:
Authentication — проверяет допустимость логина и пароля.
Authorization — проверяет наличие прав на выполнение некоторых действий.
Accounting — учитывает ваши дейсвия в системе.
Сам протокол передает имя пользователя, список атрибутов и их значений для него. То есть, например, атрибут Auth-Type := Reject — отклонить этого клиента, а Client-Password == «password» — сравнить атрибут в запросе со значением password.
Вообще говоря, база аккаунтов и прав для них не обязательно должна храниться на RADIUS-сервере, да и базой может быть что угодно — никсовые пользователи, пользователи домена Windows… да хоть текстовый файлик. Но в нашем случае все будет в одном месте.

Базовая настройка

В этой статье нас будут интересовать в первую очередь WPA2-EAP/TLS способ авторизации.
Практически все современные точки доступа Wi-Fi стоимостью больше 3 тыс. рублей поддерживают нужную нам технологию. Клиентские устройства поддерживают и подавно.
В статье я буду использовать следующее оборудование и програмное обеспечение:

• Точка доступа Ubiquiti NanoStation M2
• Сервер Gentoo и Freeradius
• Клиентское оборудование с установленным програмным обеспечением Windows 7, Android, iOS

Настройка точки доступа

Главное, чтоб точка поддерживала нужный способ аутентификации. Оно может называться по разному в разных устройствах: WPA-EAP, WPA2 Enterprise и т.д. Во всяком случае выбираем аутентификацию, устанавливаем IP-адрес и порт RADIUS-сервера и ключ, который мы вводили в clients.conf при настройке Freeradius.
Приведу картинку с настроенной точки Ubiquiti. Помечено галкой то, что нужно менять.

RADIUS-сервер

Зайдем на наш компьютер с Linux и установим RADIUS-сервер. Я брал freeradius, и ставил я его на gentoo. К моему удивлению, в рунете нет материалов, относящихся к настройке Freeradius 2 для наших целей. Все статьи довольно стары, относятся к старым версиям этого програмного обеспечения.

Все:) RADIUS-сервер уже может работать:) Вы можете проверить это так:

Это debug-mode. Вся информация вываливается на консоль. Приступем к его настройке.
Как это водится в Linux, настройка выполняется через конфигурационные файлы. Конфигурационные файлы хранятся в /etc/raddb. Сделаем подготовительные действия — скопируем исходные конфиги, почистим конфигурация от всякого мусора.

Далее добавим клиента — точку доступа. Добавляем в файлик /etc/raddb/clients следующие строки:

Далее добавляем домен для пользователей. Сделаем дефолтовый.

И, наконец, добавляем пользователей в файл /etc/raddb/users:

Ух, можно стартовать!

Наш сервер запущен и ждет подключений!

Настройка клиентов

Пробежимся по настройке основных пользовательских устройств. У наших сотрудников есть клиенты, работающие на Android, iOS и Windows 7. Оговоримся сразу: так как мы используем самосозданные сертификаты, то нам нужно несколько раз вносить всевозможные исключения и подтверждать действия. Если бы мы пользовали купленные сертификаты, возможно, все было бы проще.

Всех проще дело обстоит на iOS-устройствах. Вводим логин и пароль, нажимаем «Принять сертификат», и вперед.

Чуть сложнее выглядит, но на практике все тоже просто на Android. Там немного больше полей для ввода.

Ну и на Windows 7 приедтся немного понастраивать. Осуществим следующие шаги:
Идем в центр беспроводных подключений.

1. Устанавливаем необходимые параметры в свойствах Вашего беспроводного подключения
2. Устанавливаем необходимые параметры в расширенных настройках EAP
3. Устанавливаем необходимые параметры в расширенных настройках Дополнительных параметрах
4. Подключаемся в панели задач к Wi-Fi сети и вводим логин-пароль, наслаждаемся доступом к Wi-Fi

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

Собственный мини-биллинг

Теперь осталась одна проблема — если вы захотите добавить-удалить нового пользователя, то вам придется изменить users и перезапустить radius. Чтобы этого избежать подключим базу данных и сделать свой собственный мини-биллинг для пользователей. Используя БД, вы всегда сможете набросать простенький скрипт для добавления, блокировки, изменения пароля пользователя. И все это произойдет без останова всей системы.

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

Для начала создаем саму базу данных:

Далее надо создать нужные таблицы. Вообще с Freeradius идет документация по схемам таблиц для различных баз данных, правда в различных дистрибутивах находятся они в разных местах. У меня лично это лежит в /etc/raddb/sql/postgresql/schema.sql. Просто вставьте эти строки в psql, либо просто запустите

На всякий случай добавлю сюда схему для Postgres:

Отлично, база подготовлена. Теперь законфигурим Freeradius.
Добавьте, если ее там нет, в /etc/raddb/radiusd.conf строку

Теперь отредактируйте /etc/raddb/sql.conf под вашу реальность. У меня он выглядит так:

Добавим несколько новых пользователей test1, test2, test3, и… заблокируем test3

Ну, перезапускаем freeradius и пробуем подключиться. Должно все работать!

Конечно биллинг получился ущербный — у нас нигде не хранится информации по аккаунтингу(учету действий пользователя), но и нам здесь этого не надо. Чтобы вести аккаунтинг, необходимы еще и Wi-Fi точки подорооже, чем 3 тыс. рублей. Но уже и так мы с легкостью управлять пользователями.

Что дальше

В последнем разделе мы собрали собственный небольшой биллинг! Остается для полноты картины привернуть какой-нибудь WEB-интерфейс управления Базой Данных, добавить обязательное изменение пароля раз в месяц по крону. А если еще разориться сертификат и контроллер Wi-Fi точек доступа, то у вас в руках есть полноценная корпоративная беспроводная сеть. Но даже без этих затрат и при малых усилиях с Вашей стороны сделав своим пользователям такой доступ, они вам скажут огромное спасибо.

Источник