# Schermare le aree admin con IP, VPN o protezione aggiuntiva

> Proteggere l'area admin con whitelist IP, VPN o accesso preliminare: quale metodo scegliere, insidie dietro CDN e proxy, con configurazione e test.

Fonte: https://phpsos.de/it/blog/admin-bereiche-abschirmen/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** l'area admin si protegge nel modo più efficace aprendola solo a reti note: con una whitelist di indirizzi IP nel server web, tramite una VPN con indirizzo di uscita fisso o con un secondo accesso preliminare. Contano un elenco completo di tutti gli indirizzi di amministrazione, il corretto trattamento di proxy e CDN e un test dall'esterno. La schermatura integra l'autenticazione a due fattori e gli aggiornamenti, non li sostituisce.

## Perché il backend è aperto, in fondo?

In molte aziende, la settimana scorsa gli admin hanno aggiornato PHP e riavviato i worker. Chi poi guarda i log di accesso spesso nota un'altra cosa: la pagina di login del CMS, lo strumento per il database e il pannello di hosting vengono richiamati ventiquattr'ore su ventiquattro da tutto il mondo. Servono però solo a una manciata di persone del proprio team.

Ognuno di questi indirizzi è superficie di attacco. I moduli di login vengono provati a tentativi, gli strumenti di amministrazione contengono vulnerabilità proprie e i plugin per il backend sono spesso verificati meno bene del nucleo di un CMS. Se gli estranei non raggiungono affatto queste aree, molti attacchi cadono nel vuoto prima di cominciare.

Detto onestamente: contro PHP2Shell in sé questo aiuta poco. Le vulnerabilità si trovano nell'interprete e, secondo php.net, si possono innescare senza autenticazione tramite pagine PHP pubbliche. La schermatura del backend è un hardening duraturo, non una patch d'emergenza.

## Proteggere l'area admin con IP, VPN o secondo accesso

Non esiste un unico metodo giusto. Conta come lavora il suo team e dove gira il sito.

| Metodo | Adatto per | Limite |
|---|---|---|
| Whitelist IP nel server web | Ufficio con indirizzo fisso, piccoli team | Indirizzi variabili in smart working, manutenzione dell'elenco |
| VPN con indirizzo di uscita fisso | Team distribuiti, fornitori di servizi | La VPN stessa deve essere ben protetta e aggiornata |
| Accesso preliminare (autenticazione HTTP) | Integrazione, se non è possibile un indirizzo fisso | Password aggiuntiva, sensata solo insieme a TLS |
| Certificati client | Pochi dispositivi gestiti in modo stabile | Rilascio e revoca dei certificati richiedono disciplina |
| Hostname proprio solo nella rete interna | Ambienti più grandi con DNS interno | Modifica dell'applicazione, non ogni CMS lo supporta |

Nella pratica si rivela valida una combinazione: autorizzazione solo per la VPN o la rete aziendale, più un secondo accesso come livello di riserva. Il login vero e proprio nel CMS resta con l'autenticazione a due fattori, come descritto nella guida [Autenticazione a due fattori per gli accessi admin](https://phpsos.de/it/ratgeber/zwei-faktor-admin/).

## Quali indirizzi fanno parte del backend, in realtà?

Il punto debole più frequente non è la tecnica, ma un elenco incompleto. Proceda quindi in quest'ordine:

1. **Rilevare le pagine di login** del CMS o dello shop, compresi gli indirizzi di login alternativi creati dai plugin.
2. **Cercare gli strumenti di amministrazione:** interfacce per database, file manager, script di installazione, pagine di stato e monitoraggio.
3. **Includere i pannelli di hosting e di server**, che spesso girano su porte proprie.
4. **Controllare le istanze di test e staging**, che spesso usano le stesse credenziali del sito live.
5. **Delimitare le interfacce:** alcuni percorsi del backend vengono richiamati anche dal frontend pubblico, ad esempio per richieste Ajax. Non vanno bloccati alla cieca, altrimenti si rompono moduli o carrelli.

Il punto cinque è il motivo per cui una schermatura va sempre provata. In WordPress, ad esempio, un file nella cartella admin viene usato anche per funzioni pubbliche.

## Configurazione: whitelist IP più secondo accesso

Con Nginx si possono combinare entrambe le condizioni. Con `satisfy all` una richiesta deve provenire da una rete autorizzata e superare in più il secondo accesso. Percorso, indirizzi e passaggio a PHP sono segnaposto:

```nginx
location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # rete aziendale (segnaposto)
    allow 198.51.100.10;     # uscita VPN (segnaposto)
    deny  all;

    auth_basic           "Interner Bereich";
    auth_basic_user_file /etc/nginx/htpasswd-backend;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}
```

La location PHP annidata è importante: con `^~` le altre regole per `.php` non vengono più valutate. Con Apache si ottiene lo stesso risultato con un blocco in cui devono valere entrambe le condizioni:

```apache
<Location "/backend">
    AuthType Basic
    AuthName "Interner Bereich"
    AuthUserFile /etc/apache2/htpasswd-backend
    <RequireAll>
        Require ip 192.0.2.0/24 198.51.100.10
        Require valid-user
    </RequireAll>
</Location>
```

Il file delle password va collocato fuori dal webroot. Il secondo accesso trasmette le credenziali a ogni richiesta, quindi lo si usi solo tramite HTTPS.

> **Importante:**
> Prima di ogni modifica tenga aperta una seconda via d'accesso al server, ad esempio una sessione SSH già attiva. Chi si chiude fuori, altrimenti, ha bisogno dell'hoster.

## Le insidie: CDN, proxy, IPv6 e smart working

Se il suo sito si trova dietro una CDN come Cloudflare o un load balancer, il server web vede in un primo momento solo i loro indirizzi. Una whitelist IP bloccherebbe allora tutti oppure lascerebbe passare tutti. Il server web deve riprendere l'indirizzo reale da un'intestazione: con Nginx tramite `set_real_ip_from` e `real_ip_header`, con Apache tramite `mod_remoteip`.

Vale questo: accettare l'intestazione solo dagli indirizzi del proprio proxy. Altrimenti qualunque visitatore può simulare un'origine a piacere. Altrettanto importante è che il server di origine non sia raggiungibile direttamente, perché altrimenti il proxy con le sue regole può essere aggirato. Indicazioni in merito si trovano in [Firewall per server web](https://phpsos.de/it/blog/firewall-fuer-webserver/).

Altri due punti vengono spesso trascurati. Se il server è raggiungibile via IPv6, anche gli indirizzi IPv6 della sua rete richiedono una voce, altrimenti gli admin con IPv6 si ritrovano davanti a un blocco. E le connessioni Internet private cambiano indirizzo con regolarità. Per lo smart working e i fornitori esterni una VPN è quindi di solito la soluzione più stabile.

## Come verificare che la schermatura funzioni

Una regola non testata non si considera attuata. Verifichi da una connessione esterna alla rete aziendale, ad esempio tramite la rete mobile:

```bash
# Atteso: 403 (bloccato) oppure 401 (richiesto il secondo accesso)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Verificare direttamente anche i file PHP, non solo la directory
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
```

Poi le stesse chiamate dalla rete aziendale o dalla VPN: lì la pagina deve essere raggiungibile. Controlli quindi il frontend pubblico, cioè moduli, ricerca e carrello. Nei log dei giorni seguenti gli accessi agli indirizzi admin dovrebbero comparire quasi solo più con stato 401 o 403.

Se l'area finora era aperta, vale la pena dare un'occhiata agli account esistenti. Come trovare amministratori sconosciuti lo descrive [Trovare account admin sconosciuti in CMS e server](https://phpsos.de/it/blog/fremde-admin-konten-finden/). In aggiunta, una protezione contro i tentativi di massa frena gli attacchi, vedi [Proteggere i login admin dal brute force](https://phpsos.de/it/ratgeber/brute-force-login-schutz/).

## Come aiuta concretamente PHP SOS?

- Rileviamo tutti gli indirizzi di amministrazione dei suoi siti, pannelli e strumenti e li separiamo dai percorsi necessari al pubblico.
- Scegliamo con Lei il metodo adatto, in base a dimensione del team, smart working e hosting.
- Attuiamo le regole nel server web, tenendo conto di CDN, proxy e IPv6 e lasciando sempre aperta una via di ritorno.
- Testiamo dall'esterno e dall'interno e consegniamo una breve documentazione con le reti autorizzate.

La schermatura delle aree admin fa parte del nostro [hardening del server per server web PHP](https://phpsos.de/it/leistungen/server-haertung/).


## Domande frequenti

**Non basta una password sicura per il login del CMS?**  
Una password robusta e l'autenticazione a due fattori sono obbligatorie, ma proteggono solo l'accesso in sé. Le vulnerabilità nelle pagine di login, nei plugin o negli strumenti di amministrazione restano raggiungibili da chiunque. Una schermatura a livello di rete o di server web fa sì che gli estranei non arrivino nemmeno fin lì.

**Che cosa faccio se i miei collaboratori hanno indirizzi IP variabili?**  
In tal caso una VPN con indirizzo di uscita fisso è di solito la soluzione migliore rispetto a un elenco di singoli indirizzi. Tutti gli admin si collegano prima alla VPN e il server web autorizza solo il suo indirizzo. In alternativa è adatto un secondo accesso preliminare.

**Un blocco per IP funziona anche dietro Cloudflare o un load balancer?**  
Solo se il server web riprende l'indirizzo reale del visitatore da un'intestazione affidabile e accetta questa intestazione esclusivamente dal proprio proxy. Altrimenti vede soltanto gli indirizzi del proxy oppure si fida di indicazioni falsificate. Inoltre il server di origine non dovrebbe essere raggiungibile direttamente da Internet.

**Un'area admin schermata protegge da PHP2Shell?**  
Solo in misura molto limitata. Le vulnerabilità di PHP2Shell si trovano nell'interprete PHP e si possono attaccare senza autenticazione tramite qualsiasi pagina PHP pubblica. Contro PHP2Shell aiuta l'aggiornamento di PHP con il successivo riavvio di tutti i worker; la schermatura riduce soltanto la restante superficie di attacco.

## Fonti

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [Documentazione di Nginx](https://nginx.org/en/docs/)
- [Apache HTTP Server: documentazione](https://httpd.apache.org/docs/)