По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Domain Name System DNS - это сетевая система, содержащая информацию о каждом web-сайте в Интернете. Каждый сайт имеет свой уникальный IP-адрес, имеющий вид 111.222.111.222, а также доменное имя, например merionet.ru. Человеку гораздо проще запомнить доменное имя сайта, нежели набор цифр входящих в IP-адрес. Для этих целей и была разработана система DNS. Подобно записной книжке, в ней хранится таблица соответствия доменного имени сайта и его IP-адреса.
В DNS используется иерархическая древовидная структура серверов и имен. Самый верхний уровень это “root”, представляющий из себя точку (.) и следующий за ним домен верхнего уровня (Top Level Domain). Эти домены бывают двух типов:
Generic Top Level Domain (gTLD)
Например: .com (коммерческие web-сайты), .net(web-сайты сетевых структур), .org (вэб- сайты организаций), .edu (web-сайты образовательных структур)
Country Code Top Level Domain (ccTLD)
Например: .ru (Россия), .us (США), .uk (Великобритания), .in (Индия)
Данные, которые сообщают веб-серверу, как ответить на ваш запрос называются DNS записи или Zone Files. Каждая запись содержит информацию о конкретном объекте. DNS-сервер использует записи, чтобы отвечать на запросы хостов из определенной доменной зоны. Например, запись address mapping (A) отвечает за связку host name и IP-адреса, а запись reverse-lookup pointer (PTR), за связку IP-адреса и host name. Стоит отметить, что в терминологии DNS очень много различных записей, мы же приведем основные:
A Record - Содержит информацию об определенном доменном имени и соответствующем IP-адресе. DNS-сервер обращается к данной записи, чтобы ответить на запрос, содержащий доменное имя. Ответом будет IP-адрес, указанный в записи.
PTR Record - Связывает IP-адрес с определенным доменным именем.
NS (Name Server) Record - Связывает доменное имя со списком DNS-серверов, отвечающих за данный домен.
MX (Mail Exchange) Record - Связывает доменное имя со списком серверов почтового обмена для данного домена. Например, при отправке письма на адрес example@merionet.ru, данное письмо будет перенаправлено на сервер, указанный в MX записи.
Типы запросов DNS
В терминологии DNS существует три типа запросов:
Recursive – Такие запросы можно представить так: “Какой IP-адрес у a.merionet.ru?”
При получении recursive запроса, DNS-сервер выполняет следующие действия:
Хост отправляет локальному DNS-серверу запрос “Какой IP-адрес у a.merionet.ru?”
DNS-сервер проверяет наличие записи a.merionet.ru в локальных таблицах и не находит ее.
DNS-сервер отправляет запрос IP-адреса a.merionet.ru к root-серверу
Root-сервер отвечает, что надо обратиться к TLD серверу, отвечающий за домен .ru
DNS-сервер, получив ответ от root-сервера, отправляет recursive запрос одному из ccTLD-серверов, отвечающих за домен .ru
TLD-сервер отвечает, что нужно обратиться к серверу, отвечающему за домен merionet.ru
DNS-сервер отправляет запрос IP-адреса a.merionet.ru к серверу, отвечающему за домен merionet.ru
Сервер обращается к A Record и находит там соответствующий IP-адрес для a.merionet.ru
Таким образом, хост получает запрашиваемую страницу по адресу a.merionet.ru
Второй тип DNS-запросов – это Iterative запросы. Данные запросы передаются между DNS-серверами, когда один из них не имеет соответствующих записей. Таким образом, инициатор запроса будет контактировать с сервером, который имеет нужную запись
Последний тип запросов – Inverse. Собственно из названия данного запроса понятно, что они работают по инверсному принципу, то есть при известном IP-адресе запрашивается информация о доменном имени.
Привет! В предыдущей статье, посвященной основам WLAN, вы узнали о беспроводных клиентах, формирующих ассоциации с беспроводными точками доступа (AP) и передающих данные по Wi-Fi. В сегодняшней статье мы рассмотрим анатомию защищенного соединения в беспроводных сетях.
Основы защищенного соединения в беспроводных сетях.
Все клиенты и точки доступа, которые соответствуют стандарту 802.11, могут сосуществовать на одном канале. Однако не всем устройствам, поддерживающим стандарт 802.11, можно доверять. Нужно понимать, что данные передаются не как в проводной сети, то есть непосредственно от отправителя к получателю, а от приемника до ближайшей точки доступа, располагаемой в зоне досягаемости.
Рассмотрим случай, изображенный на рисунке ниже. Беспроводной клиент соединяется с каким-либо удаленным объектом с использованием зашифрованного пароля. В сети так же присутствуют два не доверенных пользователя. Они находятся в пределах диапазона сигнала клиента и могут легко узнать пароль клиента, перехватив данные, отправленные по каналу. Особенности беспроводной связи позволяют легко перехватывать пересылаемые пакеты злоумышленниками.
Если данные передаются по беспроводным каналам, как их можно защитить от перехвата и взлома? В стандарте 802.11 предусмотрены механизмы безопасности, которые используются для обеспечения доверия, конфиденциальности и целостности беспроводной сети. Далее более подробно разберем методы беспроводной безопасности.
Аутентификация.
Для того чтобы начать использовать беспроводную сеть для передачи данных, клиенты сначала должны обнаружить базовый набор услуг (BSS), а затем запросить разрешение на подключение. После чего клиенты должны пройти процедуру аутентификации. Зачем это делать? Предположим, что ваша беспроводная сеть позволяет подключиться к корпоративным ресурсам, располагающим конфиденциальной информацией. В этом случае доступ должен предоставляться только тем устройствам, которые считаются надежными и доверенными. Гостевым пользователям, если они вообще разрешены, разрешается подключиться к другой гостевой WLAN, где они могут получить доступ к не конфиденциальным или общедоступным ресурсам. Не доверенным клиентам, вообще рекомендуется запретить доступ. В конце концов, они не связаны с корпоративной сетью и, скорее всего, будут неизвестными устройствами, которые окажутся в пределах досягаемости вашей сети.
Чтобы контролировать доступ, WLAN могут аутентифицировать клиентские устройства, прежде чем им будет разрешено подключение. Потенциальные клиенты должны идентифицировать себя, предоставив информацию учетных данных для точки доступа. На рисунке ниже показан основной процесс аутентификации клиента.
Существует много методов аутентификации по «воздуху». Есть методы, которые требуют ввода только кодового слова, которое является общим для всех доверенных клиентов и AP. Кодовое слово хранится на клиентском устройстве и при необходимости передается непосредственно в точку доступа. Что произойдет, если устройство будет утеряно или похищено? Скорее всего, любой пользователь, владеющий данным устройством, сможет аутентифицироваться в сети. Другие, более строгие методы аутентификации требуют взаимодействия с корпоративной базой данных пользователей. В таких случаях конечный пользователь должен ввести действительное имя пользователя и пароль.
В обычной жизни, при подключении к любой беспроводной сети, мы неявно доверяем ближайшей точке доступа проверку подлинности нашего устройства. Например, если вы на работе, используя устройство с беспроводной связью, найдете WI-Fi, скорее всего, подключитесь к ней без колебаний. Это утверждение верно для беспроводных сетей в аэропорту, торговом центре, или дома - вы думаете, что точка доступа, которая раздает SSID, будет принадлежать и управляться организацией, в которой вы находитесь. Но как вы можете быть уверены в этом?
Как правило, единственная информация, которой вы владеете- это SSID транслируемый в эфир точкой доступа. Если SSID знаком, вы, скорее всего, подключитесь к ней. Возможно, ваше устройство настроено на автоматическое подключение к знакомому SSID, так что оно подключается автоматически. В любом случае, есть вероятность невольно подключиться к тому же SSID, даже если он рассылается злоумышленником.
Некоторые атаки, организованные злоумышленником, осуществляются посредством подмены точки доступа. «Поддельная» точка доступа, аналогично настоящей, так же рассылает и принимает запросы, и затем осуществляет ассоциацию клиентов с АР. Как только клиент подключается к «поддельной» AP, злоумышленник может легко перехватить все данные передаваемые от клиента к центральному узлу. Подменная точка доступа может также отправлять поддельные фреймы управления, которые деактивируют подключенных клиентов, для нарушения нормального функционирования сети.
Чтобы предотвратить этот тип атаки, называемой «man-in-the-middle», клиент должен сначала идентифицировать точку доступа, и только потом подключиться, используя логин и пароль (пройти аутентификацию). На рисунке ниже показан простой пример данного защищенного подключения. Также, клиент, получая пакеты управления, должен быть уверен, что они отправлены с проверенной и доверенной точки доступа.
Конфиденциальность сообщений.
Предположим, что клиент изображенный на рисунке 3, должен пройти аутентификацию перед подключением к беспроводной сети. Клиент должен идентифицировать точку доступа и её фреймы управления для подключения перед аутентификацией себя на устройстве. Отношения клиента с точкой доступа могли бы быть более доверительными, но передача данных по каналу все еще подвергается опасности быть перехваченной.
Чтобы защитить конфиденциальность данных в беспроводной сети, данные должны быть зашифрованы. Это возможно кодированием полезной нагрузки данных в каждом фрейме, пересылаемым по WI-Fi, непосредственно перед отправкой, а затем декодирования ее по мере поступления. Идея заключается в использование единого метода шифрования/дешифрования как на передатчике, так и на приемнике, чтобы данные могли быть успешно зашифрованы и расшифрованы.
В беспроводных сетях каждый WLAN может поддерживать только одну схему аутентификации и шифрования, поэтому все клиенты должны использовать один и тот же метод шифрования при подключении. Вы можете предположить, что наличие одного общего метода шифрования позволит любому клиенту сети перехватывать пакеты других клиентов. Это не так, потому что точка доступа при подключении к клиенту высылает специальный ключ шифрования. Это уникальный ключ, который может использовать только один клиент. Таким образом точка доступа рассылает каждому клиенту свой уникальный ключ. В идеале точка доступа и клиент- это те два устройства, которые имеют общие ключи шифрования для взаимодействия. Другие устройства не могут использовать чужой ключ для подключения. На рисунке ниже конфиденциальная информация о пароле клиента была зашифрована перед передачей. Только точка доступа может успешно расшифровать его перед отправкой в проводную сеть, в то время как другие беспроводные устройства не могут.
Точка доступа также поддерживает «групповой ключ» (group key), когда ей необходимо отправить зашифрованные данные всем клиентам ячейки одновременно. Каждый из подключенных клиентов использует один и тот же групповой ключ для расшифровки данных.
Целостность сообщения
Шифрование данных позволяет скрыть содержимое от просмотра, при их пересылке по общедоступной или ненадежной сети. Предполагаемый получатель должен быть в состоянии расшифровать сообщение и восстановить исходное содержимое, но что, если кто-то сумел изменить содержимое по пути? Получатель не сможет определить, что исходные данные были изменены.
Проверка целостности сообщений (MIC)- это инструмент безопасности, который позволяет защитить от подмены данных. MIC представляет собой способ добавления секретного штампа в зашифрованный кадр перед отправкой. Штамп содержит информацию о количестве битов передаваемых данных. При получении и расшифровке фрейма устройство сравнивает секретный шифр с количеством бит полученного сообщения. Если количество бит совпадает, то соответственно данные не были изменены или подменены. На рисунке ниже изображен процесс MIC.
На рисунке показано, что клиент отправляет сообщение точке доступа через WLAN. Сообщение зашифровано, «741fcb64901d». Сам процесс MIC заключается в следующем:
Исходные данные –«P@ssw0rd».
Затем вычисляется секретный шифр MIC (штамп).
После вычисления штампа происходит шифрование данных и MIC завершается.
На стороне получателя следует расшифровка, вычисление MIC и сравнение штампов.
В сегодняшней статье расскажем о том, как проверить скачанные или добавленные модули в графическом интерфейсе FreePBX 13.
/p>
C недавних пор FreePBX имеет встроенную систему проверки подписи для всех официальных модулей. Это было сделано для того, чтобы конечный пользователь или администратор системы могли без проблем определить, подвергался ли модуль изменениям (например, из-за уязвимости системы безопасности, или же модуль вовсе вредоносный).
Неподписанные модули после обновления
Если после обновления с FreePBX 2.11 до FreePBX версии 12 или 13, на главной странице появляются информационные сообщения о неподписанных модулях (Unsigned Modules) это может означать, что Вы не завершили последнюю часть обновления. Для того, чтобы её корректно завершить требуется подключиться к вашей IP-АТС по ssh или через консоль и ввести следующий ряд команд:
amportal chown
amportal a ma refreshsignatures
amportal a reload
Эти команды запустят внутреннюю проверку модулей, а также проверку того, что все файлы имеют правильные разрешения. Если будут обнаружены модули, которые не имеют подписи, то система загрузит их заново и перезапустится. После этого, все предупреждения и ошибки должны исчезнуть.
Сообщения о неподписанных модулях на главной странице
Уведомления о подписи модулей были введены в FreePBX 12 как сообщения, которые появляются на главной панели (Dashboard) при обнаружении каких-либо проблем. Выглядит это примерно так:
Вы можете детально узнать подробности этих информационных уведомлений, нажав кнопку Details. Откроется анализ того, что не удалось корректно выполнить в процессе проверки целостности.
В качестве альтернативы можно также скрыть эти сообщения безопасности, нажав X в правом верхнем углу. Таким образом, уведомления будут скрыты до тех пор, пока не появится новый неподписанный модуль. Эти уведомления будут также отображаться на панели управления, в разделе System Overview и приходить по электронной почте в следующем виде:
Желтые уведомления безопасности являются общими предупреждениями. В то время как красные сообщения, означают, что файл был изменен по сравнению с тем, каким он первоначально был во FreePBX. Например:
Вы можете отключить все уведомления о недействительной подписи в меню Advanced Settings, установив Enable Module Signature Checking в положение False.
Настоятельно не рекомендуем выставлять флаг Enable Module Signature Checking в положение False в системах, которые работают в продакшене, поскольку данное действие отключает несколько уровней системной защиты.
Типы предупреждений
Существует два типа предупреждений о подписи модуля, их описание ниже:
Unsigned - неподписанные модули. Это модули, которые не были санкционированы командой разработчиков FreePBX. Они потенциально могут иметь вредоносный код, который может угрожать вашей системе. Установка этих модулей на свой страх и риск.
Altered - изменённые модули. Это модули, имеющие файлы, которые были модифицированы по сравнению с их первоначальной версией. Рекомендуется повторно загрузить эти модули, чтобы предотвратить возможные проблемы с вашей АТС.