Es muy probable que tu servidor SSH esté sufriendo ataques cientos de veces al día. No basta con decir que es probable. Estoy seguro de que prácticamente al 100% tu servidor está siendo atacado cientos de veces al día. Aún así, muchos desarrolladores casi nunca abren la carpeta /var/log. Intenta ejecutar ahora en el terminal un simple journalctl -f | grep ssh.

Al observar correctamente los registros:

  • Quién

  • Cuándo

  • Dónde

  • Cómo
    Se intenta acceder al servidor, queda claramente expuesto.

En este artículo, se presenta cómo interpretar los registros del servidor SSH y métodos de análisis prácticos para encontrar signos de hacking desde la perspectiva del desarrollador.

1. ¿Dónde se almacenan los registros de SSH?

Commandbox 광고

La ubicación de los registros de SSH varía un poco entre las distribuciones de Linux.

En general:

  • Distribuciones de Ubuntu / Debian

    • /var/log/auth.log

  • Distribuciones de CentOS / RHEL

    • /var/log/secure

  • Comandos comunes basados en systemd

    • journalctl -u ssh.service o journalctl -u sshd

Está bien usar tail, pero personalmente prefiero verlo con journald, porque se pueden ver los registros de todos los servicios en un solo lugar.

# Ejemplo en Ubuntu
sudo tail -f /var/log/auth.log

# Ejemplo en CentOS/RHEL
sudo tail -f /var/log/secure

# Ver registros de servicios systemd en tiempo real
sudo journalctl -u ssh.service -f

Consejo: Aun en un servidor de desarrollo, sería bueno tener el hábito de “monitorear los registros” al menos de vez en cuando usando tail -f.

Para más detalles sobre el uso de journald, haz clic "aquí".

2. Desglose de una línea de registro de SSH

Veamos un ejemplo típico de una línea de registro de SSH para entender su estructura. (Ejemplo de Ubuntu)

2.1 Inicio de sesión exitoso con clave pública

Jan 10 12:34:56 myserver sshd[12345]: Accepted publickey for deploy from 203.0.113.10 port 50312 ssh2: ED25519 SHA256:xxxx

Significado de cada parte:

  • Jan 10 12:34:56 : Fecha y hora

  • myserver : Nombre del host

  • sshd[12345] : Nombre del proceso (demonio SSH) y PID

  • Accepted publickey : Autenticación exitosa, método de clave pública

  • for deploy : Nombre de la cuenta que inició sesión

  • from 203.0.113.10 : IP de origen de la conexión

  • port 50312 : Puerto del cliente

  • ssh2: ED25519 ... : Información de protocolo/tipo de clave

Al entender esto, podrás identificar rápidamente “quién se conectó desde dónde con qué clave”.

2.2 Fallo en inicio de sesión con contraseña

Jan 10 12:35:01 myserver sshd[12346]: Failed password for root from 198.51.100.23 port 50320 ssh2

  • Failed password : Falla en la autenticación de contraseña

  • for root : Intento en la cuenta root

  • from 198.51.100.23 : IP remota

Si ves que estos registros se repiten decenas a cientos de veces en intervalos de pocos segundos,
es casi seguro que se está llevando a cabo un ataque de fuerza bruta.

2.3 Intento de inicio de sesión con un usuario que no existe

Jan 10 12:35:05 myserver sshd[12347]: Invalid user admin from 198.51.100.23 port 50325
  • Invalid user admin : Intento de inicio de sesión con la cuenta admin que no existe en el servidor

Este también es un patrón común utilizado por bots automatizados.

3. Patrones de ataque comunes a través de los registros

Commandbox 광고

3.1 Ataque de fuerza bruta

Características:

  • Registros de Failed password ocurren con mucha frecuencia en un corto período de tiempo

  • Intentos repetidos desde la misma IP decenas a cientos de veces

  • Uso de nombres de cuenta como root, admin, test, oracle

Ejemplo rápido para comprobar:

# Conteo total de contraseñas fallidas
sudo grep "Failed password" /var/log/auth.log | wc -l

# Qué cuenta recibe más ataques
sudo grep "Failed password" /var/log/auth.log \
  | awk '{for (i=1;i<=NF;i++) if ($i=="for") print $(i+1)}' \
  | sort | uniq -c | sort -nr | head

3.2 Escaneo de usuarios no existentes

sudo grep "Invalid user" /var/log/auth.log | head

Si hay muchos registros de este tipo, significa que “están probando aleatoriamente qué cuentas pueden existir en este servidor”.

3.3 Intentos excesivos desde una IP específica

Para verificar qué IP está fallando especialmente:

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

En el código anterior, $(NF-3) generalmente apunta a la parte from <IP> de la IP, pero
puede variar un poco dependiendo del entorno, así que debe adaptarse al formato de sus registros.

4. Encontrar signos de anormalidad entre inicios de sesión “exitosos”

Normalmente los ataques terminan en fallos, pero lo verdaderamente alarmante son los inicios de sesión exitosos.

4.1 Recolección de registros aceptados

sudo grep "Accepted" /var/log/auth.log

Puntos a observar con especial cuidado:

  • Accesos desde cuentas que normalmente no se utilizan

  • Accesos en horarios poco comunes (ej: 3 a.m.)

  • IPs de países/rangos desconocidos (no de la oficina/casa/VPN)

4.2 Ver historial de accesos recientes de un solo vistazo

El comando last muestra el historial de inicios de sesión recientes.

# Historial reciente de inicios de sesión SSH
last -i | head

# Inicios de sesión fallidos (en entornos soportados)
lastb | head

Con solo hacer esto regularmente,
puedes descubrir fácilmente
“registros de conexión en horarios que no has accedido”.

5. Análisis práctico de registros: un ejemplo de rutina rápida de chequeo

Supongamos que tienes un servidor SSH,
y vamos a crear una rutina de chequeo que se puede hacer en 5 minutos.

5.1 Paso 1: Verificar cantidad total de inicios de sesión fallidos

sudo grep "Failed password" /var/log/auth.log | wc -l
sudo grep "Invalid user" /var/log/auth.log | wc -l
  • Si de repente aumentan los números drásticamente, se puede sospechar un “aumento en la intensidad de ataques”.

5.2 Paso 2: TOP 10 de las IPs más atacadas

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head
  • Las IPs principales pueden ser añadidas a las reglas de firewall/fail2ban.

5.3 Paso 3: Intentos de inicio de sesión como root

sudo grep "Failed password for root" /var/log/auth.log | tail
sudo grep "Accepted.*root" /var/log/auth.log
  • Si aparece Accepted, significa que ya se logró iniciar sesión como root, lo cual es extremadamente peligroso.

5.4 Paso 4: Escanear inicios de sesión exitosos recientes

sudo grep "Accepted" /var/log/auth.log | tail -n 50

Puntos a verificar aquí:

  • ¿Es una IP que no conozco?

  • ¿Es durante un horario laboral normal?

  • ¿Es una cuenta que apareció de repente?

6. ¿De qué sirve solo observar los registros? Medidas de defensa a aplicar de inmediato

Si has olfateado señales de un ataque a partir de los registros,
ahora debe haber configuraciones de defensa.

6.1 Desactivar el inicio de sesión por contraseña (solo permitir clave pública)

En /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Después de modificar:

sudo systemctl reload sshd
# O
sudo service ssh restart

Siempre desactiva la contraseña solo después de haber probado que el inicio de sesión con clave pública fue exitoso.
Si no, podrías quedar bloqueado fuera de tu propio servidor.

6.2 Prohibir el inicio de sesión directo como root

PermitRootLogin no

Es recomendable evitar que se inicie sesión directamente como root,
forcing el inicio de sesión como cuentas normales y usando sudo.

6.3 Cambiar el puerto (para reducir el ruido)

Port 22    # -> Cambiar a, por ejemplo: 2222

  • Cambiar el puerto no “fortalece” la seguridad, pero

  • Reduce significativamente los registros de ataques/utilización automática, haciendo que sea más fácil detectar
    “los verdaderos signos de anomalía”.

6.4 Usar herramientas como fail2ban

fail2ban monitorea los registros y

  • Desde la misma IP

  • En un corto período de tiempo

  • Si ocurren múltiples fallas de inicio de sesión

Agrega automáticamente reglas de firewall para bloquear esa IP.

El concepto es simple:

  1. Monitorizar el patrón Failed password en auth.log

  2. Bloquear la IP correspondiente con iptables/ufw al exceder un umbral específico

Es como automatizar el análisis de registros para bloquear automáticamente los ataques de fuerza bruta.

6.5 Limitar el acceso SSH mediante firewall

Si es posible:

  • Permitir acceso a 22/tcp (o el puerto cambiado) solo desde IPs fijas específicas o VPN de la empresa

  • Bloquear todas las demás conexiones

Ejemplo simple con ufw

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp
sudo ufw deny 22/tcp

7. “Rutina mínima de chequeo de registros” para desarrolladores

Si se resume a lo que los desarrolladores pueden realizar de manera realista durante su trabajo,
con solo hacer estas cosas una vez a la semana,
la sensibilidad a la seguridad cambiará completamente.

Una vez a la semana:

  1. Revisar la cantidad de Failed password e Invalid user en la última semana

  2. Verificar el TOP 10 de IPs con fallas más frecuentes

  3. Revisar en logs de Accepted

    • IPs nuevas,

    • Horarios inusuales,

    • Inventariar cuentas desconocidas

  4. Bloquear IPs sospechosas con firewall/fail2ban u otros métodos

Una sola vez de ver en persona,
te dará la sensación de
“Wow, este servidor realmente está siendo atacado todos los días”.

Un hacker atacando un servidor SSH

Conclusión: Comienza a revisar los registros ahora

La seguridad SSH comienza, antes de soluciones grandes,
observando lo que realmente sucede en tu servidor.

  1. Abrir /var/log/auth.log o /var/log/secure

  2. Leer en base a Failed password, Invalid user, Accepted

  3. Si hay algo extraño, inmediatamente revisar configuraciones y considerar implementar firewall, fail2ban

Si has terminado de leer este artículo,
ahora estás preparado para evitar “hacking por no ver los registros”.
Abre tu terminal y echa un vistazo a los registros de tu servidor.

Para los desarrolladores, la seguridad no es una opción, sino una necesidad y una rutina.

Puedes hacer clic "aquí" para conocer más sobre cómo usar Fail2ban.