102.219.170.XXX - - [30/Mar/2026:19:45:13 +0200] "GET /16/page/15/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
103.189.194.XXX- - [30/Mar/2026:19:45:13 +0200] "GET /35/page/42/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
200.8.173.XXX - - [30/Mar/2026:19:45:14 +0200] "GET /21/page/23/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"

Si tratta sicuramente di uno scanner/bot che prova URL generati automaticamente e che non esistono nel sito. Come anticipato, il sito è attivo su WHM/cPanel ed ha nginx come reverse proxy (EA4 + nginx).

La soluzione più efficace in questo caso è creare una regola di nginx che blocchi le richieste prima ancora di essere passate ad apache.

Il file con le regole di nginx va posizionato in /etc/nginx/conf.d/users/[USERNAME]/ e chiamato con un suffisso .conf. In questo caso specifico possiamo scrivere nel file:

location ~ ^/[0-9]+/page/ {
access_log off;
return 444;
}

e poi riavviare nginx. Questo fa si che le richieste vengano direttamente chiuse senza risposta, senza scrivere log e senza avviare PHP.

enjoy!

In modo molto semplice è possibile usare direttamente nginx per attivare la verifica sul passaggio di un parametro token sulle richieste.

Nel file di configurazione del virtualhost definiamo innanzitutto il recupero del token:

# Estraggo il token Bearer dall'header Authorization
map $http_authorization $bearer_token {
         default         "";
         "~*^Bearer\s+(.+)$"  $1;
}

# Mappa il token: accetta header X-API-Token, query param ?token=, oppure Authorization: Bearer
# la regex sulla seconda map usa ~* (case-insensitive), sostituire ~* con ~ per case-sensitive
map "$http_x_api_token$arg_token$bearer_token" $auth_token_valid {
        default             0;
        #"~*${SHARED_TOKEN}"  1;
        "~*XXXXXXXXXXXXX" 1;
}

dove XXXXXXXXXXXXX è il nostro token che possiamo generare facilmente con:

openssl rand -hex 32

Ora nella rotta da proteggere, ipotizziamo tutto /, inseriamo la verifica del token:

        location / {
            # Verifica token
            if ($auth_token_valid = 0) {
                return 401 '{"error":"Unauthorized: missing or invalid token"}';
            }
...
...

e se nginx è usato come reverse proxy, inserire sotto la parte di verifica del token anche:

            # Rimuove il query param ?token= prima di passare al backend
            set $clean_uri $request_uri;
            # Rimuove il token dall'header verso il backend
            proxy_set_header X-API-Token "";

Bene, ora basterà aggiungere l’header X-API-Token, ad esempio:

curl "https://url_sito_web" -H "X-API-Token: XXXXXXXXX"

oppure il parametro ?token= nell’url:

curl "https://url_sito_web?token= XXXXXXXXX"

oppure (ad esempio per Ollama) modalità OpenAI compatibile:

curl "https://url_sito_web" -H "Authorization: Bearer XXXXXXXXX"

Escludere le chiamate GET ed HEAD dalla verifica token

Partendo dalla configurazione precedente, se volessimo escludere le chiamate di tipo GET e HEAD dalla verifica del token, potremmo modificare la configurazione come segue:

Sotto il blocco map precedente in cui estraiamo la variabile $auth_token_valid, aggiungiamo l’estrazione di una nuova variabile $auth_is_valid:

# Bypass auth per GET/HEAD, altrimenti controlla il token
map $request_method $auth_is_valid {
    default $auth_token_valid; # POST, PUT, DELETE, ecc. → controlla token
    GET 1; # GET → sempre autorizzato
    HEAD 1; # HEAD → sempre autorizzato (opzionale)
}

e poi modifichiamo il blocco di verifica dentro location, controllando $auth_is_valid piuttosto che $auth_token_valid così:

    location / {
      # Verifica token
      if ($auth_is_valid = 0) {
        return 401 '{"error":"Unauthorized: missing or invalid token"}';
      }

Nota

Se bisogna escludere i GET solo su certi path e non globalmente, si può anche fare con una location separata:

# Path pubblici in GET (es. /api/models, /api/tags)
location ~* ^/(api/models|api/tags) {
    limit_except GET { deny all; }  # solo GET ammesso senza token
    # ... proxy pass
}

enjoy!

La cosa più semplice è aprire il file nginx.conf e modificare la direttiva log_format per aggiungere anche la variabile upstream_cache_status. Ad esempio qualcosa del genere:

log_format combined_custom '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" $upstream_cache_status';

Riavviamo nginx e poi andiamo ora a controllare il file di log con “tail -f” ed alla fine di ogni riga sarà mostrata una parola chiave che ci fa capire come il contenuto è stato recuperato, es:

MISS – La risposta non è stata trovata nella cache ed è stata quindi recuperata da un server di origine. La risposta potrebbe quindi essere stata memorizzata nella cache.
BYPASS – La risposta è stata recuperata dal server di origine anziché essere servita dalla cache perché la richiesta corrispondeva a una direttiva proxy_cache_bypass. La risposta potrebbe quindi essere stata memorizzata nella cache.
EXPIRED – La voce nella cache è scaduta. La risposta contiene contenuti aggiornati dal server di origine.
STALE – Il contenuto è obsoleto perché il server di origine non risponde correttamente ed è stato configurato proxy_cache_use_stale.
UPDATING – Il contenuto è obsoleto perché la voce è attualmente in fase di aggiornamento in risposta a una richiesta precedente ed è configurato l'aggiornamento di proxy_cache_use_stale.
REVALIDATED – La direttiva proxy_cache_revalidate è stata abilitata e NGINX ha verificato che il contenuto corrente nella cache fosse ancora valido (If-Modified-Since o If-None-Match).
HIT – La risposta contiene contenuti validi e aggiornati direttamente dalla cache.

enjoy!

The Requested nginx Plugin Does Not Appear to Be Installed

In questo caso basterà installare il necesario plugin e poi riprovare:

apt install python3-certbot-nginx

verificare che il plugin sia installato su certbot:

certbot plugins

e riprovare:

certbot --nginx

enjoy!

location ~ ^/curioso/.* {
        auth_basic            "Admin";
        auth_basic_user_file  /etc/nginx/nginx.htpasswd;
}

Per generare i dati (username/password) per l’accesso, possiamo usare il seguente comando:

printf "read -p Username:\ ; echo $REPLY:openssl passwd -apr1\n" >>  >> /etc/nginx/nginx.htpasswd

enjoy!

Per loggare il corretto IP del visitatore finale dobbiamo innanzitutto recuperare l’IP del bilanciatore/proxy e lo possiamo fare velocemente dai log in /var/log/nginx. Recuperato l’IP, es 10.10.10.10, possiamo aprire il file /etc/nginx/nginx.conf ed aggiungere, nella sezione http{}, le seguenti direttive:

set_real_ip_from 10.10.10.10;
real_ip_header X-FORWARDED-FOR;
real_ip_recursive on;

ed infine riavviare:

systemctl restart nginx

Ora potremo controllare, nei file di log di nginx, che gli IP registrati siano quelli dei visitatori finali.

Enjoy!

apt install nginx-extras libnginx-mod-rtmp

Ora aggiungiamo in /etc/nginx/nginx.conf il seguente codice per vedere se il supporto rtmp è presente:

rtmp {
   server {
      listen 1935; # The port where RTMP will listen on. Default = 1935.
      chunk_size 4096;
      timeout 30s;
      buflen 1s;
   }
}

e poi verifichiamo la configurazione con:

nginx -t

enjoy!

Per l’installazione possiamo affidarci a let’s encrypt oppure a qualcuna delle azienda commerciali più note.

Oggi volevo però parlarvi della configurazione e non dell’installazione. Una volta installato il certificato, se non ben configurato, si avranno comunque potenziali problemi di sicurezza.

Innanzitutto consiglio https://www.ssllabs.com/ssltest/analyze.html per verificare la situazione del certificato HTTPS del proprio sito.

Per quanto riguarda invece la configurazione, consiglio di dare un’occhiata a https://ssl-config.mozilla.org/. Dal portale si sceglie il tipo di server web, quanto la configurazione deve essere compatibile con i vecchi browser e si possono specificare la versione di server web e di openssl.

enjoy!

Ipotizziamo di avere smsoft.it.crt e smsoft.it.ca-bundle, per unire questi ceritifcati in un unico file bisogna digitare:

cat smsoft.it.crt smsoft.it.ca-bundle > smsoft.it.ca-combined.crt

e poi avremo nel file di configurazione del VH su nginx:

...
ssl_certificate /etc/nginx/ssl/smsoft.it.ca-combined.crt;
ssl_certificate_key /etc/nginx/ssl/smsoft.it.key;
...

Questo però provoca l’accodamento dei due file, infatti eseguendo:

openssl x509 -text -noout -in smsoft.it.ca-combined.crt

avremo un errore tipo:

unable to load certificate
139998757910160:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:804:

e qualcosa del genere se proviamo a riavviare nginx:

(SSL: error:0906D066:PEM routines:PEM_read_bio:bad end line)

ATTENZIONE: una cosa importante è aprire il file smsoft.it.ca-combined.crt, cercare la riga con scritto:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

e dividerla in due righe:

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

ora funzionerà tutto correttamente e potremo riavviare nginx.

enjoy!

Consiglio quindi di dare un’occhiata a https://ssl-config.mozilla.org/ per generare la corretta configurazione da inserire nel proprio server web.
In realtà il sito offre supporto anche per altri servizi server (MySQL, Postfix, ProFTPD, etc), dategli un’occhiata…

enjoy!