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.

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 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

Migrazione CentOS, i passi da compiere

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

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 criticita’ 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.

Rocky Linux il nuovo clone di RHEL per i server

In arrivo in primavera il clone della distribuzione Linux Enterprise col cappello rosso.
La risposta dopo l’annuncio che a breve cessera’ il supporto di CentOS 8 (previsto inizialmente per il 2029 e anticipato al 2021 !)
L’annuncio di Jordan Pisaniello racconta quali sono gli sviluppi a poche settimane dall’avvio.
Le attese della comunita’ sono molte visto che la distribuzione e’ per molte aziende il sistema operativo alla base del proprio business.

Rocky Linux server enterprise

Il gruppo di sviluppo dichiara che la trasparenza con la comunità e per coloro che si affideranno a Rocky Linux è fondamentale.
Presto sara resa pubblica la Timeline del che seguira’ i seguenti passi:

  • realizzazione dei sistemi e delle infrastrutture
  • creazione delle infrastrutture per il build automatico dei pacchetti
  • il repository dei pacchetti sarà reso pubblico per i test
  • disponibilità dell’installatore per i test
  • stimato il tempo necessario per i test della comunità
  • rilascio della release-candidate

Fonte: https://fossbytes.com/first-release-of-rocky-linux-will-arrive-after-march-2021/

La fine di CentOS come distribuzione Enterprise

In settembre si discuteva. Una idea sul futuro di CentOS: penso non sia roseo.

Senza tediarti gli eventi passati sono questi (la storia si ripete).

  • Redhat (la compagnia) fa business con la sua distribuzione libera e gratuita chiamata appunto “RedHat”, e’ il 1995 circa
  • per fare piu’ contratti di assistenza e profitto la distribuzione RedHat viene trasformata in Red Hat Enterprise Linux “RHEL”(circa 2003) non piu’ libera (solo i sorgenti, come impone la GPL sono disponibili), per accontentare la comunita’ e far sperimentazioni viene lanciata Fedora. Peccato che negli ambienti di produzione non si vuole sperimentazione ma STABILITA’.
  • Nasce CentOS come ricompilazione dei sorgenti di RHEL (circa 2004),
  • CentOS 6 e 7 si diffondono moltissimo nelle sale server,
  • 2018 tutti i dipendenti di CentOS assunti da RedHat !
  • 2018, viene rilasciata RHEL 8, la ricompilazione di RHEL 8 in CentOS 8 ritarda quasi 1 anno
  • 2018 nasce CentOS Stream: una versione non ricompilata dai sorgenti RHEL ma di sviluppo e test di RHEL (non adatta alla produzione… ci risiamo…)
  • 2019 RedHat viene acquisita da IBM…
    Mi sembra sia chiaro che i giganti dell’informatica (Google, Amazon, IBM, Oracle, …) ormai abbiano capito i modi per aggirare o superare gli ostacoli imposti dalle licenze del software libero e stanno producendo enormi profitti da cio’.
    Cosa ne sara’ di CentOS ??? Difficile dirlo ma e’ presente in una grossa fetta degli ambienti server e difficilmente non stimola l’appetito di soldi del mondo informatico.

Oggi 12 Dicembre 2020, la notizia che CentOS 8 e suoi futuri sviluppi termineranno. Sostituiti con una distribuzione di sviluppo e NON di produzione.
La notizia riporta chiaramente: “CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021.”

Fonte: https://blog.centos.org/2020/12/future-is-centos-stream/

Addio CentOS RIP