Detén la fuerza bruta SSH en tus servidores Linux

Sí. El agente solo lee el registro de autenticación de su propio sistema operativo y bloquea conexiones entrantes a los puertos protegidos de esa misma máquina. Solo realiza peticiones HTTPS salientes y no abre puertos entrantes.

Sí. La decisión de bloquear se toma localmente en el agente, por lo que la protección sigue funcionando con la última política aplicada aunque la nube no esté disponible.

El agente detecta el puerto SSH real automáticamente a partir de sshd_config y de los sockets a la escucha, y reconstruye sus reglas cuando el puerto cambia. El puerto FTP se detecta igual.

No. Durante la instalación su dirección IP actual se añade a la lista blanca, y las fuentes de la lista blanca siempre tienen prioridad sobre cualquier bloqueo.

Cualquier distribución moderna basada en systemd - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - en x86-64 y ARM64. Un único binario estático sin dependencias adicionales.

Los pagos internacionales se procesan con PayPro Global, los pagos en Rusia con YooKassa, y la criptomoneda está disponible como alternativa. El plan Free es permanente 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.