Le risposte alle domande dei partecipanti

• Cosa fare nel caso di plugin, come quelli di cache, che utilizzano script .php all'interno di wp_content?

  Nel webinar abbiamo consigliato di proibire gli accessi ai file php nelle directory che non contengono file .php, se un plugin necessita di un php basta escludere quella directory dalla lista delle directory alle quali blocchiamo gli accessi ai file php.
  
  Faccio un esempio pratico, supponiamo di avere la seguente alberatura di directory:
  wp-content/
  ├── p1
  ├── p2
  E di voler bloccare il php per tutta la directory wp-content ad eccezione della sottodirectory p1, mi basterà mettere un file .htaccess con questo contenuto sotto la wp-content:
  
  Order Allow,Deny
  Deny from all
  
  e uno sotto la directory p1 con questo contenuto:
  
  Order Allow,Deny
  Allow from all
  
  in questo modo blocco l’esecuzione di tutti i files .php sotto la directory wp-content ad eccezione dei php all’interno della sottodirectory wp-content/p1

• Fino a che punto è consigliato avere gli aggiornamenti automatici abilitati? non si rischia di avere incompatibilità tra temi, core e plugin?

  Il nostro consiglio generale è quello di utilizzare un sito di staging in cui attiviamo gli aggiornamenti automatici in modo da testare in ambiente “sterile” eventuali problemi dovuti ad aggiornamenti automatici e, nel caso in cui l’aggiornamento sia andato correttamente a buon file, effettuare manualmente l’aggiornamento sul sito di produzione.

• La configurazione dei permessi a livello di file su ftp verrà trattata nella seconda parte del corso?

  Sì, come detto nel webinar il file .htaccess si può modificare sia sul proprio pc con un normale editor di test e poi effettuare l’upload tramite ftp oppure attraverso il filemanager di cPanel, l’unica cosa da ricordarsi è di abilitare la visualizzazione dei files nascosti attraverso i settings (opzione Show Hidden Files (dotfiles) ).

• Come si impostano gli header di sicurezza in htaccess?

  Se intende come si fa ad impostare gli headers nel file .htaccess di sicurezza vedi risposta precedente, se intende cosa inserire quello dipende da cosa si vuole ottenere, un esempio di settaggi molto stretto:
  
  Header always set Strict-Transport-Security "max-age=63072000;"
  Header always set Content-Security-Policy "default-src 'self'"
  Header set X-XSS-Protection "1; mode=block"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Expect-CT "max-age=304800, enforce"
  Header set Referrer-Policy "same-origin"
  
  È un esempio e deve essere sempre tarato sulle reali necessità del sito.
  
  

• L'aggiornamento del core non è consigliabile farlo dopo aver verificato che i plugin installati siano compatibili con quella versione? Questo per evitare che il CMS vada off line per incompatibilità tra core e plugin. Cosa ci consigliate?

  Il nostro consiglio generale è quello di utilizzare un sito di staging in cui attiviamo gli aggiornamenti automatici in modo da testare in ambiente “sterile” eventuali problemi dovuti ad aggiornamenti automatici e, nel caso in cui l’aggiornamento sia andato correttamente a buon file, effettuare manualmente l’aggiornamento sul sito di produzione.

• Nel secondo webinar, si parlerà di come modificare o rendere sicuro il file wp-config?

  Sì, l’argomento verrà trattato nella seconda parte del corso

• I parametri del php.ini è meglio lasciarli di default?

  Il php.ini è ottimizzato per la maggior parte dei siti, ma se per un determinato sito web che ha esigenze particolari può essere personalizzato.

• Non aggiorno frequentemente i plugin di WordPress per paura che l'aggiornato possa compromettere il funzionamento del mio sito web. Sono esposto a rischi? Come posso fare per conciliare le due esigenze?

  Il nostro consiglio generale è quello di utilizzare un sito di staging in cui attiviamo gli aggiornamenti automatici in modo da testare in ambiente “sterile” eventuali problemi dovuti ad aggiornamenti automatici e, nel caso in cui l’aggiornamento sia andato correttamente a buon file, effettuare manualmente l’aggiornamento sul sito di produzione.

• Plugin come Wordfance possono essere una soluzione per mettere in sicurezza un sito WorsdPress?

  Tali plugin permettono una gestione centralizzata, monitorabile e con interfacce intuitive di molte funzionalità di sicurezza facilitando quindi la messa in sicurezza del sito e la sua gestione nel tempo ma non coprono tutte le possibili minacce.

• In quale tipologia di attacco si pongono injection di articoli? Come è possibile prevenirli?

  L’inserimento non autorizzato di articoli o contenuti malevoli in essi può configurarsi in diverse categorie di attacco a seconda della fonte e dell’intento. Riportiamo di seguito una serie di esempi:
  • può essere il risultato di un attacco di SQL injection
  • può essere il risultato dell’attività di un Malware attraverso una Backdoor;
  • qualunque sia la fonte può mirare ad un attacco XSS inserendo nell’articolo dei link al fine di ridirezionare gli utenti verso siti malevoli;
  • qualunque sia la fonte può mirare ad un attacco di tipo Pharma Hack inserendo nell’articolo dei link al fine di ridirezionare gli utenti verso siti pubblicitari.
  

• Avete parlato di vari possibili attacchi. In che percentuale questi attacchi sono usati?

  I dati annuali ed il loro andamento nel tempo sulla percentuale di distribuzione delle tecniche di attacco sono resi disponibili nei Rapporti sulla Sicurezza ICT del CLUSIT.
  
  Si riporta di seguito la tabella relativa all’andamento 2017 – 2021.
  

• L'attacco brute force è riferito alla forms di login?

  Nel caso di un sito WordPress l’attacco è principalmente indirizzato su tali forms ma in generale può essere indirizzato a eventuali componenti architetturali esposte della piattaforma di hosting gestita dall’hosting provider.

• Che tipo di protezioni DDoS ha implementato Register.it?

  Qui trovi un articolo sull’argomento che avevamo scritto tempo fa sul blog in cui comunichiamo le misure di Register.it per contrastare un attacco DDoS.
  
  https://blog.register.it/attacco-ddos-cose-come-funziona-e-come-difendersi/
  
  

• Ci sono consigli su come approcciare la gestione e l'aggiornamento di diverse decine di siti WordPress?

  Il consiglio è di adottare modalità, strumenti e proprie procedure operative per:
  1 pianificare/schedulare e consuntivare periodicamente di tutte le attività di gestione e di aggiornamento
  2 consultare sistematicamente fonti ufficiali su aggiornamenti o interventi di sicurezza necessari
  3 effettuare verifiche sistematiche sullo stato di sicurezza di tutte le componenti dei siti WordPress gestiti tracciando le vulnerabilità individuate e mettendo a piano (punto 1) il loro fix
  
  Queste attività possono essere in parte realizzate anche tramite applicazioni che permettono la gestione centralizzata ed automatizzata di più installazioni WordPress ma, soprattutto per il punto 2, è sempre bene effettuare ulteriori attività di controllo e aggiornamento oltre quelle gestite in automazione.
  

• Perché non è citato il Ransomware tra i possibili attacchi? Cosa fare in caso ne sia vittima?

  Il Ransomware non è stato citato come attacco perché si tratta in sintesi dell’obiettivo di varie tipologie di attacchi che possono essere realizzati con modalità/tecniche differenti ma con la stessa finalità, quella di cifrare/rendere inaccessibili o inutilizzabili/cancellare i dati della vittima e chiedergli un “riscatto” per riacere o poter accedere nuovamente ai suoi dati.
  
  Le tecniche in merito sono fondamentalmente preventive, dato che una volta esfiltrati i dati possono essere usati a piacimento dall’attaccante anche a fronte dell’eventuale pagamento del riscatto da parte della vittima, con tutte le implicazioni legali che questo comporta.
  
  Si rimanda a tal proposito alle indicazioni fornite in merito dall’ Agenzia per la Cybersicurezza Nazionale https://csirt.gov.it/contenuti/ransomware-misure-di-protezione-e-organizzazione-dei-dati-per-un-ripristino-efficace