Всем привет! В сентябре OTUS открывает набор на новый поток курса «Безопасность Linux». В связи с этим традиционно подготовили для вас перевод полезного материала.
В 1991 году произошли два не связанных между собой события, каждое из которых предвещало две совершенно разных свободы: конец Холодной Войны и рождение Linux.
Возможность патчинга ядра в реальном времени появилась в 2008 году, когда Linux был еще подростком. Сегодня, когда ядру Linux вот вот стукнет 30, патчинг в реальном времени тоже созрел и готов опровергнуть свою репутацию необязательного дополнения, которое просто «неплохо иметь в комплекте».
На это есть две причины. Во-первых, это доминирование Linux в качестве предпочтительной платформы для экономичного и универсального веб-хостинга: более половины всех известных веб-сайтов в настоящее время работают на Linux. Во-вторых, признание того, что патчинг в реальном времени — это не просто удобство; это также эффективный и малозатратный способ повышения безопасности системы Linux.
Ksplice, первое решение для патчинга ядра Linux в реальном времени, без особых усилий приобрело прибыльный статус после запуска, лишь укрепив свое лидерство, когда технологический гигант Oracle купил его в 2011 году. Сегодня это самая известная из пяти организаций, предлагающих услуги автоматических исправления безопасности для Linux. В алфавитном порядке это:
Каждая компания продвигает свои услуги с использованием одних и тех же шаблонных ключевых слов, одних и тех же стандартных фраз, повторяемых до бесконечности. Я приведу вам самые популярные из них и то, как вы должны их понимать.
Не обращайте внимания на эти ослепляюще очевидные коммерческие доводы и вы обнаружите другие особенности, заслуживающие внимания, другие факторы, которые вы можете использовать, чтобы сравнить одну службу с другой. В этой статье рассматриваются некоторые из них, слегка приправленные утверждением и назиданием. Но сначала напомним, что такое live patching.
Ядро Linux содержит более 20 миллионов строк кода, написанных в основном (предположительно) людьми-программистами. Как и во всем программном обеспечении, в нем есть ошибки. В наш век повышенного внимания к кибербезопасности ошибки предполагают уязвимости. Чтобы решить эту проблему, производители Linux стараются как можно быстрее выпускать обновления для своих ядер. Системные администраторы Linux также стараются быстро реагировать, устанавливая эти обновления, составлять график работы становится сложнее. Это потому, что нет никакой закономерности для обнаружения уязвимостей. Вот несколько причин, почему:
Есть еще один момент, о котором редко упоминают: это инстинктивное отвращение системного администратора к остановке машины, вызывающая физический дискомфорт от необходимости сказать: «Сервер отключен на обслуживание».
Зачем нужна остановка сервера? Потому что обновление ядра не вступит в силу до перезагрузки. Если вы не перезагрузитесь — если отложите ее в долгий ящик или забудете, — вы окажетесь в затруднительном положении, потому что сервер без актуальных патчей является небезопасным. Позже мы поговорим об этой мантре подробнее, но суть ее такова:
Когда уязвимости становятся общедоступными, то же происходит и с их эксплойтами.
Или, говоря другими словами, у вас есть уязвимость, о которой вы не знали раньше, но теперь знаете. И все остальные тоже.
Спаситель в этом сценарии — установка исправлений в реальном времени (live patching). Это способ обновления не всего ядра Linux, а только его проблемной части. И делается это без остановки процессов или прерывания работы пользователей.
Однако есть ограничения. Патчинг ядра в реальном времени не может исправить все виды ошибок. Ошеломляющая сложность кода ядра и технические проблемы, связанные с изменением кода на лету, означают, что эта техника используется только для устранения критических проблем, обычно связанных с безопасностью.
Несмотря на это, система со средствами для установки патчей в реальном времени более безопасна, чем система без нее. Вот несколько вопросов, которые стоит задавать, когда вы ищете решение для патчинга в реальном времени:
Когда вы подписываетесь на услугу патчинга в реальном времени, вы платите больше, чем просто за само программное обеспечение. Это становится понятно, когда вы начинаете копаться в исходном коде ядра Linux и понимаете, как плохо написанный патч может нанести вред всей Linux системе.
Я упоминал ранее, что ядро - это огромный объем работы, которая, кажется, расширяется как по активности, так и по объему. Обратите внимание на рост количества строк кода в главной ветке репозитория ядра Linux. (Подсчет происходит по состоянию на 1 января каждого года. Учитываются только файлы и заголовки C/C++, файлы Python и Perl.)
С таким большим объемом кода писать патчи для ядра Linux — непростая задача. Требуется глубокое знакомство с архитектурой ядра и структурами данных. Требуется опыт работы с соглашениями о написании кода и стандартами качества сообщества Linux. И нужен особый талант, чтобы изобретать решения, не влияющие на функциональность, производительность и стабильность.
Есть два противоположных метода, которые производители исправлений используют для разработки и доставки патчей для ядра. Я называю их инкрементальным и монолитным.
Инкрементальные патчи, как шарик жевательной резинки, накладываются друг на друга, каждый из которых изменяет поведение предыдущего. Вы, как заказчик, должны отслеживать, какие патчи вы устанавливаете, а какие нет, а также порядок их установки. Невнимание к этим вопросам может привести к непредсказуемым изменениям в поведении вашей системы. Этот метод наложения патчей позволяет поставщикам быстро выпускать небольшие целевые патчи. Но со временем система может стать нестабильной до такой степени, что восстановить ее сможет только полное обновление ядра.
Монолитный патч — это патч, включающий все предыдущие патчи. По сути, есть только один мастер-патч, который заменяет активный, а не добавляется к нему. Такой подход делает платформу более стабильной, значительно увеличивая время безотказной работы сервера, которое часто измеряется тысячами дней.
Между отчетом об уязвимости и ее исправлением неизбежна присутствует задержка. Требуется время, чтобы проанализировать ошибки ядра, и время, чтобы оценить их влияние. Требуются изобретательность и мастерство, чтобы найти решение, и масса тестов, чтобы убедиться, что оно работает. Затем его ждет обязательная проверка и утверждение в рамках процесса разработки Linux.
Задержки, которых можно избежать, случаются, когда поставщик Linux заменяет оценку серьезности сообщества своей собственной. Это означает, что поставщик может устранить несколько уязвимостей с помощью меньшего количества исправлений, но из-за этого заказчик в среднем дольше ждет исправления определенных проблем.
Администраторы Linux, которые понимают причины беспорядочного характера выпусков исправлений, не в большем выигрыше, чем те, что нет. Ни один из них не находит утешения в знании того, что пока они ждут патчей, их системы еще более уязвимы для эксплойта, чем они были до его обнаружения.
И вот почему: члены сообщества исследователей кибербезопасности любят объявлять об уязвимости вместе с наглядным примером использования. Обычно они принимают форму подтверждения концепции, подробного технического описания того, как воспроизвести ошибку или использовать эксплойт. Эти описания имеют честное намерение: помочь разработчикам ядра найти и залатать дыру. Но они также экономят хакерам много времени и усилий, давая им короткий путь к буквальному рецепту катастрофы в их гонке за использование уязвимости в качестве оружия.
Почти все вновь обнаруженные уязвимости получают идентификатор CVE. Позже, при более внимательном рассмотрении исследователей безопасности уязвимость получает оценку серьезности, то есть меру ее воздействия.
Важной схемой рейтинга является общая система оценки уязвимостей (CVSS — Common Vulnerability Scoring System). Она представляет уязвимость в виде набора чисел, каждое из которых является оценкой характеристики, например:
В полный комплект входит еще много подобных оценок. Алгоритм объединяет их в базовую оценку, одну аккуратную цифру, выражающую серьезность уязвимости в диапазоне от 0 (низкая) до 10 (высокая). CVSS второй версии делит диапазоны этих чисел на ключевые слова LOW, MEDIUM и HIGH. В новой версии CVSS 3 добавлены еще два: NONE и CRITICAL.
Таким образом, количество уязвимостей варьируется не только по месяцам и годам, но и по степени серьезности.
Схемы оценки уязвимости, такие как CVSS, дают поставщикам Linux возможность оценить, как реагировать на конкретную уязвимости ядра. Например, они могут захотеть написать исправления для уязвимостей с совокупным баллом 7 и выше. Это означает HIGH в CVSS v2, HIGH или CRITICAL в CVSS v3. Поставщик, утверждающий, что нацелен на критические уязвимости, может иметь в виду только уязвимости с рейтингами серьезности 9 и 10, если использует CVSS v3.
Автоматическая установка исправлений без какого-либо надзора — страшная идея для многих системных администраторов. Они знают, что даже тщательно протестированные исправления могут изменить поведение системы, влияя на ее производительность или функциональность незаметным и не вполне очевидным образом. Когда это происходит, когда сервер ведет себя странно после установки патча, самый быстрый способ справиться с этим — удалить патч.
Некоторые сервисы патчинга в реальном времени могут удалять патчи. Это упрощает определение того, является ли недавнее обновление причиной изменений в поведении системы.
Агент ПО для патчинга в реальном времени проверяет наличие доступных исправлений на удаленных птач-серверах. Он делает это через регулярные настраиваемые интервалы, обычно с возможностью выполнения специальных проверок. Если патч доступен, программное обеспечение агента загрузит и установит его. Но если агент патчинга не может связаться с патч-сервером, где служба патчинга поставщика хранит патчи, патчинг в реальном времени не произойдет.
Чтобы решить эту проблему, нужно создать собственный патч-сервер. Такой локальный сервер транслирует патчи на все компьютеры вашей компании под вашим фаерволом. Средство безопасного копирования загружает патч и затем распространяет их через фаервол после проверки целостности файлов патчей. Вы можете управлять этим процессом и проверять его, когда вам удобно, сделав совет директоров вашей компании немного спокойнее.
Есть и другие преимущества:
Для динамического патчинга необходимы локальный агент и удаленный патч-сервер. Контроль над обоими очень важен для развертываний в масштабах предприятия.
Перед тем как подвести итоги, вот три дополнительных вопроса, которые следует задать потенциальному поставщику решений для патчинга:
То, что они не так бросаются в глаза в списках описаний продуктов поставщиков патчинговых служб, не делает функции, описанные в этой статье, менее важными. Любая из них может повлиять на ваше решение обратиться к конкретному поставщику. Каждая из них может напрямую влиять на эффективность и актуальность решения для вашей среды. Поскольку плата за подписку на сервер составляет от нескольких десятков в месяц до тысяч долларов США в год, при выборе решения для патчинга ядра Linux полезно быть внимательным.
В 1991 году произошли два не связанных между собой события, каждое из которых предвещало две совершенно разных свободы: конец Холодной Войны и рождение Linux.
Возможность патчинга ядра в реальном времени появилась в 2008 году, когда Linux был еще подростком. Сегодня, когда ядру Linux вот вот стукнет 30, патчинг в реальном времени тоже созрел и готов опровергнуть свою репутацию необязательного дополнения, которое просто «неплохо иметь в комплекте».
На это есть две причины. Во-первых, это доминирование Linux в качестве предпочтительной платформы для экономичного и универсального веб-хостинга: более половины всех известных веб-сайтов в настоящее время работают на Linux. Во-вторых, признание того, что патчинг в реальном времени — это не просто удобство; это также эффективный и малозатратный способ повышения безопасности системы Linux.
Ksplice, первое решение для патчинга ядра Linux в реальном времени, без особых усилий приобрело прибыльный статус после запуска, лишь укрепив свое лидерство, когда технологический гигант Oracle купил его в 2011 году. Сегодня это самая известная из пяти организаций, предлагающих услуги автоматических исправления безопасности для Linux. В алфавитном порядке это:
- Canonical Livepatch Service для Ubuntu.
- KernelCare для Ubuntu, Red Hat Enterprise Linux, Oracle Linux, Amazon Linux и остальных.
- Kpatch для Red Hat Enterprise Linux.
- Ksplice для Oracle Linux.
- SUSE Linux Enterprise Live Patching для SUSE Linux Enterprise.
Каждая компания продвигает свои услуги с использованием одних и тех же шаблонных ключевых слов, одних и тех же стандартных фраз, повторяемых до бесконечности. Я приведу вам самые популярные из них и то, как вы должны их понимать.
- Rebootless: обновляет ядро Linux без перезагрузки.
- Automated: проверяет и устанавливает обновления безопасности ядра без наблюдателя.
- Easy install: установка и настройка очень просты или вовсе не нужны.
- Fully supported: вам не нужно писать патчи самостоятельно. (Посмотрите на руководство по написанию патчей от Kpatch, чтобы понять почему это важно)
Не обращайте внимания на эти ослепляюще очевидные коммерческие доводы и вы обнаружите другие особенности, заслуживающие внимания, другие факторы, которые вы можете использовать, чтобы сравнить одну службу с другой. В этой статье рассматриваются некоторые из них, слегка приправленные утверждением и назиданием. Но сначала напомним, что такое live patching.
Что такое патчинг ядра Linux в реальном времени?
Ядро Linux содержит более 20 миллионов строк кода, написанных в основном (предположительно) людьми-программистами. Как и во всем программном обеспечении, в нем есть ошибки. В наш век повышенного внимания к кибербезопасности ошибки предполагают уязвимости. Чтобы решить эту проблему, производители Linux стараются как можно быстрее выпускать обновления для своих ядер. Системные администраторы Linux также стараются быстро реагировать, устанавливая эти обновления, составлять график работы становится сложнее. Это потому, что нет никакой закономерности для обнаружения уязвимостей. Вот несколько причин, почему:
- В любой момент времени используется много разных версий ядра Linux. Некоторые потребуют исправления; некоторые нет.
- Один патч может исправить множество проблем в ядре, или для одной проблемы может потребоваться серия патчей.
- Мейнтейнеры ядра Linux могут сгруппировать уязвимости с низкой степенью серьезности, выпустив для них один комбинированный патч позднее.
- Поставщики Linux могут предпочесть использовать свои собственные схемы оценки степени серьезности уязвимости. Таким образом, один поставщик исправит определенную уязвимость, а другой — нет.
Есть еще один момент, о котором редко упоминают: это инстинктивное отвращение системного администратора к остановке машины, вызывающая физический дискомфорт от необходимости сказать: «Сервер отключен на обслуживание».
Зачем нужна остановка сервера? Потому что обновление ядра не вступит в силу до перезагрузки. Если вы не перезагрузитесь — если отложите ее в долгий ящик или забудете, — вы окажетесь в затруднительном положении, потому что сервер без актуальных патчей является небезопасным. Позже мы поговорим об этой мантре подробнее, но суть ее такова:
Когда уязвимости становятся общедоступными, то же происходит и с их эксплойтами.
Или, говоря другими словами, у вас есть уязвимость, о которой вы не знали раньше, но теперь знаете. И все остальные тоже.
Спаситель в этом сценарии — установка исправлений в реальном времени (live patching). Это способ обновления не всего ядра Linux, а только его проблемной части. И делается это без остановки процессов или прерывания работы пользователей.
Однако есть ограничения. Патчинг ядра в реальном времени не может исправить все виды ошибок. Ошеломляющая сложность кода ядра и технические проблемы, связанные с изменением кода на лету, означают, что эта техника используется только для устранения критических проблем, обычно связанных с безопасностью.
Несмотря на это, система со средствами для установки патчей в реальном времени более безопасна, чем система без нее. Вот несколько вопросов, которые стоит задавать, когда вы ищете решение для патчинга в реальном времени:
1. Что внутри патча (и кто за ним стоит)?
Когда вы подписываетесь на услугу патчинга в реальном времени, вы платите больше, чем просто за само программное обеспечение. Это становится понятно, когда вы начинаете копаться в исходном коде ядра Linux и понимаете, как плохо написанный патч может нанести вред всей Linux системе.
Я упоминал ранее, что ядро - это огромный объем работы, которая, кажется, расширяется как по активности, так и по объему. Обратите внимание на рост количества строк кода в главной ветке репозитория ядра Linux. (Подсчет происходит по состоянию на 1 января каждого года. Учитываются только файлы и заголовки C/C++, файлы Python и Perl.)
С таким большим объемом кода писать патчи для ядра Linux — непростая задача. Требуется глубокое знакомство с архитектурой ядра и структурами данных. Требуется опыт работы с соглашениями о написании кода и стандартами качества сообщества Linux. И нужен особый талант, чтобы изобретать решения, не влияющие на функциональность, производительность и стабильность.
Есть два противоположных метода, которые производители исправлений используют для разработки и доставки патчей для ядра. Я называю их инкрементальным и монолитным.
Инкрементальные патчи, как шарик жевательной резинки, накладываются друг на друга, каждый из которых изменяет поведение предыдущего. Вы, как заказчик, должны отслеживать, какие патчи вы устанавливаете, а какие нет, а также порядок их установки. Невнимание к этим вопросам может привести к непредсказуемым изменениям в поведении вашей системы. Этот метод наложения патчей позволяет поставщикам быстро выпускать небольшие целевые патчи. Но со временем система может стать нестабильной до такой степени, что восстановить ее сможет только полное обновление ядра.
Монолитный патч — это патч, включающий все предыдущие патчи. По сути, есть только один мастер-патч, который заменяет активный, а не добавляется к нему. Такой подход делает платформу более стабильной, значительно увеличивая время безотказной работы сервера, которое часто измеряется тысячами дней.
2. Как долго ждать до следующего патча?
Между отчетом об уязвимости и ее исправлением неизбежна присутствует задержка. Требуется время, чтобы проанализировать ошибки ядра, и время, чтобы оценить их влияние. Требуются изобретательность и мастерство, чтобы найти решение, и масса тестов, чтобы убедиться, что оно работает. Затем его ждет обязательная проверка и утверждение в рамках процесса разработки Linux.
Задержки, которых можно избежать, случаются, когда поставщик Linux заменяет оценку серьезности сообщества своей собственной. Это означает, что поставщик может устранить несколько уязвимостей с помощью меньшего количества исправлений, но из-за этого заказчик в среднем дольше ждет исправления определенных проблем.
Администраторы Linux, которые понимают причины беспорядочного характера выпусков исправлений, не в большем выигрыше, чем те, что нет. Ни один из них не находит утешения в знании того, что пока они ждут патчей, их системы еще более уязвимы для эксплойта, чем они были до его обнаружения.
И вот почему: члены сообщества исследователей кибербезопасности любят объявлять об уязвимости вместе с наглядным примером использования. Обычно они принимают форму подтверждения концепции, подробного технического описания того, как воспроизвести ошибку или использовать эксплойт. Эти описания имеют честное намерение: помочь разработчикам ядра найти и залатать дыру. Но они также экономят хакерам много времени и усилий, давая им короткий путь к буквальному рецепту катастрофы в их гонке за использование уязвимости в качестве оружия.
3. Насколько серьезной должна быть ошибка?
Почти все вновь обнаруженные уязвимости получают идентификатор CVE. Позже, при более внимательном рассмотрении исследователей безопасности уязвимость получает оценку серьезности, то есть меру ее воздействия.
Важной схемой рейтинга является общая система оценки уязвимостей (CVSS — Common Vulnerability Scoring System). Она представляет уязвимость в виде набора чисел, каждое из которых является оценкой характеристики, например:
- Насколько это легко воспроизвести (использовать).
- Как сложно это исправить.
- Масштаб влияния на доступность серверов и сервисов.
- Важность или конфиденциальность открытых данных.
В полный комплект входит еще много подобных оценок. Алгоритм объединяет их в базовую оценку, одну аккуратную цифру, выражающую серьезность уязвимости в диапазоне от 0 (низкая) до 10 (высокая). CVSS второй версии делит диапазоны этих чисел на ключевые слова LOW, MEDIUM и HIGH. В новой версии CVSS 3 добавлены еще два: NONE и CRITICAL.
Таким образом, количество уязвимостей варьируется не только по месяцам и годам, но и по степени серьезности.
Схемы оценки уязвимости, такие как CVSS, дают поставщикам Linux возможность оценить, как реагировать на конкретную уязвимости ядра. Например, они могут захотеть написать исправления для уязвимостей с совокупным баллом 7 и выше. Это означает HIGH в CVSS v2, HIGH или CRITICAL в CVSS v3. Поставщик, утверждающий, что нацелен на критические уязвимости, может иметь в виду только уязвимости с рейтингами серьезности 9 и 10, если использует CVSS v3.
4. Могу ли я откатить патч?
Автоматическая установка исправлений без какого-либо надзора — страшная идея для многих системных администраторов. Они знают, что даже тщательно протестированные исправления могут изменить поведение системы, влияя на ее производительность или функциональность незаметным и не вполне очевидным образом. Когда это происходит, когда сервер ведет себя странно после установки патча, самый быстрый способ справиться с этим — удалить патч.
Некоторые сервисы патчинга в реальном времени могут удалять патчи. Это упрощает определение того, является ли недавнее обновление причиной изменений в поведении системы.
5. Могу ли я хостить свой собственный патч-сервер?
Агент ПО для патчинга в реальном времени проверяет наличие доступных исправлений на удаленных птач-серверах. Он делает это через регулярные настраиваемые интервалы, обычно с возможностью выполнения специальных проверок. Если патч доступен, программное обеспечение агента загрузит и установит его. Но если агент патчинга не может связаться с патч-сервером, где служба патчинга поставщика хранит патчи, патчинг в реальном времени не произойдет.
Чтобы решить эту проблему, нужно создать собственный патч-сервер. Такой локальный сервер транслирует патчи на все компьютеры вашей компании под вашим фаерволом. Средство безопасного копирования загружает патч и затем распространяет их через фаервол после проверки целостности файлов патчей. Вы можете управлять этим процессом и проверять его, когда вам удобно, сделав совет директоров вашей компании немного спокойнее.
Есть и другие преимущества:
- Вы лучше контролируете, какие патчи будут получать ваши серверы и когда.
- Вы можете заблокировать большое количество серверов для известных уровней патчей.
- Легче разделить кластеры серверов для разработки, тестирования, стейджинга и производства.
Для динамического патчинга необходимы локальный агент и удаленный патч-сервер. Контроль над обоими очень важен для развертываний в масштабах предприятия.
Заключение
Перед тем как подвести итоги, вот три дополнительных вопроса, которые следует задать потенциальному поставщику решений для патчинга:
- Могу ли я отменить автоматическое обновление? Бывают случаи, когда вы не хотите автоматически обновлять ядра.
- На каких платформах оно работает? Хотя ваша серверная среда может исключать любую гибкость при выборе решения для патчинга в реальном времени, лучше, если подписка на сервис не ограничивает, какой вариант Linux вам нужно использовать.
- Могу ли я запускать кастомные ядра? Не все используют стандартные ядра по умолчанию, предлагаемые основными поставщиками Linux. Некоторые специалисты разрабатывают и поддерживают пользовательские ядра для специального оборудования или сред с оптимизацией производительности. Им нужна служба патчинга в реальном времени, которая может взять на себя ответственность за предоставление патчей для пользовательских ядер.
То, что они не так бросаются в глаза в списках описаний продуктов поставщиков патчинговых служб, не делает функции, описанные в этой статье, менее важными. Любая из них может повлиять на ваше решение обратиться к конкретному поставщику. Каждая из них может напрямую влиять на эффективность и актуальность решения для вашей среды. Поскольку плата за подписку на сервер составляет от нескольких десятков в месяц до тысяч долларов США в год, при выборе решения для патчинга ядра Linux полезно быть внимательным.
Читать ещё:
Установка и настройка AlienVault SIEM (OSSIM)
10 практических рекомендаций по безопасности образов Docker. Часть 1
10 практических рекомендаций по безопасности образов Docker. Часть 2
