Tag: security

  • Ubuntu: Apache2 con certificati self-signed e senza password all’avvio

    Recentemente mi è capitato di dover installare apache [in particolare, apache2] su una macchina Ubuntu. In particolare, mi è stato chiesto di installare la versione con ssl, ovvero che implementa il protocollo cifrato https.

    Apache2+ssl richiede l’utilizzo di un certificato firmato da un’autorità [es. Thawte, Verisign, etc.]. Se non vogliamo pagare una CA per ottenere un certificato firmato, possiamo generare un certificato firmato da noi stessi. Tuttavia, seguendo molte delle guide che si trovano in rete, apache viene installato con l’opzione ssl ma ogni volta che viene avviato richiede la password per l’utilizzo del certificato.

    Per questo riporterò qui una guida passo-passo che fa in modo che Apache2 non richieda la password per l’utilizzo del certificato: questa procedura è consigliata solamente se l’utilizzo è volto al testing o allo sviluppo. Qualsiasi altro uso è sconsigliato [richiedere una password per l’utilizzo del certificato è più che normale].

    • Abilitate il modulo ssl per apache2: sudo a2enmod ssl
    • Generiamo il certificato: cd /tmp; sudo openssl req -new > new.cert.csr
    • Vi verranno chieste delle informazioni a scopo puramente informativo e che compariranno nel certificato. Riempite le varie informazioni come credete
    • Ed ora una serie di comandi per generare tutti i file richiesti dai certificati: sudo openssl rsa -in privkey.pem -out new.cert.key
      sudo openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 1825
      sudo cp new.cert.cert /etc/ssl/certs/server.crt
      sudo cp new.cert.key /etc/ssl/private/server.key
    • Ora abilitiamo l’utilizzo dei certificati appena generati:sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl
    • Modificate il file /etc/apache2/sites-available/default con il vostro editor preferito, ad esempio vi: sudo vi /etc/apache2/sites-available/default e cambiate le seguenti linee:
      Cambiare da…A…
      NameVirtualHost: *NameVirtualHost: *:80
      <VirtualHost *><VirtualHost *:80>
    • Modificate ora il file /etc/apache2/sites-available/ssl sempre con il vostro editor preferito e cambiate le seguenti linee:
      Cambiare da…A…
      NameVirtualHost: *NameVirtualHost: *:443
      <VirtualHost *><VirtualHost *>

      Dopo la linea che contiene DocumentRoot, aggiungete le seguenti righe:

      SSLEngine on
      SSLOptions +StrictRequire
      SSLCertificateFile /etc/ssl/certs/server.crt
      SSLCertificateKeyFile /etc/ssl/private/server.key
      
    • Ora date il seguente comando per abilitare l’utilizzo dei certificati in apache2: sudo a2ensite ssl
    • Infine riavviate Apache2 e finalmente non chiederà più la password del certificato: sudo /etc/init.d/apache2 restart

    Nota: se avete problemi controllate che il vostro file /etc/hosts sia fatto in questo modo:

    127.0.0.1 localhost localhost.localdomain {il vostro hostname}
    127.0.1.1 {il vostro hostname}
    {IP statico se ne avete uno} {DNS fully qualified se ne avete uno}
  • Come impostare ssh in modo che non richieda la password di accesso (chiavi asimmetriche per il login)

    Alcuni client ssh permettono di definire “sessioni salvate” di connessioni in modo che username e password vengano salvati e non vengano richiesti ad ogni connessione verso un host. Trovo che permettere all’utente di poter salvare la password sia profondamente sbagliato dal punto di vista della security, soprattutto se l’utente ha privilegi non indifferenti sulla macchina remota [ad esempio è nei sudoers].

    Detto questo, trovo anche che sia abbastanza noioso inserire la propria password ad ogni connessione. Ma non disperate: il meccanismo standard per risparmiarvi preziosi secondi esiste e ve lo spiegherò tra poco. Inoltre, il meccanismo standard è sicuro di per sé e non indebolisce la struttura di ssh perché utilizza un’autenticazione basata sulla crittografia asimmetrica.

    Innanzitutto: queste istruzioni sono per Linux e OSX. In futuro posterò anche le istruzioni per Windows/PuTTY.

    Obiettivo: loggarsi dalla macchina locale (local) alla macchina remota (remote) senza inserire la password

    Sulla macchina locale: generare le chiavi di autenticazione [1/2]

    Le chiavi di autenticazione sono composte da 2 chiavi, una pubblica e una privata. La chiave pubblica rappresenta la nostra identità nel mondo esterno. La chiave privata, invece, rappresenta la nostra chiave segreta, la nostra “password” [anche se è molto più lunga di una password].

    Per generare le chiavi bisogna dare questo comando:
    local$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/mbologna/.ssh/id_rsa):

    Accettate il path che vi viene proposto premendo Invio
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:

    Vi consiglio fortemente di inserire una password a questo punto. Nonostante molte persone consiglino (sbagliando) di non inserire una password perché si ripeterebbe il problema di dover inserire una password, vi posso assicurare che impostare un ulteriore livello di sicurezza per poter accedere ad un file così delicato come la vostra chiave privata è più che consigliato [e per sfatare un falso mito: non è vero che bisogna reinserire la password, basta affidarsi a un’implementazione sicura di ssh-agent].

    Ora controllate che effettivamente il comando abbia creato le vostre chiavi:

    local$ ls -la .ssh/
    drwx------  2 mbologna mbologna   4096 2009-09-24 18:43 .
    drwx------ 55 mbologna mbologna   4096 2009-11-13 00:42 ..
    -rwx------  1 mbologna mbologna   1743 2009-08-04 16:52 id_rsa
    -rwx------  1 mbologna mbologna    433 2009-08-04 16:52 id_rsa.pub

    id_rsa contiene la vostra chiave privata, mentre id_rsa.pub contiene la vostra chiave pubblica.

    Sulla macchina remota: autorizzare l’autenticazione tramite chiave pubblica [2/2]

    Loggatevi sulla macchina remota inserendo la vostra password [per l’ultima volta :)]:

    local$ ssh username@remote
    A questo punto seguite i seguenti passi:

    • create una directory .ssh nella vostra home mkdir .ssh
    • impostate i permessi appropriati chmod 700 .ssh
    • spostatevi nella directory .ssh cd .ssh
    • create un file chiamato authorized_keys touch authorized_keys
    • impostate i permessi approppriati chmod 600 authorized keys
    • aprite il file authorized_keys con il vostro editor preferito [ad esempio vi] vi authorized_keys
    • copiate e incollate il contenuto del file ~/.ssh/id_rsa.pub presente su local nel file authorized_keys
    • fate un logout

    Abbiamo finito! Ora potete semplicemente loggarvi sulla macchina remote semplicemente con ssh username@remote

    Nota: se non volete digitare la password ogni volta che accedete alla vostra chiave privata, date un’occhiata a ssh-agent.

  • Ubuntu e Debian: come aggiornare automaticamente i pacchetti installati (unattended-upgrades)

    Nella vita di un sistemista esiste un task piuttosto ripetitivo: ovvero quello di aggiornare i pacchetti (= gli applicativi) installati sul proprio sistema (vuoi perché le versioni recenti dello stesso software dovrebbero essere migliori, più performanti e al riparo dagli ultimi bug di security, etc.).

    Nel caso di un sistemista alle prese con un sistema Ubuntu (o Debian), il task [da eseguire ripetutamente] si riduce a:
    apt-get update
    apt-get dist-upgrade

    (o comunque equivalente se usate aptitude).

    Ora, per evitare di ripetere il task, i sistemi Ubuntu/Debian mettono a disposizione unattended-upgrades: una volta installato il pacchetto, il sistema provvederà ad aggiornare e installare automaticamente tutte le applicazioni installate nel sistema. Vediamo come installare e configurare passo-passo unattended-upgrades:

    1. apriamo un terminale e installiamo il pacchetto unattended-upgrades: apt-get install unattended-upgrades update-notifier-common
    2. editiamo il file /etc/apt/apt.conf.d/50unattended-upgrades in questo modo:

      Automatically upgrade packages from these (origin, archive) pairs
      Unattended-Upgrade::Allowed-Origins {
      "Ubuntu hardy-security";
      "Ubuntu hardy-updates";
      };

    3. editiamo il file /etc/apt/apt.conf.d/10periodic in questo modo:

      APT::Periodic::Update-Package-Lists "1";
      APT::Periodic::Download-Upgradeable-Packages "1";
      APT::Periodic::AutocleanInterval "1";
      APT::Periodic::Unattended-Upgrade "1";

    A questo punto i pacchetti installati nel sistema verranno aggiornati automaticamente.

    Nota: è sempre opportuno controllare i log degli aggiornamenti per evitare eventuali problemi. I log degli aggiornamenti si possono trovare, ovviamente, in /var/log/unattended-upgrades

  • Ecco perché anche gli utenti di OSX hanno bisogno di un antivirus

    Di solito gli utenti Mac non installano un antivirus perché si crede che il sistema operativo OSX sia esente da virus. Infatti, la giustificazione è quella per cui “su OSX non esistono virus [vedi sito Apple], e se esistessero chiedono comunque la password di sudo/root prima di installarsi; basta non fornire la password a programmi sconosciuti!”.

    Ultimamente ho trovato un interessante articolo da parte di Sophos, la famosa società di sicurezza. In pratica, su un sito (di cui non riporto il link per ovvie ragioni) viene offerta la possibilità ad utenti Windows e Mac (!) di poter scaricare un codec HDTV/DTV. Il codec però si rivela un trojan horse. Ovviamente gli utenti Mac non potranno più utilizzare la giustificazione “basta non fornire la password”, in quanto è l’utente che vuole legittimamente (ed è sua intenzione) installare il codec, quindi fornirà sicuramente la password. Ed ecco che così il computer viene infettato!

    Nel video sottostante potete trovare tutta la descrizione grafica del processo: download, spacchettamento e installazione (bloccata dall’antivirus).


    Apple Mac malware: Caught on camera from Sophos Labs on Vimeo.

  • Scandoo: un modo per scoprire se il proprio sito ha dei link a pagine sospette o infette

    Potrebbe accadere che qualche malintenzionato abbia modificato le pagine del vostro sito/blog per inserire alcuni link nascosti a pagine sospette o a pagine che contengono del malware. In questi casi i motori di ricerca penalizzano fortemente la vostra pagina web, sia per problemi di posizionamento (le pagine sospette non sono mai ben viste, anche se si tratta solo di un link) sia per problemi di security per i visitatori (un motore di ricerca che consiglia pagina contenenti del malware non è affidabile).image

    Per evitare di incorrere in questi problemi, si utilizza Scandoo, un wrapper di ricerca attorno a Google che permette di capire se i link di destinazione presenti in una pagina sono sospetti o meno. Per testare il vostro sito, vi basta scrivere "site:vostrosito.com” nella casella di ricerca: Se i risultati contengono tutti segni di spunta verdi, allora il vostro sito non contiene link sospetti. Se invece ottenete una croce rossa o altro, allora il link è sospetto e dovete intervenire.

  • Kevin Mitnick: l’arte dell’inganno e l’arte dell’intrusione

    Sono sempre stato incuriosito da un personaggio quale Kevin Mitnick, per il movimento Free cosaleggoKevin e per le sue idee.

    Ormai due anni or sono, ho letto il primo libro di Mitnick: l’arte dell’inganno (the art of deception). Il libro tratta il tema del social engineering: il tema è interessante, e rivela quanto spesso le persone sono inclini a fornire informazioni sensibili a persone sconosciute (o che forniscono credenziali convincenti). Tuttavia in alcuni punti la lettura è noiosa (ci sono trascrizioni di dialoghi e il dettaglio tecnico è molto basso). In definitiva, leggetelo se vi interessa sapere di più sulle tecniche di social engineering che vengono usate, e come difendersi.

    006Il secondo libro, l’arte dell’intrusione (the art of intrusion): 288 pagine divorate in 6 giorni. Si parla di dettagli tecnici, tecniche di intrusione, storie “gialle”: un mix veramente interessante e che crea dipendenza. I 10 capitoli scorrono veloci, tra slot-machine modificate e intrusioni in banche dati. Alla fine di ogni capitolo, Kevin analizza le tecniche utilizzate e costruisce alcune riflessioni, e spiega come ci si può difendere da questi attacchi. L’ultimo capitolo del libro è dedicato ad un attacco di social  engineering, un caso esemplare da cui trarre insegnamento. Alcune considerazioni:

    • Il libro in alcuni punti è molto tecnico (si parla di RARP, reverse DNS, port knocking): anche se si parla di “racconti gialli”, è meglio avere un buon background tecnico per comprendere al meglio i dettagli di attacco nel corso del libro.
    • La traduzione in italiano, in alcuni punti, è forse un po’ troppo spinta (“token-gettoni”, magari colpa di un traduttore troppo zelante?)
    • Nelle ultime parti del libro si pubblicizza in modo eccessivo il primo libro di Mitnick, l’arte dell’inganno.

    La citazione nella citazione: nel suo libro, Mitnick cita “L’arte della guerra” di Sun Tzu:

    Know thy enemy and thyself, and you will be victorious.

  • Rootkit: cosa sono, perché si usano e come funzionano

    Per il corso di Sicurezza dei Sistemi Informatici, ho realizzato una presentazione che spiega cosa sono i rootkit (in ambito UNIX e GNU/Linux) e come funzionano.

    La presentazione tratta:

    • Che cos’è un rootkit
    • A cosa serve
    • Come funzionano
    • Tipi di rootkit
    • Come difendersi dai rootkit
    • Cosa fare se si è infetti

    Rootkit: cosa sono, perché si usano e come funzionano

    La presentazione si può scaricare da qui.

    Commenti benvenuti!

  • Come generare password sicure e come memorizzarle crittografate per consultarle da qualunque PC

    safepasswd.pngAvete bisogno di generare una password sicura ma non avete un metodo? Vi ricordo che utilizzare la stessa password per account e servizi diversi è considerato insicuro (se la password viene compromessa, tutti i vostri servizi saranno compromessi).

    192×53.png

    SafePasswd può aiutarvi: basta andare sul sito, scegliere la lunghezza della password (personalmente consiglio almeno 10) e generare una password. Premi il pulsante a sinistra per provare!

    A questo punto sorge un problema: come si possono memorizzare le password associate ai vari servizi? (il post-it sul monitor o sulla scrivania non è sicuro).

    clipperz.pngEcco perché esistono servizi quali Clipperz, un online password manager.

    Alcune caratteristiche:

    • per utilizzare la versione online non è necessaria l’installazione di alcun software: le password sono salvate (in modo cifrato) sui servers di Clipperz). In questo modo è possibile accedere alle proprie password da qualsiasi PC, con qualsiasi sistema operativo
    • è anche possibile avere una versione “offline” del database (cifrato) delle password per poterle trasportare, ad esempio, su una chiavetta USB
    • totalmente anonimo: per l’iscrizione non serve un’e-mail: si richiede solo di scegliere username e una frase segreta. Viene precisato che se verrà dimenticata la frase segreta, non si potrà più accedere ai propri dati
    • l’interfaccia è in stile web 2.0 ed è in italiano
    • integrazione con Firefox: attraverso un bookmarklet è possibile effettuare il login automatico ad un sito le cui credenziali di accesso siano memorizzate sul vostro account di Clipperz (qui per maggiori informazioni)
  • Windows Vista è più sicuro di Windows XP?

    Windows Vista è più sicuro di Windows XP?

    Oggi stavo leggendo il blog di Feliciano Intini, che riporta un link ad un report stilato da Jeff Jones.

    Il report riguarda un’analisi dei primi 6 mesi di vita di Windows Vista. In particolare, su questo report troviamo un grafico molto interessante (vedi il post di Feliciano qui).

    Come riporta Feliciano,

    la tabella riportata confronta le vulnerabilità critiche note pubblicamente, distinte in vulnerabilità corrette e non ancora corrette, tra i sistemi operativi Windows Vista, Windows XP, Red Hat Enterprise Linux, Novell SUSE Linux Enterprise Desktop e Mac OS X 10.4 (Tiger), e mostra in modo evidente che Windows Vista è decisamente messo molto meglio sia del suo predecessore, che dei sistemi operativi concorrenti.

    Per altri dati di confronto, vi rimando al report e al blog di Feliciano.

    Per quanto mi riguarda, invece, posso dire che la notizia conferma ciò che mi aspettavo da Windows Vista: è molto più sicuro di XP grazie alle tecnologie introdotte da Microsoft per il suo sviluppo, tra cui (a mio avviso) le principali:

    In definitiva, nonostante quello che si dica in rete e le varie critiche al report, penso che le tecnologie appena citate permettano a Windows Vista di ottenere una maggiore sicurezza rispetto al suo predecessore e Microsoft abbia fatto un notevole passo in avanti sul piano sicurezza: ecco perché, appena possibile, migrerò a Windows Vista.

  • Come controllare se il software installato sul proprio computer è sicuro?

    La società di sicurezza Secunia ci mette a disposizione un ottimo tool, basato su Java, per controllare i programmi installati sul proprio computer. Il controllo ci fornirà un profilo di tutti i programmi installati, consigliandoci di aggiornare (e anche indicando come) i programmi che hanno (o hanno avuto) problemi di sicurezza.

    Ovviamente, bisogna accettare che il plugin acceda al nostro hard disk; il tool si esegue direttamente dal browser, senza bisogno di installare nulla. L’indirizzo a cui trovare il tool è qui.