Уязвимости в программном коде и методы противостояния им

Если гора не идет к Магомету, то Магомет сам идет к горе (крылатая фраза).

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

Первым бастионом на пути злоумышленника являются брандмауэры и прокси-сервера, ограничивающие доступ к потенциально уязвимым сервисам на основе Access Control Lists (ACL). Для защиты сервисов от некорректно сформированных пакетов применяется нормализация трафика. Крайне важно, чтобы настройкой списков контроля доступа занимался человек хорошо понимающий принципы их работы и специфику защищаемых сервисов.

Тем не менее, эти механизмы практически не спасают в ситуациях, когда следует обеспечить безопасность общедоступного сервиса использующего разрешенный порт и протокол, такого как DNS, web-сайт, ftp-сервер, почтовая система или B2B-система.

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

Следующей категорией идут механизмы, предназначенные для ограничения возможностей злоумышленника в случае успешной эксплуатации уязвимостей. Рассмотрим эти механизмы на примере операционных систем Linux и FreeBSD.

Весьма эффективным является Mandatory Access Control (MAC) во FreeBSD, он позволяет реализовать различные уровни секретности по аналогии с тем, как это организовано у спецслужб, то есть данные подразделяются на совершенно секретные, секретные, конфиденциальные и несекретные и сотрудники (а в нашем случае программы) в зависимости от принадлежности к подразделению и назначенного им уровня допуска имеют или нет к ним доступ.

В Linux есть две аналогичные (конкурирующие) технологии:

Стремительно набирает популярность Apparmor — программный инструмент упреждающей защиты, основанный на политиках безопасности (известных также как профили для приложений), которые определяют, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. в AppArmor включён набор стандартных профилей, а также инструменты статического анализа и инструменты, основанные на обучении, позволяющее ускорить и упростить построение новых профилей.

Традиционным средством изоляции процессов является подмена для них корневого каталога (chroot), что позволяет изолировать сервисы друг от друга в случае взлома одного из них. При использовании этой техники, процессы не должны иметь полномочий суперпользователя, т. к., в противном случае, злоумышленник сможет воспользоваться second chroot чтобы выйти из chroot, поэтому для сервисов требующих административных привилегий целесообразно использовать средства виртуализации на уровне ОС, такие как Jail во FreeBSD и OpenVZ/LXC в Linux.

Цель каждой из вышеописанных технологий — не дать злоумышленнику насладиться победой, даже если ему удалось воспользоваться уязвимостью одного из сервисов. Данный подход хорош, но профессионалы в области защиты информации пошли дальше, так появлись GRSecurity и PaX. Это патчи к ядру Linux делающие невозможной эксплуатацию 60-70% уязвимостей, путем:

  • контроля

  • запрета исполнения в сегменте

    • данных

    • кучи

    • стека

  • запрета доступа к процессам других пользователей

  • запрета second chroot

  • рандомизации адресного пространства

Данный механизм (ядро c его поддержкой называется Hardened-ядром, впервые реализованным для Gentoo Linux) позволяет эффективно противостоять многочисленным атакам основанным на переполнении буфера и некоторым другим типам атак, но он требует чтобы сами приложения были написаны аккуратно, что делает его практически неприменимым на десктопах и ограниченно применимым на серверах, т. к. разработчики далеко не всегда достаточно аккуратны даже при создании сетевых демонов. Таким образом, несмотря на свою крайне высокую эффективность Hardened-ядро не применимо в 70% случаев из-за неаккуратного программирования присущего многим opensource-разработчикам.

Чтобы усугубить, картину хотелось бы обратить Ваше внимание на то, что не смотря на многообразие защитных механизмов не все из них совместимы между собой, так например, придется выбирать между Hardened-ядром (с поддержкой RBAC), SELinux или AppArmor, так как это конкурирующие технологии. Точно также, OpenVZ не тестировался на совместную работу с AppArmor и SELinux.

Не меньшее влияние на применимость защитных механизмов оказывает прикладное ПО, так почти все популярные Web-панели написанные на PHP (например ISPConfig) не дружат c AppArmor или SELinux, а JIT-компилятор для Python’a не совместим c Hardened-ядром.

Если подвести итоги, то специалист по безопасности UNIX-систем должен знать все средства обеспечения безопасности доступные на используемой им платформе и уметь выбрать наилучшее их сочетание для решаемой им задачи. Курс «UNIX (Ubuntu Linux/FreeBSD). Уровень 3. Обеспечение безопасности UNIX» предназначен для того, чтобы сориентировать системного администратора или офицера по безопасности в доступном ему инструментарии и получить навыки применения этих инструментов для построение периметровой защиты на всех 4-х уровнях

Запись опубликована в рубрике Без рубрики, Публикации. Добавьте в закладки постоянную ссылку.

Один комментарий: Уязвимости в программном коде и методы противостояния им

  1. sergio говорит:

    Ближайшая группа по курсу «UNIX (Ubuntu Linux/FreeBSD). Уровень 3. Обеспечение безопасности UNIX» стартует 26.11.2011 и будет идти по субботам.

Добавить комментарий