Category: linux

  • Hardening services: let’s review our config files

    It’s hardening Sunday here: I reviewed the config files of my main daemons (nginx, openvpn, tinc, sshd) with the help of two resources that I want to share with you, fellow readers.

    First of all, a guide dedicated exclusively to hardening ssh: from using public key authentication only (I strictly encourage it!) to the selection of which ciphers ssh should use (there is theory behind, so read it!).

    The second guide, is a guide for hardening all services, from web servers to VPN concentrators (divided by vendor): a worth reading guide. Every option is very well detailed and discussed, for all you nitpickers like me.

    So, take aside 2 hours, read the theory, then adopt the changes you think would benefit your setup. Happy hardening!

    Update: if you are using OSX, do not use default ssh toolset that ships with OSX: it is not updated and it does not have ssh-copy-id to distribute your public key among your ssh servers. More that that, OSX default ssh does not support ecdsa which is the main crypto algorithm that the linked guides are using.
    Solution: brew install homebrew/dupes/openssh and adjust your PATH accordingly.

  • HP 6730b and fan at full speed after suspend (Fedora, Ubuntu, openSUSE)

    It seems that with kernels 3.9 onwards there are some issues with fan speed and the 6730b model of HP notebook. I tried with Fedora 22 (my main distribution of choice), openSUSE Tumbleweed and Ubuntu 15.04.

    The problem occurs only when the system is woken up after a sleep/suspend: fans spin at full speed indefinitely, without resort (apart from reboot/shutdown). This is a problem with ACPI. In order to solve this problem, if you’re using Fedora like me, create the file /etc/pm/sleep.d/99fancontrol.sh and fill it with the following:

    case "$1" in
    hibernate|suspend)
    # Stopping is not required.
    ;;
    thaw|resume)
    # In background.
    ls /sys/devices/virtual/thermal/cooling_device*/cur_state | while read A; do echo 1 > $A; echo 0 > $A; done
    ;;
    *) exit $NA
    ;;
    esac

    and of, course, set it executable with chmod +x.

    It basically flips on and off the current state of the cooling devices: with this script you won’t have the noisy fans at full speed on resume.

  • Ubuntu rcS – variabili per modificare il comportamento degli script di boot

    Quando mi trovo a dover fare il setup di un nuovo server, cambio sempre una variabile nel file /etc/default/rcS, ovvero:

    FSCKFIX=yes

    che significa che, in caso di problemi durante il mount dei filesystem al boot, il sistema tenta automaticamente di riparare il file-system, senza interrompere il processo di boot invocando la shell come avviene nel caso default (FCSFIX=no).

    Ubuntu Manpage: rcS – variables that affect the behavior of boot scripts.

  • Xubuntu/XFCE: come avviare una sessione in VNC

    Di recente ho dovuto avviare una sessione VNC su una macchina remota; la mia preferenza per un desktop environment “light” ma al tempo stesso completo è andata su XFCE (installato di default su Xubuntu).

    Per avviare una sessione VNC è necessario modificare il file posto nella vostra home, e più precisamente in ~/.vnc/xstartup. Il file deve essere strutturato come segue (nel mio caso ho dovuto inserire soltanto le ultime due righe):

    #!/bin/sh

    Uncomment the following two lines for normal desktop:

    #unset SESSION_MANAGER
    #exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    xsetroot -solid grey
    vncconfig -iconic &
    x-terminal-emulator -geometry 80×24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    x-window-manager &
    startxfce4 &
    exec /usr/bin/xfce4-session &

  • Installazione e configurazione di Logwatch su Ubuntu

    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: michele@bologna.com

    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

    logwatch2

     

     

     

     

    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.

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

    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.

  • zsh: perché non utilizzo bash

    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:

    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 root
    • Colorazione del prompt in base all’esito positivo o negativo dell’ultimo comando utilizzato
    • Visualizzazione dello stato del repo git della directory attuale: branch + status (modifiche unstaged?)

    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!

  • Installare ed utilizzare Mosh (mobile-shell) su Ubuntu e MacOSX

    Per le sessioni semi-perpetue di ssh che contraddistinguono il mio setup, utilizzo una combinazione di autossh e tmux/screen (wrappato da byobu). Ultimamente ho scoperto mobile-shell (Mosh): proveniente dal MIT, si tratta di un ssh killer perché, a differenza di ssh:

    • ristabilisce automaticamente la connessione dopo un certo timeout (problema risolto in precedenza da autossh);
    • utilizza un eco locale (addio lag ssh su connessioni lente!);
    • mosh e mosh-server possono essere avviati da utenti non privilegiati
    • supporta solo UTF-8!

    Da Ubuntu 12.04, mosh è presente nei repo ufficiali di Ubuntu (per le versioni precedenti, è presente anche un ppa). Per MacOSX, si può usare compilare il pacchetto usando homebrew o scaricare il dmg già pronto dal sito di riferimento.

    Provarlo è molto semplice: supponiamo di avere un server Linux e un client MacOSX. Installatelo su Linux tramite apt-get e scaricate il pkg per MacOSX. Una volta installato, per connettersi da MacOSX ho dovuto dichiarare un locale (ho scoperto che, sfortunatamente, MacOSX non dichiara alcun locale). Per cui, controllate il locale in uso sul server remoto e dichiarate lo stesso locale su MacOSX (eventualmente modificate anche il file rc relativo alla vostra shell di riferimento):

    michele@delta:~ % locale                                             
    LANG=
    LC_COLLATE="C"
    LC_CTYPE="C"
    LC_MESSAGES="C"
    LC_MONETARY="C"
    LC_NUMERIC="C"
    LC_TIME="C"
    LC_ALL=
    michele@delta:~ % export LANG="en_US.UTF-8"
    michele@delta:~ % mosh server
  • Evitare riavvii e shutdown remoti su Ubuntu con molly-guard

    Non mi è mai capitato ma potrebbe essere molto utile ai sysadmin più distratti: molly-guard è un pacchetto presente su Ubuntu/Debian che vi permette di evitare un riavvio/shutdown di una macchina remota a cui siete collegati tramite ssh.

    Se, per esempio, tentate di eseguire uno shutdown di una macchina remota a cui siete collegati tramite ssh, molly-guard vi chiede di scrivere per intero l’hostname della macchina che volete riavviare/spegnere.

    Il pacchetto è incluso nei repository ed è molto semplice da installare (basta un apt-get) ed è davvero molto utile: ho provveduto ad installarlo su tutte le macchine che gestisco.

    Per i più curiosi, il nome molly-guard deriva da una “divertente” vicenda.

  • RescueTime: il modo migliore per visualizzare dove “spendiamo” il nostro tempo

    RescueTime: il modo migliore per visualizzare dove “spendiamo” il nostro tempo

    Ricordarsi dove si “spende” la maggior parte del proprio tempo al computer è un’attività davvero difficile, soprattutto per chi con i computer ci lavora! Proprio per questo motivo ci viene in aiuto RescueTime: una volta installato vi verrà proposto di installare un programma che se ne starà in background e che monitorerà non invasivamente quello che fate al vostro computer, per produrre poi un report delle attività che svolgete al vostro computer, contabilizzando le ore che spendete in ogni applicazione; il tutto, automaticamente!

    Una volta installato, RescueTime vi fa alcune semplici domande per capire quali sono, a vostro giudizio, i programmi che ritenete più produttivi e quali, invece, perdite di tempo. Ogni volta che RescueTime vi invierà un report delle vostre attività, con dei semplici e chiari grafici come quello qui sopra, vi dirà se siete stati produttivi o meno proprio secondo le regole che voi stessi avete dichiarato.

    Come funziona? Dopo un po’ di investigazione, ho scoperto che RescueTime memorizza solamente il titolo dell’applicazione in foreground e per quanto tempo viene utilizzata (per il browser: anche il sito visitato). Questi sono i dati memorizzati da RescueTime, per cui, se siete preoccupati per la vostra privacy, potete decidere in autonomia se installare RescueTime.

    In generale trovo RescueTime davvero utile, proprio perché mi aiuta a capire dove spendo la maggior parte del mio tempo e, nel caso in cui le attività siano distrazioni, a potermi meglio regolare in futuro. Inoltre, funziona anche come un pratico “cronometro” per progetti: spesso mi aiuta a capire qual è l’elapsed vero di un progetto a cui sto lavorando.

    RescueTime è gratuito nella versione base per Windows, Linux e MacOSX ed offre anche una versione a pagamento che vi offre informazioni ancora più dettagliate e alcune funzionalità per restare nella “zone” bloccando le attività che vi distraggono.