Detén la fuerza bruta SSH en tus servidores Linux

Sí. El agente de SSH Protector lee el registro de autenticación de su propio sistema operativo y escribe reglas nftables que filtran el tráfico entrante hacia los puertos protegidos de ese mismo equipo. El agente no abre ningún socket a la escucha, no expone ningún canal de órdenes remotas e inicia únicamente HTTPS saliente. Nada dentro del agente puede actuar contra otra máquina.

Fail2ban analiza el registro de autenticación, cuenta los fallos dentro de findtime y programa el cortafuegos durante bantime, una dirección cada vez y solo en ese equipo. SSH Protector resuelve el origen a su prefijo anunciado y banea todo el /24 como una entrada de conjunto nftables, mantiene el conjunto entre reinicios en lugar de dejarlo expirar con un temporizador, lee systemd-journald a través de su API nativa en vez de emparejar líneas de texto con expresiones regulares, y comparte la reputación resultante con todos los demás equipos protegidos. La tabla de arriba pone ambos comportamientos por defecto uno junto a otro, y /guides/fail2ban-limitations desarrolla las diferencias por completo.

SSH Protector programa nftables por defecto, usando un conjunto con nombre para que muchos prefijos baneados queden tras una única consulta de regla en el hook input de netfilter. En equipos cuyo kernel o distribución sigue usando la ruta heredada, el agente recurre a iptables con ipset, lo que produce el mismo comportamiento a nivel de paquete. El agente detecta qué backend está en uso en lugar de suponerlo, y nunca vacía reglas que no haya creado él.

El agente es un ejecutable enlazado estáticamente con un conjunto residente por debajo de 10 MB y un uso de CPU que se mantiene cerca de cero entre eventos de autenticación, porque el trabajo por paquete ocurre en el kernel y no en el agente. El coste de analizar registros queda acotado al leer systemd-journald por su API nativa en lugar de seguir y emparejar con expresiones regulares /var/log/auth.log línea a línea.

Sí. Cada decisión de baneo se calcula en el equipo protegido a partir de su propio registro de autenticación, de modo que la protección contra fuerza bruta SSH continúa bajo la última política aplicada mientras el plano de control esté inaccesible. La reputación compartida es lo único que necesita conectividad, y su ausencia reduce la cobertura en vez de detener la protección local.

Un programa eBPF enganchado en XDP descarta paquetes en el controlador de red, que es la respuesta correcta a una inundación volumétrica. Un programa XDP no puede leer /var/log/auth.log, no puede observar un resultado de PAM y no puede distinguir una contraseña incorrecta de una correcta, así que la decisión sobre qué prefijo descartar sigue viniendo del análisis de registros en espacio de usuario. El tráfico de fuerza bruta SSH es una baja velocidad de paquete que transporta un intento de autenticación de alto valor, y el hook input de netfilter lo descarta mucho antes de que la velocidad de paquete llegue a ser la limitación.

El agente lee el puerto efectivo de sshd_config, de sus ficheros drop-in bajo /etc/ssh/sshd_config.d/ y de los sockets a la escucha del equipo, y reconstruye sus reglas nftables cuando ese puerto cambia. El puerto del demonio FTP se descubre igual, así que un puerto no estándar se detecta en lugar de configurarse.

No. El instalador añade a la lista blanca la dirección desde la que se ejecutó la instalación antes de confirmar la primera regla, y los orígenes en lista blanca se evalúan antes que cualquier ruta de bloqueo. La protección permanente contra bloqueos banea además un prefijo atacante antes de que se alcance el umbral deny de pam_faillock en /etc/pam.d/sshd, así que una tanda de fuerza bruta tampoco puede bloquear la cuenta real.

Cualquier distribución basada en systemd sobre x86-64 o ARM64: Debian, Ubuntu, RHEL, CentOS, AlmaLinux, Rocky Linux, Fedora y Alpine con systemd. El agente se entrega como un único binario enlazado estáticamente, así que en el equipo protegido no hay que resolver ningún intérprete, ningún runtime de Python ni ninguna dependencia de paquetes.

Los pagos internacionales los procesa PayPro Global como comerciante registrado, los pagos dentro de Rusia los procesa YooKassa, y la criptomoneda queda disponible como alternativa. El plan gratuito es permanente, cubre un servidor con protección completa contra fuerza bruta y no requiere tarjeta.

Con SSH Protector instalo el agente como un servicio systemd: lee el registro de autenticación localmente, determina el puerto sshd real y, después de un umbral de tiempo, bloquea la red de origen en el firewall del sistema. Agrego mi dirección o VPN a la lista blanca por adelantado, controlo el historial en el panel y guardo la política más reciente cuando pierdo Internet.

Gratis sin SSH Protector. Desactivo PasswordAuthentication y PermitRootLogin, dejo las claves en Ed25519, limito AllowUsers/AllowGroups y solo permito el puerto desde VPN o CIDR confiables. Si se requiere una contraseña temporalmente, configuro fail2ban usando journald/auth.log, reviso nftables/iptables, configuro findtime, maxretry y bantime, y pruebo periódicamente las excepciones desde la consola de respaldo.

Con SSH Protector bloqueo la fuente en los inicios de sesión fallidos reales sin importar el nombre que intente, y puedo extender la prohibición a la red del atacante. Verifico el puerto SSH encontrado, agrego la VPN administrativa a la lista blanca y uso una solución de agente local para que la protección no dependa de la disponibilidad del panel.

De forma gratuita, desactivo los inicios de sesión con contraseña y root, creo un usuario separado con sudo, subo una clave única a través de cloud-init y cierro el grupo de seguridad de la VPN/mis redes. Elimino las authorized_keys no utilizadas, habilito MFA en bastión, configuro fail2ban y alertas de contraseña/clave pública aceptadas para fuentes desconocidas; Considero cambiar el puerto solo para reducir el ruido.

Con SSH Protector instalo un agente estático que lee eventos locales y bloquea la fuente en el firewall hasta que la cuenta se ve comprometida. Utilizo protección gratuita para el primer servidor, incluyo mi canal en la lista blanca y me aseguro de que el agente siga trabajando sin conexión; Dejo la copia de seguridad y el privilegio mínimo como capas separadas.

De forma gratuita, bloqueo SSH detrás de WireGuard/Tailscale, desactivo las contraseñas y el root, solicito una clave con frase de contraseña y la limito a sudo. Almaceno copias de seguridad fuera del VPS con credenciales separadas, habilito actualizaciones de seguridad automáticas, fail2ban y auditoría de inicios de sesión exitosos; Compruebo la consola de emergencia del proveedor antes de reforzar el firewall.

Con SSH Protector utilizo un binario estático compatible para la arquitectura y el sistema apropiados, habilito el análisis de registros locales y el bloqueo de firewall sin un puerto de control entrante. Verifico la compatibilidad del sistema operativo y el firewall antes de la instalación, configuro una lista blanca de administración y me aseguro de que el agente no sobrecargue los recursos limitados del dispositivo.

De forma gratuita, no publico SSH externamente en absoluto: conecto el dispositivo a través de VPN, desactivo la contraseña y la raíz, permito una clave y una subred de control. Actualizo el firmware, desactivo los servicios no utilizados, configuro el fail2ban mínimo solo si hay suficiente memoria y guardo la configuración del firewall; Para un sistema operativo no compatible, elijo una puerta de enlace externa en lugar de un binario desconocido.

Con SSH Protector, habilito la lectura de registros SSH y FTP admitidos, dejo que el agente determine los puertos y aplico una única regla local a la red de origen. Agrego integraciones confiables a la lista blanca, verifico el historial en el panel y tengo en cuenta que la protección FTP avanzada y las funciones adicionales pueden depender de la tarifa.

De forma gratuita, reemplazo el FTP normal por SFTP sobre SSH o FTPS, si el protocolo es realmente necesario, y cierro el servicio de todo Internet. Creo cárceles fail2ban separadas para sshd y FTP, las dirijo a una nftables configurada con tiempo de espera, verifico el formato de registro después de las actualizaciones y desactivo las cuentas compartidas.

Con SSH Protector, dejo el bloqueo automático de red en todas las fuentes externas y incluyo en la lista blanca solo la VPN controlada, y no todas las IP domésticas. Utilizo el panel para ataques, pero guardo la identidad en cuentas y claves Unix separadas: el agente protege el perímetro y revoco el acceso eliminando una clave específica.

De forma gratuita, administro authorized_keys de forma centralizada a través de Ansible, emito una clave por persona y dispositivo con un comentario claro, desactivo cuentas compartidas y limito sudo. Habilito VPN/MFA en el bastión, configuro el período de acceso en el inventario, recopilo la clave pública aceptada con huella digital en SIEM y elimino automáticamente la clave al final del contrato.

Con SSH Protector, separo las direcciones de los corredores confiables a través de una lista blanca precisa y dejo todas las demás fuentes bloqueadas por inicios de sesión fallidos. No considero que esto sea un reemplazo del control de claves: el agente reduce la fuerza bruta desde el exterior mientras que las restricciones de la cuenta de servicio en sí contienen las consecuencias de una autenticación exitosa.

De forma gratuita, uso una clave Ed25519 separada para el trabajo, la almaceno en un almacén secreto, la restrinjo en authorized_keys a través de from=, command=, no-port-forwarding, no-agent-forwarding y no-pty. Solo permito SSH desde la red del corredor, emito comandos sudo mínimos, giro la clave regularmente y registro una huella digital en el registro de implementación.

Con SSH Protector, primero instalo una capa protectora adicional y pongo en la lista blanca la dirección administrativa actual mientras realizo la migración. El agente bloquea la fuerza bruta activa, toma en cuenta automáticamente el puerto real y deja la política fuera de línea, pero después de verificar con éxito las claves, todavía desactivo el inicio de sesión con contraseña.

De forma gratuita, abro una segunda sesión SSH y la consola del proveedor, agrego una clave única, verifico los permisos ~/.ssh 700 y Authorized_keys 600, ejecuto sshd -t y vuelvo a cargar sin cerrar la primera sesión. Luego configuro PasswordAuthentication no, KbdInteractiveAuthentication no y PermitRootLogin no, verifico el nuevo inicio de sesión y guardo la clave de emergencia por separado.

Con SSH Protector bloqueo inmediatamente fuentes y redes activas, reviso el historial de ataques y dejo el acceso solo a través de una lista blanca confiable. Luego cambio la contraseña/clave, finalizo las sesiones y analizo por separado la contraseña/clave pública aceptada; el bloqueo reduce la ventana de ataque, pero no prueba la ausencia de un inicio de sesión exitoso.

De forma gratuita, cierro temporalmente el grupo de seguridad SSH o nftables a la VPN, bloqueo al usuario, revoco las claves y cambio los secretos asociados. Verifico last/lastlog, journalctl, sudo, nuevos usuarios/claves, unidades cron/systemd, procesos y conexiones de red, luego restauro el acceso solo con clave y desactivo las contraseñas reutilizadas.

Con SSH Protector sigo bloqueando la fuerza bruta externa y veo fuentes sospechosas, pero no confío en ella para obtener la clave robada correcta. Inmediatamente elimino la huella digital de todos los servidores, emito una nueva clave con frase de contraseña y dejo la lista blanca solo para VPN; Investigaré las entradas exitosas por separado.

De forma gratuita, busco la clave pública anterior en todas las authorized_keys, la revoco mediante la administración de configuración y verifico la clave pública aceptada por huella digital y fuente. Emito un FIDO2/ed25519-sk de hardware o una clave con frase de contraseña y tiempo de espera de ssh-agent, desactivo el reenvío de agentes a menos que sea necesario y mantengo un registro del propietario, el dispositivo y las fechas de rotación.

Con SSH Protector adjunto un historial de ataques y bloqueos, configuración de políticas, una lista de servicios protegidos y excepciones aprobadas. Documento la solución local del agente, el canal TLS saliente y la falta de un puerto de control entrante, luego realizo inicios de sesión incorrectos controlados y guardo las líneas de registro, la regla del firewall y la notificación.

De forma gratuita, exporto sshd_config, nftables/ufw, fail2ban jail y changelog desde Git, y envío auth.log/journald a un almacenamiento seguro. Verifico PasswordAuthentication, PermitRootLogin, MFA/VPN y pruebo la revocación de clave mensualmente, firmo el resultado y almaceno evidencia durante el período requerido.

Con SSH Protector bloqueo la fuente en el firewall después de una serie de fallas, para que las siguientes conexiones TCP no lleguen a sshd y no creen tantas entradas. Mantengo una auditoría del sistema, controlo por separado el tamaño/retención del diario y uso el historial de ataques en el panel como índice, no como reemplazo del registro original.

De forma gratuita, cierro SSH a VPN/lista de permitidos, desactivo contraseñas e inicios de sesión estándar y envío fail2ban a nftables configurado con tiempo de espera. Configuro SystemMaxUse y la rotación de diario/rsyslog, envío eventos aceptados y fallidos clave a un syslog externo y no reduzco LogLevel por debajo del valor necesario para la investigación.

Con SSH Protector configuro el umbral y la ventana una vez, después de lo cual el agente crea y libera bloqueos localmente y la lista blanca tiene prioridad. Utilizo una prohibición de red donde el atacante rota las direcciones vecinas, verifica los cambios en el panel y guarda una consola de respaldo antes de la primera política.

De forma gratuita, reemplazo las reglas individuales eternas de iptables con nftables configuradas con tiempo de espera o acción fail2ban, configuro maxretry/findtime/bantime e ignoreip para VPN. Pruebo el filtro en líneas de registro reales, habilito la recidiva con cuidado, limito el tamaño establecido y superviso los errores de recarga después de una actualización de distribución.

Con SSH Protector conecto hosts con un agente compatible, veo los puertos y ataques detectados desde un panel, pero mantengo las excepciones y políticas dentro de los límites del servidor/cliente deseado. Aplico valores de referencia, documento las desviaciones por separado y notifico al cliente responsable.

De forma gratuita, describo sshd, fail2ban y nftables en roles de Ansible con un inventario y una bóveda separados para cada cliente, verifico cambios en CI y recopilo registros en Wazuh/syslog central con etiquetas de inquilino. Comparo automáticamente la configuración con la línea base y nunca combino claves, CIDR y secretos de diferentes clientes.

Con SSH Protector hago cumplir la política al agente por adelantado; continúa leyendo el registro local y cambia el firewall del sistema a la última configuración cuando se pierde la comunicación con el panel. Sincronizo la lista blanca antes del apagado, verifico el historial acumulado después de la restauración y no abro el puerto de control del agente entrante.

De forma gratuita, hago el control completamente local: nftables/ufw permite SSH solo desde una VPN o las subredes requeridas, y fail2ban funciona a través de journald sin una red externa. Guardo las reglas para la carga, configuro una cola local para notificaciones, pruebo un reinicio sin DNS y salgo de la consola física/del proveedor para restaurar la regla errónea.

Instalo el agente de SSH Protector mientras fail2ban sigue en marcha. El agente tiene su propia tabla de nftables (inet sshprotector, o un espacio de nombres de ipset con prefijo en equipos más antiguos) y solo reconstruye esa, así que nunca toca las cadenas de fail2ban y ninguno de los dos revierte al otro. Al instalar pongo primero mi propia dirección en la lista blanca y luego miro el panel durante un día para ver si el agente está cazando las mismas fuentes que la jail. Solo entonces paro fail2ban y retiro sus reglas. Si cambio de idea, desinstalar el agente se lleva sus propias reglas y deja el cortafuegos como estaba.

Sin ningún agente, el cambio entre dos herramientas que leen un registro se hace igual. Deja la vieja funcionando, dale a la nueva su propio nombre de cadena o de tabla para que las reglas no choquen, compara durante un día entero de tráfico real qué cazó cada una, y desactiva la vieja solo cuando el contador de baneos de la nueva haya dejado de ser el menor de los dos. Nunca quites primero la que funciona: unos pocos minutos sin protección en un puerto SSH expuesto le bastan a una botnet que ya te está escaneando.

Los dos resuelven problemas que se solapan, pero desde extremos distintos, y elijo por forma y no por puntuación. CrowdSec es un motor: un lenguaje de escenarios, componentes de bloqueo que instalas y conectas tú mismo, y una blocklist alimentada por todos los que lo ejecutan; su alcance va mucho más allá de SSH. SSH Protector es un binario que hace una cosa: lee el registro de autenticación de SSH, SFTP y FTP, banea todo el /24 del atacante en su propia tabla de nftables, mantiene ese baneo tras reiniciar, detecta el puerto real de sshd en vez de suponer el 22, e informa a un panel que me avisa cuando un servidor protegido se ha quedado callado. La reputación se comparte entre cuentas protegidas, no con el internet público.

Así que la decisión trata de lo que tengo de verdad. Si necesito amplitud - HTTP, bases de datos, fuentes de registro arbitrarias, mis propios escenarios de detección -, CrowdSec tiene sitio para eso y ejecutarlo no cuesta nada. Si lo que tengo es un puñado de máquinas Linux con el puerto SSH expuesto y nadie que mantenga una pila de detección, quiero la cosa estrecha que acierta sin configuración. No he medido las dos una contra otra en el mismo equipo, así que no elijo por cifras de rendimiento, y quien me las cite tampoco debería.