Как опрашивается DNS-сервер?
Обновлено: 03.07.2024
chrony и ntpd — это две разные реализации протокола сетевого времени (NTP).
chrony – это более новая реализация, разработанная для эффективной работы в более широком диапазоне условий. Обычно он может синхронизировать системные часы быстрее и с большей точностью времени. У него много функций, но он не реализует некоторые менее полезные режимы NTP, такие как широковещательный клиент или многоадресный сервер/клиент.
Если ваш компьютер подключен к Интернету только на несколько минут, сетевое соединение часто перегружено, вы часто выключите компьютер или приостановите его работу, часы не очень стабильны (например, есть быстрые изменения в температура или это виртуальная машина), или вы хотите использовать NTP в изолированной сети без аппаратных эталонных часов, вероятно, вам лучше подойдет chrony.
Для более подробного сравнения функций и производительности см. страницу сравнения на веб-сайте chrony.
2. Проблемы с конфигурацией
2.1. Какова минимальная рекомендуемая конфигурация для клиента NTP?
Во-первых, клиент должен знать, какие NTP-серверы он должен запрашивать для текущего времени. Они задаются директивой сервера или пула. Директива pool используется с именами, которые разрешаются в несколько адресов разных серверов. Для надежной работы у клиента должно быть не менее трех серверов.
Опция iburst включает пакет запросов для ускорения начальной синхронизации.
Чтобы стабилизировать первоначальную синхронизацию при следующем запуске, предполагаемый дрейф системных часов сохраняется в файле, указанном в директивеdriftfile.
Если системные часы могут быть далеки от истинного времени после загрузки по какой-либо причине, chronyd должен позволить быстро исправить это, пошагово, а не поворотно, что займет очень много времени. Это делает директива makestep.
Для того, чтобы часы реального времени (RTC) были близки к истинному времени, чтобы системное время было достаточно близко к истинному времени, когда оно инициализируется при следующей загрузке из RTC, директива rtcsync включает режим в котором системное время периодически копируется в RTC. Он поддерживается в Linux и macOS.
2.2. Как создать NTP-сервер?
По умолчанию chronyd не работает как сервер NTP. Вам нужно добавить директиву allow в файл chrony.conf, чтобы chronyd открывал NTP-порт сервера и отвечал на запросы клиентов.
Директива allow без указания подсети разрешает доступ со всех адресов IPv4 и IPv6.
2.3. Должны ли все компьютеры в локальной сети быть клиентами внешнего сервера?
Это зависит от требований. Обычно лучшая конфигурация — сделать один компьютер сервером, а остальные — его клиентами. Добавьте локальную директиву в файл chrony.conf сервера. Эта конфигурация будет лучше, потому что
нагрузка на внешнее подключение меньше
нагрузка на внешний NTP сервер(ы) меньше
если ваше внешнее соединение прервется, компьютеры в локальной сети будут поддерживать общее время друг с другом.
2.4. Должен ли я указывать серверы по IP-адресу, если DNS недоступен при запуске chronyd?
Нет, chronyd будет пытаться разрешить имена, указанные в директивах server , pool и peer, с увеличивающимся интервалом, пока не добьется успеха. Онлайн-команда может быть запущена из chronyc, чтобы заставить chronyd попытаться немедленно разрешить имена.
2.5. Как сделать хронид более безопасным?
Если вам не нужно использовать chronyc или вы хотите запускать chronyc только под пользователем root или chrony (который может получить доступ к chronyd через сокет домена Unix), вы можете отключить IPv4 и Командные сокеты IPv6 (по умолчанию прослушивание на локальном хосте), добавив cmdport 0 в файл конфигурации.
Вы можете указать непривилегированного пользователя с помощью параметра -u или директивы пользователя в файле chrony.conf, на которого chronyd переключится после запуска, чтобы отказаться от привилегий суперпользователя. Сценарий configure имеет параметр --with-user, который устанавливает пользователя по умолчанию. В Linux chronyd должен быть скомпилирован с поддержкой библиотеки libcap. В других системах chronyd разветвляется на два процесса. Дочерний процесс сохраняет привилегии root, но может выполнять только очень ограниченный набор привилегированных системных вызовов от имени родителя.
Кроме того, если chronyd скомпилирован с поддержкой средства безопасных вычислений Linux (seccomp), вы можете включить фильтр системных вызовов с помощью параметра -F. Это значительно уменьшит поверхность атаки ядра и, возможно, предотвратит эксплойты ядра из процесса chronyd, если он будет скомпрометирован. Рекомендуется включать фильтр только в том случае, если известно, что он работает с версией системы, на которой установлен chrony, так как фильтр должен также разрешать системные вызовы, сделанные из библиотек, которые использует chronyd (например, libc), а также различные версии или реализации библиотеки могут выполнять разные системные вызовы.Если в фильтре отсутствует какой-либо системный вызов, хронид может быть убит даже при нормальной работе.
2.6. Как сделать системные часы более безопасными?
Клиент NTP, синхронизирующий системные часы с сервером NTP, подвержен различным атакам, которые могут нарушить работу приложений и сетевых протоколов, зависящих от точности часов (например, DNSSEC, Kerberos, TLS, WireGuard).
Как правило, злоумышленник, использующий посредника (MITM) между клиентом и сервером, может
создавать поддельные ответы или изменять реальные ответы от сервера, чтобы создать произвольно большое смещение по времени и частоте, сделать сервер более точным, вставить дополнительную секунду и т. д.
задерживать запросы и/или ответы, чтобы создать ограниченное смещение по времени и временно также ограниченное смещение по частоте
удалить запросы или ответы, чтобы предотвратить обновление часов с новыми измерениями
перенаправлять запросы на другой сервер
Для большего эффекта атаки можно комбинировать. Злоумышленник может сначала задержать пакеты, чтобы создать значительный сдвиг частоты, а затем отбросить все последующие пакеты, чтобы часы быстро отклонились от истинного времени. Злоумышленник также может управлять часами сервера.
Некоторые атаки невозможно предотвратить. Мониторинг необходим для обнаружения, т.е. регистр доступности в отчете об источниках показывает отсутствующие пакеты. Степень, в которой злоумышленник может контролировать часы клиента, зависит от его конфигурации.
Включите аутентификацию, чтобы запретить chronyd принимать измененные, поддельные или перенаправленные пакеты. Его можно включить с помощью симметричного ключа, указанного в параметре key, или Network Time Security (NTS) в параметре nts (поддерживается, начиная с версии 4.0 chrony). Сервер должен поддерживать выбранный механизм аутентификации. Симметричные ключи должны быть настроены как на клиенте, так и на сервере, и у каждого клиента должен быть свой ключ (по одному на сервер).
Максимальное смещение, которое злоумышленник может добавить в измерение NTP, задерживая пакеты, может быть ограничено параметром maxdelay. Значение по умолчанию — 3 секунды. Измеренная задержка сообщается как задержка однорангового узла в отчете ntpdata и журнале измерений. Установите параметр maxdelay на значение больше, чем максимальное значение, которое обычно наблюдается. Обратите внимание, что задержка может значительно увеличиться, даже если вы не подвергаетесь атаке, т.е. когда сеть перегружена или маршрутизация изменилась.
Максимально допустимое изменение смещения времени между обновлениями часов может быть ограничено директивой maxchange. Большие изменения в смещении будут проигнорированы или вызовут выход из chronyd. Обратите внимание, что злоумышленник может обойти это ограничение, разделив смещение на несколько меньших смещений и/или создав большое смещение частоты. При использовании этой директивы chronyd придется перезапускать после успешной атаки. Самостоятельно восстановиться не получится. Он не должен перезапускаться автоматически (например, менеджером службы).
Влияние большого принятого смещения времени можно уменьшить, отключив тактовые шаги, то есть не используя директивы makestep и initstepslew. Смещение будет медленно корректироваться путем ускорения или замедления часов со скоростью, которая может быть ограничена директивой maxslewrate. Полное отключение шагов часов целесообразно только в том случае, если часы не могут получить большую ошибку сами по себе, например. когда компьютер выключен или приостановлен, а предел maxslewrate достаточно велик, чтобы исправить ожидаемую ошибку за приемлемое время. Директиву rtcfile с параметром -s можно использовать для компенсации дрейфа RTC.
Более практичный подход — включить makestep для ограниченного числа обновлений часов (второй аргумент директивы) и ограничить изменение смещения во всех обновлениях директивой maxchange. Злоумышленник сможет сделать лишь ограниченный шаг и только в том случае, если атака начнется через короткое время после загрузки компьютера или при перезапуске хронида без опции -R.
Смещение частоты может быть ограничено директивой maxdrift. Измеренное смещение частоты сообщается в файле дрейфа, отчете о слежении и журнале слежения. Установите maxdrift на значение больше, чем максимальное абсолютное значение, которое обычно наблюдается. Обратите внимание, что частота часов может измениться из-за старения кристалла, различий в калибровке источника часов между перезагрузками, миграции виртуальной машины и т. д. Типичные компьютерные часы имеют дрейф менее 100 частей на миллион (ppm), но возможны гораздо большие дрейфы (например, в некоторых виртуальных машинах).
Используйте только доверенные серверы, которые, как вы ожидаете, должны быть хорошо настроены и управляемы, использовать аутентификацию для собственных серверов и т. д. Используйте несколько серверов, в идеале в разных местах. Злоумышленнику придется иметь дело с большинством серверов, чтобы пройти выбор источника и обновить часы с большим смещением. Используйте директиву minsources, чтобы увеличить необходимое количество выбираемых источников, чтобы сделать выбор более надежным.
Не указывайте серверы в качестве одноранговых узлов. Симметричный режим менее безопасен, чем режим клиент/сервер. Если он не прошел проверку подлинности, он уязвим для атак типа «отказ в обслуживании» вне пути, и даже после проверки подлинности он по-прежнему подвержен атакам воспроизведения.
Как правило, следует избегать одновременного использования аутентифицированных и неаутентифицированных серверов. Если необходимо смешивание (например, для более точной и стабильной синхронизации с более близким сервером, который не поддерживает аутентификацию), аутентифицированные серверы должны быть настроены как доверенные и требовать, чтобы неаутентифицированные серверы не преобладали над аутентифицированными серверами при выборе источника. Начиная с версии 4.0 chrony, опции выбора включаются в таком случае автоматически. Это поведение можно отключить или изменить с помощью директивы authselmode.
Примером конфигурации клиента, ограничивающей воздействие атак, может быть
2.7. Как повысить точность системных часов с помощью источников NTP?
Выберите серверы NTP, которые хорошо синхронизированы, стабильны и расположены близко к вашей сети. Лучше использовать более одного сервера. Обычно рекомендуется как минимум три или четыре, чтобы chronyd мог обнаруживать серверы, которые подают ложное время, и объединять измерения из нескольких источников.
Если у вас есть сетевая карта с аппаратной отметкой времени, поддерживаемой в Linux, ее можно включить с помощью директивы hwtimestamp. Это должно сделать локальные метки времени приема и передачи пакетов NTP более стабильными и точными.
У директивы server есть несколько полезных опций: minpoll , maxpoll , polltarget , maxdelay , maxdelayratio , maxdelaydevratio , xleave , filter .
Первые три параметра задают минимальный и максимальный допустимый интервал опроса, а также способ корректировки фактического интервала в указанном диапазоне. Их значения по умолчанию: 6 (64 секунды) для minpoll, 10 (1024 секунды) для maxpoll и 8 (выборки) для polltarget. Значения по умолчанию следует использовать для обычных серверов в Интернете. Если у вас есть собственные NTP-серверы или если у вас есть разрешение на более частый опрос некоторых серверов, установка этих параметров для более коротких интервалов опроса может значительно повысить точность системных часов.
Оптимальный интервал опроса зависит главным образом от двух факторов: стабильности сетевой задержки и стабильности системных часов (которая в основном зависит от температурной чувствительности кварцевого генератора и максимальной скорости изменения температуры).
Как правило, если команда sourcestats обычно сообщает о небольшом количестве выборок, сохраненных для источника (например, менее 16), следует рассмотреть более короткий интервал опроса. Если количество выборок обычно не превышает 64, более длительный интервал опроса может работать лучше.
Примером директивы для NTP-сервера в Интернете, который вам разрешено часто опрашивать, может быть
Примером использования более коротких интервалов опроса для сервера, расположенного в той же локальной сети, может быть
Параметры maxdelay полезны для игнорирования измерений с необычно большой задержкой (например, из-за перегрузки в сети) и повышения стабильности синхронизации. В пример с локальным NTP-сервером можно добавить опцию maxdelaydevratio
Если ваш сервер поддерживает чередующийся режим (например, на нем работает chronyd ), в директиву сервера следует добавить параметр xleave, чтобы сервер мог предоставлять клиенту более точные метки времени передачи (ядро или предпочтительно аппаратное обеспечение). Например:
В сочетании с метками времени на локальном оборудовании, хорошими сетевыми коммутаторами и еще более короткими интервалами опроса возможна точность до микросекунд и стабильность в несколько десятков наносекунд. Например:
Для лучшей стабильности ЦП должен работать на постоянной частоте (т. е. отключать энергосбережение и повышение производительности). Энергоэффективный Ethernet (EEE) должен быть отключен в сети. Коммутаторы должны быть настроены на приоритет пакетов NTP, особенно если ожидается, что сеть будет сильно загружена. Директиву dscp можно использовать для установки точки кода дифференцированных услуг в передаваемых пакетах NTP, если это необходимо.
Если клиенты NTP в сети могут отправлять запросы с высокой скоростью, можно указать интервал опроса в доли секунды. Медианный фильтр может быть включен для обновления часов с пониженной частотой с более стабильными измерениями. Например:
В качестве экспериментальной функции, добавленной в версии 4.2, chronyd поддерживает поле расширения NTPv4, содержащее дополнительную метку времени, позволяющую передавать частоту и значительно улучшающую стабильность синхронизации. Его можно включить опцией extfield F323. Например:
2.8. Есть ли у chronyd режим ntpdate?
Да. С опцией -q chronyd установит системные часы один раз и выйдет. С опцией -Q будет напечатано измеренное смещение без установки часов.Если вы не хотите использовать файл конфигурации, серверы NTP можно указать в командной строке. Например:
Приведенная выше команда обычно занимает около 5 секунд, если серверы хорошо синхронизированы и отвечают на все запросы. Если не синхронизироваться или не отвечать, chronyd потребуется около 10 секунд, чтобы сдаться и выйти с ненулевым статусом. Возможна более быстрая конфигурация. Вместо четырех серверов можно использовать один сервер, с помощью параметра maxsamples можно уменьшить количество измерений до одного (поддерживается, начиная с версии 4.0 chrony), а с помощью параметра -t можно указать тайм-аут. Следующая команда займет около одной секунды.
Не рекомендуется периодически запускать chronyd с параметром -q (например, из задания cron) в качестве замены режима демона, поскольку он работает значительно хуже (например, часы ступенчатые, а их частота не корректируется). Если вы должны запустить его таким образом и используете общедоступный NTP-сервер, убедитесь, что chronyd не всегда запускается примерно в первую секунду минуты, например. добавив случайный сон перед командой chronyd. Общедоступные серверы обычно получают большие пакеты запросов примерно в первую секунду, поскольку большое количество клиентов NTP запускается из cron без задержки.
2.9. Можно ли настроить chronyd для управления часами, как ntpd?
Невозможно идеально эмулировать ntpd , но есть некоторые параметры, которые могут настроить chronyd так, чтобы он вел себя как ntpd, если есть причина предпочесть это.
В следующем примере директива minsamples замедляет реакцию на изменения частоты и смещения часов. Директивы maxslewrate и corrtimeratio уменьшают максимальную ошибку частоты из-за коррекции смещения, а директива maxdrift уменьшает максимальную предполагаемую ошибку частоты часов. Директива makestep включает порог шага, а директива maxchange включает порог паники. Директива maxclockerror увеличивает минимальную скорость дисперсии.
Обратите внимание, что увеличение числа минимальных выборок может привести к тому, что смещения в отчетах/журналах отслеживания и исходной статистики будут значительно меньше, чем фактические смещения, и это будет непригодно для мониторинга.
2.10. Можно ли отделить NTP-сервер от NTP-клиента?
Да, на компьютере можно запускать несколько экземпляров chronyd одновременно. Один может работать в основном как клиент NTP для синхронизации системных часов, а другой — как сервер для других компьютеров. Если они используют одну и ту же файловую систему, их необходимо настроить с разными pid-файлами, командными сокетами домена Unix и любым другим файлом или каталогом, указанным в файле конфигурации. Если они работают в одном и том же сетевом пространстве имен, им необходимо использовать разные порты NTP и команд или привязать порты к разным адресам или интерфейсам.
Экземпляр сервера следует запускать с параметром -x, чтобы предотвратить настройку системных часов и вмешательство в работу экземпляра клиента. Его можно настроить как клиент для синхронизации своих часов NTP с другими серверами или как экземпляр клиента, работающий на том же компьютере. В последнем случае параметр копирования (добавленный в версии 4.1 chrony) может использоваться для получения эталонного идентификатора и слоя экземпляра клиента, что позволяет обнаруживать циклы синхронизации с его собственными клиентами.
В Linux, начиная с версии chrony 4.0, можно запускать несколько экземпляров сервера с общим портом, чтобы лучше использовать несколько ядер ЦП. Обратите внимание, что для правильной работы ограничения скорости и режима чередования клиент/сервер необходимо, чтобы все пакеты, полученные с одного и того же адреса, обрабатывались одним и тем же экземпляром сервера.
В декабре 2018 г. я написал пакет для опроса и кэширования DNS-записей – пыльцы – для смягчения последствий инцидентов на работе.
Node.js уязвим для сбоев DNS
Node.js особенно уязвим для ошибок поиска DNS, потому что:
- Стандартная библиотека Node.js не имеет кэша DNS по умолчанию, в то время как другие языки/среды выполнения, такие как Java и Go, имеют его по умолчанию.
- Node.js использует небольшой пул потоков для поиска DNS. При медленных DNS-запросах или потере пакетов последующие поиски DNS должны ждать их завершения или истечения времени ожидания.
- До Node 10.12.0 ситуация была еще хуже, поскольку медленные DNS-запросы влияли на другие задачи в пуле потоков, такие как ввод-вывод файлов и кодирование/декодирование gzip.
Кэширование на уровне ОС
Мы можем сделать поиск в DNS быстрым и надежным, кэшируя его. Проблема в репозитории nodejs/node рекомендует использовать кэширование на уровне ОС. Мы можем запустить демон, такой как dnsmasq, unbound, CoreDNS и т. д.
Однако это не всегда просто в зависимости от используемой вами платформы. Моя команда использовала платформу, на которой мы просто развертываем Docker-контейнер вашего приложения, и было сложно настроить еще один демон в ОС.Большинство пользователей платформы были средами выполнения приложений, такими как Java и Go, которые по умолчанию имеют базовое кэширование DNS и редко имеют те же проблемы с приложениями Node.js. Было трудно убедить команду разработчиков платформы внедрить кэширование DNS для каждого узла на платформе только для приложений Node.js без конкретных доказательств, пока они сосредоточились на новой платформе на основе Kubernetes. (Позже они добавили DNS-кэширование для каждого узла на новую платформу, но рассматриваемое приложение не перейдет на нее по причинам.)
Поскольку инциденты не происходили на инстансах C4, а у нас были другие приоритеты для работы, мы просто откатились и какое-то время продолжали использовать инстансы C4. Однако я хотел закончить этот вопрос до празднования 2019 года. Поэтому я решил реализовать кэширование DNS на уровне приложения с помощью Node.js.
Кэширование и предварительная выборка DNS с помощью Node.js
Уже были некоторые пакеты кэширования DNS:
Кэширование и предварительная выборка DNS сообщают нам об изменении IP-адресов. Таким образом, мы можем продолжать использовать существующие подключения, пока IP-адреса остаются прежними, и повторно подключаться только при изменении IP-адресов. Таким образом, мы можем избежать ненужных рукопожатий TCP/TLS.
Результат
Я написал пыльцу, протестировал ее с экземплярами C4 и снова перенес наши серверы на C5. За пять месяцев проблем не возникло. Таким образом, похоже, что причиной был сбой DNS, и пакет может смягчить его.
Я ожидал повышения производительности из-за меньшего количества рукопожатий TCP/TLS, но не обнаружил большой разницы в задержке.
Как его использовать
Бонус: метрики поиска DNS
Поскольку поиск в DNS является важной операцией, рекомендуется отслеживать ее скорость, ошибки и задержку. пыльца испускает события для этой цели.
Я был удивлен тем, что поиск DNS иногда занимает 1,5 секунды. Это может быть из-за повторных попыток c-ares, но я пока не уверен (тайм-аут по умолчанию, кажется, составляет 5 секунд).
По умолчанию Burp использует общедоступный сервер Collaborator, предоставляемый PortSwigger, и этот вариант подходит для многих целей. Дополнительные сведения см. в основной документации Burp Collaborator.
При желании вы можете развернуть собственный частный экземпляр Collaborator Server. В этой документации описывается этот процесс и рассматриваются следующие темы:
- Установка и выполнение
- Базовая настройка в закрытой сети.
- Работа на нестандартных портах
- Конфигурация DNS
- Настройка SSL
- События взаимодействия и опросы
- Показатели
- Ведение журнала
- Проверка установки
- Формат файла конфигурации
Установка и выполнение
Сервер Burp Collaborator включен в тот же исполняемый файл, что и сам Burp Suite Professional. Для запуска собственного экземпляра сервера не требуется лицензионный ключ. Сервер можно запустить прямо из командной строки с помощью аргумента --collaborator-server, например:
sudo java -jar burp.jar --collaborator-server
Сервер не запустится, если он не сможет привязаться к портам, необходимым для работы его служб. Вам нужно будет остановить любые другие процессы, использующие эти порты. По умолчанию сервер Burp Collaborator прослушивает следующие порты:
Кроме того, в системах на основе Unix вам может потребоваться запустить сервер с привилегиями root для привязки к этим портам. Кроме того, вы можете настроить сервер для работы на нестандартных портах и использовать сопоставление портов для перенаправления исходных портов.
При запуске сервера Collaborator желательно настроить обработку памяти JVM и сборку мусора в зависимости от ожидаемого использования. Если вы используете сервер Collaborator на настольном компьютере для небольшого числа ожидаемых пользователей, вы можете уменьшить объем памяти, используемый JVM. Следующая команда позволяет размеру кучи колебаться от 10 до 200 МБ, а JVM может тратить 5 % своего времени на сборку мусора, которая обычно использует меньше памяти:
sudo java -Xms10m -Xmx200m -XX:GCTimeRatio=19 -jar burp.jar --collaborator-server
Если вы запускаете сервер Collaborator на выделенном компьютере для поддержки большего числа пользователей, то целесообразно зафиксировать размер кучи в соответствии с объемом доступной физической памяти, обычно оставляя 1 ГБ доступным для операционной системы. JVM и любые другие запущенные процессы. Например:
sudo java -Xmx3g -Xms3g -jar burp.jar --collaborator-server
Если предполагается, что сервер будет интенсивно использоваться и имеет более 4 ГБ физической памяти, рекомендуется переключиться на сборщик мусора G1, который значительно сокращает паузы JVM, которые могут возникать во время сбора мусора. Например:
sudo java -Xmx12g -Xms12g -XX:+UseG1GC -jar burp.jar --collaborator-server
Чтобы в полной мере использовать возможности сервера Collaborator, обычно также необходимо создать подходящий файл конфигурации.
Базовая настройка в закрытой сети
Частный сервер Collaborator обычно используется для поддержки одного тестировщика (или небольшой группы), работающего в частной закрытой сети. Если вы тестируете приложение в закрытой сети без доступа к Интернету, то общедоступный сервер Collaborator по умолчанию, конечно же, использовать нельзя.
В этом случае вы можете запустить базовый экземпляр сервера Collaborator с помощью одной из команд в разделе «Установка и выполнение» без необходимости в каком-либо файле конфигурации. Затем вам просто нужно настроить Burp для использования IP-адреса вашего компьютера в качестве сервера Collaborator.
Работа на нестандартных портах
Если вы хотите запустить сервер Collaborator от имени пользователя без полномочий root, вам необходимо настроить его для работы на нестандартных портах. Вам также потребуется настроить операционную систему для сопоставления исходных портов с пользовательскими портами, которые вы используете. Как правило, вам потребуется настроить сопоставления для входящих соединений TCP и UDP, а также для исходящих ответов UDP.
Вы можете настроить сервер Collaborator для использования нестандартных портов с помощью его файла конфигурации. Например:
<
"serverDomain" : "burpcollaborator.example.com",
"eventCapture": <
"http": <
"порты" : 8080
>>,
«https»: <
«порты» : 8443
>,
«smtp» : <
«порты» : [8025, 8587] < br />>,
"smtps": <
"ports" : 8465
>
>,
"dns": <
"ports" : 8053
>
>Обратите внимание, что значение "ports" может быть одним номером порта или массивом номеров портов, если вы хотите прослушивать службу на нескольких портах. По умолчанию сервер Collaborator прослушивает SMTP-взаимодействия через порты 25 и 587.
Конфигурация DNS
Burp Collaborator по умолчанию запускает службу DNS для определенного домена, и для ее использования вам потребуется выделенный домен или субдомен для использования Collaborator. Вы можете не использовать DNS и получать доступ к серверу Collaborator только по IP-адресу; однако эта конфигурация менее эффективна при обнаружении различных уязвимостей.
Серверу Collaborator необходимо знать, какой домен он контролирует, чтобы он мог обслуживать соответствующие записи DNS. Это настраивается в файле конфигурации Collaborator. Например:
Вам также потребуется настроить свой домен, чтобы DNS для домена был делегирован вашему серверу Collaborator. Детали этого будут зависеть от вашей настройки. Большинство регистраторов доменов предоставляют веб-интерфейс, позволяющий настроить официальные DNS-серверы для вашего домена.
Вам также потребуется настроить связующие записи, чтобы связать каждую из них с IP-адресом вашего сервера Collaborator. Если регистратор вашего домена требует, чтобы каждый настроенный DNS-сервер для домена располагался на другом IP-адресе, вам может потребоваться настроить два общедоступных IP-адреса на вашем сервере Collaborator.
Примечание. Невозможно избежать использования службы Collaborator DNS, просто отредактировав файл hosts тестируемого целевого сервера. При использовании сервера Collaborator в своем тестировании Burp использует случайно сгенерированные поддомены основного настроенного домена. Файлы хоста не поддерживают подстановочные знаки, поэтому их нельзя использовать для маршрутизации запросов со случайно сгенерированными субдоменами.
Настройка SSL
"ssl": <
"имя хоста" : "burpcollaborator.example.com"
>Использования самоподписанного сертификата может быть достаточно, если вы можете установить сертификат как доверенный на целевом сервере, который вы тестируете, или если целевое приложение не проверяет SSL-сертификаты.
Если вы приобрели действительный подстановочный SSL-сертификат для своего домена, вы можете получить сертификат в своем центре сертификации (ЦС) и установить его на своем сервере Collaborator. В этом примере мы сгенерировали запрос на подпись сертификата (CSR) с использованием OpenSSL, и ЦС предоставил сертификат и промежуточный сертификат.
В OpenSSL форматом ключей по умолчанию является традиционный формат SSLeay. Их необходимо преобразовать в PKCS8, прежде чем сервер Collaborator сможет их импортировать. Команда OpenSSL для этого преобразования:
Сертификаты SSL можно настроить с помощью файла конфигурации Collaborator. В следующем примере файла конфигурации показано, как загрузить закрытый ключ, сертификат и промежуточный сертификат:
"ssl": <
"certificateFiles" : [
"keys/burpcollaborator.example.com.key.pkcs8",
"keys/burpcollaborator.example.com.crt" ,
"keys/intermediate.crt"]
>Примечание. Файлы сертификатов должны быть указаны в правильном порядке: закрытый ключ, сертификат, промежуточные сертификаты.
Кроме того, вы можете сгенерировать CSR с помощью инструмента для работы с ключами Java и импортировать полученный сертификат в хранилище ключей Java на сервере. В этой ситуации вы можете настроить Collaborator для загрузки сертификата, используя:
"ssl": <
"keystore": <
"path" : "myKeystore.jks",
"password" : "myPassword"
>Если вы настроили отдельные сетевые интерфейсы для событий взаимодействия и опроса, вам потребуется настроить SSL отдельно для каждого интерфейса.
События взаимодействия и опросы
Сервер Collaborator поддерживает два типа входящих сообщений от клиентов:
По умолчанию сервер Collaborator обрабатывает как события взаимодействия, так и запросы опроса на одном и том же сетевом интерфейсе. При желании вы можете настроить Collaborator на использование разных интерфейсов (или портов) для обслуживания запросов на опрос. Это средство можно использовать для обхода ограничений брандмауэра или для управления доступом к функции опроса на сетевом уровне.
Вы можете настроить отдельный интерфейс опроса, используя необязательный раздел "опрос" в файле конфигурации Collaborator. Если вы сделаете это, вы сможете использовать один и тот же подстановочный SSL-сертификат для обоих интерфейсов и позволить службе DNS сервера Collaborator направлять запросы опроса на правильный интерфейс. При такой настройке вам нужно будет только настроить местоположение сервера в параметрах Burp Collaborator Server, и Burp автоматически добавит «опрос». к серверному домену при выполнении запросов на опрос. Служба DNS Соавтора разрешает субдомен опроса в общедоступный IP-адрес отдельного интерфейса опроса. Это дает преимущество использования отдельных интерфейсов взаимодействия и опроса, а также упрощает настройку клиента Burp.
Показатели
Сервер Collaborator регистрирует различные показатели использования, что позволяет администраторам отслеживать производительность и нагрузку на сервер. Эти метрики могут быть полезны для подтверждения того, что компьютер Collaborator достаточно мощный для своего уровня использования. Обратите внимание, что метрики не содержат данных, извлеченных из конкретных событий взаимодействия и запросов опроса.
Данные показателей доступны через интерфейс опроса сервера Collaborator, а доступ можно контролировать с помощью общего секретного URL-адреса и белого списка клиентских IP-адресов. Показатели отключены по умолчанию, но их можно включить с помощью дополнительного раздела «метрики» в файле конфигурации Collaborator. Например:
"опрос" : <
"publicAddress" : "10.20.0.159"
>,
"метрика": <
"путь" : "jnaicmez8",
"адресБелый список" : ["21.10.23.0/24"]
>,При такой конфигурации метрики будут доступны клиентам в сети 21.10.23.0/24 по URL-адресу:
Ведение журнала соавторов
- ВЫКЛ — ничего не регистрируется.
- ОШИБКА. Зарегистрированы непредвиденные исключения.
- ИНФОРМАЦИЯ. Информация о конфигурации и службах регистрируется при запуске. Это значение по умолчанию.
- ОТЛАДКА – регистрируются сведения о взаимодействиях и опросах соавторов, включая исходный IP-адрес и идентификаторы взаимодействий. Обратите внимание, что это может привести к раскрытию конфиденциальной информации в выходных данных журнала.
Проверка установки
Когда сервер развернут, вы можете использовать Burp Suite для проверки правильности его работы. В Burp Suite Professional настройте параметры вашего сервера в параметрах сервера Burp Collaborator и запустите функцию проверки работоспособности. Затем Burp попытается выполнить каждую из ожидаемых функций Collaborator и сообщит об успешном или неудачном выполнении каждой функции.
Формат файла конфигурации соавтора
Все параметры сервера Burp Collaborator управляются с помощью файла конфигурации. По умолчанию сервер Collaborator ищет файл с именем collaborator.config в текущем рабочем каталоге. Это расположение можно переопределить из командной строки с помощью аргумента --collaborator-config, например:
sudo java -jar burp.jar --collaborator-server --collaborator-config=myconfig.config
Файл конфигурации использует формат JSON с поддержкой комментариев. Там, где требуются IP-адреса, вы можете настроить либо один адрес, либо список адресов. Например, для настройки локальных адресов сетевого интерфейса можно использовать любой из следующих способов:
"localAddress" : "10.20.0.159"
"localAddress" : ["10.20.0.159", "127.0.0.1"]Ниже показан полный пример файла конфигурации вместе с объяснением каждой доступной опции:
<
"serverDomain" : "burpcollaborator.example.com",
"workerThreads" : 10,
"eventCapture": <
"localAddress" : ["10.20 .0.159", "127.0.0.1"],
"publicAddress" : "10.20.0.159",
"http": <
"порты" : 80
>, < br />«https»: <
«порты» : 443
>,
«smtp»: <
«порты» : [25, 587]
> ,
"smtps": <
"ports" : 465
>,
"ssl": <
"certificateFiles" : [
"keys/ burpcollaborator.example.com.key.pkcs8",
"keys/burpcollaborator.example.com.crt",
"keys/intermediate.crt" ]
>
>,
"опрос" : <
"localAddress" : "127.0.0.1",
"publicAddress" : "10.20.0.159" ,
"http": <
"порт": 9090
>,
"https": <
"порт" : 9443
>, < br />"ssl": <
"имя хоста" : "collaboratorpolling.example.com"
>
>,
"метрики": <
"путь" : "jnaicmez8",
"адресБелый список" : ["21.10.23.0/24"]
>,
"dns": <
"интерфейсы" : [ <
"name": "ns1",
"localAddress" : "34.23.11.6",
"publicAddress" : "98.87.76.55"
>, <
"name" : "ns2",
"localAddress" : "34.23.11.6",
"publicAddress" : "98.87.11.00"
>],
"порты" : 53
>,
"logLevel" : "INFO"
>Определения поддерживаемых полей в файле конфигурации показаны ниже:
DNS-серверы можно настроить на устройстве Solace PubSub+ с помощью инструкций, приведенных в разделе Добавление DNS-серверов. Эта функция не поддерживается программными брокерами событий.
Как на устройствах, так и на программных брокерах событий рабочая команда, показанная в разделе «Настройка имени опрашиваемого домена», может использоваться для установки имени домена, который будет опрашиваться, чтобы определить, доступны ли подготовленные DNS-серверы, а также команда, описанная в разделе «Отображение подготовленных DNS-серверов». DNS-серверы можно использовать для перечисления этих серверов.
Добавление DNS-серверов
На устройстве можно настроить DNS-серверы на внешних хост-компьютерах, чтобы имена хостов можно было использовать в качестве IP-адресов сетевых объектов. (Информацию о выборе хост-компьютера и установке серверного программного обеспечения см. в документации к стороннему DNS-серверу.)
Чтобы добавить DNS-сервер к устройству, введите следующие команды CONFIG после того, как убедитесь, что IP-адрес DNS-сервера доступен из интерфейса управления Solace и что DNS-сервер находится в VRF Solace Management:
это IP-адрес DNS-сервера, указанный в виде десятичной записи с точками nnn.nnn.nnn.nnn.
Версия no этой команды, no name-server , удаляет существующий DNS-сервер из списка DNS-серверов и удаляет все связанные с ним значения конфигурации.
- DNS-серверы также можно добавить к устройству во время его первоначальной настройки. См. Первоначальная настройка.
- Вы должны повторить команду name-server DNS CONFIG для каждого DNS-сервера, который вы хотите добавить (можно добавить до трех). Каждое добавление помещается в конец списка DNS.
- Если подготовлено несколько DNS-серверов имен, механизм запроса имени хоста пытается использовать первый DNS-сервер в списке, а если время запроса истекает, он пытается использовать следующий DNS-сервер, пока не будет достигнут конец списка. Однако, если при запуске первый DNS-сервер отвечает сообщением NOT FOUND, цикл запроса отменяется.
- При использовании Config Sync настроенные DNS-серверы синхронизируются между резервными устройствами; однако DNS-серверы не синхронизируются между сайтами репликации.
Настройка имени опрашиваемого домена
Чтобы настроить доменное имя, которое будет проверяться каждые 30 секунд, чтобы определить, доступны ли подготовленные DNS-серверы, введите следующие команды CONFIG:
Настройка списка поисковых доменов
Конфигурация DNS на каждом устройстве включает список доменов, которые нужно добавить к имени хоста, которое система пытается разрешить. Если поиск в DNS завершается неудачно, система повторяет поиск с доменами, содержащимися в списке поиска, по порядку, пока один из них не будет успешным.
Например, предположим, что система пытается разрешить имя хоста ldap.example.echonet, а список поиска включает домены xmp.solace.intra , solace.intra и eu.solace.intra . Если DNS-сервер, который использует устройство, не может разрешить ldap.example.echonet, он попытается разрешить ldap.example.echonet.xmp.solace.intra, ldap.example.echonet.solace.intra и ldap.example.echonet. .eu.solace.intra по порядку, пока один из них не будет успешным.
Чтобы настроить список поисковых доменов, введите следующие команды CONFIG:
— это список доменов для поиска. Вы можете указать разделенный пробелами список до шести доменов общей длиной 256 символов. По умолчанию в список не включены домены.
Версия no этой команды, no search-domain-list , сбрасывает список доменов по умолчанию.
Отображение подготовленных DNS-серверов
Чтобы просмотреть подготовленные DNS-серверы, введите следующую команду User EXEC:
Если предоставлено несколько серверов DNS-имен, запросы выполняются в порядке перечисления серверов, отображаемом командой show dns User EXEC.
Поиск DNS-имени
Во всех контекстах, где применяется разрешение имен (например, адреса подключения через для VPN-мостов), брокер событий пытается разрешить доменные имена с помощью настроенных DNS-серверов либо на устройстве, либо в ОС хоста программного обеспечения. брокер событий.
В обоих случаях брокер попытается установить соединение с IPv4-адресом с наивысшим приоритетом и IPv6-адресом с наивысшим приоритетом (если поддерживается); сначала предпринимается попытка подключения к адресу с более высоким приоритетом.
Читайте также: