По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
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. Полученные данные можно обрабатывать и использовать для глубокой аналитики
img
Параллельно с развитием технологий в сегменте корпоративных сетей повышаются риски компании понести убытки от уязвимостей в безопасности сети. Злоумышленники прибегают к кибер – атакам на сеть предприятия с целью получения и распространения важной коммерческой документации, нанесения урона ИТ – комплексам с целью вывода из строя или нанесении урона по имиджу и репутации компании. Число зарегистрированных нарушений сетевой безопасность на предприятиях, учебных заведениях и правительственных организациях резко возросло за последние несколько лет. Все чаще советы и даже подробные инструкции по «вторжению» в корпоративную сеть можно найти в свободном доступе в сети интернет, следовательно, специалисты по сетевой безопасности должны анализировать риски и применять определенные методики для предотвращения атак «извне». Современные угрозы различны: атаки на отказ оборудования 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.
img
Одиннадцатая часть тут. Если у вас есть сеть, подобная той, что показана на рисунке 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) и начинает пересылку трафика, полученного в данной многоадресной группе, полученной через любой другой интерфейс. Таким образом, может быть построен путь от получателя к отправителю трафика -это называется деревом обратного пути. Второй вариант определения того, какие хосты заинтересованы в получении трафика для определенной группы многоадресной рассылки, - через своего рода сервер регистрации. Каждый хост, который хотел бы получить копию потока, может зарегистрировать свое желание на сервере. Есть несколько способов, которыми хост может обнаружить присутствие сервера, в том числе: Обращение с адресом группы многоадресной рассылки как с доменным именем и поиск адреса сервера регистрации путем запроса адреса группы многоадресной рассылки. Построение и ведение списка или сопоставления групп с серверами, отображаемыми в локальной таблице Использование некоторой формы хэш-алгоритма для вычисления регистрационного сервера по адресу группы многоадресной рассылки Регистрации могут отслеживаться либо устройствами на пути к серверу, либо, когда набор приемников и передатчиков известен, сервер может сигнализировать соответствующим устройствам вдоль пути, какие порты следует настроить для репликации и пересылки пакетов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59