AskOverflow.Dev

AskOverflow.Dev Logo AskOverflow.Dev Logo

AskOverflow.Dev Navigation

  • Início
  • system&network
  • Ubuntu
  • Unix
  • DBA
  • Computer
  • Coding
  • LangChain

Mobile menu

Close
  • Início
  • system&network
    • Recentes
    • Highest score
    • tags
  • Ubuntu
    • Recentes
    • Highest score
    • tags
  • Unix
    • Recentes
    • tags
  • DBA
    • Recentes
    • tags
  • Computer
    • Recentes
    • tags
  • Coding
    • Recentes
    • tags
Início / server / 问题

Perguntas[nginx](server)

Martin Hope
Amr Abu Aza
Asked: 2025-04-28 22:29:01 +0800 CST

O NGINX encaminha todas as solicitações para o serviço de backend em vez de separar o backend e a API (PHP YII2)

  • 6

Estou executando dois serviços (backend e API) na mesma porta dentro do Docker. No entanto, sempre que envio solicitações, o NGINX encaminha todas as solicitações para o serviço de backend, e não consigo acessar o serviço de API corretamente.

Suspeito que seja um problema com minha configuração do NGINX.

Aqui estão meus arquivos:

docker-compose.yml

version: '3.8'

services:
  backend:
    build:
      context: .
      dockerfile: ./backend/Dockerfile.dev
    volumes:
      - ./backend:/var/www/html/backend
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  api:
    build:
      context: .
      dockerfile: ./api/Dockerfile.dev
    volumes:
      - ./api:/var/www/html/api
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  postgres:
    image: postgres:13
    restart: always
    volumes:
      - ~/bysooq-data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: xxx
      POSTGRES_USER: xx
      POSTGRES_PASSWORD: xxx
    networks:
      - bysooq-network

  redis:
    image: redis:latest
    ports:
      - "6380:6379"
    restart: always
    networks:
      - bysooq-network

  nginx:
    image: nginx:latest
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
      - ./api:/var/www/html/api
      - ./backend:/var/www/html/backend
    ports:
      - 80:80
    depends_on:
      - backend
      - api
    networks:
      - bysooq-network

networks:
  bysooq-network:
    driver: bridge

nginx default.conf

nginx

server {
    listen 80;
    server_name localhost;
    client_max_body_size 100M;
    index index.php;

    # API Service - Must come first with strict matching
    location ~ ^/api(/.*)?$ {
        root /var/www/html/api/web;
        try_files $1 $1/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass api:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root/index.php;
            fastcgi_param REQUEST_URI $1$is_args$args;
        }
    }

    # Backend Service
    location / {
        root /var/www/html/backend/web;
        try_files $uri $uri/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass backend:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }
}

O que eu espero:

Solicitações para /api/* devem ir para o serviço de API.

Outras solicitações devem ser encaminhadas para o serviço de backend.

O que acontece:

Todas as solicitações (mesmo /api/...) são tratadas pelo backend.

Pergunta: Como posso configurar corretamente o NGINX para rotear solicitações /api/* para o serviço de API e outras solicitações para o serviço de backend?

Desde já, obrigado!

nginx
  • 1 respostas
  • 51 Views
Martin Hope
Jerome WAGNER
Asked: 2025-03-26 00:15:22 +0800 CST

Manipulação de bots que escaneiam milhares de URLs em busca de configurações de segurança incorretas

  • 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
  • 2 respostas
  • 74 Views
Martin Hope
natli
Asked: 2025-03-25 02:19:20 +0800 CST

O filtro fail2ban não está sendo acionado, mesmo que o regex corresponda

  • 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
  • 1 respostas
  • 80 Views
Martin Hope
Rekiel
Asked: 2025-03-22 23:10:50 +0800 CST

403 Proibido com Nginx Proxy Manager

  • 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
  • 1 respostas
  • 57 Views
Martin Hope
Quinnell
Asked: 2025-03-22 03:20:45 +0800 CST

Redirecionando um caminho de subdomínio específico usando Nginx sem substituir caminhos gerenciados pela Synology

  • 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
  • 1 respostas
  • 29 Views
Martin Hope
Kevin Schulz
Asked: 2025-03-21 01:37:09 +0800 CST

Como restringir o acesso a um serviço web no meu VPS através do endereço IP do servidor para somente domínio com SSL?

  • 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
  • 1 respostas
  • 189 Views
Martin Hope
ShadowEagle
Asked: 2025-03-14 22:16:25 +0800 CST

Nginx - Intercepta apenas 404 do backend e mostra página de erro personalizada

  • 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
  • 1 respostas
  • 61 Views
Martin Hope
Lifeboy
Asked: 2025-03-12 02:35:32 +0800 CST

Nginx e acne.sh LE certs: Erro de verificação: Resposta inválida de .well-known/acme-challenge

  • 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
  • 1 respostas
  • 120 Views
Martin Hope
RDK
Asked: 2025-03-02 00:22:18 +0800 CST

Configurar uma prisão Fail2ban para capturar o código de status 302 para um arquivo específico

  • 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
  • 1 respostas
  • 138 Views
Martin Hope
Dream59
Asked: 2025-02-24 22:11:26 +0800 CST

Como os bots ainda estão enviando solicitações para meu serviço AWS ECS Fargate, apesar dos grupos de segurança bloquearem o acesso direto ao IP?

  • 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
  • 3 respostas
  • 78 Views

Sidebar

Stats

  • Perguntas 205573
  • respostas 270741
  • best respostas 135370
  • utilizador 68524
  • Highest score
  • respostas
  • Marko Smith

    Você pode passar usuário/passar para autenticação básica HTTP em parâmetros de URL?

    • 5 respostas
  • Marko Smith

    Ping uma porta específica

    • 18 respostas
  • Marko Smith

    Verifique se a porta está aberta ou fechada em um servidor Linux?

    • 7 respostas
  • Marko Smith

    Como automatizar o login SSH com senha?

    • 10 respostas
  • Marko Smith

    Como posso dizer ao Git para Windows onde encontrar minha chave RSA privada?

    • 30 respostas
  • Marko Smith

    Qual é o nome de usuário/senha de superusuário padrão para postgres após uma nova instalação?

    • 5 respostas
  • Marko Smith

    Qual porta o SFTP usa?

    • 6 respostas
  • Marko Smith

    Linha de comando para listar usuários em um grupo do Windows Active Directory?

    • 9 respostas
  • Marko Smith

    O que é um arquivo Pem e como ele difere de outros formatos de arquivo de chave gerada pelo OpenSSL?

    • 3 respostas
  • Marko Smith

    Como determinar se uma variável bash está vazia?

    • 15 respostas
  • Martin Hope
    Davie Ping uma porta específica 2009-10-09 01:57:50 +0800 CST
  • Martin Hope
    kernel O scp pode copiar diretórios recursivamente? 2011-04-29 20:24:45 +0800 CST
  • Martin Hope
    Robert ssh retorna "Proprietário incorreto ou permissões em ~/.ssh/config" 2011-03-30 10:15:48 +0800 CST
  • Martin Hope
    Eonil Como automatizar o login SSH com senha? 2011-03-02 03:07:12 +0800 CST
  • Martin Hope
    gunwin Como lidar com um servidor comprometido? 2011-01-03 13:31:27 +0800 CST
  • Martin Hope
    Tom Feiner Como posso classificar a saída du -h por tamanho 2009-02-26 05:42:42 +0800 CST
  • Martin Hope
    Noah Goodrich O que é um arquivo Pem e como ele difere de outros formatos de arquivo de chave gerada pelo OpenSSL? 2009-05-19 18:24:42 +0800 CST
  • Martin Hope
    Brent Como determinar se uma variável bash está vazia? 2009-05-13 09:54:48 +0800 CST

Hot tag

linux nginx windows networking ubuntu domain-name-system amazon-web-services active-directory apache-2.4 ssh

Explore

  • Início
  • Perguntas
    • Recentes
    • Highest score
  • tag
  • help

Footer

AskOverflow.Dev

About Us

  • About Us
  • Contact Us

Legal Stuff

  • Privacy Policy

Language

  • Pt
  • Server
  • Unix

© 2023 AskOverflow.DEV All Rights Reserve