Installazione e configurazione di Logwatch su Ubuntu

Lascia una risposta

Nei server Linux che amministro ho recentemente installato un programma di monitoring dei logs: logwatch.
Una questione importante ma abbastanza noiosa e per cui non si ha mai molto tempo è – appunto – quella dell’analisi dei log, una sorta di “diario” dell’attività svolta dal sistema.
Spesso si ricerca nei logs solo quando insorge un problema: la proattività di logwatch, invece, ci permette di avere una sintesi di ciò che è successo e che merita la nostra attenzione direttamente via email.

Assicuratevi di avere un MTA installato e configurato a dovere [consiglio: postfix o qmail].
Una volta installato, logwatch invia una mail a root@localhost ogni giorno.
Modifichiamo quindi l’indirizzo a cui root farà il forward di tutta la posta:

% cat /etc/aliases
postmaster: root
root: cron@michelebologna.net

Modifichiamo la schedulazione dell’esecuzione di logwatch da giornaliero a mensile [da cron.daily a cron.weekly]:

mv /etc/cron.daily/*logwatch /etc/cron.weekly

Ed infine specifichiamo a logwatch di analizzare i log relativi agli ultimi 7 giorni e il formato da usare (HTML):

cp /usr/share/logwatch/default.conf /etc/logwatch/conf/logwatch.conf

Nel file di conf cambiate:

  • Format = html
  • Range = between -7 days and -1 days

Ecco l’esempio di una mail ricevuta da logwatch:

logwatch1 150x150 Installazione e configurazione di Logwatch su Ubuntu

logwatch2 150x150 Installazione e configurazione di Logwatch su Ubuntu

 

 

 

 

Come potete vedere ci sono informazioni molto interessanti, come:
* i pacchetti installati/aggiornati tramite dpkg
* gli accessi tramite ssh
* gli utilizzatori di sudo
* lo spazio disco utilizzato
e altre informazioni sicuramente utili sullo stato della macchina in questione.

logwatch è entrato nella dotazione software standard che installo su tutte le macchine Linux che amministro.

iOS Bootcamp al TAG di Bergamo

Lascia una risposta

Ieri sera ho partecipato all’incontro “iOS Bootcamp” organizzato dalla community di #pragma mark presso il TAG di Bergamo.
Non era la prima volta che frequentavo il TAG: un luogo dove incontrare giovani startupper e persone interessanti con cui discutere di tecnologia ed innovazione in un ambiente stimolante e creativo.

Era la prima volta, però, che partecipavo ad un talk tecnico presso il TAG. L’organizzazione è stata impeccabile: è stato usato EventBrite per gestire gli inviti ed i tickets di ingresso [il talk non aveva alcun costo], la sala era spaziosa, i tempi rispettati, e la dotazione tecnologica a disposizione ha permesso di seguire il talk in completa autonomia. Essendo un talk prettamente tecnico, la sala si è rapidamente trasformata in un covo di nerds, ma rispetto ad altre conferenze non ci sono stati incidenti.

Incontravo la community di pragma mark e i suoi quattro fondatori: il talk che hanno tenuto ha spaziato lungo tutto l’ecosistema Apple per lo sviluppo di applicazioni iOS e OSX, passando dai provisioning profiles [più croce che delizia per i developers] fino ad arrivare al message-passing tipico di Objective-C [derivante da SmallTalk].
Il talk è stato presentato in maniera logica, chiara e anche divertente: il trivia che spiega come è nato il nome della community è stato un piacevole break.
I presentatori sono stati molto disponibili: nella parte di Q&A ho posto alcune domande su ARC e manual memory management e le risposte sono state molto esaustive e chiare.

L’impressione che ho avuto, quindi, è molto positiva: sicuramente parteciperò ai prossimi talk organizzati da #pragma mark presso il TAG, e ho già sottoscritto il feed RSS dei rispettivi blog.

sshuttle: creiamo una VPN (via transparent proxy) con SSH

Lascia una risposta

In passato vi ho spiegato come creare un tunnel SSH per poter “tunnelizzare” il traffico Internet usando da tramite un server che esponeva il demone sshd. La scomodità di questa soluzione risiede nell’ultimo passo: dobbiamo impostare un tunnel SOCKS per ogni programma di cui vogliamo tunnelizzare il traffico. Ok, questo può non essere una scomodità vera e propria, tuttavia: per esempio, vogliamo tunnelizzare solo il traffico del browser [pensiamo di trovarci in una rete pubblica], mentre il traffico SSH [già cifrato] non ha bisogno di essere tunnelizzato.

Oggi facciamo un passo oltre: vogliamo sfruttare la connessione SSH che abbiamo per tunnelizzare  tutto il traffico attraverso SSH. Questo è equivalente a creare una VPN con il server remoto, ma l’unica differenza importante è che non si creano interfacce di rete aggiuntive!

Di conseguenza, l’host locale (che chiamiamo client) instaurerà una connessione SSH verso il server che si assumerà la responsabilità di instaurare la connessione verso gli altri host e di fare da “passacarte” verso il client. La configurazione è molto utile nel caso in cui il client si trovi ad utilizzare una rete pubblica non sicura (pensiamo ad esempio a Starbucks) ma allo stesso tempo voglia che tutto il traffico sia cifrato per evitare problemi di sniffing.

Il software che ci permette di costruire la VPN (vi ricordo che non è a tutti gli effetti una VPN, anche se ne si hanno tutti i benefici) è sshuttle, disponibile per Linux e OSX.

Una volta installato solo sul client (lo trovate nei repo di Ubuntu e in homebrew), vi consiglio di configurarlo per fare il forward di tutto il traffico (comprese le richieste DNS) nel seguente modo:

./sshuttle --dns -vvr username@sshserver 0/0

[Nota: 0/0 è uno shortcut per 0.0.0.0 - se volete modificarlo per fare selective routing verso il tunnel di una particolare subnet, sapete cosa dovete modificare ;)]

Per i più curiosi, ecco una piccola spiegazione di cosa c’è under the hood di sshuttle.

Tutte le novità di Java 7

Lascia una risposta

A metà 2011 è stata rilasciata la versione 7 di Java [nickname Dolphin].
Due sono le grandi novità di questo rilascio:

  • Java è ora marchiata Oracle (che ha acquisito Sun)
  • La reference implementation è ora OpenJDK (l’implementazione open-source di Java), mentre per le passate versioni rimane HotSpot, la versione di Sun Oracle.

Le novità più interessanti, dal punto di vista delle API, sono:

  • Una (nuova) versione delle API NIO 2 per la gestione e la navigazione del file-system (come ad esempio: Path, Files)
  • Supporto al multiprocessing (ForkJoinTask / RecursiveTask)
  • La possibilità di usare instanze di String come argomento di switch: 
    switch (s) {
case "foo": break;
case "bar": break;
case "foobar": System.out.println("it's foobar!");
}
  • Catturare diversi tipi di Exception con una sola catch [separando le Exception con un '|']: 
    try {
FileInputStream fi = new FileInputStream("foo.txt");
}
catch(FileNotFoundException | IoException e) {
log.error("error: not found or I/O Exception");
}
  • try-with-resource [Automatic Resource Management]: dentro ai blocchi try/catch/finally si rimanda la chiusura degli stream/connessioni al finally. Grazie a try-with-resource è la stessa JVM che si occupa di fare ordine con le risorse utilizzate al termine del blocco. 
    try (FileOutputStream fos = new FileOutputStream(f)) {
fos.write(buf, 0, len);
}
catch (Exception e) {
log.error(e);
}
  • Diamond operator (solo sintassi, evitiamo la ripetizione della classe usando i Generics): 
    List<String> foobar = new ArrayList<>();
  • Leggibilità dei valori numerici (specifichiamo un separatore ‘_’): 
    long accountNumber = 1234_5678_9012L;
  • JDBC 4.1 (Annotazioni @Select e @Update per definire le query, DataSet sostituisce ResultSet)

Convertire una macchina fisica in una virtuale: VMware vCenter Converter

Lascia una risposta

Ho recentemente convertito due macchine fisiche Windows in macchine virtuali (per questioni di manutenibilità) con un tool gratuito messo a disposizione da VMware: VMware vCenter Converter.

Una volta installato si occupa di fare un’immagine virtuale di tutto il contenuto dell’hard disk (comprese eventuali partizioni), creando una macchina virtuale (compatibile con VMware e con Oracle VirtualBox).

Non ho ancora provato a virtualizzare una macchina Linux (mi sono affidato a clonezilla), ma VMware supporta anche la conversione di Linux da fisico a virtuale.

zsh: perché non utilizzo bash

2 Repliche

Su tutte le macchine Linux e OSX che amministro non uso come shell di default la bash; uso invece zsh, perché:

  • zsh si offre di completare anche le opzioni e i parametri dei programmi più usati;
  • zsh fa spelling correction dei comandi digitati, chiedendo interattivamente se volete correggere il comando;
  • zsh offre una customizzazione più spinta della bash (vedremo tra poco il mio prompt);
  • zsh condivide la history tra più sessioni attive contemporaneamente;
  • zsh è già installata, di default, su OSX (ed è nei repo di Ubuntu, percui basta un aptitude install zsh).

Se questi vantaggi non dovrebbero bastare, ecco il mio prompt:

oh my zsh prompt 150x150 zsh: perché non utilizzo bash

Ho scritto un tema ad-hoc, che funziona grazie a oh-my-zsh (un framework di customizzazione per zsh, che consiglio vivamente!). Cos’ha di speciale il mio prompt rispetto ad una semplice bash?

  • Colorazione diversa del prompt se siamo rootoh my zsh prompt root 150x150 zsh: perché non utilizzo bash
  • Colorazione del prompt in base all’esito positivo o negativo dell’ultimo comando utilizzatooh my zsh lastret color 150x150 zsh: perché non utilizzo bash
  • Visualizzazione dello stato del repo git della directory attuale: branch + status (modifiche unstaged?)oh my zsh git 150x150 zsh: perché non utilizzo bash

Ho caricato su github i due temi che ho creato per oh-my-zsh: michelebologna.zsh-theme è quello mostrato in questi screenshot. Ovviamente, prima dovete installare oh-my-zsh. Feedback benvenuti!

HTTPS e le applicazioni di terze parti: attenzione!

Lascia una risposta

“È sufficiente usare HTTPS per essere sicuri: protegge la comunicazione cifrando il traffico e usando certificati validati da CA riconosciute”.

SBAGLIATO. Spesso si sente pronunciare questa frase, ma non è del tutto vero: ho recentemente letto con molta attenzione un paper presentato alla conferenza CCS 2012, una conferenza dedicata alla Computer Security. Il paper ha un titolo curioso: “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software“.

Si parla di HTTPS/SSL in contesti in cui è richiesta una comunicazione cifrata tra due sistemi (trasmissione di dati sensibili); distinguiamo due tecnologie lato end-user per accedere a sistemi HTTPS: un browser (accediamo, per esempio, ad un sito di e-commerce e facciamo il checkout in modalità protetta) oppure un’applicazione 3rd party (per esempio, lo stesso sito di e-commerce tramite un’app dedicata a smartphone/tablets).

Bene: i browser non sono in discussione e non risentono dei problemi presentati nel paper. Invece, le libraries SSL (due nomi su tutti: OpenSSL e JSSE) che solitamente vengono utilizzate nei back-end o utilizzate dagli sviluppatori per costruire applicazioni che accedono a risorse tramite HTTPS soffrono di alcuni problemi che rendono l’intera comunicazione vulnerabile a diversi tipi di attacchi, come il famoso man-in-the-middle. In breve, il problema principale è il processo di validazione dei certificati SSL (solitamente: si risale la chain fino alla root CA). Se lato client non viene effettivamente fatta la validazione del certificato presentato dal server, il client è una facile preda! Questa non-validazione è causata da molteplici fattori:

  • pigrizia dei developers che, nell’utilizzare queste librerie, disabilitano controlli fondamentali durante la fase di sviluppo (perché si usano dei certificati self-signed) che poi dovrebbero essere riabilitati al go-live. Ma così non accade;
  • utilizzo sbagliato delle API che settano impostazioni non congruenti (setto il check per la verifica del certificato ma poi non ricordo/non so/non è specificato che devo leggere un’ulteriore return code per verificare se la validazione è andata a buon fine).

Nel paper sono presenti alcuni esempi interessanti con tanto di codice reverse engineered.

Quali sono i rimedi?

  • Come sviluppatori: configurare correttamente i parametri di validazione SSL della libreria che si usa, controllando anche i valori di ritorno della validazione se devono essere richiamati tramite un’ulteriore chiamata alle API della library utilizzata
  • Come sviluppatori: fare sempre un testing utilizzando certificati SSL non verificati.

La lettura del paper è davvero molto interessante ed è vivamente consigliata per tutti quelli che hanno a che fare con lo sviluppo di applicazioni 3rd party che accedono a risorse esposte tramite HTTPS/SSL.

FizzBuzz reloaded: le differenze tra Java e Ruby

2 Repliche

Tempo fa vi ho parlato di FizzBuzz, un quiz spesso posto ai programmatori alle prime armi.

Una variante è la seguente:

Sommare tutti i numeri da 1 a 200 che non sono multipli di 4 e di 7

La parte divertente sta nella differenza di espressività tra Java e Ruby per ottenere lo stesso risultato. In Java, infatti:

public class FizzBuzzReloaded {
	public static void main(String[] args) {
		int sum = 0;
 
		for (int i = 1; i <= 200; i++) {
			if (i % 4 != 0 && i % 7 != 0) {
                             sum += i;
			}
		}
		System.out.println(sum);
	}
}

In Ruby, invece, grazie alla funzionalità del linguaggio, possiamo semplicemente scrivere:

(1..200).select {|n| n % 4 != 0 and n % 7 != 0}.inject(:+)

OSX: come aggiungere un separatore tra gli elementi della Dock

Lascia una risposta

Ultimamente ho fatto ordine tra gli elementi che compongono la mia Dock (che potete vedere qui accanto).
dock1 45x150 OSX: come aggiungere un separatore tra gli elementi della Dock
Per separare logicamente le applicazioni che compongono la Dock, ho deciso di introdurre alcuni elementi “separatori” (degli spazi vuoti) tra le applicazioni. In questo modo è più facile distinguere tra il gruppo di applicazioni che servono a svolgere un determinato task da un altro.
Come si aggiunge il separatore?
Aprite un terminale e digitate:
defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="spacer-tile";}'; killall Dock
All’ultima posizione della vostra Dock verrà aggiunto un separatore che potrete spostare come un’applicazione.
Per rimuovere il separatore è sufficiente trascinarlo fuori dalla Dock, come una normale applicazione.

Formattare i decimali con Python

Lascia una risposta

Un problema che ho recentemente risolto usando Python e la logica binaria prevedeva di stampare i numeri binari usando lo stesso numero di cifre [ad esempio: nel caso di 8 bit, stampare le parole di 4 bit anteponendo zero per quattro volte]. Tecnicamente, gli zero a sinistra sono ininfluenti ma servono per uniformare la formattazione, e in gergo sono chiamati leading zeros.
Questo ragionamento non vale solo per i numeri in binario, ma per tutti i casi in cui si vuole formattare l’output di Python.

Veniamo al codice. Si può formattare la stringa tramite format, specificando il numero di leading zeros.
Esempio:

for i in range(1,101,1):
	print(format(i, "03d"))

In questo caso vengono stampati i numeri usando 3 cifre: si parte quindi da 000 e si arriva a 100. E in più, abbiamo usato una sintassi già compatibile con Python3.