По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Данная статья посвящена, наверное, самой сложной части начальной части изучения Linux - правам доступа. В данной статье будет рассказано о правах доступа, владельцах файлов, папок.
Цели статьи:
Просматривать и изменять владельцев объектов.
Устанавливать правила доступа к объектам.
Понимать право “Execute”
Основные команды для работы с правами доступа:
chown – установка владельца
chgrp – установка группы владельца
chmod – установка прав доступа
В Windows у нас есть только один владелец файла или папки. Это можно посмотреть в свойствах объекта на вкладке безопасность, дополнительно и там же мы можем сменить владельца. Владелец в Windows по умолчанию обладает полными правами на объект. В Linux все происходит немного по-другому: Любой объект моет иметь своего владельца и группу владельцев, и кроме этого для объекта существуют все остальные пользователи в системе. Это самое существенное различие, что может быть владелец и группа владельцев.
И так у меня есть пользователь petya и пользователь siadmin. Теперь посмотрим информацию по этим двум пользователям. Чтобы посмотреть воспользуемся командой id siadmin и id petya.
У моего пользователя есть uid, который говорит, что я siadmin и вхожу в группу siadmin. Когда мы создаем нового пользователя группа по умолчанию совпадает с именем пользователя. Т.е каждый пользователь по умолчанию входит в свою собственную группу. Для пользователя petya я создал группу не по его имени. Я создал группу testusers и включил данного пользователя в данную группу и установил данную группу по умолчанию для данного пользователя.
Я нахожусь в домашней папке. Набрав команду ls –l мы можем посмотреть список каталогов и файлов, у каждого из них есть владелец и группа владельцев. Эти данные указаны в колонках. Для файла test1.txt владельцем является root и группа владельцев root.
Я создал папку Folder и файл test2.txt и назначил владельца и группу владельцев, согласно картинке. Для изменения данных параметров используется команда chown. Данную команду необходимо применять с повышением в привилегиях, через команду sudo. Например, изменим владельца для файла test1.txt. команда будет выглядеть так sudo chown petya test1.txt. Пароль не запросило, т.к я уже его вводил.
Как мы видим все успешно отработало. Если раньше был владелец root, то теперь мы видим petya. Для изменения группы мы так же можем воспользоваться командой sudo chgrp testusers test1.txt.
Данная команда chgrp используется редко, т.к вполне достаточно знать команду chown. Данная команда умеет менять в том числе и группу. Простой пример изменим группу используя команду chown :testusers file.txt. Просто перед группой ставим знак : который и говорит, что надо заменить группу на указанную. А можно сделать сразу 2 действия chown petya:testusers file1.txt
Немного сумбура вносит, что у пользователя группа по умолчанию совпадает с именем пользователя. Но это стандартное поведение Linux, который так заводит группу. Даже суперпользователь root имеет свою группу root. При создании пользователя petya был принудительно включен в группу testusers и она была выставлена по умолчанию для данного пользователя.
Еще есть важный момент, который необходимо упомянуть. Это рекурсивное выставление владельцем или группы владельцев на папки или файлы. Т.е если у нас есть папка родительская и в ней дочерние папки и файлы, а то и несколько вложений, а мы хотим изменить владельца или группу владельцев рекурсивно вниз, то команду chown необходимо использовать с ключем –R.
Пример: sudo chown –R siadmin:testusers Folder
Права доступа
Далее вернемся к самой первой картинке. На картинке добавлены подписи на английском языке. Это сделано, для большей наглядности. Потому, что сейчас будем раздавать права на объекты файловой системы файлы, папки и другие объект. Следовательно, права будут присваиваться владельцам, группе владельцев и все остальные. Права для владельцев – это user - (u), права для группы владельцев group - (g), Права для всех остальных other - (o).
Для того, чтобы далее разбираться с темой прав, надо запомнить вот такую табличку.
В классическом Linux, есть 3 вида доступа к объекту, это право на чтение, право на запись и право на выполнение и различные комбинации из этих прав. Заглавные буквы на верху таблицы отвечают за какое-либо право. Цифрами обозначены значения данных прав. Если мы даем право на чтение, то оно обозначается r--, если чтение и запись то rw-, если даем все права то rwx. Мы можем объединять данные права, как видите в табличке различные комбинации указаны. Всего 8 комбинаций от "нет прав", до "полных прав". Так же данная комбинация может назначаться в виде цифр. Т.е на какой то файл у такого товарища доступ 5, это значить что данный товарищ имеет право читать файл и запускать на выполнение. Посчитать очень просто чтение это - 4 , а выполнение – это 1, а в сумме будет 5 или по другому r-x. Следовательно мы можем назначать, как в цифровом, так и в символьном варианте права.
Еще один не маловажный момент мы назначаем права на файл, сразу для всех видов пользователей. Следовательно, указывая права, мы их сразу задаем для владельца, для группы владельца и всех остальных. Права мы можем назначать. Точно так же как на картинке символами rwx или цифрами, согласно табличке. Для лучшего понимания пример:
Chmod 750 script - полные права владельцу, чтение и выполнение группе владельца и ничего всем остальным.
Когда мы просматриваем права на объекты мы видим символьные обозначения, а там, где нет символа ставится прочерк, который означает, что данное право отсутствует.
Право <<rwx rw- r-->> script - полные права владельцу, чтение и запись группе владельца, чтение остальным.
Чтобы легче было определять права на объект надо мысленно разделить на блоки по 3 символа. Первый блок — это Владелец, 2-й Блок — это группа владельца и 3-й блок — это другие пользователи.
Сhmod u+w script - дать право записи владельцу.
Chmod ugo-x script - отобрать у всех право исполнения файла.
Посмотреть, какие объекты находятся в директории и их права можно командой ls –la. Так же мы видим владельца и группу владельца. Теперь мы можем понимать первую строчку.
Вывод из всего этого, напрашивается следующий. Владелец у объекта файловой системы может быть только один. В группу testusers или другую мы можем добавить кого угодно и они будут следовательно иметь права, как группа владельцев. И, следовательно, все остальные пользователи, т.е не владелец и не входящие в группу, будут относится к категории всех остальных пользователей. Получается Linux нам дает разбить всех на три группы и в соответствии с этим назначить различные права, а Windows ведет себя по-другому и там можно более гибко задавать права. Мы можем создать 100 пользователей и каждому из них дать какие-то свои уникальные права. В Linux тоже это возможно с помощью разных ACL (Access Control List - лист доступа), но это не входит в базовые понятия, которые мы разбираем в рамках данной статьи.
Можно заметить ,что для папки спереди появляется символ d. Это d – directory каталог. Может появляться l – link – ссылка и.т.д.
Следовательно, можно убирать права указывая у кого, например, забрать выполнение chmod ugo-x test1.txt или мы можем добавить владельцу chmod u+x test1.txt. И третий вариант изменения прав на файл - это полностью перезаписать права на объект chmod 640 test1.txt.
Разберемся с правом на execute – выполнение.
Понятно становится это права, когда мы имеет дело с каким-то скриптом или бинарником или программой исполняемой. Так же у нас данное право может назначаться на каталог, а каталог мы исполнить не можем. Но тут есть интересный момент, если у вас будет на папку разрешение только на чтение и запись, прочитать папку, переименовать ее т.е поработать с наименованием папки, но в глубь папки вы не сможете зайти. Чтобы зайти во внутрь папки необходимо право execute – т.е выполнение ее.
Маска создания файлов и папок
В данной части статьи рассмотрим следующий вопрос:
Понимание принципов работы и управления масками создания файлов и папок.
Основные понятия:
umask – маска создания файлов и папок
suid – бит запуска от имени владельца
sgid – бит запуска от имени группы владельцев
sticky – бит защиты содержимого
Первое понятие umask - user creation mask - т.е маска с которой создается новая папка или файл, это то с какими правами по умолчанию будут создаваться папки и файлы для данного пользователя. В том случае если не создано каких-то особенных настроек наследования папки.
suid – set user id, который позволяет, если установлен на исполняемый файл, то любой пользователь, который запускает, получает права определенные для владельца данного файла. По-другому, позволяет использовать права владельца данного файла, происходит некая подмена вас на владельца этого файла.
sgid – set user id, который позволяет, если установлен на исполняемый файл, то любой пользователь, который запускает, получает права определенные для группы владельца данного файла. По-другому, позволяет использовать права группы владельца данного файла, происходит некая подмена вас на пользователя входящего в группу владельца этого файла.
Маска это такая интересная штука, которая указывает права по–умолчанию. Она рассчитывается с помощью вычитания из максимальных прав. Примеры вычисления показаны на картинке.
Посмотрим, как выглядит это в консоли.
Создадим текстовый файл от имени стандартного пользователя touch test10.txt.
Мы видим права, которые были выданы по умолчанию 664, соответственно я являюсь владельцем и моя группа.
Создадим папку mkdir TestFolder.
Выданы права по умолчанию 775. Теперь посмотрим правило действующее. Почему создаются объекты именно с такими правами. Этот параметр находится в профиле в старых версиях, сейчас он перенесен и за данный параметр отвечает утилита pam_umask. Если мы откроем мануал по данной утилите, то мы увидим, что данный параметр находится в /etc/login.defs
Видим, что значение umask = 022. – это значение, которое идет по умолчанию во всех дебиан подобных операционных системах.
Введем новое значение umask 075. Создадим новый файл touch test20.txt.
Получаем права 602.
После перезагрузки маска изменится на маску по умолчанию, чтобы маску нужную зафиксировать, необходимо отредактировать файл /etc/login.defs. Следовательно, для нашего пользователя значить маска изменится с 022 на ту маску, которую там пропишем.
Нужно обратить внимание, что при создании папки права на выполнение по умолчанию выдаются, а на файл нет. Это связанно с тем, что без данных прав в данную папку невозможно будет зайти, а с файла убираются в целях защиты. Например, если вдруг окажется, что файл – это вредоносный код.
Suid, sgid, sticky
Рассмотрим оставшийся вопрос. Зачем нужны suid, sgid и sticky, биты и их установка.
Suid – устанавливается для файлов.
Sgid – устанавливается для файлов и для папок
Sticky – устанавливается для папок.
У них у всех есть цифровые значения. Их можно назначать точно так же, как и права, можно назначать через rwx или цифирные сочетания, а также т.к есть цифирные обозначения их можно комбинировать. Если мы установили 6 то мы установили suid и sgid. Этот бит через цифры ставится, точно так же, как и права, только ставим дополнительную цифру перед цифрами, означающими права.
Так же эти биты можно ставить, через буквы:
Chmod u+s script - установка suid
Chmod g+s script - установка sgid
Chmod o+t script - установка sticky
Как мы видим suid добавляется к правам владельца, sguid прибавляется к правам группы владельца. Sticky добавляется к правам всем остальным.
Как мы видим создан файл script.run с правами 755 и папка TestFolder 755. Установим suid бит на файл script.run. В настоящее время данный файл может выполнить любой человек. Изменим права на 770 - sudo chmod 770 script.run. Переключимся под пользователя, который не входит в группу siadmin. Например, пользователь su petya. Можно конечно добавить права пользователю petya, но иногда нужно, чтобы файлик запустился из-под Владельца файла. Даже если будут стоять разрешение на запуск данного файла и будет стоять suid, то файл запуститься из под Владельца.
Устанавливаем sudo chmod u+s script.run и видим, во-первых, теперь у нас файлик подкрашен красным, данное выделение делает оболочка. Во-вторых, когда мы смотрим права, то видим x заменился на s. И теперь, кто бы не запускал файл, он всегда будет запускать от имени Владельца.
Можно подробнее посмотреть через команду stat script.run, которая показывает полную статистику по файлу.
Мы можем увидеть, что права стали теперь 4770. Вот эта самая цифра 4 впереди и говорит, что установлен suid бит. Мы аналогично можем убрать suid бит sudo chmod u-s script.run. Все вернулось на свои места.
Для чего это нужно, есть некоторые программы которым необходим доступ к аппаратной части. Например ping, который проверяет связь, ему нужен доступ к сетевой карте. По умолчанию права на ping есть только у root, но если мы хотим чтобы все пользователи могли использовать данную утилиту, то мы должны разрешить ее запуск от имени root. Фактически та же самая функция, как и в операционной системе Windows запустить от пользователя. Аналогичным образом работает и sgid, если нам необходимо запускать от группы владельца, то устанавливаем этот бит и можем пользоваться - sudo chmod g+s script.run.
Результат наших действий подсвечен желтым.
Можно одновременно оба бита установить, следовательно, при выполнении будет и владелец заменен и группа заменена. Это имеет смысл делать, только для исполняемых файлов. Устанавливать на обычный текстовый файл данные биты, смысла конечно же нет.
Очень редко, когда применяю оба бита сразу, такое сочетание необходимо если уж сильно кто-то заморачивается с безопасностью или требуется ювелирная настройка прав доступа и запуска.
Теперь посмотрим, что с папкой происходит. На папку можно устанавливать sgid и sticky биты. Если мы устанавливаем групповой бит, то он для папок будет менять владельцев всех вложенных файлов на группу владельцев этой папки, т.е это один из вариантов наследования.
Создадим файл от пользователя siadmin. Touch file.txt в текущей папки он создается со стандартными правами. Установим sgid на папку TestFolder - Sudo chmod g+s TestFolder.
Создадим в ней такой же файл sudo touch TestFolder/file.txt
Как мы видим группа осталась прежней. Если пользователю root сказать создать файл в текущем каталоге, то владелец и группа будут root.
Теперь про sticky бит. Если установлен sticky бит на папку, то только Владелец данной папки или суперпользователь может удалить из нее файлы.
Создадим папку Folder, поставим на нее максимальные права 777. И внутри создадим файл file.txt.
Файлик с правами по умолчанию. Поменяем права на данный фал 666. Права на чтение и запись появились теперь у всех. Переключимся на другого пользователя, например, petya. Перейдем в домашний каталог пользователя siadmin - cd /home/siadmin/Folder. Внутри файл txt, который мы создавали. И удаляем rm file.txt. Файл удалился без проблем. Допустим мы хотим защитить от удаления, следовательно, необходимо установить sticky бит - sudo chmod o+t Folder
Как видим появилась буква t на месте прав для всех остальных. Создадим еще раз файл touch file1.txt. Даем на данный файл всем права 666. А далее перелогиниваемся под petya. Заходим в папку /home/siadmin/Folder и командой rm file1.txt пытаемся удалить, на что получаем отказ от системы. Несмотря на права 666, система не дает удалить файл. Следовательно, удалить все вложенные объекты может либо root или Владелец папки.
Существует большое количество методов аутентификации клиентов беспроводных сетей при подключении. Эти методы появлялись по мере развития различных беспроводных технологий и беспроводного оборудования. Они развивались по мере выявления слабых мест в системе безопасности. В этой статье рассматриваются наиболее распространенные методы проверки подлинности.
Открытая аутентификация
Стандарт 802.11 предлагал только два варианта аутентификации клиента: open authentication и WEP.
Open authentication-предполагает открытый доступ к WLAN. Единственное требование состоит в том, чтобы клиент, прежде чем использовать 802.11, должен отправить запрос аутентификации для дальнейшего подключения к AP (точке доступа). Более никаких других учетных данных не требуется.
В каких случаях используется open authentication? На первый взгляд это не безопасно, но это не так. Любой клиент поддерживающий стандарт 802.11 без проблем может аутентифицироваться для доступа к сети. В этом, собственно, и заключается идея open authentication-проверить, что клиент является допустимым устройством стандарта 802.11, аутентифицируя беспроводное оборудование и протокол. Аутентификация личности пользователя проводится другими средствами безопасности.
Вы, вероятно, встречали WLAN с open authentication, когда посещали общественные места. В таких сетях в основном аутентификация осуществляется через веб-интерфейс. Клиент подключается к сети сразу же, но предварительно должен открыть веб-браузер, чтобы прочитать и принять условия использования и ввести основные учетные данные. С этого момента для клиента открывается доступ к сети. Большинство клиентских операционных систем выдают предупреждение о том, что ваши данные, передаваемые по сети, не будут защищены.
WEP
Как вы понимаете, open authentication не шифрует передаваемые данные от клиента к точке доступа. В стандарте 802.11 определен Wired Equivalent Privacy (WEP). Это попытка приблизить беспроводную связь к проводному соединению.
Для кодирования данных WEP использует алгоритм шифрования RC4. Данный алгоритм шифрует данные у отправителя и расшифровывает их у получателя. Алгоритм использует строку битов в качестве ключа, обычно называемого WEP- ключом. Один кадр данных-один уникальный ключ шифрования. Расшифровка данных осуществляется только при наличии ключа и у отправителя, и у получателя.
WEP- это метод безопасности с общим ключом. Один и тот же ключ должен быть как у отправителя, так и получателя. Этот ключ размещается на устройствах заранее.
WEP-ключ также может использоваться в качестве дополнительного метода аутентификации, а также инструмента шифрования. Если клиент отправляет неправильный ключ WEP, он не подключится к точке доступа. Точка доступа проверяет знание клиентом ключа WEP, посылая ему случайную фразу вызова. Клиент шифрует фразу вызова с помощью WEP и возвращает результат точке доступа (АР). АР сравнивает шифрование клиента со своим собственным, чтобы убедиться в идентичности двух ключей WEP.
Длина WEP - ключей могут быть длиной 40 или 104 бита, представленные в шестнадцатеричной форме из 10 или 26 цифр. Как правило, более длинные ключи предлагают более уникальные биты для алгоритма, что приводит к более надежному шифрованию. Это утверждение не относится к WEP. Так как WEP был определен в стандарте 802.11 в 1999 году, и соответственно сетевые беспроводные адаптеры производились с использованием шифрования, специфичного для WEP. В 2001 году были выявлены слабые места WEP, и началась работа по поиску более совершенных методов защиты беспроводной связи. К 2004 году поправка 802.11i была ратифицирована, и WEP официально устарел. Шифрование WEP и аутентификация с общим ключом WEP являются слабыми методами защиты WLAN.
802.1x/EAP
При наличии только open authentication и WEP, доступных в стандарте 802.11, требовался более безопасный метод аутентификации. Аутентификация клиента обычно включает в себя отправку запроса, получение ответа, а затем решение о предоставлении доступа. Помимо этого, возможен обмен ключами сессии или ключами шифрования в дополнение к другим параметрам, необходимым для клиентского доступа. Каждый метод аутентификации может иметь уникальные требования как уникальный способ передачи информации между клиентом и точкой доступа.
Вместо того чтобы встроить дополнительные методы аутентификации в стандарт 802.11, была выбрана более гибкая и масштабируемая структура аутентификации-разработан расширяемый протокол аутентификации (EAP). Как следует из его названия, EAP является расширяемым и не состоит из какого-либо одного метода аутентификации. Вместо этого EAP определяет набор общих функций, которые применяют фактические методы аутентификации, используемые для аутентификации пользователей.
EAP имеет еще одно интересное качество: он интегрируется со стандартом управления доступом на основе портов стандарта IEEE 802.1X. Когда порт стандарта 802.1X включен, он ограничивает доступ к сетевому носителю до тех пор, пока клиент не аутентифицируется. Это означает, что беспроводной клиент способен связываться с точкой доступа, но не сможет передавать данные в другую часть сети, пока он успешно не аутентифицируется.
Open authentication и WEP аутентификация беспроводных клиентов выполняется локально на точке доступа. В стандарте 802.1 x принцип аутентификации меняется. Клиент использует открытую аутентификацию для связи с точкой доступа, а затем фактический процесс аутентификации клиента происходит на выделенном сервере аутентификации. На рисунке 1 показана трехсторонняя схема стандарта 802.1x, состоящая из следующих объектов:
Клиент: клиентское устройство, запрашивающее доступ
Аутентификатор: сетевое устройство, обеспечивающее доступ к сети (обычно это контроллер беспроводной локальной сети [WLC])
Сервер аутентификации (AS): устройство, принимающее учетные данные пользователя или клиента и разрешающее или запрещающее доступ к сети на основе пользовательской базы данных и политик (обычно сервер RADIUS)
На рисунке клиент подключен к точке доступа через беспроводное соединение. AP представляет собой Аутентификатор. Первичное подключение происходит по стандарту open authentication 802.11. Точка доступа подключена к WLC, который, в свою очередь, подключен к серверу аутентификации (AS). Все в комплексе представляет собой аутентификацию на основе EAP.
Контроллер беспроводной локальной сети является посредником в процессе аутентификации клиента, контролируя доступ пользователей с помощью стандарта 802.1x, взаимодействуя с сервером аутентификации с помощью платформы EAP.
Далее рассмотрим некоторые вариации протокола защиты EAP
LEAP
Первые попытки устранить слабые места в протоколе WEP компания Cisco разработала собственный метод беспроводной аутентификации под названием Lightweight EAP (LEAP). Для проверки подлинности клиент должен предоставить учетные данные пользователя и пароля.
Сервер проверки подлинности и клиент обмениваются челендж сообщениями, которые затем шифруются и возвращаются. Это обеспечивает взаимную аутентификацию. Аутентификация между клиентом и AS осуществляется только при успешной расшифровке челендж сообщений.
На тот момент активно использовалось оборудование, работавшее с WEP- протоколом. Разработчики протокола LEAP пытались устранить слабые места WEP применением динамических, часто меняющихся ключей WEP. Тем не менее, метод, используемый для шифрования челендж сообщений, оказался уязвимым. Это послужило поводом признать протокол LEAP устаревшим. Существуют организации, которые все еще используют данный протокол. Не рекомендуется подключаться к таким сетям.
EAP-FAST
EAP-FAST (Flexible Authentication by Secure Tunneling) безопасный метод, разработанный компанией Cisco. Учетные данные для проверки подлинности защищаются путем передачи зашифрованных учетных данных доступа (PAC) между AS и клиентом. PAC- это форма общего секрета, который генерируется AS и используется для взаимной аутентификации. EAP-FAST- это метод состоящий из трех последовательных фаз:
Фаза 0: PAC создается или подготавливается и устанавливается на клиенте.
Фаза 1: после того, как клиент и AS аутентифицировали друг друга обсуждают туннель безопасности транспортного уровня (TLS).
Фаза 2: конечный пользователь может быть аутентифицирован через туннель TLS для дополнительной безопасности.
Обратите внимание, что в EAP-FAST происходят два отдельных процесса аутентификации-один между AS и клиентом, а другой с конечным пользователем. Они происходят вложенным образом, как внешняя аутентификация (вне туннеля TLS) и внутренняя аутентификация (внутри туннеля TLS).
Данный метод, основанный на EAP, требует наличие сервера RADIUS. Данный сервер RADIUS должен работать как сервер EAP-FAST, чтобы генерировать пакеты, по одному на пользователя.
PEAP
Аналогично EAP-FAST, защищенный метод EAP (PEAP) использует внутреннюю и внешнюю аутентификацию, однако AS предоставляет цифровой сертификат для аутентификации себя с клиентом во внешней аутентификации. Если претендент удовлетворен идентификацией AS, то они строят туннель TLS, который будет использоваться для внутренней аутентификации клиента и обмена ключами шифрования.
Цифровой сертификат AS состоит из данных в стандартном формате, идентифицирующих владельца и "подписанных" или подтвержденных третьей стороной. Третья сторона известна как центр сертификации (CA) и известна и доверяет как AS, так и заявителям. Претендент также должен обладать сертификатом CA только для того, чтобы он мог проверить тот, который он получает от AS. Сертификат также используется для передачи открытого ключа на видном месте, который может быть использован для расшифровки сообщений из AS.
Обратите внимание, что только AS имеет сертификат для PEAP. Это означает, что клиент может легко подтвердить подлинность AS. Клиент не имеет или не использует свой собственный сертификат, поэтому он должен быть аутентифицирован в туннеле TLS с помощью одного из следующих двух методов:
MSCHAPv2;
GTC (универсальная маркерная карта): аппаратное устройство, которое генерирует одноразовые пароли для пользователя или вручную сгенерированный пароль;
EAP-TLS
PEAP использует цифровой сертификат на AS в качестве надежного метода для аутентификации сервера RADIUS. Получить и установить сертификат на одном сервере несложно, но клиентам остается идентифицировать себя другими способами. Безопасность транспортного уровня EAP (EAP-TLS) усиливает защиту, требуя сертификаты на AS и на каждом клиентском устройстве.
С помощью EAP-TLS AS и клиент обмениваются сертификатами и могут аутентифицировать друг друга. После этого строится туннель TLS, чтобы можно было безопасно обмениваться материалами ключа шифрования.
EAP-TLS считается наиболее безопасным методом беспроводной аутентификации, однако при его реализации возникают сложности. Наряду с AS, каждый беспроводной клиент должен получить и установить сертификат. Установка сертификатов вручную на сотни или тысячи клиентов может оказаться непрактичной. Вместо этого вам нужно будет внедрить инфраструктуру открытых ключей (PKI), которая могла бы безопасно и эффективно предоставлять сертификаты и отзывать их, когда клиент или пользователь больше не будет иметь доступа к сети. Это обычно включает в себя создание собственного центра сертификации или построение доверительных отношений со сторонним центром сертификации, который может предоставлять сертификаты вашим клиентам.
Интерфейс управления Asterisk, или как его называют Asterisk Manager Interface (AMI) представляет собой интерфейс для управления вашей IP – АТС внешними приложениями, путем передачи команд или получения различных телефонных событий. Зачастую, данный интерфейс используется для интеграции 1С и asterisk, что позволяет принимать звонки в интерфейсе 1С, выполнять вызовы, подтягивать карточку клиента при входящем звонке и так далее.
Разберем настройку данного интерфейса и параметров подключения к нему на примере настройки через графический интерфейс администратора FreePBX 13 и через консоль сервера (CLI) в настройках CentOS
Настройка AMI в FreePBX
В верхнем меню навигации, выберите вкладку Settings и далее перейдите в раздел Asterisk Managers, как указано на скриншоте ниже:
Далее, для того, чтобы добавить нового пользователя, нажмите на кнопку Add Manager:
Откроется окно настройки нового пользователя. Разберем каждый пункт отдельно:
Manager Name - Имя пользователя AMI. Не должно содержать в себе пробелы.
Manager Secret - Пароль для пользователя AMI.
Deny - В данном поле вы можете указать IP – адрес и маску подсети, с которых необходимо запретить подключение к AMI по указанным данным. Если хотите указать несколько подсетей, то используйте символ &. Например, 192.168.1.0/255.255.255.0&192.168.2.0/255.255.255.0
Permit - Укажите IP – адрес и маску подсети, с которых разрешено подключение к AMI через этого пользователя. Синтаксис аналогичен как и в поле Deny.
Write Timeout - Укажите таймаут, который будет использовать Asterisk при записи данных через данную AMI учетную запись. По умолчанию, период равен 100 миллисекунд.
Следующим шагом будет настройка прав данного пользователя. Для этого, необходимо перейти во вкладку Rights
По окончанию настроек нажмите Submit
Настройка AMI в CLI
Сделаем тоже самое, но через консоль CentOS. Для этого, необходимо подключиться к серверу по SSH и выполнить следующие итерации:
Перед началом работ по изменению конфигурации, рекомендуем сделать резервную копию файла.
[root@localhost ~]# vim /etc/asterisk/manager.conf //подключаемся к конфигурационному файлу manager.conf
Делаем следующие настройки в секции [general]:
[general]
enabled = yes //включает AMI
port = 5038 //порт для подключения к AMI интерфейсу
bindaddr = 0.0.0.0 //откуда принимать подключения (по умолчанию, 0.0.0.0 – разрешено подключаться со всех адресов)
displayconnects=no ; //отображать ли подключения к Asterisk в командной строке
Переходим к настройке самого пользователя. Для этого, под секцией [general] необходимо создать нового пользователя. Дадим ему имя – test с паролем P@ssw0rd :
[test] //аналогично полю Manager Name в FreePBX
secret = P@ssw0rd //аналогично полю Manager Secret
deny=0.0.0.0/0.0.0.0 //аналогично полю Deny
permit=127.0.0.1/255.255.255.0 //аналогично полю Permit
read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
writetimeout = 5000 //аналогично полю Write Timeout
По окончанию настроек, нажмите комбинацию клавиш :x! для сохранения файла. После этого, введите команду:
[root@localhost ~]# asterisk -rx "core restart now"
Проверяем подключения к AMI
Теперь, после настроек, проверим подключение к AMI через созданного пользователя. Для этого, через консоль сервера сделаем подключение по протоколу telnet на порт 5038, который указан в секции [general] в параметре Port, конфигурационного файла manager.conf :
[root@localhost ~]# telnet localhost 5038
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Asterisk Call Manager/2.8.0
Action: login
Username: test
Secret: P@ssw0rd
Response: Success
Message: Authentication accepted
Готово. Ответом на подключения является сообщение Success. Это означает, что интерфейс настроен и готов к работе.