Обеспечение безопасности с помощью firewalld и SELinux в RHEL

Введение

В этой лабораторной работе вы узнаете, как защитить веб-сервер Apache (httpd) в Red Hat Enterprise Linux (RHEL) путем управления политиками SELinux и правилами брандмауэра. Вы пройдете через практический сценарий, в котором настроите httpd на прослушивание нестандартного порта и изучите, как системы SELinux и брандмауэра управляют безопасностью для таких конфигураций. Это упражнение дает практический опыт выполнения типичных задач администрирования безопасности в среде RHEL.

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

Настройка httpd на пользовательском порту и понимание контекста SELinux

На этом этапе вы узнаете, как настроить веб-сервер Apache (httpd) для работы на нестандартном порту и поймете, как SELinux управляет доступом к портам. Мы будем работать с портом 8081 и изучим управление портами SELinux, даже если служба успешно запускается в некоторых конфигурациях.

Необходимые пакеты (httpd, policycoreutils-python-utils и firewalld) уже установлены на этапе подготовки. Пакет policycoreutils-python-utils предоставляет команду semanage, которую вы будете использовать на следующем этапе.

Давайте начнем с изменения конфигурации httpd по умолчанию, чтобы она прослушивала нестандартный порт 8081. Основной файл конфигурации httpd находится по адресу /etc/httpd/conf/httpd.conf. Мы будем использовать редактор nano для изменения порта прослушивания.

sudo nano /etc/httpd/conf/httpd.conf

Внутри редактора nano используйте клавиши со стрелками, чтобы прокрутить вниз и найти строку Listen 80. Измените ее на:

Listen 8081

Чтобы сохранить файл и выйти из nano, нажмите Ctrl+X, затем Y для подтверждения изменений и, наконец, Enter для записи в файл.

Теперь, когда конфигурация изменена, давайте попробуем запустить службу httpd. В этой контейнеризированной среде systemctl недоступен. Мы запустим демон httpd напрямую.

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

sudo /usr/sbin/httpd

Вы можете увидеть предупреждающее сообщение о полном доменном имени сервера, но это нормально, и его можно игнорировать.

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe02:1a1e%eth0. Set the 'ServerName' directive globally to suppress this message

Давайте проверим, запущена ли служба, проверив наличие процессов httpd.

ps aux | grep httpd

Вы должны увидеть несколько запущенных процессов httpd, что означает успешный запуск веб-сервера.

root        4813  0.0  0.2  23364  7736 ?        Ss   09:32   0:00 /usr/sbin/httpd
apache      4814  0.0  0.1  23020  5092 ?        S    09:32   0:00 /usr/sbin/httpd
apache      4815  0.0  0.4 1441064 14620 ?       Sl   09:32   0:00 /usr/sbin/httpd
apache      4816  0.0  0.5 1441064 18736 ?       Sl   09:32   0:00 /usr/sbin/httpd
apache      4837  0.0  0.4 1572200 16872 ?       Sl   09:32   0:00 /usr/sbin/httpd
labex       4996  0.0  0.0   6408  2176 pts/3    S+   09:32   0:00 grep --color=auto httpd

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

sudo tail /var/log/httpd/error_log

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

[Tue Jun 17 09:32:46.374275 2025] [core:notice] [pid 4812:tid 4812] SELinux policy enabled; httpd running as context system_u:system_r:unconfined_service_t:s0
[Tue Jun 17 09:32:46.377265 2025] [suexec:notice] [pid 4812:tid 4812] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jun 17 09:32:46.394284 2025] [lbmethod_heartbeat:notice] [pid 4813:tid 4813] AH02282: No slotmem from mod_heartmonitor
[Tue Jun 17 09:32:46.399433 2025] [mpm_event:notice] [pid 4813:tid 4813] AH00489: Apache/2.4.62 (Red Hat Enterprise Linux) configured -- resuming normal operations
[Tue Jun 17 09:32:46.399458 2025] [core:notice] [pid 4813:tid 4813] AH00094: Command line: '/usr/sbin/httpd'

Интересно, что служба httpd запустилась без каких-либо проблем с SELinux. Давайте проверим, были ли в журнале аудита отказы SELinux.

sudo grep AVC /var/log/audit/audit.log | grep httpd

Если результатов нет, это означает, что SELinux не блокировал службу httpd при привязке к порту 8081. Это может быть связано с тем, что:

1. Порт 8081 может быть разрешен для HTTP-служб по умолчанию в некоторых конфигурациях.
2. Процесс httpd может работать в неограниченном (unconfined) контексте.
3. Порт 8081 может быть уже определен в политике SELinux.

Давайте проверим текущий режим SELinux:

getenforce

Вы должны увидеть, что SELinux находится в режиме "Enforcing", что означает, что он активно применяет политики. Тот факт, что httpd запустился успешно, указывает на то, что порт 8081, возможно, уже имеет правильную метку SELinux, или служба работает в неограниченном контексте, как показано в сообщениях журнала. Для целей этого учебного упражнения давайте перейдем к следующему шагу, где мы изучим управление портами SELinux и обеспечим правильную конфигурацию.

Понимание и управление метками портов SELinux с помощью semanage

На этом этапе вы узнаете, как управлять метками портов SELinux с помощью команды semanage. Несмотря на то, что служба httpd в настоящее время работает на порту 8081, важно понимать, как правильно настраивать политики портов SELinux для обеспечения безопасности и соответствия требованиям. Вы изучите текущую конфигурацию портов и узнаете, как явно назначать правильный тип SELinux пользовательским портам.

Сначала вам нужно найти правильный тип SELinux для портов веб-сервера. Команда semanage port -l выводит список всех определений портов, известных SELinux. Мы можем передать этот вывод в grep, чтобы найти типы, связанные с http.

sudo semanage port -l | grep http

Вывод показывает несколько типов портов. Наиболее подходящим для стандартного веб-сервера является http_port_t.

http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989

Как видите, http_port_t назначен стандартным портам HTTP/HTTPS, таким как 80 и 443. Политика SELinux позволяет процессам с типом httpd_t (наш веб-сервер) привязываться к любому порту, помеченному как http_port_t. Давайте проверим, есть ли порт 8081 в этом списке.

Обратите внимание, что порт 8081 в настоящее время не указан в http_port_t. Однако в некоторых конфигурациях RHEL этот порт может быть уже определен в политике SELinux. Давайте попробуем явно добавить его для надлежащего соответствия требованиям SELinux с помощью команды semanage port -a.

• Опция -a означает "add" (добавить).
• Опция -t http_port_t указывает тип для назначения.
• Опция -p tcp указывает протокол.

sudo semanage port -a -t http_port_t -p tcp 8081

Вы можете увидеть сообщение "Port tcp/8081 already defined, modifying instead", что означает, что порт уже был настроен. Это объясняет, почему httpd успешно запустился на предыдущем шаге. Чтобы проверить текущую конфигурацию, снова выведите определения http_port_t.

sudo semanage port -l | grep '^http_port_t'

Теперь вы должны увидеть порт 8081 в списке.

http_port_t                    tcp      8081, 80, 81, 443, 488, 8008, 8009, 8443, 9000

Благодаря явно обновленной политике SELinux, порт 8081 теперь официально распознается как HTTP-порт. Служба httpd должна продолжать работать без каких-либо проблем, и вы обеспечили надлежащее соответствие требованиям SELinux.

Давайте убедимся, что процесс все еще работает:

ps aux | grep httpd

Вы должны продолжать видеть несколько процессов httpd, что указывает на то, что веб-сервер успешно работает с правильной маркировкой портов SELinux.

root        4813  0.0  0.2  23364  7736 ?        Ss   09:32   0:00 /usr/sbin/httpd
apache      4814  0.0  0.1  23020  5092 ?        S    09:32   0:00 /usr/sbin/httpd
apache      4815  0.0  0.4 1441064 14620 ?       Sl   09:32   0:00 /usr/sbin/httpd
apache      4816  0.0  0.5 1441064 18736 ?       Sl   09:32   0:00 /usr/sbin/httpd
apache      4837  0.0  0.4 1572200 16872 ?       Sl   09:32   0:00 /usr/sbin/httpd
labex       5215  0.0  0.0   6408  2176 pts/3    S+   09:33   0:00 grep --color=auto httpd

Вы успешно настроили политику SELinux, чтобы явно разрешить службе httpd работать на порту 8081, обеспечив надлежащее соблюдение требований безопасности.

Открытие пользовательского порта в брандмауэре с помощью firewall-cmd

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

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

sudo firewall-cmd --list-all

Если вы видите "FirewallD is not running", нам нужно запустить демон firewalld. В этой контейнерной среде мы запускаем демон firewalld напрямую. Символ & в конце запускает процесс в фоновом режиме.

sudo /usr/sbin/firewalld &

Подождите немного, пока служба инициализируется, затем убедитесь, что она работает:

sudo firewall-cmd --list-all

Теперь вы должны увидеть текущую конфигурацию брандмауэра для зоны по умолчанию (public).

Давайте протестируем доступ к веб-серверу из командной строки с помощью curl. Эта команда пытается подключиться к localhost на порту 8081.

curl http://localhost:8081

Вы должны увидеть HTML-содержимое вашей тестовой страницы, что означает, что веб-сервер доступен локально. Это ожидаемо, так как firewalld обычно разрешает трафик localhost по умолчанию.

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

Сначала давайте проверим текущие правила для зоны по умолчанию (public):

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Теперь добавьте новое правило, чтобы разрешить TCP-трафик на порту 8081. Убедитесь, что firewalld запущен перед выполнением этой команды.

• --add-port=8081/tcp указывает порт и протокол для открытия.
• --permanent гарантирует, что правило сохранится после перезагрузки или перезагрузки брандмауэра.

sudo firewall-cmd --permanent --add-port=8081/tcp

Если вы видите "FirewallD is not running", убедитесь, что вы запустили демон firewalld на предыдущем шаге, и подождите немного, пока он инициализируется.

Команда должна вернуть success, когда firewalld работает правильно.

success

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

sudo firewall-cmd --reload

Эта команда также должна вернуть success.

success

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

sudo firewall-cmd --list-all

Теперь вы должны увидеть 8081/tcp в разделе ports:.

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports: 8081/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

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

Проверка доступа к стандартным и пользовательским портам веб-сервера

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

Сначала давайте создадим простую тестовую страницу, чтобы при подключении мы получали пользовательское сообщение. Корневой каталог документов по умолчанию для httpd — /var/www/html. Мы создадим файл index.html в этом каталоге. Вам потребуются привилегии sudo для записи в это место.

echo "Success! Web server on custom port 8081 is working." | sudo tee /var/www/html/index.html

Эта команда помещает сообщение об успехе в файл index.html. Команда tee используется здесь, потому что она позволяет нам записывать в файл, требующий привилегий sudo, при использовании конвейера. Вы должны увидеть сообщение, выведенное в терминал в качестве подтверждения.

Success! Web server on custom port 8081 is working.

Чтобы завершить упражнение, давайте продемонстрируем контраст, попытавшись получить доступ к стандартному HTTP-порту 80. Поскольку наш сервер настроен на прослушивание только порта 8081, этот запрос должен завершиться неудачей.

curl http://localhost:80

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

curl: (7) Failed to connect to localhost port 80: Connection refused

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

1. Проверка состояния службы и журналов.
2. Исследование отказов SELinux в журнале аудита.
3. Исправление политик SELinux с помощью semanage.
4. Настройка правил брандмауэра с помощью firewall-cmd.
5. Проверка подключения.

Резюме

В этой лабораторной работе вы узнали, как настроить веб-сервер на пользовательском порту и управлять политиками безопасности SELinux. С предварительно установленными пакетами веб-сервера Apache (httpd), policycoreutils-python-utils и firewalld вы сосредоточились на понимании управления портами SELinux и конфигурации брандмауэра. Вы изменили файл httpd.conf, чтобы изменить порт прослушивания веб-сервера на нестандартный порт 8081.

Вы обнаружили, что служба httpd успешно запустилась на пользовательском порту, потому что порт 8081 уже был правильно настроен в политике SELinux. Это дало возможность изучить управление портами SELinux и понять, как semanage работает для поддержания правильной маркировки портов. Вы также научились использовать firewall-cmd для управления правилами брандмауэра, обеспечивая как соблюдение требований безопасности, так и доступность. Несмотря на то, что httpd работал в неограниченном контексте, эта лабораторная работа продемонстрировала важность правильной конфигурации SELinux и брандмауэра для производственных сред.