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/

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.

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.

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/

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.

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.

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

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

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.

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.

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.

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

Ormai è un fattore imperativo anche per i semplici gestori ed amministratori di web server: la sicurezza è essenziale anche per i servizi web non e non solo per i siti. No parliamo del protocollo HTTPS. Tale non è sinonimo di sicurezza nei servizi Web che gli ISP ci mettono a disposizione per amministrare in tranquillità un Web Server.

Con il periodo estivo gli attacchi ai servizi Web si intensificano in modo esponenziale. Penetrazione, SQL injection, DDoS sono solo alcuni dei tanti metodi che i malintenzionati usufruiscono per minare i nostri server. E non è una questione di livello di importanza o di utilità di un sito. Chi per grandi Compagnie, PMI o piccole realtà attive nel web, tutte possono essere sensibili ad attacchi di qualunque tipo.

Ecco perché con questo articolo vogliamo sensibilizzare gli utenti in modo attivo, facendo comprendere le regole e i metodi essenziali per alzare i livelli di sicurezza di un server web.

Il Firewall, la prima arma a nostra disposizione.

Un Server è una macchina che gestisce servizi e come tali operano con protocolli, sfruttando le Reti configurate. Un Server web, sia su Macchina Virtuale che in qualità di macchina dedicata, è per forza di cose attivo su classi di IP pubbliche (private se dietro un NAT, ma questa è un’altra storia).

Il Firewall è il primo tool a nostra disposizione per proteggerci a basso livello. Molti ISP mettono a disposizione, in affitto o correlati nelle loro offerte, Firewall Hardware già preconfigurati, ma che spesso sono ultra dispendiosi, pregiudicando i nostri investimenti.

Se state gestendo dei servizi web su Tech Unix, per evitare di appesantire il Vostro Server e di conseguenza il vostro portafogli, sappiate che di default Linux utilizza Netfilter già integrato nel sistema. Il programma che sfrutta queste funzionalità è IPTables: il Firewall per eccellenza.

Quando acquistate o affittate un Server presso il vostro ISP, la macchina vi viene fornita con un box di Network config standard, ma a traffico aperto in qualunque direzione, su qualsiasi porta voi utilizziate. Insomma il Server è letteralmente privo di sicurezza. Spetta a voi configurarlo a dovere.

Per essere pratici potete creare una serie di regole Firewall nel INCOMING Traffic come segue:

• Bloccare tutte le porte sul traffico INCOMING
• Tenere aperte solo le porte di servizio necessarie, come
  80,443 (HTTP,HTTPS) 21(FTP standard), 22 (SSH per admin da remoto)…ecc (nello standard)

Ovviamente avrebbe più incidenza se tali porte fossero concesse a sorgenti di IP statici (magari per il controllo da remoto), in modo da poterne usufruire personalmente tagliando fuori chi non ne è autorizzato.

Questa particolarità operativa la affrontiamo dettagliatamente in un approfondimento contenuto nel corso “Linux Web Server Administrator“, che permette di accedere ad un Server da remoto, solo a sorgenti IP autorizzate, statiche o anche dinamiche, attraverso determinate procedure di configurazione. In questo modo potremo usufruire delle nostre priorità senza abbassare i livelli di sicurezza.

Web Application Firewall, l’agente per le nostre Web Applicatin

Molti lo confondono con il Firewall di cui abbiamo parlato precedentemente, ma sono 2 cose distinte. Mentre IPTables (Firewall) agisce sui livelli più bassi del nostro Network, su più servizi configurati, il Web Application Firewall, applica dei filtri dedicati e pre-configurati unicamente sui servizi e porte di utilizzo Web, es. come HTTP e HTTPS, siti, Web Application ecc..

Solitamente chiamato WAF, agisce in simbiosi con alcuni servizi di terze parti, spesso collegati da API o legati ad azioni esterne. Il Mod Secure di Apache non è un WAF, e nemmeno un Reverse Proxy. Stesso un Proxy non è un WAF.

Un WAF agisce sistematicamente sul traffico di layer Application (vedi TCP, ISO/OSI) cui è stato congegnato, affidandosi a regole e filtri ben precisi. Quindi per tutti i servizi associati al Web.

A meno che non si voglia disporre di alte prestazioni della macchina, infatti avviare un WAF richiede un altissimo dispendio di risorse di memoria e di accesso al disco, molti servizi WAF sono resi disponibili esternamente da compagnie di terze parti.

Per nominarne due, le più utilizzate sono Wordfence, ottimizzato per servizi Web basati su WordPress. Integra autonomamente nel CMS un sistema di regole configurabili, a seconda delle sottoscrizioni, già attivi in WordPress, del tutto Free anche se senza alcun limite eccessivo, è disponibile in versione PRO più completo.

In alternativa segnaliamo Sucuri. Leader in questo tipo di servizio offerto, si adatta benissimo su qualsiasi supporto e servizio Web, indistintamente dalla sua configurazione. Anche se limitato nelle versioni Free, tramite un sistema di abbonamento, garantisce un altro livello di stabilità su qualsiasi supporto richiesto, con la possibilità di essere personalizzato nelle sue configurazioni.

Quindi un WAF è una priorità di alto livello, per tener lontani accessi e tentativi di intrusione o iniezione di codice malevolo, accessi via web, attraverso le porte aperte che permettono al nostro Server di far fruire tutti i servizi Web di cui abbiamo bisogno.

Fail2Ban e gli Attacchi DDoS

In Linux esiste un ottimo strumento che permette di evitare le intrusioni perpetrate da agenti esterni. Gli attacchi DDoS sono una piaga del Web e della Rete. Tutti i server ne sono assoggettati, anche quelli di minore importanza. Per questo Fail2Ban è una soluzione prioritaria da installare sui nostri server Linux.

Fail2Ban è la soluzione ottimale per innalzare il nostro livello di sicurezza quando lo sfruttamento del nostro server richiede molto dispendio di traffico. Ottimo contro gli attacchi DDoS, impedisce regolarmente al traffico malevolo di incidere sulle prestazioni della nostra macchina.

Questo Tool molto semplice da gestire, permette di configurare delle regole ben precise, usufruendo anche di IPTables, per bannare autonomamente o rigettare, traffico anomalo, proveniente dall’esterno perpetrato direttamente verso i nostri servizi.

Il Backup dei dati

Il Backup dei dati, non dev’essere considerata l’ultima spiaggia, o una risorsa di scarsa importanza nelle nostre regole di High Level Security. Come già affrontato in altri Post del Gruppo Facebook, l’importanza di dotare il Nostro Server di un sistema di Backup, ha una priorità essenziale.

Il backup non dev’essere attivato a senso unico, ma dev’essere configurato sistematicamente per permetterci un ripristino veloce dei dati e dei servizi del nostro server Web. Quindi dei Contenuti dati dei Siti e dei Dati di Storage (Database ecc), oltre che alle config dei servizi avviati.

Molti ISP, mettono a disposizione degli utenti una serie di servizi di Backuo on-line e/o Cloud come li chiamano loro, in modo da accorciare i tempi di ripristino. Pochi sanno però che è possibile creare una serie di comandi Bash, da attivare periodicamente sui sistemi Linux, che permettono di creare Backup ricorsivi ed aggiornati, sfruttando protocolli e tool di default Unix, come Cron e Tar, senza acquistare ulteriori licenze a discapito dei nostri investimenti IT.

Nel corso “Linux Web Server Administrator” è specificato come adottare questi sistemi di Backup, nelle proprie macchine, senza richiedere l’attivazione di ulteriori servizi da parte del vostro ISP, a vantaggio del nostro investimento e delle nostre tasche.

Aggiornamenti OS Costanti

Molti malintenzionati tendono a sfruttare determinati Bug di sistema o 0-Day come li vogliamo chiamare, che possono minare la sicurezza dei nostri server. Per ovviare a questo, è bene tenere sempre aggiornato costantemente il Sistema Operativo.

Non è una questione di tecnologia o di portanza della macchina. Periodicamente le Case di distribuzione, rilasciano non diciamo quotidianamente, degli aggiornamenti se non upgrades dei sistemi operativi.

Il Kernel Linux, poi non è mail statico e viene costantemente aggiornato. L’aggiornamento dei siatemi onerativi, dei pacchetti e delle applicazioni dev’essere una costante imperativa nelle gestioni ed amministrazioni dei Server Web.

Un costante monitoraggio dei pacchetti, degli aggiornamenti ma soprattutto del traffico ci mette nelle condizioni ottimali per aumentare la sicurezza dei nostri server.

Speriamo che tali specifiche siano state di facile apprendimento a chi necessita di amministrare e/o gestire dei Server Web Virtuali o dedicati che siano. Per qualsiasi domanda o chiarimento, lasciate un commento a questo articolo. Oppure postate nel Gruppo Facebook delicato ai “Sistemisti e Amministratori di Reti – Italiani“,qualsiasi critica costruttiva è ben accetta.

Corsi ed affini

Abbiamo iniziato a testare l’ultima versione di Ubuntu 18.04. La prima cosa che abbiamo notato è stata la diversa gestione delle interfacce di rete. Il modo in cui Ubuntu gestisce le interfacce di rete è completamente cambiato.

Mai sentito parlare di NetPlan? Probabilmente no!
Netplan è una nuova utility di configurazione della rete a riga di comando introdotta in Ubuntu 17.10 per gestire e configurare facilmente le impostazioni di rete nei sistemi Ubuntu. Ti consente di configurare un’interfaccia di rete usando l’astrazione YAML. Funziona in combinazione con NetworkManager e i demoni di rete systemd-networkd (indicati come renderer, è possibile scegliere quale di questi utilizzare) come interfacce per il kernel.

Leggendo la configurazione di rete descritta in /etc/netplan/*.yaml, in questi tipi di file è possibile memorizzare le configurazioni per tutte le interfacce di rete.

In questo articolo, spiegheremo come configurare un indirizzo IP statico o dinamico di rete per un’interfaccia di rete in Ubuntu 18.04 usando l’utilità Netplan.

Questo nuovo strumento sostituisce il file delle interfacce statiche (/etc/network/interfaces) precedentemente utilizzato per configurare le interfacce di rete Ubuntu. Ora si deve usare /etc/netplan/*.yaml per configurare le interfacce di rete Ubuntu.

Elenca tutte le interfacce di rete attive su Ubuntu

Innanzitutto, è necessario identificare l’interfaccia di rete che si intende configurare. Puoi elencare tutte le interfacce di rete collegate sul tuo sistema usando il comando ifconfig come mostrato.

$ ifconfig -a

Dall’output del comando precedente, identifichiamo le interfacce collegate al sistema interfaccia ethernet e l’interfaccia loop back. Tuttavia, l’interfaccia ethernet ens33 non è stata configurata e non ha un indirizzo IP statico.

Configurare un indirizzo IP statico con Ubuntu Server 18.04

In questo esempio, configureremo un IP statico per l’interfaccia di rete ethernet. Apri il file di configurazione di netplan usando l’editor di testo come mostrato.

$ sudo nano /etc/netplan/01-netcfg.yaml 

Importante: nel caso in cui un file YAML non venga creato dal programma di installazione della distribuzione oppure il file YAML non sia presente nella directory /etc/netplan/ , è possibile generare la configurazione richiesta per i renderer con questo comando.

$ sudo netplan generate

Inoltre, i file generati automaticamente possono avere nomi di file diversi su desktop, server, istanze cloud ecc. (Ad esempio 01-network-manager-all.yaml o 01-netcfg.yaml), ma tutti i file in /etc/netplan/*.yaml verrà letto da netplan.

Quindi il file dovrebbe apparire come qui sotto:

network:
    ethernets:
        ens33:
            addresses: []
            dhcp4: true
    version: 2

Da notare è la sintassi del codice che assomiglia ad un file di dati JSON.
Quello riportato sopra è un file di configurazione renderer di rete predefinito per un server Ubuntu che utilizza la configurazione IP DHCP…. Se si desidera impostare un indirizzo IP statico, configurare il file come mostrato di seguito:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: no
      addresses: [192.168.0.30/24]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

network: è il nodo dell’interfaccia di configurazione
version: la versione da attribuire
renderer: il tipo di attribuzione al sistema per inizializzarlo (networkd, demone di avvio da sistema, NetworkManager, settaggio da GUI Ubuntu, sconsigliata)
ethernets: Nodo delle interfacce fisiche
ens33: id dell’interfaccia fisica di sistema (riconosciuta)
dhcp4: attivare o disabilitare il dhcp (no nel nostro caso di IP Statico)
address: tra parentesi [] IP statico da assegnate con portata massima della NM
gateway4: Indirizzo IP di interfaccia gateway di configurazione della rete.
nameservers: Nodo DNS
addresses: DNS 1 e 2 tra parentesi [] separati da comma (virgola) – DNS pubblici di Google

La proprietà address di un’interfaccia prevede una voce di sequenza, ad esempio [192.168.14.2/24, “2001: 1 :: 1/64”] o [192.168.56.110/24,] (vedere la pagina man di netplan per maggiori informazioni).

Vogliamo far notare la completa differenza di scrittura e sintassi da mantenere rispetto alle configurazioni nei sistemi Ubuntu server precedenti allocate su /etc/network/interfaces:

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.30
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 8.8.8.8 8.8.8.4

Ora Salvate il file YAML nella sua posizione ed uscite. Quindi applicare le recenti modifiche alla rete usando il seguente comando netplan.

$ sudo netplan apply

Ora verificate ancora una volta tutte le interfacce di rete disponibili, l’interfaccia ethernet ens33 ora dovrebbe essere connessa alla rete locale e avere un indirizzo IP come mostrato nella seguente schermata.

$ ifconfig -a

Impostare l’indirizzo IP DHCP dinamico in Ubuntu Server 18,04 LMS

Per configurare l’interfaccia ethernet ens33 e ricevere dinamicamente un indirizzo IP tramite servizio DHCP, utilizzare semplicemente la seguente configurazione:

network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     dhcp4: yes
     dhcp6: yes

Salvate il file ed uscite. Quindi applicare le recenti modifiche alla rete e verificare l’indirizzo IP utilizzando i seguenti comandi.

$ sudo netplan apply
$ ifconfig -a

D’ora in poi il sistema riceverà un indirizzo IP in modo dinamico da un router.

Potete trovare maggiori informazioni e opzioni di configurazione consultando la pagina man di netplan.

$ man netplan

Congratulazioni! Avete configurato correttamente una rete con indirizzi IP statici per i vostri server Ubuntu. Se avete domande, condividetele con noi sui social tramite il modulo di commento qui sotto. Oppure dalla nostra Pagina Facebook o dal Gruppo ufficiale Sistemisti di reti Italiani.

Corsi ed affini