¿Mi servidor ha sido comprometido? (Ransomware relacionado)

3

Acabo de recibir un correo electrónico que corresponde a la descripción aquí, que se publicó hace solo un par de horas:

enlace

Dado que el remitente era [email protected] , es posible que alguien haya iniciado sesión en mi servidor Ubuntu o simplemente se haya enviado el correo electrónico al servicio de correo electrónico de mi servidor, en cuyo caso es solo correo no deseado.

No pude encontrar ninguna evidencia de inicios de sesión desconocidos utilizando last o en syslog , pero hay una cantidad increíble de estos en syslog hoy:

postfix/smtpd[24558]: connect from jackofallthreads.co[128.199.182.74]
postfix/smtpd[24558]: lost connection after UNKNOWN from jackofallthreads.co[128.199.182.74]
postfix/smtpd[24558]: disconnect from jackofallthreads.co[128.199.182.74]

El inicio de sesión SSH en mi servidor requiere una clave privada, y el inicio de sesión raíz está inhabilitado.

EDITAR: Aquí está el historial de Delivered del correo electrónico. Nota Tengo un reenvío de correo electrónico de $ME@$MYDOMAIN a [email protected]. ¿Cómo puedo deducir de esto si mi servidor se vio comprometido?

Delivered-To: [email protected]
Received: by $SOMEIP with SMTP id $ID;
        $DATE
Received: from localhost ($MYHOSTNAME. [$MYIP])
        by mx.google.com with ESMTP id $ID
        for <[email protected]>;
        $DATE
Received-SPF: neutral (google.com: $MYIP is neither ... admin@$MYDOMAIN) client-ip=$MYIP;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: $MYIP is neither ... admin@$MYDOMAIN) smtp.mailfrom=admin@MYDOMAIN
Received: from [$SOMEIP] (unknown [$SOMEIP])
    by localhost (Postfix) with ESMTP id $ID
    for <$ME@$MYDOMAIN>; $DATE
    
pregunta forthrin 17.03.2016 - 16:01
fuente

1 respuesta

3
  

El inicio de sesión SSH en mi servidor requiere una clave privada, y el inicio de sesión raíz está inhabilitado.

Es una precaución sensata para ssh.

  

Dado que el remitente era [email protected]

Si toma precauciones para su ssh, ¿aplica lo mismo a su SMTP? Debe tener al menos SPF configurado para su dominio. ¿Vos si? ¿El SPF está validado por su MTA receptor? Esto debería evitar que reciba correos electrónicos que no provengan de una fuente legítima (o al menos reduzca el ruido).

Suponiendo que tat SPF no funciona de extremo a extremo por el motivo que sea, ¿ha revisado los encabezados de los correos electrónicos para ver si realmente se originaron en sus servidores? Creo que es muy poco probable que lo hiciera, pero si este es el caso, entonces tiene buenas razones para sospechar que su servidor o el entorno de alojamiento se ha comprometido.

Si no es así, entonces considérelo como un pequeño indicador para que se resuelva la seguridad de su correo electrónico.

    
respondido por el symcbean 17.03.2016 - 16:15
fuente

Lea otras preguntas en las etiquetas