Configurare in Sicurezza un Web Server

Sicurezza web Server

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

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

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

Il Firewall, la prima arma a nostra disposizione.

Firewall

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

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

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

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

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

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

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

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

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

WAF - Web Aoolication Firewall

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

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

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

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

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

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

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

Fail2Ban e gli Attacchi DDoS

Fail2Ban - DDos attacchi

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

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

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

Il Backup dei dati

Backup Web server

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

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

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

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

Aggiornamenti OS Costanti

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

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

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

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

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

Corsi ed affini

[CORSO – CS01LWSA218]

Linux Web Server Administrator

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

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

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

IscrivitiDettaglio
 

Aggiornamento sulla Sicurezza WordPress. Botnet all’attacco di siti WordPress.

Il Defiant Threat Intelligence Team ha recentemente iniziato a tracciare un comportamento anomalo di una campagna di attacchi Brute Force organizzata contro siti WordPress. Questa campagna ha creato una botnet di siti Web WordPress infetti per eseguire ulteriori attacchi verso altri siti WordPress, nel tentativo di bucare l’autenticazione XML-RPC distruggendo la sicurezza wordpress, per accedere agli account con privilegi.

Negli ultimi trenta giorni, sono stati rilevati da alcuni WAF, cinque milioni di tentativi di autenticazione maligni associati a questo tipo di campagna.

Gli autori delle minacce (gli hacker) utilizzano un gruppo di quattro server C2 (command and control) per inviare richieste a oltre 14.000 server proxy forniti da un provider proxy russo chiamato best-proxy.ru. Usano questi proxy per rendere anonimo il traffico C2. Le richieste passano attraverso i server proxy e vengono inviate a oltre 20.000 siti WordPress infetti. Questi siti stanno eseguendo uno script di attacco che attacca altri siti WordPress mirati. Lo schema seguente illustra la catena di sequenza d’attacco.

Sicurezza wordpress

In questo articolo, descriveremo questa catena di attacco in dettaglio in modo che ricercatori, venditori e team per le operazioni di sicurezza possano beneficiarne. In alcuni casi sono stati omessi o cancellati i dati, perché i server C2 e i siti WordPress infetti sono ancora online e potrebbero essere sfruttati da altri. Attualmente sono in corso manovre di esperti, team organizzati che stanno condividendo i dati con le forze dell’ordine relative a questa indagine. Inoltre si stanno fornendo dati agli stessi host interessati per aiutarli a rimediare alle macchine infette nelle loro reti.

Identificazione di script Brute Force

Nella ricerca di questa campagna è stato determinato che gli IP che eseguivano gli attacchi Brute Force erano quasi tutti associati ai popolari provider di hosting web (italiani e non) e che gli attacchi erano tutti rivolti all’interfaccia XML-RPC di WordPress su /xmlrpc.php.

E’ stato anche notato che le stringhe User-Agent associate a queste richieste corrispondevano a quelle utilizzate dalle applicazioni comunemente viste interagendo con l’interfaccia XML-RPC, come wp-iphone e wp-android. Poiché in genere queste applicazioni memorizzano le credenziali localmente, è stato inusuale vedere da parte loro, una quantità così significativa di accessi non riusciti, il che ha attirato l’attenzione dei team di sicurezza. Sono stati identificati oltre 20.000 siti slave WordPress che stavano attaccando altri siti WordPress.

WordPress che attacca WordPress

Con questi dati in mano, hanno continuato ad identificare gli script di attacco Brute Force presenti su siti WordPress infetti, corrispondenti agli attacchi che stavamo singolarmente monitorando. Gli script mirano all’interfaccia XML-RPC dei siti WordPress per testare le coppie nome utente / password, Utilizzando uno spoof a caso delle stringhe User-Agent di ogni richiesta:

foreach ($request as $i => $id) {
 $xmlualist = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
 $xmlual = $xmlualist[array_rand($xmlualist)];

Lo script brute force accetta l’input di comando e controllo (C2) tramite POST per definire alcune impostazioni di esecuzione, come un array JSON di domini mirati e un wordlist locale da utilizzare:

if ($_POST['secret']=='111'){
    $timer = time();
    libxml_use_internal_errors(true);
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);
        }

Generazione dinamica di Wordlist

Le Wordlist associate a questa campagna contengono piccole serie di password molto comuni. Tuttavia, lo script include funzionalità per generare dinamicamente password appropriate basate su modelli comuni. Alcuni esempi di questi modelli sono:

%DomainPattern%
%nome utente%
%Username%1
%Username%123
%Username%2018
%Username%2017
%Username%2016

In altre parole, se lo script Brute Force tenta di accedere a esempio.com come utente, genererà password come esempio, alice1, alice2018 e così via. Anche se è improbabile che questa tattica abbia successo su un determinato sito, può essere molto efficace se utilizzata su larga scala con un numero elevato di obiettivi.

Funzionalità Multicall

L’interfaccia XML-RPC di WordPress ha visto un aumento degli attacchi Brute Force nel 2015, quando gli attacchi che sfruttano la funzionalità multicall sono diventati popolari. In breve, utilizzando questa interfaccia un utente malintenzionato potrebbe inviare un numero elevato di coppie utente/password in una singola richiesta. WordPress testerebbe ogni coppia e restituirebbe un elenco di successi e fallimenti. Questa tecnica ha reso il processo di attacco brute force molto più facile da avviare su scala, dal momento che un dispositivo attaccante avrebbe solo bisogno di inviare un singolo batch di credenziali e attendere una risposta.

Lo script Brute Force in questa campagna è costruito per eseguire questo tipo di attacco multicall di default. Il frammento di codice seguente mostra la funzione che, quando viene fornito un nome utente e una serie di password, assemblerà un singolo oggetto XML contenente tutte le password da tentare di forzare.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i < count($passwords); $i++){ $xml = addElementXML($xml, $login, $passwords[$i]); } $request = $xml->saveXML();
    return $request;
}

I sistemi C2 che impartiscono istruzioni allo script Brute Force possono facoltativamente definire variabili $startPass e $endPass, che indicano allo script di tentare solo un sottoinsieme di password su un determinato elenco invece di eseguire l’intero set.

Attacchi Multicall non più efficaci (principalmente)

Molti utenti di WordPress non sanno che questo attacco multicall XML non è più efficace. Una patch per wp-include/class-wp-xmlrpc-server.php è stata introdotta in WordPress 4.4. Con questa patch, se un tentativo di accesso in una richiesta XML-RPC non riesce su un sito Web target, quel sito Web fallirà immediatamente tutti i tentativi successivi nella stessa richiesta, anche se le credenziali sono valide.

La patch XML-RPC per WordPress 4.4 è stata rilasciata in modo silenzioso e non è stata divulgata nelle note di rilascio. Inoltre non è stato sottoposto a backport in precedenti sezioni di WordPress come la maggior parte delle correzioni di sicurezza, nonostante fosse una patch relativamente poco invasiva. Per chiarire, anche se un sito è sull’ultima versione di sicurezza di un ramo WordPress dalla versione 4.3 e precedenti, può essere vulnerabile a questo metodo di attacco.

Gli aggressori di questa campagna sembrano essere consapevoli di questo miglioramento. Un certo numero di richieste da sistemi C2 a siti (precedentemente) infetti sono stati intercettati da WAF esterni, tutte queste richieste definiscono lo stesso valore per i parametri $startPass e $endPass sopra descritti. Ciò significa che gli script di attacco finiscono per tentare l’autenticazione con una combinazione utente/password alla volta, deprecando efficacemente la funzionalità multicall dello script stesso.

Infrastruttura di Attacco rivelata

Come accennato in precedenza, siamo stati in grado di catturare le richieste inviate dai sistemi C2 alla rete di siti WordPress infetti e abbiamo avuto successo nell’acquisire una grande quantità di informazioni da questi dati.

Server C2 centrali identificati

La catena di attacco in questa campagna ha fatto uso di più livelli di astrazione tra l’attaccante e i siti di destinazione. Gli attacchi Brute Force vengono eseguiti da una rete di siti WordPress infetti, che ricevono istruzioni tramite una rete di server proxy, quindi in genere sarebbe molto difficile tenere traccia dei server C2 centrali dietro a tutto il resto. Siamo stati fortunatiLa fortuna sta nel fatto che, chi attacca abbia commesso alcuni errori nella loro implementazione degli script Brute Force.

Poiché gli script utilizzano entrambi elenchi di parole memorizzati nello stesso sito WordPress infetto, includono funzionalità per rigenerare queste liste di parole, se necessario:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
    }else{
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
        }else{
            return false;
        }
    }
}

La funzione checkWordsList() passa un valore $path che definisce un indirizzo remoto contenente la wordlist da utilizzare. Se manca la wordlist locale, lo script scaricherà la lista dall’indirizzo indicato. Questo percorso viene fornito insieme al resto dei dati POST inviati dai server proxy allo script brute force. Le richieste intercettate dai WAF includevano questo percorso, che conteneva un indirizzo IP.

Questo IP indicava un server che conteneva una pagina di accesso, che suggeriva di aver trovato qualcosa di grande.

Sono stati poi identificati un totale di quattro server di comando e controllo attivi coinvolti nella campagna di Brute Force.

Accesso all’interfaccia C2

Una breve analisi dei siti C2 ha rivelato che, nonostante la pagina di accesso, l’autenticazione di questi sistemi non è stata effettivamente applicata. Il tentativo di accedere alle pagine dell’interfaccia C2 attiverebbe un re-indirizzamento 302 alla pagina di accesso, ma l’applicazione ha comunque inviato i dati della pagina accanto al re-indirizzamento.

sicurezza wordpress

Richiesta cURL alla home page di un server C2. Notare il re-indirizzamento 302 su /login.php e la risposta HTML che lo segue.

Usando BurpSuite, è stata creata una regola proxy che ignora questo re-indirizzamento dell’accesso, dando la possibilità di esplorare liberamente l’interfaccia dell’applicazione C2. Contenute all’interno dell’interfaccia c’era una serie di funzionalità, inclusa la possibilità di accedere a un elenco di “slave”, che si riferivano ai siti WordPress infetti contenenti script Brute Force.

Una vista disponibile nell’interfaccia C2 che mostra un elenco di log esportati dall’hacker.

Connessione identificata a Best-Proxies.ru

Con l’accesso alle interfacce di questi server C2, sono stati in grado di identificare la relazione tra questi server e i server proxy che inviano comandi ai siti “slave”. Ogni server conteneva un file nel suo webroot denominato proxy.txt. Questo file contiene un elenco di quasi diecimila indirizzi proxy SOCKS, con indirizzi IP e porte. Questi indirizzi IP coincidevano con i server proxy identificati in precedenza, suggerendo che C2 utilizzi questo file per selezionare casualmente un proxy durante l’emissione di ciascun attacco. Sono stati identificati 14.807 server proxy.

È interessante notare che il file proxy.txt su uno dei server C2 non conteneva un elenco di indirizzi proxy, ma conteneva invece un documento HTML. Il documento era una copia di un errore 503 Servizio non disponibile, incluso un collegamento a api.best-proxies.ru. Anche in questo documento c’era il testo russo che si traduce in “Errore di autorizzazione: il periodo di validità di questa chiave è scaduto, è possibile acquistare una nuova chiave”.

Si scopre anche che gli hacker hanno dimenticano di pagare le bollette.

Screenshot del documento di errore memorizzato su un server C2, suggerendo che l’utente malintenzionato non ha rinnovato la chiave API utilizzata per accedere agli elenchi dei proxy.

Date le circostanze, è probabile che il server C2 indirizzi il proprio elenco di proxy SOCKS da api.best-proxies.ru memorizzando direttamente la risposta dell’API in proxy.txt. Quando l’API restituisce un errore, questo errore sovrascrive l’elenco dei proxy.

Collaborazione con le autorità competenti

Una grande quantità di dati preziosi è stata raccolta come parte di questa indagine. A causa della natura del lavoro svolto, sono stati mantenuti i contatti con numerose agenzie di polizia in tutto il mondo. Mentre in generale vengano condivisi dati con la maggior parte dei blog nella rete, come gli indirizzi IP e altri indicatori di compromesso, in questo caso è stato scelto scelto di conservare alcune di queste informazioni al fine di evitare interferenze con possibili indagini future.

Oltre alle forze dell’ordine, sono stati contattati alcuni provider di hosting che identificati con un gran numero di siti “slave” infetti. La speranza è che fornire queste informazioni possa aiutare a limitare l’efficacia di questa campagna riducendo il numero di siti attivi che vengano lanciati ulteriori attacchi.

Cosa dovrebbero fare i proprietari dei siti?

Per evitare che il vostro sito cada vittima di attacchi di Brute Force come questi, è utile implementare restrizioni e blocchi per accessi non riusciti. Esistono sistemi e procedure che offrono una robusta protezione brute force e che bloccano gli IP che lanciano tali attacchi.

Consultate un professionista che sappia indirizzarvi verso le corrette procedure di difesa da adottare in casi come questi.

Se ritenete che il Vostro sito sia infetto e lanci attacchi come descritto di questa campagna, Vi preghiamo di prendere in considerazione l’utilizzo dei nostri servizi di Management su Server Dedicati, VPS e siti. Avendo una certa familiarità con questi casi e possiamo garantire che il Vostro problema possa essere gestito in modo corretto e competente.

Non esitate di contattarci per avere maggiori informazioni, e servizio audit in tempo reale.

In Conclusione

Il Defiant Threat Intelligence Team ha identificato una vasta campagna di attacchi Brute Force contro i siti web di WordPress. Questi attacchi sono stati lanciati da script maligni collocati su altri siti WordPress, che hanno ricevuto istruzioni da una botnet con una sofisticata catena di attacco, utilizzando un provider proxy stanziato in Russia.

Non esitate di contattarci per avere un miglior controllo ed effetto sul vostro sito o applicazione, in modo che non possa rivelarsi dannoso per la vostra attività e il futuro della vostra reputazione in Rete.