Gli utenti i cui certificati sono programmati per essere revocati prima di allora, dovranno forzare manualmente il rinnovo. Questa piccola procedura ora si rivolge ai possessori di Pannelli Plesk, che non hanno ancora ufficializzato il bug. Questo per completare ed arricchire la soluzione del problema spiegato nel post precedente.
Saremo quindi in grado di aggiornare massivamente i certificati Let’s Encrypt anche per chi non ha dimestichezza nell’amministrazione di Web Server se non tramite l’uso del Pannello di Controllo Plesk, diffuso abbondantemente tra i nostri ISP come servizio aggiunto ai Server dedicati e VPS.
La Procedura
Connettersi in SSH al proprio server Potete Utilizzare un qualunque client con protocollo SSH (sempre che il vostro server lo permetta e sia attivato) come ad esempio Putty per Windows, o con il terminale se usate Mac/UNIX base OS.
Modificare o Creare il file/usr/local/psa/admin/conf/panel.ini con le seguenti informazioni:
[ext-letsencrypt]
renew-before-expiration = 365
Eseguire il task di rinnovo dei certificati Let’s Encrypt
Ripristinare o Rimuovere le informazioni del punto 2
Se non siete amministratore di un server web, o non avete accesso alla console o ai servizi Plesk, chiedete informazioni al vostro ISP di fiducia per adempiere immediatamente alla soluzione del problema. Spesso molti siti sono ospitati in Hosting di servizio, dove non si ha il controllo dei certificati Let’s Encrypt.
Se avete bisogno di maggiori
aggiornamenti, oppure
chiarimenti su come configurare adeguatamente un server web, non
esitate a contattarmi
in privato, sono in grado di
risolvere qualunque problema riscontriate nelle vostre
configurazioni.
Non affidatevi al caso, ma in tema di sicurezza (in questo caso
Certificati LET’S Encrypt HTTPS) affidatevi sempre ad una
Persona di Competenza.
Un ringraziamento particolare a Lorenzo Crippa per la sua segnalazione.
Probabilmente avrete sentito la notizia di alcuni mesi fa che il compilatore JIT verrà aggiunto a PHP 8. Già dalla versione PHP 7.0, sono state apportate modifiche per migliorare le prestazioni, ma questa sarà una nuova svolta per PHP. Questa grande funzionalità è stata sviluppata 2 anni fa, ma il lancio di PHP 8.0 è previsto tra meno di 1 anno. In questo articolo, daremo un’occhiata di cosa si tratta realmente, ma soprattutto proveremo a testarlo su Linux.
Che cos’è JIT
Forse non conoscete JIT, quindi prima spiegheremo di cosa si tratta. Probabilmente sapete già che PHP è un linguaggio interpretato a scripting server side, il che significa che non è necessario compilare il codice prima che venga eseguito (a differenza di altri linguaggi come C/C++). Invece, il modulo PHP legge il codice e lo esegue. In altre parole, non si codifica il codice per compilarlo in linguaggio macchina per eseguirlo, ma viene codificato uno script e poi inviato a PHP per essere eseguito Server Side appunto.
PHP è dotato di una macchina virtuale chiamata Zend VM. Perché chiamarla macchina virtuale? Perché si comporta come un computer durante l’esecuzione del codice stesso. È responsabile della lettura e dell’esecuzione del codice PHP. Ma prima di ciò, il codice verrà letto e tradotto da PHP in opcode, la lingua che Zend VM comprende. Quindi Zend VM sarà in grado di eseguire quel codice operativo. Questa è un’illustrazione per una facile comprensione.
Quindi abbiamo
bisogno prima di uno step di parse e poi di interpretazione.
Velocizzeremo il tutto, sfruttando il cosiddetto OPCache (Opcode
Cache) che memorizza i risultati della fase di compilazione, quindi
non sarà necessario compilare nuovamente la volta successiva. Ecco
come funzionava PHP fino ad ora.
Quindi ora parliamo del compilatore JIT, significa che compileremo la sorgente (codice) in un linguaggio macchina da eseguire. JIT sta per “Just-In-Time”, il che significa servirà tempo per compilare, invece di compilare prima e poi eseguire. Quando sarà necessario avviare lo script, sarà compilato subito al momento.
Per PHP, il compilatore JIT compilerà il codice sorgente, nel codice macchina ed eseguirà quel codice invece di inviarlo a Zend VM per essere eseguito. Quindi non abbiamo più bisogno di un interprete e, naturalmente, il codice funziona anche più velocemente.
Sarà davvero più veloce?
Questa è una demo che mostra la velocità di PHP con il compilatore JIT rispetto alla vecchia versione. Nel video si utilizza un codice per creare immagini 3D.
Ma ATTENZIONE, nessuno ha mai usato PHP per creare immagini 3D
Poiché il nostro script sarà compilato nel codice macchina e sarà eseguito direttamente dalla CPU anziché dall’interprete Server Side, gli aumenti di velocità riguarderanno principalmente l’avvio del codice stesso e l’utilizzo della CPU (quindi richiede potenza della macchina). Ma l’applicazione Web non avendo tale codice, il tutto sarà delegato dal processo dall’I/O (query del database, caricamento del file, richiesta HTTP ecc.), il più delle volte l’app non fa nulla, resta solo in ascolto per mostrare i risultati dal database o dall’API, ecc. Purtroppo, ora come ora una webapp difficilmente sarà più veloce.
A cosa serve la JIT?
A partire dalla versione PHP 7.0, il problema delle prestazioni è stato uno delle grosse problematiche da risolvere, in parte anche grazie alla concorrenza dell’HHVM di Facebook (pure utilizza il compilatore JIT). OPCache, struttura i dati, ottimizzando tutto poco a poco per ottenere le massime prestazioni.
Inoltre, le prestazioni di PHP per un linguaggio server possono già essere considerate abbastanza buone, e non sarà più lento come in passato. Quindi è tempo di espandere un le capacità di PHP, verso aree come l’analisi dei dati, il rendering 3D/2D, ecc.
In passato, il codice ad alte prestazioni veniva spesso scritto come estensione in C/C++ anziché come pacchetto PHP. Ad esempio, la phpredis è sempre 6-7 volte più veloce di predis. Se il codice PHP viene compilato anziché interpretato, otterremo pacchetti con le stesse prestazioni delle estensioni scritte in C/C++.
Ecco il motivo principale per cui è stato scelto il compilatore JIT: questa è la migliore e potenziale direzione verso quale dirigersi.
Proviamoci: facciamo un test
Dopo questa doverosa introduzione, proviamolo direttamente su campo. Dal momento che non esiste ancora una versione di PHP 8.0, dovremo compilare dal codice sorgente PHP versione 7.4 ossia ancora in alpha, il master è già 8.0. Innanzitutto, scarichiamo il codice sorgente:
wget -O php.zip https://github.com/php/php-src/archive/master.zip unzip php.zip cd php-src-master
Quindi installiamo le dipendenze. Useremo Ubuntu Server, se usate altre distro troverete lo stesso pacchetto da soli.
Quindi eseguire ./configure per impostare la build. Selezionate le opzioni per compilare PHP. Puoi scegliere un percorso da installare aggiungendo –prefix = <dir_install>. Di default installerà /usr/local/bin, quindi se avete già installato un’altra versione, ricordatevi di configurarlo. PHP verrà installato nel percorso <dir_install>/bin/php. Aggiungete il percorso per il file di configurazione con –with-config-file-path e –with-config-file-scan-dir se lo desiderate.
Ora proviamo il benchmark per vedere se realmente è più veloce. Nel codice sorgente, c’è un file Zend/bench.php che possiamo testare. In questo file ci sono molti codici calcolati (hash, loop .etc). Questo è il risultato ottenuto (riformattato per un facile confronto):
Sicuramente risulta più veloce, non è affatto strano. Proveremo a confrontare un’altra app web, un progetto Laravel e confrontato con lo strumento ApacheBench
ab -t10 -c10 http://test.localhost/
Questo è il risultato ottenuto:
PHP 7.3: 131.37 req/s
PHP 8.0 + JIT: 133.57 req/s
In breve , dalla versione 8 sarà significativamente più veloce, ma per il momento, la maggior parte del codice PHP esistente nel mondo, manterrà degli standard che risultano ancora approssimativamente lenti. Tuttavia, nuovi sviluppi si apriranno per la nuova versione PHP compilata JIT.
Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.
Non affidatevi al caso, ma in tema di Sviluppo Applicazioni Web (in questo caso WebApp Development) affidatevi sempre ad una Persona di Competenza.
Se i nostri siti vengono segnalati come non protetti, un motivo ci sarà! Sfortunatamente, la maggior parte degli utenti Let’s Encrypt, se non tutti, dovranno forzare manualmente il rinnovo dei loro certificati entro mercoledì 4 Marzo. È almeno un processo facile.
Il bug segnalato
Recentemente, Let’s Encrypt ha annunciato di aver scoperto un bug nel suo codice CAA (Certification Authority Authorization).
Il bug apre una finestra temporale in cui un certificato potrebbe essere emesso anche se un record CAA nel DNS di quel dominio lo dovesse proibire. Di conseguenza, Let’s Encrypt sta commettendo un errore dal punto di vista della sicurezza piuttosto che della convenienza. Sarà revocato qualsiasi certificato attualmente emesso che non sia legittimato con certezza.
Hanno Dichiarato:
Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid disruption, you’ll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologize for the issue.
If you’re not able to renew your certificate by March 4, the date we are required to revoke these certificates, visitors to your site will see security warnings until you do renew the certificate.
—
Purtroppo, ciò significa che dobbiamo revocare i certificati interessati da questo errore, che include uno o più certificati. Per evitare interruzioni, dovrai rinnovare e sostituire i certificati interessati entro mercoledì 4 marzo 2020. Ci scusiamo sinceramente per il problema.
Se non riesci a rinnovare il certificato entro il 4 marzo 2020, data in cui siamo tenuti a revocare tali certificati, i visitatori del tuo sito vedranno avvisi di sicurezza fino a quando non lo rinnoverai.
Concetti relativi a sicurezza Internet, certificato SSL/TLS
Let’s Encrypt utilizza il software dell’autorità di certificazione chiamato Boulder. In genere, un server Web che serve molti nomi di dominio separati e utilizza Let’s Encrypt per proteggerli riceve un singolo certificato LE che copre tutti i nomi di dominio utilizzati dal server anziché un certificato separato per ogni singolo dominio.
Il bug LE scoperto è che, invece di controllare separatamente ogni nome di dominio per i record CAA validi che autorizzano il rinnovo di quel dominio da quel server, Boulder controlla un singolo dominio su quel server N° volte (dove N è il numero di LE domini serviti su quel server). Let’s Encrypt in genere considera buoni i risultati della convalida del dominio per 30 giorni dal momento della convalida, ma i record CAA in particolare devono essere controllati non più di otto ore prima dell’emissione del certificato.
Il risultato è che viene presentata una finestra di 30 giorni in cui i certificati potrebbero essere emessi a un determinato server Web da Let’s Encrypt nonostante la presenza di record CAA nel DNS che vieterebbe tale emissione.
La Soluzione
Dato che Lets Encrypt si trova nella posizione non invidiabile di aver emesso certificati che non dovrebbe avere, dal 4 Marzo 2020 saranno revocati tutti i certificati correnti che potrebbero non aver avuto il controllo dei record CAA corretto. Gli utenti i cui certificati sono programmati per essere revocati prima di allora, dovranno forzare manualmente il rinnovo.
Se un Web Server Administrator non esegue questo passaggio di rinnovo manuale, i browser che raggiungeranno i loro siti Web mostreranno avvisi di sicurezza TLS a causa dei certificati revocati.
I certificati Let’s Encrypt vengono emessi per intervalli di 90 giorni e Certbot li rinnova automaticamente solo quando rimangono 30 o meno giorni nel certificato, quindi ciò potrebbe significare circa due mesi di errori del browser se il rinnovo forzato manuale non viene eseguito.
Esistono molti client ACME e le loro procedure variano, ma se state usando Certbot, tutto ciò che è necessario fare è avviare questo comando una volta da shell:
certbot renew --force-renewal
Fortunatamente, è un processo semplice.
Se non siete amministratore di un server web, o non avete accesso alla console, chiedete informazioni al vostro ISP di fiducia per adempiere immediatamente alla soluzione del problema. Spesso molti siti sono ospitati in Hosting Condiviso dove non si ha il controllo dei certificati Let’s Encrypt.
Se avete bisogno di maggiori
aggiornamenti, oppure
chiarimenti su come configurare adeguatamente un server web, non
esitate a contattarmi
in privato, sono in grado di
risolvere qualunque problema riscontriate nelle vostre
configurazioni.
Questo articolo elenca alcune delle impostazioni predefinite per server Apache 2.4 installato su un Server Ubuntu. Spiega come applicarli in modo globale a livello server. Se abbiamo dei siti ospitati in in server dedicato o una VPS, questi trucchi ci aiuteranno ad aumentare la sicurezza della nostra permanenza in Rete.
I Nostri obiettivi:
Impedire di stampare la firma del server Apache come parte di una richiesta Web: questo non è necessario e fornisce agli aspiranti hacker informazioni sul nostro server.
Negare l’accesso diretto a determinati file (ad esempio .git, .json, .sql)
Impedire l’esplorazione delle directory: non consentire a estranei casuali di sniffare la nostrs struttura del server.
Non consentire di sostituire le config di Apache nelle directory (ad es. Non abilitare i file di configurazione .htaccess)
Tenete presente che se non autorizzate i file .htaccess dovrete probabilmente includere adeguate regole di riscrittura nella configurazione dell’host virtuale Apache in ogni sito. Le impostazioni e configurazioni elencate nel post, vi aiuteranno a rendere più sicuro il server, ma anche renderlo più veloce.
Configurazione Globale di Apache
Aprite il file di configurazione di Apache:
sudo nano /etc/apache2/conf-enabled/security.conf
Apportate le seguenti modifiche:
#...
ServerTokens Prod
#...
Set ServerSignature Off
#...
# Aggiungete il seguente blocco:
# ==============================================================================
# Impedisci l'accesso a qualsiasi directory .git
# ==============================================================================
<DirectoryMatch "/\.git">
Require all denied
</DirectoryMatch>
# ==============================================================================
# # Proteggi un intervallo specificato di file dall'accesso diretto
# Da notare l'inserimento di files Standard WordPress
# ==============================================================================
<FilesMatch "^(wp-config\.php|php\.ini|php5\.ini|install\.php|php\.info|readme\.md|README\.md|readme\.html|bb-config\.php|\.htaccess|\.htpasswd|readme\.txt|timthumb\.php|error_log|error\.log|PHP_errors\.log|\.svn)">
Require all denied
</FilesMatch>
# ==============================================================================
# Impedisci l'accesso ai file di configurazione JSON
# ==============================================================================
<FilesMatch "\.(json)$">
Require all denied
</FilesMatch>
# ==============================================================================
# Impedisci l'accesso ai dump sql: questi NON dovrebbero trovarsi nella radice
# del documento, ma nel caso non si sa mai...
# ==============================================================================
<FilesMatch "\.(sql)$">
Require all denied
</FilesMatch>
# ==============================================================================
# Prevenire gli attacchi xmlrpc: se non si utilizza xmlrpc, bloccare questo file
# per evitare tentativi di hacking. Specie per WordPress.
# ==============================================================================
<FilesMatch "^(xmlrpc\.php)">
Require all denied
</FilesMatch>
Prevenire l’incorporamento e lo sniffing
Imposta le intestazioni per tutti i file pubblicati:
L’intestazione NOSNIFF impedisce ai file IE di essere sniffati
L’intestazione SAMEORIGIN impedisce l’incorporamento di contenuti in siti diversi dal nostro
ATTENZIONE!!!! Per essere operativa questa funzione e non mandare Apache in errore, il modulo headers dev’essere abilitato. Quindi abilitiamolo:
Aggiungiamo quanto segue a /etc/apache2/conf-enabled/security.conf:
# L'impostazione di questa intestazione impedisce a MSIE di interpretare i file come qualcosa
# diverso da quello dichiarato dal tipo di contenuto nelle intestazioni HTTP.
# Richiede abilitazione mod_headers.
Header set X-Content-Type-Options: NOSNIFF
# L'impostazione di questa intestazione impedirà ad altri siti di incorporare pagine da questo
# sito come frame. Questo difende dagli attacchi clickjacking.
# Richiede abilitazione mod_headers.
Header set X-Frame-Options: SAMEORIGIN
Impedisci la navigazione nella directory
Aprire il file di configurazione pertinente per la modifica:
# Valuta di fare prima un backup dell'originale:
cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak
# Apri il file per la modifica:
sudo nano /etc/apache2/apache2.conf
# ------------------------------------------------------------------------------
# Disabilita la navigazione nella directory
# ------------------------------------------------------------------------------
<Directory /var/www/>
Options -Indexes
Options FollowSymLinks
AllowOverride None
Require all granted
</Directory>
… riavviare Apache:
sudo /etc/init.d/apache2 restart
Il vostro server Apache ora dovrebbe essere un po’ più sicuro. Le impostazioni di configurazione sono state applicate a livello globale, anziché in numerosi file .htaccess a livello di directory.
Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.
Non affidatevi al caso, ma in tema di sicurezza (in questo caso sicurezza server Apache) affidatevi sempre ad una Persona di Competenza.
Da inizio Gennaio 2020 è stato scoperto un malware chiamato XsamXadoo Bot. Questo malware può essere utilizzato per avere accesso a un negozio online e prenderne direttamente il controllo.
Pensiamo che il bot abbia utilizzato una vulnerabilità nota dello strumento PHP PHPUnit, segnalata come (CVE-2017-9841). https://security-tracker.debian.org/tracker/CVE-2017-9841. Sebbene questa vulnerabilità sia specifica per Server Linux e PHP v 5.x e inferiori, un aggiornamento a una versione superiore potrebbe mitigare il problema, ma non risolverlo definitivamente. Ecco cosa fare in questi casi.
Verificare se il sito web è vulnerabile
Per sapere se il negozio Prestashop è vulnerabile a un attacco, questo è quello che si deve fare. Se non siete a vostro agio nella manipolazione dei file nei vostri server, contattate una persona qualificata e competente in materia; agire senza una minima preparazione potrebbe compromettere la stabilità se non la funzionalità del vostro sito e negozio Prestashop.
Sul vostro server, cercate la directory “/Vendor” al livello principale del sito PrestaShop
Se la directory /Vendor contiene un’altra directory “/phpunit”, potreste essere vulnerabili a un attacco esterno.
Basta semplicemente eliminare la directory “/phpunit” e il suo contenuto.
Per i più esperti potete usare il seguente comando da Shell linux del server, lanciandolo dal path della directory principale del sito Prestashop /vendor
find . -type d -name "phpunit" -exec rm -rf {} \;
Attenzione: non toccate nient’altro o potreste pregiudicare la funzionalità dell’intero sito. Altri file e directory (ad es. /Vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit/ o .xml) sono sicuri, non vanno eliminati.
Dopo aver controllato la directory principale di PrestaShop, ripetete gli stessi passaggi all’interno di tutte le directory dei moduli:
In ogni directory di un modulo, verificate se esiste una directory /Vendor
All’interno della /Vendor di ciascun modulo, verificate se esiste una directory “/phpunit”.
Se la directory di un modulo contiene questa directory “/phpunit”, questo modulo può rendervi vulnerabili a un attacco esterno.
Basta semplicemente eliminare la directory “/phpunit” e il suo contenuto.
Sempre per gli esperti utilizzate lo stesso comando dalla directory principale, /modules//vendor
find . -type d -name "phpunit" -exec rm -rf {} \;
Controllate di nuovo che nessuna directory /Vendor contenga una directory “/phpunit”
La cancellazione della directory “/phpunit” dalla cartella di un modulo non avrà alcuna conseguenza sul funzionamento del modulo stesso. Questo semplice passaggio proteggerà il vostro negozio online da questa vulnerabilità critica, sempre che il vostro sito Web non sia già stato compromesso. Se non avete trovato alcun modulo contenente questa directory “/phpunit”, il negozio non è vulnerabile.
Cosa può succedere se il negozio è compromesso?
Questa vulnerabilità consente a un utente malintenzionato di accedere al vostro sito web: ad esempio, un utente malintenzionato può potenzialmente rubare i vostri dati e prendere le autorizzazioni per eseguire qualsiasi comando indistintamente dal vostro permesso e/o autorizzazione.
Secondo la nostra analisi, la maggior parte degli aggressori inserisce nuovi file nel filesystem o modifica file già esistenti, come AdminLoginController.php.
Ecco un elenco non esaustivo di file dannosi noti che potrebbero indicare un negozio compromesso:
XsamXadoo_Bot.php
XsamXadoo_deface.php
0x666.php
f.php
Xsam_Xadoo.html
Potete verificare se i file core di PrestaShop sono stati modificati visualizzando la sezione “Elenco dei file modificati” nella parte inferiore della pagina “Parametri avanzati> Informazioni” nel Back Office di Prestashop. Tuttavia, questo controllo potrebbe non essere sufficiente poiché il sito potrebbe essere già stato compromesso. Quindi è utile eseguire delle procedure corrette:
Controllate attentamente che l’attacco non abbia lasciato alcun file sul vostro server, ad esempio file nascosti nel mezzo e/o con caratteristiche ereditarie.
Prendete in considerazione la possibilità di chiedere a tutti gli utenti dei negozi di modificare la propria password, inclusi anche gli utenti del back office, così come gli account dei clienti. Assicuratevi comunque prima, che nessun file compromesso sia ancora presente nel negozio.
Se ritenete che il vostro sito Web sia già stato compromesso, vi consigliamo di contattare SUBITO un esperto di sicurezza.
Cosa sta facendo in merito PrestaShop per risolvere questa vulnerabilità?
Stando alle loro dichiarazioni, tutti i partner e gli ambasciatori PrestaShop sono stati informati e dovrebbero aver già reso sicuri i negozi su cui hanno il controllo.
Tutti i moduli PrestaShop sono stati aggiornati e ora sono al sicuro. Attualmente stanno anche controllando ogni altro modulo disponibile su PrestaShop Addons, per verificare che non contengano la directory vulnerabile “phpunit”.
La sicurezza dei negozi online è al centro delle nostre preoccupazioni. Valutiamo e stiamo assicurando che l’impatto con questo malware sia più lieve possibile. Vi aggiorneremo regolarmente su questo argomento.
Questo sito Web utilizza i cookie per migliorare la tua esperienza. Supponiamo che tu sia d'accordo con questo, ma puoi decidere se desideri. AccettoRifiutoInfo
