Bloqueo de cuenta frente a prohibición de dirección: dónde cuenta realmente OpenVPN

Bloquear una dirección y bloquear una cuenta son dos mecanismos distintos y fallan en direcciones opuestas. Una prohibición de dirección detiene un origen y deja la cuenta objetivo accesible desde otro lugar; un bloqueo de cuenta detiene esa identidad en todas partes, incluso en el portátil del propio usuario.

Para una VPN que delega la autenticación en PAM, el contador es aquello a lo que llega la pila PAM, no lo que registró el oyente.

Dos contadores, dos víctimas distintas

Un limitador de velocidad observa un origen y pregunta cuántos intentos llegaron de él recientemente. Un bloqueo observa una identidad y pregunta cuántos fallos ha acumulado esa cuenta. El primero protege la disponibilidad, el segundo la credencial; ninguno sustituye al otro.

Por eso la frase bloqueamos la IP tras cinco fallos no es respuesta a un informe de relleno de credenciales. El atacante rota orígenes, cada uno recibe pocos intentos y la cuenta nunca se cuenta. A la inversa, un bloqueo sin control de origen permite al atacante mantener la cuenta bloqueada indefinidamente fallando a propósito.

Los dos controles también tienen historias de recuperación distintas. Una prohibición de dirección caduca con un temporizador en el que nadie tiene que pensar; un bloqueo puede necesitar un administrador, un periodo de espera documentado o un restablecimiento de autoservicio.

Encuentre el almacén que ya posee el recuento

Antes de añadir nada, averigüe si ya existe un almacén de fallos. Una cuenta local de Linux, un servicio de directorio y un proveedor de identidad externo llevan su propio recuento, y un módulo PAM delante crea un segundo en lugar de extender el primero.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

Lea el archivo de servicio que la VPN nombra realmente y siga sus líneas de inclusión. En muchas distribuciones el servicio de VPN incluye un archivo común, lo que significa que el recuento que ajusta también se aplica a SSH y a los inicios de sesión locales.

Si el directorio ya impone un bloqueo, la pregunta útil es cómo llega la conversación PAM a esa decisión y cómo lo informa la VPN. Un recuento local encima no se convierte en el contador del directorio, y las dos políticas pueden discrepar sobre cuándo se desbloquea la cuenta.

pam_faillock tiene tres posiciones de llamada, no una

El módulo separa tres operaciones que una línea copiada suele difuminar: comprobar si la cuenta ya está bloqueada, registrar un fallo y borrar el historial tras un éxito.

Aquí es donde la migración desde un módulo de recuento más antiguo suele equivocarse. Copiar una línea de un ejemplo de pam_tally2 que funciona en una pila de pam_faillock no es un cambio de nombre; la configuración documentada es distinta, y una llamada mal colocada puede registrar fallos sin comprobarlos nunca.

faillock --user alice
faillock --user alice --reset

La utilidad de inspección es la forma más rápida de ver si el contador es real: muestra los fallos registrados de una cuenta y puede borrarlos. Si un fallo controlado no cambia esa salida, la posición de la llamada es incorrecta.

Un nombre de servicio dedicado no es aislamiento

Dar a la VPN su propio archivo de servicio PAM hace visible la política pretendida, pero no limita el efecto. Cualquier inclusión de un archivo común arrastra lo que ese archivo hace, incluidos recuentos para todo el sistema.

Decida explícitamente si el bloqueo debe cubrir solo el acceso VPN o cada servicio que autentica la misma cuenta. Ambas respuestas son defendibles; el fallo es creer que eligió una mientras la pila implementa la otra.

Luego tenga en cuenta el coste. Un atacante puede provocar el bloqueo, y el usuario que sufre es el dueño de la cuenta. El umbral, el periodo de espera y la vía de recuperación administrativa forman parte de la política, y la recuperación no debe depender de reconfigurar la VPN durante un incidente.

Acepte la secuencia, no un solo rechazo

Pruebe con identidades designadas bajo un plan aprobado, y pruebe una cadena en lugar de un solo evento: una cuenta válida se autentica, una contraseña deliberadamente incorrecta mueve el contador, el bloqueo configurado entra en vigor y la recuperación documentada devuelve el acceso.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

Observe el comportamiento de éxito con tanto cuidado como el de fallo. Si un inicio de sesión correcto no borra el historial, la cuenta se bloqueará tras una acumulación lenta de errores ordinarios. Si borra todo de todos los servicios, el contador es más débil de lo que afirma la política.

Por último, detenga los clientes desatendidos antes de declarar la victoria. Una credencial guardada que reintenta en segundo plano recreará los fallos minutos después de una recuperación y volverá a bloquear la cuenta. La limitación de velocidad por origen puede quedarse como control adicional, pero no es la política de la cuenta.