Tag: email

  • Si trova proprio di tutto

    Abbiamo trattato varie volte il problema dei motori di ricerca che indicizzano più di quello che ci si aspetta.

    Con la formula corretta si possono trovare varie cose: chiavi private, log di trasferimenti FTP, chiavi o configurazioni dei VPN, telecamere

    Aggiungiamo questa messe di informazioni un esempio di come sia possibile cercare dei fogli di Excel il cui none finisce con la parola email:

    filetype:xls inurl:"email.xls"

    Il risultato è interessante e potrebbe essere una delle tante possibili risposte alla domanda “Ma da dove diavolo hanno preso la mia mail?!”

    Mutatis mutandis, si potrebbero cercare documenti che contengono altre parole nel nome.

    Chi ha detto “password”?

    inurl:elmah.axd "powered by elmah" password

  • Mail server in IPv6

    Questo articolo spiega come passare in IPv6 un mail server Linux con Postfix, Amavisd-new e Dovecot.

    Il sistema di partenza è un Linux con il dual stack IPv4/IPv6 attivo e funzionante con un indirizzo pubblico IPv4 e uno IPv6. Anche il sistema di posta elettronica è perfettamente funzionante in IPv4 con le ultime versioni dei programmi indicati sopra installati da sorgente, non da pacchetto della distribuzione Linux. Ciò perché con IPv6 è sempre meglio avere le ultime versioni, anche se la maggior parte delle istruzioni che seguono dovrebbero funzionare anche con le versioni distribuite nei pacchetti standard.

    Continua a leggere
  • Reset della password

    Per vari motivi ho cercato in giro alcune linee guida su come scrivere una buona procedura di reset della password di un account via posta elettronica, ne riassumo qui alcune, in ordine sparso.

    Non modificare i dati fino alla conferma dell’utente. A meno di necessità specifiche o casi particolari, i dati di autenticazione non devono essere modificati fino all’avvenuta conferma da parte dell’utente, al fine di impedire che buontemponi blocchino l’accesso all’utente semplicemente chiedendo un reset della password.

    Usare CAPTCHA. La pagina di richiesta del reset della password dovrebbe contenere un CAPTCHA per evitare che i sistemi automatici possano attaccare facilmente il sistema oppure possano provocare disagi a più utenti.

    Utilizzare una buona fonte di entropia. L’URL per il reset della password inviato via mail deve contenere una parte casuale, che non deve essere legata al timestamp o ad altri valori deterministici. È bene utilizzare sempre il generatore di numeri casuali disponibile sul sistema (/dev/urandom per *NIX) anziché una funzione di libreria del linguaggio.

    Limite di tempo. L’URL utilizzabile per il reset della password deve avere una scadenza oltre la quale non è più valido.

    Spiegare bene. Sia la pagina di reset della password sia le mail che vengono inviare all’utente devono essere ben chiare e spiegare bene la modalità di reset. In particolare, la mail deve indicare in maniera precisa il nome del sito di cui si sta reimpostando la password, il termine ultimo di validità e le azioni da intraprendere se chi riceve la mail non ha chiesto il reset della password.

    Confermare. Una volta terminata (o cancellata) l’operazione, è bene inviare una seconda mail di conferma all’utente.

    Monitorare. Una funziona amministrativa dovrebbe segnalare gli account di cui viene richiesta spesso la reimpostazione della password. Inoltre è bene impedire un numero non-umano di richieste di reset della password nell’unità di tempo, come, ad esempio, 500 richieste all’ora.

    HTTPS. Se possibile, utilizzare HTTPS con un certificato valido per il form di richiesta di reset e per l’URL di sblocco.

    Cookie. Non devono essere utilizzati i cookie per identificare l’utente ed eventuali cookie di sessione o di identificazione devono essere cancellati nel momento in cui la password viene reimpostata.

    Riservatezza. Se nel form di richiesta password si richiede direttamente la mail (da evitare, se possibile), quando viene inserita una mail sconosciuta, il programma deve comportarsi allo stesso modo in cui si comporterebbe se la mail fosse di un utente registrato, al fine di impedire ad un eventuale curioso o attaccante di capire se una mail corrisponde ad utente effettivamente registrato.

    Va da sé che queste sono linee guida che si applicano a siti normali, per ambienti che richiedono una sicurezza maggiore devono essere messe in campo procedure completamente diverse.

  • Bloccare le conferme di lettura con Postfix

    Alcune organizzazioni vogliono impedire che vengano inoltrate le conferme di lettura dei messaggi.

    Con Postfix questo blocco si attua attraverso la funzione header_checks. Nel file main.cf si specifica qualcosa tipo

    header_checks = regexp:/etc/postfix/header_checks

    La distribuzione standard di Postfix contiene un file header_checks senza direttive ma con alcune istruzioni sommarie nei commenti.

    Tenendo presente che le conferme di recapito hanno generalmente tra gli header la direttiva MIME che indica che il contenuto è di tipo Multipart/Report (RFC6522), è sufficiente aggiungere una riga di questo tipo a /etc/postfix/header_checks

    /^Content-type: Multipart\/report/   DISCARD

    Il file va quindi compilato con

    postmap /etc/postfix/header_checks

    e alla fine si ricarica Postfix per attivare la configurazione.

  • Archiviazione della posta elettronica

    È fuori discussione che l’archiviazione della posta elettronica sia una necessità e, alcune volte, un obbligo.

    Il SysAdmin deve risolvere in un modo o in un altro questa necessità degli utenti, senza decidere ex auctoritate che si tratta di un vezzo o della conseguenza della pigrizia di chi utilizza la mail. Nella posta elettronica ci sono le tracce con riferimenti temporali delle interazioni con clienti o fornitori esterni e alcune volte c’è la storia evolutiva di un’organizzazione.

    (altro…)
  • Rubare un account di Google con il cellulare

    Negli USA ci sono campagne basate sul social engineering in cui si cerca di rubare gli account di Gmail utilizzando la funzione di conferma via SMS.

    Una delle opzioni offerte da Gmail in caso di perdita della password è l’invio di un codice di verifica ad un numero cellulare fornito in precedenza, se un attaccante conosce l’account di Gmail e utilizza metodi di social engineering per carpire il codice inviato, il gioco è fatto.

    Ecco un esempio di come sia possibile un sistema del genere.

    (altro…)
  • Email privacy tester

    Mike Cardwell ha aggiornato il suo email privacy tester.

    Si tratta di un sito che ospita un’applicazione (i cui sorgenti sono disponibili) per verificare quando un client di posta elettronica riveli a terzi.

    Un normale messaggio di posta elettronica senza oggetti incorporati o richieste di conferme non può rivelare molto perché l’azione di apertura del messaggio da parte del client di posta elettronica (Outlook, Thunderbird, un webmail o altro) non comporta alcuna interazione aggiuntive con Internet che non sia l’atto di scaricare il messaggio stesso, azione che avviene con il proprio mail server, senza che il mittente abbia traccia di alcunché.

    (altro…)
  • PEC, firme, certificati…

    Oramai ci siamo: tutte le aziende costituite in forma societaria devono dotarsi di un indirizzo PEC entro martedì 29 novembre p.v.

    Nell’ultimo mese ho, però, notato che c’è molta confusione in merito al valore probatorio della PEC; le improvvide affermazioni esternate qualche tempo fa da qualche (ora ex) Ministro della Repubblica in qualche trasmissione televisiva non hanno fatto che peggiorare la situazione, dal momento che qualcuno ha dato valore di legge a quelle affermazioni tirate a caso.

    (altro…)
  • Blackberry e sistemi complessi

    Ieri molti server di RIM sono finiti a gambe all’aria lasciando milioni di possessori di BlackBerry senza servizi Internet.

    Molti operatori hanno avvisato i loro clienti via Twitter e mi risulta che Vodafone Italia abbia inviato anche un SMS (se il BlackBerry non va su Internet difficilmente l’utente apprende la notizia via Twitter).

    In questo caso la tecnologia su cui si basa la rete di BlackBerry ha mostrato il suo punto debole: va giù un data centre a causa di un aggiornamento andato male e i BlackBerry della zona EMEA tornano ad essere dei semplici telefoni cellulari.

    Questo perché tutte le comunicazioni dati dei terminali mobili avvengono in maniera criptata tramite dei data centre di RIM. Quando viene configurato un account di posta su un BlackBerry, sono i server di RIM a scaricare la posta dal server, o a riceverla tramite BES, e ad inviarla al terminale.

    Queste feature sono comode in alcune situazioni e l’uso del BES torna utile nelle aziende sia per la possibilità di impostare delle policy che limitano l’abuso del terminale, sia per la possibilità di cancellare da remoto un terminale connesso alla rete cellulare senza dover passare tramite il call centre del provider di telefonia.

    Ma l’utente home o anche SOHO ha davvero bisogno di un dialogo crittografato con RIM? Non è sufficiente una connessione IMAPS anche con un certificato auto generato? In questo modo si toglie una variabile dall’equazione e la si rende più semplice.

    Tantopiù  che il protocollo del BlackBerry non è un protocollo di sincronizzazione, ma di aggiornamento a coda di transazioni. Il che significa che se il vostro terminale si perde gli aggiornamenti che spedisce RIM, quei dati non li vedrete mai sul telefono.