Parliamo di HTTP/2

HTTP/2

Ciao SiteGrounders! Visto che la settimana scorsa mi sono concentrato su certificati SSL e HTTPS mi sembrava giusto dedicare spazio questa volta al protocollo HTTP/2 di cui ho solo accennato qualcosa nel precedente post. Che cos’è dunque nello specifico questo HTTP/2 e perché è importante averlo e sapere cosa sia?

Internet, come lo conosciamo oggi, non sarebbe mai esistito senza l’HTTP. Esso è sempre stato il cuore e l’anima stessa di internet e ciò che ci consente di leggere le ultime notizie, ordinare articoli online, guardare video su YouTube e accedere ai nostri siti web preferiti su tutti i tipi di dispositivi: workstation, laptop, smartphone, tablet e persino e-reader che offrono funzionalità di navigazione.

Tuttavia il protocollo HTTP per molti anni, sin da quando fu rilasciata la versione 1.1 nel 1999, non ha visto modifiche sostanziali; ecco perché quando nel 2015 fu rilasciato HTTP/2 per molte compagnie come la nostra fu un momento di grande eccitazione. Ovviamente in SiteGround non ci siamo fatti sfuggire l’occasione e, già poco dopo il suo rilascio, tutti i nostri server lo supportavano.

Continue reading “Parliamo di HTTP/2”

Parliamo di Let’s Encrypt!

Il tuo sito web non si apre in HTTPS? Dovrebbe. Non è passato molto tempo da quando si pensava che l’HTTPS fosse solo per siti di e-commerce o che richiedevano carte di credito, mentre oggi questo protocollo è sulla buona strada per diventare la norma per ogni sito web. Ne hai bisogno, se vuoi un buon posizionamento in Google; ne hai bisogno, se vuoi che il tuo sito venga visualizzato senza alert in Chrome; ne hai bisogno, se vuoi sfruttare tutte le future funzionalità di WordPress e ne hai bisogno persino se vuoi che il tuo sito sia più veloce grazie all’HTTP/2.

Da qualche anno, grazie all’iniziativa Let’s Encrypt, il rilascio dei certificati SSL è gratuito e accessibile a tutti; questo comprende anche tutti voi che in più, come clienti SiteGround, avete anche la possibilità di poter forzare l’HTTPS per il vostro sito direttamente dal cPanel.

Continue reading “Parliamo di Let’s Encrypt!”

Parliamo di SiteGround… cominciamo una nuova rubrica!

Ciao a tutti cari SiteGrounders italiani! Lo sapete che il primo cliente italiano di SiteGround fu nel lontano 2004 mentre oggi, a neanche un anno di distanza dalla nascita di SiteGround Italia, siamo decine di migliaia? Ebbene si, siete ufficialmente parte di una community davvero immensa. Per questo da oggi vorrei far partire una rubrica sul nostro Blog con lo scopo di generare discussioni e confronti sui servizi che trovate più interessanti, i benefici che si possono ottenere e le esperienze che avete vissuto.

Continue reading “Parliamo di SiteGround… cominciamo una nuova rubrica!”

Perché l’intestazione HTTP Vary può danneggiare il tuo sito web

vary-user-agent

Vary è un’intestazione HTTP potente che svolge un ruolo significativo nel funzionamento della cache del tuo sito web. Quando questa intestazione è impostata correttamente, assicura che i visitatori del sito web visualizzino il contenuto giusto, indipendentemente dal caching applicato. Tuttavia, se questa intestazione è impostata in modo non corretto, può eliminare completamente i vantaggi del miglior sistema di caching e causare un sovrautilizzo delle risorse. In questo articolo del nostro blog, voglio fare un po’ di luce sul modo in cui l’intestazione Vary influisce sul tuo sito ospitato su SiteGround e, in particolare, sul nostro sistema di caching, e mostrarti l’utilizzo consigliato dell’intestazione Vary per il tuo sito web.

Come funziona l’intestazione Vary?

Il ruolo dell’intestazione Vary è quello di indicare in quali casi dovrebbe essere mostrata una versione diversa del tuo sito web. Se l’intestazione Vary ha uno dei seguenti valori: User-Agent, Cookie, Referred o * (wildcard), può ridurre significativamente l’effetto del nostro sistema di caching. Ciò accade perché questi valori indicano che dovrebbe essere mostrata una versione diversa delle tue pagine in base al tipo di browser utilizzato (user-agent), che è presente un cookie unico o URL referral o, nello scenario peggiore, quando viene utilizzato *, che verrà mostrato un contenuto nuovo durante ogni singola visita, che equivale a disattivare completamente la nostra cache.

Vary: User-Agent

Diamo un’occhiata al modo in cui funziona il valore più comunemente utilizzato, User-Agent. Dice al nostro caching dinamico: “Ehi, dovresti memorizzare diverse cache per sistemi operativi e browser diversi”. Questo per evitare di mostrare, ad esempio, una versione desktop presente in cache a un visitatore che utilizza un dispositivo mobile. Tuttavia, considera che al giorno d’oggi la maggior parte dei siti web non mostra in realtà HTML diversi per le loro versioni mobili. È il CSS responsivo che fa tutto il lavoro pesante e mostra il tuo sito web in maniera diversa su smartphone e desktop. Pertanto, a meno che non utilizzi plugin come ad esempio WP Touch, o sai per certo di avere differenze nell’uscita HTML del tuo sito web in base ai browser dei visitatori, il tuo sito web non dovrebbe inviare l’intestazione Vary: User-Agent.

Senza impostare Vary: User-Agent, il nostro sistema di caching memorizzerà in cache il tuo sito web durante il primo caricamento e in seguito mostrerà la versione in cache durante le richieste successive – a meno che non aggiorni i contenuti o svuoti manualmente la cache. Con User-Agent attivato, il sistema manterrà copie diverse per ciascuna combinazione di sistema operativo e browser che visita il tuo sito web. Ciò significa che avrai una richiesta dinamica per la prima persona che carica il tuo sito web su Safari da desktop, uno per la prima persona che lo carica su Chrome da dispositivo mobile, uno per la prima persona che lo carica su Chrome da desktop… e così via.

Diciamo che svuoti la tua cache ogni 100 visite circa. Senza l’intestazione Vary: User-Agent inviata dal tuo sito web, il tuo sito web avrà solo una richiesta dinamica su 100. D’altra parte, con l’intestazione abilitata, a seconda del profilo dei tuoi visitatori, avrai 5-30 richieste dinamiche per le stesse 100 visite. Quindi lo stesso sito web utilizzerà 5-30 volte le risorse che sarebbero state necessarie con  l’intestazione disattivata.

Bot cattivissimi!

Odiamo il traffico malware e i bot maligni. Per noi, combatterli in ogni modo possibile si è rivelato uno sforzo costante. Sto citando i bot qui, perché se ricevi spam da essi, l’intestazione Vary: User-Agent potrebbe determinare il grado di successo del loro attacco e il grado con cui il crawling da parte dei bot influirà sulle prestazioni del tuo sito web.

Puoi considerare un bot come un browser che effettua azioni automatizzate sul tuo sito web. Può raccogliere dati per il proprio indice, cercare le vulnerabilità, provare a compilare e inviare moduli, ecc.  L’User-Agent del Bot è semplicemente una porzione di testo aggiunto dal suo creatore. Sistemi di crawling rinomati come il bot di Google sono impostati correttamente, mentre altri possono tentare di imitare il bot di Bing o il bot di Google o addirittura generare un user agent in maniera casuale.

Se il bot inizia ad eseguire il crawling del tuo sito web e disponi dell’intestazione Vary: User-Agent, ogni richiesta che fa al tuo sito web costituirà un elemento dinamico e consumerà le tue risorse. D’altra parte, se l’intestazione non viene utilizzata, mostreresti ai bot le richieste in cache direttamente dal caching dinamico.

Come visualizzare le tue intestazioni di risposta

Prima di tutto, dovresti controllare le intestazioni che il tuo sito web sta restituendo ai visitatori. Di solito, uso la scheda Network di FireBug nel mio browser, ma esiste un comodo checker online (http://www.webconfs.com/http-header-check.php) che puoi utilizzare anche tu. L’intestazione Vary presenta valori multipli e l’user-agent è semplicemente uno di essi. Se non disponi di un’intestazione Vary o quest’ultima include solo il valore Accept-Encoding (che aiuta il corretto funzionamento della compressione gZIP), non dovresti preoccuparti. Tuttavia, se visualizzi User-Agent o un qualsiasi altro valore (Cookie, Referrer o *), ti consigliamo di rimuoverli dalla tua intestazione.

[subscribe_cta]

Come configurare l’intestazione Vary

Generalmente, l’approccio migliore sarebbe quello di capire quale parte del tuo sito web la sta generando e riconfigurarla. Tuttavia, ciò potrebbe richiedere alcune capacità di risoluzione dei problemi e potrebbe non essere un compito molto facile. Quindi, se sei su WordPress, potresti controllare le tue intestazioni, e quindi sostituire la risposta con solo quello che desideri, aggiungendo le seguenti righe al tuo file function.php:

function replace_wp_headers($headers) {
$headers['Vary'] = 'Accept-Encoding';
return $headers;
}

add_filter(‘wp_headers’, replace_wp_headers);

In alternativa, è possibile provare a utilizzare le regole .htaccess per disattivare le intestazioni Vary non necessarie:

<ifModule mod_headers.c>
Header unset Vary
Header set Vary “Accept-Encoding”
</ifModule>

Facendo questo, rimuoverai tutte le intestazioni dal tuo sito web e lascerai solo quelle specificate nel tuo codice Accept-Encoding. Naturalmente, puoi aggiungere altre regole ma assicurati sempre di averne veramente bisogno: non c’è altro modo per ottenere il risultato che stai cercando!

Playlist 14 Anni di WordPress

È il periodo dell’anno in cui ci prepariamo per festeggiare un altro anniversario di WordPress. Domani, 27 maggio, WordPress compie 14 anni! Per lasciare un segno “alla maniera” SiteGround, per l’occasione abbiamo creato una playlist con una traccia di ogni musicista a cui sia mai stata dedicata una versione di WordPress a suo nome. Il mix ha fatto miracoli per la nostra produttività in ufficio, quindi abbiamo deciso di condividerlo con voi. Speriamo che renderà la vostra giornata migliore, se avete dovuto passarla a lavorare sul vostro sito web oppure a festeggiare. Godetevelo e ancora un buon 14 ° compleanno tutta la comunità di WordPress!

Nuove opzioni nell’interfaccia Let’s Encrypt

Da più di un anno, ci impegniamo affinché i certificati SSL siano accessibili e utilizzabili da chiunque. Siamo stati tra i primi a offrire i certificati Let’s Encrypt gratuiti. In seguito, abbiamo automatizzato il rilascio di SSL per tutti gli account. Successivamente, abbiamo aggiornato il nostro plugin per WordPress SiteGround Optimizer per permettere la configurazione di SSL WordPress con un clic . Ora siamo all’ultimo passaggio: il nostro ultimo aggiornamento per lo strumento Let’s Encrypt in cPanel ti consente di forzare tutto il traffico del tuo dominio attraverso HTTPS con un singolo clic, indipendentemente dall’applicazione che stai utilizzando. Continua a leggere per scoprire quali sono le nuove opzioni all’interno della nostra interfaccia Let’s Encrypt.

HTTPS Enforce

Il sistema che abbiamo sviluppato trova al volo le richieste al tuo dominio e sostituisce il protocollo utilizzato. Si tratta di un enforce a livello server, che non effettua nessuna modifica alla configurazione della tua applicazione e del tuo database. Si tratta di un modo fantastico con cui la grande maggioranza degli utenti può effettuare l’enforce HTTPS in tutta semplicità. Ovviamente, questi switch automatizzati possono fallire in alcuni rari casi. La regola generale è quella di controllare sempre se il tuo sito web e la tua area di amministrazione vengono caricati normalmente con https dopo lo switch. Se per qualche motivo la procedura non funziona, puoi semplicemente disabilitare HTTPS enforcer e tutto tornerà allo stato precedente, senza nessun danno per il tuo sito web.

[subscribe_cta]

Lo switch del tuo dominio a HTTPS potrebbe non essere sufficiente per vedere il tuo sito web contrassegnato come sicuro dal browser. Se stai caricando contenuto da una posizione esterna utilizzando un link http, il browser potrebbe mostrare un avviso di “Contenuto non sicuro” ai tuoi visitatori. Per risolvere questo problema, abbiamo fornito uno switch separato per riscrivere anche i link esterni. Abbiamo inserito la riscrittura dei link esterni come opzione separata, in quanto le risorse già utilizzate sul tuo sito web potrebbero non essere disponibili su HTTPS. In questo caso, potresti preferire caricarle con un avviso di contenuto misto, piuttosto che non caricarle affatto.

Quindi, qual è il miglior modo per passare a HTTPS?

Dipende dal tuo livello di esperienza.

Naturalmente, se ti senti abbastanza sicuro, il modo migliore per far funzionare il tuo sito web attraverso HTTPS  è quello di riconfigurare manualmente la tua applicazione, cambiando in https tutti i link delle risorse caricate. Così eliminerai ogni possibile problema. Tuttavia, è necessaria una certa conoscenza tecnica per completare correttamente l’attività, in quanto le risorse possono essere caricate dal database, da un plugin o dal tuo tema.

La seconda migliore opzione è disponibile per i nostri utenti WordPress: si tratta della stessa logica precedente, ma eseguita tramite plugin, il nostro SiteGround Optimizer. Richiede soltanto l’installazione del plugin.

La terza opzione consiste nell’utilizzare le nuove opzioni nell’interfaccia cPanel Let’s Encrypt. Si tratta del modo più semplice e veloce, e funziona benissimo per la maggior parte del sito web. Tuttavia, in quanto le impostazioni sono a livello server, ci potrebbe essere la possibilità che entri in conflitto con un’impostazione a livello di applicazione, se nel file htaccess sono già presenti alcuni codici difficili da modificare per i protocolli HTTPS/HTTP. Consigliamo questa opzione a chi non può utilizzare le due precedenti.

In che modo la nostra nuova IA anti-bot impedisce milioni di attacchi brute-force

Anti-bot-AI-660x330

Negli ultimi giorni stiamo gradualmente lanciando sui nostri server un nuovo sistema di prevenzione bot basato su intelligenza artificiale, sviluppato dai nostri specialisti DevOps. Stiamo già riscontrando sorprendenti risultati per quanto riguarda il funzionamento del sistema: ogni ora blocca tra 500.000 e 2 milioni di tentativi brute-force su tutti i nostri server. Di conseguenza, abbiamo impedito un numero imprecisato di potenziali accessi non autorizzati, ma ciò che è ancora più importante è che siamo riusciti a risparmiare un’enorme quantità di risorse server, che ora possono essere utilizzate dai nostri utenti per attività significative e legittime.

Perché i bot sono un problema?

Il traffico dannoso è un enorme problema, che probabilmente colpisce ogni singolo sito web online. Generalmente, questo traffico viene generato dai bot che cercano di ottenere l’accesso al tuo sito web tramite un attacco brute-force al suo login. I bot eseguono più tentativi di accesso, utilizzando combinazioni diverse di nomi utente e password. In realtà, se hai inserito una password complessa, le probabilità di successo di un accesso bot sono minime, tuttavia questa attività è ancora un problema serio. Nei tentativi di accesso, i bot utilizzano una quantità enorme di risorse del server (ad esempio, in un blog personale può superare di più volte il traffico legittimo creato dai veri visitatori umani). Anche se il volume dell’attività bot non è eccessivo – e non risulta quindi nella mancanza di erogazione del servizio (Denial of Service o DoS) – può comunque rendere il tuo piano di hosting più costoso, facendoti superare le risorse del tuo account: l’account deve gestire non solo il traffico legittimo dei visitatori, ma anche il traffico bot indesiderato.

[subscribe_cta]

Come funziona il nostro sistema?

L’intelligenza artificiale analizza i dati da più server

La difficoltà principale nella lotta contro l’attività dei bot è che sono molto intelligenti ed elusivi. Gli attacchi bot utilizzano IP e user agent differenti, e spesso la qualità dei dati provenienti da tentativi rivolti all’accesso di un singolo sito web, o perfino da un singolo server, non è sufficiente per determinare un bot di brute-force. Disponiamo da tempo di un sistema di prevenzione brute-force su tutti i nostri server, ma la nuova IA è molto più efficace, in quanto è in grado di raccogliere e analizzare simultaneamente i dati di tutti i nostri server. È inoltre possibile applicare automaticamente azioni per bloccare i bot indesiderati, in base ai risultati dell’analisi. La nostra IA monitora numerosi indicatori per individuare schemi di comportamento dannosi e bloccare il traffico negativo. Tra questi:

  • Tentativi di accesso non riusciti nelle applicazioni web più diffuse: WordPress, Drupal, Joomla, Magento, ecc.
  • Numero di connessioni simultanee a URL differenti
  • Differenti tipi di richiesta e vulnerabilità DDoS conosciute nelle applicazioni
  • Elenco dinamico di bad user agent aggiornato continuamente

Abbiamo introdotto pagine captcha impegnative

Una volta che il nostro sistema segnala come dannoso un determinato indirizzo IP o un user agent, viene immediatamente bloccato e gli viene richiesto di risolvere una pagina captcha. Il sistema impara continuamente a ridurre i falsi positivi. Se un visitatore umano raggiunge la pagina captcha e la risolve, l’indirizzo/agente relativo viene messo in white list. Se la pagina captcha persiste (ad esempio la vedi più di una volta per 24 ore), contatta la nostra assistenza.