Попытка запустить Security Onion на AWS за ALB (nginx за ALB)

Попытка запустить Security Onion на AWS за ALB (nginx за ALB)

У меня есть wildcard-сертификат для внутренних служб. Я хотел бы запустить Security Onion за ALB, чтобы получить действительный SSL с одним сертификатом, хранящимся в диспетчере сертификатов. (Хранение там лучше для безопасности, а также для более легкого обслуживания и надежности)

Проблема, по-видимому, в файле конфигурации Security Onion /opt/so/saltstack/local/pillar/global.sls

url_base: # IP or FQDN

Можно ли настроить прослушивание по IP-адресу (в этом случае перенаправление входа в систему указывает на IP-адрес и проверяемые разрывы SSL) ИЛИ по полному доменному имени (в этом случае он не отвечает на запросы по IP-адресу, и проверка работоспособности целевой группы завершается неудачей).

Я случайно заставил его работать, переключившись с IP на FQDN. Но я подозреваю, что он работал в течение 2-минутного льготного периода, пока проверка работоспособности была еще зеленой, но сервер работал по FQDN.

За кулисами Security Onion использует nginx для маршрутизации хост-докер. Файл конфигурации nginx находится здесь /opt/so/saltstack/default/salt/nginx/etc/nginx.conf

Кто-нибудь делал это раньше?

решение1

Мне удалось заставить это работать, вставив простую проверку работоспособности в конфигурацию nginx.

server {
              listen 443 ssl http2;
              server_name 192.168.1.something;
              location /health {
                  access_log off;
                  add_header 'Content-Type' 'text/plain';
                  return 200 "healthy\n";
             }
         }

Два ограничения этого подхода.

  1. Я жестко запрограммировал IP-адрес в своей конфигурации, и это сломается, если мой хост когда-либо переместится или будет повторно создан из снимка. (Можно ли это исправить, заставив nginx выводить локальный IP-адрес?)
  2. Проверка работоспособности проверяет, работает ли nginx, но не работоспособен ли SO за ним.

Связанный контент