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



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

Здравствуйте, жители Хабро! Авторы шаг за шагом познакомят вас с основами и возможностями 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 И инструменты.

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. фильтр касается правил фильтрации (принятие, отклонение или игнорирование пакета); 2. nat (трансляция сетевых адресов) касается трансляции адресов источника или назначения и портов пакетов; 3. mangle относится к другим изменениям в IP-пакетах (включая поле и параметры ToS (Type of Service)); 4. raw позволяет вносить другие изменения в пакеты вручную до того, как они достигнут системы отслеживания соединений.

Каждая таблица содержит списки правил, называемые цепочками.

Межсетевой экран использует стандартные цепочки для обработки пакетов на основе заранее определенных условий.

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

Таблица фильтров содержит три стандартные цепочки: 1. INPUT – касается пакетов, целью которых является сам межсетевой экран; 2. ВЫХОД – относится к пакетам, исходящим от брандмауэра; 3. FORWARD — относится к пакетам, проходящим через брандмауэр (который не является ни их источником, ни местом назначения).

Таблица nat также имеет три стандартные цепочки: 1. PREROUTING — менять пакеты сразу после их поступления; 2. POSTROUTING - менять пакеты, когда они готовы к отправке; 3. ВЫХОД — для модификации пакетов, генерируемых самим межсетевым экраном.

Эти схемы показаны на рис.

7.1.

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

Каждая цепочка представляет собой список правил; Каждое правило представляет собой набор условий и действие, выполняемое при выполнении условий.

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

Наиболее распространенные типы поведения стандартизированы и для них предусмотрены конкретные действия.

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

Ниже приведены действия Netfilter. 1. ACCEPT — разрешить пакету двигаться дальше по своему маршруту.

2. ОТКЛОНЕНИЕ — отклонить пакет, используя пакет ошибок ICMP (протокол управляющих сообщений Интернета) (опция --reject-with type для iptables указывает тип ошибки, которую следует отклонить).

3. DROP – удалить (игнорировать) пакет. 4. LOG — Зарегистрируйте (через демон syslogd) сообщение, описывающее пакет. Обратите внимание, что это действие не прерывает обработку, и цепочка продолжается со следующего правила, поэтому для регистрации отклоненных пакетов требуется как правило LOG, так и правило REJECT/DROP. Общие варианты регистрации включают в себя:

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

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

6. Chain_name — перейти к указанной цепочке и оценить ее правила.

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

8. SNAT (только в таблице nat) — применить преобразование адресов исходной сети (SNAT).

Дополнительные параметры описывают точные изменения, которые необходимо применить, включая параметр --to-source адрес:порт, который указывает новый IP-адрес и/или порт источника.

9. DNAT (только в таблице nat) - применить назначение трансляции сетевых адресов (Destination Network Address Translation, DNAT).

Дополнительные параметры описывают точные изменения, которые следует использовать, включая параметр --to-destinationaddress:port, который указывает новый исходный IP-адрес и/или порт. 10. MASQUERADE (только в таблице nat) - применить маскирование (частный случай Source NAT).

11. REDIRECT (только таблица nat) — открыто перенаправить пакет на заданный порт на самом брандмауэре.

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

Опция --to-ports port(s) указывает порт или диапазон портов, на которые должны пересылаться пакеты.

Другие действия, особенно связанные с таблицей mangle, в этот подраздел не включены.

Полный их список вы найдете на страницах руководства iptables (8) и ip6tables (8).



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

Команды iptables и ip6tables используются для управления таблицами, цепочками и правилами.

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

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

1. -L цепочка печатает список правил, содержащихся в цепочке.

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

2. Цепочка -N создает новую цепочку.

Вы можете создавать новые каналы для различных целей, включая тестирование новой сетевой службы или отражение сетевой атаки.

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

4. -Правило цепочки добавляет правило в конец данной цепочки.

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

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 port и --destination-port port.

Отрицательные условия Добавление восклицательного знака перед условием означает, что оно отменено.

Например, отрицание опции -p означает «любой пакет с протоколом, отличным от указанного».

Этот механизм отрицания можно применить к любым другим условиям.

Условие -s адрес или -s сеть/маска соответствует исходному адресу пакета.

Соответственно, -d адрес или -d сеть/маска соответствуют адресу назначения.

Условие -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. Несколько контекстных меню позволяют изменить условие (например, запретить его).

Затем необходимо выбрать и настроить действие.



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

Для 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 может создавать отчеты с различными уровнями детализации: параноидальным, серверным и рабочей станцией.

Параноидальный режим очень многословен и, вероятно, его следует ограничить конкретными серверами, такими как брандмауэры.

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

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

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

Поскольку механизм выбора сообщений достаточно сложен, файл /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-extension. О системном событии сообщается всегда, если только правило в одном из каталогов /etc/logcheck/ignore.d.{paranoid, server, workstation}/ не указывает, что событие следует игнорировать.

Конечно, только Теги: #Настройка Linux #Профессиональная литература #книги #книги

Вместе с данным постом часто просматривают: