Let’s Encrypt scopre il bug CAA e revoca i certificati dei domini sui nostri siti

Let's Encrypt

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.

URL: https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

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.

Per chi amministra Server Web tramite Pannello di Controllo Plesk, vi consigliamo di affidarvi all’addendum, con le procedure descritte in questo Post: Riattivare i Certificati Let’s Encrypt gestiti con Plesk.

Non affidatevi al caso, ma in tema di sicurezza (in questo caso Certificati LET’S Encrypt HTTPS) affidatevi sempre ad una Persona di Competenza.

Corsi e Affini sulla Sicurezza dei Siti Web

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio
 

Vulnerabilità confermata PHPUnit su Prestashop

prestashop

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.

  1. Sul vostro server, cercate la directory “/Vendor” al livello principale del sito PrestaShop
  2. Se la directory /Vendor contiene un’altra directory “/phpunit”, potreste essere vulnerabili a un attacco esterno.
  3. 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:

  1. In ogni directory di un modulo, verificate se esiste una directory /Vendor
  2. All’interno della /Vendor di ciascun modulo, verificate se esiste una directory “/phpunit”.
  3. Se la directory di un modulo contiene questa directory “/phpunit”, questo modulo può rendervi vulnerabili a un attacco esterno.
  4. 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.

Per informazioni più dettagliate e per esperti o di chi ne ha rigorosa competenza, consigliamo di consultare il post ufficiale di Prestashop che può aiutare in modo più dettagliato sulla forma e sull’incidenza che ha il negozio on Line con questo malware:
https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/

Download Modulo di verifica automatica di vulnerabilità:
https://www.presta-addons.com/free/m4check.zip

Download Modulo automatico di fix alla vulnerabilità phpunit:
https://www.myprestastore.com/downloads/module-prestashop-auto-clean-phpunit/

Terremoto nell’Open-Source. NGINX è prossimo alla chiusura?

Nginx

A fronte di fatti divulgati notoriamente circa la notizia, pare che il fatto sia divenuto virale, ma la verità si infittisce tanto quanto più grave sia la pratica e gli atti penali depositati dal Gruppo Rambler stesso.

I fatti

La polizia russa ha fatto irruzione negli uffici di Mosca di NGINX, Inc., una consociata di F5 Networks e la compagnia dietro la più famosa tecnologia di web server di Internet. L’attrezzatura è stata sequestrata e i dipendenti sono stati arrestati per essere interrogati.

La polizia di Mosca ha eseguito il raid dopo che la scorsa settimana il Gruppo Rambler ha presentato una violazione del copyright contro NGINX Inc., rivendicando la piena proprietà del codice del proprio server web. Il Gruppo Rambler è la società madre di rambler.ru, uno dei maggiori motori di ricerca e portali Internet della Russia.

Secondo le copie del mandato di ricerca pubblicato oggi su Twitter, Rambler afferma che Igor Sysoev stesse sviluppando NGINX mentre lavorava come amministratore di sistema per l’azienda, quindi sono i legittimi proprietari del progetto.

NGINX è un software open-source Web Server Reverse Proxy più conosciuto, alternativo ad Apache ed usato al mondo. Lo ha creato Sysoev nei primi anni 2000 e ha acquisito il codice NGINX nel 2004.

Nel 2009, ha fondato NGINX, Inc., una società statunitense, per fornire strumenti e servizi di supporto adiacenti per le implementazioni di NGINX. La società ha sede a San Francisco, ma ha uffici in tutto il mondo, tra cui Mosca. Il codice sorgente del server NGINX è ancora gratuito e gestito attraverso un modello open-source, anche se una grande parte dei principali collaboratori del progetto sono i dipendenti di NGINX, Inc., che hanno una buona fetta sulla gestione del progetto.

Sysoev non ha mai negato la creazione di NGINX mentre lavorava in Rambler. In un’intervista del 2012, Sysoev ha affermato di averlo sviluppato nel suo tempo libero e che Rambler non ne era nemmeno a conoscenza per anni. Ha detto che il server è stato inizialmente distribuito sui siti Rate.ee e zvuki.ru e Rambler ha iniziato a usarlo solo dopo che un collega lo ha chiesto.

Nel febbraio 2019, NGINX pare abbia detronizzato Apache HTTPD ed è diventato il server più diffuso su Internet. Secondo il sondaggio sul server Web Netcraft di dicembre 2019, NGINX avrebbe una quota di mercato del 38%.

Un dipendente di NGINX riferisce l’arresto di Sysoev.

La notizia del raid è diventata virale quando un dipendente NGINX ha pubblicato uno screenshot del mandato di ricerca su Twitter. Successivamente ha cancellato il tweet su richiesta della polizia russa. Il raid è stato confermato da altri dipendenti.

Nginx

Lo stesso dipendente ha affermato che durante il raid sono stati arrestati due dipendenti di NGINX, tra cui il suo creatore, il co-fondatore di NGINX Inc. e l’attuale CTO Igor Sysoev, nonché il co-fondatore Maxim Konovalov.

Nginx

Un portavoce di F5 Networks ha confermato il raid ma ha detto a ZDNet che stanno ancora raccogliendo i fatti e al momento non hanno ulteriori commenti.

Un portavoce del Gruppo Rambler ha confermato a ZDNet di aver effettivamente presentato un reclamo per violazione del copyright contro NGINX il 4 dicembre.

“Abbiamo scoperto che il diritto esclusivo di Rambler Internet Holding sul web server di NGINX è stato violato a seguito di azioni di terzi”,
ha detto Rambler a ZDNet.

Leonid Volkov, il capo di stato maggiore del candidato presidenziale Alexei Navalny, ha criticato il raid e il caso legale, sostenendo che dopo 15 anni, lo statuto delle limitazioni è scaduto per presentare un reclamo per violazione del copyright.

Rambler ha dichiarato di aver ceduto i diritti legali di rivendicare il copyright nei confronti di NGINX Inc. a Lynwood Investments CY Ltd, una società con sede a Cipro “hanno le competenze necessarie per fornire giustizia in materia di proprietà”.

Nginx non ha ancora emesso un comunicato stampa con i dettagli circa il raid. Vista la portata dei server dotati di tale software e la gravità della situazione legale, non ci resta che aspettare e attendere il verdetto finale!

Sorgente diretta da ZDNet: https://www.zdnet.com/google-amp/article/russian-police-raid-nginx-moscow-office/

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio
 

Comprendere i problemi di sicurezza dei Siti Web

Esistono Persone che vengono pagate per hackerare Siti, hosts Condivisi VPS ecc, In questo articolo spiegherò come è possibile, in modo da poter prevenire futuri attacchi dall’esterno. Come consulente per la sicurezza, spesso cerco i punti deboli nelle Applicazioni, negli E-commerce e nei Siti Web dei miei clienti. Molto spesso un attacco comincia sfruttando una falla di sicurezza che è visibile da remoto. Se continuerete a leggere questo articolo scoprirete come gli hacker trovano facilmente le falle nella sicurezza dei Web Server e indicheremo i metodi più opportuni per correggerli.

Per hackerare un’Applicazione, un negozio online o un Sito Web, gli hacker spesso prendono di mira i server dove sono ospitati. Per spiegare perché gli hacker fanno questo, si deve prima comprendere che cos’è l’hosting e che tipo di servizi hosting i nostri ISP ci mettono a disposizione.

Che cos’è l’hosting?

L’hosting è un servizio che vi consente di rendere disponibile la vostra Applicazione, il vostro negozio online o il vostro sito Web in Internet. L’hosting viene eseguito avviando servizi da macchine e apparati comunemente chiamati server. Quando qualcuno digita l’indirizzo del vostro Sito Web nel proprio browser, il suo dispositivo si connetterà al vostro server.

Se gli hacker sono in grado di assumere il controllo di un server, possono accederci senza problemi e manipolare tutte le informazioni in esso contenute. Inoltre, possono abusare della rete del server stesso a proprio vantaggio, anche per operazioni illecite, Spam, attacchi DDoS e tanto altro.

sicurezza_siti_web

Diversi tipi di hosting

La vostra Applicazione, negozio online o sito Web può essere ospitata in diversi modi. Ogni tipo di hosting ha diverse configurazioni per la sicurezza, ma è relativamente facile da capire in quanto tutto dipende dal modo in cui il server fisico (nel datacenter) è condiviso tra i siti Web.

Le società di web hosting (ISP) di solito gestiscono più server e dividono la loro capacità tra il numero di Siti che necessitano ospitare. Un grande server può facilmente ospitare più Siti Web, tutto a seconda della quantità di traffico che l’Applicazione, il negozio online o il Sito Web ha a disposizione. Banalmente il principio si basa sul tipo di contratto che viene stipulato con l’ISP.

Sostanzialmente esistono tre diversi tipi di hosting:

  • Hosting condiviso: il server gestisce più Siti Web condividendo il sistema operativo, la memoria, i core del processore e l’archiviazione del disco rigido. Non ci sono divisioni difficili tra i siti Web. Non tutti i siti sono associati tra di loro. Un Hosting condiviso spesso gestisce più contratti separati con diversi utenti. Nella maggior parte dei casi non si ha il controllo diretto dei servizi, che spesso risultano essere limitati e inefficaci per determinate operazioni e le applicazioni. Vedi ad esempio alcune limitazione nella gestione degli script PHP, gestione dei Database, limitazione nella gestione della banda e delle Sessioni del server. Spesso all’utente viene riservato un Pannello di Controllo in Formato WebGUI per permettere la gestione dell’host e delle configurazioni preliminari, senza avere le competenze necessarie al loro funzionamento. Puntamento domini, Shared hosting ed Email.
Schema di riferimento della struttura di un servizio di Hosting Condiviso.
  • Hosting VPS: il server fisico esegue più server privati virtuali (VPS) che dispongono tutti del proprio sistema operativo e della propria condivisione di memoria, capacità del processore e spazio di archiviazione. Un singolo VPS può essere configurato per eseguire uno o più siti Web (correlati). A causa della forte divisione tra le istanze virtuali, le VPS hanno limiti di gestione della Banda, e spesso i contratti hanno limiti proprio sul loro utilizzo. Ovviamente la gestione del Sistema Operativo, può essere assegnato all’Utente tramite sessioni e partizioni virtuali, oppure in mancanza delle corrette competenze sulla gestione dei servizi, molti ISP mettono a disposizione una serie di strumenti WebGUI utili per la configurazione. Puntamenti dominio, gestione DNS e Email, sono spesso integrati direttamente nei servizi e nei contratti associati.
sicurezza_siti_web
  • Hosting dedicato (solitamente detto Housing): si tratta di un server Fisico, con il suo sistema operativo, i servizi e le memorie appositamente assegnate dall’ISP. Il server fisico, può essere acquistato direttamente da noi e opportunamente collegato a Internet direttamente dal Datacenter del nostro ISP. Oppure molti contratti racchiudono già l’affitto di Macchinari già pronti e configurati, con range di IP assegnati per ogni singola macchina. Spesso tali servizi ISP non hanno alcun limite. Per gestire un Housing, sempre previo contratto stipulato con il nostro ISP, ci si serve di strumenti per accedere da remoto e permetterne la configurazione. Ancora sempre tramite contratto, l’ISP può affidare e/o installare un applicazione a conto terzi (vedi Plesk, Cpanel, ecc) di Pannelli di controllo, utili per chi non ha dimestichezza nell’amministrare un server da remoto. Questi pannelli User Friendly, spesso non sono Freeware e richiedono oltre all’assegnazione ed acquisto di una licenza, anche l’utilizzo e pagamento di un certificato che periodicamente (spesso ogni anno) va aggiornato.
Schema di riferimento della struttura di un servizio Housing (Server dedicato)

In questo senso, per i Server dedicati, il prezzo di gestione e affitto, può risultare maggiorato, a causa proprio dell’ulteriore assistenza dedicata, comunemente meglio detta Management, che essi richiedono periodicamente. La sicurezza nei servizi di Management di un server al giorno d’oggi è un’attività importantissima da non tenere affatto di poco conto. Una volta acquisita la competenza necessaria nella gestione e Management di un Server Dedicato, è possibile sfruttare tale opportunità come Business da integrare nella propria attività di Webmaster da offrire come consulenza Web.

Analisi delle Opzioni

Con i Server VPS e dedicati, nella maggior parte dei casi la faccenda può complicarsi ulteriormente, poiché a meno che non si aggiungano al contratto altri servizi di Monitoraggio e Management e/o di sicurezza, altresì dispendiosi, ci troviamo spesso a dover ricorrere alle competenze necessarie per reagire e fronteggiare le minacce provenienti dall’esterno.

Avvertenza: “Cloud Hosting” è spesso rinominato come hosting condiviso (titolo forviante)

È importante capire che il più moderno “Cloud Hosting” è in realtà in tutto per tutto un hosting condiviso con un nome di fantasia. Le Web agency spesso configurano il proprio server privato dedicato o virtuale per vendere hosting condiviso ai propri clienti. Quindi, a meno che voi non sappiate gestire una VPS o un server dedicato, è probabile che i vostri siti, applicazioni ed e-commerce siano ospitati in un hosting condiviso.

Problemi di sicurezza con l’hosting condiviso

I rischi per la sicurezza dell’hosting condiviso derivano principalmente dalla sua base di condivisione. Quando uno dei siti Web nello stesso server viene violato, c’è un‘alta probabilità che lo sia anche il vostro, già ospitato nello stesso server ne risente direttamente. In questa situazione, le misure di sicurezza applicate al vostro Sito Web potrebbero non essere sufficienti per proteggerlo dagli hacker. Anche perché tali manovre non sono contemplate da tali tipologie di contratto. Ecco perché gli ISP mantengono limitazioni nei loro servizi di Hosting Condiviso. Questo però non permette di avere le giuste proprietà per un fruizione corretta delle nostre applicazioni, siti web o altro, costringendoci anche noi a dover optare per una soluzione di livello superiore.

Indirizzo IP condiviso

Con l’hosting condiviso di solito significa che più siti Web condividono lo stesso indirizzo IP. Si incontrano svariati problemi se qualsiasi altro sito Web è stato colpito da un attacco, come l’invio di e-mail di spam o l’hosting di contenuti illegali. Ciò potrebbe causare l’inserimento inappropriato alle blacklist, con il conseguente blocco del sito stesso o il downgrade del vostro stesso sito, senza considerare le altre regressioni e posizionamenti dei motori di ricerca, che possono essere penalizzati per un lungo periodo di tempo.

Le Prestazioni

Se consideri che le società di hosting (ISP) di solito mettono centesimi (a volte persino migliaia) di siti Web sullo stesso server condiviso, capirai perché ciò aumenta la possibilità di essere hackerato. Oltre ai problemi di sicurezza, un servizio di hosting condiviso influisce anche sulle prestazioni del vostrosito Web, in quanto deve lavorare anche con altri siti Web con la stessa quantità limitata di risorse del server stesso. Se uno degli altri siti Web riscontra un traffico estremo, inevitabilmente rallenta anche la vostra applicazione, il vostro negozio online o il vostro sito Web!

Servizi di rete condivisa

Un altro problema con l’hosting condiviso è che di solito sul server sono abilitati molti servizi di rete, come un servizio web, posta, FTP e database. Questi servizi sono disponibili tramite porte impropiamente aperte. È una cattiva forma avere tutte le porte aperte ovunque perché espone a exploit quei servizi che sono in attivo su quelle porte. I firewall possono limitare ciò che è consentito connettere una determinata porta, ma in un ambiente di hosting condiviso queste restrizioni spesso non sono molto rigide (o addirittura assenti). Questo perché tali servizi aggiunti sono deleteri per le stesse performance della macchina stessa. Tuttavia per fortuna, la maggior parte degli ISP, affiancano tali soluzioni di sicurezza ai loro servizi, ma purtroppo con una massiccia limitazione di servizi offerti, come determinati Scripting, Database e/o Gestione di banda, li rende già precari per come abbiamo accennato prima.

Hackerare un’Applicazione, un e-commerce o di un Sito Web

Per hackerare la vostra Applicazione, negozio online o Sito Web, un hacker può eseguire la scansione del vostro server di hosting alla ricerca di porte aperte, identificando i diversi servizi in esecuzione sul server stesso. Il programma unix NMap è spesso usato per fare questo. L’hacker si collega al servizio in ascolto su porte aperte per scoprire di che programma e servizio si tratta.

Utilizzo di nmap per eseguire la scansione di un server di hosting, identificando i servizi di rete e le porte aperte

Queste informazioni possono essere utilizzate per verificare se i servizi di rete in esecuzione presentano punti deboli di sicurezza noti. Esistono librerie online in cui è possibile ricercare queste debolezze in base al nome e alla versione del software. Trovare una debolezza nota è facile come una query di Google. Se viene rilevato un punto debole esistente, l’hacker può utilizzarlo per ottenere l’accesso al server.

Controllando l’indirizzo IP del server di hosting, l’hacker può determinare se il server è condiviso con altre Applicazioni, negozi online o Siti Web (basta un semplice reverse DNS). È possibile utilizzando ricerche, elencare tutti i Siti Web ospitati sullo stesso server. Sebbene il vostro sia aggiornato e sicuro, altri sullo stesso server potrebbero eseguire software obsoleti (con punti deboli di sicurezza). Il software del sito Web comune è ben documentato, le versioni precedenti di PHP e WordPress hanno gravi problemi di sicurezza. In questo caso la soluzione è usare Plugin ufficiali, e scripting controllato secondo le esigenze, che nella maggior parte dei casi risulta impraticabile per le proprie esigenze.

Una volta che un hacker sa quale software utilizza il vostro Sito Web, è facile cercare buchi di sicurezza noti utilizzando database come cvedetails.com

In Conclusione

Il modo migliore per proteggere le proprie Applicazioni, e-commerce o Siti Web è limitare il più possibile l’esposizione agli exploit. Mantenere aggiornato il software del sito Web è fondamentale, ma potrebbe non essere sufficiente se il vostro hosting è condiviso.

Per evitare che altri hacker possano influenzare la vostra Applicazione, e-commerce e Sito Web, dovreste considerare di ospitarla su un server fisico o virtuale dedicato con il suo indirizzo IP. È quindi possibile rafforzare la sicurezza di un sito web filtrando le porte aperte e chiudendo i servizi di rete inutilizzati.

In questo modo riducete quella che gli esperti di sicurezza informatica chiamano “attack surface”. Più è piccolo, più diventa facile difenderlo. Basta acquisire le giuste competenze in merito, che sicuramente vi aiuteranno ad ottenere una corretta pratica di management del Server adottando le giuste strategie d’intervento e di difesa.

Contattateci ora!!!

Contatto Immediato

Contattate subito un Nostro consulente per avere un riscontro immediato. Sappiamo di certo come aiutare i nostri Clienti, al fine di avere un giusto e corretto servizio web ben difeso e operativo senza problemi.

Corsi e Affini sulla Sicurezza dei Siti Web

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio