Подключение к wifi по сертификату. Как программно установить сертификат CA (для конфигурации EAP WiFi) в Android? Настройка сетевых параметров на клиентских компьютерах

В первой части мы узнали, зачем предприятием использовать Enterprise режим Wi-Fi Protected Access (WPA or WPA2), а не Personal (PSK) режим. Мы узнали, что 802.1X проверка подлинности в режиме Enterprise требует использование RADIUS сервера, который включен в Windows Server.

Мы уже установили и настроили службу сертификатов в Windows Server 2008. В этой части мы продолжим установку и настройку сетевой политики и служб доступа. Затем мы настроим беспроводные контроллеры и/или точки доступа (APs) на использование шифрования, а также параметры RADIUS. Затем мы настроим клиентские компьютеры. И наконец, мы сможем подключиться.

Установка ролей сетевой политики и служб доступа

В предыдущих версиях Windows Server функция RADIUS обеспечивалась службой Internet Authenticate Service (IAS). Начиная с Windows Server 2008, она обеспечивается сетевой политикой (Network Policy) и службами доступа (Access Services). Сюда входят предыдущие службы IAS наряду с новым компонентом NAP.

В окне начальной настройки (Initial Configuration Tasks) пролистайте вниз и выберите Добавить роли (Add roles) . Если вы закрыли и свернули это окно, нажмите Пуск> Диспетчер сервера, выберите Роли и нажмите Добавить роли.

Выберите Сетевая политика и службы доступа (Network Policy and Access Services) (рисунок 1), и нажмите Далее .

Рисунок 1: Выбор установки ролей сетевой политики и служб доступа

Выберите следующее (рисунок 2):

  • Сервер сетевой политики (Network Policy Server)
  • Серверы маршрутизации и удаленного доступа (Routing and Remote Access Servers)
  • Службы удалённого доступа (Remote Access Services)
  • Маршрутизация (Routing)

Рисунок 2: Выбор установки первых четырех опций

Теперь можно начать настройку NPS для функции RADIUS: нажмите Пуск , введите nps.msc и нажмите Enter .

Для опции Стандартная конфигурация (Standard Configuration) выберите опцию RADIUS сервер для 802.1X Wireless или проводных подключений (RADIUS server for 802.1X Wireless or Wired Connections) (рисунок 3) из раскрывающегося меню.

Рисунок 3: Выбор RADIUS сервера для 802.1X

Нажмите Настроить 802.1X .

Для типа 802.1X подключений выберите Защищать беспроводные подключения (Secure Wireless Connections) (рисунок 4), и нажмите Далее .

Рисунок 4: Выбор защиты беспроводных подключений

Для каждого беспроводного контроллера и/или точки доступа нажмите Добавить , чтобы создать новую запись клиента RADIUS. Как показано на рисунке 5, нужно указывать дружественные имена, которые помогут вам определить их среди прочих, IP или DNS адреса и общий секрет (Shared Secret).

Рисунок 5: Ввод информации для беспроводного контроллера или точки доступа

Эти общие секреты важны для проверки подлинности и шифрования. Делайте их сложными и длинными, как пароли. Они должны быть уникальными для каждого контроллера/AP. Позже вам нужно будет ввести такие же общие секреты для соответствующих контроллеров/AP. Не забывайте держать их в секрете, храните их в безопасном месте.

Для способа проверки подлинности (Authentication Method) выберите Microsoft Protected EAP (PEAP) , поскольку мы будем использовать PEAP.

Нажмите кнопку Настроить" , выберите ранее созданный сертификат и нажмите OK .

В окне указания групп пользователей (рисунок 6) нажмите Добавить .

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

В диалогах выбора группы введите группы или нажмите дополнительно (Advanced) для поиска доступных групп. Если вы не создали дополнительные группы, вам, возможно, придется выбрать Пользователей домена (Domain Users) для разрешения пользователей и Компьютеры домена (Domain Computers) для проверки подлинности машин, если ваши контроллеры/APs поддерживают их. Если вы получите сообщение об ошибке, говорящее о том, что домен не существует, перезапустите сервер Active Directory Domain Services и попробуйте еще раз.

После добавления нужных групп нажмите Далее для продолжения.

В окне настройки VLAN (рисунок 7), если ваша сеть (коммутаторы и контроллеры/APs) поддерживает VLAN и они настроены, нажмите Настроить" , чтобы установить функцию VLAN.

Рисунок 7: Нажмите кнопку настройки для определения параметров VLAN

Просмотрите параметры и нажмите Готово .

Настройка беспроводных контроллеров и/или точек доступа

Пришло время настроить беспроводные контроллеры или точки доступа (APs). Вызовите веб-интерфейс путем ввода IP адреса точек доступа или контроллеров в браузер. Затем перейдите в параметры беспроводной сети.

Выберите WPA-Enterprise или WPA2-Enteprise . Для типа шифрования выберите TKIP, если используется WPA (TKIP if using WPA) или AES, если используется WPA2 (AES if using WPA2) . Затем введите IP адрес RADIUS сервера, которым должна быть только что настроенная машина Windows Sever. Введите общий секрет, созданный ранее для этого контроллера/AP. Сохраните параметры.

Установка ЦС сертификата на клиентских машинах

В первой части цикла вы создавали собственный Центр сертификации (ЦС) и сертификат сервера. Таким образом, нужно установить ЦС на все клиентские компьютеры. В этом случае клиент может выполнить проверку сервера перед прохождением проверки подлинности.

Если вы используете сеть доменов с Active Directory, вам, возможно, понадобится развернуть этот сертификат с помощью групповой политики. Однако вы также можете установить его вручную.

Для просмотра и управления сертификатами в Windows Server 2008, вызовите диспетчер сертификатов (Certificate Manager). Если вы сохранили эту MMC на свой компьютер в первой части, откройте ее. В противном случае выполните эти шаги еще раз:

  1. Нажмите Пуск , введите MMC и нажмите Enter .
  2. В окне консоли MMC выберите Файл >Добавить или удалить оснастку .
  3. Выберите Сертификаты и нажмите Добавить .
  4. Выберите Учетная запись компьютера и нажмите Далее .
  5. Выберите Локальный компьютер , нажмите Готово и OK .

Теперь разверните Сертификаты (Локальная учетная запись компьютера (Local Computer Account)) , разверните Личные (Personal) и нажмите Сертификаты (Certificates) .

Как показано на рисунке 8, нажмите правой клавишей на сертификате, у которого значение «Выдан для» (Issued To) заканчивается на CA , перейдите к пункту Все задачи и выберите Экспорт" . Затем следуйте указаниям мастера экспорта. Когда мастер вас спросит, не экспортируйте закрытый ключ , а используйте DER формат. Вам, возможно, придется экспортировать его на флешку, чтобы можно было брать его с собой к клиентским машинам.

Теперь на клиентских компьютерах дважды нажмите на сертификате и нажмите кнопку Установить сертификат (Install Certificate) (рисунок 9). Используйте мастер для импорта сертификата в хранилище Доверенные корневые центры сертификации (Trusted Root Certificate Authorities) .

Рисунок 9: Установка ЦС сертификата на клиенте.

Настройка сетевых параметров на клиентских компьютерах

Теперь можно настроить сетевые параметры. Как и с установкой сертификатов, можно продвигать сетевые настройки на клиенты с помощью групповой политики, если вы работаете в сети доменов с Active Directory. Однако можно также настроить клиентов вручную, как в нашем случае для Windows XP, Vista и 7.

Сначала, вручную создаем сетевой профиль или предпочитаемую запись сети. Для Типа безопасности (Security Type) выберите WPA-Enterprise или WPA2-Enteprise . Для Типа шифрования (Encryption Type) выберите TKIP, если используется WPA или AES, если используется WPA2 .

Откройте сетевой профиль и выберите закладку Безопасность (в Vista и 7) или Проверка подлинности (в XP). В XP отметьте опцию Включить IEEE 802.1x проверку подлинности для этой сети .

Для Способ проверки подлинности сети (Network Authentication method) (в Vista и 7, как показано на рисунке 10) или EAP Type (в XP), выберите Protected EAP (PEAP) . В XP также уберите флажки с опций внизу окна.

Рисунок 10: Выбор PEAP для способа проверки подлинности

В Windows 7 (только) нажмите кнопку Дополнительные параметры (Advanced Settings) в закладке Безопасность. Затем в окне дополнительных параметров отметьте опцию Указать способ проверки подлинности (Specify authentication mode) , выберите Проверка подлинности пользователя (User Authentication) и нажмите OK , чтобы вернуться в закладку безопасности.

Нажмите кнопку Параметры (в Vista и 7) или Свойства (в XP).

В диалоге свойств Protected EAP Properties выполните эти шаги (рисунок 11):

  • Отметьте первую опцию, Проверять сертификат сервера (Validate server) .
  • Отметьте вторую опцию, Подключаться к этим серверам (Connect to these servers) , и введите полные имена компьютеров серверов. При необходимости дважды нажмите на нем в Windows Server, выбрав Пуск > Диспетчер сервера.
  • В окне списка Доверенных корневых центров сертификации выберите сертификат ЦС, который вы импортировали.
  • Выберите Защищённый пароль (Secured password (EAP-MSCHAP v2)) для способа проверки подлинности.

Рисунок 11: Настройка свойств PEAP

  • Нажмите кнопку Настроить . Если вы работаете в сети доменов с Active Directory, лучше отметить эту опцию. В противном случае снимите флажок с этой опции, чтобы можно было вводить имя пользователя и пароль при подключении к сети.

Наконец, нажмите OK в диалоге windows для сохранения параметров.

И, наконец, подключаемся и входим!

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

На клиентском компьютере выбираем сеть из списка доступных сетевых подключений. Если вы не настроили клиента на автоматическое использование входа в Windows, вам нужно будет ввести учетные данные для входа, как показано на рисунке 12. Используйте учетную запись на Windows Server, принадлежащую к группе, настроенной ранее в разделе установки сетевой политики и служб доступа. Если вы выбрали группу пользователей домена, учетная запись администратора должна быть разрешена по умолчанию.

Рисунок 12: Окно входа.

Заключение

Теперь у вас должна быть сеть с 802.1X проверкой подлинности и защитой Enterprise шифрованием, благодаря Windows Server 2008 и предоставляемой им функции RADIUS. Мы настроили сервер, беспроводные APs, и клиентов на использование PEAP проверки подлинности. Конечные пользователи смогут входить с помощью своих учетных записей.

Для управления параметрами сервера RADIUS, такими как добавление или удаление APs, используйте утилиту Network Policy Server: нажмите Пуск >Все программы > Инструменты администрирования >Сервер сетевой политики .

Моя цель: Создайте конфигурацию WiFi EAP, включая сертификат CA, в программе Android.

Проблема: Как программно установить сертификат CA (а затем ссылаться на этот сертификат в конфигурации WiFi EAP)?

Однако это предполагает, что вы уже установили сертификат CA на устройстве. Я хотел бы установить сертификат в своем приложении - либо из ресурсов в приложении, либо отправлен с сервера.

Возможно ли это? (Корень в данном случае не является вариантом). Если да, то как?

Дополнительная информация...

Я также нашел способ добавить сертификат в KeyStore:

Однако это используется специально для создания безопасного сокета и подключения через HTTPS. Я хочу использовать сертификат для WiFi.

К сожалению, мне еще предстоит найти способ установить сертификат CA программно - из приложения.

Тем не менее, можно установить сертификат через веб-браузер в Android. Таким образом, решение (на данный момент) заключается в следующем: Запустите намерение открыть URL-адрес в веб-браузере, который отправляется непосредственно в сертификат CA.

Это работает, но есть некоторые проблемы:

  • Пользователь должен указать сертификат. Это проблема, потому что мы добавляем конфигурацию WiFi программно. Таким образом, мы должны попросить пользователя предоставить сертификат с тем же именем.
  • Пользователь должен ввести пароль. Если у них нет пароля, пользователь создаст его и дважды введите его. Если они установили пароль безопасности, пользователь должен будет запомнить тот же пароль и ввести его.
  • Предполагая, что пользователь успешно выполнил эти шаги, он остается висящим в браузере.

Это приводит к нескольким вопросам:

  • Из моего приложения есть способ заставить имя сертификата, установленного пользователем через браузер?
  • Из моего приложения, есть ли способ узнать, когда установка сертификата завершена, а затем вернуть фокус в мое приложение?

Просто дайте мне знать, если вам нужно разъяснение.

3 ответов

Вы не можете установить его напрямую, поскольку несистемные приложения не имеют доступа к хранилищу ключей. В ICS существует API для этого KeyChain.createInstallIntent() , который запустит системный диалог, запрашивающий у пользователя, хотят ли они установить сертификат. На предварительном ICS вы можете достичь того же, запустив намерение установки напрямую с помощью имени компонента (это может работать или не работать на всех устройствах). Пройти через браузер на самом деле обходной способ сделать то же самое.

Что касается ваших вопросов:

  • вы не можете указать/принудительно ввести имя. Почему вас интересует фактическое имя?
  • На самом деле не через браузер. Если вы используете намерение системы, вы можете вернуться к своей деятельности и получить обратный вызов, если вы используете startActivityForResult() .

В настоящее время я ищу решения тех же проблем. Самое лучшее, что я нашел, это KeyChain.choosePrivateKeyAlias ​​(), позволяющий пользователю выбрать, какой сертификат использовать для SSL. Оттуда вы можете получить имя псевдонима и передать его на корпоративную конфигурацию wifi.

  • Tutorial

С практической точки зрения было бы удобно управлять 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 тыс. рублей поддерживают нужную нам технологию. Клиентские устройства поддерживают и подавно.
В статье я буду использовать следующее оборудование и програмное обеспечение:

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

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

RADIUS-сервер

Зайдем на наш компьютер с Linux и установим RADIUS-сервер. Я брал freeradius, и ставил я его на gentoo. К моему удивлению, в рунете нет материалов, относящихся к настройке Freeradius 2 для наших целей. Все статьи довольно стары, относятся к старым версиям этого програмного обеспечения.
root@localhost ~ # emerge -v freeradius
Все:) RADIUS-сервер уже может работать:) Вы можете проверить это так:
Это debug-mode. Вся информация вываливается на консоль. Приступем к его настройке.
Как это водится в Linux, настройка выполняется через конфигурационные файлы. Конфигурационные файлы хранятся в /etc/raddb. Сделаем подготовительные действия - скопируем исходные конфиги, почистим конфигурация от всякого мусора.
root@localhost ~ # cp -r /etc/raddb /etc/raddb.olg root@localhost ~ # find /etc/raddb -type f -exec file {} \; | grep "text" | cut -d":" -f1 | xargs sed -i "/^ *\t* *#/d;/^$/d"
Далее добавим клиента - точку доступа. Добавляем в файлик /etc/raddb/clients следующие строки:
root@localhost ~ # cat /etc/raddb/clients.conf | sed "/client test-wifi/,/}/!d" client test-wifi { ipaddr = 192.168.0.1 #IP адрес точки, которая будет обращаться к радиусу secret = secret_key #Секретный ключик. Такой же надо будет поставить на Wi-Fi точке. require_message_authenticator = no #Лучше так, с каким-то D-Linkом у меня не получилось иначе }
Далее добавляем домен для пользователей. Сделаем дефолтовый.
root@localhost ~ # cat /etc/raddb/proxy.conf | sed "/realm DEFAULT/, /^}/!d" realm DEFAULT { type = radius authhost = LOCAL acchost = LOCAL }

Домены в RADIUS

Здесь надо заметить, что можно делить пользователей по доменам. А именно, в формате имени пользователя может указываться домен(например user@radius). DEFAULT означает любой неопределенный домен. NULL - без домена. В зависимости от домена(можно сказать префикса в имени пользователя) можно осуществлять различные действия, как то отдать право аутентифицировать другому хосту, отделять ли имя от домена во время проверки логина и т.д.


И, наконец, добавляем пользователей в файл /etc/raddb/users:
root@localhost ~ # cat /etc/raddb/users | sed "10,$!d" user1 Cleartext-Password:= "password1" user2 Cleartext-Password:= "password2" user3 Cleartext-Password:= "password3"
Ух, можно стартовать!
root@localhost ~ # radiusd -fX
Наш сервер запущен и ждет подключений!

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

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

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

Скриншот с IOS


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

Скриншот с Android


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

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

Скриншоты Windows

Шаг 1


Шаг 2

Шаг 3


Шаг 4

Шаг 5


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

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

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

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

Root@localhost ~ # psql -U postgres radius_wifi=> create user radius_wifi with password 1111; radius_wifi=> create database radius_wifi with owner=radius_wifi; radius_wifi=> \q

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

Root@localhost ~ # cat /etc/raddb/sql/postgresql/schema.sql | psql -U radius_wifi radius_wifi

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

Схема для Postgres

root@localhost ~ # cat /etc/raddb/sql/postgresql/schema.sql | sed "/^--/d;/\/\*/d;/\*/d;/^$/d;" CREATE TABLE radacct (RadAcctId BIGSERIAL PRIMARY KEY, AcctSessionId VARCHAR(64) NOT NULL, AcctUniqueId VARCHAR(32) NOT NULL UNIQUE, UserName VARCHAR(253), GroupName VARCHAR(253), Realm VARCHAR(64), NASIPAddress INET NOT NULL, NASPortId VARCHAR(15), NASPortType VARCHAR(32), AcctStartTime TIMESTAMP with time zone, AcctStopTime TIMESTAMP with time zone, AcctSessionTime BIGINT, AcctAuthentic VARCHAR(32), ConnectInfo_start VARCHAR(50), ConnectInfo_stop VARCHAR(50), AcctInputOctets BIGINT, AcctOutputOctets BIGINT, CalledStationId VARCHAR(50), CallingStationId VARCHAR(50), AcctTerminateCause VARCHAR(32), ServiceType VARCHAR(32), XAscendSessionSvrKey VARCHAR(10), FramedProtocol VARCHAR(32), FramedIPAddress INET, AcctStartDelay INTEGER, AcctStopDelay INTEGER); CREATE INDEX radacct_active_user_idx ON radacct (UserName, NASIPAddress, AcctSessionId) WHERE AcctStopTime IS NULL; CREATE INDEX radacct_start_user_idx ON radacct (AcctStartTime, UserName); CREATE TABLE radcheck (id SERIAL PRIMARY KEY, UserName VARCHAR(64) NOT NULL DEFAULT "", Attribute VARCHAR(64) NOT NULL DEFAULT "", op CHAR(2) NOT NULL DEFAULT "==", Value VARCHAR(253) NOT NULL DEFAULT ""); create index radcheck_UserName on radcheck (UserName,Attribute); CREATE TABLE radgroupcheck (id SERIAL PRIMARY KEY, GroupName VARCHAR(64) NOT NULL DEFAULT "", Attribute VARCHAR(64) NOT NULL DEFAULT "", op CHAR(2) NOT NULL DEFAULT "==", Value VARCHAR(253) NOT NULL DEFAULT ""); create index radgroupcheck_GroupName on radgroupcheck (GroupName,Attribute); CREATE TABLE radgroupreply (id SERIAL PRIMARY KEY, GroupName VARCHAR(64) NOT NULL DEFAULT "", Attribute VARCHAR(64) NOT NULL DEFAULT "", op CHAR(2) NOT NULL DEFAULT "=", Value VARCHAR(253) NOT NULL DEFAULT ""); create index radgroupreply_GroupName on radgroupreply (GroupName,Attribute); CREATE TABLE radreply (id SERIAL PRIMARY KEY, UserName VARCHAR(64) NOT NULL DEFAULT "", Attribute VARCHAR(64) NOT NULL DEFAULT "", op CHAR(2) NOT NULL DEFAULT "=", Value VARCHAR(253) NOT NULL DEFAULT ""); create index radreply_UserName on radreply (UserName,Attribute); CREATE TABLE radusergroup (UserName VARCHAR(64) NOT NULL DEFAULT "", GroupName VARCHAR(64) NOT NULL DEFAULT "", priority INTEGER NOT NULL DEFAULT 0); create index radusergroup_UserName on radusergroup (UserName); CREATE TABLE radpostauth (id BIGSERIAL PRIMARY KEY, username VARCHAR(253) NOT NULL, pass VARCHAR(128), reply VARCHAR(32), CalledStationId VARCHAR(50), CallingStationId VARCHAR(50), authdate TIMESTAMP with time zone NOT NULL default "now()");

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

$INCLUDE sql.conf

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

Мой sql.conf

root@localhost ~ # cat /etc/raddb/sql.conf sql { database = "postgresql" driver = "rlm_sql_${database}" server = "localhost" login = "radius_wifi" password = "1111" radius_db = "radius_wifi" acct_table1 = "radacct" acct_table2 = "radacct" postauth_table = "radpostauth" authcheck_table = "radcheck" authreply_table = "radreply" groupcheck_table = "radgroupcheck" groupreply_table = "radgroupreply" usergroup_table = "radusergroup" deletestalesessions = yes sqltrace = no sqltracefile = ${logdir}/sqltrace.sql num_sql_socks = 5 connect_failure_retry_delay = 60 lifetime = 0 max_queries = 0 nas_table = "nas" $INCLUDE sql/${database}/dialup.conf }


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

Root@localhost ~ # psql -U postgres radius_wifi=> insert into radcheck (username, attribute, op, value) values ("test1", "Cleartext-Password", ":=", "1111"); radius_wifi=> insert into radcheck (username, attribute, op, value) values ("test2", "Cleartext-Password", ":=", "1111"); radius_wifi=> insert into radcheck (username, attribute, op, value) values ("test3", "Cleartext-Password", ":=", "1111"); radius_wifi=> insert into radcheck (username, attribute, op, value) values ("test3", "Auth-Type", ":=", "Reject");

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

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

Версия RoS 6.39rc27

За защиту WiFi сети в Mikrotik отвечают три вкладки: Access List (/interface wireless access-list), Connect List (/interface wireless connect-list), Security Profiles (/interface wireless security-profiles).

Access List - список правил, которые ограничивают соединения других устройств к вашей точке , а также служат для управления параметрами подключения. (режим ap mode).

Пример: вы хотите ограничить подключение к вашей точке доступа по MAC-адресам.
Connect List - список правил, которые ограничивают соединение вашего устройства к другим точкам доступа (режим station mode).

Пример: вы хотите автоматически подключать свою клиентскую станцию к точке доступа с максимальным уровнем сигнала (при наличии нескольких базовых станций).

Security Profiles - настраиваются профили методов защиты и, непосредственно, ключи защиты беспроводной сети.

Security Profiles

Начнем с самого интересного - Security Profiles. Именно здесь мы настраиваем шифрование для наших беспроводных точек. Настройка будет осуществляться для домашней или офисной точки доступа. Профиль защиты выставляется непосредственно в свойства беспроводного интерфейса.

При переходе на вкладку /interface wireless security-profiles видим такую картину.

Вы можете добавить свой профиль, я всегда использую стандартный - че добру пропадать =).

Вкладка General.

Name - имя профиля.

Если используем стандартный профиль - оставляем по-умолчанию.

Mode - режим шифрования.

  • none - шифрование не используется. Зашифрованные кадры не принимаются. Широко используется в системах гостевого доступа, вроде предоставления Интернета в кафе или гостинице. Для подключения нужно знать только имя беспроводной сети.
  • static-keys-required - WEP-режим. Не принимать и не посылають незашифрованные кадры. Скомпроментированый протокол. Использовать нельзя, или в крайних случаях (для старых устройств). Основная статья - .
  • static-keys-optional - WEP-режим. Поддержка шифрования и дешифрования, но также позволяют получать и отправлять незашифрованные кадры. Использовать нельзя, или в крайних случаях (для старых устройств). Основная статья - .
  • dynamic-keys - WPA режим.

Для защиты беспроводной сети ВСЕГДА используем режим dynamic-keys.


Аuthentication Types - набор поддерживаемых типов аутентификации. Клиент сможет подключится к точке доступа только если поддерживает данный тип аутентификации. Предлагаемые варианты: WPA-PSK , WPA2-PSK , WPA-EAP и WPA2-ЕАР. Техническое отличие WPA от WPA2 состоит в технологии шифрования, в частности, в используемых протоколах. В WPA используется протокол TKIP, в WPA2 – протокол AES. На практике это означает, что более современный WPA2 обеспечивает более высокую степень защиты сети. К примеру, протокол TKIP позволяет создавать ключ аутентификации размером до 128 бит, AES – до 256 бит. Фактически WPA2 представляет собой улучшенный WPA; WPA2 использует протокол AES, WPA – протокол TKIP; WPA2 поддерживается всеми современными беспроводными устройствами; WPA2 может не поддерживаться устаревшими операционными системами.

Разница между WPA2-PSK и WPA2-ЕАР состоит в том, откуда берутся ключи шифрования, используемые в механике алгоритма AES. Для частных (домашних, мелких) применений используется статический ключ (пароль, кодовое слово, PSK (Pre-Shared Key)) минимальной длиной 8 символов, которое задается в настройках точки доступа, и у всех клиентов данной беспроводной сети одинаковым. Компрометация такого ключа (проболтались соседу, уволен сотрудник, украден ноутбук) требует немедленной смены пароля у всех оставшихся пользователей, что реалистично только в случае небольшого их числа. Для корпоративных применений, как следует из названия, используется динамический ключ, индивидуальный для каждого работающего клиента в данный момент. Этот ключ может периодический обновляться по ходу работы без разрыва соединения, и за его генерацию отвечает дополнительный компонент — сервер авторизации, и почти всегда это RADIUS-сервер.

RADIUS-сервер мы не используем, сотрудники у нас говорливые, но и пароли мы меняем часто, поэтому наш выбор WPA2-PSK. Оставляем галочку только на нем, все другие "небезопасные" протоколы - отключаем.

Unicast Ciphers - выбор типа шифрования. Клиенты смогут подключиться в вашей точке, если поддерживают данный тип шифрования. Поддерживаются два типа tkip и aes-ccm . AES - это современный и более безопасный алгоритм. Он совместим со стандартом 802.11n и обеспечивает высокую скорость передачи данных. TKIP является устаревшим. Он обладает более низким уровнем безопасности и поддерживает скорость передачи данных вплоть до 54 МБит/сек. Кроме того, стандарт алгоритма ССМ требует использования новых временных ключей для каждой вновь создаваемой сессии, а это плюс к безопасности.

Используем только aes-ccm.

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

Используем только aes-ccm.


WPA-Pre-Shared Key, WPA2 Pre-Shared Key - значение ключа. Для задания пароля используйте цифры, буквы верхнего И нижнего регистра, Специальные символы (%, *, @, #, $, ~). Не забывайте регулярно менять пароль (например раз в 15 дней). Mikrotik позволяется сделать это скриптом, у меня так меняется пароль на 10 офисах одновременно, если интересно - могу описать в отдельной статье.

Используем сложный пароль.

Supplicant Identity - EAP-идентификатор, который посылается клиентом в начале аутентификации EAP. Это значение используется в качестве значения для атрибута User-Name в сообщениях RADIUS.

WPA2-ЕАР не используем - значение игнорируем.

Group Key Update - время как часто обновлять ключ шифрования. Функция не работает в режиме station. Фактически изменять значение можно при непонятных отвалах устройств (например Android-смартфонов при уходе в ждущий режим).

Значение оставляем по-умолчанию - 5 минут.

Managment Protection - защита от атак деаутентификации и клонирования MAC-адреса. Свой алгоритм защиты беспроводной сети от Mikrotik.

  • disabled - защита управления отключена.
  • allowed - разрешить использовать защиту, если это поддерживается удаленной стороной.
  • required - требуется. Для базовой станции установить связь только с клиентами поддерживающими Managment Protection. Для клиентов - установить связь только с точками доступа поддерживающими Managment Protection.
Managment Protection не используем - оставляем disabled.

Managment Protection Key - ключ защиты Managment Protection.

Поле не активно, если не используется Managment Protection.


Вкладка RADIUS.

MAC Authentication - авторизация по mac-адресу. Эта настройка применяется к тем клиентам, которых нет в access-list. Сервер RADIUS будет использовать MAC-адрес клиента в качестве имени пользователя.

Галочку не ставим .

MAC Accounting - включить MAC-статистику.

Галочку не ставим.

EAP Accounting - включить EAP-статистику.

Галочку не ставим.


Interim Update - интервал времени через который точка доступа повторно запрашивает информацию об аккаунте с Radius сервера.

Параметр не изменяем.


MAC Format - формат в котором записываем MAC-адреса. Доступные форматы:

XX: XX: XX: XX: XX: XX

XXXX: XXXX: XXXX

XXXXXX: ХХХХХХ

XX-XX-XX-XX-XX-XX

XXXXXX-XXXXXX

XXXXXXXXXXXX

XX XX XX XX XX XX

Указывает как MAC-адрес клиента кодируется точкой доступа в атрибут User-Name RADIUS-сервера.

Параметр не изменяем.

MAC Mode - значения:

  • as-username - использовать только имя при проверке подлинности в RADIUS-сервере.
  • as-username-and-password - использовать имя и пароль при проверке подлинности в RADIUS-сервере (в качестве атрибута User-Name).

Параметр не изменяем.


MAC Caching Time - промежуток времени через который точка доступа будет кэшировать ответы аутентификации. Значение disabled отключает кэш, все ответы направляются напрямую в RADIUS-сервер.

Параметр не изменяем.

Вкладка EAP.


EAP Methods - метод EAP-аутентификации. Значения:
  • eap-tls - использование встроенной аутентификации EAP TLS. Клиент и сервер поддерживают сертификаты.
  • eap ttls mschapv2 - аутентификации EAP с именем пользователя и паролем.
  • passthrough - точка доступа будет ретранслировать процесс аутентификации на сервер RADIUS.
TLS Mode - режим проверки TLS. Значения:
  • verify certificate - проверять сертификат.
  • dont verify certificate - не проверять сертификаты у клиента.
  • no certificates - не использовать сертификат, использовать метод 2048 bit anonymous Diffie-Hellman key.
  • verify certificate with crl - проверять сертификат по спискам CRL (список аннулированных сертификатов SSL).
TLS certificate - тут указываем непосредственно сертификат TLS.

MSCHAPv2 Username - имя пользователя для аутентификации eap ttls mschapv2.

MSCHAPv2 Password - пароль для аутентификации eap ttls mschapv2.

Вкладка Static Keys.

Данный раздел активен если используется "static keys optional" и "static-keys-required" на вкладке "General". Он используется для ввода ключей .


Key 0, Key-1, Key-2, Key-3 - шестнадцатеричное представление ключа. Длина ключа должна соответствовать выбранному алгоритму (40bit-wep, 104bit-wep, tkip или aes-ccm).

Transmit Key - точка доступа будет использовать указанный ключ для шифрования кадров для клиентов, также он будет использоваться для шифрования широковещательной и групповой передачи кадров.

St. Private Key - только для использования в режиме "station". Точка доступа будет использовать соответствующий ключ выбранного алгоритма (в шестнадцатеричном представлении ключа).

Access List

Чтобы включить доступ по правилам Access List, на вкладке Interfaces необходимо открыть свойства беспроводного интерфейса, где на вкладке Wireless, убрать галочку с параметра Default Authenticate.

После снятия галки, переходим в Access List и создаем правило. Оно может быть для каждого клиента свое, или общее на всех.


MAC Address - MAC адрес устройства, которое будет подключатся к вашему роутеру. Если снять галочку Default Authenticate и выставить тут MAC адрес, то только это устройство сможет подключится к сети. Это и есть ограничение подключения по MAC-адресам в Mikrotik. Для того, что бы другое устройство смогло подключится к вашей точке, нужно внести его MAC в список правил.

Interface
- интерфейс к которому будет производится подключение. Если указать "all" - правило будет применяться ко всем беспроводным интерфейсам вашего устройства.

Signal Strength Range - диапазон уровня сигнала, при котором возможно подключение. Настройка применяется в сетях с бесшовным роумингом между точками. Служит для того, что-бы ваше устройство не держалось за текущую точку доступа до критически слабого уровня сигнала, а перерегистрировалось на новую точку (при одинаковом SSID).

Обычно выставляют диапазон типа "-75..120" при наличии нескольких точек доступа в нормальной доступности.


AP Tx Limit - ограничить скорость передачи данных этому клиенту. Значение "0" - без ограничений.


Client Tx Limit - передать ограничение скорости клиента. Поддерживается только на RouterOS клиентах.

Authentication - возможность авторизации. Если убрать галочку, устройство с этим MAC адресом, не сможет подключиться к вашей сети.

Forwarding - возможность обмена информацией с другими участниками беспроводной сети. Если убрать галочку с этого пункта - пользователь этого устройства не будет иметь доступа к другим клиентам wifi-сети.

Обычно на публичных точка доступа - галочку снимают, для экономии трафика и безопасности.

VLAN-Mode - С помощью VLAN Tagging можно отделить трафик виртуальных беспроводных точек доступа от локальных клиентов (например, что-бы отделитель гостевую сеть от рабочей). Значения:

  • no-tag - не использовать VLAN-тегирование на беспроводном интерфейсе;
  • use-service-tag - использовать 802.1ad тегирование;
  • use-tag - использовать 802.1q тегирование.
VLAN-ID - VLAN-идентификатор.
VLAN не используем, оставляем по-умолчанию - "1". Private Key - возможность установки персонального ключа шифрования для устройства с данным MAC адресом. Только для режимов WEP.

Private Pre Shared Key - персональный ключ шифрования. Используется в режиме WPA PSK.

Managment Protection Key - ключ защиты Managment Protection. Managment Protection - защита от атак деаутентификации и клонирования MAC-адреса. Выставляется на вкладке "General" в Security Profiles.

Time - в этом разделе можно указать временной диапазон, в рамках которого будет возможно подключение этого устройства.

Connect List

Interface - правило в списке connect list может быть применимо только к одному беспроводному интерфейсу. Тут мы его выбираем.

MAC Address - указываем MAC AP к которой будем подключатся.

Сonnect - если галочка стоит, то подключатся к точке доступа, которая соответствует этому правило, если не стоит - не подключатся.

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

Area Prefix - правило действует для интерфейса с заданным префиксом. Area - позволяет создать группу и включить беспроводные устройства в нее, а затем использовать определенные правила для этой группы и всех входящих в нее устройств, вместо того, чтобы создавать отдельные правила для каждого устройства. Это значение заполняется в настройках точки доступа и может быть сопоставлено с правилами в connect-list.

Signal Strength Range - подключатся только к точкам доступа в пределах заданного диапазона уровня сигнала.

Wireless Protocol - протокол беспроводной связи. Значения:

  • any - любой поддерживаемый (автовыбор);
  • 802.11 - только стандартные протоколы 802.11abgn. Обычно используется для совместимости с оборудованием других производителей;
  • nstreme - «фирменный» протокол Mikrotik, характеризующийся высокой скоростью потока данных в одну сторону (RX или TX);
  • 7) скройте SSID вашей сети.

    8) поменяйте MAC беспроводного интерфейса - для затруднения идентификации устройства.

    Бонус

    Скрипт, который анализирует логи Mikrotik. Если попадается сообщение о подключении с неправильным паролем - добавляется правило в access-list, которое запрещает данному клиенту (по MAC) подключатся к всем нашим беспроводным интерфейсам. Автор EdkiyGluk , за что ему спасибо.

    :local pop 4
    :local mac
    :local wifi foreach i in=$wifi do={
    :set mac [:pick 0 ([:len ]-50)]
    #:log warning $mac
    if ([:len ] >= $pop) do={
    if ( = "") do={
    /interface wireless access-list add mac-address=$mac authentication=no
    interface=all
    }
    }
    }
    #:log warning "FINISH"

    Скрипт в планировщик с запуском каждые N минут. Для того, чтобы в бан не попадали разрешённые устройства - заранее добавляем их в Access List.

Ещё один компьютерный пост.

Недавно построил WiFi-сетку с аутентикацией по 802.1x, использующую сертификаты для опознания юзеров. В числе прочего, пришлось настраивать для работы с ней устройства на Android – смартфоны и планшетки. Тут-то и выяснилось, что нормального howto, как это сделать, найти не получается – те, которые были, касались сценариев с паролями, а мне от них-то и хотелось избавиться. Потому и решил свести информацию по вопросу в один пост.


Что такое 802.1x и как его использовать на Windows и Linux , написано предостаточно, поэтому тут будет только про настройку клиента на Android.

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

Для этого делаем следующее: на устройство (телефон, планшетку) ставится сертификат с секретным ключом (на каждый девайс – отдельный ключ). Управление ключами в Андроиде весьма примитивно, однако даёт ровно тот минимум, какой нам требуется – даёт импортировать ключ и использовать его, но не извлекать обратно (по крайней мере, без пароля, который мы выдавать не собираемся). Эти ключи и будут выдаваться access point’у в ответ на требование представиться.

Процедурка вся укладывается в 4 шага:

1. Подготовка “credential storage” :
Перед тем, как заводить в девайсину какие-либо секретные ключи, надо подготовить для них хранилище, где ключи будут сохраняться в зашифрованном виде. Шифрование будет происходить на основе пароля, который вводится лишь при создании хранилища. Для использования секретного ключа пароль вводить не нужно – лишь для его экспорта (который к тому же невозможно осуществить через обычный андроидный UI). Посему пароль мы этот оставим у себя, а юзеру выдавать отнюдь не будем. Evil laughter прилагается.

[Update : увы, не выйдет. При выключении девайса пароль уходит, и для использования ключей его придётся вводить заново. У этого есть и хорошие, и плохие стороны:
* Сохранять пароль в тайне от юзера не выйдет - иначе придётся вводить его всякий раз при включении.
* Это значит, что теоретически юзер может скопировать из девайса секретный ключ - что с админской точки зрения плохо. Но, насколько я понимаю, ему для этого требуется рутовый доступ. Получение такого доступа хлопотно, но возможно.
* Хорошая сторона в том, что сам пароль в флэш-памяти не сохраняется - а криптоключи, которые сохраняются, шифруются этим паролем по AES.
* Ну и к тому же, если пароль при включении введён ещё не был, то это даёт защиту от кого-то постороннего, кто попытается использовать ключ, пароля не зная.
]

Пароль можно впоследствии сменить – но лишь при знании нынешнего. Можно и обнулить всё хранилище – при этом пароль уйдёт, и юзер сможет выставить свой, но с ним погибнет безвозвратно также и секретный ключ, прямо как тайна верескового мёда.

Собственно процесс: Settings --> Location and security --> Set password . Ввести пароль дважды. После чего галочка “Use secure credentials ” включится автоматически.

Чтобы поменять пароль: “Set password ” повторно.

Чтобы обнулить всё нафиг: “Clear storage ” там же.

2. Импорт корневого сертификата :
Нужно забросить в девайс файл с расширением .crt (.cer не принимается) и в формате PEM, также известном как Base-64. Можно это сделать через USB, можно через Bluetooth. Файл должен быть скопирован в директорию /sdcard – та, что видна как корень при подключении девайса через USB или при просмотре файлов через “My Files ”.

Затем: Settings --> Location and security --> (хоть в данном случае сертификат и не encrypted). Сертификат будет добавлен в список доверяемых, а файл в /sdcard стёрт.

Более удобный способ: опубликовать сертификат на каком-нибудь веб-сайте и просто открыть его URL в родном андроидном браузере (для пущей надёжности, использовать известный вебсервис через https или же сугубо внутренний сайт). Тот сразу запросит, добавить ли сертификат в список доверяемых, или нет. Чтобы не набивать URL руками, можно сгенерировать QR-code с ним, и затем просто отсканить его.

3. Импорт сертификата юзера с секретным ключом :
Файл с секретным ключом в формате PKCS#12 и с расширением .p12 кладётся в /sdcard (.pfx , опять же, игнорируется). Способов создать такой файл множество – не буду их перечислять, но отмечу, что обязательно стоит задать для него одноразовый пароль, шифрующий ключ.
Затем, опять же, Settings --> Location and security --> Install encrypted certificates . На этот раз будет запрошен пароль. Это не тот, что задавался при создании хранилища, а тот, который нужен для расшифровки ключа из файла. После введения пароля, ключ будет дешифрован и сохранён зашифрованным заново – на этот раз, паролем от хранилища. Файл же будет стёрт из /sdcard , что нас вполне устраивает.

Можно также забросить файл .p12 через URL, но я бы не стал – в отличие от сертификатов, расползания ключей, хоть и в шифрованном виде, стоит избегать.

4. Подключение к собственно сети :
После того, как ключ задан, остались лишь настройки WiFi-сети. Ничего секретного в этом этапе нет, можно оставить его юзерам, выслав инструкцию.
Итак: Settings --> Wireless and network --> Wi-Fi settings . Найти сеть в списке, либо, если SSID скрыт, жмякнуть на “Add Wi-Fi network ”.
Затем:



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

Всё. После этого юзеру останется только жмякнуть по названию сетки и подключиться. Если же он по недомыслию как-нибудь нажмёт на “Forget network ” и сотрёт настройки, для восстановления достаточно лишь пройти заново шаг 4 – процедура несекретная, юзер её может проделать сам.

Примечания:
В принципе, есть также опция PEAP. Протокол PEAP-EAP-TLS считается чуть более защищённым – к примеру, юзерский сертификат в нём пересылается в зашифрованном виде по установленному туннелю TLS. Однако мои усилия заставить Андроид работать в этом режиме ни к чему не привели. Подозреваю, что дело в том, что поле “Phase 2 authentication ” не содержит опции для использования юзерского сертификата – поэтому приходится удолетворяться EAP-TLS, которому никакой phase 2 не нужен. Но разница минимальна и несущественна.

Понятия не имею, зачем нужен. В принципе, юзер должен опознаваться по полю CN в сертификате.



Есть вопросы?

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: