Я играю с bind и начал задаваться вопросом, почему это программное обеспечение, например, в CentOS работает в chroot. Не поймите меня неправильно, я знаю, что такое bind и для чего нужен chroot (jail). Но мой главный вопрос заключается в том, что связывание, работающее без chroot, настолько небезопасно?
Неужели это вредно ставить без джейла (больше, чем любой другой сервис или софт). В системах много процессов, работающих без chroot, и я думаю, что компрометация любого из них очень опасна, но что делает named более опасным, чем другое программное обеспечение, работающее без chroot?
Как сказал @Some Guy, вы должны думать об этом в исторической перспективе.
Историческая перспектива заключалась в том, что одна часть оборудования представляет собой дюжину или около того различных служб под одной операционной системой. Если одна служба была скомпрометирована, то все на этом оборудовании было скомпрометировано.
С виртуализацией это не проблема. Хотя сбежать из виртуальной машины возможно, это далеко не тривиально. Вырваться из виртуальной машины, безусловно, труднее, чем для процесса, работающего с привилегиями root, выйти из chroot. Итак, мои серверы привязки работают на собственной виртуальной машине. В этом случае действительно нет особого смысла для chroot, поскольку ущерб уже ограничен просто тем фактом, что это виртуальная машина.
Chroot - это очень слабая попытка создать что-то вроде виртуальной машины. Однако от chroot можно экранировать любой процесс с привилегиями root. Chroot не предназначен и не работает как механизм безопасности. Chroot с тюрьмой BSD или LXC обеспечивает виртуализацию на уровне ОС и предоставляет функции безопасности. Но в наши дни, когда настолько легко развернуть новую виртуальную машину на целой машине, может не стоить усилий по настройке или изучению того, как использовать инструменты виртуализации на уровне ОС для этой цели.
Более ранние версии bind не теряли привилегий. В Unix только учетная запись root может открывать порты ниже 1024, а Bind, как мы все знаем, должен прослушивать udp / 53 и tcp / 53. Поскольку Bind запускается как root и не теряет привилегий, любой компромисс может означать, что вся система может быть скомпрометирована. Почти любое программное обеспечение в наши дни начнет открывать свои сокеты и выполнять любые другие действия, требующие привилегий root, а затем они изменят пользователя, которого они запускают, на непривилегированную учетную запись. Как только привилегии отброшены, влияние компрометации на хост-систему намного ниже.
Другие ответы довольно хороши, но не упоминают концепцию послойной безопасности. Каждый уровень безопасности, который вы добавляете в свою систему, - это еще один уровень, который злоумышленник должен преодолеть. Включение BIND в chroot добавляет еще одно препятствие.
Допустим, в BIND есть уязвимость, которую можно использовать, и кто-то может выполнить произвольный код. Если они находятся в chroot, им нужно выйти из этого, прежде чем переходить к чему-либо еще в системе. Как уже упоминалось, для взлома chroot необходимы права root. 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 jail.
несколько шагов по защите вашей chroot jail
то есть делать НЕ запускать процессы как 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 ПО-ПРЕЖНЕМУ служит цели. существует множество приложений, в которых виртуализация всей системы является излишней.
В ответ на ваш вопрос
Я не особо использую CentOS, но знаю, что Bind теперь теряет свои привилегии перед операциями. Я бы предположил, однако, что привязка хромирована из-за истории векторов атак и потенциальных уязвимостей.
также ... имеет больше смысла автоматически исключать это приложение, чем нет, потому что не КАЖДЫЙ имеет доступ к полной виртуализации на уровне системы / операционной системы. это, в свою очередь, теоретически помогает обеспечить безопасность базы пользователей CentOS:
поставщики операционных систем просто не предполагают, что все работают с одной и той же системой. таким образом, они могут помочь обеспечить дополнительный уровень безопасности в целом ...
есть причина, почему так много приложений используют это, и почему, очевидно, ваша ОС работает по умолчанию: потому что она ИСПОЛЬЗУЕТСЯ как средство безопасности и ДЕЙСТВИТЕЛЬНО работает. При тщательной подготовке, как уже говорилось ранее, потенциальный злоумышленник должен преодолеть еще одно препятствие - большую часть времени, ограничивая нанесение ущерба только chroot jail.
Частично это связано с историческими причинами, когда старые версии Bind часто имели серьезные уязвимости в системе безопасности. На самом деле я не был в курсе событий по этому поводу, но готов поспорить, что он значительно улучшился со времен старых плохих дней.
Другая причина, более практичная, заключается в том, что она обычно развертывается в роли, доступной для Интернета, и поэтому открыта для большего количества атак, зондирования и общих неприятностей.
Поэтому, как это часто бывает в вопросах безопасности: лучше перестраховаться, чем сожалеть, тем более что усилия по chroot-процессу относительно невелики.