Il mio server è stato compromesso? (Relativo al ransomware)

Naviga le tue risposte
3

Ho appena ricevuto un'email che corrisponde alla descrizione qui, che è stata pubblicata solo un paio di ore fa:

link

Poiché il mittente era [email protected] , qualcuno potrebbe aver effettuato l'accesso al mio server Ubuntu, oppure l'email è stata semplicemente inviata al servizio di posta elettronica sul mio server, nel qual caso è solo spam.

Non sono riuscito a trovare alcuna prova di accessi sconosciuti utilizzando last o in syslog , ma oggi ne esiste una quantità folle in syslog : 

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]

L'accesso SSH al mio server richiede una chiave privata e l'accesso root è disabilitato.

EDIT: questa è la cronologia Delivered della posta elettronica. Nota Inoltro di e-mail da $ME@$MYDOMAIN a [email protected]. Come si può ottenere da questo se il mio server è stato compromesso? 

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
    
posta forthrin 17.03.2016 - 16:01
fonte

1 risposta

3

SSH login to my server requires a private key, and root login is disabled.

È una precauzione ragionevole per ssh.

Since the sender was was [email protected]

Se prendi delle precauzioni per il tuo ssh, applichi lo stesso al tuo SMTP? Dovresti avere almeno SPF configurato per il tuo dominio. Fai? L'SPF è convalidato dal tuo MTA ricevente? Questo dovrebbe impedire di ricevere e-mail non da una fonte legittima (o almeno di ridurre il rumore).

Supponendo che SPF non stia funzionando end-to-end per qualsiasi motivo, hai controllato le intestazioni delle e-mail per vedere se effettivamente ha avuto origine sui tuoi server? Penso che sia molto improbabile, ma se questo è il caso, allora hai buone ragioni per sospettare che il tuo server o l'ambiente di hosting sia stato compromesso.

In caso contrario, pensaci come un piccolo suggerimento per ottenere la sicurezza della tua posta elettronica risolta.

    
risposta data 17.03.2016 - 16:15
fonte

Leggi altre domande sui tag

Sfruttare un buffer overflow senza SIGSEGV Uno dei miei file aperti è diventato un elenco di URL e codici dopo aver fatto clic su un collegamento su un messaggio di posta elettronica di phishing?