пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня подробно расскажем как найти практическое применение знаниям, полученным в статье про структуру asteriskcdrdb, а именно, как сделать ежедневные отчеты о входящих звонках на почту.
Создание скрипта
Чтобы наш .php скрипт смог подключиться к базе данных, необходимо создать пользователя, с правами, которые буду позволять ему извлекать необходимую информацию. Для этого, подключимся к нашему серверу по SSH
[root@asterisk]# mysql
mysql>CREATE USER ' user'@'localhost' IDENTIFIED BY 'P@ssw0rd';
На данном этапе мы создали пользователя user с паролем P@ssw0rd. Далее дадим ему необходимые права:
mysql> GRANT SELECT ON asteriskcdrdb.cdr TO 'user'
Создадим файл с расширением .php, в котором мы отразим подключение к нашей базе данных. Запишем эту конструкцию так:
$hostname = "localhost"; //адрес хоста. Скрипт мы будем запускать на той же машине, на которой находится БД asteriskcdrdb;
$username = "user"; //отражаем пользователя
$password = "P@ssw0rd"; //пароль для созданного нами пользователя
$dbName = "asteriskcdrdb"; //база данных, в которой хранятся необходимые нам данные
$today = date('y-m-d'); // сегодняшняя дата в формате 2016-03-25
$counter = 1; // счетчик
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение "); // соединиться к БД
mysql_select_db($dbName) or die(mysql_error()); //выбрать базу данных. Если произойдет ошибка - вывести ее
$headers = "; charset=windows-1251
"; //заголовок для письма
$headers .= "From: Мерион Нетворкс <info@merionet.ru>
";
$headers .= "Reply-To: info@merionet.ru
";
Предположим, что все входящие звонки приходят на номер секретаря – 100. Так же мы знаем, что при звонке из города, мы видим номер звонящего, который содержит в себе больше 3 символов (пусть у нас используется трехзначная внутренняя нумерация). Наша задача сводится к формулировке запроса к таблице cdr. Добавляем к нашему .php файлу:
$query = "SELECT `dst` , `src` , `duration` , `dstchannel` , `calldate` , `disposition` FROM `cdr` WHERE `calldate` >='$today 00:00:00' AND `calldate` <='$today 23:59:59' AND LENGTH( `src` ) >3 AND `dst` = '100';" ;
$res=mysql_query($query) or die(mysql_error()); // Выполнить запрос. Если произойдет ошибка - вывести ее.
$number = mysql_num_rows($res); // Как много нашлось строк
У нас почти все готово. Осталось только обработать данные на выходе. Для этого, нам понадобится следующая конструкция:
//формируем шапку нашей таблицы со значениями
$mes .= '
table style="max-width: 575px;border-bottom:none; margin: 0 auto;border-spacing: inherit;">
thead>
tr style="border-bottom: 2px solid #05477c;">
th style="padding:10px; color: #fff; max-width: 150px;background:#05477c;">Порядковый номер</th>
th style="padding:10px; color: #fff; max-width: 150px;background:#05477c;">Дата</th>
th style="padding:10px; color: #fff; max-width: 100px;background:#05477c;">От кого</th>
th style="padding:10px; color: #fff; max-width: 45px;background:#05477c;">Кому</th>
th style="padding:10px; color: #fff; max-width: 45px;background:#05477c;">Статус звонка</th>
/tr>
/thead>';
//перебираем значения ассоциативного массива. Число элементов данного массива равно числу строк на выходе sql запроса
while ($row=mysql_fetch_array($res)) { $mes .= '
tbody>
tr style="width: 100px;">
td style="padding:10px; border-bottom: 1px solid #eee; text-align:center;">'.$counter.'</td>
td style="padding:10px; border-bottom: 1px solid #eee; text-align:center;min-width: 100px;">'. $row['calldate'].'</td>
td style="padding:10px; border-bottom: 1px solid #eee; text-align:center;min-width: 100px;">'. $row['src'].'</td>
td style="padding:10px; border-bottom: 1px solid #eee; text-align:center;">'.$row['dst'].'</td>
td style="padding:10px; text-align:center; border-bottom: 1px solid #eee; min-width: 120px; ">'.$row['disposition'].'</td>
/tr>';
$counter = $counter + 1;
}
Теперь, мы храним в переменной $mes html таблицу, которая готова к отправке на почту. Добавим в конец скрипта:
mail("info@merionet.ru", 'Все входящие за '.$today.'', $mes, $headers);
ВАЖНО! Если вы используете кириллические символы, установите кодировку .php файла на Кириллицу (windows-1251)
Итак, готово. Давайте посмотрим что приходит нам на почту:
Работает. Давайте сделаем ежедневное задание на отработку этого скрипта через cron. Сделаем, например, ежедневно, в 17:30, когда рабочий день подходит к концу:
30 17 * * * php /home/admin/mail_report.php
Не забудьте в начала скрипта поставить открывающий тэг php, а в конце скрипта закрывающий.
Сегодня поговорим о том, как установить сторонний модуль для FreePBX 13, который позволит отслеживать и собирать статистику о работе Вашего Call-центра - Asternic Call Center Stats, а также о другой разработке Asternic - Asternic CDR Reports, являющуюся более простой и удобной адаптацией встроенного модуля FreePBX - CDR Reports.
Установка Asternic Call Center Stats
Для начала установим Asternic Call Center Stats. Версия, которая будет представлена в данной статье – Lite 1.5, является бесплатной open-source версией модуля. Более расширенный функционал доступен в версии Pro.
Скачаем модуль с сайта разработчика:
cd /usr/src
wget http://download.asternic.net/asternic-stats-1.5.tgz
Распакуем файлы
tar zvxf asternic-stats-1.5.tgz
cd asternic-stats
Создаем новую базу в MySQL. Обратите внимание, что в тестовой версии Lite скрипт qstat.sql выполняет операции с БД qstatlite, поэтому мы должны использовать только такое имя при конфигурации. Для создания новой базы нужно знать пароль от mysql.
mysqladmin -u root -p create qstatslite
mysql -u root -p qstatslite < sql/qstats.sql
Редактируем файл /usr/src/asternic-stats/html/config.php чтобы настроить необходимые аутентификационные реквизиты для доступа к базе.
$dbhost = 'localhost';
$dbname = 'qstatslite';
$dbuser = 'root';
$dbpass = '1111';
$manager_host = "127.0.0.1";
$manager_user = "admin";
$manager_secret = "admin";
$language = "en"; {Если хотите русифицировать модуль – ставьте “ru”}
Отредактируйте файл /etc/asterisk/manager.conf чтобы установить требуемый пароль для Asterisk Manager’а.
Затем необходимо отредактировать файл /usr/src/asternic-stats/parselog/config.php и в нём также установить аутентификационные данные для новой базы.
$queue_log_dir = "/var/log/asterisk/";
$queue_log_file = "queue_log"
$dbhost = 'localhost';
$dbname = 'qstatslite';
$dbuser = 'root';
$dbpass = '1111';
Важно! Убедитесь, чтобы значения $dbname, $dbuser и $dbpass совпадали в обоих файлах (/usr/src/asternic-stats/html/config.php и usr/src/asternic-stats/parselog/config.php )
Наконец последовательно выполняем следующие команды:
mv /usr/src/asternic-stats/html /var/www/html/queue-stats
mv /usr/src/asternic-stats/parselog /usr/local
Тем самым мы переместили папку html в корневую директорию Apache, а папку parselog в домашнюю директорию. Если операционная система укажет, что папки /var/www/html/queue-stats не существует, то создайте ее с помощью команды:
mkdir /var/www/html/queue-stats
Последний шаг – запуск планировщика cron, который будет периодически просматривать папку parselog и заносить информацию от туда в базу данных.
crontab -e
Заносим в cron следующее правило:
0 * * * * php -q /usr/local/parselog/parselog.php convertlocal
Если всё было сделано правильно, то при переходе по ссылке http://”IP-адрес _Asterisk” /queue-stats , мы увидим сам модуль и сможем начать с ним работать. На этом установка Asternic Call Center Stats завершена.
Установка Asternic CDR Reports
С модулем Asternic CDR Reports всё гораздо проще. Просто качаем дистрибутив с сайта разработчика, а потом добавляем его через функционал управления модулями FreePBX. Для этого переходим в Admin -> Module Admin и выбираем Upload Modules
Выбираем Upload (From Hard Disk), указываем путь к скаченному дистрибутиву и нажимаем Upload (From Hard Disk)
После чего появится сообщение о том, что модуль успешно загружен и что нужно включить его через local module administration.
Переходим по ссылке, ищем новый модуль в разделе Reports, нажимаем Install и кнопку Process в самом низу.
Подтверждаем установку кнопкой Confirm
По завершению установки, мы увидим соответствуюшее сообщение:
Теперь модуль доступен из главной панели в разделе Reports
Если всё было сделано правильно, то мы увидим интерфейс модуля и сможем начать работу с ним. На этом установка модуля Asternic CDR Reports завершена
Kubernetes стал незаменимым инструментом для оркестровки, масштабирования, автоматического развертывания и управления контейнеризованными приложениями.
А если проще, Kubernetes – это система, которая обеспечивает совместную работу различных приложений на разных компьютерах.
Следует отметить, что эта система, как правило, работает именно с контейнеризованными приложениями, такими как образы Docker. Строго говоря, это тип виртуализации, при котором приложения запускаются в изолированных пользовательских пространствах, которые называются
контейнерами
.
Проблемы безопасности контейнеров
То, как приложение будет работать и взаимодействовать с другими приложениями и внешним миром, определяет пользователь. А все, что предполагает вмешательство человека, подвержено появлению дефектов и ошибок.
Серьезность ошибки напрямую зависит от навыка человека, который управляет контейнерами. Иногда даже самая несерьезная ошибка может сломать всю систему. Один из самых ярких примеров – уязвимость в Java под названием Log4j, которая совсем недавно привела к серьезному сбою по всей сети Интернет.
Как правило, программное обеспечение/приложение не защищено от злоумышленников на 100%, это просто невозможно. Но нельзя ошибочно полагать, что наличие утечек и уязвимостей – это нормально, и надеяться на то, что их никто не обнаружит.
Искать уязвимости безопасности и дефекты нужно всегда. Кроме того, по мере возможности их необходимо устранять.
Дефекты могут сделать кластер или контейнер уязвимыми, а это, в свою очередь, может позволить неавторизованным лицам воспользоваться ими в своих целях. А учитывая тот факт, что популярность Kubernetes только растет, нам необходимо более серьезно подумать о том, как оценить его действенность и решить проблемы безопасности конвейеров.
Дабы вы смогли лучше организовать защиту ваших конфигураций и программ Kubernetes, давайте рассмотрим несколько распространенных уязвимостей, а также изучим рекомендации по обеспечению безопасности Kubernetes.
Необходимость выбора конфигурации
Если вы только начали знакомиться с Kubernetes, но при этом пытаетесь развернуть проект самостоятельно, вам может быть сложно разобраться в правилах конфигурации безопасности. Это происходит потому, что Kubernetes в таких случаях, к сожалению, не предоставляет правил конфигурации по умолчанию, которых было бы достаточно для обеспечения безопасности.
Несмотря на то, что конфигурация безопасности не так важна на начальных этапах, позже, когда вы перейдете к более поздним этапам развертывания в производственной среде, она станет критичной.
Аналогичная проблема существует и с тем, как взаимодействуют друг с другом модули. Эти права на «общение» определяются сетевыми политиками, но по умолчанию такие политики не имеют отношения к модулям. И снова, это, то, что вам придется настроить самостоятельно.
Для решения этой проблемы есть простой обходной путь – обеспечить ролевое управление доступом (RBAC - Role-Based Access Control) для того, чтобы понимать, кто имеет доступ к API и какие права доступа у них есть.
Для того, чтобы повысить безопасность по части считывания объектов и уровня привилегий, вы можете воспользоваться такими атрибутами, как
allowPrivilegeEscalation
и
readOnly
.
Следующая политика демонстрирует, какие уровни полномочий есть у пользователя «bob»:
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
В данном случае пользователь «bob» может только считывать объекты из пространства имен «projectCaribou».
Если бы запрос имел тип «write» или «update», то действие было бы отклонено.
Вредоносный код в образах Docker
Так как Kubernetes зачастую работает с контейнеризованными приложениями, как правило, с образами Docker, чаще всего злоумышленники проникают в кластер или узел, получая доступ из этого самого контейнеризованного приложения.
Конечно, существует большое количество решений для предотвращения различных типов атак, но для того, чтобы предотвратить DoS-атаки, вы всегда можете просто ограничить использования ресурсов памяти.
Это можно сделать, настроив Ingress-контроллер. Этот контроллер будет ограничивать количество запросов за определенный период времени, например, он поставить ограничение на 10 запросов в секунду или 1000 запросов в минуту.
Реализовать такой подход можно, ограничив количество запросов на IP-адрес клиента или ограничив запросы на уровне узла службы.
Или же вы можете определить список для контроля доступа, чтобы запросы могли отправлять только определённые выбранные вами IP-адреса. В таком случае вы гарантируете, что никакой трафик анонимных запросов не перегрузит сервер, а также, что сервер будет обрабатывать трафик/запросы только из надежных источников.
Кроме того, вы можете сканировать приложения перед тем, как его развертывать. Это также является отличной практикой для обнаружения и немедленного устранения вредоносного кода.
Кластер безопасен, а передача данных – нет
В большинстве случаев приоритет отдается именно безопасности кластера, так как именно он управляет приложениями. Но есть одна вещь, о которой многие забывают – по умолчанию нет никаких мер безопасности и шифрования передачи данных.
Это довольно распространенная проблема, и, если вы будете ее игнорировать, то злоумышленники смогут получить несанкционированный доступ к вашей системе. Это значит, что обеспечивать взаимодействие служб в кластере должен протокол TLS (протокол защиты транспортного уровня).
Сетевые технологии развиваются, и это привело к появлению таких продуктов, как LinkerD, которые могут поддерживать протокол TLS по умолчанию. Кроме того, они предоставляют дополнительную телеметрическую информацию о взаимодействии служб.
Аналогичный принцип применяется и к «etcd», где хранится состояние кластера. Если вы оставите эту базу данных незащищенной, то она может стать привлекательной целью для злоумышленников, так как в случае удачной атаки злоумышленник сможет захватить весь кластер. Даже если у них будет доступ только для чтения, они смогут злоупотребить им, чтобы повысить свои привилегии.
Контроль времени выполнения
Даже если вы успешно справитесь с уязвимостями, связанными с политикой и конфигурацией, на вашем пути могут появится дополнительные препятствия во время выполнения. Один из примеров уязвимости, связанной с безопасностью во время выполнения, является взломанный контейнер, в котором запускаются различные вредоносные процессы.
Конечно, майнинг криптовалют стал довольно популярной целью для злоумышленников, которые пытаются вмешаться в настройки контейнера, но они могут выполнять и другие вредоносные действия, например, они могут сканировать сетевые порты для того, чтобы получить доступ к нужным ресурсам из скомпрометированного контейнера.
Для того, чтобы справиться с проблемами, возникающими во время выполнения, вы можете постоянно отслеживать активность выполнения критических с точки зрения безопасности контейнеров, например, активность процессов и передачу данных по сети.
Кроме того, настоятельно рекомендуется учитывать информацию о времени сборки и развертывания для того, чтобы вы могли сравнить наблюдаемую и ожидаемую активность во время выполнения. Таким образом, обнаружить любое нестандартное поведение будет намного проще.
Несоответствие стандартам
Соблюдать стандарты безопасности, нормативные требования и нормы, а также внутренние правила организации в облачных системах может быть не так просто.
Самая распространенная причина несоблюдения требований – игнорирование аспекта безопасности в процессе внедрения контейнера.
Лучший способ устранить такие уязвимости – принять все необходимые меры безопасности еще на ранних этапах жизненного цикла контейнера. Также неплохой практикой для сокращения накладных расходов считается автоматизация всех необходимых проверок (насколько это возможно).
Заключение
Безопасность – важный компонент контейнерных технологий, и это то, что обязательно нужно учитывать и внедрять при работе с Kubernetes.
Все-таки ваша конечная цель должна заключаться в том, чтобы помешать злоумышленникам получить доступ к вашим системам. А если им все-таки удастся это сделать, инфраструктура должна быть настолько хорошей, чтобы обнаружить аномальную активность и предотвратить ее распространение.
Как говорит Рори МакКьюн – главный эксперт по безопасности в NCC Group:
«Kubernetes – сложная система, и при ее настройке очень легко допустить ошибку».
Уязвимости контейнеров и Kubernetes в целом могут привести к серьезным негативным последствиям, если, конечно, вы не исправите их вовремя.