Введение
В предыдущих лабораторных работах вы открывали и закрывали «двери» — порты — для всех пользователей. Но что, если вы хотите открыть дверь только для друга или закрыть её именно для известного нарушителя?
Здесь пригодятся расширенные правила. Они позволяют не просто открыть или закрыть службу целиком, а задавать более точную политику: проверять адрес источника, вести журнал событий или отклонять определённый трафик.
Это важно, потому что реальные политики брандмауэра часто зависят от условий. Решения по безопасности редко сводятся только к вариантам «порт открыт» или «порт закрыт».
Примечание о среде лабораторной работы: чтобы вы случайно не потеряли доступ к веб-терминалу, по умолчанию мы будем использовать зону trusted. Это означает, что весь трафик разрешён, пока мы явно его не заблокируем. В реальной рабочей среде следует использовать более строгую зону, например public или drop.
В этой лабораторной работе вы научитесь:
- Блокировать конкретных пользователей: отклонять подключения с определённого IP-адреса.
- Вести записи: регистрировать попытки подключения, чтобы видеть, кто пытался получить доступ.
- Ограничивать доступ: настраивать правило, разрешающее удалённое управление (SSH) только из определённой сети.
- Проводить аудит: сохранять правила в файл для последующей проверки.
Блокировка определённого IP-адреса
Сначала научимся блокировать конкретного нарушителя. Предположим, вы заметили, что компьютер с адресом 192.168.1.100 пытается взломать вашу систему. Вы хотите полностью заблокировать его.
Для этого мы используем «расширенное правило». Хотя наша зона по умолчанию — trusted и разрешает весь трафик, специальное правило Reject будет иметь приоритет для этого IP-адреса.
Расширенные правила важны, потому что реальная политика брандмауэра часто зависит от условий. Вам может понадобиться разное поведение в зависимости от адреса источника, службы, необходимости ведения журнала или других критериев, которые обычные команды открытия и закрытия не позволяют точно выразить.
Синтаксис похож на составление предложения: rule family="ipv4" source address="192.168.1.100" reject
Выполните следующую команду, чтобы добавить это правило в постоянную конфигурацию.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" reject'
Разберём это «предложение»:
rule family="ipv4": правило относится к стандартным IP-адресам.source address="...": адрес нарушителя.reject: выполняемое действие.
Разница между Reject и Drop:
- Reject — вежливый вариант: отправитель получает сообщение «Доступ запрещён».
- Drop — жёсткий вариант: система полностью игнорирует отправителя, как будто компьютера не существует.
Выбор между ними — не просто вопрос стиля. reject быстрее сообщает результат легитимным клиентам и упрощает устранение неполадок, а drop раскрывает злоумышленнику меньше информации, но может привести к более длительному ожиданию ответа.
Поскольку мы использовали --permanent, правило сохранено, но ещё не действует. Перезагрузите конфигурацию брандмауэра, чтобы применить его.
sudo firewall-cmd --reload
Теперь убедитесь, что правило существует.
sudo firewall-cmd --list-rich-rules
В выводе должно появиться добавленное правило.
Регистрация отклонённых пакетов в журнале
Просто заблокировать кого-либо бывает недостаточно — иногда нужны подтверждающие записи. К правилу можно добавить «ведение журнала». Это похоже на установку камеры безопасности, которая записывает каждое срабатывание правила.
Сочетание фильтрации и ведения журнала часто используется в операциях безопасности. Блокировка защищает систему, а записи в журнале сохраняют сведения, которые можно изучить позже.
Заблокируем другой IP-адрес — 10.0.0.5. На этот раз перед отклонением подключения мы зарегистрируем попытку в журнале.
Выполните команду:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.5" log prefix="BLOCKED_IP: " level="info" reject'
Что здесь нового?
log: включает «камеру», то есть ведение журнала.prefix="BLOCKED_IP: ": при записи события в системный журнал строка начинается с указанного текста. Благодаря этому такие события легко находить с помощью инструментов поиска.
Примените изменения.
sudo firewall-cmd --reload
Проверьте результат.
sudo firewall-cmd --list-rich-rules
Теперь вы должны увидеть два правила: первое простое правило отклонения и второе правило, которое записывает событие в журнал и отклоняет подключение.
Ограничение доступа к службе
В защищённой среде обычно блокируют SSH для всех источников и разрешают доступ только из доверенной сети, например через VPN.
Учебное примечание: поскольку для сохранения вашего подключения мы используем зону trusted, этот шаг носит отчасти демонстрационный характер. Добавление правила «Allow», когда весь трафик уже разрешён, не меняет поведение системы. Однако важно освоить этот синтаксис для работы со строгими зонами, такими как public или drop.
Нужно создать правило со следующим условием: «Разрешить SSH, если источник находится в сети 192.168.0.0/24».
Это хороший пример принципа минимальных привилегий в сетевой политике. Вместо того чтобы открывать административный доступ для всего мира, вы ограничиваете его сетью, из которой сервер действительно должен управляться.
Сначала удалите общедоступную службу SSH.
sudo firewall-cmd --permanent --remove-service=ssh
Примечание: вы можете увидеть предупреждение, например Warning: NOT_ENABLED: ssh. Это нормально и ожидаемо. Наша зона по умолчанию — trusted: она разрешает весь трафик, но не содержит явно включённых служб. Поэтому попытка удалить службу, которая явно не указана в списке, вызывает безвредное предупреждение.
Затем добавьте специальное расширенное правило для подсети.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" service name="ssh" accept'
Перезагрузите конфигурацию, чтобы изменения стали активными.
sudo firewall-cmd --reload
Теперь проверьте результат. Сначала просмотрите список служб.
sudo firewall-cmd --list-services
В этом списке не должно быть ssh: служба удалена из общих служб.
Затем проверьте расширенные правила.
sudo firewall-cmd --list-rich-rules
В выводе должно появиться правило, разрешающее service name="ssh" для указанного источника.
Аудит правил
В рабочей среде рекомендуется перед завершением сеанса выполнить итоговую проверку правил брандмауэра и создать их резервную копию. Это позволяет убедиться, что правила применяются в правильном порядке, а также сохранить файл для восстановления.
На этом шаге вы экспортируете расширенные правила в текстовый файл для аудита.
Сначала выведите все расширенные правила и перенаправьте результат в файл rules_list.txt в каталоге проекта.
sudo firewall-cmd --list-rich-rules > ~/project/rules_list.txt
Затем прочитайте файл и убедитесь, что его содержимое правильное.
cat ~/project/rules_list.txt
В файле должен находиться список правил, созданных в этой лабораторной работе. Теперь этот файл служит простой резервной копией конфигурации расширенных правил.
Итоги
В этой лабораторной работе вы улучшили навыки настройки брандмауэра с помощью расширенных правил. Вы научились:
- Блокировать определённые IP-адреса с помощью правила «Reject».
- Регистрировать события безопасности с помощью правила «Camera».
- Ограничивать доступ к важным службам, например SSH, только доверенными сетями.
- Проводить аудит конфигурации, экспортируя правила в файл.
Эти расширенные методы дают точность, необходимую для защиты сложных сред.
