По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда синхронизация менее важна, чем фактическая доставка, трафиком часто можно управлять с помощью метода взвешенной справедливой организации очереди на основе классов (CBWFQ). В CBWFQ участвующие классы трафика обслуживаются в соответствии с назначенной им политикой. Например, трафику, помеченному как AF41, может быть гарантирована минимальная пропускная способность. Для трафика, помеченного как AF21, также может быть гарантирована минимальная пропускная способность, возможно, меньшая, чем объем, предоставленный трафику AF41. Немаркированный трафик может получить любую оставшуюся полосу пропускания.
CBWFQ имеет понятие справедливости, когда различные классы трафика могут доставляться по перегруженному каналу. CBWFQ обеспечивает справедливое обслуживание пакетов в очереди в соответствии с политикой QoS. Пакеты будут отправляться всем классам трафика с назначенной им полосой пропускания.
Например, предположим, что пропускная способность канала составляет 1024 Кбит / с. Для класса трафика AF41 гарантирован минимум 256 Кбит / с. Для класса AF31 гарантирована скорость минимум 128 Кбит / с. Для класса AF21 гарантирована скорость минимум 128 Кбит / с. Это дает нам соотношение 2: 1: 1 между этими тремя классами. Остальные 512 Кбит / с не распределены, то есть доступны для использования другим трафиком. Включая нераспределенную сумму, полное соотношение составляет 256: 128: 128: 512, что сокращается до 2: 1: 1: 4.
Чтобы решить, какой пакет будет отправлен следующим, очередь обслуживается в соответствии с политикой CBWFQ. В этом примере пропускная способность 1024 Кбит / с делится на четыре части с соотношением 2: 1: 1: 4. Для простоты предположим, что перегруженный интерфейс будет обслуживать пакеты в очереди за восемь тактов:
Тактовый цикл 1. Будет отправлен пакет AF41.
Тактовый цикл 2. Будет отправлен еще один пакет AF41.
Тактовый цикл 3. Будет отправлен пакет AF31.
Тактовый цикл 4. Будет отправлен пакет AF21.
Тактовые циклы 5-8. Пакеты с другими классификациями, а также неклассифицированные пакеты будут отправлены.
В этом примере предполагается, что есть пакеты, представляющие каждый из четырех классов, находящихся в буфере, поставленных в очередь для отправки. Однако не всегда все бывает так однозначно. Что происходит, когда нет пакетов из определенного класса трафика для отправки, даже если есть место в гарантированном выделении минимальной полосы пропускания?
Гарантированная минимальная пропускная способность не является резервированием. Если класс трафика, которому назначен гарантированный минимум, не требует полного распределения, другие классы трафика могут использовать полосу пропускания. Также нет жестких ограничений гарантированного минимума пропускной способности. Если объем трафика для определенного класса превышает гарантированный минимум и полоса пропускания доступна, трафик для класса будет проходить с большей скоростью. Таким образом, происходящее могло бы выглядеть примерно так:
Тактовый цикл 1. Отправляется пакет AF41.
Тактовый цикл 2. Нет пакета AF41 для отправки, поэтому вместо него отправляется пакет AF31.
Тактовый цикл 3. Отправлен еще один пакет AF31.
Тактовый цикл 4. Нет пакета AF21 для отправки, поэтому отправляется неклассифицированный пакет.
Тактовые циклы 5-7. Отправляются пакеты с другими классификациями, а также неклассифицированные пакеты.
Тактовый цикл 8. Нет более классифицированных или неклассифицированных пакетов для отправки, поэтому отправляется еще один пакет AF31.
В результате неиспользованная полоса пропускания делится между классами с избыточным трафиком.
Перегрузка
CBWFQ не увеличивает пропускную способность перегруженного канала. Скорее, алгоритм предусматривает тщательно контролируемое совместное использование перенапряженного канала, отражающее относительную важность различных классов трафика. В результате совместного использования CBWFQ трафик доставляется через перегруженный канал, но с меньшей скоростью по сравнению с тем же каналом в незагруженное время.
Невозможно переоценить различие между "совместным использованием перегруженного канала" и "созданием полосы пропускания из ничего". Распространенное заблуждение о QoS заключается в том, что, несмотря на точки перегрузки на сетевом пути, взаимодействие с пользователем останется идентичным. Это совсем не так. Инструменты QoS, такие как CBWFQ, по большей части предназначены для того, чтобы максимально использовать плохую ситуацию. При выборе того, когда и когда пересылать трафик, QoS также выбирает, какой трафик отбрасывать. Среди потоков, передаваемых по сети, есть "победители" и "проигравшие".
LLQ является заметным исключением, поскольку предполагается, что трафик, обслуживаемый LLQ, настолько критичен, что он будет обслуживаться, исключая другой трафик, вплоть до назначенного ограничения полосы пропускания. LLQ стремится сохранить пользовательский опыт.
Другие инструменты управления перегрузкой QoS
Формирование трафика - это способ изящно ограничить классы трафика определенной скоростью. Например, трафик, помеченный как AF21, может иметь скорость 512 Кбит / с. Формирование изящное. Он допускает номинальные всплески выше определенного предела перед отбрасыванием пакетов. Это позволяет TCP более легко настраиваться на требуемую скорость. Когда пропускная способность сформированного класса трафика отображается на графике, результат показывает нарастание до предельной скорости, а затем постоянную скорость передачи на протяжении всего потока. Формирование трафика чаще всего применяется к классам трафика, заполненным слоновьими потоками.
Слоновидные потоки - это долговечные потоки трафика, используемые для максимально быстрого перемещения больших объемов данных между двумя конечными точками. Слоновые потоки могут заполнять узкие места в сети собственным трафиком, подавляя меньшие потоки. Распространенная стратегия QoS состоит в том, чтобы формировать скорость трафика слоновьих потоков, чтобы в узком месте оставалась достаточная пропускная способность для эффективного обслуживания других классов трафика.
Применение политик аналогично формированию трафика, но более жестко обращается с избыточным (несоответствующим) трафиком. Вместо того, чтобы допускать небольшой всплеск выше определенного предела пропускной способности, как при формировании перед сбросом, применение политик немедленно отбрасывает избыточный трафик. При столкновении с ограничителем трафика затронутый трафик увеличивается до предела пропускной способности, превышает его и отбрасывается. Такое поведение отбрасывания заставляет TCP заново запускать процесс наращивания мощности. Полученный график выглядит как пилообразный. Применение политик может использоваться для выполнения других задач, таких как перемаркировка несоответствующего трафика на значение DSCP с более низким приоритетом, а не отбрасывание.
Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно.
В данной статье, подробно разберём один из способов атак на системы, работающие по протоколу SIP, через генерацию вредоносного пакета и последующую компрометацию учётной записи.
Вы убедитесь, что провести подобную атаку - совсем не сложно. Инструменты для её осуществления не являются какой-то сверхсекретной разработкой и находятся в свободном доступе.
Цель данной статьи - показать, к чему может привести недостаточное внимание, уделённое вопросам безопасности при настройке систем IP-телефонии и как просто это могут использовать злоумышленники.
Внимание! Информация, представленная в данной статье, носит исключительно ознакомительный характер. Компания Мерион Нетворкс не несёт ответственности за последствия применения техник и способов, описанных в данном материале. Напоминаем, что неправомерный доступ к компьютерной информации преследуется по закону и влечет за собой уголовную ответственность.
Атака, о которой мы поговорим, связана с процессом аутентификации по протоколу SIP, а именно - с получением информации из заголовков SIP пакета и её последующая обработка для извлечения учётных данных. Чтобы понять её суть и определить, какие системы уязвимы к данной атаке, нужно вспомнить как происходит SIP аутентификация.
Как показано на рисунке:
Клиент отправляет запрос регистрации на сервер;
Сервер сообщает о необходимости зарегистрироваться и запрашивает данные для аутентификации;
Клиент повторно отправляет запрос регистрации, но на этот раз со строкой Authorization, в которой указаны учётные данные;
Сервер проверяет учётные данные в локальной базе и если есть совпадения – разрешает регистрацию.
В стандартном процессе SIP аутентификации все запросы клиентов и ответы от сервера идут в строгой последовательности. Пользователь просто вводит учётные данные и клиент сам формирует пакеты для отправки на сервер, которые он может обработать. Если учётные данные не верны, то сервер не разрешит регистрацию и дальнейшее взаимодействие для осуществления звонков.
Однако, злоумышленник, используя специальные инструменты, может сам решать какие отправлять пакеты и более того - осуществлять их формирование.
Наверное, Вы догадались, что ключевым моментом процесса SIP аутентификации является отправка клиентом повторного запроса REGISTER, который также содержит учётные данные для регистрации на сервере. Как раз в этот момент, наш потенциальный злоумышленник и нанесёт свой удар.
Давайте рассмотрим, что из себя представляет строка Authorization в повторном запросе REGISTER.
Как видно на рисунке, заголовок Authorization включает в себя следующие поля:
Authentication Scheme - метод аутентификации;
Поскольку SIP многое унаследовал от протокола HTTP, то и схема аутентификации в нём основана на HTTP аутентификации, которая также называется Дайджест (Digest) аутентификация. Эта схема применяется серверами для обработки учётных данных от клиентов. При этом, часть учётных данных передаётся в виде хэш-сумм, которые сервер комбинирует с открытыми данными и вычисляет пароль для данного клиента. Это значительно повышает уровень безопасности, но как мы убедимся в дальнейшем – не помогает при некорректной настройке учётной записи.
Username - имя пользователя, заданное на сервере. В нашем случае – это внутренний номер 3354;
Realm - параметр, определяющий подключение к серверу телефонии;
Как правило, администратор VoIP сервера сам настраивает realm и транслирует его пользователю, который хочет осуществить подключение. Например, у провайдеров облачных услуг это может быть строка вида domain.com, в сервере Asterisk, по-умолчанию значение этой строки - asterisk.
Nonce Value - рандомно сгенерированная сервером, уникальная строка, при формировании ответа 401 в сторону клиента. В дальнейшем используется сервером в вычислениях после получения учетных данных от клиента, должна совпадать с тем, что пришло от сервера;
Authentication URI - унифицированный идентификатор ресурса. В нашем случае, ресурсом является сервер, расположенный по адресу 123.45.67.89, обращение к нему происходит по протоколу SIP, по порту 5060.
Digest Authentication Response - ответ от клиента, посчитанный на основании данных, полученных от сервера. На основании этого значения сервер в том числе сверяет пароль, который задан клиенту.
Согласно RFC 2069, который описывает HTTP дайджест аутентификацию, response вычисляется следующим образом:
HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)
Как видите, на основании MD5 хэш-сумм полей: username, realm, password (да, это пароль клиента), method, digestURI и nonce высчитывается тот самый заветный response, от которого зависит регистрация клиента на сервере, а следовательно, и возможность осуществлять им вызовы.
Algorithm - алгоритм, по которому высчитывался response
Догадываетесь о чём идёт речь? О том, что если злоумышленник заполучит полную строку Authorization, то он может вычислить пароль клиента, зарегистрироваться на сервере и спокойно звонить куда ему вздумается.
Пространство для данной атаки достаточно обширное. Дело в том, что клиент может передавать строку авторизации в нескольких запросах – в уже известном нам REGISTER, INVITE или BYE.
Атакующему не составит труда притвориться “сервером” и затребовать от клиента аутентификации. Для этого, атакующий направит в сторону клиента, созданный с помощью специальной программы вредоносный SIP пакет с ответом 401 Unauthorized, который будет содержать строку, заставляющую клиента отправить учётные данные. Данная строка должна содержать realm и nonce . Выглядит эта строка следующим образом:
Таким образом, атака может выглядеть следующим образом:
С точки зрения атакуемого, это будет выглядеть как простой звонок, на другой стороне трубки которого будет тишина. Он даже не будет подозревать о том, что его учётные данные вот-вот утекут к злоумышленнику. Атакующий в нужный момент разорвёт соединение, отправив BYE и затем сформированный вредоносный пакет.
Нагляднее всего приводить в пример прямое взаимодействие между клиентами. Такой сценарий становится, когда есть возможность отправлять SIP запросы напрямую до оконечного клиента. Например, когда телефон выставлен в открытую сеть по SIP порту. Помимо этого, уязвимости подвержены сервера, разрешающие прямое взаимодействия между оконечными клиентами. Лучше всего, пропускать все запросы через Proxy-сервер.
Итак, данной атаке могут быть подвержены:
IP-телефоны с открытыми в интернет SIP-портами;
IP-телефоны, отвечающие на запросы INVITE от неизвестных серверов;
IP-АТС, разрешающие запросы INVITE напрямую до клиентов.;
Заполучив полную строку Authorization атакующий может в оффлайн режиме подобрать пароль к учётной записи. Для этого ему нужно подать на вход специального скрипта, который перебирает хэш-суммы по словарям, перехваченные данные: username, realm, method, digestURI, nonce и наконец - response. На выходе он получит пароль от учётной записи. Если пароль слабый или, ещё хуже, совпадает с username, то время перебора не превысит 1 секунды.
Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.
Если вы когда-то пользовались какой-нибудь серверной версией Linux, то скорее всего сталкивались с командой curl. Эта мощная утилита системы Linux позволяет скачивать и загружать файлы на сервер и поддерживает более 20 протоколов.
Раньше мы писали про первые 15 примеров cURL в Linux. Статья зашла - это продолжение :)
cURL идеальная команда для взаимодействия с веб-сайтом или API, отправления запросов и получения ответов на терминал или с выводом в файл. Иногда она используется как часть сложного скрипта для передачи полученных данных другим функциям на дальнейшую обработку.
Наряду с получением файлов из сервера, cURL так же используется для закачки части вебсайта. Несмотря на то, что она довольно хорошо справляется с работой, но всё же wget лучше наточен под такую работу.
В конце материала мы рассмотрим несколько отличий и сходств этих двух утилит, но а пока расскажем как пользоваться утилитой curl.
Скачивание файла
Самая базовая команда, которую можно дать утилите cURL это скачать сайт или файл. По умолчанию, cURL использует протокол HTTP, но мы можем задать любой другой. Чтобы открыть исходный код сайта просто нужно ввести команду:
$ curl http://www.google.com
Когда мы вводим указанную команду, окно терминала заполняется HTML и другим кодом, используемым для создания веб страницы, но от такого вывода мало пользы. Изменим команду так, чтобы вывод перенаправлялся в HTML файл, чтобы затем можно было просмотреть содержимое.
$ curl www.likegeeks.com --output likegeeks.html
Теперь файл можно открыть любым браузером.
Если нужно скачать какой-то файл, то команда остается та же. Только нужно добавить опцию output, как мы и сделали ранее. Если не сделать команда вернёт бинарный код файла, что может привести к сбою.
Ниже показано что мы видим при попытке загрузить Word документ размером 500Кб.
Файл начинает закачиваться, и мы видим текущий статус закачки. Когда загрузка завершится файл будет расположен по пути, указанной во время запуска команды. Если такового не было указано, то файл будет расположен в текущей директории.
Также, вы, наверное, заметили ключ L в команде. При загрузке файла этот ключ необходим, но о его назначении поговорим чуть позже.
Отслеживание редиректа
Если после выполнения команды ничего не вернулось это значит, что на сайте есть редирект (переадресация) на другую ссылку, но cURL не понимает этого. Это можно исправить, указав ключ L при вводе команды.
Во время подготовки материала мы заметили, что данный ключ нужен в подавляющем большинстве случаев. Так что возьмите себе эту фишку на вооружение.
Остановка и продолжение скачивания
Если во время закачки файла что-то пошло не так или же качаете большой файл, но ввиду каких-то причин не хотите делать это за одну сессию, cURL предоставляет возможность остановки и продолжения закачки.
Чтобы остановить процесс вручную, нужно нажать комбинацию CTRL+C, которая используется для остановки почти всех процессов, запущенных в терминале.
Итак, загрузка была начата, но мы прервали её комбинацией клавиш, а теперь нам нужно продолжить закачку. Для этого вводим следующую команду.
$ curl -C - example.com/some-file.zip --output MyFile.zip
Ключ C говорит утилите cURL продолжить закачку, но обратите внимание, что сразу после ключа указан дефис. Этот дефис указывает команде перед продолжением просмотреть уже закачанную часть, чтобы понять с какого места нужно продолжать загрузку.
Закачка продолжилась и успешно завершилась.
Указание времени выполнения команды
Если нужно чтобы прервать выполнение команды cURL по истечении указанного времени, мы можем указать таймер выполнения команды. Это особо полезно так как некоторые операции выполняются бесконечно, что может привести к зависанию системы. Чтобы избежать этого можно указать максимальный период в секундах, по истечении которого cURL прервёт выполнение команды. Вышесказанное реализуется следующим образом:
$ curl -m 60 example.com
Также есть возможность указать в течении какого времени держать соединение активным. Это позволит избежать бесконечных попыток соединения с узлом, который не доступен. Эта опция тоже в качестве аргумента принимает значение в секундах. А команда выглядит так:
$ curl --connect-timeout 60 example.com
Указание логина и пароля
Утилита cURL позволяет указывать имя пользователя и пароль при подключении. Чаще всего это нужно при аутентификации на FTP сервере. Для этого используется ключ u. Синтаксис команды указан ниже:
$ curl -u username:password ftp://example.com
Данную опцию можно использовать с любым протоколом, но FTP является самым распространённым для простой передачи файлов.
Если нужно скачать файл указанный на скриншоте ниже запускаем ту же команду, только указываем полный путь к нужному документу.
$ curl -u username:password ftp://example.com/readme.txt
Использование прокси
cURL можно указать, чтобы подключение выполнялось через прокси сервер. По умолчанию, она использует HTTP прокси, но можно указать и другие. Чтобы направить трафик через прокси используется ключ x.
$ curl -x 192.168.1.1:8080 http://example.com
Данная команда обязует cURL подключиться к прокси по адресу 192.168.1.1 на порту 8080 перед обращением на example.com
Прокси можно использовать и с другими протоколами. Ниже показан пример использования прокси сервера для получения файла с фтп сервера.
$ curl -x 192.168.1.1:8080 ftp://example.com/readme.txt
cURL поддерживает много типов прокси и соответствующих ключей, но охватить их всех в одном руководстве сложно. Для более подробной информации о туннелировании, SOCKS прокси, аутентификации и т.п. можете прочитать man по команде cURL.
Загрузка больших файлов по частям
Мы уже показывали как можно остановить и запустить закачку, но что если мы хотим скачать файл большого размера по частям? cURL имеет и такую возможность. Чтобы реализовать это достаточно указать ключ -range и размер загружаемой части. Размер должен быть указан в байтах.
Чтобы скачать последнюю версию Ubuntu частями по 100 МБ нужно прописать следующую команду:
$ curl --range 0-99999999 http://releases.ubuntu.com/18.04/ubuntu-18.04.3-desktop-amd64.iso ubuntu-part1
Во вторая команде нужно указать с какого байта начинать загрузку. И так пока не скачается весь файл.
$ curl --range 100000000-199999999 http://releases.ubuntu.com/18.04/ubuntu-18.04.3-desktop-amd64.iso ubuntu-part2
Затем просто нужно собрать воедино скачанные части:
$ cat ubuntu-part? > ubuntu-18.04.3-desktop-amd64.iso
Аутентификация по сертификату
Для подключения к сайту использованием сертификата вместо обычной аутентификации можно указать опцию cert и путь к сертификату.
$ curl --cert path/to/cert.crt:password ftp://example.com
cURL поддерживает большое количество форматов сертификатов и имеет очень много опций для работы с ними: -cacert, cert-status, -cert-type, и т.д. Для списка всех ключей посмотрите man.
Тихий режим
Если вас раздражают разные сообщения об ошибках во время работы с cURL, то можно запустить её в тихом режиме. Для этого используется ключ s. Но, чтобы увидеть результат выполнения команды вывод нужно перенаправить в файл. Для сохранения файла в текущей директории просто нужно указать ключ O.
$ curl -s -O http://example.com
Как альтернатива, команду можно запустить с опцией --output и указать название и путь к месту сохранения файла.
$ curl -s http://example.com --output index.html
Получение заголовков
cURL позволяет легко получать заголовков какого-либо сайта. Для этого достаточно запустить команду с ключом I.
$ curl -I example.com
Если запустить команду с ключами I и L совместно, то cURL выведёт заголовки даже если на сайте стоит переадресация.
Множественные заголовки
Команде cURL можно передать и заголовки. Для этого есть ключ H. Для передачи нескольких заголовков перед каждым из них нужно поставить данный ключ.
$ curl -H 'Connection: keep-alive' -H 'Accept-Charset: utf-8 ' http://example.com
POST Закачка файла на сервер
POST самый распространённый метод получения данных на веб-сайтах. Например, когда заполняете форму на сайте, скорее всего данные из форм передаются серверу методом пост. Чтобы отправить сайту данные этим методом нужно использовать ключ d.
$ curl -d 'name=geek&location=usa' http://example.com
Чтобы загрузить файл вместо текста нужно ввести следующую команду
$ curl -d @filename http://example.com
Используйте ключ d столько раз, сколько данных или файлов нужно отправить на сайт.
Чтобы загрузить файл через протокол FTP используйте ключ T
$ curl -T myfile.txt ftp://example.com/some/directory/
Отправка почты
Отправка почты это один из видов загрузки данных на почтовый сервер. Так как cURL может загружать файлы, то мы можем использовать ее и для отправки почты. Есть много вариантов сделать это, но здесь мы рассмотрим, как посылать почты через SMTP сервер.
$ curl smtp://mail.example.com --mail-from me@example.com --mail-rcpt john@domain.com --upload-file email.txt
Учтите, что файл e-mail должен быть отформатирован нужным образом. Что-то вроде этого:
$ cat email.txt
From: Web Administrator <me@example.com>
To: John Doe <john@domain.com>
Subject: An example email
Date: Sat, 7 Dec 2019 02:10:15
John,
Hope you have a great weekend.
-Admin
Как всегда, за подробной информацией можете обратиться к man.
Чтение почты
Для получения почты используется IMAP и POP3 и сurl поддерживает оба протокола. Зайдем на почту используя протокол IMAP:
$ curl -u username:password imap://mail.example.com
Данная команда выведет список доступных почтовых ящиков, но не покажет их содержание. Чтобы прочитать письмо нужно указать UID письма аргументов для опции X.
$ curl -u username:password imap://mail.example.com -X 'UID FETCH 1234'
Разница между cURL и wget
Иногда пользователей путаются между curl и wget, так как обе они могут получать информацию с сервера. Но это единственное сходство между ними.
В этом материале мы показали возможности curl. wget дает другие возможности. wget лучшая утилита для скачивания файлов, а также у него есть возможность делать это рекурсивно, переходя по всем ссылкам и директория и скачать сайт полностью.
Таким образом, если вам нужно скачать все исходные файлы сайта используйте wget. Если же используется протокол отличный от HTTP или HTTPS, или нужно закачать файл на сервер, выберите curl. cURL удобен для скачивания одиночных файлов, хотя и wget неплохо справляется с данной задачей.