• Установка phpMyAdmin из исходников в Debian 9 Stretch

    10.04.2020 Автор:Жаконда
    8 391 Просмотров 1 Комментарий

    Разберем как установить phpMyAdmin последней версии из исходников в Debian 9 Stretch. Так же рассмотрим как обезопасить доступ к нему.

     

    Устанавливаем необходимые пакеты:

    apt-get install php php-common php-cli libapache2-mod-php php-gd php-mbstring php-zip php-xml php-curl php-bz2 php-mysql php-common php-tcpdf php-gettext mariadb-server -y

     

    Скачиваем последнюю версию phpMyAdmin, распаковываем скачанный архив и перемещаем его в пользовательский каталог:

    wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.zip

unzip phpMyAdmin-latest-all-languages.zip
rm phpMyAdmin-latest-all-languages.zip
mv phpMyAdmin-*-all-languages/ /usr/share/phpmyadmin

     

    Создадим каталог в котором phpMyAdmin будет хранить свои временные файлы и назначаем права доступа к нему для веб-сервера (www-data):

    mkdir -p /var/lib/phpmyadmin/tmp
chown -R www-data:www-data /var/lib/phpmyadmin

     

    Создаем базу данных и таблицы конфигурации для phpMyAdmin. Применяем поставляемый вместе с phpMyAdmin скрипт:

    mariadb < /usr/share/phpmyadmin/sql/create_tables.sql

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (3 голос(ов), в среднем: 2,67 из 5)
    Загрузка...

  • Исправление ошибки assertion failed: http.cc:1533: «!Comm::MonitorsRead(serverConnection->fd)» на Squid 4

    08.04.2020 Автор:Жаконда
    5 452 Просмотров Комментариев нет

    У одного из читателей блога наблюдалась проблема в произвольной перезагрузке Squid при работе в режиме перехвата HTTPS трафика с использованием «bump all». В логах (/var/log/squid/cache) в момент перезагрузки Squid появляется запись assertion failed: http.cc:1533: «!Comm::MonitorsRead(serverConnection->fd)».

     

    Решается данная проблема путем применения не-официального патча (long-term fix for v4, take2 (unofficial)). В ниже описанном порядке действий, можно использовать материалы по сборке Squid c поддержкой HTTPS:

    БесполезноСлабоватоПриемлемоОтличноПревосходно (14 голос(ов), в среднем: 2,64 из 5)
    Загрузка...

  • Как добавить поддержку шифрования по ГОСТ Р 34.10-2012 в OpenSSL 1.1.1d на Debian 9 Stretch

    06.04.2020 Автор:Жаконда
    24 279 Просмотров 6 комментариев

    В работе имеется веб-сайт на котором реализована авторизация посредством ЕСИА (Единая система идентификации и аутентификации). До недавнего времени можно было использовать самоподписной RSA сертификат, но с 1 апреля 2020 года, для взаимодействия с ЕСИА необходимо использовать сертификат с алгоритмом шифрования по ГОСТ Р 34.10-2012.

     

    В связи с этим мне необходимо было реализовать возможность работы с алгоритмом ГОСТ Р 34.11-2012 в OpenSSL на Debian 9 Stretch.

     

    Путем перелопачивания множества информации по этому вопросу и проб использования движка GOST-Engine с различными версиями OpenSSL, для себя определил рабочую связку OpenSSL 1.1.1d + GOST-Engine.

     

    В качестве памятки опишу действия для реализации связки OpenSSL 1.1.1d + GOST-Engine на Debian 9 Stretch.

     

    Устанавливаем необходимые пакеты:

    apt-get install build-essential wget git cmake unzip gcc -y

     

    Выполняем сборку OpenSSL 1.1.1d, выполняем команды:

    cd /opt

wget "https://github.com/openssl/openssl/archive/OpenSSL_1_1_1d.zip" -O "OpenSSL_1_1_1d.zip"
unzip OpenSSL_1_1_1d.zip && cd openssl-OpenSSL_1_1_1d

./config shared -d --prefix=/usr/ssl --openssldir=/usr/ssl
make all && make install

rm /usr/bin/openssl
ln -s /usr/ssl/bin/openssl /usr/bin/openssl
echo "/usr/ssl/lib" >> /etc/ld.so.conf.d/ssl.conf && ldconfig

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (3 голос(ов), в среднем: 2,00 из 5)
    Загрузка...

  • Настройка Autoprovision на телефонах Cisco SPA (3xx-5xx серии) в связке DHCP + TFTP

    10.03.2020 Автор:Жаконда
    10 873 Просмотров 1 Комментарий

    Рассмотрим как реализовать Autoprovision на телефонах — Cisco SPA (3xx-5xx серии) в связке DHCP (на базе Windows Server 2012 R2) + TFTP.

     

    Исходные данные:

        • Телефоны Cisco 504G
        • TFTP-сервер на Debian 8 Jessie (установка) — 192.168.1.2
        • Развернутый DHCP-сервер на Windows Server 2012 R2 с областью:
          • Telephone (10.10.10.0/24)

    Задача:

    Необходимо чтобы телефон Cisco SPA 504G, автоматически настраивал общие параметры, обновлял прошивку и регистрировал SIP аккакунт.

     

    Настройка DHCP-сервера

    В созданной области Telephone (10.10.10.0/24) необходимо добавить «Опцию». Переходим в параметры области и добавляем параметр со значением IP-адреса TFTP-сервера:

     

    Теперь при подключении телефона к локальной сети, он определит TFTP-сервер.

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
    Загрузка...

  • Подключение SIP транка от Ростелеком (Виртуальная АТС) к FreePBX 14 в связке с Asterisk 16

    10.03.2020 Автор:Жаконда
    28 377 Просмотров 3 комментария

    Понадобилось недавно подключить SIP-транк от Ростелекома к FreePBX 14 в связке с Asterisk 16. В качестве памятки опишу порядок действий, для того чтобы иметь возможность на FreePBX принимать\звонить через SIP-транк Ростелекома.

     

    В личном кабинете Виртуальной АТС (Ростелеком) переходим в «Пользователи» и заходим в «user1» (можно создать нового, кому как удобней).

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
    Загрузка...

  • Уведомление о занятости абонента при входящем звонке на занятую линию с включенным Call Waiting в FreePBX 14

    29.02.2020 Автор:Жаконда
    8 512 Просмотров 7 комментариев

    В качестве памятки опишу способ доработки функции второй линии (Call Waiting) в FreePBX 14.

     

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

     

    Было бы куда информативнее проигрывать звонящему информационное сообщение, о том что абонент разговаривает, оставайтесь на линии или перезвоните позднее..

     

    Как оказалось в FreePBX есть определенная обработка macro-dialout-one-predial-hook описанная в /etc/asterisk/extensions.conf и которая срабатывает до момента непосредственного звонка абоненту. В этой обработке можно проверить статус выдываемого абонента и в случае если статус линии занят, то проигрывать звонящему сообщение и продолжить вызов.

     

    В файл конфигурации /etc/asterisk/extensions_custom.conf в секцию [from-internal-custom] добавляем:

    [from-internal-custom]

;----- Playback Wait for answer in INUSE line -----
[macro-dialout-one-predial-hook]
exten => s,1,Noop(DEVICE STATE - ${DEVICE_STATE(${DSTRING})})
exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "INUSE"]?Playback(custom/wait_for_answer))
exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "INUSE"]?Set(D_OPTIONS=Ttm))
    ПОЯСНЕНИЕ. Возможные варианты состояния линии (DEVICE_STATE) — UNKNOWN, NOT_INUSE, INUSE, BUSY, INVALID, UNAVAILABLE, RINGING, RINGINUSE, ONHOLD (более подробно можно почитать в оф. документации)
    ИНФОРМАЦИЯ. По-умолчанию FreePBX смотрит каталог со звукам по пути — /var/lib/asterisk/sounds/ru

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (1 голос(ов), в среднем: 4,00 из 5)
    Загрузка...

  • Работа мессанджера Whatsapp через прокси-сервер Squid 4.9

    27.02.2020 Автор:Жаконда
    10 048 Просмотров Комментариев нет

    В работе имеется прокси-сервер Squid 4.9, работающий с HTTPS поддержкой. Столкнулся с проблемой в работе мессанджера Whatsapp (Web, Desktop версии) на конечных системах.

     

    Проблема заключается в том что web, desktop версии Whatsapp не соединяются со своими серверами и выдают сообщение что отсутствует подключение к сети интернет. В логах Squid (access.log) видны следующие события при попытке Whatsapp установить соединение:

    1582785108.113    154 10.10.15.9 TCP_MISS/400 231 GET https://web.whatsapp.com/ws - ORIGINAL_DST/31.13.72.52 -
1582785108.278    161 10.10.15.9 TCP_REFRESH_MODIFIED/200 390 GET https://web.whatsapp.com/status.json - ORIGINAL_DST/31.13.72.52 text/json

     

    Видно что приложение пытается открыть WebSocket соединение, о чем свидетельствует /ws в строке запроса. Так же в браузере при просмотре кода можно увидеть что не удается выполнить WebSocket соединение (WebSocket connection to ‘wss://web.whatsapp.com/ws’ failed: Error during WebSocket handshake: Unexpected response code: 400)

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (1 голос(ов), в среднем: 4,00 из 5)
    Загрузка...

  • Блокировка исходящих звонков на определенные номера или номера из заданного списка в FreePBX 14

    14.02.2020 Автор:Жаконда
    7 647 Просмотров Комментариев нет

    От коллеги по цеху поступила просьба помочь с реализацией интересной задачи, которая заключается во исполнении №152-ФЗ (Федеральный закон «О персональных данных») по которому необходимо блокировать исходящие звонки на номера клиентов, который дали отказ на них.

     

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

     

    Я увидел решение задачи несколькими способами, рассмотрим этим варианты реализации.

     

    Исходные данные:

    • Debian 9 Strech
    • Asterisk 16 + FreePBX 14
    • Номерная маска операторов — _146XX

     

    Вариант #1

    В файл конфигурации /etc/asterisk/extensions_custom.conf добавляем следующую обработку:

    [from-internal-custom]
exten => _89858887766/_146XX,1,GoSub(sub-marketing-block,s,1)
exten => _89855554433/_146XX,1,GoSub(sub-marketing-block,s,1)
exten => _89852221100/_146XX,1,GoSub(sub-marketing-block,s,1)
; -- УКАЗЫВАЕМ ОСТАЛЬНЫЕ НОМЕРА КОТОРЫЕ ПОД ЗАПРЕТОМ --

[sub-marketing-block]
exten => s,1,Background(custom/message)
exten => s,2,WaitExten(3)
exten => 1,1,Goto(s,5)
exten => i,1,Goto(s,6)
exten => t,1,Goto(s,6)
exten => s,5,Return()
exten => s,6,Hangup()

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
    Загрузка...

  • Перехват и просмотр HTTPS трафика на прокси-сервере Squid 4.9

    03.02.2020 Автор:Жаконда
    26 891 Просмотров 54 комментария

    Рассмотрим как реализовать перехват пользовательских HTTPS-запросов в сеть интернет для дальнейшего анализа и учета их. Все ниже описанные действия производятся на Debian 9 Stretch с установленным прокси-сервером Squid 4.9.

     

    Для работы с HTTPS трафиком необходимо, чтобы Squid был собран с следующими параметрами:

    --enable-ssl-crtd --with-openssl
    ПОДСКАЗКА. Как собрать из исходников Squid 4.9 с необходимыми параметрами, можно посмотреть из этой статьи.

     

    Для просмотра HTTPS трафика, прокси-сервер Squid должен иметь свой собственный СА сертификат, который используется для подписывания динамически генерируемых сертификатов для серверов, к которым пользователи посылают запросы.

     

    Выполним генерацию CA сертификата и назначим права доступа для него, выполним команды:

    cd /usr/local/etc/squid/ssl
openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout squidca.pem -out squidca.pem

chown proxy:proxy squidca.pem 
chmod 640 squidca.pem

     

    Конвертируем сертификат в формат для импорта на пользовательские системы:

    openssl x509 -outform der -in squidca.pem -out squidca.crt
    ПОДСКАЗКА. Как скачать сертификат из Linux системы в Windows, можно посмотреть из этой статье.
    Полученный сертификат необходимо установить в «Доверенные корневые сертификаты» на все пользовательские компьютеры, которые будут работать через прокси-сервер Squid. В доменной среде это проще всего сделать при помощи GPO (Group Policy objects).

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
    Загрузка...

  • Интеграция Squid 4.9 с Active Directory на Debian 9 Stretch. Реализация Kerberos аутентификации и LDAP авторизации.

    29.01.2020 Автор:Жаконда
    10 256 Просмотров 11 комментариев

    Разберем как настроить связь Squid 4.9 c Active Directory через Kerberos аутентификацию и Basic LDAP авторизацию, для предоставления доступа в интернет по доменным учетным записям и разграничение прав согласно заданным группам безопасности Active Directory.

     

    Исходные данные:

    • Контроллер домена (DC1) на Windows Server 2012 R2, домен JAKONDA.LOCAL
    • Прокси-сервер Squid 4.9 (squid) на Debian 9 Stretch

     

    Подготовка системы (Debian 9 Stretch)

    Перед началом выполнения ниже описанных действий обновляем систему до актуального состояния:

    apt-get update && apt-get upgrade -y

     

    Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле (/etc/hostname):

    squid.jakonda.local

     

    Так же файл (/etc/hosts) приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP:

    127.0.0.1	localhost
127.0.1.1	squid.jakonda.local squid

     

    Настраиваем синхронизацию времени с контроллером домена, выполняем установку NTP, выполняем синхронизацию времени с контроллером домена:

    apt-get install ntp ntpdate

ntpdate dc1.jakonda.local
    Более подробно о синхронизации времени на Debian 8 Jessie/Ubuntu Server 14.04 можно почитать в этой статье

    Читать далее…

    БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
    Загрузка...
Предыдущая страница Следующая страница
© IT-блог Жаконды All Rights Reserved.
Яндекс.Метрика