Archives For In Evidenza

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!

È strano, è una cosa che faccio abitualmente (e che consiglio) ma senza averne mai parlato qui sul blog. Si tratta di un trucco semplice da mettere in pratica e che -oggi- può tranquillamente sostituire il salvataggio automatico dei dati di Desktop e Documenti su iCloud, soprattutto se hai già un account su Dropbox, giusto per fare un esempio.

macOS: salvare una cartella su Dropbox automaticamente 1

Lo scopo è semplice: voglio che qualsiasi file passi dal Desktop o dalla cartella Documenti del mio MacBook, vada automaticamente a finire su Dropbox, così da poter recuperare quei file da qualsiasi altro dispositivo e dall’interfaccia web, quello che già succede su Windows (avevo parlato del junction per Windows Xp e il mklink per Windows 7 e superiori, già nel 2010). Per poter collegare una cartella all’equivalente su Dropbox, funziona praticamente alla stessa maniera, ti basterà infatti una riga di codice lanciata da Terminale.

Crea e spostati nella cartella di destinazione (es: cd Dropbox/CARTELLABACKUPDESKTOP), quindi lancia un ln -s ~/Desktop/ (nel caso in cui tu voglia clonare la cartella Desktop del tuo sistema operativo, altrimenti ~/Documents/ per la Documenti):

macOS: salvare una cartella su Dropbox automaticamente

La modifica è immediata e partirà così la sincronizzazione dei file già presenti nella cartella sorgente, sulla sua equivalente in Dropbox. Inutile dire che vale per qualsiasi sorgente e quindi destinazione, a prescindere che si tratti di Dropbox o un altro servizio (NAS compreso).

Se hai ancora dubbi in merito, lascia pure un commento in fondo all’articolo! :-)

Il messaggio che compare a video è poco eloquente, eppure segnala un evidente problema nato durante l’installazione di un software.

KB3172605 and/or KB3161608 are installed in your system. Please uninstall KB3172605 and/or KB3161608 before installing this driver.

Scoprirò in seguito che si tratta di un driver, quello bluetooth per l’esattezza. Una rapida ricerca nei forum di Microsoft ed ecco che salta immediatamente fuori la segnalazione (ce ne sono diverse altre, una in particolare è palese). Non sono il solo a lamentarlo (e fin qui era stata semplice, perché alcuni utenti in ufficio mi avevano detto di aver visto la stessa finestra comparire a tradimento da un paio di settimane), si tratta di un errore che nasce dall’accoppiata Microsoft e Lenovo System Update (in alcuni configurazioni viene anche chiamato “Lenovo – Aggiornamento e driver“, nda).

Lenovo: modificare il BIOS eliminando il Secure Boot (UEFI)

Ho fatto ulteriori ricerche, tutto sembra essere partito a luglio dello scorso anno (Microsoft yanks buggy speed-up patch KB 3161608, replaces it with KB 3172605 and 3172614), si parla -appunto- dei driver bluetooth di Intel. Microsoft ha rilasciato un paio di KB che quasi certamente avrai anche tu sulla tua macchina Lenovo, la quale però tenterà di far installare alla sua utility una nuova versione del driver durante uno dei controlli settimanali pianificati di default, i due KB di Microsoft non possono però coesistere (in questo ordine) con il fix ordinato da Lenovo:

KB3172605, KB3161608 e Lenovo System Update

KB3172605 and/or KB3161608 are installed in your system. Please uninstall KB3172605 and/or KB3161608 before installing this driver.

Partendo dal thread sul forum di Microsoft, pare che qualcuno sia uscito fuori dal tunnel disinstallando le KB manualmente, facendo seguire poi l’aggiornamento del driver così come richiesto (da Lenovo System Update), e lasciando poi che Windows Update facesse nuovamente il suo lavoro (cioè reinstallasse i due KB): answers.microsoft.com/thread/bd93ab91-5d9b-434a-a10e-d6574ca97180.

Prova ora a immaginare circa 500 macchine con lo stesso problema, capisci bene che è letteralmente impensabile intervenire così come riportato dall’utente nel forum. Potrei chiedere al nostro WSUS di rimuovere i due pacchetti e tenerli fermi (per il momento), lasciare che System Update lavori, rilasciare nuovamente i due KB. Ho notato però, dopo diversi test e ricerche, che non tutti i System Update propongono l’aggiornamento come “Critical“, a causa del fatto che alcune macchine non hanno precedentemente aggiornato quel driver (non arrivato quindi alla versione interessata dal problema), rendendo di fatto inutile questo metodo:

KB3172605, KB3161608 e Lenovo System Update 1

Ho scelto quindi di tenere fuori dai giochi il Lenovo System Update, non impedendo certo il suo utilizzo, ma andando a staccare quella che è la schedulazione che viene creata di default su ogni macchina Lenovo (la puoi verificare tu stesso avviando l’applicazione e facendo clic su Pianifica aggiornamenti). Per operare ho scelto di creare una GPO ad-hoc, ti spiego rapidamente come replicare nel tuo ambiente aziendale. Se sei un utente casalingo e vuoi risolvere rapidamente il problema, salta all’ultimo paragrafo dell’articolo :-)

Goodbye System Update

Il Lenovo System Update ha due schedulazioni predefinite che partono al logon dell’utente e una volta a settimana. La seconda è quella che si occupa del download e dell’installazione degli update definiti critici. Teoricamente ogni utente può scegliere di modificare questo comportamento andandolo a variare dall’applicazione stessa (come spiegato poco fa), la mia modifica segue il suggerimento di questo articolo e inibisce all’utente tale possibilità.

Regedit, XML, GPO

Il metodo è sempre lo stesso. La chiave di registro da modificare è la HKLM\SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler (su un sistema a 32 bit si salterà la \Wow6432Node\), il valore è lo SchedulerAbility, che cambierà da YES a NO.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler]
"SchedulerAbility"="NO"

[HKEY_LOCAL_MACHINE\SOFTWARE\Lenovo\System Update\Preferences\UserSettings\Scheduler]
"SchedulerAbility"="NO"

La chiave, trasformata in XML, darà questo risultato (non è indentato, lo so):

<?xml version="1.0" encoding="UTF-8"?>
<Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Disable Lenovo System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="HKEY_LOCAL_MACHINE"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="SOFTWARE"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Wow6432Node"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Lenovo"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Preferences"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="UserSettings"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Scheduler"><Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="SchedulerAbility" status="SchedulerAbility" image="7" changed="2017-01-16 16:01:08" uid="{8D71093F-6362-7087-5ED8-94EDBD7719C6}"><Properties action="U" displayDecimal="0" default="0" hive="HKEY_LOCAL_MACHINE" key="SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler" name="SchedulerAbility" type="REG_SZ" value="NO"/><Filters/></Registry></Collection></Collection></Collection></Collection></Collection></Collection><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Lenovo"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Preferences"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="UserSettings"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Scheduler"><Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="SchedulerAbility" status="SchedulerAbility" image="7" changed="2017-01-16 16:01:08" uid="{0D58379E-C99A-0B72-264C-4143F8AD0680}"><Properties action="U" displayDecimal="0" default="0" hive="HKEY_LOCAL_MACHINE" key="SOFTWARE\Lenovo\System Update\Preferences\UserSettings\Scheduler" name="SchedulerAbility" type="REG_SZ" value="NO"/><Filters/></Registry></Collection></Collection></Collection></Collection></Collection></Collection></Collection></Collection>

A questo punto è tutto in discesa. Dal Group Policy Management Editor crea la nuova GPO e naviga in Computer ConfigurationPreferencesWindows SettingsRegistry. Copia il codice XML che vedi qui sopra e incollalo direttamente nella finestra del Group Policy Management Editor (nella parte destra, quella del Registry), otterrai un risultato simile a quello in figura :-)

KB3172605, KB3161608 e Lenovo System Update 2

A questo punto potrai assegnare la GPO ai domini che ti interessano (mantieni il filtro di sicurezza su Authenticated Users). Non appena questa andrà ad applicarsi ai PC gestiti, nessuno più lamenterà l’anomalia (e le operazioni schedulate spariranno da Windows).

Come lo risolvo sul mio PC di casa?

Scarica la chiave di registro che trovi sul mio spazio box: app.box.com/s/v4xhf99dx8lxjbi5c0qir2l4gzhtgvpo.

Fai doppio clic sul file scaricato, conferma la modifica delle informazioni di registro e verifica che ora il tuo Lenovo System Update non effettui controlli e installazioni autonome (puoi controllarlo aprendo l’applicazione e facendo clic su Pianifica aggiornamenti, che ora dovrebbe essere completamente disabilitato).

KB3172605, KB3161608 e Lenovo System Update 3

Inutile dirlo, ma è chiaro che il mio è un work-around e non una soluzione al problema che spero Lenovo possa gestire in qualche maniera, basterebbe far saltare fuori una soluzione per mettere a posto l’anomalia e nulla più, nulla che poi non si possa gestire tramite GPO o un sistema di distribuzione software (almeno spero). Io continuerò a tenermi aggiornato tramite forum di Microsoft e Lenovo, aggiornerò questo articolo in caso ci fossero novità.

Buon lavoro! :-)

È un problema che ho affrontato qualche tempo fa e che inizialmente mi ha dato un po’ di grattacapi, salvo poi trovare casi molti simili che mi hanno aiutato a risolvere l’anomalia. Il disco di un PC si satura e la colpa è della cartella C:\Windows\Temp, invasa da file senza estensione, dal nome che comincia sempre per cab_. Perché accade? Il problema viene generato da una installazione di alcuni aggiornamenti (da Windows Update) evidentemente non andata a buon fine, non del tutto almeno, nonostante la schermata preposta di Microsoft dica che tutto va bene.

Windows: l'invasione dei CBSPersist e dei cab_ (C:WindowsTemp)

Facendo un po’ più di attenzione, si scopre che in realtà di cartella che occupa spazio ce n’è un’altra. Teoricamente dovresti trovare anomala anche la C:\Windows\Logs\CBS, all’interno della quale dovresti trovare dei file CAB veri, e un file di log dalla dimensione decisamente robusta (CBS.log). L’anomalia parte proprio da qui. Partiamo con le opportune presentazioni (recuperate con una semplice ricerca):

CBS stands for “Component-Based Servicing” and it basically is the way components get installed and uninstalled during updates. It is the reason you see “Stage 1”, “Stage 2”, and “Stage 3” during the Service Pack 1 install (for example). “Stage 2” and “Stage 3” exists for the registry keys and files that are normally locked during regular operation.

Tutto chiaro? Un log in cui ogni aggiornamento di Microsoft va a scrivere e tiene traccia di ogni movimento. Un log destinato –per forza– a crescere, e che per un comportamento assolutamente standard va a ruotare, sospendendo la scrittura, finendo in un CAB che ne riduce (di parecchio) la dimensione, e infine ne prepara uno nuovo in cui tornare a scrivere, per poi ricominciare il giro ancora e ancora.

Se per qualsivoglia motivo questo procedimento non fila liscio, il CBS.log diventa più grande del previsto, ingestibile e –soprattutto– impossibile da mettere in un CAB nei tempi previsti. Il risultato? Cartella Temp di Windows piena di tentativi falliti di comprimere quel log, cartella CBS che si ingigantisce.

Diverse le fonti dove ho trovati informazioni in merito e persone capitate nello stesso vortice, ne ho selezionate tre che mi hanno aiutato:

Riepilogando, tutto questo può accadere in qualsiasi momento e -in base alla capacità del disco e lo spazio libero da poter sfruttare- potresti accorgertene a mesi (o forse anni) di distanza. Io ho scoperto di essere soggetto al problema solo perché un utente ha lamentato poco spazio libero e mi ha fatto scoprire l’anomalia. Le operazioni da affrontare per resettare il procedimento di scrittura e archiviazione del CBS.log è questo:

  • Fermare il servizio Windows Update.
  • Rinominare la cartella della Software Distribution (C:\Windows\SoftwareDistribution).
  • Cancellare ogni file in C:\Windows\Temp (ovviamente ignorando quelli in uso e che faranno comparire il classico errore a video di impossibilità di cancellazione, nda).
  • Riavviare il servizio di Windows Update.
  • Cancellare ora la cartella SoftwareDistribution precedentemente rinominata, non serve più, Windows Update provvederà a crearne una nuova in totale autonomia (dovrebbe già averlo fatto in fase di avvio del servizio, come da passaggio precedente).
  • Fermare il servizio Trusted Installer.
  • Cancellare ogni file in C:\Windows\Logs\CBS.
  • Riavviare il servizio Trusted Installer.
  • Forzare una ricerca aggiornamenti di Windows Update (direttamente via prompt).

Visto che questa cosa potrebbe capitare ad altri client in futuro, ho pensato di tradurla in codice batch, da dare in pasto anche al Kace di Dell (tanto per fare un esempio). Il tutto intervallando alcuni secondi di pausa prima di poter eseguire l’operazione successiva (dando così modo al client di non saltare alcun passaggio fondamentale):

sc stop wuauserv
ping 127.0.0.1 -n 7 > NUL
cd \Windows\
move SoftwareDistribution SoftwareDistribution_old
del /S C:\Windows\Temp\* /Q
FOR /D %%p IN ("C:\Windows\Temp\*.*") DO rmdir "%%p" /s /q
sc start wuauserv
rd /S /Q C:\Windows\SoftwareDistribution_old
sc stop TrustedInstaller
ping 127.0.0.1 -n 7 > NUL
del /S C:\Windows\Logs\CBS* /Q
sc start TrustedInstaller
ping 127.0.0.1 -n 5 > NUL
wuauclt.exe /detectnow

Così facendo ho risolto il problema e liberato spazio sul disco. Ho fatto queste modifiche al sistema mesi fa e il problema non si è più presentato (a me, ma anche ad altri utenti che nel frattempo ho rilevato nella nostra rete).

Facile (soprattutto se si ha un aiuto nella software distribution) fare un’analisi all’interno della rete aziendale e cercare le macchine che soffrono la stessa anomalia ma che ancora non hanno saturato il disco, basterà cercare nella cartella C:\Windows\Temp una forte presenza di cab_, così da portarsi avanti ed evitare che il problema si presenti agli occhi dell’utente.

Estote parati (cit.).

G

Update

Ho aggiunto il passaggio relativo alla cancellazione della cartella SoftwareDistribution rinominata (nella lista delle operazioni manuali da compiere), come da commento di GDB, che ringrazio per avermelo fatto notare.

Il titolo è volutamente simile a quanto già scritto poco tempo fa, e vuole analizzare alcuni consigli che anche io cerco di dare a chiunque si mette a preparare una nuova installazione WordPress (spero prima per sé, poi forse –con buona esperienza sulle spalle– anche per altri), anche se in realtà i concetti di base valgono per qualsiasi accesso a qualunque servizio disponibile sulla grande rete. Basandomi sul blog di chi iThemes Security lo scrive, riporto alcuni passaggi secondo me fondamentali.

WordPress e Authy: autenticazione OneTouch 6

According to this infographic by WP Template on WordPress safety, insecure WordPress themes and plugins contribute to over 50% of all successful WordPress hacks.

Plugins and themes have to go through a screening process before they are released for public use from the WordPress.org plugin repository, so it is important to download your plugins and themes from trustworthy sources and always keep active themes and plugins update to the latest version.

fonte: ithemes.com/2016/11/08/wordpress-hacks

e ancora:

Using the same password on multiple sites is risky.

Using strong passwords for all your logins is one of the best online security practices you can develop.

The best practice to follow is creating a different password for every sing website you are registered on. Definitely don’t use the password you use for your bank account on another site.

An average of 30,000 sites are hacked every day.
This should give you an idea of how many people are affected by cyber attacks, and motivate you to use stronger passwords.

fonte: ithemes.com/2016/11/04/brute-force-attacks

Che poi non è che proprio ci voglia la scala eh. Strumenti come KeePass o simili (anche quelli completamente in cloud) sono fatti apposta per ricordarti password altrimenti (probabilmente) molto difficili da ricordare, soprattutto quando decidi di lasciare fare loro nella fase di generazione di una nuova password complessa. Vale anche il vecchio (ma ancora perfetto) consiglio del “utilizza password apparentemente stupide“, perché ti assicuro che “Il cavallo bianco di Napoleone!” può essere una password certamente più complessa della targa della tua automobile (puoi provare tu stesso su passwordmeter.com, tanto per levarti la curiosità).

Sulla base di ciò, è semplice stilare una ToDo List da tenere sempre bene a mente:

  • Sempre tenere aggiornato il tuo WordPress. Questo vale per il motore principale del CMS, ma anche (soprattutto, in realtà) plugin, temi e codice personalizzato che potresti aver scritto e poi dimenticato lì dopo poco, offrendo una possibile backdoor poco simpatica. Se il server che lo ospita è controllato da te, occorre tenere aggiornato ciò che gli permette di stare online (server web, MySQL, PHP, ecc.).
  • Disinstallare sempre plugin e temi non più utilizzati. Perché qui non si tratta solo di pulizia (sicuramente necessaria per tenere sempre snella l’installazione), ma perché così si vanno a chiudere possibili ulteriori falle, esattamente come da ragionamento del precedente punto della lista.
  • Utilizzare password complesse per ciascun account, possibilmente. Perché se è vero che il tuo blog è aperto alle iscrizioni (e si basa così sul buon senso dei tuoi utenti), è -spero- anche vero che tu possa stabilire delle regole precise per le password di coloro che possono pubblicare qualcosa, o peggio che possono modificare il comportamento del blog intero (un amministratore, tanto per essere chiari).
  • Abilitare l’autenticazione in due fattori per WordPress. E qui ti rimando all’articolo dedicato ad Authy e alla sua possibile integrazione con WordPress, comoda, funzionale, sicura.
  • Cancellare o declassare l’account “admin” predefinito di WordPress. Detto e stradetto, anche nel mio precedente articolo sulla protezione degli accessi alla Dashboard amministrativa, perché quell’utente creato di default nel database, è sempre scomodo e attaccabile (perché è quello che si da per scontato che esista).
  • Scegliere un buon hosting provider per il proprio CMS. Perché la sicurezza comincia dalle fondamenta, e affidarsi a chiunque non è –probabilmente– la migliore scelta, almeno per come la vedo io (e non solo). Un buon partner (perché di questo si tratta, nda) è quello che è sempre attento e pronto ad affrontare una difficoltà, a suggerirti le prossime mosse da fare, a bloccare chi è sgradito prima che faccia danni (più di quanti ne abbia già fatti entrando nel tuo sistema), e che ci tiene alla salvaguardia dei tuoi dati ma anche di coloro che abitano nel tuo stesso “condominio” (quando si parla di hosting condiviso, molto diffuso e primo step per tutti).
  • Scarica plugin e temi solo da fonti sicure. Evita come la peste siti web che promettono di regalarti il tema all’ultimo grido, creati con ore di sudato lavoro e ricchi di plugin solitamente a pagamento, pacchetti “all-in-one” appositamente clonati da siti web che li vendono e supportano quotidianamente. Spesso quei temi contengono codice malevolo, codificato (quindi di difficile decodifica per chi è alle prime armi), da qui in poi è tutto un salto nel buio. Se pensi che un tema sia assolutamente irresistibile, valuta l’acquisto della sua licenza, otterrai così anche un aiuto qualificato in caso di problemi, certamente meno costoso di qualcuno in grado di rimetterti in piedi dopo un deface (o simile) ai danni del tuo sito web.

Hai altri consigli? Vuoi raccontare la tua esperienza e dare qualche suggerimento in merito? L’area commenti –manco a dirlo– è a tua completa disposizione :-)

Qualche tempo fa ho avuto un problema piuttosto fastidioso: qualcuno ha deciso che uno specifico articolo di questo blog era poco gradito, buon (?) motivo per rompermi le scatole e saturare le risorse messe a disposizione dal mio hosting provider (che ringrazio per la pazienza). Per cercare di correre ai ripari, ho incattivito l’opzione di un plugin che già utilizzavo e che utilizzo ancora oggi, iThemes Security (ex Better WP Security).

Proteggere WordPress da login non autorizzati

Ci sono molteplici modi per proteggere l’accesso al wp-login.php, questo è uno tra i tanti attuabili senza molta fatica, una soluzione tutto sommato semplice da mettere in piedi.

Il mio consiglio? Fallo dopo aver chiuso l’accesso al sito web “al pubblico“, perché se è vero che sei sotto attacco, è anche vero che le risposte del tuo blog potrebbero andare in timeout, non arrivare mai. Per chiudere l’accesso a tutti tranne che a te dovrai conoscere il tuo indirizzo IP (mioip.it aiuta in questi casi) e sbarrare le porte grazie al file htaccess. Farlo è semplice, ti basterà creare (o modificare quello esistente) il file inserendo questo pezzo di codice:

order deny,allow
deny from all
allow from 127.0.0.1

Sostituisci il 127.0.0.1 con il tuo IP, carica il file .htaccess nel tuo spazio web (ripeto: se lo hai già, modifica quello che hai e non sovrascriverlo) e il gioco è fatto. Nessuno potrà visitare il tuo sito web a eccezione di te. Così facendo dovresti tagliare fuori il resto del mondo e avere campo libero per lavorare.

Installa iThemes Security e attivalo, così possiamo passare alla sua configurazione, e nello specifico quella utile a proteggere il blog da ripetuti tentativi di accesso alla dashboard di amministrazione o a un URL in particolare (giocando un pelo in contropiede e cambiando le carte in corsa, per poi rimetterle al loro posto).

Il plugin propone moltissime opzioni che ti consiglio caldamente di analizzare, ragionare e attivare secondo tue necessità, io preferisco saltare sulla singola esigenza di stavolta, andiamo con ordine.

404 detection

Servirà a proteggerti da chi tenta di raggiungere costantemente URL non esistenti, le sue impostazioni (e i limiti oltre i quali mandare in ban l’IP di chi ci sta provando) si trovano però in Global Settings, nello specifico parlo di:

  • Blacklist Repeat Offender, che deve essere assolutamente attivo.
  • Blacklist Threshold, che corrisponde al numero di tentativi da abbuonare all’IP prima di escluderlo in maniera definitiva (impedendogli di visualizzare il sito web).
  • Blacklist Lookback Period, che corrisponde al numero di giorni durante i quali quell’IP continuerà a rimanere sotto controllo (per capirci: se il limite di lockout è 2, per il numero specificato di giorni basterà farne un altro per andare in ban, una soluzione molto secca, tanto chi attacca generalmente raggiunge il limite di lockout nel giro di qualche minuto al massimo).
  • Lockout Period, che corrisponde all’intervallo di tempo (in minuti) di allontanamento di quell’IP dal blog.
  • Lockout White List è invece il box adatto a raccogliere gli IP che non devono essere soggetti alle impostazioni sopra riportate.

In tutto questo, nella stessa tab (Global Settings, nda), potrai scegliere di essere avvisato dei lockout e dei ban a mezzo posta elettronica (l’opzione da spuntare è Enable Email Lockout Notifications), che poi è un po’ come avere l’immediato polso della situazione …

Proteggere WordPress da login non autorizzati 1

e pensa che quella che vedi qui sopra è solo una parte dei ban a me notificati nel periodo dell’attacco, in pratica un campo di battaglia senza esclusione di colpi (sono arrivato a toccare quota 400 ban circa in un paio di giorni).

Banned Users

Passa ora alla tab Banned Users e imposta ciò che credo possa esserti più utile, ovvero:

  • Default Blacklist, che ti permetterà di sfruttare liste già popolate e verificate, offerte da HackRepair.com.
  • Enable Ban Lists, che manco a dirlo è tutto ciò che serve per iniziare a fare la raccolta differenziata di IP che servono evidentemente poco alle tue visite, ma che minano per troppo tempo la tua pazienza.

Volutamente non ho specificato (almeno fino a oggi) degli User Agents specifici. Generalmente quelli più fastidiosi vengono lasciati liberi nel web da player molto grandi, motori di ricerca, servizi. Ricorda che potrai comunque appoggiarti a questa ulteriore funzione in qualsiasi momento, in caso di necessità.

Local Brute Force Protection

Ciò che più va a “braccetto” con la protezione relativa agli errori 404, opzioni che riguardano stavolta il login alla Dashboard amministrativa di WordPress e che –secondo me– devono essere altrettanto restrittive e di difficile perdono, perché se sei davvero il gestore del blog, hai anche la possibilità di chiuderti fuori dalla porta ma conoscere il trucco delle chiavi sotto al tappeto, andando a disabilitare il plugin (rinominando la sua cartella nello spazio FTP) in caso di errore ripetuto e non voluto.

  • Max Login Attempts Per Host: specifica qui il numero di tentativi massimi di login per un singolo host (IP) prima di finire nella lista dei cattivi, in alternativa puoi lasciarlo a zero per evitare di mandare in ban l’indirizzo IP e decidere di rendere sufficientemente cattivo il Max Login Attempts Per User, che si riferisce invece al numero massimo di login di uno specifico utente (che può utilizzare più IP sorgenti, giusto per capirci).
  • Minutes to Remember Bad Login (check period) indica, come per il Blacklist Lookback Period di prima, il tempo che deve passare prima che il plugin dimentichi uno dei tentativi andati a male precedentemente.
  • Automatically ban “admin” user è –infine– quella che preferisco, perché la prima regola di qualsivoglia installazione di WordPress è quella di andare a disattivare o eliminare completamente l’admin creato di default dall’installazione, creandone uno che abbia uno username del tutto differente. Se qualcuno tenta di entrare come “admin” nel tuo blog, probabilmente si tratta di un bot, meglio estirparlo sul nascere, senza pensarci due volte.

C’è altro?

Si, molto. C’è da dare un’occhiata alla Network Brute Force Protection, alla File Change Detection (ciò che ti avvisa nel caso in cui vengano modificati dei file), alla WordPress Tweaks (per disattivare opzioni non necessarie e regolare l’accesso a risorse di WordPress) e tanto altro ancora, davvero. Prenditi il tempo necessario, studia tutte le possibilità offerte dal plugin, valuta se l’opzione Pro (a pagamento) proposta dallo stesso sviluppatore fa al caso tuo, imposta la migliore configurazione tenendo presente che in caso di configurazione errata o particolarmente cattiva, potrebbe chiuderti fuori dalla porta senza neanche passare dal via e prendere le duemila lire.

Quanto fatto però non basta, perché se l’attacco è verso uno specifico URL esistente, dovrai temporaneamente mettere offline il contenuto, oppure scegliere di cambiargli indirizzo, almeno per un periodo durante il quale ogni attacco non andrà a buon fine e porterà direttamente al ban, raccogliendo una serie di IP dai quali proteggersi. Concludi l’operazione andando a rimettere a posto il file .htaccess precedentemente modificato, per permettere a tutti di accedere nuovamente al blog. Le risorse del provider saranno ora più che sufficienti e potrai sopportare nuovamente il tuo carico di visite, quelle vere e assolutamente gradite.

Dopo aver adottato la soluzione, ho potuto rimettere abbastanza rapidamente online il contenuto precedentemente attaccato, che ancora oggi fa parte degli archivi di questo blog e che spero possa rimanere lì per molto altro tempo (no, non dirò di quale si tratta) :-)

L’area commenti è –come sempre– a totale disposizione per ulteriori soluzioni, alternative, commenti, critiche costruttive e per raccolte di “beneficenza“, che Natale si avvicina e sta baracca bisogna pur pagarla per tenerla viva e vegeta.

Estote parati (cit.).

G