Il pannello di amministrazione di un sito, che sia /wp-admin, /administrator o un altro indirizzo, è il punto più sondato da bot automatici in cerca di credenziali deboli o già rubate altrove. Non serve avere un sito importante per diventare un bersaglio: basta essere online. Questa guida spiega cosa succede davvero durante un attacco agli accessi amministrativi, quali presidi lo bloccano per davvero e quali invece sono falsi miti.
Il pannello di amministrazione di un sito, che sia /wp-admin, /administrator o un altro indirizzo riservato, è il punto più sondato da bot automatici in cerca di una combinazione di username e password che funzioni. Non serve gestire un sito importante per diventare un bersaglio: basta essere raggiungibili su internet. La buona notizia è che i presidi che fermano la quasi totalità di questi tentativi sono pochi, noti, e non richiedono un budget di sicurezza enterprise.
Questa guida è per chi gestisce un sito aziendale o un ecommerce su WordPress, Joomla o una piattaforma simile e vuole capire cosa mettere davvero in sicurezza sugli accessi, non un elenco di consigli generici. Se il sito è già compromesso, la procedura da seguire nelle prime ore è un altro lavoro, descritto nella guida su cosa fare se il sito è stato hackerato. Se invece sospetti che qualcuno sia già entrato senza lasciare tracce evidenti, i segnali sono nella guida su sito compromesso senza saperlo.
Cosa succede quando il pannello viene attaccato
Nella grande maggioranza dei casi non c'è una persona che sceglie il tuo sito: c'è uno script che scansiona in continuazione internet in cerca di pannelli di amministrazione raggiungibili, e quando ne trova uno prova in sequenza combinazioni di username e password. Due varianti ricorrono più spesso. Il brute-force in senso stretto prova molte password diverse contro un username noto o ricorrente, come "admin". Il credential stuffing è più insidioso: usa coppie di username e password già trapelate da violazioni di altri siti, scommettendo che qualcuno abbia riusato la stessa password altrove, cosa che succede più spesso di quanto si creda.
Chi gestisce questi script non lavora quasi mai da un solo indirizzo IP. Usa reti di computer compromessi (botnet) che distribuiscono i tentativi su centinaia di indirizzi diversi, proprio per aggirare blocchi semplici legati all'IP. Se l'attacco va a segno, il passo successivo tipico non è "vandalizzare" il sito: è installare una backdoor discreta, spesso una webshell, che garantisce un accesso che sopravvive anche al cambio della password rubata. Il meccanismo di una webshell, e come riconoscerla, è descritto nella guida su cos'è una webshell e come bloccarla.
Perché un pannello diventa un bersaglio facile
Tre condizioni, quasi sempre presenti insieme, trasformano un pannello normale in un bersaglio comodo. La prima è un username prevedibile: "admin", il nome a dominio, o il nome del titolare scritto nell'email di contatto. La seconda è una password debole o riusata su più servizi, spesso scelta per essere facile da ricordare piuttosto che difficile da indovinare. La terza, la più sottovalutata, è l'assenza di un limite ai tentativi: se il pannello accetta tentativi illimitati senza rallentare o bloccare nulla, uno script può provare migliaia di combinazioni senza alcun costo per l'attaccante.
A queste si aggiunge spesso una quarta condizione tecnica: endpoint accessori lasciati attivi senza bisogno reale. Su WordPress, per esempio, il file xmlrpc.php può essere sfruttato per automatizzare tentativi di accesso in blocco (un singolo pacchetto può contenere centinaia di coppie username/password), ed è comune disattivarlo quando non serve a integrazioni che lo richiedono davvero.
KeideaCMS
Vuoi sapere se gli accessi del tuo sito attuale sono esposti?
Misure di sicurezza dichiarate →Contatti
I presidi che bloccano la maggior parte degli attacchi
Non serve un budget di sicurezza enterprise. Servono pochi presidi, applicati davvero, non solo dichiarati.
Password univoca e lunga. Le linee guida NIST SP800-63B, richiamate da OWASP, indicano che senza autenticazione a più fattori una password sotto i 15 caratteri è da considerare debole; con il 2FA attivo la soglia scende a 8. Meglio una passphrase lunga e unica, gestita con un password manager, che una password complessa ma riusata su più siti.
Autenticazione a due fattori (2FA/MFA). È il presidio singolo più efficace: OWASP cita un'analisi Microsoft secondo cui fermerebbe il 99,9% delle violazioni di account legate alla password. CISA raccomanda, dove possibile, forme di MFA resistenti al phishing come FIDO/WebAuthn; in alternativa, un'app di autenticazione (TOTP) è comunque molto meglio di nessun secondo fattore.
Limite ai tentativi falliti. OWASP consiglia di definire tre numeri: quanti tentativi falliti sono ammessi, in quale finestra di tempo, e per quanto tempo scatta il blocco dopo. Il contatore andrebbe legato all'account, non solo all'indirizzo IP, perché un IP si cambia facilmente con una botnet.
Disattivare ciò che non serve. Endpoint come xmlrpc.php su WordPress, se non li usa nessuna integrazione reale, vanno disattivati: riducono la superficie d'attacco senza costare nulla in funzionalità.
Log e notifiche degli accessi. Sapere quando e da dove qualcuno ha effettuato (o tentato) l'accesso al pannello permette di accorgersi di un'anomalia prima che diventi un incidente, non dopo.
I presidi a colpo d'occhio
Una sintesi dei cinque presidi, con dove si configurano tipicamente su un sito WordPress o Joomla autogestito.
| Presidio | Cosa blocca | Dove si configura |
|---|---|---|
| Password univoca, lunga | Tentativi a dizionario, password riusate | Password manager, policy del CMS |
| 2FA / MFA (TOTP o FIDO) | Accesso con password rubata o indovinata | Plugin/estensione CMS, o nativo in piattaforma |
| Limite ai tentativi falliti | Scansioni automatiche su larga scala | Plugin/estensione CMS, firewall applicativo, hosting |
| Disattivare endpoint non usati | Automazione su larga scala (es. xmlrpc.php) | Configurazione CMS o file di sistema (.htaccess) |
| Log e notifiche | Tempo di reazione a un'anomalia | Plugin di audit, pannello hosting, piattaforma gestita |
Cosa non basta: i falsi miti
Alcune pratiche diffuse danno una sensazione di sicurezza superiore a quella reale. Vale la pena essere precisi, perché la differenza tra "sembra protetto" ed "è protetto" è esattamente dove si infilano gli attacchi riusciti.
Spostare l'indirizzo di login (es. da wp-login.php a un URL personalizzato) riduce il traffico dei bot più pigri, ma è sicurezza per occultamento: chi conosce la piattaforma trova comunque il nuovo indirizzo, e da sola non sostituisce 2FA e limite ai tentativi. Un CAPTCHA senza limite ai tentativi rallenta ma non ferma gli script più sofisticati, che oggi spesso includono moduli per risolverlo. Bloccare solo per indirizzo IP, senza legare il contatore all'account, si aggira con una botnet che distribuisce i tentativi su centinaia di indirizzi diversi: OWASP lo segnala esplicitamente come una scappatoia da chiudere. L'assenza di un attacco visibile finora non è una prova di sicurezza: significa solo che non te ne sei accorto, o che i log non vengono controllati.
Cosa dichiara oggi KeideaCMS (e cosa no)
Sulla pagina sicurezza, verificata il 16 ottobre 2026, KeideaCMS dichiara per gli accessi amministrativi: autenticazione a due fattori con standard TOTP (RFC 6238), compatibile con app come Google Authenticator e Authy; un sistema di dispositivi "fidati" che evita di richiedere il 2FA a ogni accesso per 30 giorni, con un token crittografico a 256 bit; un limite ai tentativi con soglia configurabile (di default 5 tentativi in un'ora), oltre la quale l'indirizzo IP viene inserito automaticamente in una blacklist per 24 ore; e un registro di accessi, modifiche e attacchi bloccati, con conservazione configurabile fino a oltre 90 giorni.
Va detto con precisione quello che quella pagina non dichiara: un meccanismo di blocco permanente dell'account dopo ripetuti tentativi falliti, e il dettaglio completo di quali eventi, oltre alla soglia sui tentativi, fanno scattare la blacklist automatica. Non presentiamo queste misure come una garanzia di invulnerabilità: nessun presidio tecnico lo è. Sono misure verificabili sulla pagina pubblica, che riducono in modo concreto la superficie d'attacco rispetto a un pannello senza 2FA e senza limite ai tentativi. Hosting, aggiornamenti e supporto sono compresi nel canone dei piani; un confronto punto per punto con altre strade è nella pagina di confronto.
Se gestisci tu stesso un sito WordPress o Joomla e vuoi capire chi dovrebbe occuparsi di questi presidi nel tempo, non solo attivarli una volta, il quadro completo è nella guida sulla sicurezza gestita del sito web. Se invece il backup è il presidio che ti manca, la guida di riferimento è su backup del sito web.
Checklist di autoverifica
Dieci minuti per capire a che punto sei. Più caselle riesci a spuntare, più il pannello è difficile da violare con un attacco automatico.
Nessun utente amministratore si chiama "admin" o ha come username il nome a dominio.
Le password degli account con accesso al pannello sono uniche, lunghe, generate o gestite con un password manager.
Il 2FA è attivo su tutti gli account con privilegi di amministratore, non solo sul principale.
Esiste un limite ai tentativi falliti, con un numero, una finestra di tempo e una durata del blocco definiti, non lasciati al caso.
Gli endpoint non usati da nessuna integrazione reale (es. xmlrpc.php) sono disattivati.
Qualcuno controlla, o riceve una notifica, quando ci sono accessi o tentativi anomali al pannello.
Gli account di ex collaboratori o di fornitori che non lavorano più al sito sono stati disattivati, non solo "dimenticati".
Proteggere gli accessi amministrativi non elimina il rischio di un attacco: lo rende molto più costoso per chi lo tenta, al punto da scoraggiare la quasi totalità degli script automatici che oggi scansionano il web in cerca del pannello più debole, non del più importante.
Fonti e data di controllo
Consultate il 16 ottobre 2026. Le guide di settore descrivono pratiche raccomandate, non un obbligo automatico uguale per ogni sito. La pagina prodotto descrive ciò che il fornitore dichiara, non una prova di superiorità.
OWASP, Authentication Cheat Sheet (account lockout legato all'account, soglie NIST SP800-63B sulla lunghezza delle password, MFA ed efficacia contro gli attacchi legati alla password).
CISA, guida alla Multi-Factor Authentication (MFA resistente al phishing, FIDO/WebAuthn).
KeideaCMS, pagina sicurezza (2FA TOTP, limite tentativi, blacklist IP, audit trail).
Ricerca e prima bozza assistite da strumenti di intelligenza artificiale. Autore proposto e revisore proposto: Antonio Cicirelli, in attesa di verifica umana. La byline pubblica va assegnata solo dopo l'approvazione.
