Выполнение самоподписания в Nginx и отклонение HTTP/HTTPS-трафика, направленного на необработанные IP-адреса на уровне L7 прикладного уровня

5 min

nginxfreebsd
language: ja bn en es hi pt ru zh-cn zh-tw

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

Конечно, можно блокировать DDoS-атаки с помощью Fail2ban, но, судя по логам, он, похоже, управляет блокируемыми IP-адресами, помещая их в базу данных, что может привести к высокой нагрузке. Если использовать Fail2ban, то лучше делать это на уровне доменов. Для необработанных IP-адресов, которые обычно не используются, я выберу другой метод и на этот раз защищу их от HTTP/HTTPS-трафика на стороне Nginx.

Простая блокировка только HTTP-трафика

В моем случае глобальный публичный IP-адрес следующий, поэтому это выглядит так:

# http通信
server {
    listen 80;
    listen [::]:80;

    server_name 167.179.75.206;

    return 444;
}

Однако в случае SSL-трафика Nginx становится слушателем HTTPS, явно указывая, что это SSL-трафик, например, listen 443 ssl;.

И если вставить это в секцию http и выполнить nginx -t...

# https通信
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name 167.179.75.206;

    # IPアドレスへのアクセスを拒否
    return 444;
}

Что произойдет?

# nginx -t
nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /usr/local/etc/nginx/nginx.conf:90
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

Да, поскольку это SSL-трафик, он будет ругаться, что нет ключа.
В таких случаях требуется самоподписанный сертификат... Нужно сказать: "Это я! Мой сертификат!" и представить его. Я подтверждаю свою личность, здесь и сейчас...

Итак, OpenSSL, можете ли вы что-нибудь сделать?

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

openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout /usr/local/etc/nginx/selfsigned.key -out /usr/local/etc/nginx/selfsigned.crt

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

Nginx, я вернулся

Давайте укажем этот ключ в Nginx.

# https通信
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name 167.179.75.206;

    # 自己署名証明書と秘密鍵の指定
    ssl_certificate /usr/local/etc/nginx/selfsigned.crt;
    ssl_certificate_key /usr/local/etc/nginx/selfsigned.key;

    return 444;
}

Вот так это и сработало.
Конец.

Related Posts