Ricerche IT

Una delle situazioni più antipatiche che un amministratore di un server di posta deve affrontare, è la richiesta da parte di qualche utente (che, sapendo di romperti le scatole, ed essendo in difficoltà, farà la richiesta nel modo più suadente possibile) di recuperare un messaggio/elemento (o più messaggi/elementi) cancellato per sbaglio. In genere la cosa è piuttosto antipatica, soprattutto se si tratta di andare a ripristinare dei messaggi dai nastri di backup.

Nel caso di Exchange, un ripristino da backup è un’operazione piuttosto delicata, poiché, se non si segue una strategia intelligente, il ripristino è un vero delirio; ad esempio, se si fa solamente il backup dello store, tramite ntbackup, bisogna ripristinare lo store, montarlo a parte e poi estrarre ciò che serve, questo almeno in linea teorica, io per fortuna non ho mai dovuto compiere quest’operazione, che secondo me equivale ad un impeto masochistico degno del miglior Tafazzi.

Rimanendo nell’ambito del backup, una strategia un minimo più intelligente può essere quella di utilizzare uno strumento come Exmerge (descritto, anche se non in modo completo, in quest’articolo), oppure un software di backup che consenta di effettuare il salvataggio delle singole cassette postali.

In ogni caso il ripristino di un backup è sempre una grossa rottura, ma, nel caso di Exchange, esistono strumenti per poter ripristinare gli elementi cancellati, a patto che questi non siano stati cancellati da più di una settimana (Exchange conserva gli elementi cancellati per una settimana come impostazione predefinita).

Nel caso siano stati cancellati alcuni messaggi o altri tipi di elementi dalla propria cassetta postale (per cancellati si intende che i messaggi sono stati rimossi anche dalla posta eliminata), è possibile utilizzare una funzione di Outlook, che consiste nell’entrare nella cartella Posta eliminata, quindi andare sul menu Strumenti -> Recupera posta eliminata, dove è possibile recuperare i messaggi cancellati da non più di una settimana, come mostrato nella figura seguente:

Figura 1 - recupera posta eliminata

Da questa finestra è possibile decidere se ripristinare l’elemento in Posta eliminata oppure se rimuoverlo definitivamente.

Diverso il caso se si cancella per errore uno o più elementi da una cartella pubblica, poiché, in questo caso, gli elementi cancellati non finiscono nella cartella Posta eliminata, ma semplicemente svaniscono. In realtà, è possibile ripristinare gli elementi eliminati dalle cartelle pubbliche utilizzando il tool PFDAVAdmin rilasciato da Microsoft, il cui utilizzo principale consiste nella gestione centralizzata delle autorizzazioni sulle cartelle pubbliche, ma che può essere utilizzato ottimamente per ripristinare elementi rimossi incautamente da una cartella pubblica. Una volta scompattato PFDAVAdmin, lanciare l’eseguibile dal server Exchange utilizzando l’account Administrator, quindi cliccare sul menu File -> Connect ed impostare il valore del server Exchange e del Global Catalog dell’organizzazione, lasciando selezionata l’opzione Public Folders, come illustrato in figura 2:

Figura 2 - finestra di connessione di PFDAVAdmin

Effettuata la connessione, espandere l’albero a sinistra e andare a selezionare la cartella pubblica da cui vogliamo recuperare l’elemento cancellato, quindi, selezionare la scheda Items e l’opzione in basso Deleted contents, quindi selezionare l’elemento/gli elementi da recuperare, cliccare col tasto destro e selezionare la voce Recover items, come evidenziato in figura 3:

Figura 3 - finestra di recupero elementi di PFDAVAdmin

Una volta cliccato su Recover Items, cliccare Ok sulla finestra di notifica dell’avvenuto ripristino, dopodiché verificare che l’elemento sia stato effettivamente ripristinato, cosa che in genere avviene.

La cosa bella di questo tool, è che le stesse operazioni è possibile compierle anche sulle cassette postali dell’intera organizzazione, a patto di avere le autorizzazioni del caso sulle mailbox dei singoli utenti; per poter gestire le cassette di posta, nella finestra di connessione mostrata in Figura 2 bisogna indicare l’opzione All mailboxes in luogo dell’opzione Public Folders.

Link di riferimento

http://support.microsoft.com/?scid=kb%3Ben-us%3B924044&x=4&y=9

Se si deve gestire un firewall Linux con iptables, in determinate situazioni può riverlarsi indispensabile poterne gestire il logging nel modo più lineare possibile; il passo più logico per raggiungere questo scopo è quello di effettuare un logging su file delle attività di iptables che si intende monitorare. Si tenga presente che questi passaggi sono stati effettuati su Debian Etch.

L’operazione consta di più passaggi:

1. configurazione di iptables per fare in modo che venga fatto il logging di determinati tipi di traffico su file;
2. installazione e configurazione di syslog-ng, che consentirà di specificare uno specifico file su cui redirigere il logging di iptables;
3. configurazione di logrotate per poter ruotare i file di log di iptables.

Configurazione di iptables

Per prima cosa, dobbiamo decidere quale tipo di traffico vogliamo monitorare, in questo caso, scegliamo di monitorare il traffico icmp verso l’ipotetica interfaccia esterna del nostro firewall. Se si prende come riferimento l’articolo precedente riguardante iptables, bisogna aggiornare lo script di iptables, caricando per prima cosa il modulo ipt_LOG tramite la direttiva:

modprobe ipt_LOG

Ora è possibile specificare un’istruzione per il logging del traffico ICMP sull’interfaccia esterna, assumendo che questa prenda il nome eth1:

iptables -A INPUT -i eth1 -p icmp -j LOG --log-level 4 --log-prefix='LOG_ICMP '

quest’istruzione è da inserire prima dell’eventuale direttiva che consente o nega il traffico ICMP verso l’interfaccia eth1. Da notare la direttiva log-prefix, che farà precedere le stringhe di logging da ciò che abbiamo specificato tra apici (nel nostro caso LOG_ICMP ). Con questo comando termina la configurazione di iptables.

Installazione e configurazione di syslog-ng

In questo secondo passaggio andremo a sostituire il server syslog classico con syslog-ng, un server syslog più evoluto che permette una gestione più raffinata dei messaggi di log provenienti da kernel e demoni. Prima di configurare syslog-ng, dobbiamo però fare in modo che i log di iptables non compaiano in console (che in pratica si traduce nella comparsa dei vari log sul monitor del PC), cosa decisamente fastidiosa: ciò è possibile editando il file /etc/sysctl.conf:

nano /etc/sysctl.conf

quindi, dobbiamo decommentare la riga 1 del seguente listato sostituendola con la riga 3:

1
2
3

#kernel.printk = 7 4 1 7
 
kernel.printk = 4 4 1 7

in tal modo, indicando il valore 4 in vece del valore 7, si indica che il logging a console viene abilitato solo per il logging di livello inferiore a 4, avendo indicato noi nello script di iptables che il nostro logging è di valore 4, la console rimarrà immacolata.

AGGIORNAMENTO
Un metodo alternativo per raggiungere lo stesso scopo è quello di editare il file /etc/default/syslog-ng decommentando l’ultima riga, che diventerà:

CONSOLE_LOG_LEVEL=4

al posto di 4, potremo mettere, nel caso, anche un numero inferiore fino ad arrivare a 1. Una volta riavviato il demone di syslog-ng, verrà modificato come visto in precedenza il file kernel.printk per prevenire la visualizzazione sulla console dei log di iptables.
FINE AGGIORNAMENTO

Ora, installiamo syslog-ng con il classico apt:

apt-get install syslog-ng

che non si limita ad installare syslog-ng ma disinstalla anche il classico syslog, di cui va a prendere il posto. A questo punto va configurato syslog-ng per far sì che i log non vadano a finire nei file /var/log/messages, /var/log/kern.log e /var/log/syslog, editando il file /etc/syslog-ng/syslog-ng.conf:

nano /etc/syslog-ng/syslog-ng.conf

dove bisogna aggiungere in fondo al file le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# configurazione logging di iptables
 
destination df_firewall {
        file("/var/log/iptables.log");
};
 
filter f_firewall {
match("LOG_ICMP ");
};
 
log {
        source(s_all);
        filter(f_firewall);
        destination(df_firewall);
};

Le righe da 3 a 5 servono per parametrizzare il file dei log di iptables, le righe da 7 a 9 rappresentano il criterio con cui viene deciso, da parte di syslog-ng, quando redirigere le stringhe di logging verso il file specificato in precedenza attraverso la condizione

match("LOG_ICMP ")

mentre le righe da 11 a 15 rappresentano la direttiva vera e propria verso syslog-ng per loggare tutto ciò che proviene da iptables contenente la stringa “LOG_ICMP “.

Lasciando le cose in questo modo, il logging verso il file /var/log/iptables.log funziona perfettamente, però i log vengono inviati anche verso i file “canonici” di log del kernel. Per ovviare al problema, bisogna modificare il file /etc/syslog-ng/syslog-ng.conf in modo che syslog-ng non scriva i messaggi provenienti da iptables nei file indicati in precedenza; primo passo, la modifica del filtro f_kern:

1
2
3

filter f_kern { facility(kern); };
 
filter f_kern { facility(kern) and not match("LOG_ICMP "); };

dove la riga numero 1 viene sostituita dalla riga numero 3, così da evitare che le voci di log vadano a finire nel file /var/log/kern.log; il passo successivo riguarda la modifica della voce relativa al filtro f_syslog:

1
2
3

filter f_syslog { not facility(auth, authpriv); };
 
filter f_syslog { not facility(auth, authpriv) and not match ("LOG_ICMP "); };

dove andremo a sostituire la riga numero 1 con la riga numero 3, per impedire che il logging di iptables vada a popolare il file /var/log/syslog. Ora rimane da modificare il filtro f_messages, che da così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news);
};

diventa così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news)
                and not match ("LOG_ICMP ");
};

modifica che inibisce il logging di iptables nel file /var/log/messages. In tutte e tre le situazioni, abbiamo aggiunto la condizione

and not match ("LOG_ICMP ")

condizione che istruisce syslog-ng ad ignorare, per quel determinato filtro, tutti i log che contengono la stringa “LOG_ICMP “, per cui, se si modifica la configurazione di iptables utilizzando, per il logging, un prefisso diverso da quello indicato (tramite la direttiva log-prefix di iptables), tutte le segnalazioni finiranno nei file “normali” e non nel file /var/log/iptables.log che abbiamo creato.

Configurazione di logrotate

Tenendo le cose così come sono, con l’andare del tempo il file /var/log/iptables.log assumerà dimensioni sempre più grandi, rendendo quindi i log di difficile lettura. La soluzione al problema sta nell’istruire logrotate (che dovrebbe essere già presente in Debian Etch) per routare il nostro file di log personalizzato secondo i criteri che preferiamo. Prima di configurare logrotate, vediamo brevemente come funziona.

Logrotate ha un file di configurazione, /etc/logrotate.conf, in cui sono indicate le opzioni generali di configurazione, ed ha una directory, /etc/logrotate.d, in cui vi sono i file di configurazione riguardanti il logging delle singole applicazioni; questi file di configurazione vengono richiamati dalla direttiva presente nel file /etc/logrotate.conf

# packages drop log rotation information into this directory
include /etc/logrotate.d

Nel nostro caso, dovremo creare un file chiamato iptables nella directory /etc/logrotate.d, quindi editarlo per indicare a logrotate come routare il nostro file:

touch /etc/logrotate.d/iptables
nano /etc/logrotate.d/iptables

Nel file /etc/logrotate.d/iptables andremo ad inserire questo contenuto:

1
2
3
4
5
6
7
8

/var/log/iptables.log {
        weekly
        rotate 4
        compress
        notifempty
        missingok
        endscript
}

Vediamo di esaminare nel dettaglio le varie istruzioni del file: weekly indica che il file di log viene routato con cadenza settimanale, rotate 4 significa che vengono conservati 4 log già routati, compress specifica che i file di log routati vengono compressi, notifempty sta ad indicare a logrotate di non routare il file di log se questo è vuoto, missingok permette a logrotate di non segnalare errori se per qualche motivo il file di log non esiste, endscript indica semplicemente il termine delle istruzioni di configurazione per il file corrente. Per ulteriori informazioni sulle opzioni di logrotate è possibile consultare le pagine man di logrotate oppure gli ultimi due collegamenti nella sezione Link di riferimento di quest’articolo.

Ora non rimane che verificare nel tempo il corretto funzionamento di logrotate.

Link di riferimento

http://tuttodebian.blogspot.com/2008/05/iptables-and-syslog-how-to-log-in.html
http://www.linux.it/~rubini/docs/printk/printk.html
http://openskill.info/infobox.php?ID=779
http://www.uielinux.org/blog/14-usare-linux/87-ubuntu-professionale-usiamo-il-logrotate.html

Recentemente mi è accaduta una cosa curiosa, su un PC di un utente, facendo doppio click su un file Excel con estensione .xls, si apre normalmente Excel ma non viene aperto il file, senza nessuna notifica o messaggio d’errore da parte del programma. Provando a cliccare col tasto destro sul file, selezionando la voce "Apri con…" e scegliendo Microsoft Excel dall’elenco, viene visualizzato un messaggio d’errore che indica l’impossibilità di trovare il percorso del file. Se invece si apre Excel, e si va su File -> Apri selezionando dalla finestra di dialogo il file da aprire, la cartella di lavoro si apre normalmente.

Per ritornare ad una situazione decente, è sufficiente andare nelle opzioni di Excel (menu Strumenti -> Opzioni), andare sulla scheda Generale e deselezionare la casella "Ignora altre applicazioni". Se invece si possiede una copia di Excel 2007, bisogna cliccare sul pulsante di Office (cioé la riedizione del pulsante Start di Windows in salsa Office), quindi andare su Opzioni, Avanzate e lì, nell’area Generale, deselezionare la casella "Ignora altre applicazioni".

Così facendo, la cartella di lavoro si aprirà normalmente con un semplice doppio click sul file Excel.

Link di riferimento
http://support.microsoft.com/kb/211494