Tratar con scripts de spam como un operador de alojamiento compartido, con usuarios que alojan correo externamente

Question

Tratar con scripts de spam como un operador de alojamiento compartido, con usuarios que alojan correo externamente

#1 de TorstenS (19 votos)
#2 de Guntram Blohm (4 votos)

16

Supongamos la siguiente configuración;

Un servidor de alojamiento compartido, que comparte una única IP con muchos sitios web pequeños.
Un subconjunto del conjunto de sitios web está enviando correos electrónicos. Algunos de esos correos electrónicos pueden ser de su propio dominio.
Otro subconjunto del conjunto de sitios web está alojando su correo en otra plataforma.
Un tercer subconjunto que host es vulnerable a una ejecución remota de código remota.
En el diagrama de Venn para los subconjuntos (2), (3), (4), se supone que cualquier parte puede ser no vacía.

Hay problemas con que los spammers sean cada vez más competentes para eludir las medidas de seguridad instaladas. Con el acceso completo a la ejecución del código, un pirata informático puede eludir la pila de correo de Linux habitual y, en su lugar, implementar su propio servidor de correo electrónico, comunicándose directamente a través de un código de socket a servidores de correo externos y enviando una gran cantidad de spam.

Un servidor es una máquina bastante poderosa, por lo que este código de itinerancia libre puede enviar cantidades suficientes de spam para que entren en el radar de los Big Boys, como Microsoft y Google. Estas compañías tienen sus propios sistemas patentados ofuscados que tienden a bloquearse en función de la propiedad intelectual. Sé que esto es algo estúpido: IP no es igual a una máquina única. Obviamente, un pequeño proveedor de hosting puede hacer poco por estas grandes políticas corporativas, y usted tampoco puede ignorarlas; muchos consumidores (por ejemplo, los usuarios de los sitios web de la plataforma) tendrán direcciones de correo electrónico en las plataformas de los grandes proveedores.

También hay un elemento de secreto involucrado; las grandes empresas están tratando activamente de luchar contra las redes de bots de spammer, por lo que proporcionan ninguna información mínima o mínima sobre cualquier bloqueo para que los spammers no puedan usar esta información. Al enviar correo no deseado "firmado" es posible que hayan identificado la botnet en particular y hayan marcado el servidor de alojamiento como una herramienta sospechosa de ciberdelincuencia. No es del todo irrazonable, porque en verdad para eso se está usando el servidor en ese momento.

El agotamiento de la dirección IPv4 significa que el alojamiento no compartido no es más que una opción para estos sitios web pequeños. Es financieramente simplemente no alcanzable.

Nota; asuma que siempre habrá algunos sitios vulnerables, eso es una debilidad intrínseca de una plataforma compartida, no todos los clientes tendrán su código igualmente seguro.

Al ser hackeado, el cliente es, por supuesto, notificado. El procedimiento estándar es desconectar el sitio y restablecer una versión limpia, lo que requiere que los desarrolladores solucionen los problemas de seguridad antes de eso.

Sin embargo, sigue habiendo un problema bastante grande; Un pequeño error para uno de cada muchos sitios web cerrará efectivamente el correo electrónico para todo el servidor, y volver a hacer copias de seguridad de todo puede demorar días en curarse en lugar de evitar este tipo de problema. A medida que los sitios se vuelven más viejos, más sitios comienzan a usar la misma IP, y los spammers son cada vez más competentes, la situación empeorará con el tiempo.

Aunque puedo pensar en algunas soluciones parciales, hasta ahora no han podido mantener el conjunto completo de funciones que estamos proporcionando. Por ejemplo, he intentado bloquear el tráfico saliente a través del puerto de correo electrónico estándar (25) a través del firewall del servidor para todos los usuarios, excepto el usuario de correo electrónico de confianza. Esto evitará totalmente nuestros problemas de spam, ya que esto significa que los sitios web deben usar la pila estándar, y es fácil de configurar cosas como la limitación de velocidad y los filtros de spam para el correo saliente en esta pila estándar.

La pequeña cantidad de spam que aún puede pasar no nos colocaría en estas listas secretas de bloqueo de ip.

Esto funciona para la mayoría de los sitios web; pero no todos. El subconjunto (3) está lanzando una llave en las obras si se combina con (2). Vamos a ilustrar:

Se supone que nuestro host (IP = H) envía un mensaje a un host de microsoft (IP = M), a través de su servidor de correo. Digamos que enviamos desde '[email protected]' a '[email protected]'. Si este mensaje se envía directamente, todo funciona. Sin embargo, cuando se envía a través del servidor de correo, necesita registros DNS. Pero luego intenta enviar a localhost (H), esto falla, porque (H) no tiene el 'contacto' del buzón, que solo debería existir en el host de Microsoft ...

Además, el simple bloqueo de todo eso puede no funcionar para todos los sitios web; algunos pueden tener su propio motor de correo incorporado, aunque si con algún problema podemos superar el problema anterior, no soy imparcial al decirles a estas personas que corrijan su software para usar el programa de correo correcto.

Me interesan las opiniones acerca de las formas inteligentes (er) de resolver este problema.

linux shared-hosting

pregunta aphid 05.10.2018 - 12:34

fuente

2 respuestas

Lea otras preguntas en las etiquetas linux shared-hosting

¿Por qué iterar 5200 veces cuando se calculan los números de seguridad en Signal? ¿Existe algún riesgo de seguridad al almacenar variaciones de contraseñas con hash?

score 19 · Answer 1

Este es un tema largo y complicado, pero intentaré responder lo más conciso que pueda.

Básicamente, estás mezclando tres tipos de problemas aquí:

Abuso de las instalaciones legítimas de envío de correo electrónico que proporciona su servidor;
Ejecución de código malicioso en su servidor web que puede enviar correos electrónicos a cualquier destinatario externo por su cuenta, es decir, sin utilizar las instalaciones locales legítimas;
Configuración adecuada de los registros DNS.

Dejaré este último ya que esto haría que la respuesta fuera demasiado larga, y me centraré en los dos primeros tipos de problemas.

No está diciendo nada acerca de cuántas máquinas y direcciones IP tiene a mano para separar las cosas, pero con recursos razonables, mi consejo de años de práctica sería como primera línea de defensa:

No permita que su servidor web envíe correos electrónicos a ningún lugar, excepto a un servidor de retransmisión SMTP que usted posee y controla, y que está separado del servidor web en caso de compromiso. Coloque un servidor de seguridad externo en la máquina del servidor web que evitará que cualquier conexión IP cualquier se origine desde su servidor web al puerto 25 en cualquier servidor excepto su servidor de retransmisión SMTP. (Algunas personas pueden decirle que evite no solo las conexiones que se originan desde su servidor web al puerto 25, sino a todos los puertos posibles, ya que los servidores web deberían responder teóricamente a las solicitudes y no iniciar las solicitudes por sí mismos. Lamentablemente, esto causará problemas a sus clientes, por ejemplo. ejecute cualquier CMS que quiera responder a su repo de extensión, por ejemplo. Dejaré este tema para una discusión por separado.)
En la conexión entre su servidor web y su servidor de retransmisión SMTP, asegúrese de usar algún tipo de autenticación. Si es necesario, cree un usuario para cada sitio web en su servidor de retransmisión SMTP y solicite que el servidor web se autentique en el servidor de retransmisión SMTP para enviar correos. Esto hará que sea extremadamente sencillo para usted desactivar el envío de correo electrónico para un solo sitio web específico.
En su servidor de retransmisión SMTP, implemente técnicas razonables para evitar el spam. Por lo general, una combinación de limitación de velocidad y posiblemente escaneo de contenido (piense en Spamassassin) donde simplemente filtraría las puntuaciones altas de muy debería ayudar.

Uno podría imaginar algo de magia de scripting luego, cuando se detecta un nuevo brote de spam en el servidor de retransmisión SMTP, el usuario que pertenece al sitio web de envío se bloqueará automáticamente para evitar daños.

Después de todo, mantenga un segundo y tercer servidor de retransmisión SMTP en espera fría con una dirección IP pública diferente y, si es posible, en un ASN diferente. Si sus contramedidas fallan y la "dirección IP" de su primer servidor de retransmisión SMTP se "quema", puede cambiar inmediatamente a uno de sus servidores "aún desconocidos" para garantizar una entrega de correo saliente adecuada.

Nota: Al implementar esto, asegúrese de que entiende correctamente cosas como DKIM y SPF y establezca los registros adecuados. Entonces eso funcionará. Si necesita apagar un servidor que lo hizo en algunas listas de bloqueo (la mayoría de ellos no son tan secretos por cierto), por lo general se eliminará de la lista después de un tiempo (piense en semanas, no en horas) y esa IP estará disponible de nuevo para algún tipo de round robin.

score 4 · Answer 2

La respuesta de ThorstenS es acertada (+1 de mi parte); Para controlar el correo electrónico que estos sitios web están enviando, debe ejecutarlos en su propio servidor.

Sin embargo, no estoy de acuerdo con algunos de los detalles: cuando se habla de esos sitios web pequeños sobre alojamiento compartido, el cliente generalmente es una entidad pequeña sin ningún conocimiento técnico, que tenía algún amigo, un interno o un diseño web pequeño. La compañía creó un sitio web hace unos años, y para quién 'configura su software para que use esto, y solo esto, el servidor de correo' o 'asegúrese de que su software se autentique en el servidor de correo' está más allá de su capacidad.

Entonces, lo que haría no es bloquear puertos, los redirigiría a mi propio servidor de correo. Esto es bastante fácil usando iptables si estás usando un host Linux; puede encontrar un ejemplo de esto en ServerFault . Esto es transparente para sus usuarios, por lo que nadie necesita reconfigurar nada, y puede modificar su destino, nuevamente sin avisar a nadie, si es necesario.

A continuación, la limitación de velocidad por usuario: hay dos (bueno, tres) enfoques para esto sin requerir autenticación. O bien, coloque una etiqueta dependiente del usuario en sus paquetes SYN y use el limitador de velocidad de iptables . O, use esa etiqueta para redirigir a diferentes puertos en su servidor de correo, haga que el software de su servidor de correo escuche cada uno de ellos y use el puerto para distinguir entre los usuarios. O, la solución que es probablemente la más robusta (y la que tiene menos rendimiento), cuando una conexión tcp entra en el servidor de correo, obtenga el número de puerto remoto, llame a netstat -ntp o lsof o similar en el servidor web para obtener la propietario, y úsalo para limitar tu tarifa.

Si un usuario insiste en que tiene que usar un servidor de correo específico (por ejemplo, estoy usando mailtrap.io en mis sitios de prueba), abra el puerto a esa dirección (lo que puede ser una molestia si las direcciones son destinos móviles) ), o simplemente redirigirlos a otra configuración en su servidor de correo que hace la limitación de velocidad y tiene el objetivo real como reenviador.