По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет описан процесс настройки SIP – транка на IP – АТС Asterisk с помощью в FreePBX 13 для провайдера Телфин.
Создание SIP - транка
Первый шаг является стандартным для настройки транка –в веб-интерфейсе необходимо открыть следующую вкладку: Connectivity – Trunks. Далее кликнуть на кнопку + Add Trunk.
Выберите «Add SIP (chan_sip) Trunk». Далее необходимо присвоить имя транку и задать исходящий CallerID
После, необходимо зайти во вкладку sip Settings и вновь ввести имя SIP - транка и информацию в поле Details:
Соответственно, Username – номер, полученный от провайдера Телфин, Secret – ваш пароль и host – адрес самого провайдера.
context=inbound_telphin
type=peer
username=4996546542 \тут должен быть ваш логин
fromuser=4996546542
secret=P@ssw0rd \тут должен быть ваш пароль
host=voice.telphin.com
port=5068
promiscredir=yes
Следующим шагом является настройка входящих параметров SIP - транка. Откроем вкладку Incoming, заполним поля “Context”, “Details”, “Register String”
type=peer
username=4996546542
host=voice.telphin.com
port=5068
И строка регистрации:
4996546542:P@ssw0rd@voice.tephin.com:5068/4996546542
Теперь ваша АТС будет регистрироваться у Телфина и входящие звонки будут приходить в контекст [inbound_telphin] на экстеншен 4996546542.
Исходящая маршрутизация
Далее необходимо задать имя маршрута и номер в Outbound Routes – номер такой же, как и при создании транка - в данном случае 4996546542.
Обратите внимание, так же необходимо указать транк в Trunk Sequence for Matched Routes, который был только что создан.
И, как финальный шаг, указываем правила набора для использования данного маршрута
После всех проведенных манипуляций, жмём Apply Config наверху страницы.
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No.
Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД
В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз.
В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение.
Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров.
Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).
В общем, как таблица в экселе, только данные могут быть связаны.
Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее.
Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.
В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.
Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе.
Базы данных "ключ-значение" (key-value)
Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных.
Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.
Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину.
Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB.
Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД)
Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.
Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя.
В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.
Базы данных документов или документориентированные БД (Document DB)
Подробнее про них можно прочитать в нашей отдельной статье.
Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации.
Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы.
Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид.
Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД.
Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.
Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии.
Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента.
Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB.
Графовые БД (Graph DB)
Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные.
Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь.
Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества.
Самые популярные графовые базы: Neo4j и DGraph
Поисковые БД (Search-engine database)
Они, как понятно из названия, нужны для поиска данных из большого количества источников.
Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста.
По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается.
И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе.
Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia
Базы данных временных рядов (Time series database)
Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений.
Примеры - InfluxDB и Prometheus
Многомодульные БД (multi-model)
Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных.
Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.
По статистике, в данный момент более 90% всех заражений происходят по электронной почте. Цифра кажется безумной только на первый взгляд, но, я уверен, вы также открывали множество ссылок и писем просто на полном автомате, или же даже по причине любопытства.
Давайте сначала разберем возможные способы атаки через электронную почту, а затем рассмотрим способы борьбы со злоумышленниками.
Способы и средства атаки
В общем и целом, атаки на электронную почту можно условно разделить на целевые (spear-phishing) и на атаки массового поражения.
В первом случае письмо приходит вам от доверенного человека, чаще всего даже вашего начальника и родственника, и там используется какой-либо посыл для того, чтобы вы открыли файл или же перешли по ссылке. Очевидно, что 99,99% людей попадутся на этот крючок, т.к такие письма ничем не вызывают подозрения - ни доменом, ни смыслом написанного, ни типом вложения. Все выглядит ровно так, как в тысяче других уже открытых прежде вами писем. Но есть нюанс - чаще всего для повышения открываемости таких писем используются психологические приемы. К числу таких приемов относятся призывы к срочности, помощи или жажде наживы, так что если письмо отличается от большинства прочих письма от вашего знакомого/начальника - будьте внимательны.
Во втором случае злоумышленники просто массово рассылают письмо с вредоносной ссылкой или вредоносным файлом, причем зачастую это выглядит как запароленный архив и сам пароль в тексте письма. С такими письмами бороться не в пример проще программно-аппаратными методами, но и ложными фишинговыми рассылками по вашей компании, чтобы бы сразу стал понятен список пользователей, которые склонны открывать такие письма.
По сути, отдельно также можно упомянуть обычный спам, который, казалось бы, совершенно безопасен. Но давайте обратимся к обычной математике: в день сотрудник тратит 30 секунд на удаление/прочтение спам-писем, а в компании 5000 сотрудников. Это значит, что сотрудники тратят в день практически 42 часа на борьбу со спамом. Нехило, да?
Способы и средства защиты
Давайте попробуем проанализировать сказанное выше и подумать, как можно защититься от такого добра, и для анализа возьмем второй сценарий с массовым фишингом.
Для начала нужно проверить домен на его наличие в различным репутационных списках
Оценить домен с помощью Защита вашего e-mail происходит с помощью специальной многоуровневой фильтрации, которая уже выполняет проверку отправляющего сервера на основе представленных данных SPF, DMARC, DKIM;
Оценить вложения на предмет их "злокачественности", то есть прогнать через антивирусные движки и при необходимости "обезвредить" - то есть преобразовать файлы с макросами в pdf формат и пометить письмо как подозрительное;
Отправить вложения в песочницу, если они поступили из странного источника и не отдавать письмо пользователю до получения вердикта;
Проверить ссылки в письме и открыть их через прокси-сервер, для определения точного сайта;
Оценить изображения в письме на предмет спама/вредоносов;
Сравнить содержимое письма с теми шаблонами вредоносных рассылок, которые происходят в мире в данный момент;
SPF - представлен в роли расширения для протокола SMTP. С помощью него возможно проверить подлинность домена отправителя; DMARC - является технической спецификацией, предназначенной для защиты электронной почты от спама и фишинговых писем; DKIM - цифровая подпись. Письмо отправленной из обслуживаемого домена присваивает себе такую подпись;
Использование этих технологий позволяет вам быть уверенным в двух вещах: ваш почтовый домен никто не спуфит, и что отправитель - это легитимный товарищ;
К сожалению, даже эти 7 шагов не являются панацеей, хотя их и можно выполнять автоматически с помощью специализированных решений, вроде Barracuda, Cisco ESA, FortiMail и пр. Касперских.
Кроме того, нужно быть уверенным, что:
Учетные записи не были скомпрометированы;
Ваша почтовый сервер не упадет от DDoS атаки;
Ваши сотрудники используют VPN для доступа к вашему почтовому серверу;
У всех сотрудников установлен антивирус на рабочих станциях;
Вы используете надежное и современное решение по защите почты, а именно - почтовую прокси, к примеру одну из перечисленных выше;
Вы постоянно проводите обучение ваших сотрудников азам ИБ и возможных типов атак с помощью электронной почты;
Вы шифруете исходящую и входящую почту с помощью PGP-ключей;
Обсудим некоторые особенности защиты E-mail от Google, Yandex, Mail.ru
Когда вы используете корпоративную почту от одного из известных IT-гигантов, вы уже оказываетесь защищены многослойной системой безопасностью. Но есть большое "но" - а именно тот факт, что вы не можете тюнинговать эту защиту именно под специфику вашей организации (если не говорить про защиту O365 от Microsoft).
Кроме того, двухфакторная аутентификация также является важной функцией, и все значимые представители облачных почтовых служб дают вам такой функционал. К примеру, Яндекс.Почта имеет двухэтапную систему аутентификации пользователей, а сервис Gmail обеспечивает защиту с помощью токен-ключа. Это может означать только одно, если же вы потеряли свой пароль, то злоумышленник никак не сможет получить доступ к вашей электронной почте без специального кода, пришедшего вам на SMS.