Pull to refresh

Книга «Kali Linux от разработчиков»

Reading time 19 min
Views 31K
image Привет, Хаброжители! Авторы шаг за шагом познакомят вас с основами и возможностями Kali Linux. В книге предложен краткий курс работы с командной строкой Linux и ее концепциями, описаны типичные сценарии установки Kali Linux. Прочитав эту книгу, вы научитесь конфигурировать, отлаживать и защищать Kali Linux, а также работать с мощным менеджером пакетов дистрибутива Debian. Научитесь правильно устанавливать Kali Linux в любых окружениях, в том числе в крупных корпоративных сетях. Наконец, вам предстоит познакомиться и со сложными темами: компиляцией ядра, созданием собственных образов ISO, промышленным шифрованием и профессиональной защитой конфиденциальной информации.


Глава 7. Защита и контроль Kali Linux


Как только вы начнете использовать Kali Linux для более конфиденциальных и высокопрофильных задач, вам, скорее всего, придется серьезнее отнестись к безопасности вашей установки. В этой главе мы вначале обсудим политику безопасности, выделив наиболее важные моменты при ее определении, и обратим внимание на некоторые угрозы для вашей системы и для вас как профессионала по безопасности. Мы также обсудим меры безопасности для ноутбуков и настольных систем и рассмотрим отдельно брандмауэры и фильтрацию пакетов. В завершение затронем инструменты и стратегии мониторинга и покажем наиболее эффективные способы их использования для обнаружения потенциальных угроз для вашей системы.

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


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

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

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

2. От чего вы пытаетесь защититься? От утечки конфиденциальных данных? От случайной потери информации? От убытка, вызванного сбоем в предоставлении услуг?

3. От кого вы пытаетесь защититься? Меры безопасности будут совершенно разными для защиты от опечатки простого пользователя системы и защиты от определенной группы злоумышленников.

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

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

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

Как только риск смоделирован, вы можете задумываться о разработке подходящей политики безопасности.

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

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

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

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

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

7.2. Возможные меры безопасности


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

На сервере

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

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

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

На ноутбуке

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

Реальный риск часто возникает, когда вы едете от одного клиента к другому. Например, ваш ноутбук может быть украден во время поездки или изъят таможенниками. Вот почему стоит использовать полное шифрование диска (см. подраздел «Установка на полностью зашифрованную файловую систему» раздела 4.2) и, возможно, также настроить функцию nuke (см. врезку «Установка пароля самоуничтожения для дополнительной безопасности» в главе 9): данные, которые вы собрали во время вашей работы, являются конфиденциальными и требуют максимальной защиты.

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

7.3. Защита сетевых сервисов


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

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

2. Некоторые сервисы не имеют учетных данных и позволяют устанавливать их при первом использовании; другие имеют стандартные (и, следовательно, широко известные) учетные данные. Убедитесь, что вы (пере)установили пароль, который известен только вам.

3. Многие сервисы выпускаются с правами root (с полными правами администратора), поэтому последствия несанкционированного доступа или нарушения безопасности обычно являются серьезными.

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

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

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

7.4. Брандмауэр или фильтрация пакетов


Брандмауэр — это часть компьютерного оборудования с аппаратным обеспечением, программным обеспечением или и тем и другим, которая анализирует входящие или исходящие сетевые пакеты (приходящие или исходящие из локальной сети) и пропускает только те, которые соответствуют определенным предварительно заданным условиям.

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

В ядро Linux встроен брандмауэр netfilter. Не существует единого решения для настройки любого брандмауэра, так как требования сети и пользователя разнятся. Тем не менее вы можете контролировать netfilter из пользовательского пространства с помощью команд iptables и ip6tables. Разница между последними заключается в том, что первая работает для сетей IPv4, тогда как вторая функционирует на IPv6. Поскольку оба стека сетевых протоколов, вероятно, будут работать в течение многих лет, то оба инструмента должны использоваться параллельно. Вы также можете применять отличную утилиту fwbuilder на основе графического интерфейса, который обеспечивает графическое представление правил фильтрации.

Однако если вы решили настроить netfilter (реализация брандмауэра Linux), то рассмотрим подробнее, как он работает.

Поведение сетевого фильтра Netfilter

Фильтр Netfilter использует четыре различные таблицы, в которых хранятся правила, регламентирующие три вида операций над пакетами:

1. filter касается правил фильтрации (принятие, отказ или игнорирование пакета);

2. nat (Network Address Translation — трансляция сетевых адресов) касается трансляции исходных или целевых адресов и портов пакетов;

3. mangle относится к другим изменениям в IP-пакетах (включая поле ToS (Type of Service — тип сервиса) и опции);

4. raw допускает другие изменения в пакетах, проведенные вручную, до того как они (пакеты) достигнут системы отслеживания соединения.

Каждая таблица содержит списки правил, называемые цепями. Брандмауэр использует стандартные цепи для обработки пакетов на основе предопределенных условий. Администратор может создавать другие цепи, которые будут применяться только при передаче одной из стандартных цепей (прямо или косвенно).

Таблица filter содержит три стандартные цепи:

1. INPUT — касается пакетов, целью которых является сам брандмауэр;

2. OUTPUT — относится к пакетам, исходящим от брандмауэра;

3. FORWARD — относится к пакетам, проходящим через брандмауэр (который не является ни их источником, ни местом назначения).

Таблица nat также имеет три стандартные цепи:

1. PREROUTING — для изменения пакетов сразу после их поступления;

2. POSTROUTING — для изменения пакетов, когда они готовы к отправке;

3. OUTPUT — для изменения пакетов, сгенерированных самим брандмауэром.

Эти цепи изображены на рис. 7.1.

image

Каждая цепь представляет собой список правил; каждое правило есть набор условий и действие, выполняемое при выполнении условий. При обработке пакета брандмауэр сканирует соответствующую цепь, одно правило за другим, и когда условия для одного правила выполняются, перескакивает (jump) (отсюда параметр -j в командах) к указанному действию для продолжения обработки. Наиболее распространенные типы поведения стандартизированы, и для них существуют специальные действия. Выполнение одного из этих стандартных действий прерывает обработку цепочки, поскольку дальнейшая судьба пакетов уже предрешена (не принимая во внимание исключение, упомянутое ниже). Далее перечислены действия Netfilter.

1. ACCEPT (ПРИНЯТЬ) — разрешить пакету двигаться далее по своему маршруту.

2. REJECT (ОТКЛОНИТЬ) — отклонить пакет с помощью пакета ошибок ICMP (Internet control message protocol — протокол межсетевых управляющих сообщений) (параметр --reject-with тип для iptables определяет тип ошибки для отклонения).

3. DROP (СБРОСИТЬ) — удалить (игнорировать) пакет.

4. LOG (ЗАРЕГИСТРИРОВАТЬ) — зарегистрировать (через демон syslogd) сообщение с описанием пакета. Обратите внимание, что это действие не прерывает обработку, а выполнение цепи продолжается со следующего правила, поэтому регистрация отклоненных пакетов требует как правила LOG, так и REJECT/DROP. Общие параметры, связанные с регистрацией, включают:

  • --log-level, с предупреждением по умолчанию, указывает уровень серьезности syslog;
  • --log-prefix позволяет указать префикс текста, чтобы различать зарегистрированные сообщения;
  • --log-tcp-sequence, --log-tcp-options и --log-ip-options обозначают дополнительные данные, которые должны быть помещены в сообщение: порядковый номер TCP, параметры TCP и параметры IP соответственно.

5. ULOG — зарегистрировать сообщение через ulogd, который может быть лучше адаптирован и более эффективен, чем syslogd для обработки большого количества сообщений; обратите внимание, что это действие, подобно LOG, также возвращает обработку к следующему правилу в вызывающей цепи.

6. имя_цепи — перейти к указанной цепи и оценить ее правила.

7. RETURN (ВЕРНУТЬ) — прервать обработку текущей цепи и вернуться к вызывающей цепочке; если текущая цепочка является стандартной, то вызывающей цепочки нет, поэтому вместо нее выполняется действие по умолчанию (определенное с помощью параметра -P для iptables).

8. SNAT (только в таблице nat) — применить источник трансляции сетевых адресов (Source Network Address Translation, SNAT). Дополнительные параметры описывают точные изменения, которые нужно применить, включая параметр --to-source адрес: порт, который определяет новый источник IP-адреса и/или порта.

9. DNAT (только в таблице nat) — применить назначение трансляции сетевых адресов (Destination Network Address Translation, DNAT). Дополнительные параметры описывают точные изменения, которые нужно использовать, включая параметр --to-destination адрес: порт, который определяет новый источник IP-адреса и/или порта.

10. MASQUERADE (МАСКИРОВКА) (только в таблице nat) — применить маскировку (особый случай Source NAT).

11. REDIRECT (ПЕРЕНАПРАВЛЕНИЕ) (только в таблице nat) — открыто перенаправить пакет в данный порт самого брандмауэра. Можно использовать для настройки открытого сервера веб-прокси, который работает без конфигурации на стороне клиента, и в то время, когда клиент считает, что подключается к получателю, фактически сообщения проходят через прокси-сервер. Параметр --to-ports порт(-ы) указывает порт или диапазон портов, куда должны быть перенаправлены пакеты.

Другие действия, особенно те, которые касаются таблицы mangle, не вошли в данный подраздел. Их полный список вы найдете на страницах руководств iptables (8) и ip6tables (8).

Синтаксис команд iptables и ip6tables


Команды iptables и ip6tables используются для управления таблицами, цепями и правилами. Их параметр -t table указывает, с какой таблицей работать (по умолчанию таблица filter).

Команды

Ниже перечислены основные параметры для взаимодействия с цепями.

1. -L цепь выводит список правил, содержащихся в цепи. Используется вместе с параметром -n для отключения разрешения имен (например, iptables -n -L INPUT выводит правила, относящиеся ко входящим пакетам).

2. -N цепь создает новую цепь. Вы можете создавать новые цепи для целого ряда целей, включая тестирование нового сетевого сервиса или отражение сетевой атаки.

3. -X цепь удаляет пустую и неиспользуемую цепь (например, iptables -X ddos-attack).

4. -A цепь правило добавляет правило в конце заданной цепи. Помните, правила обрабатываются сверху вниз, не забывайте учитывать этот момент при добавлении правил.

5. -I цепь номер_правила правило вставляет правило перед правилом с указанным номером. Как и в параметре -A, учитывайте порядок обработки при вводе новых правил в цепь.

6. -D цепь номер_правила (или -D цепь правило) удаляет правило в цепи; первый синтаксис указывает, что правило под определенным номером должно быть удалено (команда iptables -L --line-numbers выводит на экран номера правил), а второй идентифицирует правило к удалению по его сути.

7. -F цепь сбрасывает цепь (удаляет все ее правила). Например, чтобы удалить все правила, связанные с исходящими пакетами, вы должны ввести команду iptables -F OUTPUT. Если ни одна цепь не указана, то удаляются все правила в таблице.

8. -P цепь действие определяет действие по умолчанию или «политику» для данной цепи. Обратите внимание: такая политика присуща только для стандартных цепей. Чтобы удалить весь входящий трафик по умолчанию, вы должны выполнить команду iptables -P INPUT DROP.

Правила

Каждое правило задается в соответствии со следующим синтаксисом: условия -j действие параметры_действия. Если в одном правиле описано несколько условий, то критерием является объединение (логическое И) условий, которое обладает ограничением, по меньшей мере таким же, как и каждое отдельно взятое условие.

Условие -p протокол соответствует полю протокола IP-пакета. Наиболее распространенными значениями являются tcp, udp, icmp и icmpv6. Это условие можно дополнить условиями касательно TCP-портов с помощью параметров --source-port порт и --destination-port порт.

Отрицательные условия

Добавление восклицательного знака перед условием означает его отрицание. Например, отрицание условия по параметру -p означает «любой пакет с протоколом, отличным от того, который указан». Этот механизм отрицания можно применять к любым другим условиям.

Условие -s адрес или -s сеть/маска соответствует исходному (source) адресу пакета. Соответственно, -d адрес или -d сеть/маска соответствует адресу назначения (destination).
Условие -i интерфейс выбирает пакеты, исходящие из заданного сетевого интерфейса; -o интерфейс — пакеты, выходящие на определенный интерфейс.

Условие --state статус соответствует статусу пакета в соединении (для этого требуется модуль ядра ipt_ conntrack для отслеживания соединения). Статус NEW описывает пакет, запускающий новое соединение, статус ESTABLISHED соответствует пакетам, принадлежащим к уже существующему соединению, и статус RELATED соответствует пакетам, инициирующим новое соединение, связанное с существующим (что полезно для соединений ftp-данных в активном режиме протокола FTP).

Существует множество доступных параметров для iptables и ip6tables, и для их освоения потребуется немало времени. Однако один из них, который вы будете использовать чаще всего, — это параметр, блокирующий вредоносный сетевой трафик с хоста или диапазона хостов.
Например, чтобы незаметно блокировать входящий трафик с IP-адреса 10.0.1.5 и 31.13.74.0/24 класса C подсети, нужно выполнить ряд команд:

# iptables -A INPUT -s 10.0.1.5 -j DROP
# iptables -A INPUT -s 31.13.74.0/24 -j DROP
# iptables -n -L INPUT
Chain INPUT (policy ACCEPT)
target        prot opt source                  destination
DROP         all -- 10.0.1.5                   0.0.0.0/0
DROP         all -- 31.13.74.0/24           0.0.0.0/0

Другая команда iptables часто применяется с целью разрешения сетевого трафика для определенного сервиса или порта. Чтобы пользователи могли подключаться к SSH, HTTP и IMAP, вы должны выполнить следующие команды:

# iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
# iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
# iptables -n -L INPUT
Chain INPUT (policy ACCEPT)
target        prot opt source                 destination
DROP         all -- 10.0.1.5                  0.0.0.0/0
DROP         all -- 31.13.74.0/24          0.0.0.0/0
ACCEPT      tcp -- 0.0.0.0/0                0.0.0.0/0 state NEW tcp dpt:22
ACCEPT      tcp -- 0.0.0.0/0                0.0.0.0/0 state NEW tcp dpt:80
ACCEPT      tcp -- 0.0.0.0/0                0.0.0.0/0 state NEW tcp dpt:143

Правилом хорошей компьютерной гигиены является очистка старых и ненужных правил. Самый простой способ удалить правило iptables — ссылаться на правила по номеру строки, которые вы можете получить с помощью параметра --line-numbers. Будьте внимательны: при сбросе правила все последующие правила в цепочке будут перенумерованы.

# iptables -n -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num    target    prot    opt    source               destination
1        DROP     all       --      10.0.1.5            0.0.0.0/0
2        DROP     all       --      31.13.74.0/24    0.0.0.0/0
3        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0      state NEW tcp dpt:22
4        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0      state NEW tcp dpt:80
5        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0      state NEW tcp dpt:143
# iptables -D INPUT 2
# iptables -D INPUT 1
# iptables -n -L INPUT  --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0       state NEW tcp dpt:22
2        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0       state NEW tcp dpt:80
3        ACCEPT  tcp      --      0.0.0.0/0           0.0.0.0/0       state NEW tcp dpt:143

Существуют более специфические условия, зависящие от общих условий, описанных выше. Для получения дополнительной информации обратитесь к руководствам iptables (8) и ip6tables (8).

Создание правил


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

# apt install fwbuilder

Принцип прост. На первом этапе опишите все элементы, которые будут задействованы в новых правилах:

1. сам брандмауэр с его сетевыми интерфейсами;

2. сети с соответствующими диапазонами IP-адресов;

3. серверы;

4. порты, принадлежащие службам, размещенным на серверах.

Затем создайте правила с помощью простых действий перетаскивания объектов, как показано на рис. 7.2. Несколько контекстных меню могут изменить условие (например, отрицать его). Затем нужно выбрать и настроить действие.

image

Что касается IPv6, то вы можете либо создать два разных набора правил для IPv4 и IPv6, либо создать только одно и позволить fwbuilder преобразовывать правила в соответствии с адресами, назначенными объектам.

Инструмент fwbuilder создаст сценарий, настраивающий брандмауэр в соответствии с правилами, которые вы определили. Его модульная архитектура позволяет генерировать сценарии, предназначенные для разных систем, включая iptables для Linux, ipf для FreeBSD и pf для OpenBSD.

Установка правил при каждой загрузке


Чтобы внедрять правила брандмауэра при каждой загрузке машины, вам необходимо зарегистрировать сценарий конфигурации в директиве up файла /etc/network/interfaces. В следующем примере сценарий хранится в /usr/local/etc/arrakis.fw.

auto eth0
iface eth0 inet static
     address 192.168.0.1
     network 192.168.0.0
     netmask 255.255.255.0
     broadcast 192.168.0.255
     up /usr/local/etc/arrakis.fw

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

7.5. Мониторинг и протоколирование


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

В этом разделе мы рассмотрим ряд инструментов, которые можно использовать для мониторинга нескольких аспектов системы Kali.

Мониторинг журналов с помощью программы logcheck


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

Список контролируемых файлов хранится по адресу /etc/logcheck/logcheck.logfiles. Значения по умолчанию будут работать должным образом, если файл /etc/rsyslog.conf не был полностью перестроен.

Программа logcheck может отчитываться, используя разные уровни детализации: paranoid (параноидальный), server (серверный) и workstation (для рабочих станций). Режим paranoid очень многословен и, вероятно, должен быть ограничен конкретными серверами, такими как брандмауэры. Режим server используется по умолчанию и рекомендуется для большинства серверов. Режим workstation, очевидно, предназначен для рабочих станций и чрезвычайно сжат, отфильтровывая больше сообщений, чем другие «собратья».

Во всех трех случаях logcheck, вероятно, должен быть настроен для исключения дополнительных сообщений (в зависимости от установленных сервисов), если вы не хотите получать ежечасные партии длинных незарегистрированных электронных писем. Поскольку механизм выбора сообщений довольно сложный, то файл /usr/share/doc/logcheck-database/README.logcheck-database.gz обязателен к прочтению при возникновении сложностей.

Применяемые правила можно разделить на несколько типов:

1. те, которые квалифицируют сообщение как попытку взлома (хранятся в файле в каталоге /etc/logcheck/cracking.d/);

2. проигнорированные попытки взлома (/etc/logcheck/cracking.ignore.d/);

3. те, которые классифицируют сообщение как предупреждение системы безопасности (/etc/logcheck/violations.d/);

4. проигнорированные предупреждения системы безопасности (/etc/logcheck/violations.ignore.d/);

5. наконец те, которые применяются к остальным сообщениям (рассматриваются как системные события).

Файлы ignore.d используются (очевидно) для игнорирования сообщений. Например, сообщение, помеченное как попытка взлома или предупреждение системы безопасности (по правилу, хранящееся в файле /etc/logcheck/violations.d/myfile), может быть проигнорировано только правилом в файле /etc/logcheck/violations.ignore.d/myfile или в файле /etc/logcheck/changes.ignore.d/myfile-расширение.

О системном событии всегда сообщается, если только правило в одном из каталогов /etc/logcheck/ignore.d.{paranoid, server, workstation}/ не указывает, что это событие следует игнорировать. Разумеется, учитываются лишь те каталоги, чьи уровни детализации равняются выбранному режиму работы или превышают его.

Мониторинг активности в режиме реального времени


Интерактивный инструмент top отображает список процессов, запущенных в данный момент. Сортировка по умолчанию основана на текущей загруженности процессора и может быть получена с помощью ключа P. Другие сортировки указаний содержат сортировку по занятой памяти (ключ М), общему времени процессора (ключ Т) и идентификатору процесса (ключ N). Ключ k завершает процесс с введенным идентификатором. Ключ r изменяет приоритет процесса.

Когда система кажется перегруженной, top — отличный инструмент, позволяющий увидеть, какие процессы конкурируют за процессорное время или потребляют слишком много памяти. Так, часто бывает интересно проверить, соответствуют ли процессы, потребляющие ресурсы, реальным сервисам, которые должны быть размещены на компьютере. Неизвестный процесс, работающий как www-data, должен действительно выделяться из списка, и его следует изучить, поскольку он, вероятнее всего, является примером программного обеспечения, установленного и выполняемого в системе с помощью уязвимости в веб-приложении.

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

Графический инструмент gnome-system-monitor похож на top и обеспечивает выполнение примерно тех же функций.

» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 20% по купону — Linux
Tags:
Hubs:
+10
Comments 9
Comments Comments 9

Articles

Information

Website
piter.com
Registered
Founded
Employees
201–500 employees
Location
Россия