GNU/Linux >> Tutoriales Linux >  >> Ubuntu

Muchos errores de autenticación de Pam en los registros dirigidos al servidor de correo. ¿Cómo detenerlo?

Necesito ayuda para identificar algunos errores en mi auth.log archivo en mi servidor Ubuntu. Hace unas semanas, encontré una gran cantidad de intentos de inicio de sesión en mi puerto SSH (22) en auth.log , así que cambié mi puerto SSH. Estuvo limpio durante una semana, y luego encontré otro montón de intentos de inicio de sesión a través de un puerto diferente.

Recibo muchos duplicados de las líneas en rojo (en la imagen). Las líneas repetidas son las siguientes:

saslauthd[1140]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[1140]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1140]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[1140]: do_auth         : auth failure: [user=roselia] [service=smtp] [realm=mail.mydomain.com] [mech=pam] [reason=PAM auth error]

Puedo decir que están tratando de iniciar sesión en mi servidor de correo (ya que el reino es mail.mydomain.com ), pero no puedo decir exactamente lo que están tratando de hacer, ya que no sé qué es PAM. ¿Qué es PAM? ¿Y qué debo hacer para detener estos intentos de autenticación en mi servidor de correo (puerto 25)?

Ocasionalmente también obtengo algunos registros CRON en mi auth.log que está relacionado con PAM, y sería genial si alguien pudiera decirme qué significan estos también:

CRON[32236]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32235]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32236]: pam_unix(cron:session): session closed for user root
CRON[32235]: pam_unix(cron:session): session closed for user root

Respuesta aceptada:

En primer lugar, esto no es raro de ver en los servidores de correo. Cada El servidor de correo en Internet los ve si el puerto 25 está expuesto a la web. Incluso las puertas de enlace de correo y los servidores de correo en mi lugar de trabajo se ven afectados por estos, por lo que muchos de estos intentos se filtran y bloquean es el IDS/IPS (Sistema de detección/prevención de intrusión) en el borde de la red que se refiere a muchas fuentes de OSINT (Inteligencia de fuente abierta) para crear un conjunto basado en la reputación de direcciones IP incorrectas que son obstruido. Algunas de estas sondas pasan, pero no tienen éxito cuando lo intentan.

Con toda probabilidad, no es una fuerza bruta dirigida contra su servidor, son "los escáneres y sondas de Internet" haciendo lo suyo en cada servidor SMTP orientado a Internet. Probablemente se trate de robots de spam que intentan sondear retransmisiones abiertas y, si no encuentran una retransmisión abierta, es probable que intenten obtener acceso a las cuentas para utilizar el servidor SMTP como retransmisión de correo. O es un escáner de servicio que intenta ver si tiene "contraseñas débiles" en juego para que puedan explotarlas y luego explotar su servidor para enviar su propio correo a través de sus servidores de correo.

Relacionado:¿Falta Hibernate en el menú de encendido y cuando presiono el botón de encendido de la computadora portátil?

Mientras siga las otras prácticas de seguridad de contraseñas seguras, no dando acceso a los usuarios a menos que lo necesiten, etc., debería estar listo en términos de que no irrumpirán en su servidor. Estaría menos preocupado por las fallas de autenticación y más preocupado si las autenticaciones fueran exitosas.

Una opción de seguridad adicional es configurar Fail2Ban que funcionará para prohibir a los usuarios, sin embargo, todavía tengo que hacer que esto funcione correctamente y no he tenido tiempo de profundizar en él para hacer que fail2ban funcione para que mi servidor de correo prohíba automáticamente las IP si fallan. para autenticar demasiadas veces). Sin embargo, tenga cuidado con esto, porque también puede bloquearle a usted. si no tienes cuidado. (Una vez que tenga una configuración de Fail2Ban 'funcional', la compartiré como un comentario a esta respuesta, pero ha sido complicado lograr que se comporte de la manera que quiero)

En cuanto al cron:session entradas en su auth.log , eso es solo una nota que el cron del sistema el demonio está ejecutando cron tareas desde /etc/crontab , /etc/cron.{d,daily,hourly,monthly,weekly}/* y la root usuario crontab según la programación establecida para trabajos cron como usuario root (donde los crontabs están configurados para ejecutarse como root ). Por lo general, están bien, siempre que verifique cada uno de los crontab en la cuenta raíz para asegurarse de que nada "malo" se ejecute automáticamente como root .


Ubuntu
  1. ¿Cómo detener el script Loop Bash en la terminal?

  2. ¿Cómo tener un módulo Pam de respaldo?

  3. ¿Cómo devolver una tarea en segundo plano para que esté en primer plano?

  4. ¿Cómo invocar al Hud?

  5. Cómo monitorear los registros de autenticación del sistema en Ubuntu

Cómo detener las redirecciones en Google Chrome

Cómo administrar los registros del sistema usando Webmin

¿Cómo evitar que /var/log/kern.log.1 consuma todo el espacio en disco?

¿Cómo evitar que el actualizador de software me moleste para reiniciar?

¿Cómo evitar que ciertas aplicaciones aparezcan en el tablero?

¿Cómo usar la sección Registros de acceso en hPanel?