По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На сегодняшний день проблемы информационной безопасности в мире приобретают всё большую актуальность. В СМИ часто можно наткнуться на новость об очередной успешной хакерской атаке, крупной утечке критичных данных или очередном вирусе-вымогателе, который срывает работу целых компаний. Даже если Вы человек далёкий от информационной безопасности и мира информационных технологий, то Вы всё равно наверняка слышали о вирусе “WannaCry”, уязвимостях “Spectre” и “Meltdown” и может быть даже о недавней атаке на устройства компании Cisco, которая ударила по крупным провайдерам и парализовала много сервисов и сетевых сегментов.
Однако, широкой огласке обычно подвергаются новости об атаках и уязвимостях, носящие массовый характер, направленных на наиболее распространенные инфраструктурные системы. Мы же хотим рассказать о том, как обстоит ситуация с информационной безопасностью в отдельной в отдельно взятой сфере - IP телефонии и решений VoIP. Разберём наиболее важные проблемы и тренды развития данного направления.
Проблемы информационной безопасности в VoIP
Если раньше, выбирая на чём строить офисную телефонию, заказчиков больше всего волновали вопросы стоимости и надёжности, то в связи с нынешним положением, вопросы защиты и безопасности всё чаще начинают преобладать. Хотя IP телефония имеет массу преимуществ по сравнению с системами традиционной телефонии, её намного легче взломать. В случае с традиционной системой PSTN злоумышленник должен получить физический доступ к среде передачи или системам, которые задействованы в обмене голосовой информацией. IP телефония – это прежде всего сеть с коммутацией пакетов, которые передаются на ряду с другими корпоративными сервисами – Интернетом, почтой и другими. Если эта сеть недостаточно защищена, то злоумышленнику даже не обязательно находиться в одной стране с системой IP телефонии, чтобы получить доступ к критичным данным, украсть их или модифицировать.
Вот почему необходимо обеспечивать многоуровневую защиту систем корпоративной IP телефонии. Недостаточно просто поставить стойкий пароль к интерфейсу управления. Это должен быть чёткий набор определённых мер, применяемых в комплексе – межсетевое экранирование, антивирусная защита, регулярные обновления программного обеспечения, шифрование передаваемых данных и другое.
Отдельно следует уделить внимание повышению осведомлённости своих сотрудников об атаках из разряда социальной инженерии. Одним из наиболее распространённых векторов атаки данного типа на сегодняшний день является “фишинг”. Суть его заключается в том, что злоумышленник рассылает “письма счастья” с вредоносными вложениями, в надежде на то, что человек откроет это вложение и тем самым, загрузит на свой компьютер вредонос. Защититься от таких атак можно сразу на нескольких уровнях:
Межсетевой экран, на котором адрес отправителя фишинговых писем должен быть заблокирован. Автоматизировать процесс получения актуального списка адресов активных отправителей для блокировки на МСЭ, можно с помощью решений Threat Intelligence. Существуют как платные решения от таких компаний как Anomali, ThreatConnect или EclecticIQ, так и OpenSource, например, YETI и MISP.
Решение для защиты почтового сервера, которое проверяет все письма на предмет подозрительных вложений, адреса отправителя, блокирует спам. Примерами таких решений является Kaspersky Security для почтовых серверов, AVG Email Server Edition для ME, McAfee Security for Email Servers. Кстати, в этом случае также можно автоматизировать процесс блокировки с помощью решений TI.
Антивирусное ПО для защиты оконечных устройств, которое заблокирует опасное вложение, если всё-таки вредонос сможет пролезть через МСЭ и почтовый сервер. Для этого подойдёт Kaspersky Endpoint Security, Norton, Trend Micro и другие.
Но если от фишинга можно защититься с помощью специализированных программ и аппаратных решений, то от следующих видов атак, основанной на социальной инженерии, защититься гораздо труднее. Возможно, Вы не знали, но помимо традиционного email “фишинга”, существует также и телефонный. Например, сотруднику Вашей компании на голосовую почту может прийти сообщение от “банка” о том, что кто-то пытался получить доступ к его счёту и что ему необходимо срочно перезвонить по оставленному номеру. Не трудно догадаться, что на другом конце провода, его будет ждать злоумышленник, который постарается сделать всё, чтобы втереться в доверие, украсть данные его счёта, чтобы в итоге похитить денежные средства.
Существует также телефонный “вишинг”. Этот тип атаки направлен на первую линию сотрудников, которые принимают все входящие звонки в Вашей компании. На общий номер поступает звонок от какой-нибудь известной организации или персоны, а дальше с помощью методов психологического давления, доверчивого сотрудника заставляют что-либо сделать. В самом лучшем случае, позвонивший будет агрессивно требовать соединить его с руководством компании, чтобы предложить какие-нибудь услуги, в самом худшем - выдать конфиденциальную или критически важную информацию. А что, если злоумышленник узнает каким банком обслуживается Ваша компания и позвонит бухгалтеру от лица “Вашего банка”? К такому тоже нужно быть готовым.
Защититься от подобного типа атак можно было бы с помощью некоего аналога Threat Intelligence для VoIP – списка телефонных номеров, с которых поступают “фишинговые” и “вишинговые” звонки, чтобы заблокировать их на АТС. Однако, такого решения пока нет, поэтому придётся просвещать сотрудников на тему безопасности.
Безопасность облачных систем
Сейчас уже сложно обозначить чёткие границы офисной сети. С распространением облачных решений, распределённых сетей VPN и всеобщей виртуализации, корпоративная сеть уже перестала иметь чёткую географическую привязку.
Аналогично обстоят дела и в сфере VoIP. Каждый крупный провайдер IP телефонии имеет в своем наборе услуг облачную АТС, которая настраивается в считанные минуты и способна обеспечить телефонией компанию любого размера и неважно где территориально она расположена. Облачная или виртуальная АТС – это очень удобное решение, которое привлекает заказчиков тем, что не надо держать лишние сервера в здании и обслуживать их. Вместо этого, можно просто арендовать необходимые серверные мощности или сервис телефонии. Однако, с точки зрения информационной безопасности, облачные АТС – это идеальная цель для хакерских атак. Потому что, как правило, аккаунты для доступа к настройкам АТС, находятся в открытом доступе. Если владелец аккаунта не озаботится созданием стойкого пароля, то он рискует оплатить немаленький счёт за телефонные разговоры злоумышленника или предоставить доступ к записям разговоров своих сотрудников. В этой связи при выборе провайдера следует также проверить обеспечивает ли он дополнительные мероприятия по защите целостности и конфиденциальности данных. Используется шифрование при подключении к аккаунту с настройками облачной АТС, шифруются ли данные при их транспортировке.
Тренды развития направления ИБ в VoIP
Наиболее распространённым методом защиты корпоративной инфраструктуры является организация защищённой сети VPN, когда подключение извне осуществляется по зашифрованному каналу, а данные внутри сети передаются в незашифрованном виде. Это относится и к голосовому трафику. Однако, тенденции развития информационных технологий указывают на то, что в недалёком будущем голосовая информация также будет подвергаться шифрованию. Большинство VoIP вендоров уже давно имплементируют в своих решениях поддержку таких протоколов как SIP/TLS, SRTP, ZRTP и д.р, стимулируя пользователей применять внедрять ещё один уровень защиты. Например, большинство IP-телефонов и решений видеоконференцсвязи от компании Cisco, а также системы CUCM, CUBE, Cisco SBC, UCCS и д.р поддерживают TLS 1.2 и SRTP. Самое распространённое Open Source решение IP-АТС Asterisk имеет поддержку защищённых протоколов передачи медиа трафика начиная с версии 1.8. В программной Windows-based АТС 3CX версии V15, поддержка SRTP включена по умолчанию.
VoIP решения зачастую очень тесно интегрируются с другими корпоративными системами, такими как CRM, ERP, CMS, не говоря уже о таких каналах бизнес коммуникаций как email, обмен мгновенными сообщениями (чат) и социальные сети, формируя в совокупности концепцию UC (Unified Communications). Потенциальные преимущества, которые несёт данная концепция очень привлекательны, но вместе с тем, создаётся множество точек уязвимых к возможному взлому. Недостаточный уровень защиты одной из них может быть угрозой всей корпоративной сети. Поэтому разработчики, несомненно, будут усиливать безопасность каналов интеграции данных систем.
Можно также ожидать интеграцию систем корпоративной телефонии в такие средства защиты как DLP (средства защиты от утечек), адаптации метрик VoIP в SIEM системах (система управления информацией и событиями безопасности), а также появление унифицированных репутационных баз (Threat Intelligence) со списками потенциально опасных номеров или других индикаторов компрометации, относящихся к VoIP, которые будут автоматически блокироваться имеющимися средствами защиты.
Перед тем как начать: это цикл статей. Мы рекомендуем до этого материала ознакомиться со статьей про Interlayer Discovery.
Хотя IPv6 является основной темой этих лекций, в некоторых случаях IPv4 представляет собой полезный пример решения; Address Resolution Protocol IPv4 (ARP) является одним из таких случаев. ARP - это очень простой протокол, используемый для решения проблемы межуровневого обнаружения, не полагаясь на сервер любого типа. Рисунок ниже будет использован для объяснения работы ARP.
Предположим, A хочет отправить пакет C. Зная IPv4-адрес C,
203.0.113.12 недостаточно, чтобы A правильно сформировал пакет и поместил его на канал связи по направлению к C. Чтобы правильно построить пакет, A также должен знать:
Находится ли C на том же канале связи, что и A
MAC или физический адрес C
Без этих двух частей информации A не знает, как инкапсулировать пакет в канал связи, поэтому C фактически получит пакет, а B проигнорирует его. Как можно найти эту информацию? На первый вопрос, находится ли C на том же канале вязи, что и A, можно ответить, рассмотрев IP-адрес локального интерфейса, IP-адрес назначения и маску подсети.
ARP решает вторую проблему, сопоставляя IP-адрес назначения с MAC-адресом назначения, с помощью следующего процесса:
Хост A отправляет широковещательный пакет каждому устройству в сети, содержащему адрес IPv4, но не MAC-адрес. Это запрос ARP; это запрос A на MAC-адрес, соответствующий 203.0.113.12.
B и D получают этот пакет, но не отвечают, поскольку ни один из их локальных интерфейсов не имеет адреса 203.0.113.12.
Хост C получает этот пакет и отвечает на запрос, снова используя unicast пакет. Этот ответ ARP содержит как IPv4-адрес, так и соответствующий MAC-адрес, предоставляя A информацию, необходимую для создания пакетов в направлении C.
Когда A получает этот ответ, он вставляет сопоставление между 203.0.113.12 и MAC-адресом, содержащимся в ответе, в локальном кэше ARP. Эта информация будет храниться до истечения времени ожидания; правила тайм-аута записи кэша ARP различаются в зависимости от реализации и часто могут быть настроены вручную. Продолжительность кэширования записи ARP - это баланс между слишком частым повторением одной и той же информации в сети в случае, когда сопоставление IPv4-адресов с MAC-адресами не меняется очень часто, и отслеживанием любых изменений в расположении устройство в случае, когда конкретный адрес IPv4 может перемещаться между хостами.
Когда A получает этот ответ, он вставляет сопоставление между 203.0.113.12 и MAC-адресом, содержащимся в ответе, в локальный кэш ARP. Эта информация будет храниться до тех пор, пока не истечет время ожидания; правила для тайм-аута записи кэша ARP варьируются в зависимости от реализации и часто могут быть настроены вручную. Продолжительность кэширования записи ARP - это баланс между тем, чтобы не повторять одну и ту же информацию слишком часто в сети, в случае, когда сопоставление IPv4-MAC-адресов меняется не очень часто, и идти в ногу с любыми изменениями в местоположении устройства, в случае, когда конкретный IPv4-адрес может перемещаться между хостами.
Любое устройство, получающее ответ ARP, может принять пакет и кэшировать содержащуюся в нем информацию. Например, B, получив ответ ARP от C, может вставить сопоставление между 203.0.113.12 и MAC-адресом C в свой кэш ARP. Фактически, это свойство ARP часто используется для ускорения обнаружения устройств, когда они подключены к сети. В спецификации ARP нет ничего, что требовало бы от хоста ожидания запроса ARP для отправки ответа ARP. Когда устройство подключается к сети, оно может просто отправить ответ ARP с правильной информацией о сопоставлении, чтобы ускорить процесс начального подключения к другим узлам на том же проводе; это называется gratuitous ARP. Gratuitous ARP также полезны для Duplicate.
Gratuitous ARP также полезны для обнаружения дублирующихся адресов (Duplicate Address Detection - DAD); если хост получает ответ ARP с адресом IPv4, который он использует, он сообщит о дублированном адресе IPv4. Некоторые реализации также будут посылать серию gratuitous ARPs в этом случае, чтобы предотвратить использование адреса или заставить другой хост также сообщить о дублирующемся адресе.
Что произойдет, если хост A запросит адрес, используя ARP, который не находится в том же сегменте, например, 198.51.100.101 на рисунке 5? В этой ситуации есть две разные возможности:
Если D настроен для ответа как прокси-ARP, он может ответить на запрос ARP с MAC-адресом, подключенным к сегменту. Затем A кэширует этот ответ, отправляя любой трафик, предназначенный для E, на MAC-адрес D, который затем может перенаправить этот трафик на E. Наиболее широко распространенные реализации по умолчанию не включают прокси-ARP.
A может отправлять трафик на свой шлюз по умолчанию, который представляет собой локально подключенный маршрутизатор, который должен знать путь к любому пункту назначения в сети.
IPv4 ARP - это пример протокола, который отображает interlayer идентификаторы путем включения обоих идентификаторов в один протокол.
Обнаружение соседей IPv6
IPv6 заменяет более простой протокол ARP серией сообщений Internet Control Message Protocol (ICMP) v6. Определены пять типов сообщений ICMPv6:
Тип 133, запрос маршрутизатора
Тип 134, объявление маршрутизатора
Тип 135, запрос соседа
Тип 136, объявление соседа
Тип 137, перенаправление
Рисунок ниже используется для объяснения работы IPv6 ND. Чтобы понять работу IPv6 ND, лучше всего проследить за одним хостом, поскольку он подключен к новой сети. Хост A на рисунке ниже используется в качестве примера.
A начнет с формирования link local address, как описано ранее. Предположим, A выбирает fe80 :: AAAA в качестве link local address.
Теперь A использует этот link local address в качестве адреса источника и отправляет запрос маршрутизатору на link local multicast address (адрес многоадресной рассылки для всех узлов). Это сообщение ICMPv6 типа 133.
B и D получают этот запрос маршрутизатора и отвечают объявлением маршрутизатора, которое является сообщением ICMPv6 типа 134. Этот одноадресный пакет передается на локальный адрес канала A, используемый в качестве адреса источника, fe80 :: AAAA.
Объявление маршрутизатора содержит информацию о том, как вновь подключенный хост должен определять информацию о своей локальной конфигурации в виде нескольких флагов.
Флаг M указывает, что хост должен запросить адрес через DHCPv6, потому что это управляемый канал.
Флаг O указывает, что хост может получать информацию, отличную от адреса, который он должен использовать через DHCPv6. Например, DNS-сервер, который хост должен использовать для разрешения имен DNS, должен быть получен с помощью DHCPv6.
Если установлен флаг O, а не флаг M, A должен определить свой собственный IPv6-адрес интерфейса. Для этого он определяет набор префиксов IPv6, используемых в этом сегменте, исследуя поле информации о префиксе в объявлении маршрутизатора. Он выбирает один из этих префиксов и формирует IPv6-адрес, используя тот же процесс, который он использовал для формирования link local address: он добавляет локальный MAC-адрес (EUI-48 или EUI-64) к указанному префиксу. Этот процесс называется SLAAC.
Теперь хост должен убедиться, что он не выбрал адрес, который использует другой хост в той же сети; он должен выполнять DAD. Чтобы выполнить обнаружение повторяющегося адреса:
Хост отправляет серию сообщений запроса соседей, используя только что сформированный IPv6-адрес и запрашивая соответствующий MAC-адрес (физический). Это сообщения ICMPv6 типа 135, передаваемые с link local address, уже назначенного интерфейсу.
Если хост получает объявление соседа или запрос соседа с использованием того же адреса IPv6, он предполагает, что локально сформированный адрес является дубликатом; в этом случае он сформирует новый адрес, используя другой локальный MAC-адрес, и попытается снова.
Если хост не получает ни ответа, ни запроса соседа другого хоста, использующего тот же адрес, он предполагает, что адрес уникален, и назначает вновь сформированный адрес интерфейсу.
Устранение ложных срабатываний при обнаружении повторяющегося адреса
Процесс DAD, описанный здесь, может привести к ложным срабатываниям. В частности, если какое-то другое устройство на канале связи передает исходные пакеты запроса соседа обратно к A, оно будет считать, что это от другого хоста, требующего тот же адрес, и, следовательно, объявит дубликат и попытается сформировать новый адрес. Если устройство постоянно повторяет все запросы соседей, отправленные A, A никогда не сможет сформировать адрес с помощью SLAAC.
Чтобы решить эту проблему, RFC7527 описывает усовершенствованный процесс DAD. В этом процессе A будет вычислять одноразовый номер, или, скорее, случайно выбранную серию чисел, и включать ее в запрос соседей, используемый для проверки дублирования адреса. Этот одноразовый номер включен через расширения Secure Neighbor Discovery (SEND) для IPv6, описанные в RFC3971.
Если A получает запрос соседа с тем же значением nonce, который он использовал для отправки запроса соседа вовремя DAD, он сформирует новый одноразовый номер и попытается снова. Если это произойдет во второй раз, хост будет считать, что пакеты зацикливаются, и проигнорирует любые дальнейшие запросы соседей с собственным одноразовым номером в них. Если полученные запросы соседей имеют одноразовый номер, отличный от того, который выбрал локальный хост, хост будет предполагать, что на самом деле существует другой хост, который выбрал тот же адрес IPv6, и затем сформирует новый адрес IPv6.
Как только у него есть адрес для передачи данных, A теперь требуется еще одна часть информации перед отправкой информации другому хосту в том же сегменте - MAC-адрес принимающего хоста. Если A, например, хочет отправить пакет в C, он начнет с отправки multicast сообщения запроса соседа на C с запросом его MAC-адреса; это сообщение ICMPv6 типа 135. Когда C получает это сообщение, он ответит с правильным MAC-адресом для отправки трафика для запрошенного IPv6-адреса; это сообщение ICMPv6 типа 136.
В то время как предыдущий процесс описывает объявления маршрутизатора, отправляемые в ответ на запрос маршрутизатора, каждый маршрутизатор будет периодически отправлять объявления маршрутизатора на каждом подключенном интерфейсе. Объявление маршрутизатора содержит поле lifetime, указывающее, как долго действует объявление маршрутизатора.
А теперь почитайте о проблемах шлюза по умолчанию. У нас получился отличным материал на эту тему.
Седьмая часть тут.
Поля фиксированной длины - самый простой из описанных в словаре механизмов. Протокол определяет набор полей, какие данные содержит каждое поле и насколько велико каждое поле. Эта информация «встроена» в определение протокола, поэтому каждая реализация построена в соответствии с этими же спецификациями и, следовательно, может взаимодействовать друг с другом. Рисунок 1 иллюстрирует кодирование поля фиксированной длины, используемое в протоколе Open Shortest Path First (OSPF), взятом из RFC2328.
Ряд чисел в верхней части рисунка 1 указывает отдельные биты в формате пакета; каждая строка содержит 32 бита информации. Первые 8 битов указывают номер версии, вторые 8 битов всегда имеют номер 5, следующие 16 битов содержат общую длину пакета и так далее Каждое из этих полей дополнительно определяется в спецификации протокола с видом информации, переносимой в поле и как оно закодировано. Например:
Поле номера версии кодируется как целое число без знака. Это метаданные, указывающие словарь и грамматику, используемые для этого пакета. Если формат пакета необходимо изменить, номер версии может быть увеличен, что позволяет передатчикам и получателям использовать правильный словарь и грамматику при кодировании и декодировании информации в пакете
Число 5 указывает тип пакета в протоколе; это часть словаря, определенного в другом месте в документе стандартов, поэтому он просто вставляется как фиксированное значение на этом рисунке. Этот конкретный пакет является пакетом подтверждения состояния канала (Link State Acknowledgment Packet).
Длина пакета кодируется как целое число без знака, указывающее количество октетов (или наборов из 8 битов), содержащихся в полном пакете. Это позволяет размеру пакета варьироваться по длине в зависимости от объема передаваемой информации.
Формат поля фиксированной длины имеет несколько преимуществ. Прежде всего, местоположение любого фрагмента информации в пакете будет одинаковым для каждого пакета, что означает, что легко оптимизировать код, предназначенный для кодирования и декодирования информации вокруг формата пакета. Например, обычным способом обработки формата пакета фиксированной длины является создание структуры данных в памяти, точно соответствующей формату пакета; когда пакет считывается с провода, он просто копируется в эту структуру данных. Поля в пакете могут быть прочитаны напрямую.
Форматы фиксированной длины имеют тенденцию быть несколько компактными. Метаданные, необходимые для кодирования и декодирования данных, передаются «вне протокола» в форме спецификации протокола. Сами пакеты содержат только значение и никогда не содержат никакой информации о значениях. С другой стороны, форматы фиксированной длины могут тратить много места на буферизацию полей, чтобы они всегда были одинаковой длины. Например, десятичное число 1 может быть представлено одной двоичной цифрой (один бит), тогда как десятичное число 4 требует 3 двоичных цифры (три бита); если поле фиксированной длины должно быть в состоянии представить любое число от 0 до 4, оно должно быть длиной не менее 3 битов, даже если два из этих битов иногда «теряются» при представлении меньших десятичных чисел.
Форматы фиксированной длины также часто занимают место, выравнивая размеры полей по общим границам памяти процессора, чтобы повысить скорость обработки. Поле, которое должно принимать значения от 0 до 3, даже если для представления полного набора значений требуется только два бита, может быть закодировано как 8-битовое поле (полный октет), чтобы обеспечить всегда выравнивание следующего поля на границе октета для более быстрой обработки в памяти.
Гибкость - то, где кодирование фиксированной длины часто сталкивается с проблемами. Если какое-либо поле определено как 8-битное значение (один октет) в исходной спецификации, нет очевидного способа изменить длину поля для поддержки новых требований. Основной способ решения этой проблемы в схемах кодирования с фиксированной длиной - через номер версии. Если длина поля должна быть изменена, номер версии изменяется в форматах пакетов, поддерживающих новую длину поля. Это позволяет реализациям использовать старый формат, пока все устройства в сети не будут обновлены для поддержки нового формата; после того как все они обновлены, вся система может быть переключена на новый формат, будь то больше или меньше.