Archivi categoria: Linux

Case History: Web Application Security Assessment e Remediation

Web Application Security Assessment e Remediation

Per importante Cliente di Verona operante nel settore dell’e-learning, abbiamo effettuato un’attività di security assestment in seguito all’attacco hacker dei siti web del Cliente.

Continua la lettura di Case History: Web Application Security Assessment e Remediation

Case History: Integrazione Panthera ERP con Payline Decision

Integrazione Panthera ERP con Payline Decision

Per importante Cliente di Padova operante nel settore del noleggio e dell’assistenza di carrelli elevatori e piattaforme aeree, abbiamo realizzato un connettore che esporta i movimenti contabili di tutte le partite aperte e di tutte le partite chiuse degli ultimi 12 mesi dei propri clienti da Panthera verso il servizio Payline Decision di Cerved Group in modo da permettere al Cliente di usufruire di tale servizio.

Payline Decision è un servizio che mira a raccogliere e monitorare le abitudini di pagamento delle società italiane e che si realizza attraverso la collaborazione tra le imprese.

Continua la lettura di Case History: Integrazione Panthera ERP con Payline Decision

Case History: Analisi Forense e Recupero Dati Cancellati

Recupero Dati Cancellati

Per importante cliente di Brescia operante nel settore dell’investigazione privata, abbiamo effettuato un’attività di informatica forense atta a recuperare dei documenti cancellati da un hard disk.

Per svolgere questo compito abbiamo utilizzato un convertitore SATA-USB che ci ha consentito di connettere l’hard disk ai nostri PC.

Inoltre per poter operare sui dati in sicurezza abbiamo utilizzato una distro Linux specifica per le attività forensi chiamata Kali, avviata da una memoria USB in modalità forense (forensics mode).

Continua la lettura di Case History: Analisi Forense e Recupero Dati Cancellati

Con Linux è possibile esternalizzare la gestione della propria infrastruttura informatica?

Server room

Linux è un sistema operativo che ha trovato la sua maggiore applicazione nei server aziendali come dimostrano i numeri e le recenti politiche di colossi storici di questo settore come IBM che, pur avendo già sistemi operativi proprietari e affermati come AIX e OS/400 (i5/OS, IBM i, ecc.), ha deciso di offrire pieno supporto a Linux per l’intera gamma dei suoi Power Systems. Continua la lettura di Con Linux è possibile esternalizzare la gestione della propria infrastruttura informatica?

Spunti per una strategia di Disaster Recovery efficace

Al giorno d’oggi l’importanza delle informazioni e dei dati per le aziende è vitale, infatti citando wikipedia:

For example, of companies that had a major loss of business data, 43% never reopen and 29% close within two years.fonte:wikipedia

Quindi in sostanza quasi la metà delle aziende che subiscono una grave perdita di dati sono destinate a chiudere.

Può non sembrare, ma la probabilità di perdere dati importanti è molto alta, solo per fare un esempio può verificarsi a seguito di:

  • errori umani (es. per sbaglio “facendo pulizia” nel computer si cancella un file di troppo; dopo aver editato un file al posto di scegliere “Salva con nome…” si preme “Salva” ed ecco che la versione originale del file è persa.);
  • guasti (es. si rompe il disco rigido su cui erano memorizzati i dati, si danneggia la chiavetta USB, si riga il CD/DVD ecc.)
  • minacce informatiche (es. virus che cancella i dati del computer, virus che cifra i documenti presenti sul computer e chiede il riscatto ecc.)
  • furti (es. il ladro ruba i computer dell’ufficio e il server su cui erano memorizzate tutte le anagrafiche)
  • disastri (es. incendi, allagamenti ecc.)

Inoltre, anche qualora un’azienda abbia fatto delle copie dei dati importanti molte volte recuperarli (sperando che siano in buono stato) e ripristinarli richiede molto tempo (tipicamente giorni) che influisce sensibilmente sulla produttività aziendale e di conseguenze sulle perdite di denaro.

Fortunatamente con gli appositi strumenti informatici è possibile predisporre le misure tecnologiche e organizzative necessarie a far sì che i dati che perderete vengano ripristinati in scioltezza.

Come probabilmente avrete capito l’unico modo di evitare la perdita irreparabile di dati è quella di fare una copia degli stessi (copia di backup).

Questo però da solo non basta, nel seguito di questo articolo vedremo come predisporre un sistema di disaster recovery con i seguenti punti di forza:

  • backup e ripristino dei dati veloce e il più possibile automatizzato;
  • backup alla scadenza temporale preferita (giornaliero, settimanale, ogni ora, ogni minuto, ecc..).
  • copia remota dei dati (es. copia dei dati dal server in ufficio verso un computer di un’altra sede) in modo da mettersi al riparo da furti o disastri naturali;
  • backup incrementale, ovverto vengono copiate solo le ultime modifiche dei dati rispetto all’ultimo backup, in questo modo la velocità nell’effettuare un backup aumenta sensibilmente.
  • occupazione dei backup estremamente ridotta;
  • possibilità di vedere le varie versioni storiche di un documento potendo andare indietro nel tempo, nel modo più immediato possibile (Macchina del tempo).

Per raggiungere gli obiettivi sopra esposti è necessario predisporre un’infrastruttura come quella in figura.

A disaster recovery scenario

L’esempio mostra la sede di un’azienda più un secondo luogo sicuro che potrebbe essere ad esempio la seconda sede.

Il backup è fatto a due livelli.

  1. I file importanti dei computer della rete della sede 1 (es. file autocad, pdf, documenti word, excel, ecc.) sono copiati e storicizzati sul server 1.
  2. I file importanti del server 1 e i backup della rete della sede 1 sono copiati e storicizzati sul server 2.

Come si vede in figura è importante che il server 2 si trovi in una posizione geografica ragionevolmente distante dal server 1. Questo per evitare che un evento disastroso che dovesse coinvolgere il server 1 possa interessare anche il server 2 (esempi di eventi disastrosi possono essere: terremoti, allagamenti, furti, incendi ecc.).

I server e i computer della rete vanno configurati come segue:

Server:

  • Sistema Operativo: Una distribuzione Linux per Server. Ad esempio l’ultima Ubuntu Server Long Term Support.
  • Programmi: un server SVN + rsnapshot

Computer della rete:

  • Sistema Operativo: Windows
  • Programmi: un client SVN (es.  Tortoise SVN)

Il server SVN e i rispettivi client SVN installati sui computer della rete servono a eseguire il primo livello di backup. Ogni client può salvare i propri file sul server, copiare i file salvati da altri client e vedere le versioni storiche di uno stesso file in modo da poter consultare tutti i cambiamenti subiti da un file e poter ripristinare una versione precedente di un file.

Il tool Rsnapshot consente invece di implementare il secondo livello di backup. Ovvero consente di effettuare una copia tra i due server che può essere schedulata con una granularità temporale a scelta (es. ogni giorno, ogni ora ecc.). Inoltre in modo facile è possibile consultare “fotografie” dei file copiati nei vari giorni e poter aprire una versione vecchia direttamente con un doppio click.

Linux: come ricevere una mail quando il disco è quasi pieno

a server rack

Il disco del server aziendale ogni tanto si riempie bloccando tutto: gestionale, database ecc.

Se per voi questo scenario è comune forse avete trovato il modo per risolverlo, ma andiamo con ordine.

Mi è capitato nella mia carriera di aver a che fare con software enterprise che hanno la brutta abitudine di non ripulire mai i file di log che periodicamente producono (es. IBM DB2) con conseguente riempimento periodico dello spazio su disco e blocco di loro stessi in primis e a catena di tutto il resto, magari l’ERP della vostra azienda.

Sicuramente esistono dei software molto belli e molto costosi che potrebbero tener controllato lo stato del server e prevenire questi casi, fortunatamente per voi se il SO del vostro server è Linux non ne avete bisogno.

In questo caso infatti è sufficiente predisporre un piccolo script che periodicamente controlla lo stato di occupazione dei dischi e vi notifica via mail di un eventuale superamento di una soglia di occupazione predefinita.

Per realizzare uno script del genere dobbiamo essere in grado di fare sostanzialmente due cose:

  1. controllare lo stato di occupazione dei dischi
  2. inviare una mail

Il comando Linux per soddisfare il primo requisito è df che, se lanciato con l’opzione -h, ci darà una visione d’insieme umanamente leggibile sullo stato di occupazione delle partizioni.

es.

srv02:~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 98G 7.4G 91G 8% /
udev 1015M 120K 1014M 1% /dev

Per poter trattare però il suo output in maniera automatica ci conviene utilizzarne la versione seguente:

srv02:~ # df -a -P
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda2 102748540 7692172 95056368 8% /
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
debugfs 0 0 0 - /sys/kernel/debug
udev 1038388 120 1038268 1% /dev
devpts 0 0 0 - /dev/pts
securityfs 0 0 0 - /sys/kernel/security

Il comando Linux per soddisfare il secondo requisito è mail che appunto serve per mandare mail da riga di comando.

Mettendo tutto insieme otteniamo qualcosa di simile

#!/bin/bash

set -x

SIZE_PERC_LIMIT=75
TO="admin@domain.it"
CC="cto@domain.it"
NOREPLY="$(hostname)-noreply@domain.it"
FROM="$(hostname)@domain.it"

df -a -P | grep '^/dev/' | tr -s ' ' | cut -d' ' -f5 | grep '%' | cut -d% -f1 | while read value; do
if [ $value -ge $SIZE_PERC_LIMIT ]; then

echo "*** $(hostname) ha raggiunto la soglia di occupazione del ${value}% di una partizione" > /tmp/check_disco.log
echo "*** di seguito viene riportato l'output del comando: df -h" >> /tmp/check_disco.log
df -h >> /tmp/check_disco.log

SUBJECT="ATTENZIONE $(hostname): stato occupazione partizioni"

mail -c "$CC" -r "$FROM" -R "$NOREPLY" -s "$SUBJECT" "$TO" < /tmp/check_disco.log

break
fi
done

L’unica riga che credo richieda una spiegazione è la 11 la quale ha come scopo quello di ottenere per ogni partizione la percentuale di occupazione e per farlo compie in sequenza le seguenti operazioni:

  1. df -a -P: stampa lo stato di tutte le partizioni utilizzando il formato POSIX. Questo dovrebbe favorire la portabilità di questo script.
  2. grep '^/dev/': seleziona solo le partizioni che ci interessano (ovviamente l’espressione regolare potrebbe essere modificata a seconda della nomenclatura delle vostre partizioni) scartando cioè filesystem virtuali, dispositivi di rete, ecc.
  3. tr -s ' ': rimpiazza le sequenze di spazi con spazi singoli per facilitarne la suddivisione con il comando successivo
  4. cut -d' ' -f5: taglia le righe in campi separati da spazi e ne prende il quinto: quello della percentuale di occupazione
  5. grep '%': tiene solo i valori percentuali scartando eventuali trattini
  6. cut -d% -f1: separa la percentuale dal valore e tiene quest’ultimo
  7. while read value; do: il valore letto lo memorizza nella variabile $value

Il resto dello script non fa altro che confrontare ogni valore letto con la soglia d’allarme che in questo esempio è impostata sul 75% e nel caso in cui sia maggiore spedisce una mail a chi di dovere.

A questo punto non ci resta che schedulare questo script, che chiameremo check_disco.sh e a cui daremo i permessi di esecuzione, con il mitico crontab a seconda delle nostre esigenze.

Se per esempio abbiamo paura che il disco si possa riempire repentinamente, magari a causa di qualche software che in caso di errore produce grossi dump a rate elevati (Java VM anyone?), possiamo pensare di schedularlo in modo che giri ogni ora con la seguente riga di crontab:

0 * * * * /usr/bin/check_disco.sh &> /var/log/check_disco.log

Da notare come la riga 3 dello script (set -x) in combo con la redirezione degli stream di output su check_disco.log ci darà la possibilità di valutare l’ultima esecuzione dello script, nel caso in cui le cose non siano andate come ci aspettavamo.

Come nota finale aggiungo che se non riuscite a mandare le mail attraverso il comando mail, potreste provare a creare un file .mailrc nella directory home dell’utente su cui è stata schedulata l’esecuzione dello script, in cui specificare l’indirizzo del vostro server SMTP nel modo seguente:

set smtp=X.X.X.X