Перейти к содержанию книги Kali Linux Revealed
Как только вы начнете использовать Kali Linux для более конфиденциальной и высокопрофильной работы, вам, скорее всего, сразу понадобиться отнестись к безопасности вашей инсталляции намного серьезней. В этой главе мы вначале обсудим политику безопасности, выделим различные моменты, которые следует учитывать при определении подобного рода политики, и выделить некоторые угрозы для вашей системы и для вас как специалиста в сфере безопасности. Мы также обсудим меры безопасности для ноутбуков и десктопных систем, а также сосредоточимся на брандмауэрах и фильтрации пакетов. В частности, мы обсудим инструменты мониторинга и стратегии, а также покажем вам, как наилучшим образом реализовать их для обнаружения потенциальных угроз для вашей системы.
7.1 Определение политики безопасности Kali Linux
Нет никакого смысла обсуждать безопасность в общем, поскольку идея представляет собой широкий спектр понятий, инструментов и процедур, ни одна из которых не применяется повсеместно. Ваш выбор среди этого широкого спектра, в первую очередь, будет зависеть от поставленной вами задачи. Защита системы начинается с ответа на несколько вопросов. Стремление к внедрению произвольного набора инструментов сопряжено с риском сосредоточиться на неправильных аспектах безопасности.
Безусловно, всегда лучше определить конкретную цель. Грамотный подход, который поможет вам в этом заключается в постановки следующих вопросов:
- Что вы пытаетесь защитить? Политика безопасности будет отличаться в зависимости от того, хотите ли вы защитить компьютеры или данные. В последнем случае вам также необходимо знать, какие именно данные вы хотели бы защитить.
- От чего вы хотите защититься? Это может быть утечка информации или случайная потеря данных, возможно речь идет о потере дохода, вызванной нарушением работы служб.
- Также от кого вы хотите защититься? Меры безопасности будут совершенно разными, например, для защиты от случайной опечатки постоянным пользователем системы или же для защиты от определенной группы внешних злоумышленников.
Термин «риск» обычно используется для совместного обозначения этих трех факторов: что защитить, что нужно предотвратить, и кто должен это сделать. Моделируя риски вам в первую очередь необходимо ответить на три этих вопроса. На этой модели риска может быть построена политика безопасности, и далее эта политика может быть реализована путем принятия конкретных решений и выполнения последовательности определенных действий.
Неизменный вопрос
Брюс Шнайер (Bruce Schneier), мировой эксперт по вопросам безопасности (и не только по компьютерной безопасности), пытается противостоять одному из самых важных мифов в современной безопасности, используя девиз: «Безопасность — это процесс, а не продукт». Активы, которые нужно защищать, меняются со временем, и точно также меняются угрозы и средства, доступные потенциальным злоумышленникам. Даже если политика безопасности изначально была абсолютно грамотно разработана и реализована, вы никогда не должны останавливаться на достигнутом. Компоненты риска развиваются и меняются, и ответ на этот риск должен развиваться должным образом.
Кроме того, очень важно учитывать дополнительные ограничения, поскольку они могут ограничивать диапазон доступных политик. Важно понимать, насколько далеко вы готовы зайти для защиты собственной системы? Этот вопрос имеет большое значение для реализации политики. Слишком часто ответ определяется только с точки зрения денежных издержек, но также следует учитывать другие элементы, такие как количество неудобств, наложенных на пользователей системы или ухудшение производительности.
Как только основные риски будут смоделированы, вы сможете приступить к проектированию политики безопасности.
Есть крайности, с которыми вы можете столкнуться при принятии решения о необходимом уровне безопасности. С одной стороны, чрезвычайно просто обеспечить базовую безопасность системы.
Например, если система, которая должна быть защищена, представляет собой всего лишь подержанный компьютер, единственной задачей которого является добавление нескольких чисел в конце дня, то решение не делать ничего особенного для того, чтобы защитить его, является вполне себе разумным и адекватным. Внутреннее значение системы низкое, а значение данных равно нулю, так как они не хранятся на компьютере. Потенциальный злоумышленник, проникший в эту систему, получит только калькулятор. Стоимость обеспечения такой системы, вероятно, будет больше, чем стоимость её взлома.
С другой стороны, вы, возможно, захотите защитить конфиденциальность секретных данных самым всеобъемлющим путем, каким только возможно, забыв при этом о каких-либо других вопросах. В этом случае подходящим способом реализации вашей цели будет полное уничтожение данных (безопасное стирание файлов, измельчение жестких дисков в биты, затем растворение этих битов в кислоте и т. д.). Если есть дополнительное требование, которое заключается в том, что эти данные должны сохраниться в памяти для будущего использования (хотя и не быть всегда легко доступными), и если стоимость для вас по-прежнему не является весомым фактором, то оптимальным вариантом будет хранение данных в корпусе, состоящем из иридий-платиновых пластин, хранящемся в бомбонепроницаемых бункерах под разными горами в мире, каждый из которых (конечно же) и является полностью секретным и охраняется целыми армиями.
Возможно, эти примеры могут показаться вам очень гротескными, они, тем не менее, дают абсолютно адекватный ответ на определенные риски, поскольку они являются результатом мыслительного процесса, который в свою очередь рассматривает поставленные цели и ограничения, которые вы также учитываете.
Исходя из обоснованного решения, никакая политика безопасности не является более или менее достаточной, чем любая другая.
Возвращаясь к более типичному случаю, информационная система может быть сегментирована в последовательные и, в основном, независимые подсистемы. Каждая подсистема будет иметь свои собственные требования и ограничения, поэтому оценка риска и разработка политики безопасности должны проводиться отдельно для каждой подсистемы. Хороший принцип, который следует иметь в виду, состоит в том, что малую поверхность атаки намного легче защищать, чем большую. Сетевая организация также должна быть спроектирована следующим образом: уязвимые службы должны быть сконцентрированы на небольшом количестве машин, и эти машины должны быть доступны только через минимальное количество маршрутов или контрольных точек. Логика очень проста: легче защищать эти контрольные точки, чем защищать все уязвимые машины, содержащие конфиденциальную информацию, от всего внешнего мира. Именно в этот момент становится очевидной польза сетевой фильтрации (в том числе брандмауэрами). Эта фильтрация может быть реализована с помощью использования специального оборудования, но более простым и гибким решением является использование программного брандмауэра, интегрированного в ядро Linux.
Перейти к содержанию книги Kali Linux Revealed
Это интересно: