Bienvenido a proyecto online, en este lugar vas a hallar la resolución a lo que estabas buscando.
Sí, parece que está experimentando un ataque de fuerza bruta. El atacante se encuentra en una dirección privada de clase B, por lo que es probable que sea alguien con acceso a la red de su organización quien esté llevando a cabo el ataque. Por los nombres de usuario, parece que se están ejecutando a través de un diccionario de nombres de usuario comunes.
Eche un vistazo a ‘Cómo detener / prevenir la fuerza bruta SSH’ (Serverfault) y ‘Prevención de ataques SSH de fuerza bruta’ (Rimu Hosting) sobre cómo tomar medidas para mitigar algunos de los riesgos relacionados con los ataques de fuerza bruta SSH.
Sí, esto se ve exactamente como un ataque de fuerza bruta y después de buscar en Google admins phoenix piglet rainbow parece que esta es la lista de palabras que está usando el atacante: https://github.com/hydrogen18/kojoney/blob/master/fake_users
Consulte la línea 116 en adelante. La lista de palabras se utiliza exactamente en el mismo orden.
Esta parece ser una lista de palabras genérica, ya que también está presente en otros sitios. por ejemplo, http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users
@TheJulyPlot ha proporcionado buena información sobre qué hacer para mitigar este ataque.
Nota rápida agregada sobre fail2ban, como mucha gente lo ha estado mencionando: el front-end es un firewall corporativo, el back-end solo ve la redirección / proxy / dirección interna que proviene del firewall.
Entonces no, 172.25.1.1 no es una máquina interna comprometida (y tanto el comentario en la respuesta como otra respuesta aquí que indica que es una máquina interna estan equivocados al comentar eso). Es una de las direcciones IP internas del firewall.
Fail2ban en el back-end solo bloquearía todas las posibilidades de usar SSH para tramos a la vez, ya que solo ve intentos fallidos de 172.25.1.1. Así que, por favor, sigue leyendo para conocer mi respuesta.
No hay dudas, como mencionan otras publicaciones, es dolorosamente obvio que estás bajo un ataque de fuerza bruta.
Sin embargo, eso no significa en absoluto que esté comprometido de alguna manera con los registros que nos ha mostrado. Por desgracia, en estos días los ataques de fuerza bruta ssh son demasiado comunes. La mayoría de las veces están realmente automatizados y no necesariamente están dirigidos a usted.
Como una historia de advertencia anecdótica, hace algunos años, el primer día que configuré nuevos servidores en un proveedor de ISP, el ssh abierto a Internet obtuvo más de 200k sondas de escaneo ssh en una sola noche.
En cuanto a la “dirección IP interna”, o está utilizando SNAT o una redirección de proxy 22 / TCP en el mejor de los casos, y las direcciones IP de Internet de origen no se muestran (lo cual no es la mejor práctica), o en el peor de los casos, su enrutador / cable módem está comprometidos.
Si realmente tiene una configuración SSH SNAT / proxy, le recomiendo que lo piense. Quiere registros de las direcciones IP reales y no de su red.
En cuanto a medidas, sí recomiendo algunas:
- No permita contraseñas en SSH; solo inicios de sesión utilizando certificados RSA;
- No abra ssh para el exterior; restringirlo a su red interna;
- Para acceder desde el exterior, acceda a través de un VPN; no exponga SSH a Internet en general;
- SYN de limitación de velocidad desde el exterior.
Si insiste absolutamente en tener Internet SSH abierto al exterior, tenga en cuenta que cambiar el puerto SSH predeterminado solo brinda una falsa sensación de seguridad, y bloquear temporalmente las direcciones IP solo ralentiza el ataque, ya que a menudo estamos hablando de granjas coordinadas de máquinas zombies.
Es posible que desee echar un vistazo a fail2ban si cambia su configuración para recibir directamente direcciones IP públicas que se conectan a usted; sin embargo, tenga en cuenta que si de hecho llega alguna IP externa con la dirección IP de su puerta de enlace, está bloqueando efectivamente todos los accesos SSH externos que la utilizan.
También hay otras salvedades; tenga en cuenta que hoy en día los zombies / malware toman fail2ban en cuenta, y volverá después del período de tiempo de espera predeterminado o se turnará con diferentes direcciones IP. (Lo he visto suceder). Incluso si usa la autenticación de certificado RSA obligatoria, los ataques de contraseña aún se registrarán y quemarán E / S, espacio en disco y ciclos de CPU.
En cuanto a la VPN, no necesita hardware dedicado; es trivial configurar una VPN en un servidor Linux o FreeBSD.
Si no se siente cómodo configurando uno desde cero, le recomiendo una VM con pfSense. para FreeBSD; strongSwan para configurar una VPN en un servidor Linux.
Si su servidor de aplicaciones para el usuario es Linux, otra alternativa es la activación de puertos. Sin embargo, debido a su funcionamiento inherente, solo lo recomiendo para entornos domésticos. Como lo señaló correctamente @GroundZero, “el golpe de puerto es seguridad por oscuridad y un atacante puede monitorear activamente el tráfico de su red para descubrir la secuencia de golpe”.
Cómo utilizar Port Knocking para ocultar su demonio SSH de los atacantes en Ubuntu
Como medida adicional, también puede limitar la tasa con las reglas de firewall / iptables SYN en el puerto 22. De esta manera, no limitará la tasa de sus conexiones legítimas, y iptables en Linux o la mayoría de los firewalls comerciales permiten esa configuración. He visto trucos desagradables como bots que atacan a algunos demonios lo más rápido posible antes de que entren en vigor las reglas de seguridad. Sin embargo, creo que en realidad ssh tiene defensas integradas contra eso.
Para responderte sobre el escaneo desenfrenado, sí. Tiene muchos actores maliciosos, redes zombis y malware que escanean constantemente el espacio de direcciones IP para encontrar servidores con versiones comprometidas de sshd, versiones de sshd vulnerables / antiguas, servidores con contraseñas predeterminadas / incorrectas / puertas traseras conocidas y simplemente servidores con openssh para ganar un punto de apoyo en un usuario sin privilegios, ya sea a través de la fuerza bruta o ataques de doble filo a través de phishing.
Después de tres ataques exitosos a través de phishing (en eventos separados) en mi host bastión en mi trabajo actual, decidí hacer una configuración de SSH dual en la que se solicita a todos los usuarios un certificado RSA en sshd_config, y solo la red interna permite la autenticación de contraseña, agregando al final del archivo de configuración como tal:
# sshd configuration allowing only RSA certificates
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24
PasswordAuthentication yes
Como otra historia de miedo anecdótica, antes de cambiar a certificados RSA obligatorios, uno de los compromisos de phishing se realizó en la semana exacta en que hubo dos actualizaciones del kernel para vulnerabilidades que permitieron la escalada de privilegios a la raíz, y si no hubiera actualizado en el acto, lo haría han sido root comprometidos. (y si mi memoria no me falla, fue alrededor del 4 de julio … a los piratas informáticos les encanta guardar esos ataques desagradables para las vacaciones)
En cuanto a los gráficos de los ataques reales en vivo en tiempo real, eche un vistazo a:
- La interfaz gráfica del proyecto nórdico. Es muy educativo.
- Un mapa de ataques DDOS.
- Una vista gratuita de la red de monitoreo de seguridad central de Checkpoint, donde los agentes son sus clientes.
Para terminar la respuesta:
No, probablemente no esté comprometido de ninguna manera.
Sí, tienes que tomar medidas para incrementar tu nivel de seguridad. Recomendaría un túnel / cliente VPN desde el exterior a su servidor VPN corporativo. Es lo que estoy haciendo en realidad.
También tengo un último e importante consejo: para asegurarse de que una cuenta normal no se vea comprometida, consulte su /var/log/auth.log registros de autenticación para una autenticación exitosa. Hay formas de iniciar sesión en openssh con ningún cuenta sin que esté registrada en /var/log/wtmp y consecuentemente no aparecer en el last mando.
No hace falta decir que si una cuenta normal se ve comprometida en una máquina antigua sin actualizaciones, todas las apuestas están canceladas. Y en el desafortunado caso de la escalada de privilegios a root, incluso los registros pueden verse comprometidos.
Eres capaz de añadir valor a nuestra información contribuyendo tu experiencia en las aclaraciones.