Bloqueo de conta fronte a prohibición de enderezo: onde conta de verdade OpenVPN

Bloquear un enderezo e bloquear unha conta son dous mecanismos distintos e fallan en direccións opostas. Unha prohibición de enderezo detén unha orixe e deixa a conta obxectivo accesible desde outro lugar; un bloqueo de conta detén esa identidade en todas partes, mesmo no portátil do propio usuario.

Para unha VPN que delega a autenticación en PAM, o contador é aquilo a que chega a pila PAM, non o que rexistrou o oínte.

Dous contadores, dúas vítimas distintas

Un limitador de velocidade observa unha orixe e pregunta cantos intentos chegaron dela recentemente. Un bloqueo observa unha identidade e pregunta cantos fallos acumulou esa conta. O primeiro protexe a dispoñibilidade, o segundo a credencial; ningún substitúe o outro.

Por iso a frase bloqueamos o IP tras cinco fallos non é resposta a un informe de recheo de credenciais. O atacante rota orixes, cada unha recibe poucos intentos e a conta nunca se conta. Ao revés, un bloqueo sen control de orixe permite ao atacante manter a conta bloqueada indefinidamente fallando a propósito.

Os dous controis tamén teñen historias de recuperación distintas. Unha prohibición de enderezo caduca cun temporizador no que ninguén ten que pensar; un bloqueo pode necesitar un administrador, un período de espera documentado ou un restablecemento de autoservizo.

Atope o almacén que xa posúe o reconto

Antes de engadir nada, comprobe se xa existe un almacén de fallos. Unha conta local de Linux, un servizo de directorio e un provedor de identidade externo levan o seu propio reconto, e un módulo PAM diante crea un segundo en lugar de estender o primeiro.

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

Lea o ficheiro de servizo que a VPN nomea realmente e siga as súas liñas de inclusión. En moitas distribucións o servizo de VPN inclúe un ficheiro común, o que significa que o reconto que axusta tamén se aplica a SSH e aos inicios de sesión locais.

Se o directorio xa impón un bloqueo, a pregunta útil é como chega a conversa PAM a esa decisión e como o informa a VPN. Un reconto local por riba non se converte no contador do directorio, e as dúas políticas poden discrepar sobre cando se desbloquea a conta.

pam_faillock ten tres posicións de chamada, non unha

O módulo separa tres operacións que unha liña copiada adoita difuminar: comprobar se a conta xa está bloqueada, rexistrar un fallo e borrar o historial tras un éxito.

Aquí é onde a migración desde un módulo de reconto máis antigo adoita equivocarse. Copiar unha liña dun exemplo pam_tally2 que funciona nunha pila pam_faillock non é un cambio de nome; a configuración documentada é distinta, e unha chamada mal colocada pode rexistrar fallos sen comprobalos nunca.

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

A utilidade de inspección é a forma máis rápida de ver se o contador é real: mostra os fallos rexistrados dunha conta e pode borralos. Se un fallo controlado non cambia esa saída, a posición da chamada é incorrecta.

Un nome de servizo adicado non é illamento

Dar á VPN o seu propio ficheiro de servizo PAM fai visible a política pretendida, pero non limita o efecto. Calquera inclusión dun ficheiro común arrastra o que ese ficheiro fai, incluídos recontos para todo o sistema.

Decida explicitamente se o bloqueo debe cubrir só o acceso VPN ou cada servizo que autentica a mesma conta. As dúas respostas son defendibles; o fallo é crer que elixiu unha mentres a pila implementa a outra.

Despois teña en conta o custo. Un atacante pode provocar o bloqueo, e o usuario que sofre é o dono da conta. O limiar, o período de espera e a vía de recuperación administrativa forman parte da política, e a recuperación non debe depender de reconfigurar a VPN durante un incidente.

Acepte a secuencia, non un único rexeitamento

Probe con identidades designadas baixo un plan aprobado, e probe unha cadea en lugar dun só evento: unha conta válida autentícase, un contrasinal deliberadamente incorrecto move o contador, o bloqueo configurado entra en vigor e a recuperación documentada devolve o acceso.

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

Observe o comportamento de éxito con tanto coidado como o de fallo. Se un inicio de sesión correcto non borra o historial, a conta bloquearase tras unha acumulación lenta de erros ordinarios. Se borra todo de todos os servizos, o contador é máis feble do que afirma a política.

Por último, deteña os clientes desatendidos antes de declarar a vitoria. Unha credencial gardada que reintenta en segundo plano recreará os fallos minutos despois dunha recuperación e bloqueará de novo a conta. A limitación de velocidade por orixe pode quedar como control adicional, pero non é a política da conta.