Почему запуск named (bind) в chroot так важен для безопасности? Или может это не так?

Я играю с bind и начал задаваться вопросом, почему это программное обеспечение, например, в CentOS работает в chroot. Не поймите меня неправильно, я знаю, что такое связывание и для чего нужен chroot (jail). Но мой главный вопрос заключается в том, что привязка работает без chroot, так что она небезопасна?

Действительно ли вредно устанавливать его без джейла (больше, чем любой другой сервис или программное обеспечение). В системах существует много процессов, запущенных без chroot, и я думаю, что компромисс любого из них очень опасен, но что делает именованное более опасным, чем другое программное обеспечение, работающее без chroot?

Как сказал @Some Guy, вы должны думать об этом в исторической перспективе.

Историческая перспектива заключалась в том, что один аппаратный блок представлял собой дюжину различных служб в рамках одной операционной системы. Если один сервис был скомпрометирован, то все на этом оборудовании было скомпрометировано.

С виртуализацией это гораздо меньше проблем. Хотя вырваться из ВМ невозможно, это далеко не тривиально. Конечно, выйти из виртуальной машины труднее, чем процессу, работающему с привилегиями root, выйти из chroot. Так что мои серверы связывания работают на собственной виртуальной машине. В этом случае для chroot нет особого смысла, поскольку ущерб уже ограничен просто тем, что это виртуальная машина.

Chroot - очень слабая попытка создать что-то вроде виртуальной машины. Через Chroot может быть удален любой процесс с правами root. Chroot не предназначен и не работает как механизм безопасности. Chroot с BSD-тюрьмой или LXC обеспечивает виртуализацию на уровне ОС и обеспечивает функции безопасности. Но в наши дни из-за того, что так легко раскрутить новую виртуальную машину всей машины, может не стоить усилий по настройке или научиться использовать инструменты виртуализации на уровне ОС для этой цели.

Более ранние версии bind не сбрасывали привилегии. В Unix только корневая учетная запись может открывать порты ниже 1024, и Bind, как все мы знаем, должен прослушивать udp / 53 и tcp / 53. Поскольку Bind запускается с правами root и не удаляет привилегии, любой компромисс будет означать, что вся система может быть взломана. Практически любое программное обеспечение в наши дни начнет открывать свои сокеты и выполнять любые другие действия, требующие прав суперпользователя, затем они заменят пользователя, с которым они работают, на непривилегированную учетную запись. После того, как привилегии упадут, влияние компрометации будет намного ниже для хост-системы.

Другие ответы довольно хороши, но не упоминают концепцию безопасности в слоях. Каждый уровень безопасности, который вы добавляете в свою систему, - это еще один уровень, который должен преодолеть противник. Помещение BIND в chroot добавляет еще одно препятствие.

Скажем, в BIND существует уязвимость, которую можно использовать, и кто-то может выполнить произвольный код. Если они находятся в затруднительном положении, им нужно вырваться из этого, прежде чем перейти к чему-либо еще в системе. Как уже упоминалось, привилегии root требуются для взлома chroot. BIND не запускается с правами root, и предполагается, что в chroot должно быть доступно минимальное количество инструментов, что дополнительно ограничивает параметры и по существу оставляет только системные вызовы. Если нет системного вызова для повышения привилегий, то злоумышленник застревает, просматривая ваши записи DNS.

Вышеупомянутая ситуация несколько маловероятна, как упоминает SomeGuy, в наши дни BIND имеет довольно мало уязвимостей, и они в основном ограничены сценариями типа DoS, а не удаленным выполнением. Тем не менее, запуск в chroot является конфигурацией по умолчанию для довольно многих операционных систем, поэтому вряд ли вам понадобятся какие-либо усилия для поддержания слегка повышенного уровня безопасности.

преамбула

я продолжаю слышать, что люди повторяют заблуждения со всего интернета .. таким образом, я попытаюсь дать некоторые разъяснения

прежде всего; сколько случайно открытия там были, что просто .. из - за причины и следствия , в конечном итоге используется для чего - то другого , чем по прямому назначению?

что было и что такое тюрьма Chroot

Изначально Chroot был разработан для изменения корневого каталога для процесса или пользователя (отлично подходит для компиляции программного обеспечения из неизвестных источников). это обеспечило безопасность базовой системы, а также устройства для быстрого тестирования, включая простую очистку. с тех пор прошли годы, и его концепция и предполагаемое использование, безусловно, изменились.

chroot был эффективно использован и находится непосредственно в базе кода для нескольких программ и библиотек (то есть openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot и многих других ). предполагать, что все эти основные приложения реализовали ошибочные решения по безопасности, просто не соответствует действительности

chroot - это решение для виртуализации файловой системы: ни меньше, ни больше. предположение о том, что вы можете легко выйти из chroot, также неверно ... при условии, что вы придерживаетесь принципов запуска процессов внутри chroot-тюрьмы.

несколько шагов, чтобы обезопасить вашу chroot тюрьму

т.е. НЕ запускайте процессы как ROOT. это может открыть корневой вектор эскалации (что также верно внутри или вне chroot). не запускайте процесс внутри chroot, используя того же пользователя, что и другой процесс вне chroot. Разделите каждый процесс и пользователя в его собственный Chroot, чтобы ограничить поверхность атаки и обеспечить конфиденциальность. монтируйте только необходимые файлы, библиотеки и устройства. наконец, chroot не является заменой безопасности базовой системы. обезопасить систему во всей ее полноте.

Еще одно важное замечание: многие люди думают, что OpenVZ сломан или что он не равен по сравнению с полной виртуализацией системы. они делают это предположение, потому что это по сути Chroot, с таблицей процессов, которые должны быть стерилизованы. с мерами безопасности на месте на оборудовании и устройствах. большинство из которых вы можете реализовать в chroot.

Не каждый администратор обладает уровнем знаний, необходимым для защиты всех необходимых параметров ядра на выделенном сервере или при полной виртуализации системы. это означает, что развертывание OpenVZ означает, что у ваших клиентов будет гораздо меньше возможностей для атаки, чтобы попытаться их защитить и обезопасить перед развертыванием своих приложений. Хороший хост хорошо справится с защитой этих параметров, и это, в свою очередь, лучше не только для всех на узле или в дата-центре, но и для Интернета в целом ...

как указано, chroot обеспечивает виртуализацию файловой системы. Вы должны убедиться, что нет исполняемых файлов setuid, небезопасных приложений, библиотек, висячих символических ссылок без владельца и т. д. Если злоумышленник МОЖЕТ скомпрометировать связывание, ему потребуется очистить виртуальную файловую систему для чего-либо, чтобы переполнить буфер, поиграться с файловыми дескрипторами или каким-то другим образом ставить под угрозу что-либо, находящееся внутри chroot-выхода из тюрьмы, обычно путем повышения привилегий или введения его или ее полезной нагрузки в базовую систему.

если это происходит, это обычно является результатом плохого обновления, использования нулевого дня или идиоматической человеческой ошибки .

почему до сих пор используется chroot, а не полная виртуализация системы

рассмотрим следующий сценарий: вы используете виртуальный частный сервер, а на хост-узле работает OpenVZ. Вы просто не можете запустить что-нибудь, что работает на уровне ядра. это также означает, что вы не можете использовать виртуализацию операционной системы для разделения процессов и обеспечения дополнительной безопасности. таким образом, вы ДОЛЖНЫ использовать chroot для этой цели.

Более того, chroot устойчив в любой системе, независимо от доступных ресурсов. Проще говоря, он имеет наименьшие издержки из всех типов виртуализации. это означает, что это все еще важно на многих нижних уровнях.

Рассмотрим другой сценарий: у вас есть Apache, работающий в виртуальной среде. Вы хотите отделить каждого пользователя. Предоставление виртуальной файловой системы с помощью дополнения chroot к apache (mod_chroot, mod_security и т. д.) было бы наилучшим вариантом для обеспечения максимальной конфиденциальности между конечными пользователями. это также помогает предотвратить сбор информации и предлагает еще один уровень безопасности.

Проще говоря, важно реализовать безопасность в слоях . Chroot потенциально является одним из них. не у всех и у каждой системы есть возможность иметь доступ к ядру, поэтому chroot STILL служит цели. Есть множество применений, в которых полная виртуализация системы существенно излишня.

В ответ на ваш вопрос

Я не особо использую CentOS, но я знаю, что Bind теперь отбрасывает свои привилегии перед операциями. я бы предположил, однако, что привязка привязана из-за его истории векторов атак и потенциальных уязвимостей.

Кроме того ... имеет смысл автоматически синхронизировать это приложение, чем нет, потому что не ВСЕ имеют доступ к полной виртуализации на уровне системы или операционной системы. это, в свою очередь, теоретически помогает обеспечить безопасность базы пользователей CentOS:

поставщики операционной системы просто не ходят, если все работают под управлением одной и той же системы. таким образом, они могут помочь обеспечить дополнительный уровень безопасности в целом ...

есть причина, по которой так много приложений используют это , и почему очевидно, что ваша ОС делает это по умолчанию: потому что она используется в качестве функции безопасности, и она работает. с тщательной подготовкой, как указывалось ранее, это еще одно препятствие, которое потенциальный злоумышленник должен преодолеть - большую часть времени, ограничивая нанесение ущерба только тюрьме.

Частично это связано с историческими причинами, когда старые версии Bind имели серьезные, частые уязвимости безопасности. Я на самом деле не в курсе этой темы, но держу пари, что она значительно улучшилась со времен плохих времен.

Другая причина, более практичная, заключается в том, что она, как правило, развернута в роли, связанной с Интернетом, и, как таковая, она открыта для новых атак, проверок и общего вреда.

Поэтому, как это часто бывает, в вопросах безопасности: лучше, чем потом сожалеть, особенно потому, что усилия по привязке к нему относительно невелики.