Blocca lo spam utilizzando il filter geoip?

Stiamo cercando un modo per bloccare lo spam basato sulla posizione geografica filtrando utilizzando geoip.

context: raramente abbiamo una corrispondenza di posta elettronica al di fuori degli USA, quindi vorremmo bloccare tutte le email in arrivo al di fuori degli Stati Uniti tranne forse uno o due paesi.

  • Come impedire alle persone di utilizzare il mio dominio per submit lo spam?
  • 3 cassette postali di Exchange con 50GB e crescono. La ricerca / l'indexing è lento. Opzioni?
  • Come devo garantire una networking wireless aziendale?
  • Linux, aggiungendo le sottointerfacce
  • Ping "risponde" dallo stesso computer con "Host destinazione non raggiungibile" (nessun path verso un altro computer)
  • Le email sono contrassegnate come spam
  • Dopo un po 'di Googling ho trovato un paio di soluzioni che potrebbero funzionare (o no), ma vorrei sapere quali altri sisthemes sono attualmente in esecuzione o cosa consiglierebbero come soluzione.

    Ecco quello che ho trovato finora:

    Utilizzando PowerDNS e il suo back-end GeoIP è ansible utilizzare il geoip per il filtraggio. Normalmente questo backend viene utilizzato per aiutare a distribuire il carico come una sorta di bilanciamento del carico, ma non capisco perché non possa essere usato per uccidere anche lo spam?

    Forse utilizzare il database Maxmind lite paese e alcuni script per fare un lavoro simile.

    Idealmente quello che sto cercando è una soluzione che gestire bene il carico e la scala decente anche … non siamo tutti! 😉

    Grazie in anticipo per il vostro aiuto! 🙂

    8 Solutions collect form web for “Blocca lo spam utilizzando il filter geoip?”

    C'è anche la patch geoip per netfilter / iptables per Linux. Potresti usare questo per bloccare 25 per il tuo server di posta elettronica se è Linux. Potresti usare Linux come firewall per il tuo server di posta elettronica con questa patch iptables. La cosa migliore è che è gratis 🙂

    Da questo documento di ricerca su SNARE , presento questo nugget:

    Per il prosciutto, il 90% dei messaggi va da circa 4.000 km o less. D'altra parte, per lo spam, solo il 28% dei messaggi rimane all'interno di questo intervallo.

    Le mie osservazioni personali rispecchiano la tua e noti che anche oggi nel 2014, la posizione geografica continua ad essere un eccellente predittore dello spam. Come ha sottolineato altri, la localizzazione GeoIP (paese o distanza) non è una base sufficientemente affidabile per bloccare le connessioni. Tuttavia, combinando la distanza GeoIP con alcuni altri dati relativi alla connessione, ad esempio FCrDNS, la validità del nome host HELO, il sistema di destinazione OS (via p0f) e SPF, fornisce una base affidabile del 99,99% (come in una probabilità 0,01% FP) per il rifiuto dell'80% delle connessioni prima della fase DATA.

    A differenza di alcuni test SMTP (ad esempio un elenco DNSBL in zen.spamhaus.org) che hanno tariffe FP molto basse, nessuno dei singoli test sopra descritti è una base sufficiente per rifiutare le connessioni. Ecco un altro model che rientra in quella categoria: l' utente della busta mittente corrisponde all'utente destinatario della busta . Ho notato che circa il 30% dello spam segue questo schema: da: matt@spammer-controlled-domain.tld a: matt@my-domain.com. Succede molto più spesso nello spam che nei flussi di posta validi. Un altro model di spammer è una busta e un'intestazione non corrispondenti dal dominio.

    Euristicamente, puntando su queste caratteristiche di "spam", si possono assemblare le basi per un sistema di filtraggio estremamente affidabile. SpamAssassin già fa (o può fare) gran parte di quello che ho descritto. Ma hai anche chiesto una soluzione che gestisca il carico e la scala sufficiente. Mentre SpamAssassin è grande, non ho visto "massicciamente ridotto consumo di risorse" ovunque nelle note di rilascio 3.4.

    Tutti i test che ho elencato nel primo paragrafo si verificano prima di SMTP DATA. La combinazione di questi primi test costituisce una base sufficiente per rifiutare le connessioni spammy prima dei dati SMTP senza alcun False Positives. Il rifiuto della connessione prima dei dati SMTP evita i costi di width di banda di trasferimento del messaggio e la maggior parte dei filtri basati su contenuti e sulla networking di filtri basati sul contenuto (SpamAssassin, dspam, validation delle intestazioni, DKIM, URIBL, antivirus, DMARC ecc.) delle connessioni. Fare molto less lavoro per scale di connessione molto meglio.

    Per il sottoinsieme più piccolo di messaggi che sono indeterminati a DATA SMTP, la connessione è consentita a procedere e segmento del messaggio con i risultati dei filtri di contenuto.

    Per eseguire tutto quello che ho descritto, ho fatto un po 'di hacking su un server SMTP basato su node.js chiamato Haraka. Si scala molto, molto bene. Ho scritto un plugin personalizzato chiamato Karma che fa il punteggio euristico e ho messo tutti i punteggi di ponderazione in un file di configuration. Per avere un'idea di come funziona il karma, guarda il file di configuration karma.ini . Sto ottenendo risultati di filtraggio "meglio di gmail".

    Dai un'occhiata ai test eseguiti da FCrDNS, helo.checks e data.headers pure. Potrebbero fornire ulteriori idee di filtraggio. Se hai altre idee per rilevare in modo affidabile lo spam con test a buon mercato (pre-DATA), mi interessa ascoltarli.

    Altre domande wherete chiedere: qual è il tuo tasso di falsi positivo e falso negativo accettabile (quanta postazione legittima sei disposta a perdere e quanto spreco sei disposto ad accettare?)

    Quale latenza supplementare sei disposto ad accettare? Alcune tecniche molto efficaci anti-spam ( ad esempio greylisting) possono ritardare la posta. Questo può irritare alcuni utenti che (irrealisticamente) prevedono che la posta elettronica sia una comunicazione immediata.

    Riflettere su quanto si desidera esternalizzare i costi durante la progettazione di un sistema antispam. Ad esempio, i blacklist basati su ipfilter sono scoraggiati, ma non influenzano materialmente altri sisthemes. Greylisting conserva la width di banda del destinatario e del destinatario ma mantiene la posta in lunghe code più lunghe. I messaggi di rimbalzo e i sisthemes di risposta / risposta possono essere utilizzati per abbonarsi a una terza parte non correlata. Tecniche come tarpitting triggersmente esternalizzano i costi tenendo intenzionalmente i collegamenti SMTP aperti per lunghi periodi di tempo. I DNSBL richiedono di cedere una certa quantità di controllo a un terzo (gestori di liste nere), ma in ultima analisi come amministratore di posta è responsabile per spiegare la tua politica di block per i tuoi utenti e la gestione. Il risultato è che ci sono considerazioni etiche che accompagnano each tecnologia e che è importnte essere consapevoli del tuo effetto sugli altri.

    Come sanetworking tollerati verso sisthemes esterni misconfigurati? ( ad esempio quelli senza FCrDNS, stringhe rotte HELO / EHLO, pipeline non autorizzate, quelle che non si riprovano correttamente dopo un codice di errore temporaneo 4xx ecc. )

    Quanto tempo, denaro, width di banda e hardware wherete dedicare al problema?

    Nessuna singola tecnica è efficace, ma un approccio concertato di difesa in profondità può ridurre notevolmente i rifiuti in entrata. DNSBLs, URIBLs, greylisting, filtraggio dei contenuti e lavoro a mano bianco e blacklist funzionano bene sul mio piccolo dominio, ma posso permettermi di essere più liberale in quello che rifiuto.

    A less che le cose non siano cambiate di recente, la blacklisting IP per paese di origine non è terribilmente efficace. Ho avuto l'idea di utilizzare l'impronta digitale ASN e OS (via p0f) per giudicare la qualità di una connessione in entrata ma non l'ho perseguita; le statistiche sarebbero interessanti da guardare ma non sono convinto che sarebbe più utile delle tecniche standard già descritte. Le informazioni sull'impronta digitale di GeoIP, ASN e OS sono che, se individualmente potrebbero essere deboli predittori della qualità di connessione, sono disponibili a tempo di connessione TCP / IP, molto tempo prima di raggiungere il livello SMTP (fsvo "lungo"). possono risultare utili e che sarebbe utile perché lo spam diventa più costoso da bloccare mentre si avvicina all'utente finale.

    Non sto cercando di essere un nayayer; Codifica dei caratteri 'oddball' e informazioni GeoIP probabilmente si correlano bene allo spam, ma potrebbero non essere abbastanza affidabili da utilizzare come criteri singoli per bloccare la posta. Tuttavia possono essere utili indicatori in un sistema come Spamassassin. Il takeaway è che la difesa di spam è un problema complesso in analisi costi-rischio-benefici e è importnte sapere quali sono i valori prima di implementare o modificare un sistema.

    Non sarebbe semplicemente meglio utilizzare qualcosa come la list di blocchi di Spamhaus ZEN ( http://www.spamhaus.org/zen/ ) invece? È gratuito se il traffico di posta elettronica dell'organizzazione è inferiore a 100.000 connessioni SMTP e 300.000 query DNSBL al giorno.

    Dato che i loro requisiti di utilizzo ( http://www.spamhaus.org/organization/dnsblusage.html ) potrebbero richiedere un abbonamento al feed di dati se si effettua un traffico di posta elettronica molto più quotidiano, ma a quel livello di utilizzo (leggere l'ammenda printing in fondo alla pagina) probabilmente non si desidera l'onere amministrativo di gestire il proprio elenco di blocchi comunque.

    Utilizzando una combinazione di DNSBL a livello di server di posta / app e GEOIP a livello di server dovrebbe rimuovere la maggior parte del tuo spam per voi senza wherer implementare il punteggio spam, i fasle positivi, ecc.

    Questo è particolarmente vero se il tuo server di posta / azienda riceve solo email da una mano di paesi noti come USA, Canada.

    Argosoft server di posta per le windows fa un buon lavoro di questo ma non sono a conoscenza di una simile soluzione basata su Linux. Ecco perché consiglio di utilizzare un MTA affidabile su Linux (preferibilmente con DNSBL) e quindi fare una soluzione GEOIP a livello di server.

    Spero che questo ti aiuti.

    Ho pensato che ti piacerebbe sapere che ci sono già venditori commerciali anti-spam che lo fanno. Anche se IME aggiunge un punteggio di spam per i paesi al di fuori del tuo territorio di casa, per impedire l'overblocking.

    Forse è ben integrato con SpamAssassin ad esempio?

    Potresti anche considerare i caratteri che l'e-mail è in.

    Per quanto riguarda l'implementazione – ci sono alcuni database economici geo-IP accessibili in commercio. Sarei inclini ad integrare questi manualmente, in modo da poter lasciare che il messaggio arrivi fino al punto in cui conosci la coppia di destinatari del mittente, per il logging.

    HTH,

    Tom

    Ho usato Sendmail insieme a milter-greylist per esattamente questo scopo da diversi anni su diversi server di posta elettronica a media volume senza alcun problema. È facile configurare le regole GeoIP, SPF, whitelist, DNSBL ecc. Desiderate in greylist.conf per applicare selettivamente il greylisting.

    Ecco un apparecchio in linea che funziona con router e firewall per bloccare il traffico IP da nazioni e liste nere IP a velocità di linea. E Arclight è corretto, a less che non sia disposto ad assumere una maggiore latenza e abbandonare le connessioni TCP, è necessario disporre di un dispositivo specializzato come questo IP Blocker da TechGuard per mantenere la protezione della velocità di linea. TechGuard ha anche appena rilasciato dati sull'impatto degli ACL sui router e sui firewall.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.