Gestite un server e pensate di non essere attaccabili? Ecco le cose da sapere

Siamo abbondantemente nella seconda decade degli anni 2000 eppure la diffusa e fallace credenza secondo la quale gli aggressori si concentrerebbero sempre su siti Web specifici è ancora imperante. In realtà, non soltanto gli attaccanti si rivolgono verso un’ampia schiera di siti Web ma si concentrano su server collegati alla rete Internet che forniscono ogni genere di servizio. L’erogazione di pagine Web attraverso l’uso dei protocolli HTTP/HTTPS è infatti soltanto la punta dell’iceberg: i servizi che una macchina server può esporre sull’IP pubblico possono essere davvero tanti (anche non aventi a che fare con il Web).

La maggior parte degli attacchi partono da bot, ovvero da sistemi automatizzati a loro volta connessi con la rete Internet, che non sanno nulla dei sistemi oggetto di scansione, delle attività da questi espletate, dei siti Web che i server eventualmente ospitano. I bot, insomma, non tengono nella benché minima considerazione i bersagli delle loro attività: se una macchina, di qualunque tipo, è raggiungibile tramite IP pubblico è sempre un potenziale bersaglio.

I bot attaccano quotidianamente qualunque server: è un dato di fatto

Secondo gli esperti di Imperva, la metà di tutti i visitatori dei siti Web sono bot. Di questi, circa il 29% sono lì per aggredire il sito. Anzi, i server poco utilizzati, quelli che ospitano domini con poche visite giornaliere, sono spesso bersagli prediletti: la mancanza di misure di sicurezza o l’adozione di accortezze protettive insufficienti, può avere come conseguenza l’inclusione della macchina aggredita in una botnet.

Honeynet, organizzazione senza scopo di lucro che si occupa di sicurezza informatica, ha creato tempo fa una sorta di “trappola” per tracciare gli attacchi di sicurezza su un server Web connesso alla rete. La macchina usava un’istanza creata su Amazon AWS e non legava a sé nemmeno un nome di dominio: analizzando il traffico con il noto e apprezzato packet sniffer Wireshark per 24 ore e utilizzando poi p0f (Passive OS fingerprinting), software per l’identificazione di impronte digitali nel traffico TCP/IP, è stato possibile accertare che il server – praticamente sconosciuto – ha complessivamente subìto qualcosa come 250.000 tentativi di attacco.

A metà agosto 2023, due ricercatori francesi hanno pubblicato i risultati di un lavoro durato tre anni e incentrato sull’utilizzo e sull’implementazione del protocollo RDP che, com’è noto, consente di stabilire sessioni di desktop remoto. Creando anche in questo caso un honeypot, hanno potuto registrare e studiare in modo approfondito l’azione dei bot e degli attaccanti in carne ed ossa, una volta scoperto l’obiettivo vulnerabile.

In altre parole, indipendentemente dal sito Web o dal servizio che state amministrando (e che risulta pubblicamente accessibile sulla rete Internet) qualcuno, ogni giorno, busserà alla vostra porta. Di solito si tratta di bot: se l’utilizzo di particolari script o modalità di attacco “basiche” porta al risultato sperato (dagli aggressori), l’indirizzo IP del sistema vulnerabile viene annotato quindi passato a utenti malintenzionati che proveranno a violarlo per vari scopi.

Perché gli aggressori attaccano un server

Gli aggressori possono attaccare un server Web per una serie di motivi, che dipendono dai loro obiettivi e motivazioni. Si va dalla raccolta di informazioni personali e dati riservati al furto di identità, dai tentativi di estorsione alla volontà di causare danni d’immagine, dall’utilizzo del server aggredito per la distribuzione di malware all’installazione di ransomware (con la richiesta di un riscatto in denaro).

Alcuni attacchi hanno lo scopo di utilizzare le risorse del server, come la potenza di calcolo o la larghezza di banda, per compiere azioni illegali come l’avvio di attacchi DDoS (Distributed Denial of Service), l’invio di campagne spam, il mining di criptovalute a insaputa dei legittimi proprietari delle macchine.

Le azioni dei malintenzionati, tuttavia, non sono dirette soltanto verso i server Web. Anche nel caso di altri server, che non eseguono server Web, gli aggressori possono cercare di rastrellare informazioni riservate, finanziarie, dettagli personali e segreti aziendali. Per non parlare dell’abuso delle risorse di calcolo, di fenomeni di estorsione, della distribuzione di componenti dannosi, dell’aggiunta dei sistemi alle botnet e così via.

Tra i tanti, c’è anche un motore di ricerca pubblicamente accessibile, chiamato Shodan, che contiene una lista sempre aggiornata di indirizzi IP sui quali si affacciano specifici servizi: alcuni di essi soffrono palesemente di specifiche vulnerabilità. Il meccanismo di ricerca che Shodan integra, consente addirittura, usando appositi filtri, di selezionare le macchine che – a livello mondiale o in uno specifico Paese – espongono una o più porte raggiungibili da qualunque dispositivo remoto.

Utilizzare il firewall per evitare di esporre servizi non necessari sull’IP pubblico

La regola d’oro per non correre rischi consiste nell’esporre sull’IP pubblico solo ed esclusivamente i servizi strettamente necessari. Nulla di più. Se, ad esempio, una macchina deve fungere da server Web, vanno tipicamente esposte solo le porte 80 (HTTP) e 443 (HTTPS): tutto il resto deve essere assolutamente bloccato a livello di firewall.

Certo, quella stessa macchina andrà amministrata a distanza, ma non è sensato mostrare le porte sulle quali è in ascolto il modulo server che attende le richieste di connessione e amministrazione remota. Ad esempio RDP (Remote Desktop Protocol) utilizza le porte TCP/UDP 3389 ed è uno dei bersagli preferiti dagli aggressori remoti. Sia perché gli attacchi brute-force tesi a indovinare le credenziali di accesso sono in crescita, sia perché gli amministratori di sistema spesso non installano gli aggiornamenti di sicurezza che interessano direttamente i server di Desktop remoto.

Protezione degli accessi via SSH, degli RDBMS e delle altre applicazioni server

Stessa cosa dicasi per gli accessi via SSH (Secure Shell), la cui porta predefinita è TCP 22, estremamente comuni sulle piattaforme GNU/Linux. È essenziale evitare di esporre pubblicamente l’amministrazione remota SSH, anche se correttamente protetta con username e password sull’interfaccia pubblica.

Considerazioni simili valgono, ad esempio, per i server dei principali RDBMS o comunque dei moduli server utilizzati per la gestione dei dati. Le porte sulle quali si pongono in ascolto i server di MySQL/MariaDB, PostgreSQL, MongoDB e così via non possono e non devono affacciarsi sull’indirizzo IP pubblico. E ciò anche se si fosse disattivato l’utilizzo dell’account root al di fuori degli indirizzi IP locali e se si fossero assegnati con cura i permessi (grant) ai singoli account.

Non parliamo neppure delle risorse condivise via SMB/NFS: queste non dovrebbero mai e poi mai affacciarsi sull’IP pubblico.

La lista dei servizi che dovrebbero essere mantenuti irraggiungibili sull’IP pubblico è quasi infinita.

Configurazione del firewall

Il firewall dovrebbe essere configurato in maniera tale da consentire l’accesso senza limitazioni soltanto a specifici indirizzi IP statici utilizzati dagli amministratori di sistema che si collegano da remoto. In alternativa, si dovrebbe impostare un server VPN per l’accesso all’infrastruttura remota da amministrare, avendo cura di aggiornare con regolarità il server VPN stesso al fine di correggere tempestivamente eventuali vulnerabilità di sicurezza.

In caso di difficoltà, bisognerebbe sempre poter disporre di una console Web (generalmente fornita, ad esempio, dai provider cloud) che permetta di agire sulle macchine, anche nel caso in cui l’accesso via VPN non dovesse risultare funzionante.

Si dovrebbe optare per un firewall hardware; è comunque possibile integrare in un’infrastruttura cloud prodotti software come pfSense, OPNsense, Endian, IPFire o similari.

Vulnerabilità di sicurezza nei componenti server e nelle applicazioni

La “bestia nera” di qualunque amministratore di sistema è la presenza di vulnerabilità nelle applicazioni che integrano funzionalità server, soprattutto quelle che sono esposte sull’IP pubblico.

Citiamo il caso più banale (ma anche molto comune) del classico server Web: se venisse scoperta una grave lacuna di sicurezza, sfruttabile da remoto, in componenti come Apache HTTP Server (httpd), Nginx, IIS (Internet Information Services) e altri ancora, si dovrebbe studiare subito il problema e attivarsi quanto prima. Soprattutto se una richiesta “malformata”, opportunamente predisposta dall’aggressore, dovesse consentire il superamento di restrizioni, l’acquisizione di informazioni riservate o, addirittura, l’esecuzione di codice in modalità remota.

Di solito è possibile risolvere la problematica installando le patch di sicurezza ufficiali o applicando, almeno temporaneamente, workaround correttivi.

Quali sono gli attacchi informatici che possono interessare le applicazioni Web

Anche se il server Web fosse configurato in modo sicuro, è essenziale preoccuparsi anche della sicurezza delle applicazioni che sono esposte in rete. Eventuali vulnerabilità nelle applicazioni Web possono esporre ai seguenti esempi di attacco:

• SQL Injection (SQLi). Consiste nell’iniettare comandi SQL dannosi attraverso un input accettato dall’applicazione. È un esempio di cattiva programmazione: gli attaccanti possono manipolare le query SQL per ottenere dati non autorizzati e compromettere la sicurezza del database utilizzato come base per il funzionamento dell’applicazione.
• Cross-Site Scripting (XSS). Consente agli attaccanti di eseguire script lato client all’interno del browser degli utenti. Gli attaccanti possono sfruttare questa vulnerabilità per rubare informazioni sensibili o eseguire azioni dannose a nome dell’utente.
• Command Injection. Si verifica quando dei dati inviati in ingresso non sono opportunamente validati e arrivano ad essere eseguiti come comandi lato server.
• Cross-Site Request Forgery (CSRF). Questa categoria di vulnerabilità consente agli attaccanti di indurre gli utenti a eseguire azioni pericolose su un sito in cui l’utente si è autenticato. Gli attaccanti possono sfruttare la fiducia dell’utente per eseguire operazioni dannose.
• Broken Authentication and Session Management. Questo insieme ricomprende tutte quelle vulnerabilità che consentono agli attaccanti di bypassare meccanismi di autenticazione e di autorizzazione, con la possibilità di catturare e manipolare le sessioni utente.

Altre vulnerabilità degne di nota, talvolta presenti nelle applicazioni

• Configurazioni di sicurezza scorrette o superficiali. Configurazioni erronee o non sicure possono esporre informazioni sensibili, fornire accesso non autorizzato o consentire a un attaccante di eseguire azioni dannose.
• Insecure Direct Object References (IDOR). In questo caso un’applicazione Web espone riferimenti a oggetti interni, come file o database, senza controllarne l’accesso. Gli attaccanti possono manipolare tali riferimenti per ottenere informazioni non autorizzate.
• Server-Side Request Forgery (SSRF). Consente agli attaccanti di indurre il server a effettuare richieste a risorse interne, aprendo potenzialmente la possibilità di esplorare i sistemi connessi alla medesima rete locale.
• Vulnerabilità nei meccanismi di upload: Se un’applicazione consente il caricamento di file e non esegue controlli efficaci, gli aggressori possono caricare file dannosi arrivando addirittura a disporne l’esecuzione lato server oppure usarli per la distribuzione di malware.
• XML External Entity (XXE) Injection. Gli attaccanti possono sfruttare vulnerabilità contenuti nei meccanismi che gestiscono contenuti in formato XML. L’obiettivo è acquisire l’accesso a risorse locali o eseguire attività malevole.

Date un’occhiata ai file di log dei vostri server: scoprirete cose davvero interessanti

I file di log dei vostri server sono una preziosissima fonte di informazioni per capire cosa succede, giorno dopo giorno, su ciascuna macchina.

Nish Tahir, nel suo post “I looked through attacks in my access logs. Here’s what I found“, racconta tutta una serie di evidenze emerse a valle dell’analisi dei registri del Web server.

Tra i tentativi di attacco sferrati con maggior frequenza, vi sono svariati tentativi di accesso alle directory (Directory Traversal), alla ricerca di file contenenti credenziali, in particolare oggetti .env che, com’è noto, spesso contengono informazioni tecniche essenziali e riservate (comprese eventuali chiavi di accesso).

Gli aggressori, inoltre, si concentrano spesso sulla ricerca di file legati ad Amazon Web Services (AWS) e repository Git; vanno altresì cercando l’involontaria esposizione di directory comuni (si pensi a cose come /old o /temp).

Rimangono attuali anche gli storici attacchi Shellshock che sfruttano vulnerabilità irrisolte nei server Web che supportano l’esecuzione di script CGI con una versione vulnerabile della Bash. Gli attaccanti cercano di eseguire comandi arbitrari sul server, come evidenziano richieste come la seguente:

echo Content-Type: text/html; echo ; /bin/cat /etc/passwd

Molteplici tentativi di aggressione riguardano specifici dispositivi per il networking e versioni del firmware note per essere “fallate”.

Qualche osservazione conclusiva

In generale, è bene non limitarsi alle modalità di autenticazione Web delle varie applicazioni: il suggerimento è attivare una protezione aggiuntiva, basata sulla gestione dei permessi a livello di file system, assicurata da ciascun sistema operativo e da ogni server. Non fidatevi insomma nell’esporre l’accesso al backend di un CMS (content management system) o la pagina di login di phpMyAdmin da una sottocartella accessibile pubblicamente.

Interessante è il Web Application Firewall (WAF) che Cloudflare offre gratis per tutti gli utenti: si tratta di uno strumento che si frappone tra i client remoti e i server Web offrendo protezione contro un ampio ventaglio di aggressioni. Si pensi ad esempio agli attacchi di tipo SQL injection e cross-site scripting citati in precedenza, all’utilizzo di configurazioni scorrette, alle decine di attacchi classificati da OWASP, alla difesa delle installazioni di CMS comuni come WordPress, Joomla, Drupal, Magento e così via.

La morale è che se avete qualunque tipo di presenza su Internet, è indispensabile proteggere con attenzione tutti i server che utilizzate, applicando le regole di sicurezza di base. Chi gestisce un server, di qualunque tipo, esposto su Internet deve sapere che sarà costantemente attaccato. L’esposizione delle porte strettamente necessarie, un’oculata gestione dei permessi e l’applicazione regolare delle patch di sicurezza, consentono di difendere “il fortino” in maniera più che adeguata.

Credit immagine in apertura: iStock.com – Olemedia