Qual è lo scopo di questi tentativi di hacking sul mio VPS Plesk tramite postfix?

Per eseguire rapidamente le righe di registro, qualsiasi cosa con postfix / in relazione al server SMTP (il server responsabile dell'invio / ricezione di e-mail, dove ad esempio IMAP presenta la posta elettronica agli utenti).

Le altre linee, relative a plesk_saslauthd, provengono dal tuo backend di autenticazione per postfix.

Apr  3 18:11:26 myvps postfix/smtpd[12561]: warning: hostname vps863.hidehost.net does not resolve to address 91.200.12.150: Name or service not known
Apr  3 18:11:26 myvps postfix/smtpd[12561]: connect from unknown[91.200.12.150]

Una connessione a postfix (presumibilmente su tcp / 25) è stata effettuata da un server al 91.200.12.150 (che non ha una coppia A / PTR corretta e afferma di far parte di hidehost.net)

Apr  3 18:11:26 myvps plesk_saslauthd[12563]: listen=6, status=5, dbpath='/plesk/passwd.db', keypath='/plesk/passwd_db_key', chroot=1, unprivileged=1
Apr  3 18:11:26 myvps plesk_saslauthd[12563]: privileges set to (103:113) (effective 103:113)
Apr  3 18:11:26 myvps plesk_saslauthd[12563]: failed mail authenticatication attempt for user 'auditor' (password len=9)

Il tentativo di connessione è stato seguito da un tentativo di accesso come utente auditor , e dopo che plesk_saslauthd ha generato un processo per affrontarlo, il tentativo non è riuscito.

Apr  3 18:11:26 myvps postfix/smtpd[12561]: warning: unknown[91.200.12.150]: SASL LOGIN authentication failed: authentication failure
Apr  3 18:11:26 myvps postfix/smtpd[12561]: lost connection after AUTH from unknown[91.200.12.150]
Apr  3 18:11:26 myvps postfix/smtpd[12561]: disconnect from unknown[91.200.12.150]

A Postfix è stato detto che questo utente non è riuscito ad autenticarsi, riporta tanto al 'client', e il client si disconnette.

Apr  3 18:11:56 myvps plesk_saslauthd[12563]: select timeout, exiting

Il processo utilizzato per verificare le credenziali fornite durante le uscite dalla connessione.

Le cose principali di cui dovresti preoccuparti sono:

• non consente di eseguire il bruteforce di account importanti con tentativi ripetuti e illimitati
• assicurando per quanto possibile che gli utenti scelgano password valide.

Per quanto riguarda gli altri dubbi, non c'è abbastanza log per dire se il tuo servizio può essere abusato.

Come menziona @ dandavis , questo accade sempre, quindi assicurati di aver seguito le migliori pratiche applicabili (OS, Plesk e singoli servizi) è probabilmente una buona cosa.

Anch'io ho avuto questo problema per un po 'di tempo, e non sembra esserci una risposta chiara per smetterla di comunicare con il server di posta.

Ciò che ho trovato anche se funziona davvero bene è l'impostazione di Percorsi statici nella tua opzione LAN. Utilizzo dell'indirizzo di tentativo SASL non riuscito, seguito dalla maschera di sottorete 255.255.255.255 e indirizzata all'indirizzo del gateway del router, esempio: 192.168.1.1 e una metrica di 2.

Questo li ferma letteralmente anche a comunicare con il server di posta e li rimanda fuori dalla porta. (Loop)

Trovo efficace al 100% con questo tipo di intrusione, sfortunatamente il mio router ASUS consente solo un max. 10 rotte statiche. Riduce istantaneamente questi log del 90% una volta inseriti. Faccio un punto di rivederli almeno una volta alla settimana, rimuovere alcuni vecchi e applicare tutti gli indirizzi più recenti che vengono utilizzati. È un po 'di sforzo e gestione, ma non è difficile e molto soddisfacente vedere risultati KAMA immediati.