Gestire gli script di spam come un operatore di hosting condiviso, con utenti che ospitano la posta esternamente

16

Assumi la seguente configurazione;

  1. Un server di hosting condiviso, che condivide un singolo IP con molti piccoli siti web.
  2. Un sottoinsieme del set di siti Web sta inviando e-mail. Alcune di queste e-mail potrebbero essere di dominio proprio.
  3. Un altro sottoinsieme del set di siti Web ospita la propria posta su un'altra piattaforma.
  4. Un terzo sottoinsieme che ospita è vulnerabile a una vunerabilità di esecuzione di codice in modalità remota.
  5. Nel diagramma di Venn per i sottoinsiemi (2), (3), (4), supponiamo che qualsiasi parte possa essere non vuota.

Ci sono problemi con gli spammer che diventano sempre più competenti nell'eludere le misure di sicurezza installate. Con l'accesso completo all'esecuzione del codice, un hacker può aggirare il solito stack di posta di Linux e implementare il proprio server di posta elettronica, comunicando direttamente tramite codice socket a server di posta esterni e inviando una quantità enorme di spam.

Un server è una macchina piuttosto potente, quindi un tale codice di roaming gratuito può inviare quantità significative di spam per entrare nel radar dei Big Boy, come Microsoft e Google. Queste aziende hanno i loro propri sistemi proprietari offuscati che tendono a bloccare in base all'IP. So che questa è una cosa stupida da fare: IP non è uguale a una macchina unica. Ovviamente un piccolo fornitore di servizi di hosting può fare poco su queste grandi politiche aziendali e non è possibile ignorarle; molti consumatori (ad esempio utenti dei siti Web sulla piattaforma) avranno indirizzi e-mail sulle piattaforme dei grandi provider.

C'è anche un elemento di segretezza coinvolto; le grandi aziende stanno attivamente cercando di combattere le botnet degli spammer, quindi non forniscono informazioni minime o minime su alcun blocco in modo che gli spammer non possano usare queste informazioni. Con l'invio di spam che è "indicizzato", potrebbero aver identificato la particolare botnet e aver contrassegnato il server di hosting come uno strumento sospettato di cybercriminal. Non è del tutto irragionevole, perché in realtà è a questo punto che viene utilizzato il server.

L'esaurimento dell'indirizzo IPv4 significa che l'hosting non condiviso è solo un'opzione non valida per questi piccoli siti web. È finanziariamente appena non realizzabile.

Nota; Supponiamo che ci saranno sempre dei siti vulnerabili, questa è una debolezza intrinseca di una piattaforma condivisa, non ogni cliente avrà il suo codice ugualmente sicuro.

Dopo essere stato violato, il cliente viene ovviamente avvisato. La procedura standard consiste nel portare il sito offline e ripristinare una versione pulita, richiedendo agli sviluppatori di risolvere i problemi di sicurezza prima di quello.

Tuttavia, rimane un grosso problema; Un piccolo errore per uno di molti siti Web spegne efficacemente l'e-mail per l'intero server, e ripristinarne il tutto può richiedere giorni, piuttosto che prevenire questo tipo di problema. Man mano che i siti invecchiano, più siti iniziano a utilizzare lo stesso IP e gli spammer diventano sempre più competenti, la situazione peggiorerà nel tempo.

Anche se posso pensare ad alcune soluzioni parziali, finora non sono state in grado di mantenere l'intero set di funzionalità che stiamo fornendo. Ad esempio, ho provato a bloccare il traffico in uscita sulla porta e-mail standard (25) attraverso il firewall del server per tutti gli utenti tranne root e un utente di posta elettronica attendibile. Ciò impedirà completamente i nostri problemi di spam, poiché ciò significa che i siti Web devono utilizzare lo stack standard ed è semplice configurare cose come limitazione della velocità e filtri antispam per la posta in uscita su questo stack standard.

La piccola quantità di spam che può ancora passare non ci metterebbe su questi elenchi di blocco ip segreti.

Questo funziona per la maggior parte dei siti Web; ma non tutto. Sottoinsieme (3) sta lanciando una chiave inglese nelle opere se combinate con (2). Illustriamo:

Il nostro host (IP = H) dovrebbe inviare un messaggio a un host Microsoft (IP = M), attraverso il suo server di posta. Diciamo che inviamo da "[email protected]" a "[email protected]". Se questo messaggio viene inviato direttamente, tutto funziona. Tuttavia, quando viene inviato tramite il server di posta, ha bisogno di record DNS. Ma poi tenta di inviare a localhost (H), questo fallisce, perché (H) non ha il "contatto" della casella di posta, che dovrebbe esistere solo sul microsoft host ...

Inoltre, il semplice blocco di tutto ciò potrebbe non funzionare per tutti i siti web; alcuni possono avere il proprio motore di posta integrato, anche se se con qualche giochino riusciremo a superare il problema sopra, non sono imparziale a dire a queste persone di riparare il loro software per usare il programma di posta corretto.

Mi interessano le opinioni sui modi intelligenti (e) di affrontare questo enigma.

    
posta aphid 05.10.2018 - 12:34
fonte

2 risposte

19

Questo è un argomento lungo e complicato, ma cercherò di rispondere il più concisamente possibile.

Fondamentalmente, stai mescolando tre tipi di problemi qui:

  • Abuso di servizi di invio e-mail legittimi forniti dal server;
  • Esecuzione di codice dannoso sul tuo server web che può inviare email a qualsiasi destinatario esterno per conto proprio, ovvero senza utilizzare le legittime strutture locali;
  • Configurazione corretta dei record DNS.

Tralascerò quest'ultimo dato che ciò renderebbe la risposta troppo lunga e concentrarsi sui primi due tipi di problemi.

Non stai dicendo nulla su quante macchine e indirizzi IP hai a portata di mano per separare le cose, ma con risorse ragionevoli, il mio consiglio da anni di pratica sarebbe come una prima linea di difesa:

  1. Non consentire al tuo server web di inviare email ovunque tranne che a un server di inoltro SMTP di tua proprietà e che controlli e che è separato dal server web in caso di compromissione. Metti un firewall esterno sul server web che impedirà la qualsiasi connessione IP che origina dal tuo server web alla porta 25 su qualsiasi server ad eccezione del tuo server relay SMTP. (Alcune persone potrebbero dirti di impedire non solo le connessioni originate dal tuo server web alla porta 25 ma a tutte le porte possibili in quanto i server web dovrebbero in teoria rispondere alle richieste e non avviare direttamente alcuna richiesta. Sfortunatamente, questo potrebbe dare problemi ai tuoi clienti se per esempio ad esempio, esegui qualsiasi CMS che voglia parlare al suo repository di estensione. Lascerò questo argomento a una discussione separata.)

  2. Nella connessione tra il server web e il server di inoltro SMTP, assicurati di utilizzare una qualche forma di autenticazione. Se necessario, creare un utente per ciascun sito Web sul server di inoltro SMTP e richiedere al server Web di autenticarsi sul server di inoltro SMTP per inviare i messaggi. Ciò renderà estremamente semplice disattivare l'invio di e-mail per un solo sito Web specifico.

  3. Sul server di inoltro SMTP, implementare tecniche ragionevoli per prevenire lo spam. Di solito una combinazione di rate limitazione e possibilmente di scansione dei contenuti (si pensi a Spamassassin) dove si limitano a filtrare molto i punteggi migliori dovrebbero aiutare.

Si potrebbe immaginare un po 'di magia di scripting quando viene rilevata un'emergenza di spam emergente sul server di inoltro SMTP, l'utente che appartiene al sito di invio verrà automaticamente bloccato per evitare danni.

Dopo tutto, mantenere un secondo e terzo server di inoltro SMTP in cold standby con un indirizzo IP pubblico diverso e, se possibile, in un ASN diverso. Se le tue contromisure falliscono e l'indirizzo IP del tuo primo relay server SMTP viene "bruciato", puoi immediatamente passare a uno dei tuoi server "ancora sconosciuti" per garantire il corretto recapito della posta in uscita.

Nota: quando si implementa questo, assicurarsi di comprendere correttamente cose come DKIM e SPF e impostare i record appropriati. Allora funzionerà. Se hai bisogno di spegnere un server che è stato inserito in alcuni elenchi bloccanti (la maggior parte di loro non è così segreto), di solito sarai rimosso dalla lista dopo un po 'di tempo (pensa alle settimane, non alle ore) e quell'IP sarebbe disponibile di nuovo per una specie di round robin.

    
risposta data 05.10.2018 - 15:17
fonte
4

La risposta di ThorstenS è azzeccata (+1 da me); per controllare l'email che stanno inviando questi siti web, devi eseguirli sul tuo server.

Tuttavia, non sono d'accordo con alcuni dettagli - quando si parla di quei piccoli siti Web su hosting condiviso, il cliente è tipicamente una piccola azienda senza alcuna conoscenza tecnica, che ha un amico, uno stagista o un piccolo web design la società ha creato un sito Web alcuni anni fa e per chi "configura il software in uso, e solo questo, mailserver" o "assicurati che il tuo software si autentichi sul server di posta" è al di là delle loro possibilità.

Quindi quello che farei non sono le porte di blocco, le reindirizzerei al mio server di posta. Questo è abbastanza facile usando iptables se stai usando un host Linux; un esempio di questo può essere trovato su ServerFault . Questo è trasparente per i tuoi utenti, quindi nessuno ha bisogno di riconfigurare nulla, e puoi modificare la tua destinazione, ancora senza dirlo a nessuno, se necessario.

Successivamente, rate limiting per utente - ci sono due (ben, tre) approcci a questo senza richiedere l'autenticazione. O, metti un tag dipendente dall'utente sui tuoi pacchetti SYN e usa il rate rate di iptables . In alternativa, usa quel tag per reindirizzare a porte diverse sul tuo server di posta, fare in modo che il software del server di posta ascolti ognuno di essi e utilizzare la porta per distinguere gli utenti. Oppure, la soluzione che è probabilmente la più robusta (e la meno performante), quando arriva una connessione TCP sul server di posta, ottieni il numero della porta remota, chiama netstat -ntp o lsof o simile sul server web per ottenere il proprietario e utilizzalo per limitare i tassi.

Se un utente insiste sul fatto che deve utilizzare un server di posta specifico (ad esempio, sto usando mailtrap.io sui miei siti di test), aprire la porta a quell'indirizzo (il che può essere un problema con gli indirizzi che stanno spostando gli obiettivi ), o semplicemente reindirizzarli a un'altra configurazione sul tuo server di posta che fa la cosa che limita la velocità e ha il vero bersaglio come suo spedizioniere.

    
risposta data 05.10.2018 - 20:53
fonte

Leggi altre domande sui tag