Início / server / 问题

Perguntas[nginx](server)

Martin Hope
Jerome WAGNER
Asked: 2025-03-26 00:15:22 +0800 CST
  • 5

Gostaria de reduzir o tráfego e a largura de banda usados ​​por bots que enviam URLs GET para testar falhas de segurança "clássicas" em um site.

URLs como GET /.env GET /.git/config GET /phpinfo.php ..

quando olho meus logs, há milhares deles. Alguns dos bots mudam seus IPs regularmente, alguns deles continuam mudando suas strings User-Agent, ..

Então, eu estava pensando em uma lista codificada extraída dos meus logs e enviar a eles um 403 Forbidden ou algo assim, mas eu gostaria de torná-la rápida o suficiente para que o nginx ou o varnish pudessem lidar com esse filtro rápido o suficiente para que isso não afetasse seu desempenho.

Você já tentou lidar com esse fluxo constante de solicitações com essa lista? Existe algum truque especial, como uma árvore binária no Nginx ou Varnish, que pode ajudar a configurar uma lista enorme de caminhos para uma correspondência rápida?

nginx
Martin Hope
natli
Asked: 2025-03-25 02:19:20 +0800 CST
  • 5

Então, estou executando um servidor docker com um contêiner nginx fazendo proxy reverso de vários outros contêineres. No host, quero usar o fail2ban para banir IPs que tentam invadir sites do WordPress. Bem simples, mas preciso usar uma ação personalizada para que o banimento ocorra na cadeia DOCKER-USER, caso contrário, os encaminhamentos do docker (que também usam iptables) substituem os banimentos. Para conseguir isso, monto o diretório de logs do nginx do host para o contêiner para que o fail2ban possa observá-los do host.

Tudo parece estar funcionando perfeitamente, exceto pelo fato de que não está banindo nenhum IP. O regex corresponde corretamente nos testes, banir manualmente funciona perfeitamente, os logs do fail2ban não mostram nenhuma estranheza; estou perplexo.

Aqui está um trecho ofuscado/anonimizado do registro de acesso;

132.321.555.777 - - [24/Mar/2025:17:12:07 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:07 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:07 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:08 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:08 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
84.29.333.555 - - [24/Mar/2025:17:12:08 +0000] "GET /wp-content/uploads/2024/06/xx-32x32.png HTTP/1.1" 200 926 "-" "NetworkingExtension/8620.2.4.10.8 Network/4277.82.1 iOS/18.3.2"
84.29.333.555 - - [24/Mar/2025:17:12:08 +0000] "GET /wp-content/uploads/2024/06/xx-180x180.png HTTP/1.1" 200 5567 "-" "NetworkingExtension/8620.2.4.10.8 Network/4277.82.1 iOS/18.3.2"
132.321.555.777 - - [24/Mar/2025:17:12:09 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:09 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:09 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
132.321.555.777 - - [24/Mar/2025:17:12:10 +0000] "POST //xmlrpc.php HTTP/1.1" 200 423 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36"
43.166.222.22 - - [24/Mar/2025:17:12:02 +0000] "GET / HTTP/1.1" 400 248 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1"
84.29.123.32 - - [24/Mar/2025:17:12:08 +0000] "GET /wp-content/uploads/2023/01/xx-300x225.png HTTP/1.1" 200 115438 "-" "NetworkingExtension/8620.2.4.10.8 Network/4277.82.1 iOS/18.3.2"
84.29.123.32 - - [24/Mar/2025:17:12:08 +0000] "GET /wp-content/uploads/2024/06/xx-192x192.png HTTP/1.1" 200 5994 "-" "NetworkingExtension/8620.2.4.10.8 Network/4277.82.1 iOS/18.3.2"
84.29.123.32 - - [24/Mar/2025:17:12:09 +0000] "GET /wp-content/uploads/2024/06/xx-32x32.png HTTP/1.1" 200 926 "-" "NetworkingExtension/8620.2.4.10.8 Network/4277.82.1 iOS/18.3.2"

/etc/fail2ban/jail.local

[nginx-xmlrpc]
enabled  = true
filter   = nginx-xmlrpc
logpath  = /var/dockervolumes/nginx/logs/access.log
maxretry = 1
findtime = 5
bantime  = 3600
action   = iptables-docker

Configurei o maxretry e o findtime bem baixos para testes, mas isso não ajudou.

/etc/fail2ban/filter.d/nginx-xmlrpc.conf

[INCLUDES]

before = nginx-bad-request.conf

[Definition]
failregex = ^<HOST>.*] "POST (|.*)\/xmlrpc\.php.*
            ^<HOST>.*] "GET (|.*)\/xmlrpc\.php.*
            ^<HOST> .* "POST .*wp-login.php
ignoreregex = ^<HOST>.*] "POST (|.*)\/xmlrpc\.php\?for=jetpack.*

datepattern = ^[^\[]*\[({DATE})
              {^LN-BEG}

Como você pode ver, eu já tentei mexer no padrão de datas, mas isso não ajudou.

/etc/fail2ban/action.d/iptables-docker.conf

[Definition]
actionstart =
actionstop =
actioncheck = /usr/sbin/iptables -n -L DOCKER-USER | grep -q '[<ip>]'
actionban = /usr/sbin/iptables -I DOCKER-USER -s <ip> -j DROP
actionunban = /usr/sbin/iptables -D DOCKER-USER -s <ip> -j DROP

Testando o regex; fail2ban-regex /var/dockervolumes/nginx/logs/access.log /etc/fail2ban/filter.d/nginx-xmlrpc.conf

Running tests
=============

Use   failregex filter file : nginx-xmlrpc, basedir: /etc/fail2ban
Use      datepattern : ^[^\[]*\[({DATE})
{^LN-BEG} : Default Detectors
Use         log file : /var/dockervolumes/nginx/logs/access.log
Use         encoding : UTF-8


Results
=======

Failregex: 13345 total
|-  #) [# of hits] regular expression
|   1) [13299] ^<HOST>.*] "POST (|.*)\/xmlrpc\.php.*
|   2) [20] ^<HOST>.*] "GET (|.*)\/xmlrpc\.php.*
|   3) [26] ^<HOST> .* "POST .*wp-login.php
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [26486] ^[^\[]*\[(Day(?P<_sep>[-/])MON(?P=_sep)ExYear[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?)
`-

Lines: 26486 lines, 0 ignored, 13345 matched, 13141 missed
[processed in 2.39 sec]

Testando o ban manualmente; fail2ban-client set nginx-xmlrpc banip 1.2.5.9

Produz log:

2025-03-24 19:09:35,909 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Ban 1.2.5.9

E lista corretamente o ip bloqueado; iptables -L DOCKER-USER

Chain DOCKER-USER (1 references)
target     prot opt source               destination
DROP       all  --  1.2.5.9              anywhere
DROP       all  --  1.2.4.9              anywhere
DROP       all  --  1.2.3.9              anywhere
DROP       all  --  1.2.3.8              anywhere
DROP       all  --  1.2.3.7              anywhere
DROP       all  --  1.2.3.6              anywhere
DROP       all  --  1.2.3.5              anywhere
RETURN     all  --  anywhere             anywhere

O log também não mostra mais nenhuma estranheza; tail -f /var/log/fail2ban.log

2025-03-24 19:00:29,067 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.3.5
2025-03-24 19:00:29,080 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.3.6
2025-03-24 19:00:29,094 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.3.7
2025-03-24 19:00:29,104 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.3.8
2025-03-24 19:00:29,115 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.3.9
2025-03-24 19:00:29,126 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Restore Ban 1.2.4.9
2025-03-24 19:00:29,240 fail2ban.filtersystemd  [828254]: INFO    [nginx-xmlrpc] Jail is in operation now (process new journal entries)
2025-03-24 19:05:53,278 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Unban 1.2.3.4
2025-03-24 19:09:33,024 fail2ban.actions        [828254]: WARNING [nginx-xmlrpc] 1.2.4.9 already banned
2025-03-24 19:09:35,909 fail2ban.actions        [828254]: NOTICE  [nginx-xmlrpc] Ban 1.2.5.9

ATUALIZAR:

~ status do cliente fail2ban nginx-xmlrpc

Status for the jail: nginx-xmlrpc
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- Journal matches:  _SYSTEMD_UNIT=nginx.service + _COMM=nginx
`- Actions
   |- Currently banned: 0
   |- Total banned:     8
   `- Banned IP list:

Essas 8 proibições foram meus testes manuais.

~ iptables-salvar

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-51ec37449070 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-51ec37449070 -j DOCKER
-A FORWARD -i br-51ec37449070 ! -o br-51ec37449070 -j ACCEPT
-A FORWARD -i br-51ec37449070 -o br-51ec37449070 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2020 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2019 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2018 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2017 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2016 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2015 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2014 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2013 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2012 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2011 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2010 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2009 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2008 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2007 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2006 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2005 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2004 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2003 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2002 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2001 -j ACCEPT
-A DOCKER -d 172.18.0.39/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 2000 -j ACCEPT
-A DOCKER -d 172.18.0.6/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 443 -j ACCEPT
-A DOCKER -d 172.18.0.6/32 ! -i br-51ec37449070 -o br-51ec37449070 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-51ec37449070 ! -o br-51ec37449070 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-51ec37449070 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -s 1.14.96.192/32 -j DROP
-A DOCKER-USER -s 18.219.14.219/32 -j DROP
-A DOCKER-USER -s 174.138.27.210/32 -j DROP
-A DOCKER-USER -s 128.199.244.121/32 -j DROP
-A DOCKER-USER -s 45.130.145.4/32 -j DROP
-A DOCKER-USER -s 128.199.244.121/32 -j DROP
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Mar 26 09:10:19 2025
# Generated by iptables-save v1.8.10 (nf_tables) on Wed Mar 26 09:10:19 2025
*nat
:PREROUTING ACCEPT [320032242:19224216945]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [396346224:30027564903]
:POSTROUTING ACCEPT [531692826:38140531338]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.18.0.0/16 ! -o br-51ec37449070 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2020 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2019 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2018 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2017 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2016 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2015 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2014 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2013 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2012 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2011 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2010 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2009 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2008 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2007 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2006 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2005 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2004 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2003 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2002 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2001 -j MASQUERADE
-A POSTROUTING -s 172.18.0.39/32 -d 172.18.0.39/32 -p tcp -m tcp --dport 2000 -j MASQUERADE
-A POSTROUTING -s 172.18.0.6/32 -d 172.18.0.6/32 -p tcp -m tcp --dport 443 -j MASQUERADE
-A POSTROUTING -s 172.18.0.6/32 -d 172.18.0.6/32 -p tcp -m tcp --dport 80 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i br-51ec37449070 -j RETURN
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2020 -j DNAT --to-destination 172.18.0.39:2020
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2019 -j DNAT --to-destination 172.18.0.39:2019
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2018 -j DNAT --to-destination 172.18.0.39:2018
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2017 -j DNAT --to-destination 172.18.0.39:2017
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2016 -j DNAT --to-destination 172.18.0.39:2016
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2015 -j DNAT --to-destination 172.18.0.39:2015
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2014 -j DNAT --to-destination 172.18.0.39:2014
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2013 -j DNAT --to-destination 172.18.0.39:2013
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2012 -j DNAT --to-destination 172.18.0.39:2012
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2011 -j DNAT --to-destination 172.18.0.39:2011
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2010 -j DNAT --to-destination 172.18.0.39:2010
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2009 -j DNAT --to-destination 172.18.0.39:2009
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2008 -j DNAT --to-destination 172.18.0.39:2008
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2007 -j DNAT --to-destination 172.18.0.39:2007
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2006 -j DNAT --to-destination 172.18.0.39:2006
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2005 -j DNAT --to-destination 172.18.0.39:2005
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2004 -j DNAT --to-destination 172.18.0.39:2004
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2003 -j DNAT --to-destination 172.18.0.39:2003
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2002 -j DNAT --to-destination 172.18.0.39:2002
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2001 -j DNAT --to-destination 172.18.0.39:2001
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 2000 -j DNAT --to-destination 172.18.0.39:2000
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.18.0.6:443
-A DOCKER ! -i br-51ec37449070 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.18.0.6:80
COMMIT
# Completed on Wed Mar 26 09:10:19 2025
nginx
Martin Hope
Rekiel
Asked: 2025-03-22 23:10:50 +0800 CST
  • 5

Estou encontrando um erro 403 Forbidden ao tentar acessar a página /admin do Vaultwarden, que é protegida pela autenticação básica HTTP via Nginx Proxy Manager.

Resumo do problema:

Ambiente: Raspberry Pi executando Docker com Vaultwarden, Portainer e Nginx Proxy Manager. Problema: Acessar a página /admin após inserir credenciais resulta em um erro 403 Forbidden.

Detalhes e configuração:

Nginx Configuration:

location /admin {
    auth_basic "Restricted Access";
    auth_basic_user_file /data/compose/1/data/.htpasswd;

    proxy_pass http://localhost:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

O que eu tentei:

Verifiquei se o arquivo .htpasswd está configurado corretamente e acessível pelo Nginx. Verifiquei as permissões do arquivo para garantir que estejam definidas corretamente. Revisei os logs de erro do Nginx, mas eles não fornecem informações específicas sobre a causa do erro 403. Confirmei que o Vaultwarden funciona bem sem a proteção por senha.

Quaisquer insights ou sugestões serão muito apreciados. Se mais informações forem necessárias, por favor, me avise!

Obrigado!

Tela: Configuração básica do host proxy Configuração SSL Configuração avançada e personalizada do Nginx Erro 403 Proibido

nginx
Martin Hope
Quinnell
Asked: 2025-03-22 03:20:45 +0800 CST
  • 5

Tenho um Synology NAS com acesso WAN usando um proxy reverso Nginx. Como o subdomínio cloud.domain.comé roteado para o Synology, todo o caminho de subpastas é gerenciado pelo aplicativo Synology.

captura de tela da interface do Synology onde /filesé atribuído

Para acessar o Gerenciador de Arquivos, eu usaria o seguinte URL:

https://cloud.example.org/files

Tenho uma pasta compartilhada no Gerenciador de Arquivos que usa um link estilo tinyURL para acesso direto. Gostaria de criar um redirecionamento que apontasse diretamente para essa pasta compartilhada com uma URL personalizada, como a seguinte:

https://cloud.example.org/public_downloads

Em outras palavras, preciso usar https://cloud.example.org/public_downloadspara acessar https://tiny.url/abcd123. Existe uma maneira de substituir um caminho de subpasta específico sem quebrar os gerenciados pela Synology como /files?

Eu revisei uma pergunta semelhante nginx Redirect subdomain and path específico , mas depois de olhar a documentação vinculada , não estou vendo como posso configurá-lo para o /pathing em vez do subdomínio. Suspeito que a chave esteja na manipulação da locationseção da configuração do Nginx para meu cloud.example.orgservidor.

Minha configuração Nginx para o Synology

## CLOUD HTTPS ##
server {
        listen [::]:443 ssl http2;
        listen 443 ssl http2;
        server_name cloud.domain.com;

                ssl_session_timeout 30m;
                ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
                ssl_certificate      /usr/share/nginx/ssl/example.org-chain.pem;
                ssl_certificate_key  /usr/share/nginx/ssl/example.org-key.pem;
                ssl_session_cache shared:SSL:10m;

                        add_header X-Xss-Protection "1; mode=block" always;
                        add_header X-Content-Type-Options "nosniff" always;
                        add_header Strict-Transport-Security "max-age=2592000; includeSubdomains" always;
                        add_header X-Frame-Options "SAMEORIGIN" always;
                        proxy_hide_header X-Powered-By;
                        add_header 'Referrer-Policy' 'no-referrer';
                        add_header Content-Security-Policy "frame-ancestors example.org app.example.org;";

                location / {
                proxy_pass http://10.1.2.3:5000;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Ssl on;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_read_timeout  90;
                proxy_redirect http://synologyhostname:5000 https://$host/:5001;
        }
}
## END CLOUD HTTPS ##
nginx
Martin Hope
Kevin Schulz
Asked: 2025-03-21 01:37:09 +0800 CST
  • 5

Configurei o Nginx Proxy Manager no meu servidor e configurei um proxy reverso para meu domínio com SSL (Let's Encrypt). Tudo funciona bem e posso acessar meu serviço web através do meu domínio com segurança via HTTPS, mas tenho um problema: qualquer um pode acessar meu serviço via http://IP:PORT, que eu quero bloquear completamente.

Quero restringir o acesso ao meu servidor para que ele só possa ser acessado por meio de https://DOMÍNIO e não pelo endereço IP público do servidor.

Já tentei as seguintes coisas:

  • Redirecionando HTTP para HTTPS e restringindo o acesso somente ao domínio. -> não é possível escrever o endereço IP no campo de domínio no NPM
  • Usando código Nginx personalizado para bloquear completamente o acesso IP direto. -> então o host proxy obtém o status 'offline'
  • habilitar HSTS -> ainda permite acesso por IP

Alguém já enfrentou um problema semelhante ou pode sugerir a melhor maneira de configurar isso no Nginx Proxy Manager? Eu realmente apreciaria qualquer tipo de ajuda ou sugestão.

Desde já, obrigado!

nginx
Martin Hope
ShadowEagle
Asked: 2025-03-14 22:16:25 +0800 CST
  • 5

Tenho alguns problemas com uma configuração específica que desejo alcançar:

Resumo:

  • O Nginx atua como um proxy reverso
  • Backend em execução em http://localhost:8080/
  • O Nginx pode retornar HTTP 403 ( $block_access = true), nesse caso quero mostrar uma página de erro personalizada ( /errors/403.html)
  • O backend pode retornar HTTP 404, nesse caso também quero mostrar uma página de erro personalizada ( /errors/404.html)

Problemas:

  • A página HTTP 403 personalizada não funciona, a página Nginx 403 padrão é exibida em seu lugar
  • Página HTTP 404 personalizada para o backend funciona
  • Se eu remover proxy_intercept_errorsdo bloco de localização, a página 403 personalizada funciona para o Nginx, mas a página 404 personalizada para o proxy obviamente não funciona mais

Configuração:

server {
    listen 443 ssl http2;
    server_name mydomain.com;

    # Reverse proxy configuration
    location / {
        # Let Nginx handle basic blocking behavior
        if ($block_access) {
            return 403;
        }

        # Proxy request to backend
        proxy_pass http://localhost:8080/;
        proxy_buffering off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Connection $http_connection;

        # Only intercept 404 errors from the backend
        proxy_intercept_errors on;
        error_page 404 /errors/404.html;

        # Serve custom 404 error page
        location = /errors/404.html {
            root /var/www/html;
            internal;
        }
    }

    # Serve custom 403 error page for blocked access ($block_access = true)
    error_page 403 /errors/403.html;
    location = /errors/403.html {
        root /var/www/html;
        internal;
    }

    location /errors/ {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

Estou mais ou menos completamente perdido na busca por uma solução...

nginx
Martin Hope
Lifeboy
Asked: 2025-03-12 02:35:32 +0800 CST
  • 6

Estou usando acme.sh para criar um certificado para um servidor mais antigo, que preciso executar por vários motivos. No entanto, estou esquecendo de algo sobre a parte .well-known/acme-challenge.

Quando executo o script:

acme.sh --issue --nginx -d fish.pre.imb.co --test --debug 2

Recebo um erro:

fish.pre.imb.co:Verify error:197.214.119.177: Invalid response from https://fish.pre.imb.co/.well-known/acme-challenge/0wDIf77g9i9U1fx75tGX9UEOK_d4-A3ZdORclyTd14k: 404

Entretanto, se eu colocar um arquivo com o nome da consulta acima no diretório, ele será resolvido sem problemas.

Aqui está meu arquivo de configuração nginx:

upstream puma_fisheagle {
        server 192.168.abc.xyz:1234 max_fails=3 fail_timeout=30s;
}

# IMB external system api server setup.
server {
        resolver_timeout 10s;

        server_name fish.pre.imb.co;
        root /var/local/www/fisheagle/public;
        access_log /var/log/nginx/fisheagle.log;
        rewrite_log on;
        try_files $uri/index.html $uri @puma_fisheagle;

        location @puma_fisheagle {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_read_timeout  1800s;
                proxy_redirect off;
                proxy_pass http://puma_fisheagle;
                proxy_connect_timeout   2;
        }
    
        location /.well-known/acme-challenge {
                default_type "text/plain";
                allow all;
                root /var/local/www/acme;
        }

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.abc.0/24; 
    #   deny all;
    }
    
        error_page 404 /404.html;
        error_page 422 /422.html;
        error_page 500 503 504 /500.html;
        error_page 502 /502.html;
        client_max_body_size 10m;
        keepalive_timeout 10m;

    listen              443 ssl;

    ssl_certificate      /etc/acme.sh/certs/fish.pre.imb.co/fullchain.cer;
    ssl_certificate_key  /etc/acme.sh/certs/fish.pre.imb.co/fish.pre.imb.co.key;
        # intermediate configuration
        # old configuration
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/ssl/private/ffdhe4096.pem;
    ssl_ecdh_curve secp384r1;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_session_timeout 60m;
    ssl_session_cache shared:SSL:50m;
}

server {
    if ($host = fish.pre.imb.co) {
        return 301 https://$host$request_uri;
    }

    server_name fish.pre.imb.co;

    listen 80;
    return 404;
}

Então parece que o acme não consegue gravar o arquivo no diretório? Quer dizer, se eu escrevê-lo manualmente, o config lê.

O que estou perdendo?

Aqui está o arquivo de depuração acme.sh: https://pastebin.com/6zHGAprA

nginx
Martin Hope
RDK
Asked: 2025-03-02 00:22:18 +0800 CST
  • 5

Pessoal... Fiz essa pergunta no site StackExchange e me sugeriram que aqui seria melhor...

Tenho um site nginx que está recebendo muitos acessos para um arquivo inexistente "mydata.html". Esses acessos são registrados no log de acesso do site com códigos de status 301 (ou 302). Gostaria de saber como configurar uma jail Fail2ban que capturará esses acessos e banirá o IP se forem excessivos.

Aqui está um exemplo de registro do arquivo de log:

1.2.3.4 - - [02/Mar/2025:00:00:06 -0700] "GET /MyData.html HTTP/1.1" 301 185 "http://xxx.MySite.com/MyData.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/125.0.0.0 Safari/537.36"

E minha tentativa de um regex para selecionar a entrada ^.*MyData.*HTTP.* 301. Esse regex pode ser modificado para também obter os códigos 302 ou outros?

Alguém pode me dar alguma orientação, sou pior que um iniciante com expressões regex. Obrigado....RDK

nginx
Martin Hope
Dream59
Asked: 2025-02-24 22:11:26 +0800 CST
  • 5

Eu implantei meu aplicativo em contêiner usando o AWS ECS Fargate . Minha configuração consiste em:

  • Um servidor web FastAPI em execução na porta 8000 .
  • Um servidor NGINX em execução na porta 8080 .

Por motivos de segurança, bloqueei o acesso direto por meio de grupos de segurança , o que significa que ninguém pode acessar o IP público da minha instância nas portas 80, 443, 8080 ou 8000 .

Em vez disso, tornei meu aplicativo acessível somente por meio de um AWS Application Load Balancer (ALB) , que lida com tráfego baseado em domínio . Minha suposição era que, como o IP público não é acessível , os bots não seriam capazes de enviar solicitações automatizadas a menos que soubessem meu nome de domínio.

No entanto, ainda estou recebendo solicitações de bots.

Minha pergunta:

  1. Como os bots ainda estão enviando solicitações ao meu serviço se o acesso IP direto está bloqueado?
  2. Existe uma maneira de impedir completamente o tráfego de bots sem usar o AWS WAF ou outros serviços de segurança da AWS ?
  3. Bloquear o acesso direto ao IP público não significa que somente usuários que conhecem meu domínio podem acessar o serviço?

Agradeceria qualquer informação sobre o motivo disso estar acontecendo e possíveis soluções.

nginx
Martin Hope
Afshin
Asked: 2025-02-24 04:54:32 +0800 CST
  • 6

Estou tentando criar um cenário de fallback para o servidor nginx https. Quero dar suporte para TLS bidirecional com certificado de cliente e TLS unidirecional com método de autenticação (por exemplo, autenticação básica). O que quero alcançar é que, se não conseguisse estabelecer um TLS bidirecional com um certificado de cliente, fallback para um TLS unidirecional com método de autenticação adicional.

Alguma ideia de como posso fazer isso? Sou meio novo na configuração do nginx, então qualquer ajuda será ótima.

nginx