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!

May 12 14:54:20 cp dovecot: imap-login: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=info@smsoft.it, method=PLAIN, rip=X.XX.XX.XX, lip=Y.YY.YY.YY, TLS: Connection closed, session=
May 12 15:13:22 cp dovecot: imap-login: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=info@smsoft.it, method=PLAIN, rip=X.XX.XX.XX, lip=Y.YY.YY.YY, TLS: Connection closed, session=

Strano, comuqnue ricontrolliamo i dati di connessione e sono corretti; allora proviamo ad accedere alla webmail e neanche li si riusciva ad accedere.

Dopo qualche verifica, abbiamo provato la connessione da un PC esterno alla rete e qui funzionava tutto correttamente, si riusciva ad accedere sia da client email che tramite webmail.

Ecco, se usate cPanel ed avete una situazione come questa, sicuramente bisogna accedere alla sezione cPHulk Brute Force Protection del WHM e verificare se l’IP è stato inserito in History Reports. In questo caso occorre verificare come mai l’IP è finito “attenzionato” da cPHulk, sistemare le configurazioni nel client e poi aggiungere l’IP i whitelist oppure attendere che il BAN venga rimosso in automatico.

enjoy!

C’è uno script PHP che invia posta tramite la famosa libreria PHPMailer ed usando un account email attivo su un server esterno; d’un tratto mi sono accorto (probabilmente a seguito di qualche aggiornamento, magari a seguito della segnalazione “Outbound SMTP connections are unrestricted. Enable SMTP Restrictions in the “SMTP Restrictions” area” ricevuta d WHM) che la posta non veniva più inviata.

Provando lo script “a mano” da CLI, funzionava regolarmente, mentre richiamato via web, non funzionava più.

Dopo un po’ di prove, ho attivato il debug su PHPMailer e mi sono accorto (anche se mi sembrava davvero molto strano) che seppur indicato un server mail esterno al cpanel, il sistema continuava a tentare l’invio effettuando una connessione SMTP al server mail locale.

In effetti, tra i vari errori mostrati (provando ad usare un FQDN o anche direttamente un IP remoto) avevo anche qualcosa tipo:

Peer certificate CN=hostname' did not match expected CN=remote.domain'

La cosa era davvero molto strana, ho pensato ad un problema DNS, a qualche strana anomalia, ad un errore dello script PHP, insomma le ho pensate tutte.

Alla fine, mi sono accorto di una strana funzione attiva in WHM che faceva proprio questo, ovvero forzava l’uso del server mail locale al posto di un server mail esterno.

Tale funzionalità è chiamata Restrict SMTP Tweak e può essere disabilitata in questo modo:

• accedere al WHM
• andare in “Home » Server Configuration » Tweak Settings.”
• cercare FKA nella casella di ricerca, oppure selezionare il TAB “Mail” ed andare alla sezione “Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)“
• Identificare la direttiva “Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)” ed impostarla ad “off”
• premere sul pulsante “Save”

Ecco fatto, ora la posta verrà iviata come ci si aspetta che succeda.

enjoy!

Qualora si renda necessaria la modifica per un server con cPanel installato, consiglio di seguire la procedura prevista dal pannello. Vediamo come fare:

1 – Modificare l’hostname dal WHM in Home »Networking Setup »Change Hostname

2 – rigenerare i certificati SSL accedendo al terminale ed eseguendo:

/usr/local/cpanel/bin/checkallsslcert

A volte, dopo tali modifiche, capita che l’accesso FTP dia errore a causa del certificato SSL non corretto. Se si prova a riavviare il server FTP si vedrà l’errore:

Couldn't load the DH parameters file /etc/ssl/private/pure-ftpd-dhparams.pem

In questo caso, digitare:

openssl dhparam -out /etc/ssl/private/pure-ftpd-dhparams.pem 2048

e poi riavviare il servizio FTP:

/scripts/restartsrv_pureftpd

enjoy!