По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Channel event logging (события на канале) – система, созданная для детального логирования телефонных событий. Система CEL позволяет пошагово отслеживать сложные сценарии вызовов, последовательно записывая их в таблицу данных. Сегодня расскажем о типах событий CEL и о содержимом таблицы ‘cel’
?
Как и обычно, подключаемся к базе данных asteriskcdrdb:
[root@asterisk]# mysql // подключаемся к MySQL
mysql> use asteriskcdrdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
Смотрим содержимое таблица cel, видим поля и типы данных:
mysql> show columns from cel;
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| eventtype | varchar(30) | NO | | NULL | |
| eventtime | datetime | NO | | NULL | |
| cid_name | varchar(80) | NO | | NULL | |
| cid_num | varchar(80) | NO | | NULL | |
| cid_ani | varchar(80) | NO | | NULL | |
| cid_rdnis | varchar(80) | NO | | NULL | |
| cid_dnid | varchar(80) | NO | | NULL | |
| exten | varchar(80) | NO | | NULL | |
| context | varchar(80) | NO | MUL | NULL | |
| channame | varchar(80) | NO | | NULL | |
| appname | varchar(80) | NO | | NULL | |
| appdata | varchar(80) | NO | | NULL | |
| amaflags | int(11) | NO | | NULL | |
| accountcode | varchar(20) | NO | | NULL | |
| uniqueid | varchar(32) | NO | MUL | NULL | |
| linkedid | varchar(32) | NO | MUL | NULL | |
| peer | varchar(80) | NO | | NULL | |
| userdeftype | varchar(255) | NO | | NULL | |
| extra | varchar(512) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
20 rows in set (0.00 sec)
К описанию таблицы CEL мы вернемся чуть позже, а сейчас давайте разберем возможные события в рамках системы Channel Event Logging :
Событие
Описание
CHAN_START
Канал связи был создан
CHAN_END
Канал связи был разорван
LINKEDID_END
Канал связи с указанным ID был разорван
ANSWER
На созданном канале связи ответили на звонок. При звонке в город, данное событие генерируется когда удаленный (вызываемый абонент) поднимет трубку
HANGUP
Была повешена трубка. Как правило, это событие сразу же сопровождается событием CHAN_END. Разница в том, что HANGUP происходит когда трубка положена, а CHAN_END, когда Asterisk освободил все ресурсы, занимаемые этим каналом
APP_START
Определенное приложение было запущено для этого канала. Например, это может быть Dial, Busy или Congestion
APP_END
Указанное приложение в событие APP_START завершило свое выполнение
PARK_START
Была произведена «Парковка» вызова. Функция парковки, представляет собой определенный номер, в который помещается вызов, работу с которым, могут продолжить другие сотрудники.
PARK_END
Вызов был снят с «Парковки»
BRIDGE_START
Между двумя каналами образовалось соединение (мост). Данное событие сопровождает такие приложения, как Dial() или Queue()
BRIDGE_END
Мост между каналами был разрушен
BRIDGE_UPDATE
В соединении между каналами произошло обновление. Это события появляется тогда, например, если изменится имя или прочая канальная информация
BLINDTRANSFER
Был выполнен «слепой» (без предварительной консультации) трансфер
ATTENDEDTRANSFER
На канале был выполнен трансфер с предварительной консультацией
USER_DEFINED
Кастомное событие, которое определяется в приложении CELGenUserEvent()
В таблице выше мы перечислили основные события в рамках системы CEL. Теперь перейдем к описанию таблицы ‘cel’ в рамках базы asteriskcdrdb:
Столбец
Пример значения
Описание
eventtype
CHAN_START
Имя произошедшего события (все события описаны в таблице выше)
eventtime
2016-04-01 14:53:54
Время, в которое произошло указанное выше событие
cidname
Oleg Ivanov
Имя, передаваемое в рамках CallerID (CID), закрепленное за данным каналом
cidnum
84991111111
Номер, передаваемый в рамках CallerID (CID), закрепленный за данным каналом в рамках соответствующего события
cidani
84991111111
Automatic Number Identification (ANI), или другими словами – автоматическое определение номера на данном канале в рамках соответствующего события
cidrdnis
84991111234
Номер перенаправления на данном канале в рамках соответствующего события
ciddnid
84993456458
Набранный номер на канале в рамках соответствующего события
exten
7057
Добавочный номер, который был набран, в рамках плана нумерации
context
Local
Контекст для добавочного номера, который был набран
channame
SIP/0007B3060EB4-00000010
Имя установленного канала
appname
Dial
Название приложения, которое было выполнено
appdata
SIP/0007B3060EB4
Параметры, которые были переданы в приложении согласно плана нумерации
amaflags
DOCUMENTATION
Метка Automatic Message Accounting (AMA) – автоматический учет стоимости вызова.
accountcode
6473
Идентификатор аккаунта. Данное значение пустое по умолчанию, и определяется параметрами конкретного пользователя.
uniqueid
6547653456.18332
Уникальный идентификатор для канала
userfield
Chto ugodno
Пользовательское поле
linkedid
6547653456.18332
Данный идентификатор, позволяет связать воедино звонок по частям. Например, если одна часть звонка была входящей из города, следом был трансфер, потом еще один – у все этих вызовов будет разный uniqueid, но одинаковый linkedid
peer
SIP/0007B306054F-00000020
Название канала, к которому, который соединен (bridge) с каналом с идентификатором channame
Теперь, давайте рассмотрим как выглядит запись в таблице ‘cel’. Для этого выполним нижеследующий запрос к базе данных asteriskcdrdb:
mysql> SELECT * FROM `cel` WHERE `uniqueid` = '1459503113.15';
+------+------------+---------------------+-------------+-------------+-------------+-----------+----------+-------------+------------------+--------------------------------------------+------------+----------------------------------------------------------------------------------+----------+-------------+---------------+---------------+------+-------------+----------------------------------------------------------------------------+
| id | eventtype | eventtime | cid_name | cid_num | cid_ani | cid_rdnis | cid_dnid | exten | context | channame | appname | appdata | amaflags | accountcode | uniqueid | linkedid | peer | userdeftype | extra |
+------+------------+---------------------+-------------+-------------+-------------+-----------+----------+-------------+------------------+--------------------------------------------+------------+----------------------------------------------------------------------------------+----------+-------------+---------------+---------------+------+-------------+----------------------------------------------------------------------------+
| 2339 | CHAN_START | 2016-04-01 12:31:53 | | | | | | 89641111111 | from-internal | Local/89641111111@from-internal-00000004;2 | | | 3 | | 1459503113.15 | 1459503090.11 | | | |
| 2346 | APP_START | 2016-04-01 12:31:53 | 79252222222 | 79252222222 | 79252222222 | | | recordcheck | sub-record-check | Local/89641111111@from-internal-00000004;2 | MixMonitor | 2016/04/01/out-89641111111-79252222222-20160401-123153-1459503113.15.wav,ai(LOCA | 3 | | 1459503113.15 | 1459503090.11 | | | |
| 2347 | APP_END | 2016-04-01 12:31:53 | 79252222222 | 79252222222 | 79252222222 | | | recordcheck | sub-record-check | Local/89641111111@from-internal-00000004;2 | MixMonitor | 2016/04/01/out-89641111111-79252222222-20160401-123153-1459503113.15.wav,ai(LOCA | 3 | | 1459503113.15 | 1459503090.11 | | | |
| 2364 | HANGUP | 2016-04-01 12:32:10 | | 79252222222 | 79252222222 | | | h | from-internal | Local/89641111111@from-internal-00000004;2 | | | 3 | | 1459503113.15 | 1459503090.11 | | | {"dialstatus":"CANCEL","hangupcause":16,"hangupsource":"dialplan/builtin"} |
| 2365 | CHAN_END | 2016-04-01 12:32:10 | | 79252222222 | 79252222222 | | | h | from-internal | Local/89641111111@from-internal-00000004;2 | | | 3 | | 1459503113.15 | 1459503090.11 | | | |
+------+------------+---------------------+-------------+-------------+-------------+-----------+----------+-------------+------------------+--------------------------------------------+------------+----------------------------------------------------------------------------------+----------+-------------+---------------+---------------+------+-------------+----------------------------------------------------------------------------+
5 rows in set (0.00 sec)
В указанном выше запросе мы извлекли все содержимое таблицы ‘cel’, где поле uniqueid = 1459503113.15. Полученные данные можно обрабатывать и использовать для глубокой аналитики
Параллельно с развитием технологий в сегменте корпоративных сетей повышаются риски компании понести убытки от уязвимостей в безопасности сети. Злоумышленники прибегают к кибер – атакам на сеть предприятия с целью получения и распространения важной коммерческой документации, нанесения урона ИТ – комплексам с целью вывода из строя или нанесении урона по имиджу и репутации компании.
Число зарегистрированных нарушений сетевой безопасность на предприятиях, учебных заведениях и правительственных организациях резко возросло за последние несколько лет. Все чаще советы и даже подробные инструкции по «вторжению» в корпоративную сеть можно найти в свободном доступе в сети интернет, следовательно, специалисты по сетевой безопасности должны анализировать риски и применять определенные методики для предотвращения атак «извне».
Современные угрозы различны: атаки на отказ оборудования DDoS (Distributed Denial of Service), так называемые «черви», «трояны» и программы, предназначенные для похищения важной информации. Эти угрозы могут легко повредить важную информацию, восстановление которой займет много времени.
Рассмотрим подробнее базовые принципы сетевой безопасности, терминологию и решения по безопасности от компании Cisco Systems – Cisco Adaptive Security Appliances (ASA).
Первое, о чем пойдет речь – это «фаервол». «Фаервол» может устанавливаться как на границе сети (защита периметра), так и локально, на рабочих станциях.
Сетевые «фаерволы» обеспечивают безопасность периметра сети. Главная задача такого «фаервола» это запрет или разрешение трафика, который проходит через единую точку входа сети. Правила запрета определяются заранее настроенной конфигурацией оборудования.
Процесс фильтрации трафика включает в себя следующие пункты:
Простая фильтрация пакетов;
Многогранная проверка трафика;
Инспекция пакетов с сохранением состояния;
Трансляция сетевых адресов.
Простая фильтрация пакетов
Цель «простой» фильтрации пакетов заключается в контроле доступа в определенный сегмент сети в зависимости от проходящего трафика. Обычно, инспектирование проходит на четвертом уровне эталонной модели OSI (Open System Interconnection). Например, «фаервол» анализирует Transmission Control Protocol (TCP) или User Datagram Protocol (UDP) пакеты и принимает решение в зависимости от заранее настроенных правил, которые имеют название Access Control Lists (ACLs).
Следующие элементы проходят проверку:
Адрес отправителя;
Адрес получателя;
Порт отправителя;
Порт получателя;
Протокол
Нарушение информационной безопасности влечет прямые финансовые потери компаний
В рамках данного понятия оперирует устройство под названием «прокси-сервер». Прокси-сервер - это устройство, которое выступает посредником от имени клиента защищенной сети. Другими словами, клиенты защищенной сети отправляет запрос на соединение с незащищенной сетью интернет напрямую прокси-серверу [7]. Далее, прокси отправляет запрос в сеть от имени клиента, инициирующего соединение. Большая часть прокси-серверов работает на уровне приложений модели OSI. Фаерволы на базе прокси могут кэшировать (запоминать) информацию, чтобы ускорять работу клиентов. Одно из главных преимуществ прокси-сервера защита от различных WEB атак [10]. Недостаток прокси «фаерволов» - плохая масштабируемость.
Инспекция пакетов с сохранением состояния
Фаерволы по типу Statefull Packet Inspection (SPI) обладает большим функционалом по сравнению с простой фильтрацией пакетов. SPI-фаервол проверяет не только заголовки пакетов, но и информацию на уровне приложений, в рамках поля полезной нагрузки. На фаерволе может быть применено множество правил фильтрации, чтобы разрешать или запрещать трафик в зависимости от содержимого поля полезной нагрузки. SPI отслеживает параметрические данные соединения в течении сессии и записывает их в так называемую «таблицу состояний». В таблице хранится такая информация как время закрытия соединения, время открытия, установления и перезагрузки. Этот механизм предотвращает обширный список атак на корпоративную сеть.
Фаервол может быть сконфигурирован как устройство для разделения некоторых сегментов сети. Такие сегменты называют демилитаризированные зоны, или Demilitarized Zone (DMZ). Подобные зоны обеспечивают безопасность ИТ – комплексам, которые находятся в пределах этих зон, а также, различные уровни безопасности и политики между ними. DMZ могут иметь несколько назначений: например, они могут выступать как сегмент, в котором находится WEB серверная ферма, или как сегмент соединения к «экстранету» партнера по бизнесу.
Выше, изображена сеть, где в DMZ 1 находятся WEB сервера, доступные из сети Интернет, внутренней сети и сети партнера. Cisco ASA, расположенная в центре рисунка, контролирует доступ из сети партнера, ограничивая доступ из DMZ 2 только ресурсам WEB серверов, запрещая доступ к внутренней сети.
В следующих статьях мы расскажем о технологиях трансляции адресов и систем IDS/IPS.
Одиннадцатая часть тут.
Если у вас есть сеть, подобная той, что показана на рисунке 1, и Вам нужно чтобы А распространятл тот же контент в G, H, M и N, как бы вы это сделали?
Вы можете либо сгенерировать четыре копии трафика, отправив по одному потоку на каждый из приемников с помощью обычной (одноадресной - unicast) переадресации, либо каким-то образом отправить трафик на один адрес, который сеть знает для репликации, чтобы все четыре хоста получили копию. Этот последний вариант называется многоадресной рассылкой (multicast), что означает использование одного адреса для передачи трафика нескольким получателям. Ключевая проблема, решаемая в многоадресной рассылке, заключается в том, чтобы пересылать и реплицировать трафик по мере его прохождения через сеть, чтобы каждый получатель, заинтересованный в потоке, получал копию.
Важно: набор устройств, заинтересованных в получении потока пакетов от источника многоадресной рассылки, называется группой многоадресной рассылки. Это может быть немного запутанным, потому что адрес, используемый для описания многоадресного потока, также называется группой многоадресной рассылки в некоторых ситуациях. Эти два применения практически взаимозаменяемы в том, что набор устройств, заинтересованных в получении определенного набора пакетов многоадресной рассылки, присоединится к группе многоадресной рассылки, что, по сути, означает прослушивание определенного адреса многоадресной рассылки.
Важно: в случаях, когда многоадресный трафик является двунаправленным, эту проблему гораздо сложнее решить. Например, предположим, что существует требование создать группу многоадресной рассылки с каждым хостом в сети, показанной на рисунке 2, кроме N, и далее, чтобы любая многоадресная рассылка, переданная по адресу группы многоадресной рассылки, доставлялась каждому узлу в группе многоадресной рассылки.
Ключевая проблема для решения многоадресной рассылки может быть разбита на две проблемы:
Как узнать, какие устройства хотели бы получить копию трафика, передаваемого в группу многоадресной рассылки?
Как вы определяете, какие устройства в сети должны реплицировать трафик и на каких интерфейсах они должны отправлять копии?
Одним из возможных решений является использование локальных запросов для построения дерева, через которое многоадресный трафик должен передаваться по сети. Примером такой системы является разреженный режим (Sparse Mode) в Protocol Independent Multicast (PIM). В этом процессе каждое устройство отправляет сообщение соединения для многоадресных потоков, которые его интересуют; эти соединения передаются вверх по потоку в сети до тех пор, пока не будет достигнут отправитель (хост, отправляющий пакеты через многоадресный поток). Для иллюстрации этого процесса используется рисунок 2.
На рисунке 2:
A посылает некоторый трафик в группу многоадресной рассылки (адрес) - назовем его Z.
N хотел бы получить копию Z, поэтому он посылает запрос (соединение) своему вышестоящему маршрутизатору D для копии этого трафика.
D не имеет источника для этого трафика, поэтому он посылает запрос маршрутизаторам, к которым он подключен, на копию этого трафика. В этом случае единственный маршрутизатор D отправляет запрос В.
При каждом переходе маршрутизатор, получающий запрос, помещает интерфейс, на котором он получил запрос, в свой список исходящих интерфейсов (Outbound Interface List - OIL) и начинает пересылку трафика, полученного в данной многоадресной группе, полученной через любой другой интерфейс. Таким образом, может быть построен путь от получателя к отправителю трафика -это называется деревом обратного пути.
Второй вариант определения того, какие хосты заинтересованы в получении трафика для определенной группы многоадресной рассылки, - через своего рода сервер регистрации. Каждый хост, который хотел бы получить копию потока, может зарегистрировать свое желание на сервере. Есть несколько способов, которыми хост может обнаружить присутствие сервера, в том числе:
Обращение с адресом группы многоадресной рассылки как с доменным именем и поиск адреса сервера регистрации путем запроса адреса группы многоадресной рассылки.
Построение и ведение списка или сопоставления групп с серверами, отображаемыми в локальной таблице
Использование некоторой формы хэш-алгоритма для вычисления регистрационного сервера по адресу группы многоадресной рассылки
Регистрации могут отслеживаться либо устройствами на пути к серверу, либо, когда набор приемников и передатчиков известен, сервер может сигнализировать соответствующим устройствам вдоль пути, какие порты следует настроить для репликации и пересылки пакетов.