По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В статье рассматриваются примеры протоколов, обеспечивающих Interlayer Discovery и назначение адресов. Первую часть статьи про Interlayer Discovery можно прочитать тут. Domain Name System DNS сопоставляет между собой человекочитаемые символьные строки, такие как имя service1. exemple, используемый на рисунке 1, для IP-адресов. На рисунке 3 показана основная работа системы DNS. На рисунке 3, предполагая, что нет никаких кэшей любого вида (таким образом, весь процесс проиллюстрирован): Хост A пытается подключиться к www.service1.example. Операционная система хоста проверяет свою локальную конфигурацию на предмет адреса DNS-сервера, который она должна запросить, чтобы определить, где расположена эта служба, и находит адрес рекурсивного сервера. Приложение DNS операционной системы хоста отправляет DNS-запрос на этот адрес. Рекурсивный сервер получает этот запрос и - при отсутствии кешей - проверяет доменное имя, для которого запрашивается адрес. Рекурсивный сервер отмечает, что правая часть имени домена именуется example, поэтому он спрашивает корневой сервер, где найти информацию о домене example. Корневой сервер возвращает адрес сервера, содержащий информацию о домене верхнего уровня (TLD) example. Рекурсивный сервер теперь запрашивает информацию о том, с каким сервером следует связаться по поводу service1.example. Рекурсивный сервер проходит через доменное имя по одному разделу за раз, используя информацию, обнаруженную в разделе имени справа, чтобы определить, какой сервер следует запросить об информации слева. Этот процесс называется рекурсией через доменное имя; следовательно, сервер называется рекурсивным сервером. Сервер TLD возвращает адрес полномочного сервера для service1.example. Если информация о местонахождении службы была кэширована из предыдущего запроса, она возвращается как неавторизованный ответ; если фактический сервер настроен для хранения информации об ответах домена, его ответ является авторитетным. Рекурсивный сервер запрашивает информацию о www.service1.example у полномочного сервера. Авторитетный сервер отвечает IP-адресом сервера B. Рекурсивный сервер теперь отвечает хосту A, сообщая правильную информацию для доступа к запрошенной службе. Хост A связывается с сервером, на котором работает www.service1.example, по IP-адресу 2001:db8:3e8:100::1. Этот процесс может показаться очень затяжным; например, почему бы просто не сохранить всю информацию на корневом сервере, чтобы сократить количество шагов? Однако это нарушит основную идею DNS, которая заключается в том, чтобы держать информацию о каждом домене под контролем владельца домена в максимально возможной степени. Кроме того, это сделало бы создание и обслуживание корневых серверов очень дорогими, поскольку они должны были бы иметь возможность хранить миллионы записей и отвечать на сотни миллионов запросов информации DNS каждый день. Разделение информации позволяет каждому владельцу контролировать свои данные и позволяет масштабировать систему DNS. Обычно информация, возвращаемая в процессе запроса DNS, кэшируется каждым сервером на этом пути, поэтому сопоставление не нужно запрашивать каждый раз, когда хосту необходимо достичь нового сервера. Как обслуживаются эти таблицы DNS? Обычно это ручная работа владельцев доменов и доменов верхнего уровня, а также пограничных провайдеров по всему миру. DNS не определяет автоматически имя каждого объекта, подключенного к сети, и адрес каждого из них. DNS объединяет базу данных, обслуживаемую вручную, с распределением работы между людьми, с протоколом, используемым для запроса базы данных; следовательно, DNS попадает в базу данных сопоставления с классом протоколов решений. Как хост узнает, какой DNS-сервер запрашивать? Эта информация либо настраивается вручную, либо изучается с помощью протокола обнаружения, такого как IPv6 ND или DHCP. DHCP Когда хост (или какое-либо другое устройство) впервые подключается к сети, как он узнает, какой IPv6-адрес (или набор IPv6-адресов) назначить локальному интерфейсу? Одним из решений этой проблемы является отправка хостом запроса в какую-либо базу данных, чтобы определить, какие адреса он должен использовать, например DHCPv6. Чтобы понять DHCPv6, важно начать с концепции link local address в IPv6. При обсуждении размера адресного пространства IPv6, fe80:: / 10 был назван зарезервированным для link local address. Чтобы сформировать link local address, устройство с IPv6 объединяет префикс fe80:: с MAC (или физическим) адресом, который часто форматируется как адрес EUI-48, а иногда как адрес EUI-64. Например: Устройство имеет интерфейс с адресом EUI-48 01-23-45-67-89-ab. Этот интерфейс подключен к сети IPv6. Устройство может назначить fe80 :: 123: 4567: 89ab в качестве link local address и использовать этот адрес для связи с другими устройствами только в этом сегменте. Это пример вычисления одного идентификатора из другого. После того, как link local address сформирован, DHCP6 является одним из методов, который можно использовать для получения уникального адреса в сети (или глобально, в зависимости от конфигурации сети). DHCPv6 использует User Datagram Protocol (UDP) на транспортном уровне. Рисунок 4 иллюстрирует это. Хост, который только что подключился к сети, A, отправляет сообщение с запросом. Это сообщение поступает с link local address и отправляется на multicast address ff02 :: 1: 2, порты UDP 547 (для сервера) и 546 (для клиента), поэтому каждое устройство, подключенное к одному и тому же физическому проводу, получит сообщение. Это сообщение будет включать уникальный идентификатор DHCP (DUID), который формирует клиент и использует сервер, чтобы обеспечить постоянную связь с одним и тем же устройством. B и C, оба из которых настроены для работы в качестве серверов DHCPv6, отвечают рекламным сообщением. Это сообщение является одноадресным пакетом, направленным самому A с использованием link local address, из которого A отправляет запрашиваемое сообщение. Хост A выбирает один из двух серверов, с которого запрашивать адрес. Хост отправляет запрос на multicast address ff02 :: 1: 2, прося B предоставить ему адрес (или пул адресов), информацию о том, какой DNS-сервер использовать, и т. д. Сервер, работающий на B, затем отвечает ответом на изначально сформированный link local address A; это подтверждает, что B выделил ресурсы из своего локального пула, и позволяет A начать их использование. Что произойдет, если ни одно устройство в сегменте не настроено как сервер DHCPv6? Например, на рисунке 4, что, если D - единственный доступный сервер DHCPv6, потому что DHCPv6 не работает на B или C? В этом случае маршрутизатор (или даже какой-либо другой хост или устройство) может действовать как ретранслятор DHCPv6. Пакеты DHCPv6, которые передает A, будут приняты ретранслятором, инкапсулированы и переданы на сервер DHCPv6 для обработки. Примечание. Описанный здесь процесс называется DHCP с отслеживанием состояния и обычно запускается, когда в объявлении маршрутизатора установлен бит Managed. DHCPv6 может также работать с SLAAC, для предоставления информации, которую SLAAC не предоставляет в режиме DHCPv6 без сохранения состояния. Этот режим обычно используется, когда в объявлении маршрутизатора установлен бит Other. В тех случаях, когда сетевой администратор знает, что все адреса IPv6 будут настроены через DHCPv6, и только один сервер DHCPv6 будет доступен в каждом сегменте, сообщения с объявлением и запросом можно пропустить, включив быстрое принятие DHCPv6. А теперь почитайте про Address Resolution Protocol - протокол разрешения IPv4-адресов
img
Также, как и системы электронной почты, системы VoIP телефонии есть практически у каждой компании. Это могут быть простые облачные АТС, арендуемые у провайдера или собственные выделенные под IP-АТС серверные мощности, но среда, по которой передаётся сигнализация и пользовательский трафик данных систем один – Интернет. Это делает систему VoIP телефонии одной из самых востребованных злоумышленниками целей, ведь получив к ней доступ, открывается масса возможностей для извлечения прибыли или нанесения другого ущерба. Если Вы банально откроете логи своего межсетевого экрана и поищите запросы, поступающие извне, то наверняка увидите, что тысячи сканеров каждую секунду пробуют узнать какие сервисы работают на вашем внешнем адресе. И даже если этот адрес никак не связан с IP-телефонией, то вы всё равно там увидите запросы, связанные с VoIP. Это говорит о том, что злоумышленники очень хотят найти уязвимые системы телефонии и знают как проэксплуатировать выявленную брешь. В этой статье разберём какой профит получают хакеры, взломавшие VoIP систему, основные методы атак и протоколы, на которые они направлены. Чего хотят плохие парни? Как только Ваша систему IP-телефонии будет зарегистрирована в сети VoIP провайдера – вы сможете позвонить в любой уголок мира - на мобильный телефон в Тайване, на такософон в одной из красных будок Лондона и даже на декадно-шаговую АТС в музее Франкфурта-на-Майне! Что сделает злоумышленник, получивший такую возможность? – Воспользуется ею за Ваш счёт! В большинстве плачевно известных случаев, получая доступ к системе по средствам какой-либо уязвимости, злоумышленники делают следующее: совершают дорогостоящие звонки на дальние расстояния (long-distance calls); перепродают возможность звонка третьим лицам, не подозревающим, что услуга предоставляется на украденных мощностях звонят на номера с премиум обслуживанием, зарабатывая кэшбэк на свой счёт Существует провайдеры телефонных номеров с премиум обслуживанием (international premium rate number - IPRN). Это такие номера, звонки на которые, происходят очень часто и со всего мира. Например, номера для технической поддержки, прогноза погоды, сервисы для взрослых. Провайдеры таких номеров платят часть прибыли тому, кто гонит на них трафик - генератору звонков (call generator). В некоторых случаях провайдер осознанно участвует в мошеннической схеме, а иногда и вовсе не подозревает, что платит кэшбэк злоумышленникам за трафик, сгенерированный на "угнанных" мощностях. В конечном итоге и провайдеры и call generator'ы остаются в выигрыше, а платить приходится тому кого взломали. Всё вышеописанное подпадает под одно определение, которому в английской литературе дали название - toll fraud. На русский язык это можно перевести как неправомочные действия и несанкционированное пользование чужими ресурсами телефонной связи. Злоумышленникам также может быть интересно вывести вашу систему телефонии из строя, устроив атаку типа DoS (Denial of service) - отказ в обслуживании, хотя это случается реже toll fraud'а. Нам известны случаи, когда целый ботнет из серверов FreePBX начинал забрасывать IP-АТС заказчика "мусорными" вызовами, в результате чего на какое-то время, пользоваться системой стало просто невозможно. Техническая реализация Согласно исследованию IBM наиболее атакуемыми VoIP протоколами являются SIP, SCCP и H.255. Самым распространённым VoIP протоколом на сегодняшний день является SIP, поэтому и большинство атак осуществляется именно на этот протокол. Всё начинается с поиска сервера для проведения атаки. Протокол SIP использует стандартный порт 5060, поэтому первое, что сделает потенциальный злоумышленник – это отправит SIP-запрос на данный порт, чтобы посмотреть какой придет ответ. Как правило, для поиска SIP-сервиса используются стандартные запросы INVITE, REGISTER или OPTIONS. Хорошей практикой является перенос SIP-сервиса со стандартного порта на какой-нибудь другой. Таким образом мы можем увести сервис из-под удара. Ещё лучше – ограничить доступ к этому порту только для доверенного списка IP-адресов. Однако, иногда такой возможности просто нет. Для изначального установления соединения в SIP используется метод “тройного рукопожатия” , начинающийся с запроса INVITE, который подтверждается ответом 200 OK. Однако, если этот ответ от вызывающей стороны не получен, то соединение не устанавливается. Если наблюдается много таких незаконченных соединений за коротких промежуток времени, то это может быть признаком того, что против сервера идёт DoS-атака. Кстати, точно таким же образом, злоумышленник может провести атаку против легитимного устройства пользователя, чтобы сбросить его регистрацию на сервере и зарегистрироваться самому. Существует также метод “флуда” запросами REGISTER. Для этого злоумышленник должен знать параметры зарегистрированного устройства, регистрацию которого он хочет сбросить, подделать заголовок Contact в SIP пакете и отправить много (достаточно раз в 15 секунд) запросов REGISTER на сервер. Такой метод называется Registration-hijacking. Эти атаки возможны благодаря тому, что протокол SIP передает информацию в открытом виде, а значит атакующий может её собрать, модифицировать и воспроизвести. Помимо этого, в протоколе SIP не предусмотрено проверки целостности сообщений, поэтому атаки с модифицированной информацией и воспроизведенными пакетами не детектируются. Злоумышленникам совсем не обязательно перехватывать ваш трафик, чтобы вытащить запросы регистраций легитимных пользователей, потом модифицировать их и подсовывать обратно серверу. После обнаружения открытого SIP-порта, можно просто устроить перебор зарегистрированных внутренних номеров, например, от 10 до 9999. Ответ от сервера на запрос регистрации по такой схеме будет однозначно свидетельствовать о том, какие номера есть на IP-АТС, а каких там нет. Например, я могу отправить запрос на регистрацию с номера 2526 с неправильным паролем. Если на сервере зарегистрирован такой номер, то я получу ответ, что пароль неверен (Wrong Password), а если нет – то сообщение о том, что номер не найден (Not Found). Собрав список зарегистрированных номеров можно потом применить против них метод перебора паролей и получить доступ к внутреннему номеру легитимного пользователя. Другой неприятные метод атаки на VoIP позволяет прослушивать ваши телефонные разговоры. Для этого необходимо перехватить сигнальную информацию и соответствующие медиа потоки определенного соединения. Медиа потоки, которые как раз и содержат пакеты с голосом, обычно передаются по UDP с использованием протокола RTP. Захватив достаточное количество пакетов, можно декодировать RTP поток, а затем сделать из них простой аудио файл, который и будет содержать голос. Сделать это можно с помощью программы Wireshark. Мы рассказали про базовые методы проведения атак на VoIP системы. В следующих статьях, мы обязательно расскажем как защититься от каждого типа атаки, как выявить признаки атак и какие инструменты можно для этого использовать.
img
В предыдущей статье мы рассмотрели необходимость перераспределения маршрутов, а также рассмотрели некоторые примеры конфигурации. Эта статья основана на предыдущей конфигурации и рассматривает возможность фильтрации маршрутов с помощью карт маршрутов. В частности, в предыдущем примере показано взаимное перераспределение маршрутов между EIGRP и OSPF, где все маршруты были перераспределены между двумя автономными системами. Однако некоторые сценарии проектирования могут потребовать, чтобы мы предотвратили перераспределение каждого отдельного маршрута. Один из способов сделать эту фильтрацию - использовать карту маршрутов. Для справки, вот топология, с которой мы работаем: Кроме того, с нашей текущей конфигурацией перераспределения маршрутов таблица IP-маршрутизации на роутере OFF1 выглядит следующим образом: Скажем, по какой-то причине мы не хотим, чтобы сеть 192.168.2.0 /24 была перераспределена из EIGRP в OSPF. Один из способов сделать эту фильтрацию - использовать карту маршрутов, которая ссылается на список управления доступом (ACL). Во-первых, давайте перейдем к роутеру CENTR и создадим ACL, который соответствует сети, которую мы хотим отфильтровать. CENTR # conf term Enter configuration commands, one per line. End with CNTL/Z. CENTR (config) access-list 1 permit 192.168.2.0 0.0.0.255 Обратите внимание на использование ключевого слова permit в ACL. В этом контексте слово permit одно из ключевых среди match, notallow. Далее мы будем ссылаться на этот ACL в карте маршрутов, и это карта маршрутов, расскажет, что мы хотим запретить этой сети быть перераспределенной. Вот как мы можем создать эту карту маршрута: CENTR (config)# route-map LAB deny 10 CENTR (config-route-map) # match ip address 1 CENTR (config-route-map) #exit CENTR (config)# route-map LAB permit 20 CENTR (config-route-map) exit CENTR (config)# Обратите внимание, что у нас есть два оператора route-map с порядковыми номерами 10 и 20. Как и в ACL, route-map обрабатываются сверху вниз. В этом примере мы хотим запретить сеть 192.168.2.0 / 24 с порядковым номером 10. Затем, чтобы разрешить перераспределение всего остального трафика, мы создаем инструкцию route-map с порядковым номером 20. Обратите внимание, что в отличие от предыдущего оператора route-map (который содержал ключевое слово deny), этот оператор route-map содержит ключевое слово permit. В результате, без необходимости указывать условие соответствия, мы сопоставляем (и разрешаем) все остальные маршруты. Далее, давайте применим нашу карту маршрута к команде redistribute в нашем процессе маршрутизации OSPF на роутере CENTR. В настоящее время команда redistribute для процесса маршрутизации OSPF выглядит следующим образом: edistribute eigrp 1 metric-type 1 subnets То, что мы хотим сделать - это переписать эту команду, добавив ссылку на нашу недавно созданную карту маршрутов. CENTR (config)# router ospf 1 CENTR (config-router)# redistribute eigrp 1 metric-type 1 subnets route-map LAB CENTR (config-router)#end CENTR# Теперь давайте вернемся к роутеру OFF1 и посмотрим, исчезла ли сеть 192.168.2.0/24 из таблицы IP-маршрутизации. Все отлично! Маршрут 192.168.2.0/24 был успешно отфильтрован. В следующей статье мы рассмотрим, как можно устранить неполадки с перераспределением маршрутов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59