Re: [ml] mailing lists
On 26/03/14 19:00, Claudio Telmon wrote: Stile fight club. Per le stesse ragioni che Cartwright citava nel suo post sul perché ha deciso di alzare bandiera bianca, più o meno. Hmm, mailing list verticali chiuse ce ne sono sempre state, e anche per buoni motivi, se ho capito a cosa ti riferisci. I primi ambiti che mi vengono in mente sono i CERT e gli antivirus. Non sono il tipo di ml o di tematiche a cui mi riferisco. Non credo neanche che il ragionamento si possa applicare a una lista che si chiama Full Disclosure... nel senso che se una ml fosse disclosure fra un gruppo di amici, professionisti o meno, è un'altra cosa, quanto meno come impostazione etica. IMHO per un sacco di gente la connotazione etica è stata messa da parte quando in questo ambito hanno iniziato ad entrare big vendors e big money... Non è comunque questione di gruppi di amici, quanto di gruppi di lavoro. Si tratti di malware, di botnet, di infrastruttura DNS, di spam filtering, di ..., più o meno ogni argomento ha almeno un suo gruppo chiuso, e quella stessa gente che prima teneva in vita i gruppi aperti ora la trovi lì... Per contro, le ml dell'ietf, che sicuramente sono verticali e non hobbistiche, sono aperte e pubbliche, e riescono a tenere un rapporto segnale/rumore mediamente buono,ma anche perché sono veramente tanto verticali. Vero, ma difficilmente veicolano contenuti che siano ritenuti delicati quanto può essere un exploit che affligge potenzialmente decine di migliaia di sistemi. Nè attirano bimbiminkia smanianti alla prospettiva di farsi un nome mettendo in pratica cose che era meglio tenere sulla carta, o troll in cerca di far casino, o di evangelist di questa o quella azienda, o... Il punto (che intendevo) è proprio quello: chi per determinati argomenti ha un interesse diretto (professionale o personale, non fa differenza) si è ritirato in walled garden con soglie d'accesso sufficientemente alte da tenere fuori quella parte del mondo che (nella loro opinione) creerebbe solamente problemi. Mai detto che prima non ci fossero; ma ora sono di certo aumentate a discapito delle ML aperte. Comunque io mi riferisco a ml dove si discuta tecnicamente come disegnare, realizzare e gestire sistemi informativi sicuri, cosa che dovrebbe interessare più o meno tutte le aziende, e quindi non ha senso che siano ml chiuse, a prescindere dalla definizione di professionale o hobbistico. Chiarisco intanto che non ci vedo niente di male nell'essere hobbisti, nè lo contrappongo all'essere professionisti: io hobbista lo son stato per tanti anni e lo sono ancora in diverse liste e gruppi di lavoro che non ricadono nelle mie dirette competenze professionali. Ma mi interessano e quindi ci son dentro. Dove mi conoscono abbastanza da farmi entrare, almeno. Ciò detto, non sono nemmeno sicuro che liste di quel genere abbiano ancora l'utilità che avevano un tempo: rispetto a 10-15 anni fa non si può certo dire che scarseggi il materiale online al riguardo... Anzi, la mole è talmente elevata che il problema è individuare la soluzione migliore ai propri problemi. Aggiungi l'aumentata mole di fruitori (con livelli di competenza estremamente diversi tra loro) e il risultato (almeno quello che vedo io su quei 4 gruppi che ancora frequento su usenet) è che il grosso delle richieste ricade inevitabilmente nella categoria aiutatemi a debuggare 'sta cosa gratis o ditemi quale è la soluzione alle mie esigenze. Se ci metti che almeno una parte dei frequentatori (tipicamente quella più utile alla lista stessa, in termini di esperienza e competenza portata) si ritrova a fare 'sto genere di consulenza per mestiere, per 10-12 ore al giorno, è inevitabile che l'interesse di questi cali e che di conseguenza il livello si abbassi, a volte portando ad una lunga agonia. Il tutto ribadendo: opinioni mie... http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Sender address rejected: unverified address?
On 14/01/14 13:34, Marco Ermini wrote: Junk Mail is war. RFCs do not apply. (cit) Wietse Venema :-) Hai vinto una birra, ma non so quando mai saremo nello stesso posto e pagarla. Poteva essere un piccolo stimolo a restare dov'eri, ma tanto immagino che da quelle parti le occasioni da birra non manchino comunque... :-) Ho letto prima un'opiione (Tullio Andreatta) circa l'inutilit? di SPF. Tendo in generale a essere d'accordo con quanto ? stato scritto in quel messaggio. Tuttavia non sono molto d'accordo circa l'inutilit? di SPF - se ovviamente accompagnato a DMARC, DKIM e tutto il resto. Vorrei sapere cosa ne pensate in generale sull'efficacia di queste tecniche. So che i grossi player ci puntano, ma in generale mi sembrano di una complessit? notevole - tant'? che dove lavoravo prima erano praticamente impossibile da implementare (organizzazione troppo grande e troppe persone da convincere, e quando la questione diventa cos? complessa...). Sono tecnologie che hanno un loro ruolo ben preciso e di ampio utilizzo liddove si tratti di piattaforme di mail marketing o di messaggistica transazionale. Ma da sole non forniscono alcuna metrica relativa alla reputazione del mittente: tutto quello che ti possono dire è che il mittente non è forgiato. Che poi sia spam o meno, nulla dicono. Nè è il loro ruolo. Sono pertanto complementari a meccanismi di reputation: se i miei meccanismi di reputazione mi dicono che paypal.com è 100% good, e la mail soddisfa DKIM/DMARC posso permettermi di bypassare in toto gran parte degli altri filtri - dato che so di potermi fidare del mittente - riducendo il rischio di falsi positivi. Ma solo perché so chi è paypal e che va trattata di conseguenza, non per DKIM in sè... Per una azienda X anche grossa, dove la tipologia di mail in uscita è varia (mail generate da automatismi vari, mail normali inviate dai dipendenti, mail marketing fatto in maniera più o meno approssimativa dal commerciale di turno), l'utilità è opinabile, a meno di non essere disposti a segmentare le componenti del flusso postale che potrebbero trarne un vantaggio[1]. C'è poi il problema che DKIM e DMARC hanno un ampio utilizzo lato ricevente da parte di operatori con una competenza ben radicata nel settore email (i grossi fornitori di sistemi/servizi di filtraggio e i gorilla del settore freemail come Google, Hotmail, Yahoo, etc.) ma la loro diffusione in ambito più ristretto (mailserver aziendali e dintorni) è sempre rimasta piuttosto limitata. In parte per complessità intrinseca, in parte perchè se non sai che farci (leggasi: non hai o non capisci i meccanismi di reputation cui agganciarli) te ne fai poco. In soldoni, se * sei grosso e conosciuto * invii comunicazioni di carattere informativo/commerciale/transazionale * i riceventi hanno interesse a trattare in modo privilegiato tali comunicazioni (il che significa anche che sono 100% clean) * hai uno o più domini che dedichi a questa sola finalità [1] allora DKIM (e/o DMARC, soprattutto nel caso di invii transazionali) sono circa un must, attualmente. Per domini generici, aggiungono poco o nulla. Altra domanda: in generale osservo che molte organizzazioni cercano la magic box (o adesso la magic cloud) a cui delegare i problemi. Non ho visto fin'ora alcuna killer app contro lo spam e gli utenti di pi? o meno tutte queste magic box o magic cloud si lamentano per lo spam. La mia impressione ? che sia una battaglia pi? complessa di quello che il CTO medio possa comprendere, e che ciascuna azienda/situazione ha bisogno di una certa customizzazione - come diceva Emanuele Balla giustamente, *qualcuno* deve decidere cosa ti puoi permettere di perdere quando filtri le email, ed ? piuttosto difficile tradurre quello che il CTO *pensa* (e chiss? poi cosa ha capito) con un filtro Postfix/qmail... Soprattutto c'è un problema di differenti visioni e visibilità: il fatto che quello che è spam per A non è necessariamente spam per B; sicchè se sia a che B si servono dello stesso oggetto/servizio, uno dei due inevitabilmente ottiene il contrario di quello che desidera. Per una infinità di ragioni che richiederebbero un thread a sè (e per il quale non sono certo questa sia la lista adatta), ma è tuttavia un dato di fatto. Aggiungici che lo spam è una lotta tra parti, per cui se da un lato ci sono gestori/creatori di filtri dall'altro c'è chi fa di tutto per evadere gli stessi, il che rende l'approccio fire and forget del tutto inapplicabile: qualcuno le cose le deve gestire e chi riceve deve mettersi in testa che il filtro applicato (quale che sia la soluzione scelta) non funziona per magia (FUSSP!) ma per la competenza di qualcuno, che necessita anche di feedback, sia positivo che negativo. Il succo, comunque, è che la magic box, non esiste e probabilmente non può esistere. E' un pippone, ma te la sei cercata :-P E non è nemmeno finito... [1] Il fatto è che in particolare per DKIM (e di conseguenza DMARC) la
Re: [ml] Sender address rejected: unverified address?
On 08/01/14 18:46, Tullio Andreatta ML wrote: Concordo su tutto il resto, ma alcune verifiche sull'helo sono previste dalla RFC5321. In particolare nel §4.1.1.1. si afferma che l'helo deve essere il nome fqdn del client smtp (se disponibile) ovvero un IP literal. Il controllo che tale fqdn sia risolvibile è quindi lecito, dato che in caso contrario si tratta di una errata configurazione del sender. Solo perche' RFC5321 dice dovrebbe essere (SHOULD) non significa che sia lecito rifiutare i messaggi se non e' risolvibile o se non corrisponde. Ancorché concordi sul punto specifico, trovo anche che sia tu che Flavio stiate cogliendo il punto solo di striscio (nella mia personale idea, sia chiaro). Junk Mail is war. RFCs do not apply. (cit) Chi decide di pretendere un comportamento di un certo tipo da sistemi mittenti non lo fa perchè le RFC *pretendono* quel comportamento, ma perchè quello è il comportamento normalmente atteso (secondo chi implementa il ruleset; che poi questo corrisponda alla norma dei mittenti è poi da verificare) *e* ritiene di poter fare a meno delle mail di chi non vi si attiene. Se poi la quantità di FP generati da ciò sia eccessiva (nella mia opinione -nel caso di cui parliamo- lo è per chiunque, ma è appunto una opinione) e/o se tale misura sia utile a tenere fuori una quantità significativa di spam (anche questo a mio parere contestabile nel casus in questione, almeno in rapporto al rate di FP causati) sta a lui stabilirlo. Il fatto che il comportamento sia o meno definito da RFC è quindi quasi incidentale... C'è un bot, lì fuori, che invia spam usando sessioni SMTP in cui utilizza come HELO dsldevice.lan (cutwail, credo), e lo fa da anni. E piuttosto normale, quindi, per un ruleset lato ricevente, segare a vista sessioni che si presentino con tale HELO. If it looks like a duck, and quacks like a duck... Non è che questo HELO sia meno RFC-compliant del tuo smtp.network10-1-67.local, sia chiaro, ma se qualcuno decide di impostare quella stringa come HELO del proprio mailserver poi difficilmente può lamentarsi se le sue mail non vengono accettate di default, nè può pretendere che lo siano in virtù del mero fatto che quell'HELO non è vietato da RFC. Perchè, appunto, non è quello il senso della restrizione applicata. (E' mia opinione di vecchia data che nell'ambito della configurazione di filtri SMTP ci sia un proliferare di prassi basate sul mio cugino mi ha detto che più che all'effettiva efficacia in termini di rapporto FP/VP; così come una mancanza di percezione del fatto che qualsiasi misura applicata che non abbia un tasso di FP pari a *zero* richiede poi che le eccezioni *vengano gestite*. Il che è la reale causa di gran parte dei problemi cui ci si riferisce qui; ma è altro discorso...) Ad esempio, il mail server sul quale adesso sto lavorando ha come FQDN smtp.network10-1-67.local e IP literal 10.1.67.25 e - a seconda del fatto che la linea impegnata sia quella principale o quella di backup - puo' uscire con due indirizzi IP pubblici differenti, uno dei quali e' in comune con un'altra 40ina di mail server, i quali hanno nomi tutti diversi (e che, quando la linea primaria e' attiva, escono solitamente con IP pubblici tutti diversi). Che cosa devo scrivere come argomento di HELO? Quello che vuoi, purchè stia su un dominio che controlli direttamente (evita in particolare roba fantasiosa come hostX-Y-static.Z-W.business.telecomitalia.it) e risolva... ^_^ Di certo, se usi .local come TLD, così non può essere... Se vuoi far di più, associa un record SPF all'hostname usato come HELO (e, ovviamente, al dominio mittente liddove possibile). Il fatto che la risoluzione dell'HELO ritorni lo stesso IP usato per il singolo invio è un di più gradito, ma non necessario: è pur vero che ci sono taluni che lo pretendono, ma si tratta di nuovo di eccessi di zelo (sempre IMHO) ancor più limitati per diffusione. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Spam particolare
On 10/17/13 9:41 PM, Andrea wrote: Ciao a tutti, so che c'è già stato un thread riguardo lo spam ma vorrei segnalare qualcosa di anomalo che succede in una azienda con server di posta interno, in pratica da qualche giorno arrivano centinaia di mail spam il cui mittente coincide con il destinatario (tranne per il return-path), dai log sul server è chiaro che si tratta di un attacco dal'esterno ma la cosa strana è che l'IP sorgente cambia sempre! Posso capire che ci siano uno o due server da cui partono questi tipi di msg spam, ma centinaia di IP pubblici e sempre diversi che utilizzano il medesimo tipo di attacco.. mi suona strano Benvenuto nel magico mondo delle botnet. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Spamassassin e BL
On 9/23/13 3:41 PM, Mirko ML wrote: Il problema è che vi sono situazioni in cui greylisting causa delay ben superiori al tempo di requeue di un singolo tentativo. Vedi sopra per il timeout e per quanto riguarda il DSN di alcuni provider grossi e ben noti basterebbe che applicassero le Retry Strategies e la Sending Strategy della stessa RFC, cosa che semplicemente non fanno con la scusa di essere appunto grossi Non mi risultano grossi che violino le RFC sulle modalità di ritrasmissione, ad essere sinceri, ed infatti non è a questo che mi riferisco sui problemi introdotti dal greylisting, bensì sull'assunto soggiacente la logica stessa dell'approccio da questo implementato: che la ritrasmissione di un messaggio debba originarsi dallo stesso IP da cui ha avuto origine in precedente tentativo di delivery. La qual cosa che non è in alcun modo deducibile da RFC (che, appunto, definiscono SMTP e non greylisting), e che in caso di sender con SMTP pool molto distribuiti può essere una assunzione assai lungi dall'essere sensata. Poi, come disse il buon Wietze, Spam is war, RFCs do not apply, ergo ciò non è necessariamente un male di per sè. Ciò non toglie che introdurre deliberatamente ritardi su una fetta importante del traffico, ottenendo in cambio una efficienza molto limitata e facilmente superabile con dozzine di altri approcci disponibili non ricade nella mia definizione di misura efficace. YMMV, a seconda delle dimensioni dei sistemi che gestisci. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Spamassassin e BL
On 9/21/13 7:48 PM, Mirko ML wrote: Non mi piace per nulla, la trovo un'aberrazione. E' veramente utile? Benvenuto nel club. Era utile, oggi lo è meno, in virtù del fatto che molte botnet sono in grado di aggirarlo. Se implementato in maniera intelligente e su piccola scala, comunque, aiuta ancora e non ha particolari effetti collaterali. personalmente ritengo che non sia eticamente scorretto visto che è definito da RFC 5321 ( http://tools.ietf.org/html/rfc5321) Ni. Ad essere definita da RFC è la ritrasmissione, non il greylisting. Eticamente scorretto è certamente esagerato, resta il fatto che è una soluzione che non risolve (quindi, una non-soluzione, a voler ben vedere) e che a fronte di una efficienza estrmamente limitata degrada la qualità dell'intero media (per coloro i quali ne sono affetti, almeno). Vista, non piaciuta ma utilizzata, rimossa quando il livello di efficacia è sceso ben al di sotto del percepibile, a fronte di fastidi persistenti (tipo 4 anni fa). Come giustamente sottolinea Marco, è anche uno strumento oramai pressochè inutile per chi sappia gestire un ruleset SMTP adeguato e ne abbia il tempo. Come sostenevo nel post cui rispondi, può essere ancora utile a installazioni di piccole dimensioni, se ben implementato. E' più scorretto trovare qualcuno che questa cosa non la rispetti e dia un DSN al mittente dopo un singolo tentativo Il problema è che vi sono situazioni in cui greylisting causa delay ben superiori al tempo di requeue di un singolo tentativo. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Spamassassin e BL
On 9/19/13 12:10 PM, Davide Davini wrote: 2) Grey list Non mi piace per nulla, la trovo un'aberrazione. E' veramente utile? Benvenuto nel club. Era utile, oggi lo è meno, in virtù del fatto che molte botnet sono in grado di aggirarlo. Se implementato in maniera intelligente e su piccola scala, comunque, aiuta ancora e non ha particolari effetti collaterali. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] INOG
On 6/13/13 3:19 PM, Davide Davini wrote: Siccome ho letto per la prima volta di NANOG su questa lista mi permetto di fare questa domanda sciocca. Non esiste qualcosa di simile per l'Internet Italiana, vero? ITNOG: http://lists.itnog.it/listinfo/itnog Ma il traffico è desolantemente basso. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] is a phising site ?
On 9/27/11 11:10 AM, s@mba wrote: Ciao a tutti, vorrei capire se questo sito sta effettivamente facendo phishing o no: http://www.glandorepartners.com/ Recentemente ho ricevuto una mail diretta unicamente a me che mi invitava a mandare il cv se ero interessato ad una proposta di lavoro come sysadmin. Essendo diffidente per default ho controllato il sito ed ho trovato del codice Javascript offuscato che vi incollo qui: http://pastebin.com/raw.php?i=mfTUvmD7 Il codice praticamente manda una mail (credo ad ogni accesso) a: acoll...@glandorehealthcare.com Controllando il sito http://www.glandorehealthcare.com vedo lo stesso identico layout con lo stesso codice javascript dentro. Le informazioni sul sito sono basilari e gli account linkedin che ci sono in rete sembrano dei fake. ora il mio dubbio è: 1. Il sito sta facendo phishing? 2. se sì, in che modo è possibile segnalarlo e a chi? I due siti sono registrati dalla stessa entità/persona, tra dicembre 2009 e marzo 2010. Entrambi un po' vecchi per essere domini rogue (anche se può certamente capitare). La prima delle due funzioni offuscate (acollins), deoffuscata produce: a href=#x6d;#x61;#x69;#x6c;#000116;#000111;#x3a; #x61; #99; #111; #108; #x6c; #105; #110; #115; #x40; #x67; #x6c; #x61; #x6e; #100; #x6f; #114; #101; #x68; #x65; #97; #x6c; #116; #104; #x63; #97; #114; #x65; #x2e; #x63; #x6f; #x6d; class=mailto #x61; #99; #x6f; #x6c; #108; #105; #110; #115; #x40; #x67; #108; #97; #110; #x64; #111; #x72; #101; #104; #x65; #97; #x6c; #x74; #104; #99; #x61; #x72; #x65; #x2e; #x63; #111; #x6d; /a A te il compito di decodarlo in caratteri normali, ma in sostanza si limita a generare un mailto verso l'indirizzo acollins@[...]. Ergo è un semplice offuscamento degli indirizzi email per prevenirne l'harvesting... -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. - http://bofhskull.wordpress.com/ http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Comodo hack e alcune riflessioni
On 3/29/11 12:57 PM, Stefano Zanero wrote: Cari amici, dopo aver visto l'imbarazzante evento dell'hacking a Comodo (qui un mio piccolo rant personale: http://raistlin.soup.io/post/119155650/Comodo-hack-my-opinion), secondo me dovremmo immediatamente trarre alcune riflessioni relative alla recente e sciagurata iniziativa legislativa del nuovo CAD. Guarda, evito di buttarmi in considerazioni di carattere legislativo/sociologico. Mi limito ad una considerazione strettamente tecnico-economica: questa è esattamente la ragione per la quale giocare al dumping/ribasso dei servizi è -a volte- *male*. Quando vedo CA ricevere il CSR, inviare mail di autorizzazione e rilasciare il CRT in 3 minuti, francamente trovo sia da alzare le orecchie. Io mi rendo perfettamente conto del fatto che al cliente che acquista un certificato rode un po' il didietro a spendere 100/200€ -quando va bene- per un certificato. Ma ho l'illusione di pensare che dietro alla mera esecuzione di un openssl ca vi sia anche un minimo di lavoro di una persona che si prende cura di verificare (sia pur con un livello di dettaglio al più approssimativo) che lui sia chi dice di essere, che giustifica sia la spesa economica che -soprattutto- la necessità di attendere anche mezza giornata che qualcuno abbia il tempo di dare un occhio alla pratica. Ciò nonostante, questo non è ciò che richiede *il mercato*: un certificato è un certificato (purchè la CA sia nella keychain, chissenefrega, giustamente), meno mi costa e meglio è. Inevitabile che questo comporti l'ingresso in una infinita spirale discendente, in cui la firma di un certificato costa sempre meno e garantisce sempre meno, per ragioni che nulla hanno a che vedere con la sicurezza crittografica dei meccanismi sottesi. Forse, sarebbe il caso di farci un ragionamento sopra, tutto sommato, quantomeno per evitare che gli stessi problemi vadano a impattare tecnologie nascenti e in quale maniera assimilabili (penso ad es. a DNSSEC)... -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. - http://bofhskull.wordpress.com/ http://www.sikurezza.org - Italian Security Mailing List
