¿Cuál es el propósito de estos intentos de piratería en mi Plesk VPS a través de postfix?

Para ejecutar rápidamente las líneas de registro, cualquier cosa con postfix / in se relaciona con su servidor SMTP (el servidor responsable de enviar / recibir correo electrónico, donde, por ejemplo, IMAP presenta el correo electrónico a los usuarios).

Las otras líneas, relacionadas con plesk_saslauthd, son de su backend de autenticación para postfix.

Entonces:

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 conexión a postfix (probablemente en tcp / 25) fue realizada por un servidor en 91.200.12.150 (que no tiene un par A / PTR adecuado y afirma ser parte de 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)

A ese intento de conexión siguió un intento de inicio de sesión como usuario auditor , y después de que plesk_saslauthd generó un proceso para tratarlo, ese intento falló.

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]

Se le dice a Postfix que este usuario no se autenticó, informa tanto al 'cliente' y el cliente se desconecta.

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

El proceso utilizado para verificar las credenciales proporcionadas durante las salidas de conexión.

Las principales cosas que deberían preocuparte son:

• no permitir que las cuentas importantes sean reforzadas por los intentos repetidos e ilimitados
• garantizando en la medida de lo posible que los usuarios elijan buenas contraseñas.

En cuanto a sus otras preocupaciones, no hay suficientes registros para indicar si se puede abusar de su servicio.

Como @ dandavis menciona, esto sucede todo el tiempo, así que asegúrese de haber seguido las mejores prácticas aplicables. (OS, Plesk y servicios individuales) es probablemente una buena cosa.

Yo también he tenido este problema durante algún tiempo y no parece haber una respuesta clara para evitar que se comuniquen con el servidor de correo.

Lo que he encontrado, aunque funciona muy bien, es configurar las rutas estáticas en la opción de LAN. Uso de la dirección de intento de SASL fallido, seguido de la máscara de subred 255.255.255.255 y que apunta a la dirección de SU Router Gateway, por ejemplo: 192.168.1.1 y una métrica de 2.

Esto, literalmente, les detiene incluso a comunicarse con el servidor de correo y los envía de vuelta a la puerta. (Loop)

Lo encuentro 100% efectivo con este tipo de intrusión, desafortunadamente mi ASUS Router solo permite un máximo. 10 rutas estáticas. Instantáneamente reduce estos registros en un 90% una vez que se ingresan. Me refiero a revisarlos al menos semanalmente, eliminar algunas antiguas y aplicar cualquier dirección nueva que se esté utilizando. Es un poco de esfuerzo y administración, pero no es difícil y muy satisfactorio ver los resultados instantáneos de KAMA.