Gli attacchi hacker in azienda sono in netto aumento. Sia le imprese più grandi, con una struttura abbastanza articolata, ma soprattutto le piccole imprese, anche a gestione familiare, che si ritrovano un piccolo tesoretto di dati. E anche se in azienda si tenta di installare sistemi di sicurezza e di protezione, i pirati informatici stanno attaccando il punto più debole ed imprevedibile: i dipendenti.

Sono l’anello più delicato. Sia perchè non tutti hanno l’adeguata preparazione, sia perchè spesso i dipendenti attuano comportamenti imprevedibili e mescolano dati aziendali e personali. Ecco i metodi con cui gli hacker prendono di mira i tuoi dipendenti, per permetterti di stabilire da subito una politica di sicurezza adeguata.

Attacchi hacker in azienda. Il binomio peggiore? il dipendente sui social

Il campo più esposto in assoluto sono certamente i social network. 

Viviamo in un mondo incentrato sul raccontare a tutti quello che stiamo facendo mentre lo stiamo facendo. I cybercriminali hanno solo bisogno di accedere a un paio di social network per mettere insieme un quadro completo della vita di una persona. Facebook può offrire una protezione maggiore dagli attacchi ma i profili pubblici forniscono ancora un sacco di dati personali.

Facebook, Twitter, LinkedIn, Instagram possono dire quasi tutto di una persona: la famiglia, gli amici, i ristoranti preferiti, la musica, gli interessi. Mettendo insieme tutte queste informazioni, potete immaginare quanto potenti possano essere questi strumenti per un hacker.

Così ogni nuovo contatto aumenta l’esposizione al rischio lasciando che uno sconosciuto abbia accesso alla rete professionale. I dipendenti con grandi reti sociali, come quelli di marketing e PR, aumentano la loro probabilità di attacco più di tutti.

Twitter, come LinkedIn, comporta un grande rischio di social engineering perché c’è una barriera molto debole da sfondare per i malintenzionati. Anche Facebook e Snapchat sono dei social network a rischio di attacco ma le persone sono sempre meno propense ad accettare richieste da parte di individui che non hanno mai conosciuto. Su Twitter e LinkedIn, le persone si connettono basandosi sull’interesse reciproco e sulle connessioni professionali. Gli aggressori quindi possono inviare messaggi diretti facendoli sembrare innocui, ma in realtà non lo sono.

Le minacce di sicurezza informatica coprono tutti i social network, ma uno dei più pericolosi in assoluto per un dipendente aziendale è LinkedIN. Si tratta di un social network delicato a causa della sua doppia natura: da una parte si desidera espandere la propria rete e migliorare la propria visibilità professionale, ma dall’altra si sta anche inconsapevolmente aumentando la probabilità di attacco poiché non si sa con chi ci si stia collegando.

Attacchi hacker in azienda: al primo posto il furto d’identità

Tutti i dipendenti sono quindi vulnerabili al furto dell’identità. I dirigenti e tutti coloro che amministrano qualcosa, con accesso a dati sensibili, sono ad alto rischio.

Mantenere una costante consapevolezza in tutta l’organizzazione, in modo che tutti siano attenti a questo tipo di attività, è la chiave per cercare di arginare gli attacchi hacker in azienda. Per la maggior parte, chiunque può creare un account e fingere di essere qualcuno che non è”, avverte Steve Ginty, co-fondatore di PassiveTotal e ricercatore presso RiskIQ.

Rubare l’identità dei vostri dipendenti è un metodo comune per effettuare attacchi hacker in azienda.

Per questo motivo, ognuno dei dipendenti dovrebbe chiedersi: quanto bene conosco le persone con cui sono connesso? Quanti altri dei miei colleghi sono anch’essi in contatto con le mie cerchie? Queste persone hanno subito un furto d’identità in passato?

È anche interessante notare che se qualcuno ha subito un furto d’identità in passato è probabile che sarà preso di nuovo di mira in futuro. Se un dipendente riceve una richiesta da parte di qualcuno la cui identità è stata rubata in precedenza, dovrebbe prendersi del tempo per indagare sulla reale identità del contatto.

Il sito web aziendale: come fornire dati utili per attaccare l’azienda

Naturalmente gli aggressori fanno ricerche anche al di fuori dei social network per raccogliere informazioni sulle potenziali vittime. Il tuo sito web aziendale potrebbe essere usato per carpire informazioni per violazioni future.

“Anche se gli aggressori non conoscono la strada da seguire per effettuare l’attacco, possono acquisire molte informazioni attraverso risorse ad accesso libero, come i siti web aziendali: così avranno più possibilità di colpire una specifica società poiché hanno maggiore conoscenza dei loro dipendenti”, spiega Ginty.

Molte organizzazioni pubblicano sui loro siti web alcuni documenti del loro team, i consiglieri di amministrazione e spesso i dipendenti del loro staff, aggiunge Harris. Se un malintenzionato può capire in che modo sono strutturate le mail aziendali (ad esempio [email protected]) può facilmente scoprire le informazioni di contatto dei dirigenti e colpirle tramite spam.

Più informazioni possono raccogliere sui singoli dirigenti, più credibili possono essere gli attacchi hacker in azienda. “Le persone che fanno parte di una azienda e hanno profili troppo completi sul sito web aziendale, forniscono agli aggressori informazioni sufficienti a rendere gli attacchi quasi infallibili attraverso ingegneria sociale ed e-mail di phishing” dice Ginty. I siti aziendali sono il modo più facile di raccogliere informazioni per condurre con successo attacchi di ingegneria sociale.

I profili pubblicati sul sito aziendale, dunque, dovrebbero fornire informazioni utili per i lettori, investitori, clienti e fornitori ma non dovrebbero permettere di comprendere la struttura interna dei dati, come i numeri di telefono, il modello delle email, i sistemi operativi usati o le marche degli smartphone in dotazione.

Vishing: non solo tramite internet, gli hacker attaccano anche tramite telefono

L’adescamento telefonico, il cosiddetto “vishing”, è un metodo pericoloso, economico e sempre più usato dai malintenzionati per attaccare le loro vittime, dice Fincher di Social-Engineer Inc. Spesso, spiega, una azienda chiama i clienti per saperne di più su di loro e sui loro sistemi interni così da rilevare potenziali frodi o abusi.

I criminali informatici possono fare la stessa cosa. Accade spesso che gli aggressori contattino le aziende fingendosi nuovi clienti e richiedendo informazioni. Possono quindi raccogliere un sacco di dati riguardo i sistemi aziendali e i problemi attuali, essendo così avvantaggiati.

Questi tipi di attacchi sono notoriamente difficili da individuare. “Se gli hacker sono intelligenti, la gente non saprà di essere presa di mira” dice Hadnagy. “Un buon vishing può essere scambiato per una normale conversazione”.

Tuttavia, gli hacker inesperti possono commettere degli errori e ci sono alcuni segnali di allarme che i dipendenti possono notare. Alcuni possono tentare un attacco facendo troppe chiamate nell’arco di un breve periodo di tempo. Altri possono fare richieste ancor prima di aver sviluppato un rapporto con la propria vittima, sollevando il sospetto di attività fraudolente.

La tendenza dei dipendenti a fidarsi: la base degli attacchi hacker in azienda

Spesso gli aggressori possono indurre i dipendenti a fornire informazioni senza essersi prima identificati. Altre volte le aziende non hanno una procedura di autenticazione ben definita oppure non la usano.

“Se si chiama usando un tono amichevole e un numero di telefono legittimo, i dipendenti spesso non fanno domande e non contestano ciò che gli viene chiesto perché pensano sia da maleducati chiedere a qualcuno di provare la propria identità o la legittimità della richiesta” spiega Fincher. “È difficile capire se c’è un attacco hacker all’orizzonte”.

Hadnagy cita l’esempio di cybercriminali che chiamano fingendo di essere l’Agenzia delle Entrate, veste che usano per reclamare ritardi nel pagamento delle tasse e per minacciare l’arresto. Altri sostengono di far parte del personale di Microsoft offrendo il proprio supporto per fermare il traffico dannoso. Non appena gli verrà concesso l’accesso remoto, perlustreranno a fondo i PC della vostra azienda.

Le società accorte forniranno ai dipendenti politiche e linee guida da seguire per evitare di sembrare scortesi quando sarà necessario richiedere ulteriori informazioni all’interlocutore: spiegando perché hanno bisogno di verificare l’identità dell’interlocutore e di trattenere le informazioni finché la situazione possa considerarsi sicura.

La tecnica delle email: chiamata e mail successiva

Gli aggressori possono combinare truffe di vishing e phishing per creare un attacco a prova di bomba: chiamano la vittima per presentarsi e avere il pretesto per inviare una mail, e quindi spediscono un messaggio che i dipendenti di una azienda si aspettano di ricevere, per lanciare un attacco di phishing.

È difficile difendersi da queste truffe, perché non si può dire ai dipendenti di ignorare chiamate ed e-mail. “La sicurezza attraverso l’isolamento non è un grande piano” dice Fincher.

Tuttavia, si può spiegare ai dipendenti di evitare di aprire link o eseguire download di allegati da mittenti non verificati, e di stare allerta quando le domande poste da supposti clienti diventano troppo delicate.

Con un po’ di preparazione, i dipendenti possono essere in grado di individuare attacchi di phishing esaminando l’indirizzo e-mail, l’oggetto del messaggio e il formato, per notare segnali di una possibile truffa. Inoltre, messaggi di posta elettronica utilizzati in precedenti attacchi di phishing possono essere riutilizzati per identificare altri attacchi hacker in azienda.

“Spesso notiamo delle similitudini nei tentativi di phishing” dice Ginty. “Gli aggressori prendono di mira ampie fasce di individui e si lasciano alle spalle molti indizi che possiamo utilizzare per identificare futuri phishing”. Questi indicatori possono includere il linguaggio utilizzato nel corpo dell’e-mail, nel link, o nel sito web. Le aziende possono registrare i tentativi di attacco utilizzati in precedenza in modo da avere un’idea degli indizi da cercare in futuro.

Evitare attacchi hacker in azienda: non stressare i dipendenti

Dipendenti stressati prendono decisioni mediocri, spiega Hadnagy. Un dipendente stressato può non fare attenzione alle informazioni che rilascia ad un interlocutore, rilasciando informazioni sensibili senza aver prima verificato l’identità del destinatario.

Hadnagy ricorda un cliente con una rigida regola per il proprio call center che si è rivelata controproducente: i dipendenti che trascorrevano più di 90 secondi su una chiamata avrebbero avuto la loro retribuzione decurtata. Analizzando il risultato di questa norma, è risultato che i lavoratori passassero con facilità le informazioni, anche riservate, perché volevano terminare la chiamata il più rapidamente possibile e non incorrere nella sanzione.

“Gli hacker, che conoscono questi meccanismi, creano ambienti stressanti per effetture attacchi hacker in azienda, perché quando siamo sotto stress prendiamo decisioni spesso sbagliate”, osserva Hadnagy. Anche se non tutti i datori di lavoro hanno politiche così rigorose, vale la pena valutare il carico di lavoro dei dipendenti nel caso in cui si sentano eccessivamente sotto pressione. Per evitare che sbaglino.

Mettere in sicurezza Web Server Apache è una operazione di fondamentale importanza, dato che questo è molto spesso uno dei servizi più vulnerabile ad attacchi. Data la configurazione di default, molte informazioni sensibili possono essere sfruttate da un hacker per preparare un attacco all’intero web server.

La maggior parte delle applicazioni web vengono attaccate tramite XSS, furto di credenziali, sfruttamento malevolo delle sessioni e PHP Injection, attacchi che sono resi possibili proprio dalla debolezza del codice di programmazione e dalla incapacità di “sanificare” l’infrastruttura delle applicazioni web.

Stando a Cenzic, ben il 96% delle applicazioni testate presenta delle vulnerabilità; sotto è possibile visionare un grafico di Cenzic relativo ai trend di vulnerabilità del 2013.

Questa guida pratica ha come scopo proprio quello di fornire una serie di indicazioni necessarie per mettere in sicurezza web server Apache. Nel dettaglio, si discuterà di come rafforzare e rendere più sicuro un web server Apache su piattaforma Unix, con test eseguiti su Apache 2.4x (non c’è ragione di pensare che non funzionino su Apache 2.2x).

1. Si presuppone che Apache sia installato su piattaforma Unix. Se non è così, è possibile procedere all’installazione grazie alla Installation Guide o visionare una serie di video gratuiti relativi all’installazione di Apache, MySQL e PHP.
2. L’installazione di Apache sarà identificata con il nome di directory /opt/apache as $Web_Server
3. Si consiglia di fare un backup della configurazione esistente prima di procedere a qualunque modifica

Questa guida si indirizza agli amministratori, agli analisti di sistema e in generale a tutti coloro che desiderano mettere in sicurezza un web server Apache (è comunque necessaria una conoscenza di base sia di Apache che di Unix).

La sicurezza di un web server Apache: inizia dal controllare HTTP

Nella configurazione di default di Apache sono coinvolti molti dati sensibili che possono essere sfruttati per sferrare un attacco al web server. E’ quindi fondamentale per ogni amministratore mettere in sicurezza queste informazioni; come riportato da Cenzic, infatti, ben il 16% delle vulnerabilità è dovuta alla perdita di informazioni.

Per esaminare l’intestazione HTTP per la verifica sono necessari alcuni tool. La prima cosa da fare è quindi installare l’add-on Firebug su Firefox nel seguente modo:

• Aprire Firefox
• Accedere a https://addons.mozilla.org/en-US/firefox/addon/firebug/
• Cliccare su Aggiungi a Firefox

• Cliccare su installa
• Riavviare Firefox
• A questo punto è visibile l’icona di Firebug sulla destra della top bar

Per verificare le informazioni dell’intestazione HTTP è necessario cliccare sull’icona di Firebug. Oltre a questo ci sono molti altri tool online che consentono di verificare le informazioni dell’intestazione HTTP.

Per la sicurezza web server Apache, rimuovere la versione del server utilizzata

Si tratta di una delle prime cose da considerare se non si desidera mostrare quale versione del web server si sta utilizzando; mostrare quale versione è installata non fa altro che accorciare i tempi di un attacco hacker. La configurazione di default mostra la versione Apache e il tipo di sistema operativo come di seguito:

Server Apache/2.4.6 (Unix)

Implementazione:

• Andare su  $Web_Server/conf folder
• Modificare httpd.conf tramite vi editor
• Aggiungere la seguente direttiva e salvare httpd.conf

ServerTokens Prod

ServerSignature Off

• Riavviare Apache

ServerSignature rimuoverà le informazioni dal web server Apache generando pagine come 403,404.502 etc.

Verifica:

• Aprire Firefox
• Attivare Firebug cliccando l’icona dell’add-on
• Cliccare il tab Net

• Inserire l’URL nella barra degli indirizzi
• Espandere la GET request e a questo punto è possibile vedere che nella direttiva del server viene solo mostrato Apache, che è certamente meglio che mostrare il tipo e la versione del sistema operativo

Disabilitare la lista delle directory browser per la sicurezza del web server Apache

E’ molto importante disabilitare la lista delle directory nel browser di modo che non sia possibile per ogni visitatore vedere tutti i file e le cartelle archiviate nella cartella di root e nelle sottocartelle. Vediamo come questo appare nelle impostazioni di default:

• Andare su $Web_Server/htdocs directory
• Creare una cartella con alcuni file all’interno

# mkdir test

# touch hi

# touch hello

Ora proviamo ad accedere ad Apache tramite http://localhost/test

Come si vede vengono mostrate tutte le cartelle e i file, informazioni che di certo non si desidera mostrare.

Implementazione:

• Andare su $Web_Server/conf directory
• Aprire httpd.conf using vi
• Cercare una directory e modificare le opzioni None o –Indexes

<Directory /opt/apache/htdocs>

Options None

Order allow,deny

Allow from all

</Directory>

oppure

<Directory /opt/apache/htdocs>

Options -Indexes

Order allow,deny

Allow from all

</Directory>

• Riavviare Apache

Da notare, se vi sono delle directory multiple nel sistema, bisogna considerare di ripetere l’operazione per ognuna di esse.

Verifica:

Proviamo ad accedere ad Apache da http://localhost/test

Come si vede viene mostrato un “forbidden error” invece che la lista delle cartelle

Per la sicurezza web server Apache nascondi Etag

Etag header permette agli hacker di ottenere informazioni importanti come inode number, multipart MIME. Per prevenire queste vulnerabilità, bisogna procedere come di seguito.

Implementazione:

• Andare su $Web_Server/conf directory
• Aggiungere la seguente direttiva e salvare https.conf

FileETag None

• Riavviare Apache

Verifica

• Aprire Firefox e accedere all’applicazione
• Controllare l’intestazione HTTP in Firebug, Etag non sarà più visibile a tutti

Sicurezza di un web server Apache: controlla le autorizzazioni

Esaminiamo il caso di avviare Apache da un account senza privilegi. La configurazione di default di Apache viene eseguita come “nessuno” o “daemon”. E’ una buona pratica usare un account senza privilegi separato per Apache, così da proteggere tutti gli altri servizi nel caso vi siano delle faglie di sicurezza.

Implementazione:

• Creare un utente o un gruppo chiamato apache

#groupadd apache

# useradd –G apache apache

• Cambiare la propria directory di installazione apache al nuovo utente senza privilegi

# chown –R apache:apache /opt/apache

• Andare su $Web_Server/conf
• Modificare https.conf using vi
• Cercare l’utente e il gruppo di direttive e modificare come account apache senza privilegi

User apache

Group apache

• Salvare https.conf
• Riavviare Apache

Verifica

Usare il comando grep per l’esecuzione del processo http e assicurarsi che sia in esecuzione con l’utente apache

# ps –ef |grep http

Si noti che un processo è in esecuzione su root e questo perché Apache è su porta 80 e deve essere avviato da root. In seguito vedremo come cambiare il numero della porta.

Per la sicurezza web server Apache proteggi i permessi di configurazione directory

Di default i permessi binari e di configurazione sono di tipo 755 il che significa che ogni utente sul server è in grado di vedere la configurazione. Modifichiamo questo dato:

Implementazione

• Andare su $Web_Server directory
• Modificare i permessi per la cartella bin e conf

# chmod –R 750 bin conf

Verifica:

Attenzione alle impostazioni di protezione del sistema per la sicurezza del web server Apache

In un’installazione di default, gli utenti possono ignorare la configurazione di Apache utilizzando .htacces. Se si vuole impedire agli utenti la modifica delle impostazioni del server Apache, allora è possibile aggiungere AllowOverride a None come mostrato sotto ( questo deve essere fatto a livello root).

Implementazione:

• Andare su $Web_Server directory
• Aprire httpd.conf using vi
• Cercare la directory a livello root

<Directory />

Options -Indexes

AllowOverride None

</Directory>

• Salvare https.conf
• Riavviare Apache

Metodi di richiesta HTTP e sicurezza web server Apache

Il protocollo HTTP 1.1 supporta molti metodi di richiesta (query) che potrebbero non essere necessari, senza contare che alcuni di essi hanno dei potenziali rischi. In genere si ha bisogno solo dei metodi di richiesta GET, HEAD, POST in un’applicazione web, da configurare nelle rispettive directory. Di default la configurazione apache supporta anche i metodi OPTIONS, GET, HEAD, POST, PUT, DELETE, TRANCE, CONNECT per il protocollo HTTP 1.1

Implementazione

• Andare su $Web_Server directory
• Aprire httpd.conf using vi
• Cercare la  directory e aggiungere

<LimitExcept GET POST HEAD>

deny from all

</LimitExcept>

Sicurezza web server Apache: disabilitare la traccia di una richiesta HTTP

Di default il metodo “Trace” è attivo sul web server Apache. Mantenerlo attivato significa favorire attacchi Cross Site Trancing e potenzialmente significa anche dare una possibilità agli hacker di rubare informazioni sensibili dai cookie. Vediamo quindi come appare nella configurazione di default:

• Fare un IP telnet web server con una porta di ascolto
• Fare una richiesta Trace come mostrato di seguito

#telnet localhost 80

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

TRACE / HTTP/1.1 Host: test

HTTP/1.1 200 OK

Date: Sat, 31 Aug 2013 02:13:24 GMT

Server: Apache

Transfer-Encoding: chunked

Content-Type: message/http 20

TRACE / HTTP/1.1

Host: test 0

Connection closed by foreign host.

#

Come si vede, la richiesta Trace ha risposto alla query; vediamo come disabilitarlo e testarlo.

Implementazione:

• Andare su $Web_Server/conf directory
• Aggiungere la seguente direttiva e salvare httpd.conf

TraceEnable off

• Riavviare Apache

Verifica:

• Fare un IP telnet web server con una porta di ascolto e fare una richiesta Trace come di seguito

#telnet localhost 80

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

TRACE / HTTP/1.1 Host: test

HTTP/1.1 405 Method Not Allowed

Date: Sat, 31 Aug 2013 02:18:27 GMT

Server: Apache Allow:

Content-Length: 223

Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1>

<p>The requested method TRACE is not allowed for the URL /.</p> </body></html>

Connection closed by foreign host.

#

Come si vede la richiesta Trace ha bloccato la richiesta con HTTP 405 Method Not Allowed. Ora questo web server con consente la richiesta Trace e aiuta a bloccare gli attacchi Cross Site Tracing.

Impostare i cookie con HttpOnly and Secure Flag per la sicurezza web server Apache

E’ possibile limitare buona parte degli attacchi Cross site Scripting usando HttpOnly and Secure Flag nei cookie. Senza HttpOnly and Secure è possibile rubare o manipolare le sessioni delle applicazioni web e i cookie, possibilità abbastanza pericolosa.

Implementazione:

•   Garantire mod_headers.so ATTIVO httpd.conf
• Andare su $ server_web directory / conf
• Aggiungere la seguente direttiva e salvare il httpd.conf

 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

• Riavviare Apache

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; si vedrà che Set-Cookie è contrassegnato con HttpOnly and Secure come mostrato di seguito:

 Sicurezza del web server Apache: proteggersi dagli attacchi Clickjacking

Clickjacking è una vulnerabilità molto conosciuta delle applicazioni web. Un attacco di questo tipo porta l’utente che clicca su un oggetto, ad essere redirezionato verso un’altra destinazione.

Implementazione:

• Garantire mod_headers.so ATTIVO httpd.conf
• Andare su  $ server_web directory / conf
• Aggiungere la seguente direttiva e salvare il httpd.conf

Header always append X-Frame-Options SAMEORIGIN

• Riavviare Apache

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; si vedrà X-Frame-Options come di seguito

Server Side Include per la sicurezza web server Apache

Server Side Include (SSI) comporta il rischio di aumentare il carico sul server. Se l’ambiente è condiviso e si ha un traffico pesante delle applicazioni web, si potrebbe considerare di disabilitare SSI aggiungendo la direttiva Includes in Options. Gli attacchi SSI permettono di sfruttare le applicazioni web iniettando uno script nelle pagine HTML o eseguendo un codice da remoto.

Implementazione:

• Andare su $ server_web directory / conf
• Aprire httpd.conf using vi
• Ricercare la directory e aggiungere la direttiva Includes in Options

<Directory /opt/apache/htdocs>

Options –Indexes -Includes

Order allow,deny

Allow from all

</Directory>

• Riavviare Apache

Si noti che se vi sono più directory è necessario ripetere il processo per ognuna di queste.

Protezione X-XSS per la sicurezza web server Apache

La protezione Cross Site Scripting (XSS) può essere bypassata in molti browser. E’ possibile applicare questa protezione per le applicazioni web se l’user è stato disabilitato. Questo sistema è utilizzato da grande compagnie come Facebook, Twitter, Google etc.

Implementazione:

• Andare su  $ server_web directory / conf
• Aprire httpd.conf using vi e aggiungere la seguente direttiva Header

Header set X-XSS-Protection “1; mode=block”

• Riavviare Apache

Verifica:

• Aprite Firefox e accedere all’applicazione
• Controllare le intestazioni di risposta HTTP in Firebug, si dovrebbe vedere che XSS Protection è abilitato e una modalità è bloccata.

Disabilitare il Protocollo HTTP 1.0

Quando si parla di sicurezza è indispensabile proteggere tutto quello che si può. Quindi perché utilizzare la vecchia versione del protocollo HTTP? E’ possibile disattivarla usando il modulo the mod_rewrite.

Implementazione:

• Assicurarsi di caricare il modulo mod_rewrite nel file httpd.conf
• Abilitare la direttiva RewriteEngine come segue e aggiungere la condizione Rewrite per consentire solo HTTP 1.1

RewriteEngine On

RewriteCond %{THE_REQUEST} !HTTP/1.1$

RewriteRule .* – [F]

Per la sicurezza web server Apache configurare il valore Timeout

Di default il valore di Timeout di Apache è di 300 secondi, il che può rendere il server vittima di attacchi Slow Loris o DoS. Per prevenirli è possibile ridurre il valore del Timeout a circa 60 secondi.

Implementazione:

• Andare su  $ server_web directory / conf
• Aprire httpd.conf using vi
• Aggiungere il  Timeout 60 in httpd.conf

Dotarsi di SSL per la sicurezza web server Apache

Attivare la tecnologia SSL significa avere un ulteriore livello di protezione che si può aggiungere alle applicazioni web. Tuttavia la configurazione di default di SSL comporta alcune vulnerabilità ed è quindi opportuno modificare queste configurazioni. Usiamo allora alcuni tool per verificare le impostazioni SSL. Ve ne sono molti disponibili, tuttavia è possibile usare uno strumento gratuito come SSL-Scan.

Sicurezza web server Apache e SSL Key

Violare una chiave SSL è difficile ma non impossibile. E’ infatti solo una questione di tempo e di tentativi. Ad esempio, usando un PC del 2009 e tentando per circa 73 giorni è possibile decodificare addirittura una chiave 512 bit. La maggior parte delle grandi aziende web utilizza ormai un chiave a 2048 bit. Facciamolo anche noi.

Implementazione:

• E’ possibile usare openssl per generare CSR con 2048 bit come di seguito
• Generare un certificato auto-firmato

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt

• Generare una nuova CSR e chiave privata

openssl req -out localhost.csr -new -newkey rsa:2048 -nodes -keyout localhost.key

• Aggiungere Personal Cert, Signer Cert e il file Key nel file httpd-ssl.conf come di seguito:

SSLCertificateFile # Personal Certificate

SSLCertificateKeyFile # Key File

SSLCACertificateFile # Signer Cert file

Verifica:

Eseguire sslscan utility con il seguente parametro. Modificare localhost all’attuale nome dominio.

sslscan localhost | grep –i key

• Come si vede l’attuale chiave SSL è 2048 bit, che è decisamente più forte

SSL Cipher per la sicurezza web server Apache

La crittografia è il processo che consente di convertire i testi in codici segreti cifrati. SSL Cipher è un ottimo algoritmo di crittografia che si basa su due chiavi di sicurezza. Vediamo come implementarlo.

Modificare localhost all’attuale nome dominio.

sslscan –no-failed localhost

In una installazione classica vengono accettati i protocolli DHE, AES, EDH, ed RC4, quest’ultimo un sistema di cifratura abbastanza debole, che non dovrebbe essere utilizzato. In generale non bisognerebbe accettare alcun sistema di cifratura inferiore ai 128 bit.

Implementazione:

• Andare alla cartella $ server_web / conf / extra
• Modificare la direttiva SSLCipherSuite in httpd-ssl.conf come di seguito per respingere RC4

 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

• Salvare il file di configurazione e riavviare il server Apache

Si noti che se vi sono molti cipher deboli nel report di SSL allora è possibile respingerlo aggiungendo ! all’inizio.

Per esempio per respingere RC4: !RC4

Verifica: Utilizzare di nuovo l’utility sslscan per validare come di seguito e cambiare localhost al nome dominio attuale.

sslscan –no-failed localhost

RC4 non è più accettato come Cipher. E’ buona pratica rigettare tutti i cipher bassi, medi o nulli per proteggersi da attacchi. E’ anche possibile verificare il proprio dominio con Qualys SSL Labs  per controllare se vi sono dei cipher vulnerabili nel sistema.

Per la sicurezza web server Apache disabilitare SSL v2 e v3

SSL v2 e v3 hanno molte falle di sicurezza e se si esegue un test di penetrazione si vedrà come sia necessario disabilitarli per rafforzare la sicurezza. Tutte le comunicazioni SSL v2/v3 possono essere vulnerabili a attacchi Man-in-The-Middle che potrebbero compromettere o divulgare i dati.

Vediamo come implementare il web server Apache in modo che accetti solo le ultime TLS e rifiuti la richiesta di connessione SSL v2/v3.

Implementazione

• Andare alla cartella $ server_web / conf / extra
• Modificare la direttiva SSLProtocol in httpd-ssl.conf come di seguito per accettare solo TLS 1.0+

 SSLProtocol –ALL +TLSv1 +TLSv1.1 +TLSv1.2

Verifica:

Usiamo l’utility sslscanper validare il seguente comando e modificare localhost all’attuale nome dominio.

sslscan –no-failed localhost

In alternativa, è possibile controllare il sito con il tool online SSL/TLS Certificate

Utilizzare Mod Security per la sicurezza web server Apache

Mod Security è un’applicazione Firewall opensource che può essere utilizzata con Apache. Si tratta di un modulo che è necessario compilare e installare. Nel caso in cui non sia possibile permettersi un’applicazione firewall commerciale, questo modulo può essere una buona scelta.

Mod Security dice: per garantire una protezione generica delle applicazioni web, il Core rules deve utilizzare le seguenti tecniche:

• HTTP Protection: rilevare le violazioni del protocollo HTTP e  definire un utilizzo della policy localmente
• Real-time Blacklist Lookups: utilizzare 3rd Party IP Reputation
• Web-based Malware Detection: identificare i contenuti web dannosi controllando Google Safe Browsing API
• HTTP Denial of service Protections: difendersi dagli attacchi HTTP Flooding and Slow HTTP DoS
• Common Web Attacks Protection: – rilevare i comuni attacchi alla sicurezza delle applicazioni web
• Automation Detection: Rilevare  bot, crawler, scanner e altre attività dannose
• Integrare con AV Scanning per il caricamento di file: rilevare i file maligni caricati tramite l’applicazione web.
• Monitoraggio dei dati sensibili: Tracciare l’uso delle carte di credito e bloccare le perdite
• Trojan Protection: Rilevare l’accesso ai cavalli di Troia
• Identificare i difetti delle applicazioni: Segnalazioni di errori di configurazione delle applicazioni
• Error Detection and Hiding: Mascherare i messaggi di errore inviati dal server.

Verificare i download e le installazioni per la sicurezza web server Apache

I seguenti prerequisiti devono essere installati sul server nel caso in cui si desideri utilizzare Mod Security con Apache. Se alcuni di essi non sono presenti la compilazione di Mod Security è destinata a fallire. E’ possibile utilizzare l’installazione yum o Linux o Cento per installare questi pacchetti:

• apache 2.xo superiore
• pacchetto libpcre
• pacchetto libxml2
• pacchetto liblua
• pacchetto libcurl
• libapr e pacchetto libapr-util
• Modulo mod_unique_id bundle con server web Apache

Ora, cerchiamo di scaricare l’ultima versione di Mod Security 2.7.5 da http://www.modsecurity.org/download/

• Trasferire il  file scaricato in / opt / apache

• estrarre modsecurity-apache_2.7.5.tar.gz

# gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

• Andare a extracted folder modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

• Avviare lo script di configurazione includendo apxs path a Apacheù

# ./configure –with-apxs=/opt/apache/bin/apxs

• Compilare e installare con make script

# make

#make install

• Una volta che l’installazione è completa si vedrà mod_security2.so nella cartella moduli sotto /opt/apache come di seguito

A questo punto Mod Security è installato sul web server Apache

Configurazione del Mod Security per la sicurezza web server Apache

Per utilizzare Mod Security su Apache, è necessario caricare Mod Security in http.conf. Il modulo mod_unique_id è pre-requisito per Mod Security. Questo modulo fornisce un’ambiente variabile con un identificatore unico per ogni richiesta che viene monitorata e utilizzata da Mod Security.

• Aggiungere di seguito una riga per caricare il modulo per lMod Security in httpd.conf e salvare il file di configurazione

LoadModule unique_id_module moduli / mod_unique_id.so

LoadModule security2_module moduli / mod_security2.so

• Riavviare Apache

A questo punto Mod Security è installato. La cosa successiva da fare è installare Mod Security core rule per le versioni avanzate delle sue funzioni. L’ultimo Core Rule può essere scaricato gratuitamente dal link https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

• Copiare il Core Rule scaricato nella cartella /opt/apache/conf
• Decomprimere il file Core Rule; a questo punto è possibile vedere le cartelle estratte come di seguito

• Si possono rinominare le cartelle con identificativi più brevi e semplici da ricordare, come :

• Andare alla cartella ars e rinominare modsecurity_crs10_setup.conf.example to modsecurity_crs10_setup.conf

A questo punto abilitiamo le regole per attivarle sul web server Apache

• Aggiungere la seguente stringa in httpd.conf

<IfModule security2_module>

Include conf/crs/modsecurity_crs_10_setup.conf

Include conf/crs/base_rules/*.conf

</IfModule>

Nella configurazione precedente abbiamo caricato Mod Security con la configurazione del file principale modsecurity_crs_10_setup.conf e fissato le regole base_rules/*.conf fornite da Mod Security Core Rules per proteggere le applicazioni web

• Riavviare Apache

Mod Security è stato configurato con successo su Apache. Ora il web server Apache è protetto da Firewall Mod Security web application.

Una volta installato Mod Security, passiamo a esaminare le più importanti configurazione per la protezione e la sicurezza delle applicazioni web. In questa sessione tutte le modifiche di configurazione saranno effettuate in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Si farà riferimento a /opt/apache/conf/crs/modsecurity_crs_10_setup.conf setup.conf in questa sezione a scopo di esempio. E’ importante capire quali sono le regole OWASP gratuite. Ci sono tre tipi di regole fornite da OWASP.

Base Rules: queste regole sono state accuratamente testate e il rapporto di falsi allarme è basso.

Experimental Rules: queste regole sono per scopi sperimentali ed è possibile avere dei falsi allarmi. E’ importante configurare, testare e implementare in UAT prima di utilizzarle in un ambiente di produzione

Optional Rules: queste regole opzionali non sono adatte all’intero ambiente, ma possono essere utilizzate sulla base di requisiti specifici. Se si è alla ricerca di CSRF, del monitoraggio degli utenti, Session hijacking etc. per proteggerli allora è possibile utilizzare queste regole.

Le base, experimental e optional rules sono disponibili dopo aver estratto il file zip ars scaricato dalla pagina OWASP. Questi file di configurazione delle regole sono disponibili nella cartella ars / base_rules, crs / optional_rules e crs / experimental_rules.

Prediamo familiarità con alcune base rules.

• modsecurity_crs_20_protocol_violations.conf: questa regola protegge dalle vulnerabilità del protocollo come splitting, request smuggling, using non-allowed protocol (HTTP 1.0)
• modsecurity_crs_21_protocol_anomalies.conf: questa regola protegge da una richiesta mancante con Host, Accept, User-Agent nell’intestazione
• modsecurity_crs_23_request_limits.conf: questa regola dipende da applicazioni specifiche come request size, upload size, lunghezza parametro
• modsecurity_crs_30_http_policy.conf: questa regola è per configurare e proteggere i metodi permessi e non permessi come CONNECT, TRACE, PUT, DELETE, etc.
• modsecurity_crs_35_bad_robots.conf: Rintraccia i malicious robots
• modsecurity_crs_40_generic_attacks.conf: questa regola serve per proteggere da comandi OS injection, inclusione di file remoti etc
• modsecurity_crs_41_sql_injection_attacks.conf: questa regola è per proteggere SQL e per nascondere la richiesta SQL inject
• modsecurity_crs_41_xss_attacks.conf: Protezione contro la richiesta da Cross Site Scripting
• modsecurity_crs_42_tight_security.conf: Analisi e protezione trasversale Directory
• modsecurity_crs_45_trojans.conf: questa regola rileva i generici file di gestione output, il caricamento di pagine http backdoor, le firme conosciute
• modsecurity_crs_47_common_exceptions.conf: questa regola è usata come un meccanismo di eccezione per rimuovere i falsi positivi che si possono riscontrare come Apache internal dummy connection, SSL pinger etc.

Logging per la sicurezza web server Apache

La registrazione è una delle prime cose da configurare per creare dei logs per ciò che Mod Security sta facendo. Ci sono due tipi di registrazione disponibili: Debug & Audit log.

Debug Log: questo serve per duplicare i messaggi di errore di Apache, gli avvisi e le notifiche da error log

Audit Log: questo serve per scrivere i logs delle transazioni che sono contrassegnati da Mod

Security. Mod Security dà la possibilità di configurare Audit, Debug o entrambi. Vediamo la configurazione di default in setup.conf

SecDefaultAction “fphase:1,deny,log”

Per Debug e Audit log usare “log”. Per solo Audit log usare “nolog,auditlog”. Per solo Debug log usare “log,noauditlog”. E’ possibile specificare la posizione di Audit Log da archiviare e che deve essere controllato dalla direttiva SecAuditLog.

Scriviamo Audit log in /opt/apache/logs/modsec_audit.log aggiungendo come illustrato di seguito.

Implementazione:

• Aggiungere direttiva SecAuditLog in setup.conf e riavviare il server Web Apache

 SecAuditLog /opt/apache/logs/modsec_audit.log

• Dopo il riavvio è possibile vedere modsec_audit.log generato come di seguito

Abilitare Rule Engine per la sicurezza web server Apache

Di default Engine Rule è disabilitato il che significa che non si stanno utilizzando tutti i vantaggi di Mod Security. Rule Engine abilitato o disabilitato è controllato dalla direttiva SecRuleEngine.

Implementazione

• Aggiungere direttiva SecRuleEngine in setup.conf e riavviare il server Web Apache

SecRuleEngine On

Ci sono tre valori per SecRuleEngine:

• On: per abilitare Rule Engine
• Off: per disabilitare Rule Engine
• DetectionOnly: per abilitare Rule Engine senza eseguire nessuna azione come block, deny,drop, allow, proxy o redirect

Solo se Rule Engine è on Mod Security è pronto per proteggere dai più comuni attacchi.

Proteggersi dagli attacchi comuni per la sicurezza web server Apache

Ora il web server è pronto per difendersi dai più comuni attacchi come XSS, SQL Injection, Protocol Violation etc. visto che è stato installato Core rule su Rule Engine. Testiamolo:

Attacchi XSS:

• Aprire Firefox e accedere all’applicazione e inserire il tag <script>  alla fine o URL come mostrato di seguito
• Monitorare modsec_audit.log nella cartella apache/logs

Come si può vedere Mod Security blocca la richiesta che contiene il tag <script> che è la radice degli attacchi XSS.

Attacchi Directory Traversal: Questo tipo di attacchi può creare molti danni approfittando di vulnerabilità e riuscendo ad avere accesso al sistema correlato.Ex – /etc/passwd, .htaccess, etc.

• Aprire Firefox e accedere all’applicazione con directory traversal
• Monitorare modsec_audit.log nella cartella apache/logs

http://localhost/?../…/boot

Come si vede Mod Security blocca le richieste che contengono directory traversal

Cambiare Server Banner per la sicurezza web server Apache

In precedenza in questa guida, si è visto come rimuovere la versione Apache e il tipo di sistema operativo con la direttiva ServerTokens. Facciamo un passo in avanti e vediamo come mantenere il nome del server che si desidera. Questo è possibile con la direttiva SecServerSignature in Mod Security.

Si noti che per utilizzare Mod Security per manipolare Server Banner è necessario impostare ServerTokesn in httpd.conf del web server Apache.

Implementazione:

• Aggiungere la direttiva SecServerSignature con il nome del server desiderato in setup.conf e riavviare il server Web Apache

SecServerSignature YourServerName

es:

[/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf

SecServerSignature chandank.com

[/opt/apache/conf/crs] #

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; è possibile vedere che Server Banner si è modificato come di seguito:

Configurazione generale per mettere in sicurezza web server Apache

Ecco alcune best practice per la configurazione generale

Configure Listen e sicurezza web server Apache

Quando si dispone di un’interfaccia e IP multipli su un singolo server, è consigliato avere una direttiva Listen configurata con IP assoluto e numero di porta. Quando nella configurazione di Apache si lascia Listen a tutti gli IP con un certo numero di porta, si possono avere problemi nella trasmissione della richiesta HTTP ad altri server. Questa situazione è abbastanza comune negli ambienti condivisi.

Implementazione:

• Configurare la direttiva Listen in httpd.conf con IP assoluto e la porta come mostrato nell’esempio qui sotto:

Listen 10.10.10.1:80

Access Logging e sicurezza web server Apache

E’ essenziale configurare Access Logging correttamente sul web server. Alcuni dei parametri più importanti da impostare in log è il tempo necessario per soddisfare la richiesta, Session ID. Di default, apache non è configurato per catturare questi dati. E’ necessario configurarli manualmente come di seguito.

Implementazione:

• Per fissare il tempo necessario per soddisfare la richiesta e Session ID nei log di accesso
• Aggiungere% T &% sessionID in httpd.conf secondo la direttiva LogFormat

  LogFormat “% h% l% u% t “% {} sessionID C” “% r” %> s% b% T” common

È possibile fare riferimento http://httpd.apache.org/docs/2.2/mod/mod_log_config.html per un elenco completo dei parametri supportati dalla direttiva LogFormat nei web server Apache.

Per la sicurezza web server Apache disabilitare i moduli indesiderati

Se sono stati compilati e installati tutti i moduli in Apache allora vi è la possibilità che ve ne siano molti non necessari. Una buona pratica è di configurare Apache con i moduli necessari nelle proprie applicazioni web.

I moduli seguenti hanno mostrato alcuni problemi di sicurezza e si potrebbe pensare di disabilitarli in httpd.conf del web server Apache.

WebDAV (Web-based Distributed Authoring and Versioning), questo modulo consente ai clients remoti di manipolare i file sul server ed è quindi soggetto a vari tentativi di arranco denial-of-service. Per disabilitarlo aggiungere il seguente commento in https.conf

#LoadModule dav_module modules/mod_dav.so

#LoadModule dav_fs_module modules/mod_dav_fs.so

#Include conf/extra/httpd-dav.conf

Info Module: Il modulo mod_info può divulgare informazioni sensibili utilizzando .htaccess una volta che il modulo è stato caricato. Per disabilitarlo:

#LoadModule info_module modules/mod_info.so

Mentre guardavano la televisione, i dati personali e i programmi visti venivano registrati senza consenso, raccolti e rivenduti. Gli Smart TV Vizio, hanno adottato per anni questa pratica commerciale scorretta, e negli Stati Uniti, sono stati costretti a rivedere le loro politiche di trasparenza e a pagare una multa considerevole.

Secondo una denuncia presentata dalla Federal Trade Commission e dal procuratore generale del New Jersey, Vizio ha inserito una funzionalità di tracciamento dietro un’impostazione chiamata “Smart Interactivity”. La FTC e il procuratore del New Jersey sostengono che l’azienda ha descritto questa caratteristica in modo generico,  per esempio “permette il suggerimento e l’offerta di programmi”. Ciò non ha fornito ai consumatori le informazioni necessarie a sapere che le loro smart tv Vizio li stavano spiando in ogni momento.

Smart Tv Vizio: così i dati dei clienti venivano spiati

Secondo per secondo, Vizio raccoglieva così una selezione di pixel sullo schermo che abbinava poi a un database di TV, film e contenuti commerciali. Inoltre, Vizio riconosceva i dati di visualizzazione dai servizi via cavo o a banda larga, set-top box, dispositivi di streaming, lettori DVD e broadcasts over-the-air. In aggiunta ogni fino a cento miliardi di data points venivano catturati da milioni di smart tv Vizio.

Vizio poi trasformava quella montagna di dati in denaro vendendo la cronologia delle visualizzazioni dei consumatori ad altre compagnie. Cerchiamo di essere chiari: non stiamo parlando di informazioni di riepilogo su tendenze di visualizzazione nazionali. Secondo la denuncia, Vizio raccoglieva informazioni personali. La società forniva gli indirizzi IP dei consumatori ad aggregatori di dati, che poi abbinavano l’indirizzo IP con un singolo consumatore o con una famiglia.

I contratti di Vizio con terze parti vietavano l’identificazione dei consumatori e delle famiglie in base al nome. Tuttavia fornivano una serie di altri dati personali: per esempio, il sesso, l’età, il reddito, lo stato civile, la dimensione della famiglia, l’educazione, e la proprietà della casa. Ciò permetteva a queste compagnie di monitorare e indirizzare i consumatori attraverso le smart tv Vizio.

Così i consumatori non sapevano che, mentre stavano guardando i loro smart tv, Vizio li spiava.

Servizio ingannevole: milioni di dollari di multa

La denuncia sostiene che Vizio sia ricorso a pratiche commerciali sleali che hanno violato il diritto della Federal Trade Commision ed erano inconcepibili ai sensi della legge del New Jersey. La denuncia sostiene inoltre che Vizio non è riuscito a rivelare in modo adeguato la natura della sua funzione “Smart Interactivity” e ha tratto in inganno i consumatori con il suo nome generico e la descrizione fuorviante.

Per risolvere il caso, Vizio ha accettato di fermare il monitoraggio non autorizzato, di rivelare chiaramente le sue pratiche di raccolta di dati e di ottenere il consenso esplicito dei consumatori prima di raccogliere e condividere le informazioni di visualizzazione. Inoltre, l’azienda deve eliminare la maggior parte dei dati che ha raccolto e creare un programma di privacy che valuti le pratiche di Vizio e dei suoi partner. Il provvedimento include anche un pagamento di 1,5 milioni di dollari alla FTC ed una sanzione civile supplementare di 2,2 milioni di dollari al New Jersey.
Qui ci sono i consigli che le smart companie dovrebbero attuare dopo l’ultima azione legale riguardo i prodotti intelligenti, i quali sono stati discussi anche recente al seminario sulle Smart TV organizzato dalla FTC.

• Spiegare le proprie pratiche di raccolta dati in anticipo. Dire ai consumatori fin dall’inizio le informazioni che si intendono raccogliere. Bisogna lasciare perdere i discorsi tecnici e utilizzare un linguaggio facile da capire. Soprattutto quando si spiegano nuove tecnologie o raccolte di dati che le persone potrebbero non aspettarsi, la trasparenza può essere la chiave per la fidelizzazione dei clienti.
• Ottenere il consenso dei consumatori prima di raccogliere e condividere le informazioni altamente specifiche sulle loro preferenze di intrattenimento. Se i consumatori non si aspettano che si stiano raccogliendo informazioni su di loro, specialmente informazioni sensibili, assicurarsi che acconsentano a ciò che si intende fare. Il modo migliore per realizzare ciò è quello di ottenere il loro consenso, cioè che esprimano la decisione di partecipare alla raccolta dati.
• Rendere più facile per i consumatori esercitare le opzioni. Una funzione chiamata “Smart Interactivity” che “permette suggerimenti ed offerte di programmi” metterebbe al corrente i consumatori che tutto quello che guardano viene raccolto e condiviso con terze parti? Noi non la pensiamo così. Le aziende possono difficilmente pretendere di offrire ai consumatori una scelta se gli strumenti necessari per esercitare tale scelta sono difficili da trovare o nascosti dietro descrizioni plain-vanilla.
• Applicare alle nuove tecnologie i principi di tutela dei consumatori. I documenti guida della FTC come “Careful Connections: Building Security in the Internet of Things”, “.com Disclosures: How to Make Effective Disclosures in Digital Advertising”, e “Start with Security” potrebbero non avere “Smart TV” nel titolo, ma le aziende intelligenti dovrebbero rivolgersi a loro per consigli su come evitare pratiche ingannevoli o sleali.

Fino a tempi relativamente recenti, L’Autorità che certifica i siti in Https non avrebbe rilasciato un certificato SSL per un sito che cerca di far finta di essere apple.com o microsoft.com. Tuttavia, c’è una nuova CA (Certification Authority) chiamato LetsEncrypt che rilascia certificati gratuiti a siti web che desiderano utilizzare SSL.

LetsEncrypt ha un obiettivo nobile. Sta cercando di rendere libero il web di utilizzare SSL per cifrare le connessioni sui siti senza dover pagare neanche un euro. Tuttavia per motivi organizzativi non controllano  se il proprietario del sito web sta fingendo di essere qualcun altro. Così l’effetto di questo tipo di gestione è che stiamo assistendo a molti siti di phishing che hanno un certificato https valido emesso da LetsEncrypt e che appaiono come ‘sicuri’ nel browser Chrome.

Ecco un esempio di un sito Web che utilizza un certificato https di LetsEncrypt e che appare come ‘sicuro’ in Chrome.

Come si può vedere, Chrome dice che il sito è ‘sicuro’. Il proprietario del sito sta cercando di far finta di essere il negozio di Google Play. I phisher sperano di confondere il testo dopo ‘.com’ con quello che di solito appare dopo la barra sul reale negozio di Google Play. Questo è un esempio di un sito di phishing che cercherà di carpire le credenziali del tuo account  Google Play.

Per visualizzare le informazioni sul certificato di questo sito, è necessario aprire gli strumenti per sviluppatori di Chrome e visualizzare la scheda di sicurezza. È possibile farlo andando al Visualizza> sviluppatore> menu Strumenti per sviluppatori.

Ma è ovvio che pochissime persone, soprattutto coloro che non sono tecnici, lo faranno. E saranno ingannate, involontariamente, da LetsEncrypt e da Chrome.

Basta controllare e nel caso revocare il certificato, direte voi, e invece no, non basta.

Anche se il certificato non è valido rimane attivo e moltissime persone non se ne rendono conto. Ancora una volta la differenza tra avere una buona idea, quella di LetsEncrypt e metterla in pratica sta nell’esperienza.

Cosa si deve fare per essere sicuri sul web?

Il modo migliore per proteggersi contro siti dannosi, in questo caso, è quello di controllare il vostro browser direttamente nella barra degli indirizzi e leggere il Nome dominio

completo che vi appare.

Guardate la barra degli indirizzi di cui sopra. Si dovrebbe vedere ‘https://www.alground.?com/….’. Quando si visita un sito web con cui si prevede di scambiare dati sensibili bisogna verificare il completo hostname dopo ‘https: //’ . Se non si riconosce o se sembra che ha un po ‘di cose strane sulla fine,del nome dominio, chiudere immediatamente la finestra e riflettere attentamente su come sei finito su quel sito. Evitare di cliccare qualunque link ti ha portato a tale sito web.

Che cosa può LetsEncrypt fare per migliorare la sicurezza?

Il team di LetsEncrypt deve iniziare a fare ricerche per parole chiave sulle applicazioni dei certificati SSL. Questo può essere completamente automatizzato e LetsEncrypt ha bisogno di respingere i certificati che contengono stringhe come “.apple.com.”, “.paypal.com.”, “.google.com.” E altri modelli comuni di phishing.

Dovrebbero implementare un processo di revisione in cui, se la tua richiesta di certificato viene rifiutata, è possibile applicare un token che consente di bypassare il check-in futuro una volta che avete tentato di fare qualcosa di dubbio.

Insomma diventare una Ca vera e non un distributore automatico di certificati ssl senza il minimo controllo. Un comportamento come questo fa più danni che rimanere in http. Abbassa il livello di attenzione dell’utente che crede di essere al sicuro. Mentre invece è nella bocca del lupo.

Numerosi attacchi hacking di alto profilo hanno dimostrato che la sicurezza  web rimane una questione critica per tutte le aziende che operano online. I web server sono quindi un “nodo cruciale” in virtù dei dati sensibili che ospitano. La sicurezza del web server e del database è quindi importante esattamente come la sicurezza del sito web, delle applicazioni e di tutto il network.

Se si ha un’applicazione web sicura e un web server insicuro, o viceversa, allora l’intera sicurezza aziendale è messa a rischio.

Sebbene la sicurezza del web server possa essere un’operazione un pò scoraggiante, per la quale sono richieste conoscenze specialistiche, non è un compito impossibile.

E’ comunque sempre meglio dedicare qualche notte insonne e un pò di ricerche per mettere in sicurezza il web server e il database, piuttosto che trascorrere lunghe giornate in ufficio per cercare di “riparare” a futuri furti di dati.

A prescindere da quale web server e sistema operativo si sta utilizzando, un “out” del box di configurazione viene generalmente considerato insicuro, per questo è fondamentale adottare alcune misure di protezione, ritenute indispensabili per aumentare la sicurezza del web server.

Di seguito, quindi, una serie di consigli da seguire quando si procede a mettere in sicurezza il web server e il database.

Sicurezza del web server e del database: rimuovere i servizi non necessari

Alcune installazioni e configurazioni di default dei sistemi operativi non sono sicure.

In una procedura tipica di installazione di default, infatti, ci sono molti servizi, come i servizi di registro remoto, il servizio server di stampa o RAS, che, invece, non dovrebbero essere installati durante la configurazione del Web Server.

Quanti più servizi sono esecuzione tanto maggiori saranno le porte “lasciate aperte” agli utenti malintenzionati. E’ quindi consigliato spegnere e disabilitare tutti i servizi non necessari in modo che, al prossimo avvio del server, queste non saranno eseguite automaticamente.

Inoltre, disabilitare i servizi non necessari contribuisce anche a migliorare le performance del server, liberando alcune risorse hardware.

Attenzione all’accesso remoto per la sicurezza del Web Server e del database

Sebbene si tratti di una pratica oggi considerata poco funzionale, quando possibile è sempre bene che gli amministratori del server si connettano a questo localmente.

Nel caso in cui fosse necessario un accesso da remoto, è bene fare in modo che la connessione da remoto sia sicura usando i protocolli di “tunneling” e di cittografia.

L’accesso da remoto può inoltre essere ristretto a uno specifico numero di IP e solo a determinati accounts.

E’ anche di estrema importanza evitare di utilizzare computer condivisi o reti pubbliche per accedere ai server aziendali da remoto, come ad esempio le connessioni degli internet caffè o le reti wireless pubbliche.

Sviluppare, eseguire test e produrre in ambienti separati

Dal momento che è molto più semplice per uno sviluppatore implementare una nuova versione di una applicazione web su un server di produzione, è altrettanto comune che la fase di sviluppo e di test delle applicazioni web avvenga direttamente sui servers di produzione.

Si tratta di una pratica molto diffusa sul Web per trovare nuove versioni di uno specifico sito o alcuni contenuti che non sono disponibili al pubblico in directories come /test/new/ o sotto-directories simili.

Visto che queste applicazioni web sono nella prima fase di sviluppo, sono soggette a una serie di vulnerabilità, mancano di validazione e non sono in grado di gestire le eccezioni in maniera appropriata.

Queste applicazioni web possono essere facilmente scoperte e sfruttate dai malintenzionati semplicemente utilizzando i tools gratuiti disponibili su Internet.

Per facilitare la fase di sviluppo e di test delle applicazioni web, gli sviluppatori implementano specifiche applicazioni interne che danno loro un accesso privilegiato all’applicazione web, al database e alle altre risorse del web server, accesso non disponibile per un normale utente anonimo.

Sfortunatamente, se la fase di sviluppo e di test viene fatta direttamente sul server di produzione, queste applicazioni possono essere facilmente scoperte da un malintenzionato e utilizzate per avere accesso e per compromettere il server di produzione.

Ne consegue che idealmente la fase di sviluppo e di test delle applicazioni web dovrebbe sempre essere fatta su server isolati dalla rete e mai connessi al database e ai dati “reali”.

Metti file e script delle applicazioni su porzioni separate

I file e gli script delle applicazioni web o del sito dovrebbero essere sempre su una porzione separata o su un’unità diversa rispetto a quella del sistema operativo, dei logs e di ogni altro file di sistema.

Grazie all’esperienza, oggi sappiamo che un hacker che è riuscito ad accedere alla web root directory, è in grado di sfruttare le vulnerabilità e incrementare i propri privilegi per avere accesso ai dati presenti su tutto il disco, inclusi il sistema operativo e gli altri files di sistema.

Se questo si verifica, l’hacker ha la possibilità di avere accesso a ogni comando del sistema operativo, riuscendo quindi a controllare completamente il web server.

Sicurezza del Web Server e del database: attenzione ai permessi e ai privilegi

Le autorizzazioni per i file e i servizi network giocano un ruolo fondamentale per la sicurezza del Web Server e del database.

Se un web server viene compromesso tramite un software di servizio di rete, gli hacker possono utilizzare l’account sul quale il servizio di rete è in esecuzione per compiere determinate azioni, come ad esempio eseguire determinati file.

Per questo motivo è molto importante assegnare solo i privilegi minimi richiesti per l’esecuzione di uno specifico servizio di rete, come il software del web server.

Allo stesso modo è fondamentale assegnare i privilegi minimi agli utenti anonimi, impostando solo quelli necessari per accedere al sito, ai file delle applicazioni web e al baci-end dei dati e del database.

Installare in tempo le patch di protezione

Avere un software completo non significa necessariamente che il web server sia completamente al sicuro.

E’, infatti, prioritario aggiornare il sistema operativo e tutti i software in esecuzione sul server con le ultime patch di sicurezza disponibili.

Molti episodi di hacking, infatti, sfruttano proprio le vulnerabilità dei server e dei software non aggiornati con i più recenti patch.

Controllare e monitorare costantemente il server per garantire la sicurezza del Web Server e del database

Tutti i logs presenti in un server dovrebbero idealmente essere conservati in un’area separata.

I logs dei servizi network, degli accessi al sito, del database (ad esempio Microsoft SQL Server, MySQL, Oracle) e i logs del sistema operativo dovrebbero essere costantemente monitorati e controllati, verificando la presenza di voci di registro “strane”.

I file log restituiscono tutte le informazioni relativamente a un tentativo di attacco, anche nel caso di un attacco riuscito, ma spesso queste informazioni vengono ignorate.

Così, se si nota un’attività insolita nei registri di logs, è bene verificare cosa sta accedendo per accertare la presenza o meno di un problema.

Per garantire la sicurezza del Web Server e del database mai utilizzare gli account predefiniti

Tutti gli account utente predefiniti creati durante l’installazione del sistema operativo dovrebbero essere disabilitati.

C’è, inoltre, una lunga lista di software che una volta installati creano degli account utenti sul sistema operativo. Questi accounts devono essere controllati, così come devono essere modificati i relativi permessi.

L’account amministratore deve essere rinominato e non utilizzato, lo stesso si dica per il root user su Linux e Unix.

Tutti gli accessi da amministratore sul web server devono avere un proprio account, con i corretti privilegi necessari.

E’, inoltre, una buona pratica di sicurezza non condividere con altri gli account utenti.

Sicurezza del Web Server e del database: rimuovere moduli e estensioni delle applicazioni non utilizzate

L’installazione di default di Apache comporta l’abilitazione di un certo numero di moduli predefiniti, che, in linea di massima, non sono necessari al web server.

E’ quindi consigliato spegnere questi moduli al fine di prevenire attacchi contro di essi.

Lo stesso si dica per i web server Microsoft: Internet Information Services.

Di default, IIS è configurato per servire un ampio numero di applicazioni tipo come ASP, ASP.NET e altre.

La lista delle estensioni delle applicazioni dovrebbe contenere solo quelle applicazioni web e quelle estensioni per il sito che saranno realmente utilizzate. Tutte le estensioni dovranno inoltre essere limitate per utilizzare HTTP specifici dove possibile.

Tenersi costantemente aggiornati

Oggi giorno è possibile trovare in Rete gratuitamente moltissime informazioni e suggerimenti su software e sistemi operativi. Tenersi informati e conoscere le nuove tipologie di attacco è molto importante, per questo è consigliato leggere molta “letteratura” di settore e stare sempre al passo con le ultime novità.

Usare Scanner per la sicurezza del Web Server e del database

Scanner sono dei tools molto utili che permettono di automatizzare e di semplificare il processo di messa in sicurezza del web server e delle applicazioni web.

Acunetix Web Vulnerability Scanner è inoltre dotato di “port scanner” che quando abilitato sottopone a scansione le applicazioni web e l’hosting del web server.

Simile a uno scanner di sicurezza di rete, Acunetix WVS avvia una serie di controlli avanzati di sicurezza indirizzati alle porte aperte e ai servizi di rete in esecuzione sul web server.

Acunetix Web Vulnerability Scanner protegge il sito e il web server controllando SQL Injection, Cross site scripting, problemi di configurazione del server e altri tipi di vulnerabilità.

Verifica inoltre la sicurezza delle password sulle pagine di autenticazione e la protezione dei dati di acquisto, controlla i form, i contenuti dinamici Web 2.0 e ogni altro tipo di applicazione web.

Quando la scansione è completa, il software restituisce un report dettagliato che individua con precisione eventuali vulnerabilità.

Mettere in sicurezza un server Linux significa prestare attenzione a una serie di importanti fattori che, se trascurati, potrebbero mettere a rischio il server e tutte le informazioni in esso contenute.

La sicurezza, quindi, è un requisito fondamentale da adottare per salvaguardarsi da attacchi malware e sottrazioni di dati. Vediamo, dunque, quali sono i migliori accorgimenti da adottare per mettere in sicurezza un server Linux.

Mettere in sicurezza un server Linux: installa solo i pacchetti necessari per

Chi dispone di un server pensa innanzitutto alla possibilità di poter installare ogni pacchetto e applicazione, vista la disponibilità di storage che il server stesso mette a disposizione.

Questo è certamente vero, ma non si deve mai dimenticare che anche i server più potenti possono essere hackerati sfruttando le vulnerabilità dei pacchetti e delle applicazioni che girano sul server.

La prima regola per mettere in sicurezza un server Linux è quindi quella di installare solo i pacchetti di cui si ha realmente bisogno, ricordandosi sempre di leggere con attenzione la relativa documentazione prima di installare un qualsiasi software o pacchetto dipendente (ad esempio ownCloud).

Applicazioni sotto controllo per mettere in sicurezza un server Linux

La seconda regola per mettere in sicurezza un server Linux è di monitorarne i servizi, consentendo l’esecuzione solo di quei programmi di cui si necessita.

Può infatti verificarsi che alcuni pacchetti avviino alcuni servizi su porte differenti, mettendo quindi a rischio la sicurezza.

Per verificare quali servizi sono in esecuzione su quali porte, è necessario aprire:

netstat -npl

e controllare se vi sono alcuni servizi “in funzionamento” che invece si pensava “inattivi”.

In questo caso, fermare tali servizi, ricordandosi anche di verificare i servizi che vengono eseguiti all’avvio del sistema.

Per la verifica è necessario eseguire, per i sistemi che eseguono systemd, il comando:

systemctl list-unit-files –type=service | grep enabled

A seconda del sistema che si sta utilizzando, viene restituita una schermata che mostra tutti i servizi in esecuzione; nel caso ve ne siano alcuni di cui non si ha bisogno è possibile disabilitarli usando il comando:

systemctl disable service_name

Mettere in sicurezza un server Linux restringendo l’accesso

Così come non si consegnano le chiavi della propria casa a chiunque, allo stesso modo non si deve dare a tutti l’accesso al proprio server Linux.

La terza regola è dunque quella di restringere l’accesso al server, tenendo però sempre a mente che anche questa precauzione non mette il server al sicuro da eventuali tentativi di accesso indesiderati.

Evitare di loggarsi come super-utente per mettere in sicurezza un server Linux

Non viene considerata come una buona pratica quella di loggarsi al server come super-utente via secure-shell (SSH).

E’ possibile disabilitare il protocollo SSH come root user sul server, ma prima di farlo è fondamentale creare un utente con “sudo powers” così da poter utilizzare la comunicazione SSH ed eseguire attività amministrative.

Una volta loggati al server è sempre possibile passare all’user root se necessario.

Nel caso in cui si possegga già un user sul proprio server, ignorare questi passaggi, mentre nel caso contrario procedere nel seguente modo.

Per aggiungere un nuovo utente si utilizzano diversi metodi; Red Hat/CentOS (usano useradd), Ubuntu/Debian (usano user adduser).

Per creare un nuovo utente su Fedora/CentOS:

useradd swapnil

poi creare una password per l’utente

passwd swapnil

Verrà chiesto di fornire una nuova password. Concluso questo step, procedere assegnando all’utente i poteri “sudo” con il comando:

EDITOR=nano visudo

Viene restituita una schermata nella quale vi è la seguente stringa:

# %wheel ALL=(ALL) ALL

A questo punto, è necessario “togliere il commento” alla linea semplicemente cancellando il simbolo # , che indica appunto che la stringa è commentata.

Il risultato sarà:

%wheel ALL=(ALL) ALL

Basta ora salvare e chiudere il file. Se l’utente non appartiene al gruppo “wheel” è possibile aggiungerlo facilmente eseguendo il comando:

# usermod -aG wheel swapnil

Sui sistemi Ubuntu è possibile aggiungere un nuovo utente eseguendo:

adduser swapnil

Il sistema ci chiede di rispondere a una serie di domande e di creare una nuova password per l’utente. Una volta completato questo step, passare ad assegnare i “sudo powers” all’utente, con il comando:

gpasswd -a swapnil sudo

Aprire una nuova finestra, provare a loggarsi al server utilizzando il nuovo account creato e a eseguire una serie di operazioni da amministratore; se tutto funziona al meglio è possibile passare al prossimo step.

Per mettere in sicurezza un server Linux ricordarsi di disabilitare Login Root

Disabilitare il login root significa impedire a chiunque di collegarsi al server come root user o di utilizzare SSH.

Per procedere aprire il file di configurazione sshd:

nano /etc/ssh/sshd_conf

Cercare la stringa commentata:

#PermitRootLogin no

salvare e chiudere il file e poi riavviare il service:

service ssh restart oppure systemctl restart sshd

E’ molto importante non scollegarsi ancora dal server, ma verificare prima se è possibile loggarsi via SSH usando l’user precedentemente creato.

Se tutto funziona al meglio, è possibile scollegarsi dal server come root user.

Mettere in sicurezza un server Linux cambiando le porte di default

Un secondo e importante cambiamento da apportare al file ssh riguarda le porte di default, aggiungendo in questo modo un ulteriore livello di protezione e di sicurezza al server.

Per farlo è necessario aprire il file di configurazione sshd (come “sudo user” in quanto non è più possibile accedere al server come root user):

sudo nano /etc/ssh/sshd_conf

e rintracciare la linea commentata:

#Port 22

Rimuovere il commento della linea e scegliere il numero di una porta, facendo attenzione a non selezionarne una in uso a un altro servizio del sistema.

E’ possibile avere delle indicazioni su quali porte sono generalmente in uso da questo articolo di Wikipedia così da poterle evitare.

Supponiamo di scegliere la porta 1977 del server:

Port 1977

Salvare e chiudere il file e poi procedere a riavviare il servizio sshd.

Ancora una volta, prima di disconnettersi dal server, verificare le impostazioni aprendo una nuova finestra e loggarsi usando questo pattern:

ssh -p{port_number}@server_IP

Se riuscite ad accedere allora avrete correttamente modificato le porte di default.

Mettere in sicurezza un server Linux disabilitando l’autenticazione tramite password

Una altra regola importante per mettere in sicurezza un server Linux è quella di disabilitare la password di login, ricordandosi però sempre che sarà possibile accedere al server solo dalla macchina sulla quale viene generata la chiave ssh.

Per generare la chiave ssh sul sistema locale, utilizzare il comando

ssh-keygen – t rsa

Comparirà una schermata con una serie di domanda; è possibile lasciare la chiave di default e dotarla di una password forte, difficile da indovinare. Successivamente è necessario copiare queste chiavi sul server in modo tale che le due macchine possano comunicare tra loro utilizzando queste chiavi:

cat ~/.ssh/id_rsa.pub | ssh -p 1977 swapnil@remote-server “;mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”

A questo punto bisogna testare sshing sul server da un altro terminale e se tutto funziona correttamente, non sarà richiesta l’immissione della password.

Per incrementare ulteriormente i livelli di sicurezza, si può disabilitare l’autenticazione tramite password per il server.

Per fare ciò è necessario aprire il file di configurazione ssh e cercare la seguente linea commentata:

#PasswordAuthentication yes

Rimuovere il commento e modificare “yes” in “no”, salvare e chiudere il file.

A questo punto riavviare il servizio sshd e, ancora una volta, ricordarsi di non chiudere la connessione al server dalla finestra in uso. Aprire quindi una nuova finestra e loggarsi al server, accertandosi che non venga richiesta una password.

Il rovescio della medaglia di questo tipo di impostazione è che sarà possibile collegarsi al server solo dalla macchina sulla quale sono state create le chiavi ssh. Questo significa che, se ci si collega al server da macchine differenti, è bene non utilizzare questo metodo.

Mettere in sicurezza un server Linux: conclusioni

In conclusione, è bene fare alcune considerazioni che potranno essere utili soprattutto ai nuovi utenti di server Linux.

La prima cosa da tenere a mente è che i crackers sono sempre un passo avanti e capaci di sfruttare qualunque “debolezza” per accedere al server.

Uno dei migliori accorgimenti per mettere in sicurezza un server Linux è quindi quello di mantenere un backup sempre aggiornato del server.

A tal proposito, è consigliato fare un backup sia prima che dopo qualunque cambiamento al sito così, nel caso in cui il server venga compromesso, è sempre possibile ripristinare il tutto dall’ultimo backup effettuato.

Scegliere l’antivirus per l’azienda è una di quelle scelte che hanno un enorme effetto positivo nel lungo periodo e che consentono di risparmiare una enormità di tempo e di denaro.

Una volta chi gestiva un’impresa di piccole dimensioni si considerava sostanzialmente al riparo, reputando che gli attacchi di malintenzionati fossero indirizzati ad aziende di maggiori dimensioni, targhettizzate e più redditizie per i cyber-criminali.

Negli ultimi anni la strategia dei cracker si è evoluta e le tecniche di infezione sono decisamente progredite andando a interessare ogni tipologia di impresa, a prescindere dalle dimensioni.

E anzi, proprio le PMI, che tendono a non avere un responsabile esclusivo alla sicurezza, ma che accorpano in una unica persona più ruoli e che potendo, cercano di risparmiare il più possibile.

Scegliere l’antivirus per l’azienda. Capire cosa si vuole

Prima di procedere all’acquisto, è bene porsi una serie di domande che certamente risulteranno molto utili per scegliere antivirus per l’azienda più indicato.

Innanzitutto è bene capire se si necessita di un semplice antivirus per poche postazioni o di una suite di protezione completa e domandarsi, poi, se il software selezionato è effettivamente compatibile con le caratteristiche del network aziendale.

In merito a questo aspetto, quindi, si deve cercare di capire se le policy di sicurezza della propria azienda dovranno essere modificate (perché nella vostra azienda esistono già vero?) o aggiornate per garantire il corretto funzionamento del software.

Insomma, la base è avere già in mente un elenco preciso di qualità che il prodotto dovrà avere, e una serie di esigenze che per la vostra azienda sono considerate come basilari.

Nessuno è al sicuro quindi e sapere come proteggersi e soprattutto farlo efficacemente è una priorità.

Per scegliere il miglior antivirus… parti dal firewall

La scelta del giusto antivirus per la propria azienda non può prescindere dal valutare una serie di parametri fondamentali, che riescono a dare una buona misura dalla correttezza della scelta e della convenienza dell’acquisto.

Prima di individuare i principali criteri di giudizio per scegliere il migliore antivirus per la propria azienda, è bene fare una considerazione.

Non dovete fare affidamento solo sull’antivirus, ma considerarlo come parte di una suite più ampia.

Tutti i sistemi operativi infatti sono dotati di firewall (Windows Security Essential per i computer pre-Windows 8, Windows Defender per Windows 8, il sistema operativo OS X Lion per Apple) che devono sempre essere attivi in quanto riescono già a garantire una serie di funzioni di sicurezza importanti. Mai sottovalutare, dunque, questo aspetto e mai dimenticarsi di attivare il firewall.

Per scegliere l’antivirus aziendale scegli fra i più testati, ma non solo

Uno dei primi passi da compiere per scegliere un antivirus adatto alla propria azienda è sicuramente quello di valutare con la dovuta attenzione e con un giusto approccio critico le caratteristiche dei prodotti anti-malware disponibili.

Lo scopo è, chiaramente, quello di determinare i punti di forza dei singoli software al fine di compararli e di riuscire a determinare qual’è il più efficace in termini di protezione e di convenienza.

Non tutte le imprese, infatti, hanno le medesime necessità per questo riuscire a confrontare le proprie esigenze di sicurezza con gli strumenti forniti dall’antivirus è cruciale per individuare il prodotto migliore.

Molte aziende attive nella realizzazione di antivirus hanno notevolmente ampliato la propria offerta e sviluppato dei pacchetti di protezione completi che includono anche gli endpoint, generalmente più vulnerabili.

Le opzioni, dunque, sono numerose e un aiuto alle aziende alla ricerca di un buon antivirus può certamente venire da tutte quelle organizzazioni, come Virus Bulletin, Av-Comparatives, AV-Test, che si occupano appunto di valutare la reale efficacia degli antivirus.

Tenersi costantemente aggiornati sulle novità anti-virus è altrettanto fondamentale e in quest’ottica preferire i prodotti che riescono a “stare al passo” con le ultime innovazioni segnalate dai migliori team di ricerca anti-virus, può certamente essere d’aiuto.

Tuttavia, relativamente a questo aspetto, è sempre bene ricordarsi che le “indicazioni” date e le valutazioni effettuate dalle community di ricerca AV sono solitamente condotte su campioni resi disponibili dalle case di produzione ed eseguite relativamente a singoli aspetti come la capacità di individuare un malware o di bloccarlo, mentre poco si conosce dell’intero processo.

Scegliere l’antivirus per l’azienda: completezza, scansioni e aggiornamenti

Nella scelta del miglior antivirus, l’azienda deve innanzitutto valutare la completezza del prodotto cercando quindi di capire se i livelli di protezione garantiti sono realmente efficaci e capaci di contrastare le crescenti minacce malware.

Questo significa che una protezione antivirus di base non può essere considerata sufficiente e che, quindi, è fondamentale verificare che l’antivirus selezionato sia in grado di effettuare, ad esempio, scansioni approfondite e automatiche delle email e dei relativi allegati.

Un antivirus, inoltre, per funzionare efficacemente deve essere costantemente aggiornato e riuscire a “riconoscere” anche i virus più recenti.

L’aggiornamento del database delle firme dell’antivirus è quindi fondamentale per consentire al prodotto di lavorare sempre al meglio.

Non vanno, poi, sottovalutati altri due fattori di estrema importanza, vale a dire l’impatto dell’antivirus sulle prestazioni dei PC e l’assistenza fornita dalla casa di produzione.

Relativamente al primo aspetto bisogna accertarsi che l’attivazione dell’antivirus sui computer aziendali ne consenta il normale funzionamento; l’antivirus deve poter funzionare al meglio senza andare, però, ad intralciare le attività quotidiane dell’impresa.

Il supporto tecnico e l’assistenza assicurata è altrettanto fondamentale in quanto alcuni software antivirus possono essere complicati e presentare dei problemi di installazione e di gestione. Un’azienda “in difficoltà” con il proprio antivirus deve sapere a chi rivolgersi e deve poterlo fare in qualunque momento utilizzando canali differenti.

Completezza dell’antivirus non significa solo valutarne le funzionalità ma anche poterlo utilizzare su tutti i computer aziendali.

Per questo, in fase di selezione e di acquisto di un antivirus, è fondamentale anche optare per i prodotti a licenza multi-utente che consentono, in sostanza, di installare l’antivirus su tutte le macchine.

Come scegliere l’antivirus per l’azienda? Osserva tempi e falsi positivi

Comparazione dei prodotti, analisi delle proprie esigenze, frequenza di aggiornamento e assistenza garantita sono fondamentali per riuscire a scegliere un software antivirus. A questi parametri di valutazione è possibile aggiungerne degli altri che attengono più strettamente alle specifiche funzionalità del prodotto.

Gli antivirus hanno molteplici opzioni e alcune di queste risultano fondamentali per accertarsi della sua reale efficacia.

Tra le caratteristiche da considerare attentamente vi è, innanzitutto, la capacità dell’antivirus di individuare e bloccare un malware; questo significa comprendere la reale efficacia dell’analisi anti-malware del software e la sua effettiva abilità nell’attivare tutte le misure necessarie per ripulire il sistema dall’infezione.

Altrettanto cruciale è valutare il tempo generalmente impiegato dall’antivirus nell’individuare un malware prima che questo si diffonda agli endpoint e questo per garantire una adeguata protezione di tutti i PC aziendali, solitamente più a rischio di contagio.

Anche il numero dei falsi positivi è un parametro importante poiché dà la misura della reale affidabilità e della qualità del prodotto installato.

Un ulteriore consiglio per scegliere il miglior antivirus per la propria azienda è certamente quello di optare per prodotti e soluzioni di lungo termine, capaci di combinare tecniche diverse e di assicurare un elevato livello di protezione anche nel lungo periodo.

Come scegliere il miglior antivirus per l’azienda: la fase di test

Mai essere soddisfatti di quello che si legge e di quello che si pensa. La prova sul campo ha un valore insostituibile. Per questo dovete sfruttare appieno la fase di prova che ogni soluzione fornisce.

Questa fase di test è utile non solo per verificare la “compatibilità” dell’antivirus con la rete ma anche per capire se il prodotto può essere installato sui computer aziendali senza comprometterne la performance.

E’ bene poi verificare se il software antivirus prescelto sia “flessibile”, vale a dire se il prodotto consente di “spegnere” alcune delle opzioni disponibili, che potrebbero essere di intralcio alle attività aziendali, senza che questo vada a compromettere la sicurezza e la protezione dei PC.