Pull to refresh
2462.94
RUVDS.com
VDS/VPS-хостинг. Скидка 15% по коду HABR15

Kali Linux: политика безопасности, защита компьютеров и сетевых служб

Reading time 8 min
Views 51K
Original author: Коллектив авторов
→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы

Недавно мы задавали сообществу Хабра вопрос о целесообразности перевода книги «Kali Linux Revealed». Поразмыслив, приняв к сведению результаты голосования и комментарии к материалу, мы решили перевести некоторые части книги. Начнём с главы 7: «Защита и мониторинг Kali». В частности, в этом материале приведён перевод разделов 7.1-7.3, которые посвящены политике безопасности системы, защите серверов, ноутбуков и сетевых служб.



Глава 7. Защита и мониторинг Kali


Как только вы начнёте использовать Kali Linux во всё более ответственных и масштабных проектах, вам, вероятно, потребуется серьёзнее относиться к вашей собственной системе. Эту главу мы начнём с разговора о политиках безопасности.

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

7.1. Определение политики безопасности


Нет смысла говорить о безопасности в общих чертах, так как понятие «безопасность» складывается из широкого спектра концепций, инструментов и процедур, которые неприменимы во всех без исключения ситуациях. Выбор именно того, что нужно, требует наличия чёткого понимания целей того, кто собирается нечто защитить. Защита системы начинается с ответов на несколько вопросов. Бросившись очертя голову внедрять первые попавшиеся средства обеспечения безопасности, любой рискует уделить внимание не тому, что на самом деле важно.

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

  • Что вы пытаетесь защитить? Политика безопасности будет различаться в зависимости от того, хотите вы защитить компьютеры или данные. В последнем случае, кроме того, нужно точно знать — что это за данные.
  • От чего вы защищаетесь? Это утечка конфиденциальных данных? Случайная потеря данных? Потеря доходов, вызванная сбоем в работе некоей службы?
  • От кого вы защищаетесь? Меры безопасности будут сильно различаться, например, при защите от ошибки обычного пользователя системы и при защите от серьёзно настроенной внешней группы хакеров.

Термин «риск» обычно используется при упоминании всех этих трёх факторов: что защищать, что именно нужно предотвратить, и кто может это вызвать. Моделирование риска требует ответов на три вышеприведённых вопроса. Политику безопасности можно создать исходя из построенной модели рисков, после чего её можно реализовать путём выполнения конкретных действий.

▍Безопасность — это процесс


Брюс Шнайер, всемирно известный эксперт по безопасности (причём, не только по компьютерной ), пытается бороться с одним из важнейших мифов в области безопасности, заявляя: «Безопасность — это процесс, а не результат». То, что защищают, меняется со временем, то же самое происходит и с угрозами, и с инструментами, которые доступны потенциальным атакующим. Даже если политика безопасности изначально была идеально спроектирована и реализована, никогда не следует довольствоваться достигнутым. Компоненты рисков развиваются и ответные меры должны развиваться соответствующим образом.

Формируя политику безопасности, стоит принять во внимание дополнительные ограничения, так как они могут сузить диапазон доступных средств. Как далеко вы готовы пойти для того, чтобы защитить систему? Этот вопрос имеет решающее воздействие на принятие решения о том, что именно надо сделать. Слишком часто ответ на него выражается лишь в терминах стоимости, но нужно учитывать и другие аспекты. Среди них — усложнение работы пользователей или падение производительности.

После завершения моделирования рисков можно начинать размышлять о разработке самой политики безопасности.

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

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

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

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

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

Вернёмся к более типичным случаям. Информационная система может быть разбита на однородные, и, в основном, независимые подсистемы. Каждая подсистема будет характеризоваться собственными требованиями и ограничениями. В результате, анализ рисков и разработку структуры политики безопасности следует выполнять отдельно для каждой из этих подсистем. Тут есть один ценный принцип, о котором важно помнить, работая над политикой безопасности: маленькую поверхность атаки легче защитить, чем большую. Сеть тоже должна быть организована соответствующим образом. Особо важные службы должны быть собраны на небольшом количестве компьютеров, доступных через минимальное количество маршрутов или контрольных точек. За этим стоит ясная логика: легче защитить эти контрольные точки, чем защищать ценные компьютеры от всего внешнего мира. Именно в такой ситуации становится очевидной полезность сетевой фильтрации (включая ту, что выполняется файрволами). Фильтрацию можно реализовать на базе выделенного аппаратного обеспечения, но более простое и гибкое решение заключается в использовании программных файрволов, таких, как тот, что интегрирован в ядро Linux.

7.2. О мерах безопасности


Как было сказано в предыдущем разделе, нет единственно верного ответа на вопрос о том, как защитить Kali Linux. Всё зависит от того, как вы её используете и что именно вы пытаетесь защитить.

▍7.2.1. Защита сервера


Если вы используете Kali Linux на общедоступном сервере, вам, скорее всего, нужно будет защитить сетевые службы, изменив стандартные пароли, которые могут быть заданы в конфигурационных файлах (подробнее об этом — в разделе 7.3., «Защита сетевых служб»), и, возможно, путём ограничения доступа к ним с помощью файрвола (подробнее об этом — в разделе 7.4., «Файрвол или фильтрация пакетов».

Если вы выдаёте другим пользователям учётные записи либо на самом сервере, либо на одной из служб, нужно проверить, чтобы к ним были установлены стойкие ко взлому пароли, такие, которые способны выдержать атаку методом грубой силы. В то же время, может быть целесообразной установка fail2ban, что усложнит взлом паролей брутфорсом по сети (путём фильтрации IP-адресов, с которых превышено ограничение на неудачные попытки входа в систему). Для того, чтобы установить fail2ban, выполните следующие команды:

apt update
apt install fail2ban

Если вы поддерживаете веб-службы, вероятно, вам стоить организовать доступ к ним по HTTPS для того, чтобы не дать злоумышленнику анализировать ваш трафик (который может содержать аутентификационные куки-файлы).

▍7.2.2. Защита ноутбука


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

Реальный риск часто возникает, когда вы переезжаете от одного клиента к другому. Например, ваш ноутбук могут украсть в пути, его могут конфисковать на таможне. Именно поэтому вам, скорее всего, стоит использовать полное шифрование диска (подробнее об этом — в разделе 4.2.2., «Установка на полностью зашифрованную файловую систему»), и, возможно, настроить функцию самоуничтожения (подробнее об этом — в разделе «Установка пароля самоуничтожения для повышения уровня безопасности»). Данные, которые вы собрали в ходе исследования, конфиденциальны, они нуждаются в самой лучшей защите.

Кроме того, вам могут понадобиться задать правила файрвола (подробнее об этом — в разделе 7.4., «Файрвол или фильтрация пакетов»), но не для той же цели, что и на сервере. Вероятно, вы сочтёте нужным заблокировать весь исходящий трафик за исключение того, который генерирует ваш VPN. Это означает организацию безопасного сетевого взаимодействия. Если, например, ваше VPN-соединение перестанет работать, вы немедленно об этом узнаете (вместо переключения на локальный доступ к сети). В результате, вы не разглашаете IP-адреса вашего клиента, просматривая веб-сайты или делая что-то другое в интернете. В дополнение к этому, если вы выполняете локальную внешнюю проверку, лучше оставлять под контролем всё, что вы делаете для того, чтобы уменьшить «шум», который вы создаёте в сети, который может привлечь внимание пользователей и их систем защиты.

7.3. Защита сетевых служб


Рекомендуется отключить неиспользуемые сетевые службы. В Kali большинство сетевых служб отключено по умолчанию.

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

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

▍О стандартных учётных записях


Мы не будем перечислять здесь все программы, которые, после установки, оказываются настроенными на использование стандартных учётных данных. Для того, чтобы выяснить подробности о соответствующем пакете, стоит посмотреть его файл README.Debian, а также поискать информацию на docs.kali.org и tools.kali.org для того, чтобы выяснить, нуждается ли некоторая служба в особых действиях для обеспечения её безопасности.

Если вы пользуетесь системой в Live-режиме, пароль для учётной записи «root» — «toor». В результате, не следует включать SSH до изменения пароля к учётной записи root, или до настройки её конфигурации на запрет подключений с использованием пароля.

Кроме того, обратите внимание на то, что программа BeEF (из уже установленного пакета beef-xss) имеет учётные данные по умолчанию в виде пользователя «beef» и пароля «beef», которые записаны в стандартном конфигурационном файле.

Итоги


В этом материале вы ознакомились с некоторыми соображениями, которые касаются формирования политики безопасности системы, узнали о подходах к защите серверов, ноутбуков и сетевых служб. В следующий раз мы поделимся с вами переводом раздела 7.4., который посвящён файрволу и фильтрации пакетов в Kali LInux.

Уважаемые читатели! Как вы подходите к формированию политики безопасности? Как защищаете компьютеры различного назначения?
Tags:
Hubs:
+23
Comments 1
Comments Comments 1

Articles

Information

Website
ruvds.com
Registered
Founded
Employees
11–30 employees
Location
Россия
Representative
ruvds