Archivi categoria: sicurezza

Fermare i tentativi di hacking di wordpress con fail2ban

di

0


Fail2ban è uno strumento per creare delle regole dinamiche di firewalling al fine di bloccare ripetuti tentativi di hacking o bruteforce.
Ecco un utile post rapido per fermare i tentativi di hacking al tuo server web WordPress come brute force alla wp-login.php e attacchi exploit a xmlrpc.
Installa fail2ban.

sudo apt-get install fail2ban

Dopo aver installato fail2ban, configuralo per rilevare e bloccaree i tuoi host dannosi, aggiungendo queste due regole al tuo file jail su /etc/fail2ban/jail.conf

[worpdress-xmlrpc]
enabled = true
port = http,https
filter = worpdress-xmlrpc
logpath = /var/log/apache/*access.log
maxretry = 3
 
[worpdress-wplogin]
enabled = true
port = http,https
filter = worpdress-wplogin
logpath = /var/log/apache/*access.log
maxretry = 3
bantime = 86400
findtime = 600

Modifica il percorso dove si trovano i file log di Apache o del tuo webserver (anche Nginx). Ora aggiungi due file in /etc/fail2ban/filter.d chiamati worpdress-xmlrpc.conf e worpdress-wplogin.conf con il seguente contenuto:

worpdress-xmlrpc.conf:
	
[Definition]
failregex = ^ .*POST .*xmlrpc\.php.*
ignoreregex =

worpdress-wplogin.conf:

[Definition]
failregex = ^\ \-.*\"POST\ \/wp-login.php HTTP\/1\..*\"
ignoreregex =

Riavvia fail2ban con il comando

systemctl restart fail2ban

Per verificare il corretto funzionamento delle regole si può consultare il log di fail2ban che è /var/log/fail2ban.log

Zerologon: la nuova falla al Netlogon (CVE-2020-1472)

di

0

Ad agosto, Microsoft ha rilasciato un patch per diverse versioni di Windows (gratuite per Windows 10 o Windows 2012 in su) per correggere una vulnerabilità che consentirebbe ad un utente malintenzionato di diventare essenzialmente amministratore di dominio facilmente. L’unica cosa che gli serve è un collegamento diretto ad un domain controller, ossia il server che nelle reti di server Windows svolgere il ruolo di gestire gli accessi centralizzati.

La vulnerabilità è possibile grazie ad un errore in uno schema di autenticazione crittografica utilizzato dal Netlogon Remote Protocol, che tra le altre cose può essere utilizzato per aggiornare le password dei computer.
Questo problema consente agli aggressori di impersonare qualsiasi computer, incluso il domain controller (DC) stesso, ed eseguire chiamate di procedura remota (RPC) per conto di un altro computer.

Già l’anno scorso si era scoperta una vulnerabilità al componente Netlogon meno grave ma ora questa seconda vulnerabilità è molto più grave (punteggio CVSS: 10.0). Creando un token di autenticazione per una specifica funzionalità di Netlogon, è stato in grado di utilizzare una funzione per modificare la password di un computer sul domain controller su un valore noto. Dopodiché, l’aggressore può utilizzare questa nuova password per assumere il controllo del domain controller e rubare le credenziali di un amministratore di dominio.

La patch rilasciata ad agosto predispone l’insieme di server all’arrivo di una nuova patch che sarà rilasciata a febbrario 2021.
Questo è stato necessario perchè una volta installata la patch di febbraio i vecchi domain controller Windows 2003 e 2008 per i quali non verrà rilasciata nessuna patch non potranno più comunicare con domain controller patchati.

Linux è affetto?

Ora veniamo a Linux, i tool di configurazione di Samba supportano canali sicuri tra i membri del dominio e i domain controller.
Tuttavia, il comportamento predefinito per il server schannel (secure channel) prima di Samba 4.8 era di negoziare automaticamente il canale sicuro solo se un client lo supportava.
Dalla versione 4.8, il comportamento predefinito di Samba è stato quello di preferire un canale sicuro per tutti i client (come se ci fosse “server schannel = yes” nel file smb.conf), il che è una soluzione sufficiente contro gli exploit noti che sfruttano la vulnerabilità CVE-2020-1472.

La richiesta di un canale sicuro potrebbe rendere inutilizzabili alcune vecchie applicazioni scrite per vecchie versioni di Active Directory (domini NT4).
Per questo motivo, la mitigazione di Microsoft per CVE-2020-1472 non disabilita immediatamente l’accesso non autenticato al servizio di netlogon.

Red Hat non è a conoscenza di applicazioni specifiche che richiedono l’uso di un canale non autenticato per il servizio di netlogon.
Tutti i componenti Samba in tutte le versioni di Red Hat Enterprise Linux (RHEL) supportano il funzionamento con schannel e continueranno a funzionare quando i futuri aggiornamenti di Microsoft disabiliteranno del tutto il supporto del canale non autenticato.

In Red Hat Enterprise Linux 6 le configurazioni predefinite dei pacchetti samba e samba4 forniti con il sistema sono vulnerabili in quanto non impongono la creazione di canali sicuri per tutte le connessioni client al servizio netlogon. La vulnerabilità può essere mitigata mettendo “server schannel = yes” nella sezione [global] del file smb.conf e riavvia Samba su tutti i DC.

Tuttavia , si può usare testparm per verificare che la configurazione di Samba sia in esecuzione in modalità domain controller oppure standalone (ossia membro di dominio) e quale impostazione “server schannel” viene utilizzata.

testparm -v -s | grep schannel

Se nell’output del comando compare “Server role: ROLE_DOMAIN_PDC” oppure “Server role: ROLE_DOMAIN_BDC” il server agisce come domain controller.
Nelle righe successive dell’output è riportato se è attivato o meno il secure channel (schannel).

Qui è installato Samba 4.7, questo server è vulnerabile.

Anche SuSE Linux è affetta dalla problematica per le versioni di Samba precedenti alla 4.8, anche qui il suggerimento per mitigare la falla è quello di inserire lo stesso parametro visto per RHEL: “server schannel = yes” nel file smb.conf e riavviare il servizio con un “sudo service smb restart”. Il supporto di SUSE riporta sono state correzioni e aggiornamenti a tutte le versioni supportate e interessate al problema.

NXNSAttack: Scoperta nuova vulnerabilità che sfrutta il meccanismo di delega DNS

di

0

La falla consente a un utente malintenzionato di forzare qualsiasi DNS resolver ricorsivo a inviare un numero elevato di query (Distributed denial-of-service) al server DNS autorevole della vittima.

L’aspetto che viene sfruttato è la delega glueless, dove un glue record corrisponde agli indirizzi IP di un name server (ossia un DNS server).
Petr Špa?ek scrive ul blog di CZ.NIC che
“Questa è la cosiddetta delega glueless, ovvero una delega che contiene solo nomi di server DNS autorevoli (a.iana-servers.net. oppure b.iana-servers.net.), ma non contiene i loro indirizzi IP.
Ovviamente DNS risolutore non può inviare una query a “nome”, quindi il risolutore deve prima ottenere l’indirizzo IPv4 o IPv6 del server autorevole “a.iana-servers.net”. o “b.iana-servers.net.” e solo allora può continuare a risolvere la query originale “esempio.com. A”. Questa delega glueless è il principio base di NXNSAttack: il server compromesso semplicemente restituisce la delega con nomi di server falsi (casuali) che puntano al dominio DNS della vittima, costringendo così il risolutore per generare query verso i server DNS delle vittime (in un inutile tentativo di risolvere falsi nomi di server autorevoli).
Molteplici i server DNS affetti da questo problema tra cui Bind, PowerDNS, i DNS di Cloudflare, Google, Amazon, Microsoft.

Si consiglia di aggiornare al più presto i propri pacchetti sulle varie distribuzioni Linux. Rimanente in attesa per quelle che non è ancora disponibile l’aggiornamento.

Dettagli nel documento: http://www.nxnsattack.com/dns-ns-paper.pdf

Canonical Livepatch patch di sicurezza senza riavvio

di

0

Bentornati nel nuovo episodio della saga relativa al patching del kernel Linux senza la necessità di riavviare il sistema per applicare gli aggiornamenti. In questo episodio vedremo Canonical Livepatch ossia la soluzione ideata per Ubuntu che, a differenza delle altre, è gratuita fino a 3 sistemi Ubuntu.

Il fatto che essa sia gratuita permette, a chiunque possieda un computer con Ubuntu o un server con Ubuntu, di usare la tecnologia al prezzo di un’iscrizione sul sito di Canonical.

Come Kernelcare, Livepatch applica solo patch di sicurezza e non di funzionalità, queste ultime vanno installate tramite la solita procedura (es. apt upgrade) e riavvio del sistema.

Livepatch è installabile a partire da Ubuntu 14.04 fino all’ultima versione. In questo tutorial installeremo Livepatch su un server con Ubuntu 18.04 Bionic Beaver.

Per ottenere una chiave di attivazione di Livepatch basta collegarsi al sito https://ubuntu.com/livepatch, registrarsi e ottenere il proprio codice.

La prima cosa da fare sul sistema, invece, è aggiornare i metadati dei pacchetti e installare le patch del sistema.

sudo apt update && sudo apt upgrade

Poi è necessario installare snap (snapd):

sudo apt install snapd

Quindi è possibile procedere con la semplicissima installazione del pacchetto canonical-livepatch come mostrato dalla guida e poi l’abilitazione con la chiave.

sudo snap install canonical-livepatch
sudo canonical-livepatch enable afd6b**********************

Lanciato il comando di attivazione comparirà un token identificativo.

Prima di applicare le patch di sicurezza del kernel si può utilizzare il comando per capire lo stato del sistema:

sudo canonical-livepatch status

Che può restituire un output simile:

Nello screenshot precedente, si nota come il kernel instalato sia 4.15.0-72.81-generic mentre il patchState è nothing-to-apply, il che significa che il nostro kernel è già all’ultima versione con le ultime patch di sicurezza disponibili.

Ogni volta che ci colleghiamo al server, è possibile vedere nel banner iniziale alcune statistiche relative a Livepatch, che in questo caso ricordano che Livepatch è abilitato e le patch sono tutte applicate.

In questo altro sistema dopo aver installato Livepatch, abbiamo riscontrato che ci sono delle patch di sicurezza del kernel da applicare.

Solitamente per applicare le patch non bisogna fare nulla, perchè si arrangia il deamon canonical-livepatchd ad installare le patch in autonomia, in alternativa è sufficiente lanciare il seguente comando:

sudo canonical-livepatch refresh

Tuttavia nel caso dello screenshot è necessario procedere all’installazione di un nuovo kernel: non tramite livepatch ma tramite il solito dist-upgrade o apt upgrade (e riavvio). Questo perchè il patchState è kernel-upgrade-required, come si può notare nello screenshot sopra.

sudo apt update
sudo apt dist-upgrade
sudo reboot

Invece nel caso sotto proposto, Livepatch ha applicato automaticamente delle patch di sicurezza:

KernelCare – kernel security patching rebootless

di

0

Secondo appuntamento con le soluzioni per l’applicazione delle patch per il kernel Linux senza necessità di reboot.

Dopo Ksplice di Oracle, in questo episodio presenteremo KernelCare, la tecnologia di CloudLinux, disponibile per svariate distribuzioni ad un costo accessibile (molto più economico di Ksplice). Una licenza per un singolo server costa 45 dollari all’anno.

KernelCare, al momento, è disponibile per:

  • Red hat Entreprise Linux/CentOS 6 e 7,
  • Oracle Linux UEK 6 e 7,
  • Debian 8 e 9,
  • Amazon (Linux) 1 e 2,
  • Ubuntu 14.04, 16.04, 18.04.

Mancano per ora la versione 8 di RHEL/CentOS/Oracle Linux e le ultime Debian e Ubuntu.

Per ottenere KernelCare è sufficiente scaricare lo script di installazione di KernelCare e lasciarlo tramite bash:

curl -s https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash

Poi è necessario registrarsi sul sito, tramite il quale è possibile ottenere una chiave temporanea, valida per 30 giorni, con la quale attivare il periodo di prova di KernelCare.
La chiave di attivazione viene inviata via e-mail all’indirizzo di registrazione.

Dopo aver ottenuto la chiave è sufficiente lanciare questo comando, seguito dalla chiave (asteriscata):

kcarectl --register a***************o

Dopo aver registrato la propria licenza del software, si può procedere all’installazione delle patch con il comando:

kcarectl --update

Il risultato del comando dovrebbe essere “Kernel is safe”.

Prima di lanciare l’update delle patch, e dopo.

Per avere informazioni circa il “punto” (level) di patching si può usare il comando:

kcarectl --uname

Questo è necessario perchè il classico uname non restituisce variazioni. Neppure dopo il riavvio del sistema.

Infatti è bene precisare che Kernelcare, rispetto ad altre soluzioni come Kspice, applica le patch di sicurezza (solo sicurezza, no funzionalità) al kernel attivo sul sistema mentre per installare realmente un kernel nuovo è necessario farlo con metodi tradizionali (yum update o apt upgrade); questo significa che se installate solo le patch di Kernelcare al riavvio del sistema vi troverete lo stesso kernel con le patch Kernelcare, non un kernel nuovo.

Kernelcare di default installa automaticamente le patch di sicurezza ogni 4 ore per cui se desiderate disattivare tale funzionalità, potete ricorrere alla modifica del file /etc/sysconfig/kcare/kcare.conf trasformando AUTO_UPDATE=True in AUTO_UPDATE=False

Aggiornamento del kernel senza riavviare con Ksplice

di

0

L’avevamo promesso in un precedente articolo: avremmo trattato i diversi sistemi per aggiornare il kernel Linux senza la necessità di fare reboot per attivare le patch. In questo articolo vederemmo la tecnologia Ksplice messa a disposizione di Oracle Enterprise Linux (OEL), Red Hat EL, CentOS, Debian e Ubuntu.

Nella versione desktop, ossia Ksplice Desktop, è gratuito (previa registrazione mail) ed è installabile su Ubuntu 19.10, 19.04, 18.04 e 16.04 e anche su Fedora 29; questo il sito https://ksplice.oracle.com/try/desktop dove scaricare la versione desktop.

In alcuni casi, Ksplice non solo consente l’aggiornamento del kernel del pinguino ma anche di glibc e openssl (queste ultime due solo su Oracle Enterprise Linux 6 e 7, per il momento).

La tecnologia di Oracle Linux, Ksplice (per server) non è gratuita ma è possibile provarla per 30 giorni, registrandosi sul sito di Oracle, accettando il Ksplice Uptrack Subscription Agreement.

Dopo aver accettato l’accordo, viene mostrata una pagina con il codice da usare per l’attivazione di Ksplice.

La cosa è alquanto semplice, basta copiare le prime tre righe di codice sul proprio server Oracle Linux.

wget -N https://www.ksplice.com/uptrack/install-uptrack
sh install-uptrack fbf***********************456

Per installare gli aggiornamenti, è sufficiente usare il comando:

uptrack-upgrade -y

Al termine dell’installazione, avremo una nuova versione del kernel installata.

Il tutto è tremendamente semplice.

Ricordiamo che l’aggiornamento del kernel, non viene riportato dal comando uname, che continuerà a riportare il vecchio kernel come attivo. Utilizzare il comando uptrack-uname per visualizzare la versione effettiva del kernel:

# uptrack-uname -a

Migliorare il riconoscimento virus con ClamAV

di

0

ClamAV è l’antivirus open source più popolare. Sebbene per GNU/Linux sia efficace nel relevare malware se lo usiamo su sistemi Windows, è facile imbattersi in parecchi falsi positivi, anche alcuni file di sistema firmati Microsoft vengono rilevati come tali.

Rimuovere un file di sistema lecito, può portare a seri problemi, quindi per migliorare il rilevamento su più piattaforme si possono integrare le normali firme (signature) con quelle messe a disposizione gratuitamente da securiteinfo.com

Non solo Windows ne beneficierà ma e avete un mail server, queste signature possono migliorare la rilevazione di malware trasmesso via posta elettronica.

Integrare le signature con ClamAV oppure ClamWin è semplicissimo, basta andare sul sito https://www.securiteinfo.com/clients/customers/signup e registrarsi.

Una volta ricevuta la password d’accesso al sito, entrare nel pannello di controllo nel menù SETUP e copiare il testo.

Queste righe vanno incollate in fondo al file /etc/clamav/freshclam.conf.

Poi è sufficiente riavviare il deamon freshclam (e clamav se lo si desidera) con il comando:

systemctl restart clamav-freshclam.service
systemctl restart clamav-daemon.service

Se si utilizza la versione gratuita delle signature di securiteinfo.com si può sincronizzare le firme al massimo 24 volte al giorno da un solo indirizzo IP. Per questo motivo è importante assicurarsi che nel file della configurazione freshclam.conf non siano impostati più di 24 aggiornamenti quotidiani.

La riga che va ricercata nel file è Checks e tale riga deve avere un valore uguale o inferiore a 24:

# Check for new database 24 times a day
Checks 24

La versione a pagamento consente di avere, rispetto alla versione free, le firme dei malware per attachi 0-day, la possibilità di scaricare da diversi indirizzi IP e nessun limite circa la velocità massima di download delle firme. Soluzione ideale per chi vuole usare ClamAV a casa o tramite connessioni differenti per cui si ottene un indirizzo IP volatile, prezzo a partire da 29,99 Euro.

Creare un server VPN in 10 minuti

di

0

Ci sono diversi motivi per cui possa essere conveniente e utile l’uso di una VPN.
Questi vanno dalla possibilità di mascherare il proprio indirizzo IP di casa alla possibilità di evitare le restrizioni regionali per siti come Netflix e Hulu oppure semplicemente il desiderio di avere un po’ più di privacy sul web.
Le VPN pubbliche non possono sempre essere affidabili e quelle più serie sono costose per questo la creazione del proprio server VPN è l’unico modo per coniugare i benefici di una VPN con una spesa limitata.
La buona notizia è che non è così difficile configurare un server VPN in modo rapido e può essere fatto in pochi semplici passaggi.

La prima cosa da fare è acquistare un server virtuale (VPS) a basso costo con un indirizzo IP o locazione del server in base alle tue esigenze. Ossia se necessiti di avere un indirizzo IP americano, devi comperare una VPS negli Stati Uniti.
Come sistema operativo della VPS va bene sia Debian 9 sia Centos 7. Sono sufficienti 512 MB di RAM. Attenzione alla banda perchè se la VPN verrà usata per vedere video, è facile consumare parecchio traffico.

Alcuni provider richiedono l’attivazione espicita dell’interfaccia TUN/TAP dal pannello di controllo. Quindi occorre collegarsi al pannello di controllo e nelle impostazioni, mettere TUN/TAP On.

Una volta ordinato il tuo VPS, dovrai accedere tramite SSH e quindi eseguire alcuni comandi rapidi. Se non sai come accedere al tuo server, ecco un tutorial per Windows (Come usare PuTTY).

Una volta collegato alla VPS, eseguire il seguente comando: 

wget https://git.io/vpn -O install-openvpn.sh 
bash install-openvpn.sh

Verrà presentata la seguente schermata:

Welcome to this OpenVPN “road warrior” installer!
Devo farti alcune domande prima di iniziare l’installazione
In genere puoi lasciare le opzioni predefinite e premere Invio, in modo da accettare le risposte precompilate.

Quale protocollo vuoi per le connessioni OpenVPN?
1) UDP (consigliato)
2) TCP
Protocollo [1-2]: 1

Immettere “1” (se non è già stato inserito) e premere nuovamente “Invio”.

Quale porta vuoi che OpenVPN ascolti?
Porta: 1194

Qui è possibile inserire “1194” (se non è già stato inserito) e premere nuovamente “Invio”.

Quale DNS vuoi usare con la VPN?
1) resolver di sistema attuali
2) 1.1.1.1
3) Google
4) OpenDNS
5) Verisign

Quindi, scegliere “1” e premere “Invio”.
Infine, dimmi il tuo nome per il certificato client

E’ consigliabile inserire un nome composto da una singola parola senza caratteri speciali es. client o il nome dell’hostname.
L’installazione potrebbe richiedere qualche istante, quindi da lì verrà configurato il server VPN.

Durante questa fase è possibile che vengano scaricati dei pacchetti aggiuntivi che mancano. Per esempio nel caso di CentOS 7, viene abilitato il repository epel e scaricato il programma openvpn.

La configurazione da utilizzare per il client è disponibile su /root/srv02.ovpn. Dove srv02 è il nome scelto precedentemente. Lo script infatti può essere utilizzato per un solo PC, per creane un altro lanciare nuovamente install-openvpn.sh

Come configurare un client OpenVPN

Scarichiamo il programma openVPN connect (https://openvpn.net/client-connect-vpn-for-windows/) dal sito di OpenVPN e installiamolo.

Poi Scarichiamo il file /root/srv02.ovpn dal server VPN sul computer, usando un programma come FileZilla o WinSCP (su Windows).

Salvare il file per esempio sul Desktop.

Dal menù vicino all’orologio cliccare col tasto desto sull’icona di OpenVPN.

Apparirà un menù a tendina dove sarà possibile importare un file di configurazione.

Selezionare import from local file.

Dall’elenco selezioniamo l’indirizzo IP del server VPN che abbiamo appena configurato; se non abbiamo mai usato OpenVPN prima ci sarà un solo indirizzo. Poi clicchiamo su Connect.

Potrebbe apparire un messaggio di conferma. Accettare.

Ora è possibile utilizzare la VPN.

Collegandoci ad un sito per vedere il proprio IP, apparirà l’IP del server VPN.

Risoluzione dei problemi

Può essere che ci siano dei problemi a collegarsi o che il tunnel non rimanga in piedi.

Lato Windows è possibile avere maggiori informazioni riguardo i problemi di connessione andando nella cartella dei log del client OpenVPN. La cartella è:

C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\etc\log

Lì ci sono dei file di testo che contengono le informazioni per indagare sull’anomalia.

Come aggiornare Vmware ESXi 6.5 contro il bug Spectre

di

0


Questo articolo è superato, non è più valido.

VMware ha rilasciato un bollettino di sicurezza denominato VMSA-2018-0002 in merito alle vulnerabilità di Meltdown e Spectre. La nota riguarda però solo Spectre in quanto, secondo il produttore, i software VMware non sono vulnerabili al bug Meltdown.  Il risultato dello sfruttamento della falla di sicurezza Spectre potrebbe consentire il passaggio di informazioni da una macchina virtuale a un’altra macchina virtuale in esecuzione sullo stesso host.

Sono interessati diversi prodotti VMware:

  • ESXi 5.5, 6.0 e 6.5 (da installare sono rispettivamente le patch: ESXi550-201709101-SG, ESXi600-201711101-SG, ESXi650-201712101-SG)
  • Workstation 12.x (aggiornare alla 12.5.8 per risolvere)
  • Fusion 8.x (aggiornare alla 8.5.9)

Chiaramente non sono predisposte patch per sistemi fuori supporto, che comunque risultano vulnerabili.

Le patch sono disponibili già dal 19 dicembre 2017 come indicato nel bolletino VMSA-2017-0021

Come patchare un host Vmware ESXi 6.5

Per patchare un host ESXi, è essenziale spostare tutte le VM accese altrove e mettere l’host in maintenance mode.

Poi attivare, qualora non lo fosse, il deamon SSH.

Disattivare il firewall temporaneamente con il comando:

esxcli network firewall ruleset set -e true -r httpClient

Lanciare questo comando:

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-6.5

Individuare la patch da installare, che è ESXi-6.5.0-20171204001-standard.

Installare la patch

esxcli software profile update -p ESXi-6.5.0-20171204001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Al termine dell’installazione, riattivare il firewall:

esxcli network firewall ruleset set -e false -r httpClient

Riavviare l’host col comando:

reboot

 

 

Come ricercare malware e rootkit su Linux

di

1


Virus, malware, trojan e rootkit sono diventati negli ultimi tempi un argomento assai dibattuto sul web. Notizie che si diffondono riguardanti la scoperta di una nuova vulnerabilità o cronache di lunghi down e servizi indisponibili arrivano persino in televisione.

Siamo arrivati ad un punto che gli antivirus tradizionali, non sono al momento più sufficienti: vi sarà capitato probabilmente di trovare del malware in un sito web sul quale server è installato, configurato alla perfezione e in esecuzione ClamAV?

Se state leggendo questo articolo e ne proseguirete la lettura, probabilmente siete incappati in questa problematica. Spero che queste indicazioni possano esservi utili per risolvere i vostri problemi.

Come ricercare malware e rootkit su Linux

Classificare il malware non è affatto facile, ma in questo articolo proviamo a discernere due categorie. La prima categoria include i tradizionali virus e i rootkit (ossia quei tool che si insidiano nel sistema operativo), l’altra contiene gli script malevoli.

Per scoprire se il proprio server o pc, ospita i classici virus è sufficiente utilizzare un antivirus come ClamAV. Per installare ClamAV e attivare una scansione, vi rimando a questo articolo: http://www.valent-blog.eu/2007/04/02/clam-antivirus/

Per quanto concerne i rootkit, potete seguire quest’altra guida http://www.valent-blog.eu/2009/01/23/proteggersi-dai-rootkit/  nella quale viene mostrato come installare chkrootkit e Rootkit Hunter.

Nel seguito di questo articolo scopriremo come usare Lynis e LMD. Vediamo ora come utilizzare altri stumenti per la scansione del proprio sistema.

Lynis – uno strumento di security auditing

Lynis è l’erede del famoso Rootkit Hunter. Si tratta, come nel caso del precedessore, di uno strumento utilizzabile per l’analisi del sistema, dei software installati e delle configurazioni attive sul server.
A differenza di altri strumenti, Lynis si caratterizza per l’estrema semplicità: non è necessario mettere mano a complicati file di configurazione per poter procedere ad una scansione del sistema.

Se avete già scaricato una versione precedente del tool, potete scegliere di rimuovere il contenuto della cartella /usr/local/lynis con il comando:
rm -r /usr/local/lynis

Bene, ora vediamo come attivare Lynis sul server o computer.
Spostiamoci nella cartella dei file temporanei /tmp
cd /tmp

Scarichiamo l’ultima versione disponibile di Lynis
wget https://cisofy.com/files/lynis-2.2.0.tar.gz

Scompattiamo l’archivio in /usr/local/lynis
tar xvfz lynis-2.2.0.tar.gz -C /usr/local/

Creiamo un link simbolico (usate questo comando solo se non avete mai scaricato Lynis)
ln -s /usr/local/lynis/lynis /usr/local/bin/lynis

Ora per maggior sicurezza, facciamo fare un check a Lynis per capire se abbiamo l’ultima versione disponibile.

lynis update info

Se viene restituito che lo Status è Up-to-date, siamo OK.

Altrimenti procediamo alla cancellazione della cartella /usr/local/lynis e a seguire i passaggi precedenti.

A questo punto ci troviamo con Lynis attivo e pronto a fare una scansione del sistema.

Tutto è molto semplice: per lanciare una scansione interattiva (ossia con la necessità di premere INVIO di tanto in quanto) basta semplicemente lanciare il comando:

lynis audit system

Lynis

Durante l’attività, mediante scansione interattiva, sarà necessario premere il tasto INVIO per procedere oppure la combinazione di tasti CRTL e “C” per interrompere la scansione.

E’ possibile effettuare anche una scansione più rapida, aggiungendo il flag -Q oppure –quick

lynis audit system –quick

Il risultato della scansione può essere riesaminato in seguito nel file di log /var/log/lynis.log

 

Automatizzare con Lynis la scansione del sistema

Possiamo decidere di effettuare frequentemente delle scansioni del sistema e inviare i risultati di tali analisi ad una caselle di posta elettronica.

E’ opportuno accertarsi che sia disponibile il comando mail. Se digitando il comando:

whereis mail

Viene restituito nulla, allora mail non è disponibile; per disporre di questo comando si può installare il pacchetto mailutils

apt-get install mailutils

Fatto questo, è possibile creare un cronjob da usare per schedulare il lavoro.

Per aggiungere un cronjob, modifichiamo il crontab dell’utente root:

crontab -e

All’interno di questo file aggiungiamo in fondo la seguente riga:

0 3 * * * /usr/local/bin/lynis audit system –quick 2>&1 | mail -s “Analisi di Lynis” you@example.com
Questo cronjob verrà avviato tutti i giorni alle ore 3.00 e al termine della scansione invierà un messaggio di posta elettronica contenente il risultato a you@example.com, ovviamente quest’ultimo indirizzo andrà cambiato.

 

Linux Malware Detect (LMD) – analisi e monitoraggio web script

Linux Malware Detect (LMD) è uno scanner di malware per Linux progettato per individuare il software malevolo che si installa nelle cartelle contenti i file di un sito web.
E’ principalmente orientato alla ricerca di codice malevolo che viene iniettato in file php o js, questo codice solitamente non viene segnalato dai normali antivirus come problematico ma che può creare forti danni ad un sito web.
Tengo a precisare che l’uso di Linux Malware Detect (LMD)  non è così semplice ed immediato come Lynis.

Procediamo adesso a scaricare e installare il tool:

cd /tmp
wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
tar -xvzf maldetect-current.tar.gz
cd maldetect-*
sudo ./install.sh

Una volta installato LMD, il tool può essere eseguito tramite il comando maldet.

Siccome Linux Malware Detect (LMD) è stato progettato per la scansione di file appartenenti a siti web è conveniente scansionare soltanto le cartelle che contengono tali file.
Per esempio se abbiamo un webserver con sistema operativo Debian o Ubuntu, questi file sono contenuto nella cartella /var/www e nelle sottocartelle

Quindi possiamo procedere a lanciare una scansione ad-hoc, usando questo comando:

maldet -a /var/www

Verso la parte finale dell’output del comando vi viene indicato il report in cui è stato il risultato della scansione.

 

Monitoraggio in tempo reale del malware con Linux Malware Detect

A differenza di altri tool, Linux Malware Detect consente di attivare un monitoraggio e analisi in backgroud dei file creati, modificatie spostati in backgroud. Il comportamento è simile a quello degli antivirus per Windows, il software rimane sempre in esecuzione sul server in attesa di poter analizzare file recenti.

Per potersi servire del monitoraggio in tempo reale, è necessario accertarsi di aver installato il pacchetto inotify-tools (più dipendenze) che contiene il comando inotifywait, richiesto da Linux Malware Detect. Se utilizzate una distribuzione Debian o Ubuntu:

apt-get install inotify-tools

Ora creiamo un file contenente la lista dei percorsi da analizzare in tempo reale:

nano /usr/local/maldetect/maldet-path.list

Inseriamo i percorsi uno per riga, es.:

/home?/?/public_html/
/var/www/clients/

Poi lanciamo il comando:

/usr/local/maldetect/maldet -m /usr/local/maldetect/maldet-path.list

Questo crerà un processo che rimarrà in esecuzione fino a che il server non verrà riavviato. Ciò comporta che il tool di monitoring di Linux Malware Detect vada avviato nuovamente ad ogni riavvio del sistema operativo.
Pertanto è suggerito inserire una riga nel file /etc/rc.local

echo “/usr/local/maldetect/maldet -m /usr/local/maldetect/maldet-path.list” >>/etc/rc.local

Anche per Linux Malware Detect è possibile pianificare una o più scansione che vengono eseguite in modo automatico e ricevere il risultato via email.
Verifichiamo la presenza del file /usr/local/maldetect/conf.maldet. Se il file non è presente creiamo un file di configurazione personalizzato

nano /usr/local/maldetect/conf.maldet

nel file inseriamo queste righe:

email_alert=”1″
email_addr=”you@domain.com”

sostituiamo you@domain.com con l’indirizzo di posta al quale vogliamo inviare il report delle analisi.

Se il file invece è già disponibile, modifichiami i parametri email_alert e email_addr mettendo 1, e l’indirizzo mail.

lmd

Linux Malware Detect si occuperà di fare la scansione in modo automatico di alcune cartelle contenenti file di siti web come /home?/?/public_html/,/var/www/html/,/usr/local/apache/htdocs/,/var/www/clients/ ed invierà regolarmente tutti i giorni un analisi fatta sui file creati o modificati negli ultimi 7 giorni.