Vulnerabilità plugin WordPress: Really Simple Security

Milioni di siti WordPress che utilizzano le versioni gratuite e Pro di Really Simple Security sono interessati da una vulnerabilità critica di bypass dell’autenticazione.

Questa è una delle vulnerabilità più gravi relative alla sicurezza per WordPress. Questa vulnerabilità riguarda Really Simple Security, precedentemente noto come Really Simple SSL , installato su oltre 4 milioni di siti Web e consente a un aggressore di ottenere da remoto l’accesso amministrativo completo a un sito che esegue il plugin.

La vulnerabilità è programmabile, il che significa che può essere trasformata in un attacco automatizzato su larga scala, che prende di mira i siti web WordPress. Il fornitore ha collaborato con il team dei plugin WordPress per forzare l’aggiornamento di tutti i siti che eseguono questo plugin prima che pubblicassimo questo post.

Puoi aiutare creando quanta più consapevolezza possibile su questo problema nella comunità, assicurandoti che tutti i siti ritardatari e non mantenuti vengano aggiornati alla versione con patch. Incoraggiamo i provider di hosting ad aggiornare forzatamente i propri clienti ed eseguire scansioni sui loro file system di hosting per assicurarti che nessun cliente stia eseguendo una versione senza patch di questo plugin.

È importante notare che anche le versioni Pro di questo plugin sono interessate da questa vulnerabilità e i siti che eseguono le versioni premium dovrebbero verificare che siano state aggiornate automaticamente, quindi aiutateci a far circolare la notizia. Sembra che i siti senza una licenza valida potrebbero non avere aggiornamenti automatici funzionanti.

I dettagli
Il 6 novembre 2024, il nostro team Wordfence Threat Intelligence ha identificato e avviato il processo di divulgazione responsabile per una vulnerabilità Authentication Bypass nel plugin Really Simple Security e nei plugin Really Simple Security Pro e Pro Multisite , che sono installati attivamente su oltre 4.000.000 di siti web WordPress. La vulnerabilità consente a un aggressore di ottenere in remoto l’accesso a qualsiasi account sul sito, incluso l’account amministratore, quando è abilitata la funzionalità di autenticazione a due fattori.

Gli utenti di Wordfence Premium , Wordfence Care e Wordfence Response hanno ricevuto una regola firewall per proteggersi da eventuali exploit che prendono di mira questa vulnerabilità il 6 novembre 2024. I siti che utilizzano la versione gratuita di Wordfence riceveranno la stessa protezione 30 giorni dopo, il 6 dicembre 2024.

Abbiamo contattato il team di Really Simple Plugins il 6 novembre 2024 e abbiamo ricevuto una risposta il 7 novembre 2024. Dopo aver fornito tutti i dettagli di divulgazione, lo sviluppatore ha rilasciato la patch per i plugin Pro il 12 novembre 2024 e per il plugin Free il 14 novembre 2024.

A causa della gravità critica di questa vulnerabilità (punteggio CVSS 9.8 Critico), il fornitore del plugin ha collaborato con il team dei plugin di WordPress.org per spingere un aggiornamento di sicurezza forzato alla versione patchata, 9.1.2, per chiunque utilizzi una versione vulnerabile del plugin. Ciò significa che la maggior parte dei siti dovrebbe già essere patchata o lo sarà presto, tuttavia, invitiamo gli utenti a verificare che i loro siti siano stati aggiornati all’ultima versione patchata di Really Simple Security, versione 9.1.2 al momento della stesura di questo articolo, il prima possibile se utilizzano la versione 9.0.0 o successiva. Un thread nel forum di WordPress.org per il plugin indica che gli aggiornamenti forzati sono iniziati questa mattina e potrebbero continuare nei prossimi giorni.

Riepilogo della vulnerabilità
Descrizione: Really Simple Security (Free, Pro e Pro Multisite) 9.0.0 – 9.1.1.1 – Authentication Bypass
Plugin interessati: Really Simple Security, Really Simple Security Pro, Really Simple Security Pro Multisite
Slug del plugin: really-simple-ssl , really-simple-ssl-pro , really-simple-ssl-pro-multisite
Versioni interessate: 9.0.0 – 9.1.1.1
ID CVE: CVE-2024-10924
Punteggio CVSS: 9.8 (critico)
Vettore CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Ricercatore: István Márton (Wordfence)
Versione completamente patchata: 9.1.2

I plugin Really Simple Security (Free, Pro e Pro Multisite) per WordPress sono vulnerabili all’aggiramento dell’autenticazione nelle versioni da 9.0.0 a 9.1.1.1. Ciò è dovuto alla gestione impropria degli errori di controllo utente nelle azioni API REST a due fattori con la funzione ‘check_login_and_get_user’. Ciò consente agli aggressori non autenticati di accedere come qualsiasi utente esistente sul sito, come un amministratore, quando l’impostazione “Autenticazione a due fattori” è abilitata (disabilitata per impostazione predefinita).

Analisi tecnica
Il plugin Really Simple Security, precedentemente noto come Really Simple SSL, è stato recentemente rinominato con l’ultimo aggiornamento della versione principale ed è stato ampliato con molte funzionalità di sicurezza come protezione dell’accesso, rilevamento delle vulnerabilità e autenticazione a due fattori. Sfortunatamente, una delle funzionalità che aggiunge l’autenticazione a due fattori è stata implementata in modo non sicuro, rendendo possibile agli aggressori non autenticati di ottenere l’accesso a qualsiasi account utente, incluso un account amministratore, con una semplice richiesta quando l’autenticazione a due fattori è abilitata.

Esaminando il codice si scopre che il plugin utilizza la skip_onboarding()funzione nella Rsssl_Two_Factor_On_Board_Apiclasse per gestire l’autenticazione tramite REST API.

CODICE
public function skip_onboarding( WP_REST_Request $request ): WP_REST_Response {
$parameters = new Rsssl_Request_Parameters( $request );
// As a double we check the user_id with the login nonce.
$user = $this->check_login_and_get_user( (int)$parameters->user_id, $parameters->login_nonce );
return $this->authenticate_and_redirect( $parameters->user_id, $parameters->redirect_to );
}

La check_login_and_get_user()funzione verifica l’utente utilizzando i parametri user_ide login_nonce.

CODICE

private function check_login_and_get_user( int $user_id, string $login_nonce ) {
if ( ! Rsssl_Two_Fa_Authentication::verify_login_nonce( $user_id, $login_nonce ) ) {
return new WP_REST_Response( array( 'error' => 'Invalid login nonce' ), 403 );
}
/**
* Get the user by the user ID.
*
* @var WP_User $user
*/
$user = get_user_by( 'id', $user_id );
return $user;
}

Il problema e la vulnerabilità più significativi sono causati dal fatto che la funzione restituisce un WP_REST_Responseerrore in caso di fallimento, ma questo non viene gestito all’interno della funzione. Ciò significa che anche nel caso di un nonce non valido, l’elaborazione della funzione continua e richiama authenticate_and_redirect(), che autentica l’utente in base all’ID utente passato nella richiesta, anche quando l’identità di quell’utente non è stata verificata.

In definitiva, questo rende possibile agli attori della minaccia di bypassare l’autenticazione e ottenere l’accesso ad account arbitrari su siti che eseguono una versione vulnerabile del plugin. Come sempre, le vulnerabilità di bypass dell’autenticazione e il conseguente accesso ad account utente con privilegi elevati, rendono facile per gli attori della minaccia compromettere completamente un sito WordPress vulnerabile e infettarlo ulteriormente.

Questa vulnerabilità colpisce in modo critico solo i proprietari di siti che hanno abilitato l'”Autenticazione a due fattori” nelle impostazioni del plugin.

Aggiornamento php, versioni supportate e non supportate

Quali versione di php è in uso nei vostri server e verifica della sicurezza

Fine supporto php 7.4 ovvero EOL (End Of Life)

Dal 28 Novembre 2022 e’ terminato il supporto di sicurezza al PHP 7.4 (nella sua ultima release 7.4.33) (fonte Unsupported Branches php.net).

Versioni PHP in uso

Nonostante sia finito il supporto a php 7.4 da mesi, le statistiche di rilevamento, a maggio 2023 (fonte W3techs) indicano che oltre l’88% dei server usa versioni non piu’ supportate per la sicurezza, ovvero PHP dal 7.4 a versioni ancora più obsolete. Solo una piccola percentuale ha adottato le nuove versioni tra cui la 8.0 che ricevera’ supporto fino a Novembre 2023.

Queste le percentuali di uso delle versioni PHP

  • Versione PHP 8 11.9%
  • Versione PHP 7 66.4%
  • Versione PHP 5 21.5%
  • Versione PHP 4 0.2%

Tra gli utenti di php 8 troviamo la maggioranza degli utenti che usano una versione che scadra’ a breve.

  • Versione PHP 8.0 54.6%
  • Version PHP 8.1 39.9%
  • Version PHP 8.2 5.5%
  • Version PHP 8.4 <0.1%

Nel frattempo, dal 28 Novembre scorso, sono stati scoperti per il PHP 8 numerosi nuovi problemi di sicurezza (fonte changelog php.net) che molto probabilmente affliggono anche le versioni precedenti (PHP 7.4, 7.3, 7.2, 7.0, etc.).
Alcuni di questi problemi di sicurezza sono stati classificati secondo il sistema CVSS (versione 3) anche come gravi.

Problemi di sicurezza PHP

Ecco alcuni esempi di problemi di sicurezza riscontrati nelle ultime versioni del php.

SAPI: DOS vulnerability when parsing multipart request body. (CVE-2023-0662)
PDO/SQLite: PDO::quote() may return unquoted string. (CVE-2022-31631)
GD: bug #81739: OOB read due to insufficient input validation in imageloadfont(). (CVE-2022-31630)
Hash: bug #81738: buffer overflow in hash_update() on long parameter. (CVE-2022-37454)
Phar: bug #81726: phar wrapper: DOS when using quine gzip file. (CVE-2022-31628)
Mysqlnd: bug #81719: mysqlnd/pdo password buffer overflow. (CVE-2022-31626)
Pgsql: bug #81720: Uninitialized array in pg_query_params(). (CVE-2022-31625)
XML: bug #79971 special character is breaking the path in xml function. (CVE-2021-21707)
FPM: bug #81026 PHP-FPM oob R/W in root process leading to privilege escalation (CVE-2021-21703).

Oltre a beneficiare dei fix sulla sicurezza, disporre di una versione aggiornata del php offre, in genere, dei miglioramenti nelle prestazioni del sito web. In alcuni casi si possono ottenere riduzioni nei tempi di risposta rilevanti, anche superiori al 100% di richieste al secondo in più a parità di risorse.
Dal sito di Kinsta si possono rilevare i risultati di test eseguiti sulle prestazioni di WordPress con diverse versioni di PHP.

Se non avete ancora applicato i fix di sicurezza sui vostri sistemi e’ urgente aggiornare PHP o affidare a sistemisti esperti le procedure di aggiornamento dei server web.
SicurezzaRete offre assistenza per eseguire l’aggiornamento del php a versioni sicure e supportate sui vostri sistemi.

Fine supporto e migrazione CentOS 7

Quando termina il supporto CentOS 7?

La fine del supporto, o EOL (End-Of-Life), per CentOS 7 è fissata al 30 giugno 2024

CentOS 7 è installato oggi su milioni di server. Purtroppo dopo giugno 2024 non ci saranno più aggiornamenti di sicurezza. Questo potrebbe essere un problema per numerosi server in produzione.

Cosa cambia con CentOS 7?

Nel dicembre 2020 Red Hat Software, la società che ha sponsorizzato il progetto della comunità CentOS, ha annunciato che non produrrà più versioni stabili del progetto CentOS, il clone libero della versione di Red Hat Enterprise Linux (RHEL). Red Hat ora supporta solo CentOS Stream, che è una versione di sviluppo di RHEL.

La versione principale di CentOS 8 doveva essere l’ultima versione stabile della comunità del clone RHEL e Red Hat ha anticipato la sua data di fine vita a dicembre 2021. Questo significa che CentOS 8 ha già raggiunto la fine del supporto. Il supporto di CentOS 7 continua fino a giugno 2024, ma non ci sarà una successiva versione stabile di CentOS a cui passare in seguito.

Che fare quando cessa il supporto a CentOS 7?

Rimane poco più di 1 anno per migrare, ma il tempo corre. Normalmente si dovrebbe migrere a CentOS 8 entro il periodo di tempo disponibile, ovvero prima di luglio 2024. Ma CentOS 8 ora è già EOL ovvero End-Of-Life, non è più supportato, quindi il passaggio a CentOS 8 non è un’opzione e non ci sarà neppure una versione di CentOS 9.

Per la maggior parte degli utenti aziendali e dei server in produzione, CentOS Stream non è un’opzione. La sua natura “rolling” significa che non è una copia esatta della versione RHEL corrispondente, quindi la compatibilità delle applicazioni può facilmente interrompersi o nuovi bugs essere introdotti. Devi passare a un’altra distribuzione Linux o trovare un modo per estendere il supporto di CentOS 7.

Trovare un’alternativa significa testare tutti i tuoi workloads su una distribuzione diversa, e questa è un’operazione a lungo termine che richiede una pianificazione approfondita.

Fine supporto CentOS7 EOL migrazione centos 7
Fine supporto CentOS7 EOL migrazione centos 7

Devo migrare CentOS 7?

Per avere un sistema aggiornato e sicuro devi migrare CentOS7 visto che non ci saranno aggiornamenti di sicurezza dopo il 30 giugno 2024.
Puoi migrare ad Almalinux 8 o Oracle Linux 8 oppure Rocky Linux 8.

Negli anni scorsi non era possibile migrare i sistemi operativi basati su RHEL, tra cui CentOS, da una Major release al quella successiva.
Visti gli ultimi sviluppi imposti dalla casa produttrice di questo OS si sono affacciate nuovi progetti che oggi permettono la migrazione.

Come posso migrare da CentOS 7 ad un nuovo sistema operativo aggiornato?

Il progetto piu’ importante che lo permette si chiama ELevate.
La migrazione può essere eseguita “sul posto” ovvero conservando dati e configurazioni. In altre parole le applicazioni installate e le impostazioni rimarranno inalterate. In ogni caso è obbligatorio eseguire un completo backup di dati e del sistema prima di procedere all’aggiornamento.

Alcune note importanti:
1) e’ obbligatorio eseguire un backup di sistema e dati prima di procedere
2) l’upgrade richiedera’ di eseguire dei riavvi di sistema
3) Poichè ELevate e’ un tool ancora in fase di test si consiglia, prima di procedere sui server in produzione, di eseguire dei test interni su sistemi di prova.

GLI AUTORI DEL PRESENTE ARTICOLO DECLINANO OGNI RESPONSABILITA’ DERIVANTE DALL’ USO DI QUANTO DESCRITTO.
LA MIGRAZIONE DEL SISTEMA OPERATIVO E’ UNA OPERAZIONE CHE PRESENTA POTENZIALI RISCHI E LA POSSIBILE PERDITA DI DATI O DI INTERRUZIONE DEL FUNZIONAMENTO DEI SERVIZI. QUESTO POICHE’ OGNI INSTALLAZIONE E CONFIGURAZIONE SOFTWARE ED HARDWARE E’ SPECIFICA.
SE NON SI DESIDERA CORRERE I RISCHI DI COMPIERE UNA OPERAZIONE POTENZIALMENTE DANNOSA E/O BLOCCANTE SI CONSIGLIA DI FAR EFFETTUARE LA MIGRAZIONE DI CENTOS 7 DA SISTEMISTI ESPERTI.
Il nostro suggerimento è di affidarti a sicurezzarete.com

La procedura per migrare CentOS,

Di seguito saranno descritti i passa da eseguire per passare da CentOS 7 a un sistema derivato da RHEL8 come AlmaLinux, CentOS Stream, Oracle e Rocky Linux. Useremo l’utente root.

1) aggiornare CentOS 7
Come prima cosa occorre avere un sistema con CentOS 7 installato e funzionante.
Successivamente, se già non lo fosse, occorre aggiornare all’ultima versione il sistema CentOS 7 e riavviare il server, cosi’ da caricare il nuovo kernel.

yum update -y
reboot

2) installare ELevate
Ora si deve installare il tool di aggiornamento scaricando il software necessario

yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

Installiamo anche i pacchetti leapp rispettivamente richiesti per il sistema verso cui vogliamo migrare. Le possibili scelte sono:

leapp-data-almalinux
leapp-data-centos
leapp-data-eurolinux
leapp-data-oraclelinux
leapp-data-rocky

Nel nostro caso migreremo un sistema CentOS 7 ad Almalinux 8 usando il comando:

yum install -y leapp-upgrade leapp-data-almalinux

Avviamo ora un check di pre-upgrade che creera’ un file di report utile a capire eventuali problemi e soluzioni da adottare per completare la procedura.

leapp preupgrade

Il file generato è:
/var/log/leapp/leapp-report.txt

In questa fase il sistema non verra’ ancora modificato.

CONSIGLI:
In alcune configurazioni, Leapp genera /var/log/leapp/answerfile con domande vero/falso. L’utilità Leapp richiede risposte a tutte queste domande per poter procedere con l’aggiornamento.

Le correzioni dal file /var/log/leapp/leapp-report.txt sono obbligatorie, ma puoi anche rivedere le altre se necessario.

Avviso:
Il controllo di pre-aggiornamento potrebbe avere esito negativo poiché CentOS 7 in installazione minima non soddisfa tutti i requisiti per la migrazione.

rmmod pata_acpi
echo PermitRootLogin yes | sudo tee -a /etc/ssh/sshd_config
leapp answer –section remove_pam_pkcs11_module_check.confirm=True

Controlla la pagina
https://wiki.almalinux.org/elevate/ELevate-frequent-issues
per problemi noti e frequenti e istruzioni per risolverli.

Avvia l’aggiornamento. Ti verrà offerto di riavviare il sistema al termine di questo processo.

leapp upgrade
reboot

Apparirà una nuova voce in GRUB chiamata ELEvate-Upgrade-Initramfs. Il sistema verrà avviato automaticamente al suo interno. Guarda come va il processo di aggiornamento nella console.

Dopo il riavvio, accedi al sistema e controlla come è andata la migrazione. Verifica che il sistema operativo corrente sia quello che ti serve.

cat /etc/redhat-release
cat /etc/os-release
rpm -qa | grep centos

Misurare e migliora la velocità dei siti di e-commerce

Velocità del sito di e-commerce come misurare e migliorare Prestashop, Woocommerce, Magento e WordPress. Analisi e fix dei difetti.

Le prestazioni del web sono un aspetto ormai fondamentale del buon successo di un sito di e-commerce.
Gli aspetti che vengono coinvolti relativi alle prestazioni si un sito web o di e-commerce sono molteplici ma due i principali:

  • la percezione di servizio funzionale e affidabile rilevato dagli utenti che decidono pertanto di procedere all’acquisto

Da studi eseguiti sull’uso dei siti di e-commerce si è constatato che gli utenti non completano le transazioni se queste si bloccano o sono lente.

  • l’effetto diretto sul posizionamento nei motori di ricerca

Gli esperti di web usability hanno trasmesso agli ingegneri degli algoritmi di posizionamento la direttiva volta a favorire i siti web aventi massima reattività e velocità di funzionamento.
Pertanto oggi la rapidità di caricamento dei siti web e di e-commerce è un parametro di fondamentale importanza per il buon posizionamento nei motori di ricerca.

Migliora il rendimento del sito di e-commerce all’aumentare della velocità?

Ci sono documentabili segnali che se un sito di e-commerce migliora le sue prestazioni si ottiene come conseguenza un miglior posizionamento nei risultati di ricerca. Da questo ne consegue una maggiore visibilità e anche un maggior numero di visitatori. Queste visite si possono poi convertire in acquisti e, pertanto profitti aziendali.

Segue un esempio reale di un lavoro svolto da Sicurezzarete.
Nella figura riportata sotto, al punto A è indicato il momento in cui è stata eseguita una ottimizzazione della velocità di caricamento del sito di e-commerce.
Dal punto A in poi si può vedere come siano migliorati il posizionamento, le impressioni totali e i click.

Miglioramento seo ecommerce con performance tuning sito web e server. Relazione performance tuning e visite.

Miglioramento seo e-commerce conseguente a performance tuning sito web e server. Evidente la relazione tra prestazioni e visite.

Misurare le prestazioni del proprio sito e-commerce

Molti sono gli strumenti che si possono utilizzare per la misurazione delle prestazioni dei siti web.
Sicuramente uno degli strumenti fondamentali è quello messo a disposizione da Google che è anche il dominatore assoluto tra i motori di ricerca. Deve pertanto essere considerato come obiettivo principale in una campagna di miglioramento nel posizionamento SEO (Search Engine Optimization) che agisce sulle prestazioni del sito.

Qui troviamo la console di Google che ci permette di misurare importanti parametri del nostro e-commerce:
https://pagespeed.web.dev

Segnali web essenziali

Una volta avviata l’analisi offre varie parametri da valutare. Uno che oggi è fondamentale è la valutazione dei segnali web essenziali

Misurare e migliorare la velocita di sito ecommerce

Significato dei segnali web essenziali

Largest Contentful Paint, LCP

Rappresenta il tempo necessario per visualizzare nel browser il contenuto più grande in termini di dimensioni, sia esso una immagine o un blocco di testo.
Quali sono le cause di uno scarso valore di LCP?

  • Tempi di risposta del server lenti
  • JavaScript e CSS che bloccano il rendering
  • Tempi di caricamento delle risorse
  • Rendering lato client

First Input Dalay, FID

Rappresenta il tempo che passa dal momento in cui una pagina viene richiesta e il momento in cui può accettare una interazione con l’utente. Questo valore dovrebbe rimanere inferiore a 100 millisecondi (0,1 secondi).
Come migliorare il valore di FID?

  • Riduci il tempo di esecuzione di JavaScript
  • Riduci al minimo il lavoro del thread principale (lato client)
  • Mantenere bassi i conteggi delle richieste e
  • Ridurre le dimensioni degli oggetti trasferiti

Cumulative Layout Shift, CLS

Anche questo aspetto è legato al lavoro che deve compiere il browser per riposizionare oggetti nella finestra di visualizzazione a seguito del caricamento asincrono dal server.

Cumulative layout shift


Per mantenere minimo questo valore e completare il rendering della pagina, si deve pertanto tentare di

  • Assegnare attributi di dimensione nelle immagini e negli elementi video,
  • Non inserire mai contenuto sopra il contenuto esistente, tranne in risposta a un’interazione dell’utente

Altri parametri con non fanno parte dei “Core Web Vitals” (https://web.dev/vitals/) di Google ma che risultano di grande importanza sono:

First Content Paint, FCP

E’ il tempo che intercorre tra l’inizio del caricamento di una pagina e l’inizio della visualizzazione della stessa.
Per essere accettabile questo parametro, il valore deve mantenersi al di sotto di 1,8 secondi.
I tempi migliori pero’ sono considerati quelli al di sotto di 0,3 secondi.

In questo caso molti sono gli interventi che si possono fare per migliorare questo parametro. I principali sono:

  • Eliminare le risorse che bloccano il rendering
  • Minimizzare CSS Rimuovi i CSS inutilizzati
  • Rimuovere JavaScript inutilizzato
  • Usare la preconnessione ai server
  • Ridurre i tempi di risposta del server (TTFB)
  • Evitare i reindirizzamenti di più pagine
  • Precaricare le richieste di chiavi
  • Evitare enormi carichi utili di rete
  • Fornire risorse statiche con una cache efficiente
  • Evitare una dimensione DOM eccessiva, ovvero una struttura della pagina troppo complessa.
  • Ridurre al minimo la profondità delle richieste critiche
  • Assicurati che il testo rimanga visibile durante il caricamento del webfont
  • Mantieni bassi i conteggi delle richieste e le dimensioni dei trasferimenti ridotte

Interaction to Next Paint, INP

E’ un parametro che misura la responsività del sito. Misura il tempo che impiega il browser a visualizzare un contenuto a seguito di una interazione con la pagina. Questo parametro tenta di valutare complessivamente l’intera pagina e tutte le interazioni possibili.
Un buon valore indica che questo valore deve stare sotto i 200 millisecondi (0,2 secondi).

Time to First Byte, TTFB

Questo parametro può variare molto e indica il tempo necessario a ricevere il “Primo Byte” di risposta dal server.
E’ pertanto un parametro che è molto influenzato dal server da cui viene erogato il sito di e-commerce.
Un valore adeguato di TTFB non deve superare i 0,8 secondi.
In genere le cause di un elevato TTFB sono dovute a:

  • Servizi di hosting con infrastrutture inadeguate per gestire carichi di traffico elevati
  • Server Web con memoria insufficiente che possono portare a thrashing
  • Tabelle di database non ottimizzate
  • Configurazione del server database non ottimale
  • Sistemi con caching non correttamente configurati o con dimensionamento insufficiente

Le soluzioni adottabili per migliorare il TTFB sono:

  • uso di server veloci non condivisi e adeguati al carico di lavoro
  • configurazione dei server corretta ed ottimizzata
  • uso di sistemi di cache corretti
  • tuning del server
  • ottimizzazione del database server
  • ottimizzazione del database (strutture dati)

Servizi e server Trenitalia off-line

Il servizio di biglietteria Trenitalia down per molti minuti

Giovedì 20 Ottobre 2022, i server dei sistemi di biglietteria di Trenitalia.it non funzionano dando disservizio a numerosi utenti.

Servizi e server Trenitalia off-line

Internal Server Error – Read

The server encountered an internal error or misconfiguration and was unable to complete your request.

Il servizio ha reso indisponibile il servizio di biglietteria a partire dalle 18.20 circa per oltre mezzora.

Proteggere WordPress da attacchi brute force

Come proteggere WordPress da continui tentativi di accesso non autorizzato?

State usando un server web per ospitare una o più installazioni del famoso e diffuso CMS WordPress? Allora quasi di sicuro riceverete migliaia di tentativi di accesso al pannello amministrativo dei siti realizzati con tale CMS.
Si tratta appunto di attacchi “brute-force”, per tentativi.
Se le password utilizzate sono robuste probabilmente gli accessi saranno bloccati. Purtroppo pero’, a volte, tali attacchi vanno a buon fine e, in genere gli accessi illegali sono usati per rubare dati sensibili, per installare malware nel sito compromesso o per inviare spam sfruttando le funzionalità del server. Per questo è necessario proteggere WordPress da questi tentativi.

Proteggere WordPress da attacchi brute force

Come sappiamo di essere vittime di questi attacchi brute-force rivolti a WordPress?

Possiamo controllare nei log e noteremo la ripetizione di righe di questo tipo:

46.161.27.153 – – [26/Sep/2022:06:28:41 +0200] “POST /wp-login.php HTTP/1.1″ 200 4522 “-” “Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0”
46.161.27.153 – – [26/Sep/2022:06:33:27 +0200] “POST /wp-login.php HTTP/1.1″ 200 4515 “-” “Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0”
46.161.27.153 – – [26/Sep/2022:06:33:30 +0200] “POST /wp-login.php HTTP/1.1″ 200 4522 “-” “Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0”
46.161.27.153 – – [26/Sep/2022:06:37:43 +0200] “POST /wp-login.php HTTP/1.1″ 200 4515 “-” “Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0”
46.161.27.153 – – [26/Sep/2022:06:40:16 +0200] “POST /wp-login.php HTTP/1.1″ 200 4522 “-” “Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0”

Come si può notare, gli IP da cui viene eseguito il tentativo di accesso sono ripetuti. Questo è un chiaro segno che l’accesso non è avvenuto e che si sta verificando una serie di tentativi al fine di individuare una password corretta. Normalmente vengono utilizzati vocabolari contenti migliaia di password tra le più diffuse oppure vocabolari costruiti analizzando dati relativi alla vittima (sito web, pagine social, informazioni personali, etc.)

Quasi certamente sul server avrete gia’ installato un firewall ma questo non previene i tentativi e non può bloccare l’attacco.

Come bloccare l’attacco brute-force e proteggere WordPress?

Se utilizzate come firewall il diffuso CSF (ConfigServer Security & Firewall), spesso si trova installato nelle installazioni cPanel. Questo firewall dispone di un componente, LFD, che verifica i tentativi di login al diversi servizi.
Può inoltre essere customizzato per integrare nuove regole di riconoscimento.
Possiamo pertanto personalizzare il file regex.custom.pm che si trova nella cartella di installazione del firewall ed aggiungere le seguenti righe.

# WP-LOGINS
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).] “\w(?:GET|POST) \/wp-login.php.*” /)) {
return (“WP LOGIN BRUTE FORCE”,$1,”WPLOGIN_FAILURE”,”6″,”80,443,21,22,25,23″,”900″);
}

Dovremo inoltre indicare che tra i log da analizzare ci sono anche quelli del web server (apache), modificando il parametro CUSTOM1_LOG=….

A questo punto, dopo aver riavviato firewall e demone LFD, se la pagina di login sarà richiamata più di 6 volte in un breve lasso di tempo, il firewall bloccherà per 900 secondi gli accessi alle porte usate dal web server ed anche ad altri servizi (ssh, smtp, ftp, etc).

Come verifico se sta funzionando la protezione di WordPress dagli attacchi?

Nel log del sistema di controllo degli accessi, LFD, troveremo traccia dei tentativi di accesso bloccati etichettati con il testo “WP LOGIN BRUTE FORCE”. Le linee si presenteranno nel seguente modo:

Sep 26 07:40:32 host100 lfd[29428]: (WPLOGIN_FAILURE) WP LOGIN BRUTE FORCE 198.98.60.32 (US/United States/ns1.boltflare.com): 6 in the last 3600 secs – Blocked in csf for 900 secs [LF_CUSTOMTRIGGER]
Sep 26 07:41:18 host100 lfd[29689]: (WPLOGIN_FAILURE) WP LOGIN BRUTE FORCE 188.166.236.35 (SG/Singapore/-): 6 in the last 3600 secs – Blocked in csf for 900 secs [LF_CUSTOMTRIGGER]
Sep 26 07:49:41 host100 lfd[32366]: (WPLOGIN_FAILURE) WP LOGIN BRUTE FORCE 188.166.183.39 (SG/Singapore/agvn.net-alpine): 6 in the last 3600 secs – Blocked in csf for 900 secs [LF_CUSTOMTRIGGER]

Questo è uno dei vari modi che abbiamo per proteggere WordPress da attacchi brute-force, in particolare è efficace se non possiamo adottare altre soluzioni più restrittive.

Vuoi attivare la protezione di WordPress ma preferisci che questo venga fatto da sistemisti esperti? Puoi richiedere il supporto di Sicurezzarete.

Vulnerabilità di Exchange mail server

Sono gravi le quattro vulnerabilità di Exchange comunicate da Microsoft, molte sono infatti le aziende che sono state attaccate e al quale sono stati rubati i dati contenuti nelle caselle di posta elettronica. Dati preziosi di aziende ma anche di università, centri di ricerca ed enti non governativi.
Le installazioni coinvolte sono molte: Exchange Server 2010, 2013, 2016 ed Exchange Server 2019, molto diffuse anche in Italia.

Exchange vulnerabilita mail server
Vulnerabilita’ mail server

Aggiornamento e patch di Exchange

Microsoft ha promesso che ci sara’ un aggiornamento, ma seguendo il ciclo tradizionale di patch (non vi saranno update, quindi, ancora almeno per qualche giorno). Riportiamo le descrizioni ali delle quattro vulnerabilità:

UPDATE: CVE-2022-2327 Microsoft Exchange Server Remote Code Execution Vulnerability (Ulteriore vulnerabilita’ di grado CVSS SCORE 8.8 !)

Attraverso un attacco da remoto gli hacker sono grado di prendere il controllo del server e di sottrarre i dati contenuti nel server della posta elettronica e i messaggi archiviati.

Secondo alcuni centri di ricerca l’attacco non si limita alle sole azienda negli stati uniti ma sta avvenedo a scala globale, pertanto è altamente probabile che aziende ed utenti in Italia possano essere state vittime di questo attacco e furto di informazioni.

Soluzioni

Purtroppo finchè il server non viene patchato o sostituito con altra installazione il problema sussiste e il servizio puo’ essere attaccato.

Chi volesse non avere piu’ costi e rischi di una installazione Exchange per la gestione della posta elettronica puo’ sostituire l’installazione con il nostro sistema integrato SRmail, un sistema basato su Linux, performante e sicuro.

Email aziendale, posta elettronica servizi a confronto

email aziendale confronto
email aziendale confronto

Comunque vengano chiamati, Email Aziendale, Posta Elettronica Aziendale, Piani Email Aziendali, si tratta sempre dei servizi più usati dalle aziende per lo scambio dei messaggi con i propri clienti e fornitori: posta elettronica.

Qui segnaliamo un caso reale di una azienda con diverse sedi in Italia che ha in uso 700 mailbox aziendali sul proprio dominio.
Il reparto IT ha deciso di rinnovare il proprio servizio e il fornitore e per questo ci ha chiesto di mettere a confronto quanto disponibile sul mercato. Ecco cosa e’ emerso.

Stime eseguite su 700 Email account (*):

Gmail: 3.996,72 Euro/mese IVA COMPRESA (Caselle MAX 30 GB)

OVH: 2.553,46 Euro/mese IVA COMPRESA (Caselle MAX 50 GB)

Aruba: 1.779 Euro/mese IVA COMPRESA (Caselle MAX 25 GB)

Sicurezzarete: 470,00 Euro/mese IVA COMPRESA (Caselle MAX 30 GB)
Server mail dedicato, antivirus, antispam, firewall, pannello amministrativo, certificato ssl per tutti i protocolli (web, IMAP, SMTP), accesso tramite i protocolli POP3, IMAP e webmail, mailbox fino a 30 GB. Server fully managed ovvero gestito da Sicurezzarete (non occorre ulteriore assistenza). Durata minima contratto 6 mesi.
Stesso costo fino a 1000 Account.

In sostanza l’adozione di un server mail gestito (managed) per la gestione della email aziendale permette di avere un risparmio del 73% rispetto al servizio cloud piu’ economico e di avere a disposizione servizi migliori (30 GB di storage contro 25 GB spazio mailbox). Se poi il confronto dei servizi di email aziendale viene fatto con provider come Gmail o OVH il risparmio sale ad oltre l’ 88%. Se il numero di mailbox fosse maggiore di quello usato nel nostro confronto (700 mailbox aziendali), il risparmio risulterebbe ancora superiore.

Con Sicurezzarete e’ sufficiente richiedere l’attivazione del Server Email Aziendale e saranno fornite le credenziali di accesso al nuovo server per attivare autonomamente e gestire tutte le caselle email necessarie.

RICHIEDI INFORMAZIONI

(*) I calcoli sono stati eseguiti alla data del 27 ottobre 2018, aggiornati al 16 Gennaio 2021 e sono stati considerati i costi dei servizi piu’ possibile simili tra loro visto che alcuni fornitori scorporano in varie componenti i servizi acquistabili (estensione spazio di archiviazione, servizio imap, filtro antispam, blocco antivirus). Di ciascun fornitore viene riportato il link al listino usato sul relativo nome.

Vulnerabilità VMWare grave 9.8 su 10

Una grave vulnerabilità ai sistemi di virtualizzazione VMware, versioni 6.5, 6.7 e 7.0 è stata di recente scoperta e pubblicata del produttore (il 25 maggio 2021).
La falla al sistema affligge la componente VMWare vCenter, e permette di eseguire comandi con pieni privilegi amministrativi da remoto senza nessuna autenticazione.
La vulnerabilità VMware e’ cosi’ grave e facilmente sfruttabile che e’ stata classificata (CRITICAL) con punteggio 9.8 su 10 da sistema CVSS 3.x.
Se il servizio e’ in ascolto accessibile dalla porta TCP 443 (configurazione tipica e molto diffusa) si puo’ avere pieno controllo del sistema operativo ed eseguite qualsiasi operazione.
Stanno da giorni circolando script che permettono di sfruttare facilmente la falla indicata e sono gia’ stati rilevati numerosissimi attacchi ai sistemi accessibili dalla rete.

vulnerabilità VMware
vulnerabilità VMware

Riferimenti
Data: 2021-05-25
CVE(s): CVE-2021-21985, CVE-2021-21986
Prodotto affetto: VMware vCenter Server updates address remote code execution and authentication vulnerabilities
URL: VMSA-2021-0010 (vmware.com)

Red Hat introduce RHEL una versione gratuita per piccoli carichi di lavoro fino a 16 sistemi

Dopo aver ricevuto molti reclami sugli ultimi piani di sviluppo per CentOS Linux, Red Hat inizierà a offrire Red Hat Enterprise Linux a costo zero per piccoli carichi di lavoro per la produzione e lo sviluppo.
Quando Red Hat ha annunciato che avrebbe cambiato CentOS Linux da un clone stabile di Red Hat Enterprise Linux (RHEL) a una distribuzione Linux di tipo “rolling”, molti utenti di CentOS hanno reagito con grande disappunto. Ora, trovare una nuova pace con i numerosi utenti, Red Hat sta introducendo una modalità d’uso di RHEL gratuito.

Licenze REDHAT

Occorre segnalare che, al posto di CentOS Linux, Red Hat offriva da tempo agli sviluppatori l’uso gratuito di RHEL attraverso il programma Red Hat Developer. I termini dell’offerta in precedenza ne limitavano l’uso agli sviluppatori monomacchina. Ora Red Hat amplierà questo programma in modo che l’abbonamento per sviluppatore individuale a RHEL possa essere utilizzato anche in produzione per un massimo di 16 sistemi.
Per usufruire di questa possibilita’ di utilizzo e’ sufficiente la sola sottoscrizione al programma “Individual Developer”. Tale aggiornamento sara’ disponibile dal giorno 1 febbraio 2021.